ossec.conf: Active Response Options

Overview

Supported types

Most active-response options are available in the the following installation types:

• server
• local

The disabled option is available on all installation types.

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

Active-response Options

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>

Warning

This may trigger on a single authentication failure.

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>

Warning

This may trigger on a single authentication failure.