Many OSSEC users start with Active response disabled to ensure the OSSEC agent does not affect the server, especially when running in a live production environment. However, 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 defense
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. OSSEC is a quick and easy way to ensure any "interesting" changes or security events are noticed by sending an email to the configured email address. Blocking is the next step in defense. If services are being brute-forced, then you can block an IP address that is performing the brute force.
Setting up Active response
After configuring OSSEC in a default configuration with Active response disabled, you 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/).
<command>
<name>firewall-drop</name>
<executable>firewall-drop.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
Rules and alert levels
Enable Active response on specific rules or all rules above a certain alert level.
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<agent_id>001</agent_id>
<location>local</location>
<rules_id>31510</rules_id>
<level>8</level>
<timeout>600</timeout>
</active-response>
Rather than have a specific rule in the Active response block, omit the rules_id and all rules triggered above level 8 with source IP will be blocked by the firewall drop script using iptables for 600 seconds (10 minutes). Note the command block needs to be higher in the ossec.conf file than the active response block.
Verify
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 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, it specifies 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 is to capture web attack payloads from bots / random hosts, but do not wish to capture all the 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 apply the same methodology to launch any command or script on your host. The possibilities are wide-ranging and only limited by your imagination.
Conclusion
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.