Most active-reponse options are available in the the following installation types:
The disabled
option is available on all installation types.
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.
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
¶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
¶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 on unix systems, and disabled on Windows systems.
This option is available on server, local, and agent installations.
Setting it to yes
on an agent will disable active-response for that agent only,
while setting it on the server will disable all active-response.
command
¶Used to link the response to the command
location
¶Where the command should be executed. You have four options:
Allowed:
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 pipe (|).
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.
Note
This must be set in the
ossec.conf
of the agent in an agent/server setup.
Example of a local/standalone:
<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>
Example of an agent:
<active-response>
<repeated_offenders>30,60,120</repeated_offenders>
</active-response>
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>
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>
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>
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.
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>
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>
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>
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.