IDPS System with Snort / Suricata

Summary

This documentation descries the setup, configuration and testing of an Intrusion Detecetion Prevention System (IDPS) used in a unviersity project.

The system was built in VMware and uses open-source tools such as Snort, Suricata, iptables and NFQUEUE. The main goal was to detect and block malicious traffic in a controlled lab environment.

The project follows the same structure for each attack:

• No IDS / IPS: attack runs without protection
• IDS mode: attack is detected and logged
• IPS mode: attack is detected and blocked

The main attacks tested were:

• SSH brute force
• TCP SYN port scanning
• Spoofed ICMP ping flood
• SQL injection
• HTTP flood

Requirements

Virtual Machines

The lab uses three main virtual machines:

• Attacker VM (Kali Linux)
• IDPS VM (Ubuntu Server)
• Victim VM (Ubuntu Server)

Tools

• VMware Workstation Pro
• Snort
• Suricata
• iptables
• NFQUEUE
• Apache2
• PHP
• SQLite
• Nmap
• hping3
• wrk
• Postfix
• tcpdump

Network Setup

The lab lab uses VMWare as its virtualization platform, for easy of use and more customization options. It also allows snapshots and each member to work independently on the VMs. The setup uses two isolated internal networks: one for the victim and one for the attacker. The virtual networks were created in the VMware Virtual Network Editor, whereby the internal networks were mapped to host-only networks and the external one for internet access was a NAT network, sharing the IP of the host machine.

Topology

Note: In the real topology, vmbr0 corresponds to ens33, vmbr1 to ens37 and vmbr2 to ens38.

Network Plan

Network	Subnet	Purpose
VictimNet	192.168.10.0/24	Victim side
AttackerNet	192.168.20.0/24	Attacker side

IP Plan

Machine	IP Address	Role
Victim	192.168.10.10	Target machine
Attacker	192.168.20.10	Attack machine
IDPS victim side	192.168.10.254	Gateway for VictimNet
IDPS attacker side	192.168.20.254	Gateway for AttackerNet

The IDPS machine acts as the gateway between both networks. This forces attacker-to-victim traffic through the IDPS, which allows packet inspection, attack detection and blocking.

IP Forwarding

IP forwarding must be enabled on the IDPS machine:

sudo sysctl -w net.ipv4.ip_forward=1

To make it permanent:

sudo nano /etc/sysctl.conf

Add or uncomment:

net.ipv4.ip_forward=1

IDS and IPS Concept

IDS Mode

IDS mode only detects and logs suspicious traffic.

Traffic passes normally
IDS observes traffic
Alert is generated
Attack still reaches victim

IPS Mode

IPS mode runs inline. This means the packet must pass through the security tool before it reaches the victim.

Packet arrives
iptables sends it to NFQUEUE
Snort / Suricata inspects it
Packet is accepted or dropped

This is why drop rules only work when the tool is actually inline through NFQUEUE.

Attack 1: SSH Brute Force

Description

The SSH brute force attack was used to test login attack detection.

A weak test user was created on the victim. The attacker used Hydra to try passwords against SSH. The project progress presentation describes this as a weak user setup on the victim with Hydra used from the attacker. :contentReference[oaicite:3]{index=3}

Attack Command

hydra -l testuser -P customlist.txt ssh://192.168.10.10

No IDPS

Without IDPS:

• Attack runs normally
• No real-time IDPS alert
• Logs only exist on the victim
• Manual log checking is needed

Victim log:

/var/log/auth.log

Snort IDS

Snort was used to detect SSH connection attempts.

Example rule:

alert tcp any any -> 192.168.10.10 22
(msg:"SSH Attempt"; flags:S; sid:1000004;)

Result:

• Snort detects SSH attempts
• Alerts are generated
• Attack still continues

Snort IPS

In IPS mode, Snort blocks repeated SSH attempts.

NFQUEUE example:

iptables -I FORWARD -p tcp --dport 22 -j NFQUEUE
iptables -I FORWARD -p tcp --sport 22 -j NFQUEUE

Blocking rule:

drop tcp any any -> 192.168.10.10 22
(msg:"SSH Brute Force BLOCKED";
threshold:type both, track by_src, count 5, seconds 60;
sid:1000002;)

Result:

• Brute force is detected
• Repeated attempts are blocked
• Alerts are logged

Screenshot placement: Add one screenshot of Hydra running and one Snort alert screenshot.

Attack 2: TCP SYN Port Scanning

Description

Port scanning was used to simulate reconnaissance. An attacker normally scans ports before choosing the next attack method. The port scanning presentation described this as a TCP SYN port scan using Nmap, detected and prevented with Snort. :contentReference[oaicite:4]{index=4}

Victim Services

The victim had multiple open services to make the scan realistic:

Port	Service
21	FTP
22	SSH
80	HTTP / Apache
8000	Demo HTTP service
9000	Demo TCP service

These services made the Nmap result more meaningful and helped show how IPS can hide or block selected scan traffic. :contentReference[oaicite:5]{index=5}

Attack Command

sudo nmap -sS 192.168.10.10

No IDPS

Result:

• Nmap discovers open ports
• Services are visible
• No blocking is applied

Snort IDS

alert tcp 192.168.20.0/24 any -> 192.168.10.10 any
(msg:"NMAP SYN Port Scan Detected"; flags:S;
threshold:type both, track by_src, count 10, seconds 5;
sid:1000005; rev:1;)

Result:

• Multiple SYN packets are detected
• Alert is logged under /var/log/snort/alert
• Scan still reaches victim

Snort IPS

drop tcp 192.168.20.0/24 any -> 192.168.10.10 any
(msg:"PORT SCAN BLOCKED"; flags:S;
threshold:type both, track by_src, count 20, seconds 5;
sid:1000011; rev:1;)

NFQUEUE:

iptables -I FORWARD 1 -s 192.168.20.0/24 -d 192.168.10.0/24 -p tcp -j NFQUEUE --queue-num 0

Run Snort inline:

snort -Q --daq nfq --daq-var queue=0 -c /etc/snort/snort.conf -A console

Result:

• Scan is detected
• Matching packets are dropped
• Nmap receives less useful information

Screenshot placement: Add one Nmap result without IPS and one Snort IPS console/log screenshot.

Email Notification System

Email notifications were added so the administrator does not need to watch the Snort terminal all the time.

The email presentation describes the flow as Snort live output being read by a wrapper script, then sent to the administrator by email. :contentReference[oaicite:6]{index=6}

Setup

• Installed Postfix and mail tools
• Configured Gmail SMTP
• Created a Gmail App Password
• Used the app password for authentication

Flow

Snort live output
→ wrapper script reads alert messages
→ email is sent to administrator

Result:

• Alerts can be sent by email
• Admin gets faster visibility
• Useful for monitoring during attacks

Screenshot placement: Add one screenshot of a received alert email.

Attack 3: Spoofed ICMP Ping Flood

Description

The ping flood attack sends a large number of ICMP Echo Requests to the victim. In this case, the attacker also randomizes the source IP addresses.

This makes source-based detection less reliable because the traffic does not look like it comes from only one source. The final ping flood presentation used hping3 with spoofed source IPs and compared No IDPS, Snort IDS and Snort IPS. :contentReference[oaicite:7]{index=7}

Attack Command

hping3 -1 --flood -V --rand-source 192.168.10.10

Monitoring

On the victim:

sudo tcpdump -ni any 'icmp and dst host 192.168.10.10'

From the gateway:

ping 192.168.10.10

No IDPS

Result:

• Victim receives many ICMP packets
• Source IPs are random/spoofed
• Gateway ping becomes less stable
• No alerts
• No blocking

Screenshot placement: Add tcpdump screenshot showing random source IPs.

Snort IDS

Because the attacker spoofs source IPs, the rule tracks by destination.

alert icmp any any -> 192.168.10.10 any
(msg:"SPOOFED ICMP PING FLOOD DETECTED";
itype:8; detection_filter:track by_dst, count 100, seconds 1;
sid:1000501; rev:1;)

Result:

• Flood is detected
• Alert is logged
• Flood still reaches victim

Snort IPS

drop icmp any any -> 192.168.10.10 any
(msg:"SPOOFED ICMP PING FLOOD BLOCKED";
itype:8; detection_filter:track by_dst, count 100, seconds 1;
sid:1000502; rev:1;)

NFQUEUE:

sudo iptables -F FORWARD
sudo iptables -I FORWARD 1 -i ens38 -o ens37 -p icmp -j NFQUEUE --queue-num 0

Run Snort inline:

sudo snort -Q --daq nfq --daq-var queue=0 -c /etc/snort/snort.conf -A console

Result:

• Flood is detected
• Matching ICMP packets are dropped
• Less traffic reaches the victim
• Gateway ping becomes more stable

Screenshot placement: Add Snort IPS log/drop screenshot and one improved gateway ping screenshot.

Attack 4: SQL Injection

Description

For this attack, a simple vulnerable PHP product lookup website was created on the victim. It was hosted on Apache and used SQLite as the database.

The SQL injection presentation describes the goal as simulating an application-layer attack against a vulnerable page, with detection and blocking done using Suricata. :contentReference[oaicite:8]{index=8}

Website Setup

The victim hosted:

/sqli-demo.php?id=1

The database contained a simple products table:

ID	Product	Price
1	Laptop	999 EUR
2	Phone	699 EUR
3	Tablet	399 EUR
4	Headphones	149 EUR

Vulnerable PHP Query

The PHP file reads the id value from the URL:

$id = $_GET['id'] ?? '1';

Then it inserts the value directly into the SQL query:

$sql = "SELECT id, name, price FROM products WHERE id = $id";

This is vulnerable because user input is used directly as part of the SQL command.

Original Query

Normal request:

/sqli-demo.php?id=1

SQL query:

SELECT id, name, price FROM products WHERE id = 1;

Result:

• Only product ID 1 is returned

Malicious Query

Malicious request:

/sqli-demo.php?id=1 OR 1=1

SQL query:

SELECT id, name, price FROM products WHERE id = 1 OR 1=1;

Since 1=1 is always true, every row in the products table is returned.

Why This Is Vulnerable

The application does not filter or parameterize the input.

Filtered input means checking the input before using it. For example, an ID should only be a number.

Parameterized input means the SQL query structure is fixed, and user input is passed separately as data. This prevents user input from becoming SQL code.

No IDPS

The attacker entered the SQL injection directly in Firefox:

http://192.168.10.10/sqli-demo.php?id=1 OR 1=1

Result:

• Request reached the PHP page
• Query was manipulated
• All products were returned
• No alert
• No blocking

Screenshot placement: Add screenshot of the browser showing all products returned.

Suricata IDS

alert http 192.168.20.0/24 any -> 192.168.10.10 80
(msg:"SQL Injection Attempt Detected - Boolean OR Pattern";
flow:established,to_server;
http.uri;
pcre:"/sqli-demo\.php\?id=[^&]*\bOR\b[^&]*1=1/Ui";
sid:2001001; rev:1;)

Result:

• Injection is detected
• Alert is logged
• Injection still succeeds

Logs were checked in:

/var/log/suricata/suricata.log

Suricata IPS

drop http 192.168.20.0/24 any -> 192.168.10.10 80
(msg:"SQL Injection Attempt BLOCKED - Boolean OR Pattern";
flow:established,to_server;
http.uri;
pcre:"/sqli-demo\.php\?id=[^&]*\bOR\b[^&]*1=1/Ui";
sid:2001001; rev:2;)

NFQUEUE for HTTP

For Suricata IPS, HTTP traffic had to be queued in both directions:

sudo iptables -I FORWARD 1 -i ens38 -o ens37 -p tcp --dport 80 -j NFQUEUE --queue-num 0
sudo iptables -I FORWARD 2 -i ens37 -o ens38 -p tcp --sport 80 -j NFQUEUE --queue-num 0

Run Suricata inline:

sudo suricata -c /etc/suricata/suricata.yaml -q 0 -l /var/log/suricata

Result:

• SQL injection pattern is detected
• Malicious request is dropped
• Web app does not return all products

Why Both Directions Were Needed

Suricata needs to see enough of the full HTTP flow to inspect the request correctly.

At first, only attacker-to-victim traffic was queued. The rule did not match correctly.

After queueing both directions, Suricata could properly inspect the HTTP URI and block the request.

Screenshot placement: Add one Suricata log screenshot and one screenshot showing the blocked request.

Attack 5: HTTP Flood

Description

The HTTP flood targets the victim Apache web server by sending many HTTP GET requests. This is a Layer 7 DoS-style attack.

The final presentation describes the goal as generating an HTTP flood using wrk, showing the impact on Apache access logs, and detecting/blocking it with Suricata. :contentReference[oaicite:9]{index=9}

Attack Command

wrk -t12 -c400 -d30s http://192.168.10.10/

Meaning:

• 12 threads
• 400 connections
• 30 seconds duration

Monitoring

On the victim:

sudo tail -f /var/log/apache2/access.log

No IDPS

Result:

• Apache receives thousands of GET requests per second
• Access log fills quickly with 200 OK entries
• No alert
• No blocking

Screenshot placement: Add Apache log screenshot under flood.

Suricata IDS

alert http any any -> 192.168.10.10 80
(msg:"HTTP Flood Detected - High Request Rate";
flow:to_server,established;
threshold:type threshold, track by_src, count 100, seconds 5;
sid:9000001; rev:1;)

Result:

• HTTP flood is detected
• Alert is logged
• Apache still receives the requests

Suricata IPS

drop http any any -> 192.168.10.10 80
(msg:"HTTP Flood Blocked - High Request Rate";
flow:to_server,established;
threshold:type threshold, track by_src, count 100, seconds 5;
sid:9000001; rev:2;)

NFQUEUE:

sudo iptables -I FORWARD 1 -i ens38 -o ens37 -p tcp --dport 80 -j NFQUEUE --queue-num 0
sudo iptables -I FORWARD 2 -i ens37 -o ens38 -p tcp --sport 80 -j NFQUEUE --queue-num 0

Run Suricata inline:

sudo suricata -c /etc/suricata/suricata.yaml -q 0 -l /var/log/suricata

Result:

• High request rate is detected
• Excessive HTTP requests are dropped
• Apache receives fewer successful requests

Screenshot placement: Add Suricata IPS drops screenshot.

Results Summary

Attack	Tool	IDS Result	IPS Result
SSH Brute Force	Snort	Login attempts detected	Repeated attempts blocked
Port Scanning	Snort	SYN scan detected	Scan packets dropped
Ping Flood	Snort	ICMP flood detected	Flood packets dropped
SQL Injection	Suricata	Malicious URI detected	HTTP request dropped
HTTP Flood	Suricata	High request rate detected	Excessive requests dropped

Main Lessons Learned

• IDS mode gives visibility, but does not block traffic.
• IPS mode is needed to actively stop attacks.
• NFQUEUE is required when Snort or Suricata should drop packets inline.
• Source-based detection is not always reliable when source IPs are spoofed.
• For HTTP inspection, Suricata needs enough flow visibility.
• Email alerts are useful for administrator monitoring.

Conclusion

This project showed how an IDPS can detect and block multiple attack types in a controlled VMware lab.

The attacks covered both network-layer and application-layer scenarios:

• SSH brute force
• Port scanning
• Spoofed ICMP ping flood
• SQL injection
• HTTP flood

The final result showed that IDS mode is useful for detection and logging, while IPS mode provides active protection by dropping malicious traffic before it reaches the victim.

References

• https://wikipedia.org
• https://google.com