A standout feature of OSSEC is its active response module. Active response allows commands to be executed based on the triggering of a rule. It provides these commands with network, user, and file information from the rules that tripped the active response. With the active response system, you can provide targeted protection to your network. Using this mechanism, it is possible to implement the functionality of the popular Fail2Ban SSH brute-force protection using OSSEC.
In order to implement active response, you will need to know how active response commands are called. The firewall-drop.sh script ships with OSSEC implementing the locking and logging feature, and also works on most Linux/BSD systems. We'll take a look at an incredibly distilled version of the script to understand how active response works:
#!/bin/sh # ACTION=$1 SRCIP=$3 if [ "$ACTION" == "add"]; then /usr/sbin/iptables -I FORWARD -s $SRCIP -j DROP /usr/sbin/iptables -I INPUT -s $SRCIP -j DROP elif [ "$ACTION" == "delete"]; then /usr/sbin/iptables -D FORWARD -s $SRCIP -j DROP /usr/sbin/iptables -D INPUT -s $SRCIP -j DROP else echo "invalid action, specific add or delete"; exit 1; fi;
Our distilled firewall-drop.sh script is a simple shell script that receives the arguments starting with $1 from the command-line call. It doesn't implement any error-checking mechanism and assumes the host system is a Linux-based distribution with the iptables binary in /usr/sbin/iptables. It checks the $1 parameter for the action, which will be either add or delete, and executes the iptables commands to add or remove the IP for the appropriate tables.
The trickiest part of the script is knowing what each positional parameter represents. Here's a simple breakdown for Linux/BSD shell scripting:
|
Position |
Shell variable |
Description |
|---|---|---|
|
1 |
|
Action: add or delete |
|
2 |
|
Event: User or hyphen (-) if empty |
|
3 |
|
Event: Source IP or hyphen (-) if empty |
|
4 |
|
Event ID (unique per event) |
|
5 |
|
Event rule ID or source ID |
|
6 |
|
Event information: This may contain the agent name, host, or filename based on the context |
Using these variables, you could create your own active responses to integrate with your existing network and host security infrastructures.
Perform the following steps to introduce the active response module:
OSSEC ships with a few active response commands included. Configure OSSEC with active response and enable the
firewall-dropcommand; you should now have acommandattribute set up in theossec.conffile already, as follows:<command> <name>firewall-drop</name> <executable>firewall-drop.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command>
To implement the Fail2Ban functionality, configure the active response a bit more than the stock
ossec.conffile:<active-response> <command>firewall-drop</command> <location>local</location> <rules_id>5551,5712,5720,31151</rules_id> <timeout>600</timeout> <repeated_offenders>600,3600,86400</repeated_offenders> </active-response>
When setting up commands, OSSEC is configured to look for the firewall-drop.sh script in the /var/ossec/active-response/bin directory. We declared the command to expect a source IP, so events dispatching this command without a valid source IP will be ignored. A timeout is allowed for active responses that call this command, allowing the pruning of unnecessary firewall rules by setting timeout_allowed to yes.
We add an active-response element to run the firewall-drop command. The location in this case is the local agent generating the alarm, but we could simply say "all" or specify a specific agent ID where the command needs to be run.
Adding and deleting firewall rules from production systems should be something that's very deliberate and specific. We configure the response to be fired on the following rules: 5551, 5712, 5720, and 31151. This is a selection of rules that indicates SSH brute-force probes/attacks. This is much more predictable than using groups or levels as sources of events.
A timeout value of 600 seconds is set for this active response. When this active response fires the first time, the script will be called with the action parameter set to add. Ten minutes later, OSSEC will re-run the script with the same parameters, only this time modifying the action parameter to delete.
Using the repeat_offenders parameter, we can adjust this timeout based on how frequently a particular source IP trips this active response. The first two timeouts are 10 minutes, the third time that the same IP trips the alert it moves into blocking mode for an hour, and for the fourth and for all subsequent times, the IP is blocked for 24 hours.
Active response can be configured to run anywhere on the network, so there's really no limit to how interesting your responses can be. There's also nothing preventing you from leveraging the active response system to assist you in tracking events. You could easily create a simple shell script to integrate OSSEC alerting directly into a ticketing system, such as JIRA, RTIR, or Remedy.