taisa456/network-security-snortLaboratorio Snort 3 IDS → IPS su Kali. Regole di rilevamento personalizzate + applicazione di iptables contro ricognizione ICMP, scansioni SYN di Nmap, forza bruta FTP su Hydra e backdoor vsftpd 2.3.4 (CVE-2011-2523).
Un deployment a ciclo completo di Snort 3 sia come Intrusion Detection System (monitoraggio passivo) che come Intrusion Prevention System (blocco attivo tramite iptables), validato contro quattro vettori di attacco su una rete virtuale a tre macchine su Kali Linux.
Il laboratorio dimostra la distinzione operativa tra rilevamento e prevenzione eseguendo due volte una catena di attacco a quattro vettori identica — prima contro un IDS che registra ma non può bloccare, poi contro un IDS + livello IPS iptables che elimina gli attacchi selettivamente preservando il traffico legittimo.
| Componente | Dettagli |
|---|---|
| Analizzatore / Router | Kali Linux — 3 adattatori: eth0 WAN (192.168.10.143, NAT), eth1 LAN1 (10.10.10.1, solo host), eth2 LAN2 (192.168.50.1, solo host) |
| Attaccante | Kali Linux — eth0 su VMnet9 (10.10.10.10) — gateway predefinito 10.10.10.1 |
| Bersaglio | Metasploitable 2 — eth0 su VMnet10 (192.168.50.10) — gateway predefinito 192.168.50.1 |
| Versione di Snort | Snort++ 3.12.1.0-0kali1 (installato su Analizzatore) |
| Strumenti d'attacco | Nmap 7.99, Hydra v9.6, Metasploit Framework (msfconsole) |
| Virtualizzazione | VMware — VMnet9 = 10.10.10.0/24, VMnet10 = 192.168.50.0/24 (entrambi solo host) |
Tutto il traffico tra l'Attaccante e Metasploitable viene forzato attraverso l'Analizzatore, rendendolo il punto di strozzatura naturale sia per il monitoraggio che per l'applicazione.
┌─────────────────────────┐
│ 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 │ │
└─────────────────────────┘
Sostituisci questo schizzo ASCII con
screenshots/01-network-topology.pnguna volta che la figura è al suo posto:Topologia
Il laboratorio si svolge in due fasi con una catena di attacco a quattro vettori identica in ciascuna:
ping per la scoperta dell'hostnmap -sS per l'enumerazione delle porte (1000 porte)Stage 1 (IDS) esegue Snort passivamente sull'Analizzatore con cinque regole personalizzate — osserva gli alert in tempo reale, conferma che lo sfruttamento procede comunque.
Stage 2 (IPS) abbina Snort a un livello di enforcement iptables utilizzando regole di drop chirurgiche — conferma che gli attacchi vengono bloccati mentre il ping ICMP e il login FTP legittimo rimangono funzionali.
MASQUERADE + FORWARD in modo che l'Analizzatore instradi tra le sottoreti e verso il WAN — vedi scripts/router_config.sh.scripts/ping_check.sh prima di installare Snort.Snort viene installato tramite il gestore pacchetti di Kali (sudo apt install snort -y) e configurato 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 copre entrambe le sottoreti interne in modo che Snort consideri tutto il traffico tra sottoreti sull'Analizzatore degno di ispezione. alert_fast produce alert compatti su una riga (la registrazione per pacchetto genererebbe un volume eccessivo).
Convalida della configurazione:
sudo snort -T -c /etc/snort/snort.conf
# Risultato: 652 regole caricate (5 personalizzate testo + 647 built-in), 0 avvisi
Cinque regole in /etc/snort/rules/local.rules (file completo in scripts/local.rules):
| SID | Nome | Attivazione |
|---|---|---|
| 1000001 | Rilevato Ping ICMP | Qualsiasi traffico ICMP in entrambe le direzioni — intercetta ping di ricognizione |
| 1000002 | Tentativo di Connessione FTP | Qualsiasi connessione TCP alla porta 21 — intercetta traffico legittimo e di forza bruta |
| 1000003 | Possibile Scansione SYN di Nmap | Pacchetti TCP con solo il flag SYN impostato (flags:S) — la firma di una scansione half-open |
| 1000004 | Tentativo Backdoor VSFTPD 2.3.4 | content:":)" sulla porta FTP 21 — la stringa di attivazione esatta di CVE-2011-2523 |
| 1000005 | Possibile Shellcode Metasploit | `content:" |
Snort viene eseguito in modalità passiva su entrambe le interfacce interne:
sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 \
-A alert_fast -l /var/log/snort/
# Osserva gli alert in un secondo terminale:
sudo tail -f /var/log/snort/alert_fast.txt
L'output di avvio conferma pcap DAQ configured to passive — Snort vede ogni pacchetto ma non può eliminare o modificare nessuno di essi.
Dopo aver eseguito scripts/attack_simulator.sh dall'Attaccante:
| Attacco | Rilevamento | Esito |
|---|---|---|
| Riconoscimento ICMP | ✅ SID 1000001 — alert bidirezionali | Ping completato |
| Scansione SYN Nmap | ✅ SID 1000003 — migliaia di alert in <1 secondo | 23 porte aperte enumerate |
| Forza bruta FTP Hydra | ✅ SID 1000002 — ripetuti alert di connessione FTP | Credenziali msfadmin:msfadmin scoperte |
| Backdoor vsftpd 2.3.4 | ✅ SID 1000004 — corrispondenza contenuto :) attivata | Ottenuta shell Root Meterpreter |
L'IDS ha rilevato tutto e non ha fermato nulla. Questa è la lezione centrale dello Stage 1: un IDS funzionante senza enforcement è un sistema di allarme, non una serratura. Quando un analista umano legge gli alert, l'attaccante è già root.
Un'osservazione secondaria: le regole built-in di Snort (116:408, 116:414) si attivano sul traffico broadcast DHCP — non malizioso, ma in un deployment di produzione avrebbero bisogno di regole di soppressione per mantenere il log degli alert utilizzabile.
Il livello IPS viene distribuito con scripts/ips_setup.sh, che: