Tutorial IDS/IPS: installazione e ottimizzazione del rilevamento

Introduzione

Un IDS/IPS serve a vedere e, se richiesto, bloccare traffico sospetto prima che diventi un incidente. In pratica, un IDS osserva e segnala; un IPS osserva e interviene. La differenza sembra piccola, ma in produzione cambia tutto: un IPS mal configurato può interrompere traffico legittimo, mentre un IDS ben tarato aiuta a scoprire exploit, scansioni, malware e comportamenti anomali senza impattare il servizio.

In questa guida il principio è semplice: prima rendere il sistema osservabile, poi attivare il blocco solo quando i segnali sono affidabili. La parte più importante non è installare il motore, ma costruire una baseline pulita, ridurre i falsi positivi e verificare che ogni regola abbia un motivo operativo.

IDS o IPS: cosa scegliere

Se il server ospita siti web, mail o servizi critici, la scelta più sicura all’inizio è quasi sempre IDS. Questo consente di raccogliere evidenze senza rischiare blocchi improvvisi. L’IPS va introdotto dopo una fase di osservazione, quando hai capito quali pattern sono normali e quali no.

• IDS: rileva e registra, ideale per partire.
• IPS: rileva e blocca, utile quando le regole sono già testate.
• Approccio consigliato: prima IDS in alert-only, poi IPS solo su categorie ad alta fiducia.

Scelta del motore

Su Linux oggi le opzioni più comuni sono Suricata, Snort e, in alcuni scenari, Zeek come motore di analisi. Per un’installazione pratica su server web moderni, Suricata è spesso una scelta equilibrata: supporta multi-thread, output in JSON, integrazione con EVE log e regole compatibili con molti flussi operativi. Snort resta valido, soprattutto in ambienti che già lo usano, ma richiede una gestione attenta delle performance e delle regole. Zeek è eccellente per visibilità e analisi, ma non è un IPS tradizionale.

Se devi proteggere un VPS o un server hosting, la combinazione più lineare è: Suricata come IDS/IPS, log centralizzati e revisione periodica delle regole. Se hai un pannello come Plesk, cPanel o FastPanel, il motore si installa quasi sempre da terminale, mentre il controllo e il monitoraggio possono essere integrati con dashboard esterne o strumenti di log parsing.

Prerequisiti prima dell’installazione

Prima di installare, verifica tre cose: capacità della CPU, spazio disco per i log e posizione del traffico da ispezionare. Un IDS su una macchina già satura peggiora la situazione. Un IPS su un server con storage lento può generare latenza o perdita di pacchetti.

1. CPU e RAM: controlla che il server abbia margine, soprattutto se ospita PHP, database e web server.
2. Disco: i log crescono rapidamente; serve rotazione e retention.
3. Rete: definisci se analizzerai solo traffico in ingresso, anche uscita, oppure segmenti interni.

Se lavori su un firewall dedicato o su un gateway, l’IPS ha molto più senso. Su un server applicativo puro, spesso è meglio un IDS con alert mirati e un firewall separato per il blocco.

Installazione di base su Debian e Ubuntu

Su Debian e Ubuntu, Suricata è disponibile nei repository e si può installare rapidamente. Prima aggiorna gli indici e verifica la versione disponibile. Poi installa il motore e i pacchetti utili per i log e la gestione delle regole.

sudo apt update
sudo apt install -y suricata jq ethtool

Dopo l’installazione, verifica che il servizio sia presente e che l’interfaccia di rete corretta sia individuata. In molti casi l’errore più comune è attivare l’analisi sulla scheda sbagliata.

ip a
systemctl status suricata --no-pager

Esito atteso: il servizio deve risultare installato e l’interfaccia di rete deve essere quella che riceve davvero il traffico utile.

Installazione di base su AlmaLinux, Rocky e CentOS

Su sistemi RHEL-like, il pacchetto può arrivare dai repository EPEL o da repository del vendor, a seconda della versione. L’obiettivo è lo stesso: installare il motore, i tool di verifica e un sistema di aggiornamento regole affidabile.

sudo dnf install -y epel-release
sudo dnf install -y suricata jq ethtool

Dopo l’installazione, controlla che il servizio sia attivo e che non ci siano blocchi SELinux non previsti. Se SELinux è enforcing, va considerato nel tuning, non disattivato a caso.

getenforce
systemctl status suricata --no-pager

Esito atteso: il servizio parte correttamente e SELinux non genera denial rilevanti nei log durante i primi test.

Configurazione iniziale sicura

La prima configurazione deve essere conservativa. Non partire con il blocco aggressivo, non attivare tutte le regole e non ispezionare subito tutto il traffico. La priorità è capire il comportamento normale del sistema.

1. Backup del file di configurazione: prima di modificare, copia sempre il file originale.
2. Definizione delle reti protette: imposta correttamente le variabili di rete locale e delle reti da monitorare.
3. Modalità alert-only: all’inizio registra, non bloccare.

Tipicamente i file principali sono in /etc/suricata/suricata.yaml e le regole in directory dedicate come /var/lib/suricata/rules o analoghe, a seconda della distribuzione. Prima di cambiare, salva una copia di sicurezza.

sudo cp /etc/suricata/suricata.yaml /etc/suricata/suricata.yaml.bak

Verifica poi le variabili di rete, ad esempio HOME_NET, che devono riflettere le subnet realmente protette. Se sbagli qui, il motore può generare troppi eventi o ignorare traffico importante.

Caricare le regole correttamente

Le regole sono il cuore dell’IDS/IPS. Un motore senza regole ben gestite produce poco valore. Le regole possono arrivare da feed pubblici, vendor commerciali o regole personalizzate. Le regole pubbliche sono utili, ma vanno filtrate e testate.

La strategia più robusta è questa:

1. caricare un set base affidabile;
2. disattivare subito le regole troppo rumorose;
3. aggiungere regole custom per servizi realmente esposti;
4. aggiornare con cadenza regolare e verificare l’impatto.

Non tutte le firme hanno lo stesso valore. Una regola che segnala genericamente una stringa sospetta può essere utile in laboratorio, ma in produzione rischia di generare rumore. Le regole migliori sono quelle che corrispondono a servizi esposti, versioni note e vettori di attacco realistici per il tuo ambiente.

Ottimizzazione del rilevamento

L’ottimizzazione non significa soltanto “più aggressivo”. Significa trovare il punto in cui il sistema vede bene senza consumare troppe risorse e senza generare falsi positivi inutili. Le metriche da osservare sono CPU, RAM, I/O disco, latenza di rete, numero di alert per minuto e presenza di eventi ripetitivi.

1. Ridurre il rumore

Se vedi centinaia di alert ripetuti sulla stessa sorgente o sulla stessa regola, quella regola va valutata. Puoi sopprimere gli eventi meno utili, modificare soglie o escludere reti note. Il principio è semplice: un alert deve rappresentare informazione utile, non rumore.

2. Limitare il campo di ispezione

Non sempre serve analizzare tutto il traffico. In molti casi conviene concentrarsi su ingressi WAN, segmenti DMZ, servizi pubblici e porte realmente esposte. Questo riduce il carico e aumenta la precisione.

3. Usare soglie e threshold

Molti attacchi producono sequenze ripetitive. Le soglie aiutano a trasformare una raffica di eventi in un singolo alert significativo. È un modo efficace per distinguere una scansione da un evento isolato.

4. Sfruttare l’hardware disponibile

Se il server ha più core, un motore multi-thread può distribuire meglio il carico. Se invece il collo di bottiglia è il disco, l’ottimizzazione va fatta sui log: rotazione, compressione e retention devono essere razionali.

Verifica della configurazione

Prima di riavviare il servizio in produzione, valida sempre la configurazione. Un file YAML o una regola errata può bloccare il demone o farlo partire in modo incompleto.

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

Esito atteso: il test deve terminare senza errori critici. Se compare un problema, correggilo prima del riavvio. In alternativa, controlla i log del servizio per capire se il problema riguarda regole, interfaccia o permessi.

journalctl -u suricata -n 100 --no-pager

Questo controllo è utile per capire subito se il motore non parte per un errore di configurazione o per un problema di accesso alla scheda di rete.

Passaggio da IDS a IPS

Il passaggio al blocco attivo va fatto con cautela. Non tutte le regole sono adatte all’IPS. Un buon criterio è abilitare in blocco solo le firme ad alta confidenza, legate a exploit noti o a pattern chiaramente malevoli.

1. Fase 1: IDS puro, raccolta alert e baseline.
2. Fase 2: blocco solo per regole selezionate e testate.
3. Fase 3: monitoraggio stretto dei falsi positivi e rollback rapido se un servizio legittimo viene colpito.

Se il server ospita e-commerce, login o API, il rollback deve essere immediato e documentato. Un IPS che blocca login legittimi può causare danni più grandi dell’attacco che intende fermare.

Integrazione con firewall e stack hosting

Un IDS/IPS non sostituisce un firewall. Lavora meglio se è integrato con regole di rete, fail2ban, ACL del pannello e protezioni a livello web server. In un ambiente hosting conviene ragionare per strati: firewall di rete, web server, WAF, IDS/IPS, monitoraggio log.

Su server con cPanel, Plesk o FastPanel, il motore di rilevamento va coordinato con le regole già presenti. Se hai già mod_security, WAF o protezioni del pannello, evita sovrapposizioni inutili. L’obiettivo è non duplicare gli stessi controlli con strumenti diversi senza un beneficio reale.

Monitoraggio dei log

Il valore dell’IDS/IPS si misura nei log. Senza revisione periodica, anche il miglior motore diventa solo un generatore di file. I log principali da osservare sono quelli degli alert, degli eventi di drop e dei messaggi di errore del servizio.

Una routine minima utile è questa:

1. controllo giornaliero degli alert più frequenti;
2. revisione settimanale delle regole rumorose;
3. verifica mensile del consumo di risorse e della retention dei log.

Per analisi rapide, i log in formato JSON sono più facili da filtrare e integrare con strumenti di dashboard. Se usi jq, puoi estrarre rapidamente campi come firma, sorgente e destinazione.

jq '.alert.signature, .src_ip, .dest_ip' /var/log/suricata/eve.json | head

Esito atteso: vedere le firme principali e capire subito quali host generano più eventi.

Riduzione dei falsi positivi

I falsi positivi sono il vero nemico della fiducia nel sistema. Se ogni giorno arrivano decine di alert inutili, l’operatore smette di guardarli. Per evitarlo, lavora su tre livelli: regole, soglie e contesto.

• Regole: disabilita quelle troppo generiche per il tuo ambiente.
• Soglie: raggruppa eventi ripetitivi.
• Contesto: escludi reti interne, scanner autorizzati e servizi di monitoraggio noti.

Un buon tuning non elimina gli alert, li rende credibili. Se un evento è raro, coerente e collegato a un servizio esposto, ha più valore di dieci regole che scattano su traffico normale.

Hardening minimo del sistema

Per un IDS/IPS in produzione servono alcune misure minime: aggiornamenti costanti, privilegi ridotti, backup della configurazione e monitoraggio dei log. Se il motore gira con permessi eccessivi, il rischio operativo aumenta.

1. Aggiornamenti: mantieni motore e regole aggiornati.
2. Privilegi: esegui solo ciò che serve, evitando configurazioni troppo permissive.
3. Backup: salva configurazioni e regole prima di ogni cambiamento.
4. Monitoraggio: integra alert su spazio disco, stato servizio e crescita log.

Esempio di flusso operativo consigliato

Un flusso realistico per un server hosting è questo: installazione in IDS, validazione della configurazione, osservazione per alcuni giorni, tuning delle regole rumorose, attivazione selettiva dell’IPS su firme ad alta fiducia, controllo delle performance e revisione periodica.

Questo approccio è più lento di un attivazione “tutto e subito”, ma è quello che riduce gli incidenti. In sicurezza operativa, la velocità iniziale conta meno della qualità della decisione.

Controlli finali

Dopo l’attivazione, verifica sempre che il motore stia davvero vedendo traffico utile e che non stia degradando il server.

1. Stato servizio: il demone deve risultare attivo e stabile.
2. Log eventi: devono comparire alert coerenti con il traffico osservato.
3. Prestazioni: CPU, RAM e I/O devono restare entro margini accettabili.
4. Funzionalità: i servizi web, mail e pannello devono continuare a rispondere correttamente.

Se un IPS introduce blocchi anomali o latenza evidente, torna subito in modalità IDS e correggi le regole prima di riattivare il blocco.

Rollback

Il rollback deve essere semplice e documentato. Se una modifica crea problemi, disattiva le sole regole o funzioni introdotte di recente, ripristina il backup della configurazione e riavvia il servizio. Non serve smontare tutto: basta tornare all’ultimo stato stabile e poi correggere con calma.

sudo cp /etc/suricata/suricata.yaml.bak /etc/suricata/suricata.yaml
sudo systemctl restart suricata

Condizione di successo: il servizio riparte, i log non mostrano errori critici e i servizi esposti tornano a funzionare normalmente.

Conclusione operativa

Installare un IDS/IPS non significa solo mettere un pacchetto e accenderlo. Il lavoro vero è costruire affidabilità: scegliere il motore giusto, partire in osservazione, pulire le regole, misurare l’impatto e introdurre il blocco soltanto quando il segnale è abbastanza pulito. In questo modo il sistema non diventa un freno, ma uno strumento utile per leggere il traffico e reagire con criterio.