Responding to network attacks with Suricata and Wazuh XDR

| by | Wazuh 4.3
Post icon

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>
Suricata group
Fig 1: This image shows that the CentOS agent belongs to the Suricata group.

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

Attack emulation
Fig 2: 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)
active response alert
Fig 3: This image shows the active response alert that blocks the Nmap scan.

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.

Nmap scan event log
Fig 4: Nmap scan event log.

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.
Blocks the DoS attack
Fig 5: This image shows the Wazuh active response alert that blocks the DoS attack.
GoldenEye DoS attack event log
Fig 6: GoldenEye DoS attack event log

Connectivity test 2

Connectivity test
Fig 7: 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