Responding to network attacks with Suricata and Wazuh XDR
Devices today exist in more varieties and numbers than ever before. With the continuously growing number of nodes and endpoints in a network, finding and responding to threats in real-time is difficult. Technology is constantly evolving to eliminate repetitive activities. One such advancement has led to the development of Extended Detection and Response solutions (XDR). XDR platforms analyze data from events generated from monitored endpoints to spot suspicious activity and respond to them. Automated responses are issued to prioritized alerts to deal with the threat as quickly as possible.
Suricata is an intrusion detection system that can analyze network events and generate alerts when suspicious or malicious events are detected. By integrating Suricata with the Wazuh active response module, administrators can enhance the Wazuh XDR feature in their environment. Automated response actions can be applied to certain events detected by Suricata on monitored endpoints.
This blog post focuses on how we can protect an endpoint from network attacks using Suricata and the Wazuh active response module.
Suricata infrastructure
To illustrate Wazuh capabilities for detecting and responding to network-related attacks, we set up our infrastructure using the following build:
1. A pre-built ready-to-use Wazuh OVA 4.3.9. Follow this guide to download the virtual machine. In this scenario, our IP address is 10.0.2.43.
2. A CentOS 7 endpoint with the Wazuh agent 4.3.9 installed and enrolled. In this scenario, our IP address is 10.0.2.15. We will install Suricata on this endpoint to widen network attack detection. The Wazuh agent installed on this endpoint will retrieve Suricata logs. We will also install an Apache 2.4.6 web server. We do this because a web server is needed to emulate a DoS attack in a later section.
3. A Kali Linux 2022.1 attacker endpoint. In this scenario, our IP address is 10.0.2.23. In a later section, we use this endpoint to emulate attacks against the CentOS 7 endpoint.
Suricata configuration
CentOS 7 endpoint
This is the victim endpoint with the Wazuh agent installed on it. We use Suricata to monitor the network traffic for this server. To install Suricata, follow the steps below:
1. Run the following commands using the terminal to set up Suricata on CentOS 7:
$ sudo yum clean all $ sudo yum -y install epel-release wget jq $ curl -O https://copr.fedorainfracloud.org/coprs/jasonish/suricata-6.0/repo/epel-7/jasonish-suricata-6.0-epel-7.repo $ sudo yum -y install suricata $ wget https://rules.emergingthreats.net/open/suricata-6.0.3/emerging.rules.tar.gz $ sudo tar zxvf emerging.rules.tar.gz $ sudo rm /etc/suricata/rules/* -f $ sudo mv rules/*.rules /etc/suricata/rules/ $ sudo rm -f /etc/suricata/suricata.yaml $ sudo wget -O /etc/suricata/suricata.yaml https://packages.wazuh.com/4.3/suricata.yml
2. Set the network interface you wish to monitor in the Suricata configuration file /etc/suricata/suricata.yaml. Search for the string af-packet:. Beneath it, you will find the variable interface. Replace the value with the interface name of your monitored endpoint. For example, the monitored network interface name on the CentOS 7 endpoint is enp0s3.
Run the ifconfig command to find out the interface name:
$ ifconfig
The output below shows the interface name in our scenario:
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::9ba2:9de3:57ad:64e5 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:14:65:bd txqueuelen 1000 (Ethernet)
RX packets 6704315 bytes 1268472541 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4590192 bytes 569730548 (543.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Hence, the string interface in the /etc/suricata/suricata.yaml configuration file is set to enp0s3:
af-packet:
- interface: enp0s3
# Number of receive threads (>1 will enable experimental flow pinned
Save the changes.
3. Modify the Suricata service configuration file /etc/sysconfig/suricata to specify the interface Suricata is listening on. The interface in our scenario is enp0s3.
# Add options to be passed to the daemon OPTIONS="-i enp0s3 --user suricata "
Save the changes.
4. Run the suricata-update command on the CentOS endpoint terminal to install and update Emerging Threat rules:
$ sudo suricata-update
5. Modify the default /etc/suricata/suricata.yaml configuration file and specify the Suricata rules to use. We used the following configuration for this demonstration:
default-rule-path: /var/lib/suricata/rules rule-files: - suricata.rules
Save the changes.
6. Start Suricata:
$ sudo systemctl daemon-reload $ sudo systemctl enable suricata $ sudo systemctl start suricata
Installing Apache web server on the CentOS endpoint
To perform an emulated DoS attack on the CentOS endpoint, we install Apache web server. A web server running on the CentOS endpoint is needed as a target for attack emulation 2. This attack will be carried out in a later section by the Kali Linux endpoint.
7. To set up an Apache web server on the CentOS endpoint, execute the following commands:
$ sudo yum update httpd $ sudo yum install httpd $ sudo firewall-cmd --permanent --add-service=http $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --reload $ sudo systemctl enable httpd $ sudo systemctl start httpd
8. Confirm that the httpd service is running and your web server is up:
$ sudo systemctl status httpd $ curl http://<CENTOS_IP>
Wazuh server
To centrally manage the configuration of all endpoints with Suricata installed, create a new agent group called Suricata and add the CentOS agent to it.
Creating an agent group and adding an agent
1. Create an agent group called Suricata:
$ sudo /var/ossec/bin/agent_groups -a -g Suricata -q
2. Get the ID of all agents you want to add to this category:
$ sudo /var/ossec/bin/manage_agents -l
3. Include the agent ID using the command below:
$ sudo /var/ossec/bin/agent_groups -a -i <AGENT_ID> -g Suricata -q
Where:
AGENT_ID is the ID of the agent you want to add to the Suricata group.
4. Add the following configuration to the Suricata group shared agent configuration file /var/ossec/etc/shared/Suricata/agent.conf:
<agent_config>
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
</agent_config>
Extending the JSON decoder for Suricata
In Suricata logs, the src_ip field holds the IP address of the malicious actor. The Wazuh firewall-drop active response script expects the field srcip in the alert that triggers the active response. To ensure that the field src_ip is processed by the active response scripts, we configure a custom decoder to map the src_ip field to srcip. To do this, perform the following steps:
1. Add the decoders below to the local decoders file /var/ossec/etc/decoders/local_decoder.xml:
<decoder name="json">
<prematch>^{\s*"</prematch>
</decoder>
<decoder name="json_child">
<parent>json</parent>
<regex type="pcre2">"src_ip":"([^"]+)"</regex>
<order>srcip</order>
</decoder>
<decoder name="json_child">
<parent>json</parent>
<plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>
2. Restart the Wazuh manager for the changes to apply:
$ sudo systemctl restart wazuh-manager
Creating custom rules from Suricata alerts
On the Wazuh server, we add custom rules to detect the use of the Nmap scripting engine, and the GoldenEye DoS attack from Suricata alerts. These rules will be used by the active response module to trigger the firewall-drop script on the CentOS agent. This script adds the malicious IP address to the firewall block list on the monitored agent.
1. Add the following rules to the /var/ossec/etc/rules/local_rules.xml file:
<group name="custom_active_response_rules,">
<rule id="100200" level="12">
<if_sid>86600</if_sid>
<field name="event_type">^alert$</field>
<match>ET DOS Inbound GoldenEye DoS attack</match>
<description>GoldenEye DoS attack has been detected. </description>
<mitre>
<id>T1498</id>
</mitre>
</rule>
<rule id="100201" level="12">
<if_sid>86600</if_sid>
<field name="event_type">^alert$</field>
<match>ET SCAN Nmap Scripting Engine User-Agent Detected (Nmap Scripting Engine)</match>
<description>Nmap scripting engine detected. </description>
<mitre>
<id>T1595</id>
</mitre>
</rule>
</group>
Save the changes.
2. Restart the Wazuh manager for the changes to apply:
$ sudo systemctl restart wazuh-manager
Active response configuration
Wazuh includes an out-of-box firewall-drop script that adds the IP address extracted from an alert to the monitored endpoints firewall block list. Configure the firewall-drop active response on the Wazuh server using the following steps:
1. Open the Wazuh server configuration file /var/ossec/etc/ossec.conf and confirm the command section for firewall-drop exists. Add the configuration block below if it does not:
<ossec_config>
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
</ossec_config>
2. Edit the Wazuh server configuration file /var/ossec/etc/ossec.conf and add the following section:
<ossec_config>
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100200, 100201</rules_id>
<timeout>180</timeout>
</active-response>
</ossec_config>
location: This specifies where the active response command is executed. To execute the script on the Wazuh agent, we use local.
rules_id: This limits the execution of the active response script to when rules 100200 and 100201 fire. Rules can be separated with the use of a comma.
timeout: This specifies the time in seconds, taken before the active response command is reversed.
3. Restart the Wazuh manager for the configuration changes to apply:
$ sudo systemctl restart wazuh-manager
Kali Linux endpoint
Download Goldeneye on the Kali Linux endpoint by cloning the GitHub repository. We use this tool to perform the HTTP DoS attack.
$ git clone https://github.com/jseidl/GoldenEye.git
Attack emulation
In this section, we execute the following offensive activities:
- An Nmap scan.
- A DoS attack.
Connectivity test 1
1. To check for connectivity between the Kali Linux and CentOS endpoint. Ping the CentOS endpoint, from the Kali Linux endpoint:
$ ping <CENTOS_IP>
The output shows responses were being received from the CentOS endpoint:
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data. 64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.600 ms 64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.700 ms 64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.490 ms
2. Next, run tcpdump on the Kali Linux endpoint to monitor the eth0 interface for icmp requests and responses:
$ sudo tcpdump -i eth0 icmp
The output shows icmp responses received from the CentOS endpoint:
10:29:30.721391 IP 10.0.2.15 > 10.0.2.23: ICMP echo reply, id 26049, seq 9, length 64 10:29:31.745118 IP 10.0.2.23 > 10.0.2.15: ICMP echo request, id 26049, seq 10, length 64 10:29:31.745301 IP 10.0.2.15 > 10.0.2.23: ICMP echo reply, id 26049, seq 10, length 64
Attack emulation 1: Nmap scan
Nmap is an active reconnaissance tool used to gather information on infrastructure. From the Kali endpoint, we perform an Nmap scan against the CentOS endpoint using the command below:
$ sudo nmap -sS --script=vuln <CENTOS_IP>
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-05 07:25 EDT Nmap scan report for 10.0.2.15 Host is up (0.00037s latency). Not shown: 993 filtered tcp ports (no-response), 6 filtered tcp ports (host-prohibited) PORT STATE SERVICE 22/tcp open ssh MAC Address: 08:00:27:14:65:BD (Oracle VirtualBox virtual NIC)
The Wazuh active response module sends a firewall-drop command to the CentOS. This command blocks the malicious IP address from making further probes for a period of 3 minutes.
Attack emulation 2: DoS attack
Denial of service attacks aims to render system resources unavailable to users. In this scenario, we use the GoldenEye tool installed on the Kali Linux endpoint to perform a DoS attack against the web server on the CentOS endpoint.
If you have launched attack emulation 1, ensure to wait 3 minutes before launching this attack. This waiting period was set in the timeout tag within the active response configuration section. This waiting period allows the active response script to undo its original action of blocking the malicious IP address.
Navigate to the folder where the GoldenEye repository was cloned. Run the following command to launch the attack:
$ ./goldeneye.py http://<CENTOS_IP>
GoldenEye v2.1 by Jan Seidl <jseidl@wroot.org> Hitting webserver in mode 'get' with 10 workers running 500 connections each. Hit CTRL+C to cancel.
Connectivity test 2
Run the connectivity test 2 within 3 minutes of executing attack emulation 1 or 2.
1. To check for connectivity between the Kali Linux and CentOS endpoint. Ping the CentOS endpoint, from the Kali Linux endpoint:
$ ping http://<CENTOS_IP>
The output shows no response was received from the CentOS endpoint:
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.
2. Next, run tcpdump on the Kali Linux endpoint.
$ sudo tcpdump -i eth0 icmp
The tcpdump output from the Kali Linux endpoint shows that icmp replies were not received from the victim CentOS endpoint shortly after launching the Nmap scan:
10:29:32.769242 IP 10.0.2.23 > 10.0.2.15: ICMP echo request, id 26049, seq 11, length 64 10:29:33.793502 IP 10.0.2.23 > 10.0.2.15: ICMP echo request, id 26049, seq 12, length 64 10:29:34.817383 IP 10.0.2.23 > 10.0.2.15: ICMP echo request, id 26049, seq 13, length 64
Conclusion
By using Suricata to detect network events and Wazuh for analysis and automated response, you can ensure your organization stays ahead of network-related attacks. This article demonstrates how Wazuh responded to an Nmap scan, and a DoS attack using the active response module
Wazuh is open-source and free to use. It also has a large community. You can deploy Wazuh on-premises or as a cloud solution using the Wazuh cloud. To stay up to date with the work we do, check out our website.
References
- Catch suspicious network traffic – Learning Wazuh
- What Is Network Detection and Response – NDR – Cisco
- Difference between HIDs and NIDs – GeeksforGeeks
- Creating decoders and rules from scratch · Wazuh · The Open Source Security Platform
- How To Install the Apache Web Server on CentOS 7 | DigitalOcean