ossec.conf: Active Response Options

Overview

Supported types

Active-reponse options are available in the the following installation types:

  • server
  • local

Configuration pieces

There are two pieces to an active-response configuration. The first is the <command> section. This details the command to be run, and the options it will use. There can be any number of command options.

The second is the <active-response> section. This section defines when the command will be run.

Location

All active-response options must be configured in the /var/ossec/etc/ossec.conf and used within the <ossec_config> tag.

XML excerpt to show location:

<ossec_config>
    <command>
        <!--
        Command options here
        -->
    </command>
    <active-response>
        <!--
        active-response options here
        -->
    </active-response>
</ossec_config>

Command Options

command

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. command is required.

name

Used to link the command to the response. name is required.

executable

It must be a file (with exec permissions) inside /var/ossec/active-response/bin. executable is required.

You don’t need to provide the whole path.

expect

The arguments this command is expecting (options are srcip and username). If a field is not within the expect option it will be passed as a dash (-) instead of the actual value. For instance, if srcip is required for an active-response script to work it must be inside of an expect option. expect is required.

Note

expect is required, but it is not reqiured to populate it. <expect></expect> is valid if no options need to be passed to the active-response script.

timeout_allowed

Specifies if this command supports a timeout. This is optional, and defaults to yes.

Active-response Options

active-response

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.

disabled

Disables active response if set to yes. If this is not defined active response is enabled.

command

Used to link the response to the command

location

Where the command should be executed. You have four options:

Allowed:

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

rules_group

The response will be executed on any event in the defined group. Multiple groups can be defined if separated by a comma.

rules_id

The response will be executes on any event with the defined ID. Multiple IDs can be specified if separated by a comma.

timeout

How long in seconds until the reverse command is executed (IP unblocked, for example).

repeated_offenders

A comma separated list of increasing timeouts in minutes for repeat offenders. There can be a maximum of 5 entries. This should be set in the ossec.conf of an agent in an agent/server setup.

Example:

<active-response>
  <command>firewall-block</command>
  <location>defined-agent</location>
  <agent_id>001</agent_id>
  <rules_group>authentication_failed,authentication_failures</rules_group>
  <timeout>600</timeout>
  <repeated_offenders>30,60,120</repeated_offenders>
</active-response>
<active-response>
  <repeated_offenders>30,60,120</repeated_offenders>
</active-response>

Example active response configurations:

Command: Restart OSSEC on *nix systems:

This command can be used to restart the OSSEC processes. It’s commonly used to automatically restart agent processes when an agent.conf is modified. Since no parameters are necessary the <expect> is empty.

<command>
  <name>restart-ossec</name>
  <executable>restart-ossec.sh</executable>
  <expect></expect>
</command>

Active-Response: Restart the OSSEC processes:

This active response will restart the OSSEC processes using the restart-ossec command above. It is runs when rule 510010 is triggered, and it runs on the system where the rule was triggered.

<active-response>
  <command>restart-ossec</command>
  <location>local</location>
  <rules_id>510010</rules_id>
</active-response>

Here is an example rule checking for changes to the agent.conf.

<rule id="510011" level="10">
  <if_sid>550</if_sid>
  <match>/var/ossec/etc/shared/agent.conf</match>
  <description>agent.conf has been modified</description>
</rule>

Command: Block an IP with pf.sh:

pf.sh adds an ip (srcip) to an ossec_fwtable packet filter table. Information on pf tables can be found here.

<command>
  <name>pf-block</name>
  <executable>pf.sh</executable>
  <expect>srcip</expect>
</command>

This is the minimum configuration necessary to utilize pf.sh:

table <ossec_fwtable> persist #ossec_fwtable
block in log quick from <ossec_fwtable>

Active-Response: Block an IP with pf:

This active-response blocks an IP triggering an authentication_failed or authentication_failures alert. This active-response will run on agent 001 only.

<active-response>
  <command>pf-block</command>
  <location>defined-agent</location>
  <agent_id>001</agent_id>
  <rules_group>authentication_failed,authentication_failures</rules_group>
</active-response>

Command: Run the makelists.sh script:

The makelists.sh script runs /var/ossec/bin/ossec-makelists to update cdb lists. This command can be triggered by changes in configured cdb lists.

<command>
  <name>makelists</name>
  <executable>makelists.sh</executable>
  <expect>hostname</expect>
</command>

Active-Response: Update cdb lists:

This active-response will run the makelists command to update the cdb lists. This active-response should run only on the OSSEC server since agents do not have cdb lists.

<active-response>
  <command>makelists</command>
  <location>server</location>
  <rules_id>510011</rules_id>
</active-response>

Rule 510011: This example rule looks for changes to /var/ossec/lists/blocked.txt based on syscheck alerts.

<rule id="510011" level="10">
  <if_sid>550</if_sid>
  <match>/var/ossec/lists/blocked.txt</match>
  <description>blocked.txt has been modified</description>
</rule>

Command: firewall-drop:

This is a command to run the firewall-drop.sh script to block the srcip.

<command>
  <name>firewall-drop</command>
  <executable>firewall-drop.sh</executable>
  <expect>srcip</expect>
</command>

Active-Response: Block a srcip:

This active-response will use the firewall-drop command to block an IP address that has triggered an authentication_failed or authentication_failures alert. It will run on all agents, and has a timeout of 600 seconds. It also uses the repeated_offenders option blocking an IP for 30 minutes on the second infraction, 60 minutes on the third, etc.

<active-response>
  <command>firewall-block</command>
  <location>all</location>
  <rules_group>authentication_failed,authentication_failures</rules_group>
  <timeout>600</timeout>
  <repeated_offenders>30,60,120</repeated_offenders>
</active-response>