Incident response plays a pivotal role in the cybersecurity landscape. First, automated, and efficient incident handling is critical to mitigating the impact of potential breaches, safeguarding organizations from escalating threats. In this blog post, I’ll demonstrate how to leverage Wazuh’s Active Response capabilities to fortify your security posture. The lab environment for this blog is configured according to the following diagram:
Lab Environment:
For this blog post, my lab environment is set up with the following servers and applications.
Web App Server: OS: Ubuntu 22.04, IP: 192.168.23.3, Package: Apache2, MariaDB, PHP, Wazuh Agent.
On this server, I’m hosting a lightweight PHP application featuring a single login screen. The backend consists of a simple database named my_db, containing one table called users, which stores usernames and credentials. This setup serves as the target for my simulated attack. The goal is to demonstrate how Wazuh detects and mitigates this attack.
Wazuh Server: OS: Ubuntu 22.04, IP: 192.168.23.5, Package: Wazuh 4.3.10.
Intruder PC: OS: Ubuntu 22.04, IP: 192.168.23.4, Package: SQLMap installed for performing the SQL injection attack.
This lab assumes a basic understanding of Wazuh. If you’re unfamiliar with installing a Wazuh server or onboarding an agent, you can refer to my previous post linked below for a step-by-step guide.
Threat detection and response with WAZUH part-1
Threat detection and response with WAZUH part-2: Agent Installation
For more detailed instructions on installing Wazuh, be sure to check out their official documentation page here.
Here’s the current status of my Wazuh server, showing that one agent is successfully onboarded with Agent ID: 001 and the name webapp.
Attack:
I’ll kick off the attack simulation from my Intruder server (IP: 192.168.23.4). Using the SQLMap tool, I execute the following command to launch the attack. The target is specified with the -u parameter, and the –dbs flag will enumerate the databases available on the target system.
sqlmap -u "http://192.168.23.3/mysite/login.php?user=admin'" --dbs --random-agent
After running the command, SQLMap prompted me with a series of questions. I confirmed all by typing “Y,” and shortly thereafter, I received a response that disclosed the database names on my web application server. There are six databases in total and my target database name is my_db.
available databases [6]: [*] demo_db [*] information_schema [*] my_db [*] mysql [*] performance_schema [*] sys
Now that I have the database name, my next step is to explore the tables within that database. To do this, I execute the command below.
sqlmap -u "http://192.168.23.3/mysite/login.php?user=admin'" -D my_db --tables
After a short while, I received the following output, indicating that one table named users was found within the my_db database.
Database: my_db [1 table] +-------+ | users | +-------+
Alright, the attack simulation has been completed. My aim isn’t to teach you how to exploit vulnerabilities with SQLMap. But If you’re looking to extract additional information, you can enhance the command by adding parameters like –columns, which will reveal the column names. Once you have those, you can append -C <column-name> to retrieve the actual data from the specified columns.
After executing the attack, let me demonstrate how Wazuh responds to such activities. Take a look at the screenshot below, which shows that Wazuh identified this activity as an SQL injection attempt.
To identify the source of the attack, expand the log, and you’ll see the attack’s originating IP address as shown below. In my case, it displays the IP of my Intruder server.
data.srcip 192.168.23.4
A crucial aspect to note is which rule was triggered to detect the attack. In this instance, Wazuh triggered Rule ID 31171 for identifying the SQL injection attempt. This rule ID will be essential for configuring the active response mechanism later.
Active Response:
Its time to introduce active response in Wazuh. So what is active response? Its a module in Wazuh. The active response module provides pre-built scripts designed to neutralize threats, such as blocking malicious network activity or removing harmful files from endpoints. These scripts are executed automatically when alerts associated with specific rule IDs, levels, or rule groups are triggered. While the module allows for multiple response actions per trigger, it is crucial to configure them carefully. Poorly implemented rules or responses can inadvertently increase endpoint vulnerabilities, potentially compromising security. if you want to learn more about Active response checkout Wazuh official documentation page here.
To configure active response, open the Wazuh configuration file on the Wazuh server, located at /var/ossec/etc/ossec.conf. Then, add the following configuration snippet.
<ossec_config>
<active-response>
<command>firewall-drop</command>
<location>defined-agent</location>
<agent_id>001</agent_id>
<rules_id>31171</rules_id>
<timeout>600</timeout>
</active-response>
</ossec_config>
Let me explain the snippet. Wazuh will execute the firewall-drop script on Agent 001 when Rule ID 31171 is triggered. This script will create an iptables entry on the agent to block the source IP address (in my case, 192.168.23.4) for a duration of 600 seconds.
To get the active response log add the below snippet.
<ossec_config>
<localfile>
<log_format>syslog</log_format>
<location>/var/ossec/logs/active-responses.log</location>
</localfile>
</ossec_config>
After doing the configuration restart the Wazuh manager.
Active response in action:
To verify whether the active response is functioning correctly, I launch the same attack from my Intruder server (192.168.23.4) using the SQLMap command below. This is the same command I used prior to configuring the active response.
sqlmap -u "http://192.168.23.3/mysite/login.php?user=admin'" --dbs --random-agent
After some seconds the command hang and a message like below is showing by SQLMap.
[05:29:19] [WARNING] there is a possibility that the target (or WAF/IPS) is dropping 'suspicious' requests
Now, let’s observe how Wazuh is handling this attack this time. According to the security logs from Agent 001, it indicates that a host has been blocked by the firewall-drop active response. Checkmate! The attack was not only detected but also successfully prevented by Wazuh’s active response mechanism.
if you expand the log you will find the source ip of the attack. In my case its 192.168.23.4.
data.parameters.alert.data.srcip 192.168.23.4
Behind the scenes, the firewall-drop script creates an iptables entry in Agent 001, as displayed below.
imtiaz@webapp:~$ sudo iptables -L -nv | more Chain INPUT (policy DROP 92 packets, 7488 bytes) pkts bytes target prot opt in out source destination 35 5094 DROP all -- * * 192.168.23.4 0.0.0.0/0
Wait for 10 minutes (or 600 seconds) and then check the security log for Agent 001 again. This time, a new entry will be added to the logs indicating that the attacking host has been unblocked.
In this post, we explored how to configure Wazuh for active response against SQL injection attacks. Starting from an Intruder server, I demonstrated using SQLMap to exploit a PHP application. Wazuh detected the attack triggering Rule ID 31171 and executed the firewall-drop script on Agent 001, blocking the source IP for 600 seconds. After verifying the effectiveness of the active response, we observed that Wazuh not only detected the attack but also successfully prevented it.
Thanks for reading the post. If you enjoyed the post, please share it with your network and let me know your thoughts in the comments.
About the Author: Imtiaz is working in a financial organization in Bangladesh and having experience in system, network and security administration. Feel free to contact with him on LinkedIn or Twitter.