Many OSSEC users start of 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.
The advantages of running OSSEC on your servers are pretty obvious, especially when you start to get 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 simply sending an email to the configured email address. Blocking is simply the next step in defence. If services are being brute forced, then you can simply block an IP address that is performing the brute force.
After configuring OSSEC in a default configuration with active response disabled you will need to enable by modifying two sets of configuration parameters in the
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
<command> <name>firewall-drop</name> <executable>firewall-drop.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command>
Now 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 the
rules_id can be omitted 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 snip it 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
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.