network-security-snort

Laboratorio 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).

Topologia di Rete

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.

Sostituisci questo schizzo ASCII con screenshots/01-network-topology.png una volta che la figura è al suo posto: Topologia

Metodologia

Il laboratorio si svolge in due fasi con una catena di attacco a quattro vettori identica in ciascuna:

1. Riconoscimento ICMP — ping per la scoperta dell'host
2. Scansione SYN di Nmap — nmap -sS per l'enumerazione delle porte (1000 porte)
3. Forza bruta FTP con Hydra — attacco alle credenziali contro il servizio vsftpd
4. Backdoor vsftpd 2.3.4 — Exploit di Metasploit per CVE-2011-2523

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.

Configurazione pre-deployment

1. Configura l'Analizzatore con tre NIC in VMware (due solo host, una NAT/bridged).
2. Abilita l'IP forwarding e aggiungi le regole MASQUERADE + FORWARD in modo che l'Analizzatore instradi tra le sottoreti e verso il WAN — vedi scripts/router_config.sh.
3. Verifica la connettività end-to-end da ogni VM con scripts/ping_check.sh prima di installare Snort.

Configurazione di Snort

Snort viene installato tramite il gestore pacchetti di Kali (sudo apt install snort -y) e configurato in /etc/snort/snort.conf:

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:

Regole di Rilevamento Personalizzate

Cinque regole in /etc/snort/rules/local.rules (file completo in scripts/local.rules):

Stage 1 — Modalità IDS

Snort viene eseguito in modalità passiva su entrambe le interfacce interne:

L'output di avvio conferma pcap DAQ configured to passive — Snort vede ogni pacchetto ma non può eliminare o modificare nessuno di essi.

Risultati IDS

Dopo aver eseguito scripts/attack_simulator.sh dall'Attaccante:

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.

Stage 2 — Modalità IPS

Il livello IPS viene distribuito con scripts/ips_setup.sh, che:

1. Svuota le regole iptables esistenti
2. Riabilita l'IP forwarding e riapplica il routing di base
3. Applica quattro regole di drop chirurgiche mirate a firme di attacco specifiche
4. Avvia Snort in modalità demone (-D) per la registrazione continua

Regole iptables

Risultati IPS

Lo stesso script di attacco è stato rieseguito dall'Attaccante:

Traffico normale preservato

Due controlli manuali hanno confermato l'enforcement selettivo:

• ping -c 4 192.168.50.10 → 4 pacchetti trasmessi, 4 ricevuti, 0% perdita
• ftp 192.168.50.10 con msfadmin:msfadmin → 220 (vsFTPd 2.3.4) … 230 Login riuscito

Prova quantitativa dai contatori pacchetti iptables durante l'esecuzione: 2051 pacchetti accettati, 12 pacchetti eliminati dalla regola connlimit FTP, 808 pacchetti ICMP accettati — enforcement selettivo in numeri.

Registrazione continua di Snort

Anche in modalità IPS, Snort ha continuato a generare alert SID 1000002 / 1000003 sui pacchetti che hanno raggiunto il suo punto di ispezione passiva prima che iptables eliminasse quelli successivi — ciò significa che iptables fornisce l'enforcement mentre Snort fornisce la registrazione di audit, operando in tandem.

IDS vs IPS — Risultati Affiancati

Discussione

Tutti gli attacchi simulati sono stati rilevati in modalità IDS?

Sì — ciascuno dei SID 1000001–1000004 si è attivato correttamente durante la simulazione dell'attacco:

• Ping ICMP (1000001) — alert bidirezionali per ogni echo/risposta.
• Scansione SYN Nmap (1000003) — ondata di alert in millisecondi, randomizzazione caratteristica della porta sorgente.
• Forza bruta FTP (1000002) — traccia di audit pulita dei tentativi di connessione paralleli di Hydra con timestamp esatti.
• Backdoor vsftpd (1000004) — la corrispondenza del contenuto :) ha catturato la sequenza di byte esatta dell'exploit.

Ma rilevamento ≠ prevenzione. L'exploit vsftpd ha aperto una shell Meterpreter root mentre ogni alert si attivava. Un analista SOC che osserva l'IDS in tempo reale avrebbe visto il compromesso — ma con l'attaccante già root in pochi secondi, la sola segnalazione non basta. Questo è il nucleo operativo del perché esiste l'IPS.

Quanto è stato efficace l'IPS nel bloccare gli attacchi senza rompere il traffico normale?

L'implementazione ha ottenuto una mitigazione completa degli attacchi con zero impatto osservabile sul traffico legittimo. L'efficacia deriva dalla progettazione chirurgica delle regole — ogni regola iptables mira a una firma comportamentale, non a un protocollo generico:

• Il rate-limit SYN rompe il pattern di flood delle scansioni di porte senza influenzare gli handshake normali.
• connlimit per sorgente blocca il parallelismo degli strumenti di forza bruta senza rompere l'FTP a sessione singola.
• Il match STRING elimina il payload esatto dell'exploit senza filtrare il traffico di login FTP legittimo.

Una limitazione riconosciuta: ICMP è completamente consentito, il che significa che un attaccante può ancora confermare che Metasploitable è vivo tramite ping. In un ambiente a più alta sicurezza questo sarebbe limitato in velocità o ristretto a fonti fidate. In questo laboratorio, ICMP è il meccanismo primario di verifica della connettività, quindi rimane aperto.

Macchina Snort dedicata vs. plugin pfSense/OPNsense

Questo laboratorio utilizza una macchina Snort dedicata. Rispetto all'esecuzione di Snort come plugin all'interno di un appliance firewall come pfSense o OPNsense:

Vantaggi dell'approccio dedicato:

• Isolamento delle prestazioni — CPU e RAM complete disponibili esclusivamente per l'ispezione dei pacchetti; nessuna contesa con routing, DHCP, VPN, DNS.
• Flessibilità di posizionamento — l'IDS/IPS può essere posizionato inline, su una porta SPAN/mirror, o al confine di un segmento interno per monitorare il traffico est-ovest che non raggiunge mai il firewall perimetrale.
• Controllo completo della configurazione — ogni preprocessore, impostazione DAQ, plugin di output e programma di aggiornamento delle regole è configurabile tramite CLI. pfSense espone solo un sottoinsieme tramite la sua GUI.
• Resilienza — la macchina IDS/IPS può fallire-aperto o fallire-chiuso indipendentemente dal router. In pfSense, un crash di Snort abbatte sia il routing che il rilevamento contemporaneamente.

Compromessi:

• Curva di apprendimento più ripida — richiede competenza CLI e gestione diretta del set di regole.
• Costi di manutenzione — aggiornamenti delle regole, upgrade di versione, rotazione dei log, tutto manuale.

Snort dedicato è la scelta corretta per ambienti aziendali che necessitano di prestazioni, posizionamento e personalizzazione. L'approccio plugin pfSense/OPNsense è più sensato per ambienti di piccole imprese o home lab che danno priorità alla facilità d'uso.

Nota sull'Architettura

Lo Stage 2 è tecnicamente Snort passivo + enforcement iptables, non Snort in esecuzione in vera modalità inline — Snort stesso registra (pcap DAQ configured to passive), e iptables esegue l'eliminazione basata su limiti di velocità, corrispondenze di stringhe e conteggi di connessione.

Questo è un pattern di deployment legittimo e comune (è così che molti stack IDS/IPS basati su Linux nel mondo reale operano). Un seguito naturale sarebbe migrare lo Stage 2 a una vera configurazione inline usando snort --daq nfq (o afpacket in modalità inline) con le azioni di regola reject / drop di Snort, così che Snort stesso esegua l'eliminazione basata sulla corrispondenza completa delle firme piuttosto che delegare a iptables.

Struttura del Repository

Riprodurre il Laboratorio

⚠️ Solo uso laboratorio. Questi script eseguono exploit reali e strumenti di forza bruta contro un target deliberatamente vulnerabile. Non eseguirli contro alcun sistema di cui non possiedi e non hai esplicita autorizzazione scritta per testare.

1. Costruisci tre VM in VMware secondo la topologia sopra (VMnet9 e VMnet10 come solo host).
2. Sull'Analizzatore: esegui scripts/router_config.sh, poi scripts/ping_check.sh per confermare la connettività completa.
3. Installa Snort 3 sull'Analizzatore:
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. Posiziona scripts/local.rules in /etc/snort/rules/local.rules e imposta HOME_NET = "10.10.10.0/24,192.168.50.0/24" in /etc/snort/snort.conf.
5. Convalida: sudo snort -T -c /etc/snort/snort.conf — aspettati 652 regole caricate, 0 avvisi.
6. Stage 1 — IDS:
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # In un altro terminale:
   sudo tail -f /var/log/snort/alert_fast.txt
   

   Sull'Attaccante: sudo ./scripts/attack_simulator.sh — osserva gli alert attivarsi e la shell Meterpreter.
7. Stage 2 — IPS: sull'Analizzatore, esegui sudo ./scripts/ips_setup.sh, poi riesegui la catena d'attacco sull'Attaccante. Conferma i blocchi, poi testa manualmente:
   root@kitploit:~

   ping -c 4 192.168.50.10        # dovrebbe riuscire
   ftp 192.168.50.10              # msfadmin / msfadmin — dovrebbe riuscire
   

Disclaimer Etico

Tutte le attività documentate in questo repository sono state condotte esclusivamente all'interno di un ambiente di laboratorio virtuale VMware autonomo per scopi di apprendimento accademico supervisionato. Nessun sistema esterno, di produzione o reale è stato preso di mira, scansionato o influenzato in alcun modo. Metasploitable 2 è una macchina virtuale intenzionalmente vulnerabile progettata specificamente per la formazione sulla sicurezza.

Questo materiale non deve essere utilizzato per replicare queste attività contro alcun sistema reale senza esplicita autorizzazione scritta del proprietario del sistema. La scansione di porte non autorizzata, gli attacchi alle credenziali o lo sfruttamento di servizi di rete sono illegali nella maggior parte delle giurisdizioni.

Licenza

MIT — vedi LICENSE. Il rapporto di laboratorio stesso è fornito come riferimento educativo.