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”
If you visit ossec.net 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 (firstname.lastname@example.org) 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 under-linux.org) 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:
*Modifications: 4c4 < ossec.net has address 220.127.116.11 — > ossec.net has address 18.104.22.168
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"> <if_sid>31100</if_sid> <url>?-d|?-s|?-a|?-b|?-w</url> <description>PHP CGI-bin vulnerability attempt.</description> <group>attack,</group> </rule>
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: 22.214.171.124 126.96.36.199 - - [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.
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.
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.
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.
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?
“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:
ossec: output: ‘/etc/init.d/httpd status’:
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)
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.
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/ossec-tweeter.sh 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.
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: http://www.ossec.net/files/snapshots/ossec-hids-080725.tar.gz
After that you can configure OSSEC with the syslog servers of your choice. In my example here, I am sending everything to server 192.168.4.1 and only the alerts above level 10 to 10.1.1.1:
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.)…
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: ’192.168.4.1:514′.
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ’10.1.1.1:514′.
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) 192.168.2.0->/var/log/messages; srcip: 192.168.2.190; user: root; Jul 25 13:26:24 slacker sshd: Accepted password for root from 192.168.2.190 port 49737 ssh2
As always, suggestions and comments are more than welcome. Thanks!