Many 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
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
<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 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
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.
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.