taisa456/network-security-snortSnort 3 IDS → IPS lab on Kali. Custom detection rules + iptables enforcement against ICMP recon, Nmap SYN scans, Hydra FTP brute force, and vsftpd 2.3.4 backdoor (CVE-2011-2523).
A full-cycle deployment of Snort 3 as both an Intrusion Detection System (passive monitoring) and an Intrusion Prevention System (active blocking via iptables), validated against four attack vectors across a three-machine virtual network on Kali Linux.
The lab proves the operational distinction between detection and prevention by running an identical four-vector attack chain twice — first against an IDS that logs but cannot block, then against an IDS + iptables IPS layer that drops attacks selectively while preserving legitimate traffic.
| Component | Details |
|---|---|
| Analyzer / Router | Kali Linux — 3 adapters: eth0 WAN (192.168.10.143, NAT), eth1 LAN1 (10.10.10.1, host-only), eth2 LAN2 (192.168.50.1, host-only) |
| Attacker | Kali Linux — eth0 on VMnet9 (10.10.10.10) — default gateway 10.10.10.1 |
| Target | Metasploitable 2 — eth0 on VMnet10 (192.168.50.10) — default gateway 192.168.50.1 |
| Snort version | Snort++ 3.12.1.0-0kali1 (installed on Analyzer) |
| Attack tooling | Nmap 7.99, Hydra v9.6, Metasploit Framework (msfconsole) |
| Virtualisation | VMware — VMnet9 = 10.10.10.0/24, VMnet10 = 192.168.50.0/24 (both host-only) |
All traffic between the Attacker and Metasploitable is forced through the Analyzer, making it the natural chokepoint for both monitoring and enforcement.
┌─────────────────────────┐
│ Analyzer / Router │
│ Kali + Snort 3 │
│ │
Attacker Kali ──VMnet9──┤ eth1: 10.10.10.1 │
10.10.10.10 │ │
│ eth0: 192.168.10.143 ───┼──> WAN (NAT)
│ │
Metasploitable 2 ─VMnet10┤ eth2: 192.168.50.1 │
192.168.50.10 │ │
└─────────────────────────┘
Replace this ASCII sketch with
screenshots/01-network-topology.pngonce you have the figure in place:Topology
The lab executes in two stages with an identical four-vector attack chain in each:
ping for host discoverynmap -sS for port enumeration (1000 ports)Stage 1 (IDS) runs Snort passively on the Analyzer with five custom rules — observe alerts in real time, confirm exploitation proceeds anyway.
Stage 2 (IPS) pairs Snort with an iptables enforcement layer using surgical drop rules — confirm attacks are blocked while ICMP ping and legitimate FTP login remain functional.
MASQUERADE + FORWARD rules so the Analyzer routes between subnets and out to the WAN — see scripts/router_config.sh.scripts/ping_check.sh before installing Snort.Snort is installed via the Kali package manager (sudo apt install snort -y) and configured in /etc/snort/snort.conf:
HOME_NET = "10.10.10.0/24,192.168.50.0/24"
EXTERNAL_NET = "any"
ips = {
enable_builtin_rules = true,
include = "/etc/snort/rules/local.rules",
variables = default_variables
}
alert_fast = { file = true, packet = false }
HOME_NET covers both internal subnets so Snort treats all inter-subnet traffic on the Analyzer as worth inspecting. alert_fast produces compact one-line alerts (per-packet logging would generate excessive volume).
Config validation:
sudo snort -T -c /etc/snort/snort.conf
# Result: 652 rules loaded (5 custom text + 647 built-in), 0 warnings
Five rules in /etc/snort/rules/local.rules (full file in scripts/local.rules):
| SID | Name | Trigger |
|---|---|---|
| 1000001 | ICMP Ping Detected | Any ICMP traffic in either direction — catches reconnaissance pings |
| 1000002 | FTP Connection Attempt | Any TCP connection to port 21 — catches legitimate and brute force traffic |
| 1000003 | Possible Nmap SYN Scan | TCP packets with only the SYN flag set (flags:S) — the signature of a half-open scan |
| 1000004 | VSFTPD 2.3.4 Backdoor Attempt | content:":)" on FTP port 21 — the exact CVE-2011-2523 trigger string |
| 1000005 | Possible Metasploit Shellcode | `content:" |
Snort runs in passive mode on both internal interfaces:
sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 \
-A alert_fast -l /var/log/snort/
# Watch alerts in a second terminal:
sudo tail -f /var/log/snort/alert_fast.txt
Startup output confirms pcap DAQ configured to passive — Snort sees every packet but cannot drop or modify any of them.
After executing scripts/attack_simulator.sh from the Attacker:
| Attack | Detection | Outcome |
|---|---|---|
| ICMP recon | ✅ SID 1000001 — bidirectional alerts | Ping completed |
| Nmap SYN scan | ✅ SID 1000003 — thousands of alerts in <1 second | 23 open ports enumerated |
| Hydra FTP brute force | ✅ SID 1000002 — repeated FTP connection alerts | msfadmin:msfadmin credentials cracked |
| vsftpd 2.3.4 backdoor | ✅ SID 1000004 — :) content match fired | Root Meterpreter shell obtained |
The IDS detected everything and stopped nothing. This is the central lesson of Stage 1: a working IDS without enforcement is an alarm system, not a lock. By the time a human analyst reads the alerts, the attacker is already root.
A secondary observation: Snort's built-in rules (116:408, 116:414) fire on DHCP broadcast traffic — not malicious, but in a production deployment they'd need suppression rules to keep the alert log actionable.
The IPS layer is deployed with scripts/ips_setup.sh, which:
-D) for continued logging