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.

Types of IDS

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:

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:

• Network traffic monitoring: Suricata analyzes real-time network traffic for threats and anomalies. Organizations need to smartly deploy Suricata at various points in the network to analyze both incoming and outgoing traffic. This use case can help us detect malware, Distributed Denial of Service (DDoS) attacks, port scans, reconnaissance data exfiltration, and so on.
• Signature and anomaly detection: Suricata detects known attack patterns or signatures by checking network traffic against a library of rules and patterns that have already been set up. In this chapter, we will use the Suricata ruleset created by the Emerging Threats (ET) community. This ruleset can help us detect known malware, viruses, web-based attacks (SQL Injection, cross-site scripting attacks, etc.), known network attack signatures, and so on.
• Protocol analysis: Suricata can deeply examine many different network technologies, such as HTTP, DNS, and TLS. This helps us to discover anomalous behaviors of protocols, such as unusual HTTP requests, DNS tunneling, and unexpected SSL/TLS handshakes.
• Logging and alerting: Suricata keeps logs and sends out alerts when it detects possible threats. These alerts can be used to get security teams to act right away, or they can be added to security information and event management (SIEM) systems so that they can be analyzed further and linked to other security events. Wazuh, Splunk, Elastic, and all the popular SIEM solutions support integration with the Suricata IDS.

Let’s learn about the deployment methods of the Suricata IDS.

How organizations use Suricata as an IDS

There are several ways to deploy the Suricata IDS and some of the important and popular deployment methods are explained in the following:

• Inline deployment at network perimeter: Suricata sits between the external internet connection and the internal network, actively monitoring and scrutinizing network traffic in real time. It can be deployed as a physical appliance or as a virtual machine (VM). The network traffic passes through Suricata, which analyzes the packets and acts based on the criteria that have been defined.

Figure 1.2 – Inline deployment at network perimeter

• Internal network monitoring: Suricata sensors are strategically located within the internal network in order to capture network traffic between segments or departments. These sensors could be physical or virtual devices. They analyze the captured traffic and transmit alerts or records to a centralized management system for additional analysis and response. As you can see in the following diagram, the sensors will export the data to a centralized server.

Figure 1.3 – Internal network monitoring

• Cloud environment monitoring: Suricata can be deployed as virtual appliances or containers in AWS and Azure cloud environments. It is installed within the cloud infrastructure and monitors network traffic within virtual networks and between cloud resources. The captured traffic is transmitted to a central analysis system for response detection.

Figure 1.4 – Cloud security monitoring (AWS)

• Network tap deployment: Suricata is used in conjunction with network taps or port mirroring. Taps are strategically located at key network nodes to capture a copy of network traffic, which is then sent to Suricata for analysis. This deployment ensures accurate and comprehensive network activity visibility.

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:

• Core components of Wazuh
• Wazuh deployment options
• Wazuh core features
• Wazuh modules
• Wazuh administration
• Installing the Wazuh server
• Installing the Wazuh agent
• Installing Suricata on Ubuntu Server
• Setting up Windows Server with Suricata

The core components of Wazuh

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.

The Wazuh server

This central component is also used to manage the agents and analyze the data received from them:

• It collects logs from several sources such as hosts, network devices, firewalls, proxy servers, and syslog servers.
• Normalizes and standardizes collected logs and events into a uniform format for analysis and correlation. It utilizes the Wazuh decoder to parse logs to display the logs in a uniform format.
• The Wazuh server is capable of integrating logs from several data sources such as syslog, Windows event logs, Windows Sysmon, Docker logs, Palo Alto firewall logs, and Check Point firewall logs.
• The Wazuh server also provides an API for interaction, allowing remote servers or systems to interact and query, for example, the number of active Wazuh agents, vulnerability information, Wazuh rule verification, and so on.

The Wazuh indexer

It is responsible for indexing and storing alerts generated by the Wazuh server:

• The Wazuh indexer stores alerts sent by the Wazuh server and acts as a primary repository
• It’s made to handle a lot of security alerts, making sure that storage and indexing work well as the system grows

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.

• The Wazuh indexer provides robust search features that make it possible to quickly and thoroughly search through saved alerts using particular criteria or patterns
• The Wazuh indexer uses four index patterns to store the data:
  • wazuh-alerts-*: This is the index pattern for alerts generated by the Wazuh server
  • wazuharchives-*: This is the index pattern for all events sent to the Wazuh server
  • wazuh-monitoring-*: This pattern is for monitoring the status of Wazuh agents
  • wazuh-statistics-*: This is used for statistical information about the Wazuh server

The Wazuh dashboard

The 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

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:

• Servers: Putting Wazuh on dedicated servers gives you more power and lets you make changes that work with your system. You can utilize on-premises servers or cloud instances. Remember, you need multiple server instances to deploy Wazuh in cluster mode.
• VM image: Wazuh gives you an Open Virtual Appliance (OVA) formatted VM image that is already set up. This can be imported straight into VirtualBox or any other virtualization software that works with OVA files. This is good for a lab purpose only. You can use this deployment option to test all the scenarios mentioned in this book. Download the OVA file from here: https://documentation.wazuh.com/current/deployment-options/virtual-machine/virtual-machine.html.
• Docker container: Docker is an open platform for building and running applications inside an isolated software container. Docker containers are the best way to quickly and easily set up Wazuh components in independent environments. This option is commonly used for testing, development, or situations where setup and takedown need to be done quickly. You can download the Docker image from the link here: https://hub.docker.com/u/wazuh.
• Deployment on Kubernetes: Kubernetes is an open-source container orchestration platform. You can opt for this method when managing large-scale deployment with multiple containers. This method gives you higher scalability, automated deployment, and resource optimization. You can check out the Wazuh Kubernetes repository at the following link: https://github.com/wazuh/wazuh-kubernetes.

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 modules

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:

• Security information management: This consists of the Security Events and Integrity Monitoring module. Security alerts will be triggered and displayed based on predefined Wazuh rules for identified security events. The Integrity Monitoring module monitors any unauthorized changes to critical system files and directories.
• Threat detection and response: By default, this section has two modules: Vulnerabilities and MITRE ATT&CK®. However, you can also add Osquery, VirusTotal, and more. The Vulnerabilities module identifies, and tracks known vulnerabilities in the systems or software. The MITRE ATT&CK module maps detected threats or incidents to the MITRE ATT&CK framework.

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.

• Auditing and Policy Monitoring: This section consists of three modules: the Policy Monitoring module, the System Auditing module, and the Security configuration assessment module.
  • The Policy Monitoring module monitors the systems to make sure security policies are properly established.
  • The System Auditing module tracks and audits use activities including use login attempts, file access, and privilege changes in the endpoint.
  • The Security configuration assessment module is a very popular feature that checks system configurations against best practices or predefined security standards. Wazuh utilizes the CIS benchmark for most of the security configuration checks.

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.

• Regulatory Compliance: This section consists of multiple modules including PCI DSS compliance, GDPR, HIPPA, NIST 800-53, and TSC modules. Wazuh rules are created and tagged with some of these compliances. When any of those rules get triggered, we see the alerts. This is how we can align security compliances with Wazuh.

Next, let’s talk about the Wazuh Administration, where we will discuss some core features of the Wazuh manager.

Wazuh Administration

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

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.

Rules

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.

CDB lists

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.

Groups

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.

Configuration

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.

Installing the Wazuh server

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.

For a production environment

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.

For a lab environment

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:

1. Download the OVA file: Start by downloading the Wazuh OVA file from the official Wazuh website: https://documentation.wazuh.com/current/deployment-options/virtual-machine/virtual-machine.html.
2. Import the OVA file: Use your favorite virtualization platform (e.g., VMware Workstation, VirtualBox, etc.) and import the downloaded OVA file.
3. Configure VM settings: Before powering on the VM, adjust the VM settings as needed:
   • CPU cores: 4
   • RAM: 8 GB
   • Storage: 50 GB
4. Access the Wazuh web interface: You can start the VM. Next, open the Web browser using the VM IP address and enter the default username and password as shown in the diagram.

Figure 1.8 – Accessing the Wazuh web interface

You need to enter the following:

• Username: admin
• Password: admin

Installing Wazuh agent

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.

Installing a Wazuh agent on Ubuntu Server

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:

1. Select an OS, version, and architecture: As mentioned in the following diagram, navigate to the LINUX box and choose DEB amd64 for AMD architecture or DEB aarch64 for ARM architecture.

Figure 1.9 – Deploying a new agent

2. Enter the server address and other optional settings: Enter the Wazuh server address and agent name and select the group. Please make sure your desired agent group is created before you add any 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 server
• ubu-serv: This indicates the name of the Wazuh agent
• default: It represents the Wazuh agent group

3. Download the package and enable the service: Copy the curl 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:

• ID: 006
• IP address: 192.168.29.172
• Group(s): default
• Operating system: Ubuntu 22.04
• Status: active

Now, let’s install the Wazuh agent on Windows Server. The process will be the same for the Windows desktop, too.

Installing a Wazuh agent on Windows Server

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:

1. Select an OS, version, and architecture: As shown in the following diagram, navigate to the WINDOWS box, choose the MSI 32/64 bits package, and then enter the Wazuh server IP address.

Figure 1.13 – Selecting the Windows package for the Wazuh agent

2. Enter the server address and other optional settings: Enter the Wazuh server address and agent name and select the group. Please make sure your desired agent group is created before you add any new agent.

Figure 1.14 – Entering the server address and optional settings

3. Download the package and enable the service: Copy the PowerShell command to download the Wazuh module and start the Wazuh agent service as shown in the following diagram. The following command needs to be entered on a Windows PowerShell terminal.

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:

• ID: 004
• IP address: 192.168.29.77
• Group(s): default
• Operating system: Microsoft Windows Server 2019 Datacenter Evaluation 10.0.17763.737
• Status: active

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.

Installing Suricata 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.

Prerequisites

To install Suricata IDS on Ubuntu Server, the prerequisites are as follows:

• You will need to have Ubuntu Server installed (version 20.04 or higher)
• Sudo Privileges

Installation

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:

1. Install Suricata: Log in to the terminal on Ubuntu Server and install the Suricata IDS package with the following commands:

   sudo add-apt-repository ppa:oisf/suricata-stable
   sudo apt-get update
   sudo apt-get install suricata –y

2. Install the ET ruleset: Install the ET ruleset. The ET Suricata ruleset comprises a compilation of rules created for the Suricata IDS. We are required to store all the rules in the /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.

3. Modify the Suricata configuration: In order to fine-tune Suricata configuration, it is required to change the default setting under the Suricata configuration file located at /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.
4. Restart the Suricata service: In order for configuration changes to take effect, we are required to restart the Suricata service using the following command:

   $ sudo systemctl restart suricata

5. Integrate with Wazuh: In order for the Wazuh agent to monitor and collect Suricata traffic, we need to specify the Suricata log file location under the Wazuh agent 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>

6. Restart the Wazuh agent service: For the current changes to take effect, you need to restart the Wazuh agent services using the following command:

   $ 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 rule syntax

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 probe attack and detection

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:

• Lab setup
• Attack simulation
• Visualize on the Wazuh manager

Lab setup

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

Attack simulation

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.

Visualize on the Wazuh dashboard

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:

• Lab setup
• Setting up the victim server with DVWA
• Test an SQL Injection attack
• Test a reflected XSS attack

Lab setup

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:

• The attacker machine is Kali Linux, but you can use any other machine.
• The DVWA application has been installed on a Debian-based server.
• Ubuntu Server deployed in promiscuous mode (a network setting) and running a Suricata IDS and Wazuh agent. Promiscuous mode allows the network adapter to intercept and read all the network traffic that it receives.
• The Wazuh server is deployed as a VM.

Setting up the victim server with DVWA

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:

1. Let’s first install all of them with the following command:

   sudo apt -y install apache2 mariadb-server php php-mysqli php-gd libapache2-mod-php

2. Next, prepare the database:
   1. We need to run the initial database setup:

      sudo mysql_secure_installation

   2. Type 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';

3. Next, install the DVWA application. The DVWA source code is available on GitHub. You can enter the following command under /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/*

4. Let’s configure the PHP file. For this, go to the /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

5. Update the database information under the config.inc.php file. Change the db_user to dvwa and db_password to password.
6. Start the mysql service:

   systemctl start mysql or service mysql start

7. Update the php file and go to /etc/php/x.x/apache2/ to open the php.ini file.
8. Search for allow_url_include and set to On.
9. Launch DVWA.
10. Open DVWA with http://localhost/DVWA/setup.php and then reset the database.
11. Now, log in to DVWA with the default credentials:

    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.

Test an SQL Injection attack

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 name
• data.alert.category Web Application Attack: This shows the category of the rule as specified in the Suricata ET ruleset
• Data.alert.metadata.tag: SQL_Injection: This shows the metadata of the Suricata ET ruleset for web application attacks

As 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 attempted
• data.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.

Test a reflected XSS attack

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 browser
• Alert("Hello"): This is a function that tells the browser to display a pop-up box with the Hello text when the script is executed

You 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

Let’s break this down:

• 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:

• Lab setup
• Installing tmNIDS on Ubuntu Server
• Testing for a malicious User-Agent
• Testing for a Tor connection
• Test everything at once

Lab setup

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

Installing tmNIDS on Ubuntu Server

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.

Testing for a malicious User-Agent

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 signature
• data.alert.category : Not Suspicious Traffic: This represents the category of the ET ruleset category
• data.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.

Testing for Tor connection

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.

Testing everything at once

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.