bookmark_borderImport WordPress Events to OSSEC

WordPress is a very popular in the enterprise world, but a common issue that security administrators have is with visibility into platform events. System administrators want to know what is happening inside WordPress and how those events can be  incorporated into their log management and log-based intrusion detection plan.

Continue reading “Import WordPress Events to OSSEC” DNS and Content modified

If you visit you will notice a pretty new design and a new home for it. The server was officially moved to a Trend server and is now being managed by Vic Hargrave ( and the Trend team. If you notice anything wrong there (or broken links), please let Vic know and he will get it sorted out.

I also want to thank Marcus Maciel (from for hosting the server/site during all this time (almost 8 years).

Changing topics, this is the notification I got from sucuri a few minutes after the DNS was changed to point to the new location:

< has address
> has address


bookmark_borderOSSEC rule for the PHP-CGI vulnerability

I am seeing many scans for the PHP-CGI vulnerability in the wild and put up a quick OSSEC rule to detect/block those:

<rule id="31110" level="6">
<description>PHP CGI-bin vulnerability attempt.</description>

It looks for the possibly dangerous options (-d,-s,-a,-b and -w) and alerts if it sees those. This is the alert it generates when detected:

** Alert 1336547515.182029: - web,accesslog,attack,
2012 May 09 03:11:55 (honeypot3) any->/var/log/httpd/access.log
Rule: 31110 (level 6) -> 'PHP CGI-bin vulnerability attempt.'
Src IP: - - [09/May/2012:07:11:55 +0000] "GET /index.php?-s HTTP/1.1" 200 39479 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0"

This rule is also in my repository and you can download the latest from here.

bookmark_borderDatabase Logging (PostgreSQL and MySQL)

Nobody cares about database logging, but I really recommend enabling them to see what is happening behind the scenes (specially for web applications).

To enable on PostgreSQL (and be compatible with OSSEC):

# Adding the timestamp, hostname and database.
log_line_prefix = '[%m] %h:%d '

# Recommended settings:
log_connections = on
log_disconnections = on
log_duration = on

# Maybe a good idea to reduce the default log level to info:
client_min_messages = info
log_min_messages = info

# To enable query logging (all for everything or mod for inserts, updates, etc)
log_statement = 'all'


To enable the generic Query log on MySQL (the error log in on by default), you need to start MySQL with –log:

/bin/sh /usr/bin/mysqld_safe --log

The best option is to modify /etc/init.d/mysqld (if using Centos) and inside the –log in there.

Nothing new, but I was searching for this information online and couldn’t find much info.

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/
/var/ossec/bin/ addfile <filename> [<format>]
/var/ossec/bin/ addsite <domain>
/var/ossec/bin/ adddns <domain>

Example: /var/ossec/bin/ adddns
Example: /var/ossec/bin/ addsite

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

# /var/ossec/bin/ adddns

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

     <command>host -W 5 -t NS; host -W 5 -t A | sort</command>

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

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/

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_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’
    filename: ‘/etc/ossec-init.conf’
    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_borderProcess monitoring with OSSEC

OSSEC v2.3 was just released and one feature that really interested me was the Process monitoring. That’s what the OSSEC team says about it:

“We love logs. Inside OSSEC we treat everything as if it was a log and parse it appropriately with our rules. However, some information is not available in log files but we still want to monitor them. To solve that gap, we added the ability to monitor the output of commands via OSSEC and treat those just like they were log files.”

Basically, it allows you to monitor the output of any command and generate alerts/active responses from them.

Cool, let’s try it out. First, let’s monitor the output of “httpd status” to receive alerts if Apache ever goes down. I added the following command to my ossec.conf and the following rule to my local_rules:

/etc/init.d/httpd status

ossec: output: ‘/etc/init.d/httpd status’:
is stopped

Now, if I manually stop Apache to try it out, I get in a few seconds via email:

2009 Dec 08 10:45:04 (sucuri) xx->/etc/init.d/httpd status
Rule: 100200 (level 10) -> ‘Apache STOPPED.’
Src IP: (none)
User: (none)
ossec: output: ‘/etc/init.d/httpd status’: httpd is stopped

Perfect! Now I can have all my monitoring in just one tool… Next step is to create an active response to restart the service on failure.

bookmark_borderOSSEC to Twitter

Want to see your OSSEC alerts on twitter? We just added support for that on the latest snapshot.

To make it work, first update to the latest snapshot and add the following to your ossec.conf:



Where the first entry “command” is defining the active response script and the second one “active-response” is configuring when to execute it. In my example above, I chose to execute it for every alert >= level 6. Note, that you can’t run it on the individual agents, just on the management server.

After that, you need to configure the twitter script with the appropriate credentials. So, open the file /var/ossec/active-response/bin/ and modify the first 2 entries:


If you want to send direct messages to yourself (or any other account), also set the direct msg user variable:


After that, just restart OSSEC and wait for the updates. If you want some examples, check the ossec twitter page.

bookmark_borderSending OSSEC alerts via syslog

This is a feature that was constantly asked and just now I was able to include it. Basically, it allows you to send the OSSEC alerts to one or more syslog servers (granularly).

First, make sure to get the latest snapshot and install it:

After that you can configure OSSEC with the syslog servers of your choice. In my example here, I am sending everything to server and only the alerts above level 10 to



After that, run the following command and restart OSSEC:

# /var/ossec/bin/ossec-control enable client-syslog
# /var/ossec/bin/ossec-control start

You should see now ossec-csyslog starting:

OSSEC HIDS v1.5.1 Stopped
Starting OSSEC HIDS v1.5.1 (by Third Brigade, Inc.)…
Started ossec-csyslogd…

and on the logs:

# tail -n 1000 /var/ossec/logs/ossec.log |grep csyslog
2008/07/25 12:55:16 ossec-csyslogd: INFO: Started (pid: 19412).
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ’′.
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ’′.

On the syslog server, this is what you should get (every log separated by level, rule, location and the actual event that generated it):

Jul 25 12:17:41 enigma ossec: Alert Level: 3; Rule: 5715 – SSHD authentication success.; Location: (jul)>/var/log/messages; srcip:; user: root; Jul 25 13:26:24 slacker sshd[20440]: Accepted password for root from port 49737 ssh2

As always, suggestions and comments are more than welcome. Thanks!