bookmark_borderGood passwords: It is not about their size or complexity

Every time I read a password recommendation or policy, I get frustrated. It is always about their length and complexity, and they miss the real issue with passwords and how they get compromised.

So I wrote this small (non technical) paper on my thoughts on passwords and how I define a good password: http://dcid.me/texts/good-passwords.

bookmark_border3WoO: 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.

bookmark_borderDetecting 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.

bookmark_borderOSSEC v2.6 is out!

SSEC 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/.

-OSSEC Team

bookmark_borderOSSEC 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.

bookmark_borderImproved 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?

bookmark_borderRunning 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…

bookmark_borderBlocking 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).

bookmark_borderAutomatically 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).

bookmark_borderOSSEC v2.3 BETA1 available

OSSEC v2.3 BETA1 is now available and we need testers. You can find information on how to help us at http://www.ossec.net/wiki/Dev:BetaTesting

If you ever wanted to contribute to OSSEC (or to any open source project) that’s the easiest way to get involved. Just download the BETA, check if everything still works, if you have time try out some of the new features and let us know how it goes. You can submit your feedback in here, via the wiki, to the mailing list or personally to me via email.

http://www.ossec.net/wiki/Dev:BetaTesting

We appreciate any feedback.