3WoO: Alerting on DNS (IP Address) changes

If you keep your DNS outside and you can’t monitor the zone files directly, a nice way to make sure the integrity of your DNS is intact is by checking remotely that it hasn’t been changed.

With OSSEC, you can do it using the command monitoring output.

First, download the latest version from here and install it.

You will see a new tool in the /var/ossec/bin directory:

# /var/ossec/bin/util.sh
/var/ossec/bin/util.sh: addfile <filename> [<format>]
/var/ossec/bin/util.sh: addsite <domain>
/var/ossec/bin/util.sh: adddns <domain>

Example: /var/ossec/bin/util.sh adddns ossec.net
Example: /var/ossec/bin/util.sh addsite dcid.me

So, you can just run the command “util.sh adddns” and it will add the domain specified to be monitored:

# /var/ossec/bin/util.sh adddns ossec.net

In this case, we added the domain ossec.net. In the backend, it will add those new entries:

<ossec_config>
   <localfile>
     <log_format>full_command</log_format>
     <command>host -W 5 -t NS ossec.net; host -W 5 -t A ossec.net | sort</command>
   </localfile>
   </ossec_config>

   <group name="local,dnschanges,">
   <rule id="150013" level="10">
     <if_sid>530</if_sid>
     <check_diff />
     <match>^ossec: output: ’host -W 5 -t NS ossec.net</match>
     <description>DNS Changed for ossec.net</description>
   </rule>
   </group>

So you get a nice alert when your IP address changes.

Posted in ossec, v27 | Tagged , | Leave a comment

Detecting outdated (web) applications with OSSEC

For the last few days I started working (again) on the system auditing module for OSSEC and one thing that can make it more useful is to detect outdated applications (specially web apps).

Things like WordPress, Joomla, Wikis and others that can be easily used to compromise a server if not upgraded.

To get started, I added a few rules for WordPress, Joomla and osCommerce, so if you try the latest snapshot it will alert you if it finds any of them not updated:

* Alert 1316458742.1014: mail – ossec,rootcheck,
2011 Sep 19 15:59:02 testdev->rootcheck
Rule: 519 (level 7) -> ‘System Audit: Vulnerable web application found.’
System Audit: Web vulnerability – Outdated WordPress installation. File: /var/www/mysite.com/wp-includes/version.php.

But I really think we can expand it a lot more. What web applications and tools we should check? What other things we can look in the server that are important to be alerted on? I would love more ideas to expand it more.

Example of the system auditing rule:

[Web vulnerability - Outdated WordPress installation] [any] []
d:$web_dirs -> ^version.php$ -> r:^\.wp_version && >:$wp_version = ’3.2.1′;

[Web vulnerability - Outdated Joomla (v1.0) installation] [any] []
d:$web_dirs -> ^version.php$ -> r:var \.RELEASE && r:’1.0′;

I am thinking on things like PHPmyadmin, timthumb, uploadify and other tools that are easy to forget to update and had serious security vulnerabilities in the recent past.

Posted in log analysis, v27, webattacks | Tagged , | 8 Comments

OSSEC v2.6 is out!

OSSEC v2.6 was just released (finally :) ) and you can get more details here: http://www.ossec.net/main/ossec-v2-6-released

We are very happy to announce the availability of OSSEC version 2.6.

This has been a long release cycle, but it is here now with some good new features and very stable (thanks to our beta users). Our manual for the new version is also live at http://www.ossec.net/doc/.

..

Thanks!

Posted in ossec, v2.6 | Tagged , | 1 Comment

OSSEC 2.6 beta-1 available

This has been a long release cycle, but OSSEC 2.6 BETA1 is now available. Helping us out testing the beta version is a great way to contribute back to the project and the best way to get started on it.


How to test the BETA?

Download it from here:

And install on as many systems as you can. Make sure that the upgrade/install process is working without errors and that everything that was working before still it. If everything works (or you see any error), post in the comments section in here, send to the mailing list or privately to us (dcid@ossec.net).


Testing the new features

In addition to making sure everything still works, you can try some of the new features (full list here):

Plus a bunch of bug fixes… Let us know how it goes.

Posted in beta, ossec | 7 Comments

Improved reporting for file changes (OSSEC)

One that that always annoyed me on OSSEC was that ossec-reported didn’t list the file changes (from syscheck) and that I couldn’t use the filtering options in there for them. Well, that’s solved now :)

On the latest OSSEC snapshot you can use the “filename” option to filter and correlate values. For example, if I run the default reporting for the month of May I will see at the bottom a list of file changes:

# zcat /var/ossec/logs/alerts/2011/May/*.gz | /var/ossec/bin/ossec-reportd
..
Top entries for ‘Filenames’:
————————————————
/etc/ossec-init.conf |3 |
/var/www/x/index.php |1 |
/var/www/x/js.js |1 |

And you can also use the related options to see on which agents the files were changed. So for a basic integrity monitoring report, I would filter for the group syscheck and list where each file was changed:

# zcat /var/ossec/logs/alerts/2011/May/*.gz | /var/ossec/bin/ossec-reportd -f group syscheck -r location filename
..
Top entries for ‘Filenames’:
————————————————
/etc/ossec-init.conf |3 |
/var/www/x/index.php |1 |
/var/www/x/js.js |1 |

Related entries for ‘Location’:
————————————————
web1->syscheck |1 |
    filename: ‘/etc/ossec-init.conf’
    filename: ‘/var/www/x/js.js’
    filename: ‘/var/www/x/index.php’
db1->syscheck
    filename: ‘/etc/ossec-init.conf’
obsd-fw->syscheck
    filename: ‘/etc/ossec-init.conf’

So the report is simple. It shows which files were changed and how many times (for example, ossec-init changed 3 times, on 3 agents). I am even thinking on making these reports enabled by default and reducing the severity of the normal syscheck alerts so they don’t get sent by email. Comments?

Posted in ossec | 1 Comment

Running multiple OSSEC decoders on the same event

If you need to run multiple decoders on the same log to extract additional pieces of information (and at the same time do not affect the original decoder), we have a simple way to do so.

Just create multiple child decoders with the same name and no “prematch” and all of them will be evaluated. A good example is for the Microsoft event logs. This is our original decoder for Windows:

<decoder name=”windows-sub1″>
<type>windows</type>
<prematch>^WinEvtLog: </prematch>
<regex offset=”after_prematch”>^\.+: (\w+)\((\d+)\): (\.+): </regex>
<regex>(\.+): \.+: (\S+): </regex>
<order>status, id, extra_data, user, system_name</order>
<fts>name, location, user, system_name</fts>
</decoder>

You will see that we do not extract a soure IP address from there (only user, system name, location, etc). If we wanted to extract the source IP address whenever it is available, we would need to check all the variations (Source Network Address:, Source IP Address:, etc). By using sub-decoders we can check for them without affecting the original:

<decoder name=”windows”>
<type>windows</type>
<prematch>^WinEvtLog: </prematch>
</decoder>

<decoder name=”windows-sub1″>
<type>windows</type>
<parent>windows</parent>
<regex offset=”after_parent”>^\.+: (\w+)\((\d+)\): (\.+): </regex>
<regex>(\.+): \.+: (\S+): </regex>
<order>status, id, extra_data, user, system_name</order>
<fts>name, location, user, system_name</fts>
</decoder>

<decoder name=”windows-sub1″>
<type>windows</type>
<parent>windows</parent>
<regex offset=”after_regex”>Source Network Address: (\S+)</regex>
<order>srcip</order>
</decoder>

<decoder name=”windows-sub1″>
<type>windows</type>
<parent>windows</parent>
<regex offset=”after_regex”>Source IP Address: (\S+)</regex>
<order>srcip</order>
</decoder>

You see that all of them are named “windows-sub1″ and none of them have a prematch. Another option is to use the “after_regex” in the offset so OSSEC won’t check the whole string again…

Posted in ossec, v2.6 | 2 Comments

Blocking repeated offenders with OSSEC

By default OSSEC has a static timeout on our active response scripts. You specify the action and how long to block the IP Address:

<active-response>
<command>host-deny</command>
<location>local</location>
<level>6</level>
<timeout>600</timeout>
</active-response>

Which works well for most of the time. However, if you need to increase the timeout for repeated offenders (say the same IP trying to brute force your server all the time), you would have to do this manually.

To solve this problem, we added a new option to the active response config (repeated_offenders):

<active-response>
<repeated_offenders>30,60,120</repeated_offenders>
</active-response>

It allows you to specify a comma separated list of timeouts per re-incidence (in minutes). So the first time an IP is blocked it would use the default timeframe (600 seconds). If it gets blocked again, it would use the first entry in the <repeated_offenders> list (30 minutes = 1800 seconds), then 60 minutes and then 120 minutes… Anything above that would use the latest entry.

To use this option, you have to download the latest snapshot from: http://bitbucket.org/dcid/ossec-hids (just click on get source).

Posted in ossec, v2.6 | 2 Comments

Automatically creating and setting up the agent keys

The complain I hear more often about OSSEC is related to how hard it is to setup the authentication keys between the agents and the manager. Each agent share a key-pair with the manager, so if you have a thousand agents, you need a thousand keys.

To make life easier, we added a new daemon on the manager, called ossec-authd. To get that working, you need the latest snapshot (just get from here:https://bitbucket.org/dcid/ossec-hids (click on get source)).

Once you have the new version running, you need to create the certificate / private key for SSL (note that OSSEC will look at /var/ossec/etc/sslmanager.cert and /var/ossec/etc/sslmanager.key for them).

# openssl genrsa -out /var/ossec/etc/sslmanager.key 2048
# openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out /var/ossec/etc/sslmanager.cert -days 365

*note that you only need to run this command on the manager (not on the agents)

Once the keys are created, you can start the ossec-authd:

# /var/ossec/bin/ossec-authd -p 1515 >/dev/null 2>&1 &

Setting up the agents

On the agents, the work is minimal. All you have to do is to run the following command:

# /var/ossec/bin/agent-auth -m 192.168.1.1 -p 1515

INFO: Connected to 192.168.1.1:1515
INFO: Using agent name as: melancia
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.

Where 192.168.1.1 is your manager IP address. Inside the manager, you will also see the logs:

2011/01/19 15:04:40 ossec-authd: INFO: New connection from 192.168.10.5
2011/01/19 15:04:41 ossec-authd: INFO: Received request for a new agent (melancia) from: 192.168.10.5
2011/01/19 15:04:41 ossec-authd: INFO: Agent key generated for melancia (requested by 192.168.10.5)
2011/01/19 15:04:41 ossec-authd: INFO: Agent key created for melancia (requested by 192.168.10.5)

That’s it. The keys are now exchanged and you can start your agent. Note that I don’t recommend to keep the ossec-authd running during “normal” operations, only when you are setting up your agents.

The code is still in alpha/beta mode, so let us know if you find any issues (I have been using for a little while, so should be stable).

Posted in ossec | 10 Comments

OSSEC Award daemon

I just got that via the mail today:

ossec-awardd

If you can’t see well from the image, it is a beautiful plaque from the OSSEC community (Michael Starks, I know it was your idea :) ) and it says (in the OSSEC alert format):

OSSEC HIDS Notification
2010 Oct 20 15:10:04
Received from: ossec-community->/var/log/community.log
Rule: 1000000 (Level: 15) -> “A sincere thanks”
Portion of the log(s):

Oct 20 15:10:04 allhosts ossec-awardd[423]: To: Daniel Cid. From: OSSEC Community. Thank you for your tireless devotion to making our digital world a safer place.

END OF NOTIFICATION

It was the last think I was expecting and It meant a lot to me, thanks! This week of OSSEC is getting better each day :)

Posted in ossec | Leave a comment

2WoO: Day 3: Contributing to OSSEC

There are many types of open source projects out there. Many have the code base open (GPL, BSD, etc), but not all of them have an open culture.

On OSSEC, we try to be fully open. Not only the source code, but open to contributions, open to new developers, open to new ideas and open (friendly) to new users. So if you want to become involved and participating in this project, we have a few recommendations.

These recommendations will probably be valid for most open source projects, not only OSSEC.

How to get started:

1-The first thing you have to do is to become an active OSSEC user. I mean, install it on as many machines as you can, try different setups, see things you don’t like and start from there. Become passionate about it if you want to make a difference.

2-Start small. As any project, it takes some time to get used to how it works and how the code is organized. So start from simple things. Even if you detect a typo, try to fix that first and send us the patch.

3-Consider contributing your customizations. If you had to add a simple local rule to ignore a noisy event, send that to us! Get the log that was causing the false alert and the rule you created and send to our development mailing list or to our IRC channel (details after).

4-Get involved on our mailing lists and on IRC to see the needs and issues most users have.

5-You don’t need to be a developer or code in C. You can contribute with documentation, with the rules/decoders or even testing it. We also have our web interface (PHP), active responses/install scripts (in shell) that you can help out. So no excuses :)

Getting involved:

1-Our code base is available on bit bucket: http://bitbucket.org/dcid/ossec-hids/

2-Our documentation is also on bit bucket: http://bitbucket.org/jrossi/ossec-rules

3-We are always on IRC (#ossec on irc.freenode.org). That’s the best way to get quickly feedback from us and get to know everyone actively involved.

4-We also have a development mailing list, but via IRC is recommended.

If you don’t know how to access our repository on bit bucket, this link should help you: http://hginit.com

Any questions, let us know.

Posted in ossec | 1 Comment