Cosa fa#
IDS (Intrusion Detection System) e IPS (Intrusion Prevention System) sono la stessa tecnologia con risposte diverse: l'IDS rileva e avvisa, l'IPS rileva e blocca. Non sono prodotti separati ma modalita' operative dello stesso sistema.
IDS (Intrusion Detection System) e' il cappello che copre HIDS e NIDS. IPS aggiunge la capacita' di blocco. Non sono prodotti diversi: e' lo stesso sistema configurato diversamente.
TL;DR#
IDS rileva e avvisa. IPS rileva e blocca. La posizione nel flusso del traffico determina tutto.
- Un IDS riceve una copia del traffico (non e' inline) e genera alert senza interrompere il flusso.
- Un IPS sta fisicamente nel mezzo del path del traffico e puo' droppare il pacchetto prima che raggiunga la destinazione.
- HIDS/HIPS agiscono sul singolo host leggendo log, processi e file; NIDS/NIPS agiscono a livello rete.
- Solo il NIPS e' davvero inline -- HIPS blocca dopo che il pacchetto e' gia' arrivato all'host.
Come funziona#
IDS e IPS catturano il traffico di rete e lo analizzano per rilevare attacchi o anomalie. La differenza emerge quando viene individuato un evento sospetto: l'IDS invia un alert, l'IPS interviene bloccando attivamente.
graph TD
IDS["IDS
Intrusion Detection System"]
IPS["IPS
Intrusion Prevention System"]
HIDS["HIDS
Host-based"]
NIDS["NIDS
Network-based"]
HIPS["HIPS
Host-based"]
NIPS["NIPS
Network-based — inline"]
IDS --> HIDS
IDS --> NIDS
IPS --> HIPS
IPS --> NIPS
Lettura diagramma: Tassonomia IDS/IPS a quattro nodi. IDS si ramifica in HIDS (host-based) e NIDS (network-based). IPS si ramifica in HIPS (host-based) e NIPS (network-based inline). La struttura mostra che IDS e IPS non sono prodotti separati ma modalita' operative: IPS aggiunge la capacita' di blocco a IDS.
HIDS vs NIDS#
| HIDS | NIDS | |
|---|---|---|
| Dove vive | su ogni macchina | sul perimetro |
| Cosa vede | processi, file, log | pacchetti di rete |
| Cieco a | traffico di rete | cosa succede dentro l'host |
| Inline? | No | No |
| Esempio | Wazuh agent | Suricata af-packet |
Il concetto di inline#
Inline significa che il traffico passa attraverso il dispositivo prima di arrivare a destinazione. Solo il NIPS e' davvero inline.
| Posizione | Quando blocca | Inline? | |
|---|---|---|---|
| HIDS | dentro l'host, legge log | non blocca | No |
| HIPS | dentro l'host, regole iptables | dopo l'arrivo del pacchetto | No |
| NIDS | perimetro, copia del traffico | non blocca | No |
| NIPS | perimetro, nel path del traffico | prima dell'arrivo | Si' |
HIPS non e' inline. I pacchetti SSH arrivano all'host, il sistema li analizza, poi blocca i tentativi futuri. Suricata in nfqueue e' l'unico che intercetta il pacchetto prima che raggiunga la destinazione.
TAP e SPAN Port (come il NIDS riceve il traffico)#
Un NIDS non puo' essere connesso fisicamente a tutti i cavi della rete. Per ricevere una copia del traffico senza stare inline usa due meccanismi:
- TAP fisico (Test Access Point): dispositivo hardware che si interpone fisicamente sul cavo e duplica il traffico su una porta separata verso il sensore NIDS. Passivo e affidabile -- non ha impatto sul traffico originale.
- SPAN Port (Switch Port Analyzer): configurazione software sullo switch che copia tutto il traffico di una o piu' porte verso la porta del sensore NIDS. Piu' economico del TAP ma puo' perdere pacchetti sotto carico elevato.
In entrambi i casi il NIDS riceve solo una copia -- non puo' interrompere il flusso. Per bloccare il traffico serve il NIPS inline.
Wazuh nel lab#
Wazuh fa tre cose con un solo servizio:
graph LR
A["Wazuh agent
(HIDS-Barno)"]
B["Wazuh manager
(SIEM)"]
C["Active Response
(HIPS)"]
D["fail2ban
(HIPS component)"]
A -->|"invia eventi"| B
B -->|"correla, genera alert"| B
B -->|"trigger"| C
C -->|"esegue"| D
D -->|"ban IP con iptables"| D
Lettura diagramma: Wazuh come stack IDS+SIEM+HIPS in un unico servizio. L'agent invia eventi al manager. Il manager correla e genera alert. Quando l'alert supera la soglia, triggera Active Response. Active Response esegue fail2ban, che banna l'IP con iptables. Il ciclo e' automatico: evento → correlazione → ban senza intervento umano.
- HIDS: l'agente legge
auth.log, FIM, processi -- manda tutto al manager - SIEM: il manager correla gli eventi, applica regole, genera alert MITRE ATT&CK
- HIPS: con Active Response + fail2ban, blocca automaticamente l'IP attaccante dopo soglia
Lab: brute force SSH#
# Kali attacca
hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.64.3 -t 4
# Ubuntu — fail2ban banna l'IP dopo 5 tentativi in 60s
# /etc/fail2ban/jail.local
# maxretry = 5 / findtime = 60 / bantime = 300Risultato osservato: 816 authentication failures in Wazuh, poi Connection refused su Kali quando scatta il ban. Il ciclo Found → Ban → Unban visibile in /var/log/fail2ban.log.
FP/FN/TP/TN e Soglie#
La validazione degli alert consiste nel classificare le segnalazioni in base alla loro correttezza. Bilanciare correttamente i quattro esiti e' il lavoro centrale del tuning di un IDS.
| Attacco reale | Traffico legittimo | |
|---|---|---|
| IDS genera alert | True Positive (TP) | False Positive (FP) |
| IDS silenzioso | False Negative (FN) | True Negative (TN) |
- True Positive (TP): attacco reale, IDS rileva correttamente. L'esito desiderato.
- True Negative (TN): nessun attacco, IDS tace. Comportamento corretto.
- False Positive (FP): evento benigno segnalato come minaccia. Produce "rumore" e spreca tempo degli analisti.
- False Negative (FN): attacco in corso, IDS non rileva nulla. Il caso piu' pericoloso -- l'attaccante passa inosservato.
La threshold (soglia) e' il parametro che bilancia FP e FN. Non esiste una soglia universale -- dipende dall'ambiente:
- Soglia bassa → alta sensibilita' → piu' FP, pochi FN (preferibile in ambienti ad alto rischio)
- Soglia alta → alta specificita' → pochi FP, piu' FN (rischio di perdere attacchi reali)
Alert fatigue: troppi FP portano gli analisti a ignorare tutti gli alert, compresi i TP. Il rimedio e' calibrare la soglia, non sopprimere gli alert. Un IDS con troppi falsi positivi e' peggio di nessun IDS.
Scenario Reale#
In un SOC enterprise il setup tipico e' il seguente: NIDS (Suricata) sul firewall perimetrale che vede tutto il traffico in entrata tramite SPAN port; HIDS (Wazuh agent) su ogni server critico che vede log, FIM e processi interni; SIEM (Wazuh manager o Splunk) che correla eventi da entrambe le sorgenti.
Quando un attaccante fa port scan → NIDS genera alert. Quando poi tenta di escalare i privilegi sull'host → HIDS genera alert. Il SIEM correla i due eventi e ricostruisce la kill chain.
Dev parallel: Un HIDS su un server PHP/Node e' concettualmente simile al middleware di logging applicativo che logga ogni request anomala. Un WAF configurato in modalita' blocking (non solo detection) e' l'equivalente di un NIPS inline: non logga il request malevolo, lo blocca prima che raggiunga il tuo codice. La differenza tra IDS e IPS e' la stessa differenza tra un access log e un firewall rule che droppa il traffico.
Collegato a#
- log -- SIEM, correlazione eventi, Wazuh manager
- glossario-cyber -- voci IDS, IPS, HIDS, NIDS, HIPS, NIPS, CVE
- cap-04-securing-your-network -- IDS/IPS Cap 4 Gibson
