Friday, July 11, 2014

OSSEC pull requests

Since switching to github OSSEC has made some decent progress. Changes big and small have been submitted, and most of them were accepted. It's been great so far.

The biggest problem I've noticed is that I see the same names over and over. There aren't a lot of users submitting patches or issues (especially without prompting). I definitely don't see a lot of users commenting on issues and pull requests, and I think that needs to change.

The OSSEC development team is very small, and we have limited access to resources (especially time). It would be great if other users started testing out some of these changes, and report successes and failures. I've started posting links to some pull requests on twitter in the hopes of interesting people who use those bits of OSSEC.

The ones I pointed out are:

I know everyone has limited time, but it would benefit a lot of people to get some testing done. Not testing the bits you use can hurt you down the road. I hope to see some new usernames in the future!

Thursday, June 5, 2014

OSSEC 2.8 was released

It was kinda quiet, but OSSEC 2.8 was released.

Check the release notes here.

The only thing I want to point out with this release is the removal of rules/bro-ids_rules.xml. It was incomplete, old, and incorrect. Unfortunately, removing the file was probably the wrong way to move on. If you have problems starting OSSEC after an upgrade, make sure that file exists or isn't mentioned in etc/ossec.conf.

A big thanks to all of the contributors, new and old. There's a lot of interest in OSSEC, and it's great to see.

If anyone sees any issues with the documentation, let me know (on the mailing list or create an issue/pull request on ).

Download 2.8 here

Wednesday, June 27, 2012

OSSEC 101: Homework

Remember OSSEC 101? It's still alive. Really. I promise! You can see the current version here.

It seems like every time I try to work on it I start wondering if it should be OSSEC by Example instead of OSSEC 101. I'm not a huge fan of how-to type documents, but maybe scenario based documentation could work.

Changing from the current plan to scenario based documentation would mean throwing out everything I've done so far, and I don't think that's worth it (if it is, let me know!). But can I add scenarios to the current documentation without overly complicating things? Could these scenarios be both useful and generic enough that they won't need to be updated every week? If the documentation is difficult to keep up to date, then it won't be kept up to date.

I plan on adding scenarios for every FAQ entry that's appropriate. I have a few other scenario ideas, but my OSSEC experience is limited. Because of this I need help from the OSSEC community. I want scenarios. I want to know what people are doing with OSSEC that should be documented in this fashion.

So your homework: Give me scenarios. Look over the OSSEC 101 documentation that' s currently there, and give me feedback. If you don't understand something, let me know.

Also, I  want to put some information in OSSEC 101 about GUI front ends that people are using. I also don't want to install and use all of the available front ends. At some point in the future I may be looking for information, screen shots, gotchas, etc. for the various GUIs. Be prepared to contribute.

EDIT:
First attempt at a scenario: ossec-authd. Let me know what you all think!

Tuesday, December 27, 2011

OSSEC 101: The Slackening

In a small attempt to stop slacking I managed to add a bit to the OSSEC 101 project. Yesterday I wrote the initial draft of the OSSEC Linux agent installation. I had already written the companion OSSEC server installation, so an agent install was the next logical step. Since I don't have a lot of Windows machines, capturing the Linux agent installation was much easier. (I just noticed the server installation is missing an image, and I'm sure it needs some polish.)

Hoping that a bit of color would differentiate the agent bits from the server bits, I decided to use red backgrounds for putty in the agent installation screenshots. Please let me know if it just looks stupid, or if a different color would be more appropriate.

I'm not quite sure how much information should be in these sections. I don't want OSSEC 101 to turn into the typical how-to document, with a bunch of copy & paste commands. I want you to know what you're running and why you're running it. There will probably be more added to these install pages before I consider them done, but they're already useful.

The Windows agent page might stay blank for a while. I do have a Windows machine I could reinstall OSSEC onto, but meh.

Along with the slacking I've been trying to come up with scenarios for OSSEC 101. I thought it might be easier to explain things if I had real world examples of how some people use OSSEC, and I have a few ideas already. I'm always looking for more ideas, so feel free to send me any ideas (or create an issue at my bitbucket).

So that's 2 sections down, a LOT more to go. Hopefully I'll be able to devote more time to this next year. Hopefully.

Tuesday, November 1, 2011

More OSSEC Documentation

During the 3WoO I posted about the current state of the OSSEC documentation (3woo ossec documentation) and how you can help. This post is about the future of the OSSEC documentation.

I want to keep new features that haven't been in an official release documented, but not in the official OSSEC documentation. I thought this might keep people from getting confused and trying to use a new feature in an older version (I've done it, it isn't pretty). Thankfully mercurial makes having multiple repositories simple. I have a number of sandbox repositories, that will never see the light, filled with half baked ideas and dead ends.

The OSSEC documentation has now been forked. By the person maintaining the old documentation. It's not very exciting, I know (there's more exciting bits later, keep reading!). Most of the information will be the same between the ossec-rules repository and the ossec-docs-dev repository. ossec-docs-dev is just the development area. So changes to ossec-rules will make it into ossec-docs-dev, and when the next version of OSSEC (currently 2.7) is released ossec-docs-dev changes will be pushed into ossec-rules.

Now here's the exciting bit of the new repository: OSSEC 101! We're starting a new section to detail the life cycle of an OSSEC setup. It will cover installation, configuring, tuning, expanding, integrating, and more! It's just a skeleton outline at the moment, but it's being worked on.

I'd love input from the community on anything I'm doing right, or wrong, or missing. What works? What doesn't? What would you like to see? You can keep an eye on the commits at the bitbucket repository, as well as file issues, fork the repository, etc.

As long as the traffic isn't too heavy I'll have the development documentation up at devio.us as well. Go here to see it.

I had originally meant to post this for the recent Third Annual Week of OSSEC, but ran out of time.

Thursday, October 27, 2011

3WoO: Watching for Potentially Malicious Domains with OSSEC

I like logs, lots and lots of logs. When I find out certain logging capabilities aren't turned on I get confused. When I find out that they're turned on but not monitored I get angry.

DNS has been a thorn at a few places I've done work for in the recent past. There are requirements to record and monitor DNS queries, but no one seems to have a good solution. The general purpose of monitoring DNS was to look for malware that used DNS to connect to outside sites for data exfiltration. It may sound lame (not to me), but it can be quite effective depending on the intelligence you have on the threats most important to your organization.

Using snort to monitor DNS queries and responses has provided less than perfect results. Usually the sensor is placed in such a way that only recursive lookups are seen, so we end up with a bunch of alerts blaming the DNS server itself.

This post will help document part of a plan to monitor DNS. This only covers the major *nix daemons, not Windows (if someone gets me Windows logs I'll work on that too). It also only monitors the queries, not the responses. I had something that worked with bro-ids to monitor responses, but I haven't been able to test it in quite a while. I'm planning on waiting for the next major bro-ids release to update it. This method can also be worked around in a number of ways (including using domain names that aren't known to be bad, or subdomains not in the list), but it's a start.

I've tested this method with both bind and unbound, but should work with any software that logs these queries and an appropriate OSSEC decoder.

The first step is to turn on the proper logging.

Setting up the unbound.conf is simple:

log-queries: yes

Configuring named.conf is a bit more difficult:

logging {

        channel "default2" {
                syslog local7;
                severity info;
        };

        category lame-servers { null; };
        category "queries" { "default2"; };
        category "unmatched" { "default2"; };
};

I just have to make sure my syslogd is watching for local7 alerts, and writing them to a file. Configuring OSSEC to watch this logfile is pretty simple. On my system I just add the following to ossec.conf:


<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/local7</location>
</localfile>

After making the logging changes to your dns daemon you'll have to restart it. Make sure logs are being populated with client queries.

Example unbound logs (differences in timestamps are from rsyslog vs OpenBSD's syslogd):

2011-10-26T15:46:15.508083-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 www.ossec.net. A IN
2011-10-26T15:45:54.895874-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 www.google.com. A IN
2011-10-26T15:46:48.366164-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 caladan.example.com. A IN
2011-10-26T15:47:24.372937-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 wallach9.example.com. A IN
2011-10-26T15:47:24.373670-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 wallach9.be.example.com. A IN

And bind:
Oct 26 16:07:08 ix named[14044]: client 192.168.17.9#22193: query: www.ossec.net IN A +
Oct 26 16:05:51 ix named[14044]: client 192.168.1.9#19095: query: wallach9.example.com IN A +
Oct 26 16:05:51 ix named[14044]: client 192.168.1.9#26269: query: wallach9.be.example.com IN A +
Oct 26 16:03:21 ix named[14044]: client 192.168.1.16#38892: query: www.google.com IN A +

Let's look at these logs in ossec-logtest. bind first:
[root@zanovar ossec]# /var/ossec/bin/ossec-logtest
2011/10/26 16:07:46 ossec-testrule: INFO: Reading local decoder file.
2011/10/26 16:07:46 ossec-testrule: INFO: Started (pid: 11804).
ossec-testrule: Type one log per line.

Oct 26 16:07:08 ix named[14044]: client 192.168.17.9#22193: query: www.ossec.net IN A +


**Phase 1: Completed pre-decoding.
       full event: 'Oct 26 16:07:08 ix named[14044]: client 192.168.17.9#22193: query: www.ossec.net IN A +'
       hostname: 'ix'
       program_name: 'named'
       log: 'client 192.168.17.9#22193: query: www.ossec.net IN A +'

**Phase 2: Completed decoding.
       decoder: 'named'
       srcip: '192.168.17.9'
       url: 'www.ossec.net'

The domain name is decoded in the url section. Let's try the unbound log:
[root@zanovar ossec]# /var/ossec/bin/ossec-logtest
2011/10/26 16:11:47 ossec-testrule: INFO: Reading local decoder file.
2011/10/26 16:11:47 ossec-testrule: INFO: Started (pid: 11805).
ossec-testrule: Type one log per line.

2011-10-26T15:46:15.508083-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 www.ossec.net. A IN


**Phase 1: Completed pre-decoding.
       full event: '2011-10-26T15:46:15.508083-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 www.ossec.net. A IN'
       hostname: 'arrakis'
       program_name: 'unbound'
       log: '[8113:0] info: 127.0.0.1 www.ossec.net. A IN'

**Phase 2: Completed decoding.
       No decoder matched.

There is no unbound decoder currently. That's easy to fix. (in case there are any errors in the HTMLization of the decoders below feel free to grab this file)
Add the following to /var/ossec/etc/local_decoder.xml:
<decoder name="unbound">
  <program_name>^unbound</program_name>
</decoder>

<decoder name="unbound-info">
  <parent>unbound</parent>
  <prematch offset="after_parent">^\p\d+:\d+\p info: </prematch>
  <regex offset="after_prematch">^(\S+) (\S+) \S+ \S+$</regex>
  <order>srcip, url</order>
</decoder>


And this is how it decodes now:
[root@zanovar ossec]# /var/ossec/bin/ossec-logtest
2011/10/26 16:17:16 ossec-testrule: INFO: Reading local decoder file.
2011/10/26 16:17:16 ossec-testrule: INFO: Started (pid: 11810).
ossec-testrule: Type one log per line.

2011-10-26T15:46:15.508083-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 www.ossec.net. A IN


**Phase 1: Completed pre-decoding.
       full event: '2011-10-26T15:46:15.508083-04:00 arrakis unbound: [8113:0] info: 127.0.0.1 www.ossec.net. A IN'
       hostname: 'arrakis'
       program_name: 'unbound'
       log: '[8113:0] info: 127.0.0.1 www.ossec.net. A IN'

**Phase 2: Completed decoding.
       decoder: 'unbound'
       srcip: '127.0.0.1'
       url: 'www.ossec.net.'

We're one step closer to having this all work. The next step is to decide on which domain names you want to alert on. I use a number of sources and a bad python script (seriously bad, you can't have it) to create a list of suspicious domains.
I use lists from Malware Domain List, DNS-BH - Malware Domain Blocklist (please donate!), and abuse.ch Zeus Tracker. I also have a list setup for domains I hear about that may not be on these other lists, and some other lists I don't pull via the script. A quick note about the DNS-BH site: That site is primarily a source for creating a DNS blackhole. This can keep your systems from ever getting to these bad sites (redirect them to a "honeypot" system to see what traffic they try to pass). I definitely recommend doing this, it's almost a free bit of security. It's also easy to setup in both bind and unbound/nsd. I've configured both to do this, so if anyone is interested let me know!
Of course, if you're worried about RAM usage this may not be the best idea:
  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
14044 named      2    0 1088M  885M sleep/1   select   34:53  0.00% /usr/sbin/named

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
19753 _nsd       2    0  296M  249M idle      select    0:03  0.00% /usr/sbin/nsd -c /etc/nsd.conf

After collecting a list of possibly malicious domains, you'll want to create a CDB list. CDB is a key-value database format. It's great for lists that are fairly static. There's no way to add or remove items from the database, you have to recompile it from scratch. Recompiling these lists is pretty simple and quick, so it isn't much of an issue
The format is also simple:
key: value

My lists generally look like:
DOMAIN: Suspicious Domain

After this, move the list to your ossec directory, I keep mine in /var/ossec/lists. Next we configure OSSEC to use the list by adding them to the rules section:
<rules>
  ...
    <list>lists/blocked.txt.cdb</list>
    <list>lists/userlist.txt.cdb</list>
    <include>local_rules.xml</include>
</rules>

Compiling the lists is easy, and if the files haven't changed since the last recompile ossec-makelists will notify you that they don't need to be recompiled. When a list is updated you should not have to restart the OSSEC processes, they should pick up the changes automatically.
# /var/ossec/bin/ossec-makelists
 * File lists/blocked.txt.cdb does not need to be compiled
 * File lists/userlist.txt.cdb does not need to be compiled
# rm /var/ossec/lists/userlist.txt.cdb
# /var/ossec/bin/ossec-makelists
 * File lists/blocked.txt.cdb does not need to be compiled
 * File lists/userlist.txt.cdb need to be updated

The last piece will be creating a rule to use the list. These are the rules I have for unbound, but the bind rules look very similar:
   <rule id="40000" level="0" noalert="1">
    <decoded_as>unbound</decoded_as>
    <description>Grouping for unbound.</description>
  </rule>

  <rule id="40001" level="10">
    <if_sid>40000</if_sid>
    <list field="url">lists/blocked.txt</list>
    <description>DNS query on a potentially malicious domain.</description>
  </rule>

The list item compares the decoded url to the keys in blocked.txt.cdb database. If there is a match rule 40001 fires, if that url isn't in the database then it doesn't fire.
Hopefully this post gave you some ideas. There's more you can do with lists, so take a look at the documentation (more here).
Just a little teaser, I'm planning on another documentation post tomorrow or Friday. Stay tuned!

Wednesday, October 26, 2011

3WoO: Day X through Y Roundup!

I've been slacking! In no particular order:

Alerting on DNS Changes - Daniel Cid
Leveraging Community Intelligence - Michael Starks
Mapping OSSEC Alerts with Afterglow - Xavier Mertens
Detecting Defaced Websites with OSSEC - Xavier Mertens
Five Tips and Tricks for OSSEC Ninjas - Michael Starks
Week of OSSEC Roundup - Daniel Cid
You Got Your OSSEC in my Logstash
You got your OSSEC in my Logstash Part 2

If I missed something, let me know!

UPDATE:
It's not really 3WoO related, but BSD magazine has an OSSEC on OpenBSD article.

UPDATE 2:
Someone made an ossec reddit.