Manual: Active Responses

Manual -> Active responses

Active response allows you to automatically execute “commands” or responses when a specific event or a set of events are triggered. On the OSSEC HIDS, active response is very scalable, allowing you to execute commands on the agent or on the server side.

The benefits of active response are enormous, but there are also risks when using this technology. By default, the OSSEC HIDS tries to minimize some of these risks, but some problems may still arise. Read bellow for an explanation about the risks/advantages of using the active response and also the risk mitigation techniques.

Benefits:

  • - Fast (time-based) response on attacks. If an attack is detected,
    an action can be taken immediately.

  • - Extremely good deterrent against port scans, brute forces and some
    other types of “information gathering” attacks.

Risks:

  • - A false positive may block a legitimate user/host.
  • - An “attacker” may find out that you are using active response
    and try to cause some form of denial of service attack.

Risk mitigation techniques used by the OSSEC HIDS:

  • - Allows you to specify a white list of hosts that should never be blocked.
  • - Comes with granular options, allowing you to only block on rules with low
    false-positive rate.
  • - Allows the specification of timeouts. Even if someone is blocked by mistake,
    after a few minutes he or she will be able to access again.


2 – Active Response Configuration

The Active response configuration is divided by two parts. In the first one you configure the commands you want to execute. In the second one, you bind the commands to rules or events.

2.1 Commands Configuration

In the commands configuration you create new “commands” to be used as responses. You can have as many commands as you want. Each one should be inside their own “command” element. You can see an example here (for the host-deny.sh) and one here (for disable-account.sh). 

<command>
	<name>The name (A-Za-Z0-9)</name>
    	<executable>The command to execute (A-Za-z0-9.-)</executable>
      	<expect>Comma separated list of arguments (A-Za-z0-9)</expect>

        <timeout_allowed>yes/no</timeout_allowed>
</command>

 

  • - name: Used to link the command to the response.
  • - executable: It must be a file (with exec permissions) inside “/var/ossec/active-response/bin”.
    You don’t need to provide the whole path.
  • - expect: The arguments this command is expecting (options are srcip and username).
  • - timeout_allowed: Specifies if this command supports timeout.

2.2 – Responses Configuration

In the active-response configuration, you bind the commands (created) to events. You can have as many responses as you want. Each one should be inside their own “active-response” element. Examples are here (for blocking based on the severity) and here (for blocking on specific rules). 

<active-response>
    <disabled>Completely disables active response if "yes"</disabled>
    <command>The name of any command already created</command>
    <location>Location to execute the command</location>

    <agent_id>ID of an agent (when using a defined agent) </agent_id>
    <level>The lower level to execute it (0-9)</level>
    <rules_id>Comma separated list of rules id (0-9)</rules_id>
    <rules_group>Comma separated list of groups (A-Za-z0-9)</rules_group>

    <timeout>Time to block</timeout>
</active-response>

 

  • - disabled: Disables active response if set to yes.
  • - command: Used to link the response to the command
  • - location: Where the command should be executed. You have four options:
    • local: on the agent that generated the event,
    • server: on the OSSEC server,
    • defined-agent: on a specific agent (when using this option, you need to set the agent_id to use),
    • all: or everywhere.

  • - agent_id: The ID of the agent to execute the response (when defined-agent is set).

  • - level: The response will be executed on any event with this level or higher.
  • - timeout: How long until the reverse command is executed (IP unblocked, for example).


3- Active Response Tools


By default, the ossec hids comes with the following pre-configured
active-response tools:

  • host-deny.sh – Adds an IP to the /etc/hosts.deny file (most Unix systems).
  • firewall-drop.sh (iptables) – Adds an IP to the iptables deny list (Linux 2.4 and 2.6).
  • firewall-drop.sh (ipfilter) – Adds an IP to the ipfilter deny list (FreeBSD, NetBSD and Solaris).
  • firewall-drop.sh (ipfw) – Adds an IP to the ipfw deny table (FreeBSD).
      • *On IPFW we use the table 1 to add the IPs to be blocked. We also
      set this table as deny in the beginning of the firewall list. If you use the
      table 1 for anything else, please change the script to use a different
      table id.
  • firewall-drop.sh (ipsec) – Adds an IP to the ipsec drop table (AIX).
  • firewall-drop.sh (pf) – Adds an IP to a pre-configured pf deny table (OpenBSD and FreeBSD).

      • *On PF, you need to create a table in your config and deny all the
      traffic to it. Add the following lines at the beginning of your
      rules and reload pf (pfctl -F all && pfctl -f /etc/pf.conf):

      table <ossec_fwtable> persist #ossec_fwtable

      block in quick from <ossec_fwtable> to any
      block out quick from any to <ossec_fwtable>