Organizations of all sizes are increasingly concerned about protecting their digital landscape. With technology growing and digital systems becoming more important, cyber threats are escalating rapidly. Organizations must take a proactive approach toward cybersecurity and deploy mechanisms and appropriate visibility controls that not only prevent but also detect threats or intrusions. The main goal of prevention techniques is to keep threats from getting into a network or system. Like deploying perimeter security solutions such as firewalls, intrusion prevention system (IPS) infrastructure, visibility and control, and, most importantly, endpoint protection and insider threats. They intend to put up barriers that make it impossible for bad people to get in or execute any cyber-attacks.
Detection techniques, along with preventive measures, involve keeping an eye on systems all the time for any signs of compromise or strange behavior and taking the required steps to mitigate the execution of reported malicious activity/behavior. One of the popular tools for this purpose is an intrusion detection system (IDS). Wazuh can help organizations detect potential threats or ongoing attacks, and an IDS also allows a security team to enable the early detection of possible breaches or suspicious activity, and, as a result, the security team can quickly respond to mitigate potential damage. Wazuh is a popular IDS result, which works on various levels including host-level visibility along with the capability to collect, aggregate, index, and analyze logs from various sources at a perimeter and infrastructure level; it also offers end-user activity monitoring solutions and protection. It provides a ton of features, including log collection. In addition to log collection, it has various inbuilt modules including vulnerability management, file integrity, malware detection, automated incident response, and various external integrations. Another open source popular IDS/IPS solution is Suricata, which works on a network level that helps the security team detect anomalous network behavior. In this book, we get hands-on with Wazuh capabilities and features, however, in this chapter, our focus will be on integrating Suricata IDS/IPS with Wazuh. This will help us detect any network anomalous behavior.
In this chapter, we will learn the following:
An IDS works by monitoring network traffic, system logs, and other relevant information to identify and analyze patterns and signatures associated with known threats or abnormal behavior. The primary goal of an IDS is to detect and alert security administrators about potential threats or breaches. When an IDS identifies suspicious behavior or patterns, it generates an alert, notifying the security team to take appropriate action.
There are two main types of IDS: NIDS and host-based IDS (HIDS). The main difference between a NIDS and a HIDS is the monitoring scope and types of activities they detect. Have a look at the following table to look at the differences:
NIDS |
HIDS |
|
Scope |
It works at the network level, monitoring the data going to and from different devices to look for abnormal behaviors or events that might indicate an intrusion. |
It is installed directly on the host’s and monitor’s log files, system calls, file integrity, and other host-specific files for any unusual activities. |
Location |
Functions at one or more central places in a network’s infrastructure to monitor and analyze traffic going through those points. |
Operates locally on individual hosts or devices, keeping an eye on actions that are unique to that machine. |
Detection focus |
A NIDS detects network attacks and anomalies. It can detect port scans, DoS attacks, intrusion attempts, and other network infrastructure threats. |
A HIDS monitors host activity. It detects unauthorized access, file system changes, critical system file modifications, and suspicious processes or behaviors that may indicate a compromised host. |
Popular tools |
Suricata, Snort |
Wazuh, OSSEC |
Table 1.1 – NIDS versus HIDS
In the following diagram, you can see that a NIDS is installed to monitor network traffic while an HIDS monitors individual devices.
Figure 1.1 – NIDS versus HIDS
Suricata is an open-source network intrusion detection and prevention system (IDS/IPS). It is intended to monitor network traffic and detect a variety of threats, including malware, intrusion attempts, and network anomalies. Using a rule-based language, Suricata analyzes network packets in real time, allowing it to identify and respond to suspicious or malicious activities. The non-profit organization OISF (Open Information Security Foundation) owns and develops Suricata.
Suricata can also be deployed as an IPS in order to detect and block malicious traffic to the organization. Although IPS deployment might sound like the obvious option, unfortunately, it isn’t that friendly; it often blocks legitimate traffic as well if they aren’t configured properly. And yes, this is why the detection approach is sometimes better than the prevention approach.
You can download Suricata from the following link: https://suricata.io/download/.
There are multiple use cases of Suricata IDS; some of the important use cases are as follows:
Let’s learn about the deployment methods of the Suricata IDS.
There are several ways to deploy the Suricata IDS and some of the important and popular deployment methods are explained in the following:
Figure 1.2 – Inline deployment at network perimeter
Figure 1.3 – Internal network monitoring
Figure 1.4 – Cloud security monitoring (AWS)
Figure 1.5 – Network tap deployment
We have learned about the different Suricata deployment methods. In the next section, we will learn about Wazuh, its core components and deployment methods, and then we will learn how to install Suricata IDS on Ubuntu Server.
Wazuh is an open-source security monitoring platform that provides extended detection and response (XDR) and SIEM functionality. Wazuh’s capabilities include log analysis, intrusion detection, vulnerability detection, and real-time alerting, helping organizations enhance their security posture and respond to threats effectively. In this section, we will first get a basic understanding of the Wazuh platform and its core components and deployment methods, and then we will set up the Wazuh agent and connect with the Wazuh platform. Next, we will set up a Suricata IDS and integrate it with the Wazuh agent. Some of the main points we will explore are as follows:
Wazuh provides a centralized platform for monitoring and managing security events across the organization’s IT infrastructure. Wazuh collects, analyzes, and connects log data from different sources, such as endpoints, network devices, firewalls, proxy servers, and cloud instances. Once the logs are collected, Wazuh provides several capabilities to the security team such as file integrity monitoring, malware detection, vulnerability detection, command monitoring, system inventory, threat hunting, security configuration assessment, and incident response. The Wazuh solution is made up of three main parts: the Wazuh server, the Wazuh indexer, and the Wazuh dashboard. The Wazuh agent is installed on the endpoints that need to be monitored.
This central component is also used to manage the agents and analyze the data received from them:
It is responsible for indexing and storing alerts generated by the Wazuh server:
Note
Indexing is the process of arranging and arranging data to enable effective and quick retrieval. It involves creating a data structure called an index.
wazuh-alerts-*
: This is the index pattern for alerts generated by the Wazuh serverwazuharchives-*
: This is the index pattern for all events sent to the Wazuh serverwazuh-monitoring-*
: This pattern is for monitoring the status of Wazuh agentswazuh-statistics-*
: This is used for statistical information about the Wazuh serverThe Wazuh dashboard is a web interface that allows you to perform visualization and analysis. It also allows you to create rules, monitor events, monitor regulatory compliances (such as PCI DSS, GDPR, CIS, HIPPA, and NIST 800-53), detect vulnerable applications, and much more.
Wazuh agents are installed on endpoints such as servers, desktops, laptops, cloud compute instances, or VMs. Wazuh utilizes the OSSEC HIDS module to collect all the endpoint events.
Note
OSSEC is a popular and open-source host-based IDS (HIDS). It is a powerful correlation and analysis module that integrates log analysis, file integrity monitoring, Windows registry monitoring, centralized policy enforcement, rootkit detection, real-time alerting, and active response. It can be installed on most operating systems (OSs) such as Linux, OpenBSD, FreeBSD, MacOS and Windows.Wazuh deployment options
Wazuh is known for its ability to fully monitor security and detect threats. It also has several flexible deployment options. Depending on your requirement, you can deploy Wazuh in an on-premises server, cloud, Docker container, Kubernetes, or another environment. For a production environment, Wazuh core components (i.e., the Wazuh server, the Wazuh indexer, and the Wazuh dashboard) should be installed in cluster mode. Cluster mode deployment involves setting up more than one Wazuh server node to work collectively. By spreading the work and duties among several nodes in the cluster, this configuration aims to improve speed, scalability, and resilience. Let’s cover some important deployment options:
If you want to test all the use cases throughout the book, I suggest you use the Wazuh VM deployment option by downloading the OVA file; however, for the production-level deployment, you can choose any of the remaining options. The Wazuh community has done a brilliant job in documenting the installation guide. You can refer to this link for step-by-step assistance: https://documentation.wazuh.com/current/installation-guide/index.html.
Wazuh has a set of modules that work together to help organizations handle security events, find threats, make sure they are following the rules, and keep their systems and data safe. Once you access the Wazuh manager, the topmost option is Modules. By default, you can find multiple modules categorized under four sections as mentioned in the following diagram:
Figure 1.6 – Default Wazuh modules
Let us look into each of those four sections in detail:
Note
ATT&CK stands for adversarial tactics, techniques, and common knowledge. MITRE is a government-funded research organization based in Bedford, MA, and McLean, VA. MITRE ATT&CK is a framework that helps organizations with attacker’s tactics, techniques, and procedures to test their security controls.
Note
The Center for Internet Security (CIS) benchmarks are a set of best practices that are known around the world and are based on consensus. They are meant to help security professionals set up and manage their cybersecurity defenses.
Next, let’s talk about the Wazuh Administration, where we will discuss some core features of the Wazuh manager.
Under the Management section of the Wazuh dashboard, we have the Administration section. As you can see in the following diagram, the Administration section includes capabilities such as Rules, Decoders, CDB lists, Groups, and Configuration.
Figure 1.7 – Wazuh administration
All the features mentioned under the Administration tab play a pivotal role in ensuring the effectiveness of the Wazuh platform for real-time monitoring and threat detection. We will understand each of these features as explained in the following sections.
Decoders are responsible for reading incoming log entries, pulling out the important information, and putting them into a standard format that the Wazuh system can easily understand and analyze. Raw log entries can be in different formats, such as syslog, JSON, XML, or custom text formats. The job of the decoder is to figure out how these logs are put together and pull out meaningful fields and values. There are many pre-built decoders in Wazuh such as the syslog decoder, OpenSSH decoder, Suricata decoder, and the Cisco ASA decoder. To understand what decoders are and how they work, let us look at how logs from the Barracuda Web Application Firewall (WAF) are processed:
<decoder name="barracuda-svf1"> <parent>barracuda-svf-email</parent> <prematch>^\S+[\S+]|</prematch> <prematch>^\S+</prematch> <regex>^\S+[(\S+)] (\d+-\w+-\w+) \d+ \d+ |</regex> <regex>^(\S+) (\d+-\w+-\w+) \d+ \d+ </regex> <order>srcip, id</order> </decoder>
Let’s break down the parts of this Wazuh decoder:
decoder name
: This indicates the name of the decoder.parent
: This gives us the name of the parent decoder. The parent decoder will be processed before the child decoders.prematch
: This is like a condition that must match to apply the decoder. It uses regular expressions to look for a match.regex
: This represents the regular expression to extract data. In the preceding decoder, we have two regex
instances.order
: This indicates the list of fields in which the extracted information or value will be stored.Decoders have many more configuration options available to them. Visit the Decoders Syntax page (https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html) in the Wazuh documentation to see all of the available options.
Wazuh rules help the system detect attacks in the early stages, such as intrusions, software misuse, configuration issues, application errors, malware, rootkits, system anomalies, and security policy violations. Wazuh comes with several pre-built rules and decoders but also allows you to add custom rules. Let’s take a sample Wazuh rule:
<rule id="200101" level="1"> <if_sid>60009</if_sid> <field name="win.system.providerName">^PowerShell$</field> <mitre> <id>T1086</id> </mitre> <options>no_full_log</options> <group>windows_powershell,</group> <description>Powershell Information EventLog</description> </rule>
Let’s break this code down:
rule id
: This represents the unique identifier for the Wazuh rule.level
: The rule’s classification level ranges between 0 and 15. According to the rule categories page (https://documentation.wazuh.com/current/user-manual/ruleset/rules-classification.html) in the Wazuh documentation, each number indicates a distinct value and severity.if_sid
: This specifies the ID of another rule (in our case, it’s 60009
), which triggers the current rule. The “if” condition is considered as the “parent” rule that must be checked first.field name
: This specifies the name of the field extracted from the decoder. The value is matched by a regular expression. In this case, we are looking for the field name win.system.providerName
with a value of PowerShell
.group
: This is used to organize the Wazuh rules. It contains the list of categories that the rules belong to. We have organized our rule in the windows_powershell
group.There are tons of other options available for Wazuh rules. I would suggest you check out the Rules Syntax page at the following link: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html) in the Wazuh documentation.
The Constant Database (CDB) list enables the categorization and management of IP addresses and domains based on their characteristics. These lists can include known malicious IP addresses, suspicious domains, trusted IP addresses, whitelisted domains, and more. Admins maintain these lists by adding or removing entries based on reputation or risk levels. To learn more about CDB lists, you can visit the official Wazuh documentation for CDB lists: https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html.
Agents can be grouped based on their OS or functionalities using groups; for example, all Windows agents can be grouped under a single group named Windows Agents. This is helpful when you want to push configuration changes from the Wazuh manager to all Windows agents at once. This becomes a simple and single-step solution. To learn more about grouping agents, you can visit the official Wazuh documentation here: https://documentation.wazuh.com/current/user-manual/agents/grouping-agents.html.
This helps security teams to fine-tune Wazuh’s main configurations such as cluster configuration, alert and output management, log data analysis, cloud security, vulnerabilities, inventory data, active response, commands, Docker listeners, and monitoring (Amazon S3, Azure logs, Google Cloud, GitHub, Office 365, etc.). All these features can even be customized from the command-line option as well. You need to locate the ossec.conf
file in your Wazuh manager or Wazuh agent at the /
var/ossec/etc
directory.
Now, let’s start deploying our Wazuh agent on the Ubuntu machine and then we will install Suricata on the same machine.
The Wazuh server is the central component of the Wazuh security platform. It consists of two important elements: the Wazuh manager and Filebeat. The Wazuh manager collects and analyzes data from the Wazuh agents and triggers alerts when it detects any threats. Filebeat forwards alerts and events to the Wazuh indexer. The Wazuh server can be installed in multiple ways, however, I’d recommend the multi-node cluster method for a production environment and the VM method for a lab environment. You can follow the guidelines for both methods in the following sections.
To set up Wazuh in the production environment, it is recommended to deploy the Wazuh server and Wazuh indexer on different hosts. This helps you handle traffic from a large number of endpoints and also to achieve high availability. The step-by-step guide to install the Wazuh server along with the indexer and dashboard is mentioned here: https://documentation.wazuh.com/current/installation-guide/index.html.
You can use the Wazuh VM OVA file for a lab environment as it is easy to deploy. All the Wazuh components including the Wazuh server, indexer, and dashboard are unified. To install Wazuh using an OVA file, follow these steps:
Figure 1.8 – Accessing the Wazuh web interface
You need to enter the following:
admin
admin
A Wazuh agent is compatible with multiple OSs. Once a Wazuh agent is installed, it will communicate with the Wazuh server, pushing information and system logs in real-time using an encrypted channel.
To deploy a Wazuh agent on the Ubuntu Server, you need to install the agent and configure the deployment variables. To get started with installation, you need to log in to your Wazuh dashboard, navigate to Agents, click on Deploy an agent and then follow these steps:
Figure 1.9 – Deploying a new agent
Figure 1.10 – Choosing a server address and optional settings
Let’s break down what we’ve inputted:
192.168.29.32
: This is the IP address of the Wazuh serverubu-serv
: This indicates the name of the Wazuh agentdefault
: It represents the Wazuh agent groupcurl
command to download the Wazuh module and start the Wazuh agent service as mentioned in the following diagram.Figure 1.11 – Retrieving the commands to download and install a Wazuh agent
Note
Make sure that there are no firewall rules blocking communication between the agent and the Wazuh manager. The agent should be able to communicate with the manager over the configured port (the default is 1514
/514
for syslog).
Finally, you can verify whether the agent is connected and activated by logging in to the Wazuh manager and navigating to Agents.
Figure 1.12 – Visualizing Wazuh agents
As you can see in the preceding diagram, the ubu-serv-03
agent is connected with the following:
006
192.168.29.172
Now, let’s install the Wazuh agent on Windows Server. The process will be the same for the Windows desktop, too.
You can monitor real-time events from Windows Server or a desktop on the Wazuh server by using the command line interface (CLI) or graphical user interface (GUI). To get started with installation, you need to log in to your Wazuh dashboard, navigate to Agents, click on Deploy an agent and then follow these steps:
Figure 1.13 – Selecting the Windows package for the Wazuh agent
Figure 1.14 – Entering the server address and optional settings
Figure 1.15 – Retrieving the commands to download and install the Wazuh agent on a Windows machine
Finally, you can verify whether the agent is connected and activated by logging in to the Wazuh manager and navigating to Agents.
Figure 1.16 – Visualizing Wazuh agents installed on a Windows machine
As you can see in the preceding diagram, the WIN-AGNT
agent is connected with the following:
004
192.168.29.77
We have successfully learned how to deploy Wazuh agents on both the Ubuntu Server and Windows Server. In the next section, we will learn how to set up a Suricata IDS on Ubuntu Server.
With the ability to detect malicious or suspicious activities in real time, Suricata is an NSM tool, which has the potential to work as an IPS/IDS. Its goal is to stop intrusion, malware, and other types of malicious attempts from taking advantage of a network. In this section, we will learn how to install Suricata on Ubuntu server. Let’s first learn about the prerequisites.
To install Suricata IDS on Ubuntu Server, the prerequisites are as follows:
This process involves the installation of Suricata packages using the apt-get
command line tool and then we need to install the free and open source Suricata rules created by the ET community. The rules within the ET ruleset cover a broad spectrum of threat categories, including malware, exploits, policy violations, anomalies, botnets, and so on. To complete the installation, follow these steps:
sudo add-apt-repository ppa:oisf/suricata-stable sudo apt-get update sudo apt-get install suricata –y
/
etc/suricata/rules
directory:cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz sudo tar -xvzf emerging.rules.tar.gz && sudo mv rules/*.rules /etc/suricata/rules/ sudo chmod 640 /etc/suricata/rules/*.rules
Note
If the rule directory is not present, you can create one by using the mkdir /etc/suricata/
rules and then you can enter the previously mentioned commands.
/etc/suricata/suricata.yaml
:HOME_NET: "<AGENT_IP>" EXTERNAL_NET: "any" default-rule-path: /etc/suricata/rules rule-files: - "*.rules" # Linux high speed capture support af-packet: - interface: eth01
Let’s break down this code further:
HOME_NET
: This is a variable that needs to be set with the agent IP address.EXTERNAL_NET
: This variable needs to be set with "any"
to ensure Suricata will monitor the traffic from any external IP address.default-rule-path
: This is set to our Suricata rule path.af-packet
: This is a packet capture method used to capture network traffic directory from a network interface card (NIC). You can check your current NIC by using the ifconfig
command and updating the af-packet
settings.$ sudo systemctl restart suricata
ossec
config file located at /var/ossec/etc/ossec.conf
. Suricata stores all the logs at /var/log/suricata/eve.json
. You are required to mention this file under the <location>
tag in the ossec.conf
file:<ossec_config> <localfile> <log_format>json</log_format> <location>/var/log/suricata/eve.json</location> </localfile> </ossec_config>
$ sudo systemctl restart wazuh-agent
This completes Suricata’s integration with Wazuh. The Suricata IDS has been installed on Ubuntu Server along with the ET ruleset. Your endpoints are ready to trigger alerts if any malicious traffic is matched against any of the ET rulesets. Before getting into some practical use cases, let’s first get a basic understanding of Suricata rules and how to create one.
Suricata is powerful when you have a set of powerful rules. Although there are thousands of Suricata rule templates available online, it is still important to learn how to create a custom Suricata rule from scratch. In this section, we’ll learn basic Suricata rule syntax and some common use cases with attack and defense.
Suricata uses rules to detect different network events, and when certain conditions are met, it can be set up to do things such as alert or block.
Here’s an overview of the Suricata rule syntax:
action proto src_ip src_port -> dest_ip dest_port (msg:"Alert message"; content:"string"; sid:12345;)
Let’s break this code down:
action
: This says what should be done when the rule is true. It can be alert
to send an alert, drop
to stop the traffic, or any of the other actions that are supported.proto
: This shows what kind of traffic is being matched, such as tcp
, udp
, and icmp
.src_ip
: This is the source IP address or range of source IP addresses. This is where the traffic comes from.src_port
: This is the port or range of ports where the traffic is coming from.dest_ip
: This is the IP address or range of IP addresses where the traffic is going.dest_port
: This is the port or range of ports where the traffic is going.msg
: The message that will be shown as an alert when the rule is true.content
: This is an optional field that checks the packet payload for a certain string or content.Now, based on our current Suricata configuration, we have the $HOME_NET
and $EXTERNAL_NET
network variables. Let’s get an understanding of an example rule to detect an SSH connection:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"SSH connection detected"; flow:to_server,established; content:"SSH-2.0-OpenSSH"; sid:100001;)
Let’s break this down:
alert
: The rule specifies that an alert should be generated if the specified conditions are met.tcp
: This refers to Transmission Communication Protocol (TCP) based traffic.$EXTERNAL_NET any -> $HOME_NET 22
: The traffic flow is defined by directing traffic from any external network IP address ($EXTERNAL_NET
) to any home or local network IP ($HOME_NET
) on port 22
(SSH).(msg:"SSH connection detected";)
: This specifies a detailed message to be added to the alert. It indicates that the rule has identified an SSH connection in this instance.flow:to_server,established
: This defines the direction of the traffic that initiates the rule. It is looking for established connections between the server (home network) and the server (external network). This portion of the rule prevents initial connection attempts from generating alerts.content:"SSH-2.0-OpenSSH
: This part looks at the payload of the packet for a particular string ("SSH-2.0-OpenSSH"
). It searches the traffic payload for this specific string, which signifies the utilization of the OpenSSH protocol and the SSH protocol in general.sid:100001
: It is a unique identifier for a particular rule.Now that we’ve learned how to create some basic Suricata rules, let’s go through some Suricata IDS use cases with the Wazuh platform.
Network scanning is the initial stage of most hacking exercises, and the most powerful tool used for this purpose is none other than the Nmap scanner. Nmap is a free and open source Linux command-line tool. Nmap helps us to scan any host to discover opened ports, software versions, OSs, and so on. It is used by security professionals for security testing, network exploration, and vulnerability detection. Threat actors also perform network scanning to discover any open ports, software versions, or vulnerability packages. In this section, we will initiate network scanning probes using the Nmap tool against our Wazuh agent (running Suricata services). The ET ruleset already consists of rules to detect Nmap-based scanning probes. We will verify it using this attack scenario.
We will be following the points in these sections:
In this mini lab setup, we need three parts: an attacker machine (Kali Linux or Ubuntu), an Ubuntu machine or Windows machine with the Wazuh agent installed on it, and finally, our Wazuh server. If you use a Kali Linux machine, Nmap is preinstalled; however, if you use an Ubuntu machine, you can install the Nmap package using the sudo apt-get install
nmap
command.
Figure 1.17 – Lab setup of network scanning probe detection using Nmap
If you are using Kali Linux or Ubuntu as an attacker machine, you can open the terminal and enter the nmap
command using the -sS
keyword for an SYN scan and -Pn
to skip host discovery. The Nmap SYN scan is a half-open scan that works by sending a TCP SYN packet to the target machine (the Wazuh agent). If the port is open, the target device responds with a SYN-ACK (synchronize-acknowledgment) packet. However, if the port is closed, the device may respond with an RST (reset) packet, which means the port is not open. In this testing, we will run two types of scan: first to check for open ports using -sS
and second, to check for software version using -sV
(version scan):
# nmap -sS -Pn 10.0.2.5. // Port Scanning # nmap -sS -sV -Pn 10.0.2.5 // Version Scanning
Once you run the preceding command, you will learn what all the ports are open and second, what version of the package is installed on the target machine. Let’s look at the output of the Nmap port scan command:
nmap -sS -Pn 10.0.2.5 Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-10 02:53 IST Nmap scan report for 10.0.2.5 Host is up (0.0037s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 1.45 seconds
As you can see, STATE of port 22/tcp
and 80/tcp
are open. Now, let’s look at the output of the Nmap version check command:
nmap -sV -Pn 10.0.2.5 Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-10 02:59 IST Nmap scan report for 10.0.2.5 Host is up (0.0024s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.52 ((Ubuntu)) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds
From the output, you can see from the VERSION
column that the target is running two software packages: OpenSSH 8.9
and Apache with version 2.4.52
.
To visualize the Suricata alerts, log in to the Wazuh manager and navigate to Security events. Next, select the agent. You will find the security alert shown in the following diagram.
Figure 1.18 – Visualizing network scanning probes on the Wazuh dashboard
You can also apply a filter with rule.group: suricata
.
Figure 1.19 – Visualizing network scanning probes using a Suricata filter
Let’s expand one of the alerts, as shown in the following.
Figure 1.20 – The ET SCAN Potential SSH Scan OUTBOUND alert
Let’s break some of the following down:
data.alert.signature
: This field talks about the ET SCAN Potential SSH Scan OUTBOUND
Suricata rule that detected this abnormal traffic. ET
represents the ET ruleset.data.dest_ip
: This gives us the victim IP address.data.src_ip
: This gives us the attacker IP address.data.alert.action
: This field indicates the action taken by Wazuh in response to a detected security event.alerts.severity
: This field represents the severity level assigned to the security event by Wazuh.So, this was the simple use case of how Suricata can detect the network scanning probes and how Wazuh visualizes it on the dashboard. In the next section, we will learn how to detect web-based attacks on our intentionally vulnerable application DVWA.
As per a CDNetworks report, around 45.127 billion web applications were detected and blocked throughout 2022, which is an increase of 96.35% compared to 2021 (https://www.cdnetworks.com/news/state-of-waap-2022/). Attacks on web applications have become so common that they are now the main cause of data breaches. Some of the most common types of web application attacks include cross-site scripting (XSS), DDoS, cross-site request forgery (CSRF), XML External Entity (XXE), and SQL Injection. Suricata with the ET ruleset can detect such attacks by dissecting packet payloads and scrutinizing HTTP/HTTPS protocol headers for anomalies or abnormal traffic patterns. In this section, we will utilize an intentionally infected web application, DVWA. DVWA is a PHP-based application and is popular among penetration testers and ethical hackers as it helps them get hands-on with security vulnerability and exploitation. We will cover these points in the following subsections:
In this lab setup, we need four parts: an attacker machine (Kali Linux or Ubuntu), a victim server (DVWA running on a Debian server), a TAP server (Wazuh and Suricata agents on Ubuntu), and a Wazuh server. The lab design is in the following figure:
Figure 1.21 – The lab setup for detecting web-based attacks using Suricata
Let’s break this down further:
We will be installing a DVWA application on a Debian-based Linux distribution. You can download it from the following link: https://www.debian.org/distrib/. Our DVWA application has some dependencies such as php
, an apache2
web server, and a MySQL database:
sudo apt -y install apache2 mariadb-server php php-mysqli php-gd libapache2-mod-php
sudo mysql_secure_installation
yes
and then create a user and set its privileges:CREATE USER 'dvwa'@'localhost' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'localhost' IDENTIFIED BY 'password';
/var/www/html
:cd /var/www/html sudo git clone <https://github.com/digininja/DVWA.git> sudo chown -R www-data:www-data /var/www/html/*
/var/www/html/config
directory. You will find the config.inc.php.dist
file. Just make a copy of this file:cp /var/www/html/config/config.inc.php.dist /var/www/html/config/config.inc.php
config.inc.php
file. Change the db_user
to dvwa
and db_password
to password
.mysql
service:systemctl start mysql or service mysql start
php
file and go to /etc/php/x.x/apache2/
to open the php.ini
file.allow_url_include
and set to On.username: admin password: password
This completes our DVWA application installation. Next, we can start testing the DVWA application from Kali Linux against SQL Injection and XSS as explained in the next section.
SQL Injection, or SQLi, is a type of cyberattack in which malicious SQL code is injected into an application. This lets the attacker extract or modify the contents of the database. This attack modifies the database by tricking the program into running SQL commands that weren’t intended to be run. In order to test the DVWA application against SQL Injection vulnerability, we need to insert our malicious payload into the HTTP request itself:
http://<DVWA_IP_ADDRESS>/DVWA/vulnerabilities/sqli/?id=a' UNION SELECT "Hello","Hello Again";-- -&Submit=Submit
Let’s break this down:
UNION SELECT "Hello","Hello Again"
: The UNION SELECT
statement is used to combine the results of two or more SELECT
queries into a single result set. In this case, the attacker wants to add their own information to the query result. "Hello"
and "Hello Again"
are the text information that the attacker wants to inject into the query result.-- -
: This is a comment in SQL. Everything following this on the same line is considered a comment and ignored by the SQL processor.&Submit=Submit
: This part suggests that the query could be part of a form submission where the Submit
parameter is sent with the Submit
value.Now, let’s check on our Wazuh dashboard for the relevant security alerts.
Figure 1.22 – Visualizing SQL Injection alerts
As you expand the individual security alert, you will see detailed information about the alert, the Suricata ET rule, and the category as shown in the following figure:
Figure 1.23 – Suricata alert for SQL Injection on the Wazuh dashboard
Let’s break this down:
Suricata: Alert - ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT
: This represents the security alert namedata.alert.category
Web Application Attack
: This shows the category of the rule as specified in the Suricata ET rulesetData.alert.metadata.tag: SQL_Injection
: This shows the metadata of the Suricata ET ruleset for web application attacksAs we scroll down the alert information even further, we will see more information, as shown in the following figure.
Figure 1.24 – Detailed information of a Suricata alert for SQL Injection
Let’s break this down:
data.http.http.user_agent
: This represents the browser information from where the attack has been attempteddata.http.url: /DVWA/vulnerabilities/sqli/?id=a%27%20UNION%20SELECT%20%22text1%22,%22text2%22;--%20-&Submit=Submit
: This represents a URL query string for the DVWA, specifically targeting a SQL Injection vulnerability.Now, we have learned about how to detect SQL Injection attacks using a Suricata IDS and visualize them on a Wazuh dashboard. In the next section, we will test our DVWA application for XSS vulnerabilities. We will later detect and visualize them on a Wazuh dashboard.
XSS is a type of code injection attack that targets websites and sends malicious scripts to a user’s web browser to execute. In a reflected XSS attack, the attacker inserts malicious script into a website or app, which is subsequently reflected onto the user’s browser from the web server. This kind of attack is possible when a user inputs information into the application, and the application reflects it back to the user without enough sanitization or validation. To test if our intentionally vulnerable application, DVWA, for a reflected XSS attack, we can submit a piece of JavaScript code and verify whether it is reflecting the data back to our browser.
You can open the DVWA application and navigate to the XSS (Reflected) tab. Next, enter a sample JavaScript code as written here:
<script>alert("Hello");</script>
Let’s break this down:
<script> tag
: This indicates a piece of JavaScript code that should be executed by the browserAlert("Hello")
: This is a function that tells the browser to display a pop-up box with the Hello text when the script is executedYou can enter the JavaScript code and click on the Submit button as shown in the following diagram.
Figure 1.25 – Initiating a reflected XSS attack on DVWA
The DVWA application doesn’t have a sanitization check for user inputs, making it vulnerable to reflected XSS attacks. As a result, we will see the Hello text reflected back to our browser as shown in the following diagram.
Figure 1.26 – Visualizing reflected XSS on DVWA
So, the attack was successful. Let’s visualize the alert on the Wazuh dashboard. Navigate to Security Alerts and select the agent.
Figure 1.27 – Suricata alert against an XSS attack
Security Alert – ET WEB_SERVER Script tag in URI Cross Site Scripting Attempt
: This represents the security alert name and signature name.data.alert.category
Web Application Attack
: This represents the category of the alert based on the Suricata ET ruleset.data.alert.metadata.tag
Cross_Site_Scripting, XSS
: This represents the metadata of the security alerts. In our case, it’s Cross_Site_Scripting
and XSS
.In this section, we have successfully launched the SQL Injection and reflected XSS on the intentionally vulnerable application called DVWA. Finally, we were able to detect the attacks using Suricata ET rules and visualize them on the Wazuh dashboard.
In the next section, we will emulate multiple attacks on an Ubuntu machine using the tmNIDS project and visualize it on the Wazuh manager.
tmNIDS is a GitHub project maintained by 3CoreSec. tmNIDS is a simple framework designed for testing the detection capabilities of NIDS such as Suricata and Snort. The tests inside tmNIDS are designed to align with rulesets compatible with the ET community. The ET community builds and shares Suricata rules to detect a wide range of attacks such as web-based attacks, network attacks, and DDoS attacks. In this section, we will learn to simulate attacks using tmNIDS and we will visualize them on the Wazuh dashboard. We will cover these points in the following subsections:
In this lab setup, we have two devices: Ubuntu Server running the Wazuh agent, Suricata IDS, and tmNIDS, and second, the Wazuh server installed using a VM OVA file. The lab design is in the following figure.
Figure 1.28 – Lab set for testing Suricata IDS rules using tmNIDS
The source code of the tmNIDS project is published on GitHub (https://github.com/3CORESec/testmynids.org). To install tmNIDS, we can run a curl
command to download the packages:
curl –sSL https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS> -o /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS
Let’s break this down:
curl
: This is a utility tool that initiates a request to download data from the specific URL.-sSL
: Here, -s
stands for showing progress without any output. The S
flag will show errors if curl
encounters any problem during the request and the L
flag represents redirection.-o /tmp/tmNIDS
: This informs curl
to save downloaded files as tmNIDS in the /
tmp
directory.chmod +x /tmp/tmNIDS
: It changes the file permissions of the downloaded file to executable.Once the package has been executed, you will see a list of 12 tests for Suricata IDS as in the following diagram.
Figure 1.29 – Visualizing tmNIDS detection tester
So, now that our tmNIDS is ready, we can start testing our Ubuntu Server (running Suricata IDS) against multiple attacks as explained in the next sections.
In this scenario, we will execute test 3 from the tmNIDS tests, which is HTTP Malware User-Agent
. For every HTTP request, there is a User-Agent
header that describes the user’s browser, device, and OS. When an HTTP web browser sends a request to a web server, it inserts this header to identify itself to the server. The User-Agent
string usually contains information such as the browser’s name and version, OS, device type, and sometimes extra data such as rendering engine details. If you take a closer look at the HTTP header using Google developer mode, you will find the User-Agent
information:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
This User-Agent
string says that the browser is running on a Windows 10 64-bit system, using the Chrome browser (version 96.0.4664.45
) with rendering engines associated with both WebKit (Safari) and Gecko (Firefox).
To test the Ubuntu Server (running Suricata IDS) against HTTP Malware User-Agent test
, enter 3
on the tmNIDS
prompt.
Figure 1.30 – Choosing option 3 from the tmNIDS detection tester
Now, let’s visualize the alerts on the Wazuh dashboard. You can navigate to the Security Alerts module and select the endpoint. You can find the alerts as shown in the following diagram.
Figure 1.31 – Suricata alert against a suspicious User-Agent
Let’s break some of the following down:
Suricata: Alert – ET POLICY GNU/LINUX APT User-Agent Outbound likely to package management
: This represents the Security alerts name and signaturedata.alert.category : Not Suspicious Traffic
: This represents the category of the ET ruleset categorydata.alert.signature : ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management
: This suggests potential APT-related outbound network activity, possibly tied to package management.After successfully testing HTTP Malicious User-Agent
and visualizing alerts on the Wazuh dashboard, we will test the Tor connection in the next section.
In this scenario, we will execute test 5, which is Tor
. Tor is a decentralized, anonymous network that users can use to browse the internet privately and safely. However, it is often used by hackers, malicious actors, and cybercriminals who access the dark web and sell stolen data and illegal goods online. Its anonymity features can keep attackers’ identities secret, making it hard for the government to track their actions and hence, it is important for every organization to block any traffic from Tor services. The most popular Tor application is Tor Browser. When anyone accesses any website through the Tor Browser, it goes through proxy nodes, making it difficult for anyone to intercept. From a cybersecurity point of view, we can build a list of IP addresses of such nodes and eventually block them, or block Tor-based applications based on their signatures.
To test this scenario, go back to the tmNIDS prompt and enter 5
. The Tor attack will be executed on our Ubuntu Server running Suricata IDS.
Figure 1.32 – Choosing option 5 from the tmNIDS detection tester
To visualize the alert, navigate to the Security Alerts module of Wazuh and check for the relevant alerts shown in the following diagram.
Figure 1.33 – Suricata alert against Tor hidden traffic
Both have been detected by the Suricata ET ruleset. There are two rule descriptions:
Suricata: Alert - ET POLICY DNS Query for TOR Hidden Domain .onion Accessible
Via TOR
Suricata: Alert - ET MALWARE Cryptowall .onion
Proxy Domain
We have successfully tested the Tor .onion DNS response test and visualized the alerts on the Wazuh manager. In the next section, we will run all the tests at once and visualize the alerts.
Now, this is like a non-stop rifle. You basically launch all the tests at once. To start, type 11
under the tmNIDS tests prompt and monitor the events on the Wazuh manager.
Figure 1.34 – Suricata alerts against all the tmNIDS tests
As you can see, we have received alerts against all the tests listed in the tmNIDS detection tester. This shows that our Suricata IDS along with the ET ruleset are effective against attacks launched by the tmNIDS project.
In this chapter, we learned about Wazuh and its integration with the Suricata IDS to effectively detect anomalous traffic behavior. We started by exploring the Suricata IDS and its deployment method. We then covered the setup of Wazuh, the configuration of Suricata rules, and practical threat detection using DVWA. We then learned about testing Suricata rulesets using a tmNIDS tester.
In the next chapter, we will learn about the different malware detection capabilities of the Wazuh platform. We will also explore third-party integration for the purpose of detecting advanced malware files and signatures.
Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.
If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.
Please Note: Packt eBooks are non-returnable and non-refundable.
Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:
If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:
Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.
You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.
Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.
When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.
For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.