• Subscribe to the low volume list for updates.

Enable OSSEC Active Response

OSSEC LogoMany OSSEC users start off running with Active response disabled to ensure that the OSSEC agent does not affect the server especially when running in a live production environment. Once you have an understanding of the number of alerts and types of alerts you are seeing, it is a good idea to enable Active response.

Blocking is the next step in defence

The advantages of running OSSEC on your servers are pretty obvious, especially when you start to get a few alerts, even if they are false positives. It is a quick and easy way to ensure that any "interesting" changes or security events are noticed by sending an email to the configured email address. Blocking is the next step in defence. If services are being brute forced, then you can block an IP address that is performing the brute force.

An important part of any monitoring system is to minimise the noise that an admin or analyst is subjected too. Reducing the noise ensures that legitimate alerts are noticed and followed up for analysis.

Setting up Active response

After configuring OSSEC in a default configuration with Active response disabled you will need to enable it by modifying two sets of configuration parameters in the /var/ossec/etc/ossec.conf file.

Add command block

Add a command block to /var/ossec/etc/ossec.conf, this gives a name to the executable that you are going to run (typically located in /var/osssec/active-response/).


Rules and alert levels

Enable Active response on specific rules or all rules above a certain alert level.


Rather than have a specific rule in the Active response block, omit the rules_id and all rules that are triggered above level 8 with source IP will be blocked by the firewall drop script using iptables for a period of 600 seconds (10 minutes). Note that the command block needs to be higher in the ossec.conf file than the active response block.


To see how effective your Active response is take a look at /var/ossec/logs/active-responses.log. Here is a snippet of one of my logs. All the noisy bots are being blocked. Alerts for this noise no longer appear in my inbox as they are simply quietly blocked.

Sun Aug 14 11:55:04 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 192.1xx.250.89 1471175704.407764 31510 Sun Aug 14 12:05:34 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 192.1xx.250.89 1471175704.407764 31510 Sun Aug 14 14:34:25 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 103.255.xx.69 1471185265.450999 31153 Sun Aug 14 14:44:55 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 103.2xx.15.69 1471185265.450999 31153 Mon Aug 15 23:16:49 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 82.166.1xx.x4 1471303009.783488 31510 Mon Aug 15 23:27:19 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 82.1xx.1x9.94 1471303009.783488 31510 Tue Aug 16 11:43:14 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 91.200.1x.x47 1471347794.946259 31510 Tue Aug 16 11:53:45 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh delete - 91.20x.xx2.47 1471347794.946259 31510 Tue Aug 16 11:53:47 UTC 2016 /var/ossec/active-response/bin/firewall-drop.sh add - 91.20x.xx.47 1471348427.992693 31510

Custom Active Response Rules

Over on the SANS ISC Blog there is an excellent example of using Active Response to launch tcpdump upon the triggering of a rule.

In the example used you are specifying that if an alert condition is met then launch tcpdump and capture packets from the host that triggered the alert for 10 minutes. One use of this would be if you wish to capture web attack payloads from bots / random hosts, but do not wish to capture all your web traffic. As the web attacks are detected tcpdump automatically starts collecting packets. Of course you will miss the initial attacks that triggered the alert but any subsequent traffic would be collected.

It is possible to use the same methodology to launch any command or script on your host. The possibilities are wide ranging and only limited by your imagination.

That's it folks, I have written about OSSEC before and still find it to be very useful and an important part of any server build.

Do more with OSSEC

Detect WordPress attacks and monitor the application and web server logs.

Next level testing with advanced Security Vulnerability Scanners.

Trusted tools. Hosted for easy access.