Build an Attack-and-Detect Lab with Suricata

Deploy a 3-VM isolated lab and catch live attacks with Suricata IDS.

Introduction

30 Second Summary

Every network faces constant probes from attackers. Security analysts need a safe space to practice both launching and detecting these attacks before defending real systems.

In this project, you will build an isolated 3-VM detection lab on your local machine. You'll deploy Suricata IDS as a network sensor, generate attack traffic from Kali Linux, and confirm that your sensor catches it.

What You'll Build

A fully isolated cybersecurity lab with three virtual machines: an attacker (Kali Linux), a network sensor (Ubuntu Server running Suricata IDS), and a vulnerable target (Metasploitable 2), all connected on a private network invisible to the internet.

By the end of this project, you'll have:

A VirtualBox host-only network (192.168.56.0/24) isolating all lab VMs from the internet.
An Ubuntu Server VM running Suricata IDS in monitoring mode with 49,000+ ET Open detection rules loaded.
Verified Suricata alerts in both fast.log and eve.json from an Nmap scan, proving end-to-end detection works.
Secret Mission: Write a threshold-based ICMP flood detection rule and validate it against simulated flood traffic from Kali.

Are there any prerequisites?

You need VirtualBox installed and a Kali Linux VM already configured and running. Your host machine should have at least 16 GB of RAM to run three VMs simultaneously.

Set Up the Ubuntu Server Sensor VM

Every detection lab needs a dedicated sensor that watches network traffic without participating in attacks. In a real Security Operations Center, the IDS sensor sits on its own appliance, passively monitoring a network tap or span port.

In this step, you will build that sensor from scratch. You will download Ubuntu Server 24.04.4 LTS, create a virtual machine in VirtualBox, install the operating system, and configure the VM's network adapters so it can join your isolated lab network.

In this step, get ready to:

Download the Ubuntu Server ISO and create the Suricata-Sensor VM.
Configure the VM's network adapters for lab isolation.
Boot the VM and verify network connectivity.

Download Ubuntu Server and create the VM

The sensor VM needs a lightweight operating system with no graphical desktop. Ubuntu Server is ideal because it runs headless and has excellent package support for Suricata.

Open your browser and navigate to the Ubuntu Server download page:
https://ubuntu.com/download/server
Download the file ubuntu-24.04.4-live-server-amd64.iso (approximately 3.2 GB). This may take several minutes depending on your connection.

Why Ubuntu Server instead of a desktop version?

Ubuntu Server ships without a graphical interface, which means it uses less RAM and CPU. Since this VM's only job is running Suricata and monitoring packets, a lean server image keeps your host machine's resources free for the other two VMs.

While the ISO downloads, create the virtual machine.

Open VirtualBox Manager.
Click New in the toolbar to start the Create Virtual Machine wizard.
In the Name field, type Suricata-Sensor.
In the ISO Image field, click the dropdown and select the ubuntu-24.04.4-live-server-amd64.iso file you downloaded.
VirtualBox should auto-detect the Type as Linux and Version as Ubuntu (64-bit). If it does not, set these manually.
Check the Skip Unattended Installation checkbox. You will walk through the installer manually.
Click Next to proceed to the Hardware page.

Set Base Memory to 2048 MB (2 GB).
Set Processors to 2 CPU cores.
Click Next to proceed to the Virtual Hard Disk page.

Select Create a Virtual Hard Disk Now.
Set the disk size to 25 GB.
Click Next to review the summary.
Click Finish to create the VM.

Your new Suricata-Sensor VM now appears in the VirtualBox Manager machine list.

What did you just configure?

You created a virtual machine with 2 GB of RAM, 2 CPU cores, and a 25 GB virtual disk. These specs give Suricata enough resources to process packets in real time while keeping the footprint small.

Now start the VM and install Ubuntu Server.

Select the Suricata-Sensor VM in the machine list and click Start.
The VM boots from the ISO. When the installer loads, select your language and keyboard layout.
On the installation type screen, choose the default Ubuntu Server option.
On the network screen, leave DHCP as the default. Select Done.
Skip the proxy screen by selecting Done.
Accept the default Ubuntu archive mirror by selecting Done.
On the storage screen, select Use an entire disk and confirm your 25 GB virtual disk is selected. Select Done.
Confirm the partition changes when prompted by selecting Continue.
On the Profile screen, enter a hostname (e.g., suricata-sensor), a username, and a password. Remember these credentials.
On the SSH screen, check Install OpenSSH server. Select Done.
On the optional snaps screen, do not select anything. Select Done to start the installation.
Wait for the installation to complete (5-15 minutes). When finished, select Reboot Now.

What happens during installation?

The Ubuntu installer partitions the virtual disk, installs the base system, configures the bootloader, and creates your user account with sudo privileges. OpenSSH is installed so you can remotely manage this VM later.

VM stuck on a black screen after reboot?

If the VM tries to boot from the ISO again instead of the installed system, power off the VM. In VirtualBox, open Settings for the VM, then click Storage. Select the ISO under the optical drive and click the disk icon to Remove Disk from Virtual Drive. Then start the VM again.

Help me fix my VM boot issue

After the reboot, log in with the username and password you set during installation.

Configure the network adapters

Right now the VM is using whatever network adapter VirtualBox assigned by default (usually NAT). You need to switch Adapter 1 to a Host-only Adapter so the sensor joins the isolated lab network. You will also keep a second NAT adapter temporarily for downloading packages.

Shut down the Ubuntu VM by running this command in the VM terminal:

sudo shutdown now

In VirtualBox Manager, select the Suricata-Sensor VM and click Settings.
Click Network in the left sidebar.
On the Adapter 1 tab, change the Attached to dropdown from NAT to Host-only Adapter.
Click the Adapter 2 tab.
Check Enable Network Adapter.
Set Attached to to NAT. This adapter provides temporary internet access for installing packages in the next step.
Click OK to save.

What is a Host-only Adapter?

A Host-only Adapter creates a private network visible only to VMs on your machine. VirtualBox assigns IPs in the 192.168.56.0/24 range by default. No traffic can reach the internet or your home LAN through this adapter.

This isolation is critical for running vulnerable VMs like Metasploitable 2 safely. Attacks stay contained within the virtual network.

No Host-only Adapter option in the dropdown?

VirtualBox needs a host-only network to exist before you can assign it to a VM. In VirtualBox Manager, go to File then Host Network Manager (or Tools then Network in newer versions). Click Create to add a new host-only network. Ensure DHCP is enabled. Then return to the VM's network settings and try again.

Help me create a host-only network

Boot the VM and verify connectivity

With both adapters configured, you can now boot the sensor and confirm it received the correct IP addresses.

Select the Suricata-Sensor VM and click Start.
Log in with your username and password.
Check your network interfaces and IP addresses by running:

ip addr show

You should see two interfaces (aside from lo). Look for an interface with an IP in the 192.168.56.x range. This is your host-only adapter.

How do I identify the host-only interface?

The output of ip addr show lists each interface with its name (like enp0s3 or enp0s8) and assigned IP. The interface showing 192.168.56.x is your host-only adapter. Write down this interface name. You will need it when configuring Suricata in a later step.

Note the host-only interface name (e.g., enp0s3 or enp0s8). Write it down somewhere accessible.
Confirm internet access on the NAT adapter by running:

ping -c 3 google.com

You should see three successful replies. This confirms the NAT adapter is working and you can download packages in the next step.

Ping fails with network unreachable?

If the NAT adapter is not getting an IP, it may not have activated automatically. Run sudo dhclient to request an IP on all interfaces. If pings still fail, shut down the VM, double-check that Adapter 2 is enabled and set to NAT in VirtualBox settings, then boot again.

Help me troubleshoot NAT networking

Your sensor VM is installed, networked, and ready. Next up, you will import the intentionally vulnerable Metasploitable 2 VM and connect all three machines to the same isolated network.

Import Metasploitable 2 and Isolate the Network

Your sensor VM is powered up and connected to the host-only network, but right now there's nothing for it to detect.

A network IDS needs both an attacker and a victim on the same wire to have any purpose. In this step, you'll import Metasploitable 2 as your intentionally vulnerable target, then connect all three VMs to the same isolated subnet.

In this step, get ready to:

Import Metasploitable 2 as your vulnerable target VM.
Connect all three VMs to the same host-only network.
Verify full connectivity across the isolated lab.

Download and import Metasploitable 2

Metasploitable 2 is a deliberately vulnerable Linux VM created by Rapid7. It ships with over 30 exploitable services, making it the perfect punching bag for your detection lab.

Open your browser and navigate to the Metasploitable 2 SourceForge page.
Download metasploitable-linux-2.0.0.zip (~865 MB). This may take a few minutes depending on your internet speed.
Once downloaded, right-click the ZIP file in File Explorer and select Extract All.
Choose a destination folder and click Extract. Inside the extracted folder, you'll see a .vmdk file. This is the virtual hard disk you'll attach to a new VM.

What is a VMDK file?

A VMDK (Virtual Machine Disk) is a file format for virtual hard drives. VirtualBox can use VMDK files directly, so no format conversion is needed.

Now create a new VM in VirtualBox that uses this existing disk.

In VirtualBox Manager, click New in the toolbar to start the Create Virtual Machine wizard.
Enter Metasploitable2 as the Name.
Set Type to Linux.
Set Version to Ubuntu (32-bit).
In the Hardware section, set Base Memory to 512 MB.
In the Hard Disk section, select Use an Existing Virtual Hard Disk File.
Click the folder icon, then click Add. Browse to the extracted folder and select the .vmdk file.
Click Choose, then click Finish to create the VM.

You should see Metasploitable2 listed in VirtualBox Manager alongside your other VMs.

Don't see the VMDK file when browsing?

Make sure you fully extracted the ZIP file first. The VMDK is inside the extracted folder, not inside the ZIP itself.

If the file browser filters by file type, make sure it shows all files or specifically .vmdk files.

Help me troubleshoot importing the Metasploitable 2 VMDK into VirtualBox.

Configure networking and boot Metasploitable 2

Before booting the VM, you need to connect it to the same isolated host-only network where your sensor is listening.

In VirtualBox Manager, right-click Metasploitable2 and select Settings.
Click Network in the left panel.
Under Adapter 1, change the Attached to dropdown from NAT to Host-only Adapter.
Click OK to save the settings.

Now boot the VM and verify it received a lab IP address.

Select Metasploitable2 in VirtualBox Manager and click Start.
Wait for the login prompt to appear. Log in with username msfadmin and password msfadmin.
Check the VM's IP address by running:

ifconfig

Look for the eth0 interface. You should see an IP address in the 192.168.56.x range (for example, 192.168.56.101). Note this IP down. You'll need it shortly.

Why these credentials?

Metasploitable 2 ships with default credentials (msfadmin:msfadmin) intentionally. It's designed to be broken into. In later projects you'll exploit these weak credentials as part of your attack chain.

Not seeing a 192.168.56.x address?

Make sure you set Adapter 1 to Host-only Adapter before booting. If you changed the setting while the VM was running, shut it down and start it again.

Also confirm that a host-only network exists in VirtualBox. Go to File > Host Network Manager and check that a network with the 192.168.56.0/24 range exists with DHCP enabled.

Help me troubleshoot my Metasploitable 2 network configuration in VirtualBox.

Connect Kali and verify full lab connectivity

The final piece is connecting your Kali Linux attacker VM to the same isolated subnet. Once all three VMs share the host-only network, your lab is fully isolated from the internet and ready for attack-and-detect exercises.

Shut down your Kali Linux VM if it's currently running.
In VirtualBox Manager, right-click your Kali VM and select Settings.
Click Network in the left panel.
Under Adapter 1, change the Attached to dropdown to Host-only Adapter.
Click OK to save, then start Kali.

What does host-only adapter do?

A host-only adapter creates a private virtual network that exists only between VMs on your machine. No traffic can reach the internet or your home LAN.

This is critical when running vulnerable VMs like Metasploitable 2. Without isolation, its 30+ exploitable services would be exposed to your real network.

Once Kali boots, open a terminal and confirm it can reach both other VMs.

Ping the Metasploitable 2 VM by running:

ping -c 4 [[METASPLOITABLE_IP="your Metasploitable 2 IP address"]]

Ping the Ubuntu Sensor VM by running:

ping -c 4 [[SENSOR_IP="your Ubuntu Sensor IP address"]]

Both commands should return successful replies with 0% packet loss. This confirms all three VMs are on the same 192.168.56.0/24 subnet and can communicate with each other.

Ping says destination host unreachable?

Double-check that all three VMs have their Adapter 1 set to Host-only Adapter (not NAT or Bridged). Each VM must be on the same adapter type to share the subnet.

If you changed network settings while a VM was running, shut it down completely and restart it. Network adapter changes only take effect on a fresh boot.

Help me troubleshoot connectivity between my VMs on the VirtualBox host-only network.

Your isolated lab network is complete. Three VMs. One private subnet. Zero internet access. Next up, you'll install Suricata on the sensor and turn it into a detection engine that watches every packet flowing between attacker and victim.

Install and Configure Suricata on the Sensor

Your three VMs are talking to each other on the same isolated subnet. The network is ready, but right now nobody is watching the traffic.

In this step, you will install Suricata IDS on your Ubuntu Sensor VM and configure it to monitor every packet that crosses the host-only network. By the end, Suricata will be running with over 49,000 detection rules loaded and ready to catch malicious activity.

In this step, get ready to:

Install Suricata and verify the installation.
Download the ET Open detection ruleset containing over 49,000 signatures.
Configure Suricata for your lab network and start it in IDS mode.

Install Suricata and download detection rules

Suricata needs internet access for the initial install and rule download. Your Sensor VM still has its temporary NAT adapter (Adapter 2) enabled from the previous step, so it can reach the package repositories.

On your Suricata-Sensor VM, install Suricata by running this command:

sudo apt update && sudo apt install suricata -y

What does this command do?

sudo apt update refreshes the list of available packages from Ubuntu's repositories.
sudo apt install suricata -y installs Suricata and its dependencies. The -y flag auto-confirms the installation prompt.

Verify the installation succeeded by running:

suricata --build-info | head -5

You should see output showing the Suricata version number and build details.

Command not found?

If you see a "command not found" error, the installation may have failed silently. Run sudo apt install suricata -y again and watch for error messages about missing dependencies or network connectivity.

Make sure your NAT adapter (Adapter 2) is still enabled. Without it, the VM cannot reach package repositories.

Help me troubleshoot why Suricata did not install on my Ubuntu Server VM

Download the Emerging Threats Open ruleset by running:

sudo suricata-update

What is suricata-update?

suricata-update is a bundled tool that downloads community detection rules from the ET Open project. These are free, community-maintained signatures that detect common attacks like port scans, exploit attempts, and malware callbacks.

After this completes, Suricata will have approximately 49,000 rules loaded and ready to match against network traffic.

You should see output ending with a summary of how many rules were loaded. This download may take a minute depending on your internet speed.

Rule download failing?

If suricata-update fails to connect, confirm your NAT adapter is still active. You can test connectivity by running ping 8.8.8.8 to check whether the VM can reach the internet.

Help me fix suricata-update failing to download rules on my Ubuntu VM

Configure Suricata for your lab network

Suricata's default configuration assumes a generic network setup. You need to tell it specifically which subnet to protect and which network interface to listen on.

Open the Suricata configuration file by running:

sudo nano /etc/suricata/suricata.yaml

Near the top of the file, find the HOME_NET line under the vars and address-groups section. The default value contains multiple private subnet ranges.
Replace the entire value with your lab subnet, so the line reads:

HOME_NET: "[192.168.56.0/24]"

Why narrow down HOME_NET?

HOME_NET tells Suricata which IP addresses are "yours." Detection rules use this variable to distinguish between internal traffic and external threats. Setting it to your exact lab subnet (192.168.56.0/24) ensures rules like "ET SCAN" fire correctly when scans target your VMs.

If HOME_NET is too broad, some rules may not trigger because both source and destination appear "internal."

Scroll down to the af-packet section. Find the interface line beneath it.
Change the interface value to your host-only adapter name that you identified in the previous step (e.g., enp0s3). The line should look like:

  - interface: enp0s3

Confirm your interface name

If you are not sure which interface is your host-only adapter, press Ctrl+Z to suspend nano, run ip addr show, and look for the interface with a 192.168.56.x address. Then type fg to return to nano.

Scroll further down and look for the eve-log section. Confirm it shows enabled: yes. This is enabled by default, so you should not need to change anything here.
Save the file by pressing Ctrl+O, then Enter, then Ctrl+X to exit nano.

Validate your configuration has no syntax errors by running:

sudo suricata -T -c /etc/suricata/suricata.yaml

You should see a message indicating the configuration was successfully loaded with no errors.

Configuration validation failed?

YAML is sensitive to indentation. The most common errors are extra spaces, missing quotes around the HOME_NET value, or a typo in the interface name. Re-open the file with sudo nano /etc/suricata/suricata.yaml and double-check both edits.

Make sure HOME_NET has quotes around the brackets: "[192.168.56.0/24]". Also confirm the interface value has no trailing spaces.

Help me fix a Suricata configuration validation error in suricata.yaml

Isolate the sensor and start monitoring

With the configuration validated and rules downloaded, the sensor no longer needs internet access. Disabling the NAT adapter fully isolates it on the host-only network, matching how a production IDS sensor is deployed.

Shut down the Suricata-Sensor VM by running:

sudo shutdown now

In VirtualBox, right-click the Suricata-Sensor VM and select Settings.
Go to the Network tab.
Click the Adapter 2 tab.
Uncheck Enable Network Adapter to disable the NAT connection.
Click OK to save.

Why disable the NAT adapter?

In a real enterprise environment, an IDS sensor sits on a dedicated monitoring port with no route to the internet. This prevents attackers from using the sensor as a pivot point into the wider network. Disabling NAT replicates that architecture in your lab.

Start the Suricata-Sensor VM again from VirtualBox.
Log in with your username and password.
Start Suricata in IDS mode on your host-only interface by running:

sudo suricata -c /etc/suricata/suricata.yaml -i enp0s3

What does this command do?

-c /etc/suricata/suricata.yaml tells Suricata to use your edited configuration file.
-i enp0s3 specifies which network interface to listen on. Replace enp0s3 with your actual interface name if it differs.
Suricata is now running in IDS mode. It passively monitors all traffic on the host-only network and writes alerts when detection rules match.

Leave this terminal open and Suricata running. You will use a second terminal session on this VM in the next step to read the alert logs.

Seeing a permission or interface error?

If Suricata reports it cannot open the interface, double-check the interface name matches what ip addr show reports. The name must be character-for-character identical.

If you see a "permission denied" error, make sure you included sudo at the start of the command. Suricata needs root privileges to capture raw network packets.

Help me fix Suricata failing to start on my network interface

Your sensor is now live. Suricata is watching every packet on the 192.168.56.0/24 network with tens of thousands of detection rules. Next, you will generate attack traffic from Kali and confirm Suricata catches it.

Generate Attack Traffic and Validate Detection

Your detection lab is fully wired. Three VMs share the same isolated network, and Suricata is actively monitoring every packet that crosses the wire.

Now comes the moment of truth. You will generate real reconnaissance traffic from your attacker VM and confirm that Suricata catches it. Then you will write your own custom detection rule from scratch and prove it fires.

In this step, get ready to:

Run an Nmap SYN scan from Kali against Metasploitable 2.
Confirm Suricata alerts in fast.log and eve.json.
Write and validate a custom ICMP detection rule.

Run an Nmap SYN scan from Kali

An Nmap SYN scan probes every port on a target by sending TCP SYN packets. It is one of the most common reconnaissance techniques attackers use. Suricata's ET Open ruleset includes signatures specifically designed to detect this kind of scanning activity.

Switch to your Kali Linux VM.
Run an Nmap SYN scan with version detection against Metasploitable 2 by running this command:

nmap -sS -sV [[METASPLOITABLE_IP="your Metasploitable 2 IP address, e.g. 192.168.56.101"]]

What does this command do?

-sS performs a SYN scan (half-open scan). It sends SYN packets without completing the TCP handshake, which is fast and stealthy.
-sV probes open ports to determine the service and version running on each one.
Together, these flags generate significant network traffic that traverses the host-only network where Suricata is listening.

The scan takes 30-60 seconds to complete. You should see a table of open ports and services on Metasploitable 2 (FTP, SSH, HTTP, MySQL, and many more).

Scan timing out or no results?

Confirm your Kali VM is on the host-only network by running ip addr show and checking for a 192.168.56.x address.
Verify Metasploitable 2 is powered on and reachable by pinging its IP first.
Make sure you are using sudo or running as root. SYN scans require elevated privileges on Kali.

Help me troubleshoot my Nmap scan against Metasploitable 2 on a VirtualBox host-only network.

Examine Suricata alerts in fast.log and eve.json

The Nmap scan just sent hundreds of packets across the host-only network. Suricata should have matched several of those packets against its ET Open signatures and logged alerts.

Switch to your Suricata-Sensor VM.
Open a second terminal session (Suricata is still running in the first one).
Check fast.log for alerts by running this command:

sudo cat /var/log/suricata/fast.log

You should see several lines containing "ET SCAN" entries. These are alerts triggered by the Nmap activity you just generated from Kali.

What is fast.log?

fast.log is Suricata's human-readable alert file. Each line shows a timestamp, the alert message, the source and destination IPs, and the protocol. It is useful for quick checks but lacks the structured detail needed for automated analysis.

Now examine the structured JSON output by running this command:

sudo cat /var/log/suricata/eve.json | jq 'select(.event_type=="alert")' | head -50

What is eve.json?

eve.json is Suricata's structured log output in JSON format. Every event (alert, flow, DNS query, HTTP request) gets its own JSON object on a separate line. This format integrates directly with SIEMs and log analysis tools.

The jq command filters for alert events only, and head -50 limits the output to the first 50 lines so it stays readable.

You should see JSON objects with fields like alert.signature, src_ip, dest_ip, and proto. The signature field shows which ET Open rule fired.

If jq is not installed

The jq tool is not installed by default on Ubuntu Server. If you see a "command not found" error, you can temporarily re-enable the NAT adapter in VirtualBox (Settings > Network > Adapter 2 > check "Enable"), then run:

sudo apt install jq -y

Disable the NAT adapter again after installing. Alternatively, use grep as a quick substitute:

sudo grep '"event_type":"alert"' /var/log/suricata/eve.json | head -50

fast.log is empty?

Verify Suricata is still running in your first terminal. If the process exited, restart it with the same command from Step 3.
Confirm HOME_NET in /etc/suricata/suricata.yaml is set to "[192.168.56.0/24]". ET SCAN rules only fire when the target is inside HOME_NET.
Make sure the af-packet interface in suricata.yaml matches your host-only adapter name (check with ip addr show).

Help me figure out why Suricata is not generating alerts from my Nmap scan.

Write a custom ICMP detection rule

The ET Open rules detected your Nmap scan automatically. Now you will write your own rule from scratch to understand how Suricata detection logic works at the rule level.

You will create a rule that alerts whenever an ICMP echo request (a ping) reaches any host on your lab network. This is a simple but powerful exercise because it demonstrates the exact syntax used in production IDS deployments.

On your Suricata-Sensor VM (in the second terminal), open the local rules file by running:

sudo nano /var/lib/suricata/rules/local.rules

Add this custom detection rule to the file:

alert icmp any any -> $HOME_NET any (msg:"LAB - ICMP Ping Detected"; itype:8; sid:10000001; rev:1;)

What does this rule do?

alert tells Suricata to generate an alert (not drop the packet).
icmp any any -> $HOME_NET any matches ICMP traffic from any source going to any host in your lab network.
msg:"LAB - ICMP Ping Detected" is the human-readable alert message that appears in your logs.
itype:8 matches only ICMP type 8 (echo request). This means replies (type 0) will not trigger the rule.
sid:10000001 is a unique signature ID. Custom rules use IDs above 10000000 to avoid conflicts with ET Open rules.
rev:1 is the rule revision number, starting at 1.

Save the file by pressing Ctrl+O then Enter, and exit nano with Ctrl+X.
Validate that your configuration is still correct by running:

sudo suricata -T -c /etc/suricata/suricata.yaml

You should see a message indicating the configuration is valid. If there are errors, double check your rule syntax in local.rules.

Now stop the running Suricata instance. Switch to the terminal where Suricata is running in the foreground and press Ctrl+C to stop it.
Restart Suricata in IDS mode so it loads your new rule by running:

sudo suricata -c /etc/suricata/suricata.yaml -i [[INTERFACE="your host-only interface name, e.g. enp0s3"]]

Switch to your Kali VM and ping the Suricata-Sensor IP to trigger your custom rule:

ping -c 4 [[SENSOR_IP="your Suricata-Sensor IP address, e.g. 192.168.56.103"]]

Switch back to your Suricata-Sensor VM (the second terminal) and check fast.log for your custom alert:

sudo tail /var/log/suricata/fast.log

You should see new entries containing "LAB - ICMP Ping Detected" with the source IP matching your Kali VM. This confirms your custom rule fired successfully.

Custom rule not firing?

Make sure you restarted Suricata after adding the rule. Rules only load at startup.
Run the validate command again (sudo suricata -T -c /etc/suricata/suricata.yaml) and look for errors referencing local.rules.
Verify that /var/lib/suricata/rules/local.rules is referenced in your suricata.yaml under the rule-files section. If not, add it.

Help me troubleshoot why my custom Suricata rule is not generating alerts.

✔️ Awesome, I've got everything!

Great. Double check you see "LAB - ICMP Ping Detected" in your fast.log output. Your custom rule is working.

ⓧ I'd like to double check the full code

Here is what your /var/lib/suricata/rules/local.rules file should contain:

alert icmp any any -> $HOME_NET any (msg:"LAB - ICMP Ping Detected"; itype:8; sid:10000001; rev:1;)

Secret mission

Detect an ICMP Flood Attack

Your basic ICMP rule fires on every single ping. In a real SOC, that would drown analysts in noise. Can you write a threshold-based rule that only fires when ICMP traffic exceeds a defined rate, simulating the flood detection logic used in production IDS deployments?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally on your machine, so there are no ongoing costs.

Resources you used:

Suricata-Sensor VM (Ubuntu Server 24.04.4 LTS, ~25 GB disk).
Metasploitable2 VM (~8 GB disk).
VirtualBox Host-only network adapter (192.168.56.0/24).
Kali Linux VM network adapter change (switched from NAT to Host-only).

Keep everything running

No action needed. Choose this if you're still actively building or plan to continue to the next project in this series (Project 2 builds directly on this lab).

Your VMs will remain in their current state, ready to boot at any time.
The host-only network persists between VirtualBox sessions.
Your Kali VM's network adapter remains set to Host-only. If you need internet access on Kali for other work, switch its adapter back to NAT in Settings > Network > Adapter 1.

Pause - I'll come back to this later

Shut down running VMs and save their state to free up system memory. You can resume instantly later.

In VirtualBox, right-click the Suricata-Sensor VM and select Close > Save State.
Right-click the Metasploitable2 VM and select Close > Save State.
Right-click your Kali Linux VM and select Close > Save State.
To resume, double-click any saved VM and it will restore to exactly where you left off.

Delete - I don't want to use this again

Remove all project resources and start fresh. This frees up approximately 33 GB of disk space.

In VirtualBox, right-click the Suricata-Sensor VM and select Remove. Choose Delete all files to remove the virtual disk.
Right-click the Metasploitable2 VM and select Remove. Choose Delete all files.
Remove the host-only network: click File in the VirtualBox menu bar, then select Host Network Manager. Select the host-only adapter and click Remove.
Switch your Kali VM's network adapter back to NAT: right-click the Kali VM, select Settings > Network > Adapter 1, and change Attached to back to NAT.
Delete the extracted Metasploitable 2 VMDK file from wherever you saved it on your host machine.
Delete the Ubuntu Server ISO file (ubuntu-24.04.4-live-server-amd64.iso) from your Downloads folder.

Nice Work!

You just built a fully isolated cybersecurity detection lab from scratch. You have a working Suricata IDS monitoring all traffic between an attacker and a vulnerable target, with real alerts proving end-to-end detection.

You've learned how to:

Build a 3-VM isolated detection lab using VirtualBox host-only networking to keep attacker, sensor, and victim machines on a private subnet with no internet access.
Install and configure Suricata IDS on a dedicated Ubuntu Server sensor with 49,000+ ET Open detection rules loaded and EVE JSON logging enabled.
Generate Nmap reconnaissance traffic from Kali Linux and validate detection alerts in both fast.log and eve.json, plus write and test a custom ICMP detection rule.
Secret Mission: Authored a threshold-based ICMP flood detection rule and validated it against simulated flood traffic from Kali.

Ready to quiz yourself?