Wazuh Blocking attacks with Active Response

Active response allows Wazuh to run commands on an agent in response to certain triggers. In this use case, we simulate an SSH Brute Force attack and configure an active response to block the IP of the attacker. So, in this post you will learn how blocking attacks with active response.

Detecting the attack

First of all, we need to know when to execute the response. We can use one of the following options:

• Rule ID: The response will be executed on any event with the defined ID.
• Rule group: The response will be executed on any event in the defined group.
• Level: The response will be executed on any event with this level or higher.

In this use case, we want to prevent SSH brute force attacks so when the rule 5712 - SSHD brute force trying to get access to the system is triggered, it will execute the proper active response to block the IP of the attacker.

Defining the command

We know when the active response will be executed, now we have to define what it will do. You can create your own script to block an IP, or any other action, but Wazuh comes with a set of common scripts used in active response. These scripts are in /var/ossec/active-response/bin/. We are going to use the firewall-drop script that works with common Linux/Unix operating systems and it allows blocking of a malicious IP using the local firewall.

Define the command in the ossec.conf of your Wazuh manager:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

Defining the active response for blocking attacks

Define the active response in the ossec.conf of your Wazuh manager:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>1800</timeout>
</active-response>

Restart the Wazuh manager to apply changes.

Proof of concept

We are going to simulate an SSH attack, the attack will be executed from 10.0.0.6 to our agent running on 10.0.0.5. First, we check if there is connectivity between the attacker and the agent:

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=0.602 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=0.774 ms

Now, we attempt to connect to the agent by SSH several times using an invalid user:

$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).

After 8 attempts, we can see in the manager how the rule is fired:

If we try to ping the agent from the attacker, we see that it’s not possible:

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
^C
--- 10.0.0.5 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11000ms

Generating an alert when an active response is fired

Every agent has a log file at /var/ossec/logs/active-responses.log where the active response activities are registered. By default, this file is being monitored.

<ossec_config>
  <localfile>
      <log_format>syslog</log_format>
      <location>/var/ossec/logs/active-responses.log</location>
  </localfile>
</ossec_config>

When the active response is triggered we can see the corresponding alert:

This is possible because rule 651 is defined in ossec_rules.xml. If you create your own script, you must add the proper rule.

White list

We can also set a list of IP addresses that should never be blocked by the active response. In global section of ossec.conf in the Manager, use the field white_list. It allows IP address or netblock

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <email_notification>no</email_notification>
    <logall>yes</logall>
    <white_list>10.0.0.6</white_list>
  </global>

Increasing blocking time for repeated offenders

We set up a blocking time of 30 minutes for our active response, but in case you need to increase this blocking time for repeated offenders you can add the following configuration in the ossec.conf of each agent:

<active-response>
  <repeated_offenders>60,120,180</repeated_offenders>
</active-response>

The first time that the active response is triggered, it will block the IP for 30 minutes, the second time for 60 minutes, the third time for 120 minutes, and finally the fourth time for 180 minutes.

Thanks to active response you can perform actions responding to several scenarios and restricting malicious activities and blocking attacks. Be aware any automated response has an implicit risk, so define your responses carefully.