Cosa fa#
IDS (Intrusion Detection System) è il cappello che copre HIDS e NIDS. IPS aggiunge la capacità di blocco. Non sono prodotti diversi: è lo stesso sistema configurato diversamente.
TL;DR#
IDS (Intrusion Detection System)
├── HIDS — monitora un singolo host dall'interno
│ └── esempio: Wazuh agent
└── NIDS — monitora il traffico di rete sul perimetro
└── esempio: Suricata in modalità af-packet
IPS (Intrusion Prevention System) = IDS che blocca
├── HIPS — host-based, blocca con iptables/nftables dopo l'arrivo
│ └── esempio: Wazuh Active Response + fail2ban
└── NIPS — network-based, inline — droppa i pacchetti prima dell'arrivo
└── esempio: Suricata in modalità nfqueueIDS rileva e avvisa. IPS rileva e blocca. La posizione nel flusso del traffico è tutto.
Come funziona#
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
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 è 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 | Sì |
HIPS non è inline. I pacchetti SSH arrivano all'host, il sistema li analizza, poi blocca i tentativi futuri. Suricata in nfqueue è l'unico che intercetta il pacchetto prima che raggiunga la destinazione.
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
- 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.
Scenario Reale#
In un SOC enterprise il setup tipico è:
- NIDS (Suricata) sul firewall perimetrale — vede tutto il traffico in entrata
- HIDS (Wazuh agent) su ogni server critico — vede log, FIM, processi interni
- SIEM (Wazuh manager o Splunk) — 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.
Collegato a#
- log — SIEM, correlazione eventi, Wazuh manager
- network — NIDS, Suricata, traffico di rete
- glossario-cyber — voci IDS, IPS, HIDS, NIDS, HIPS, NIPS, CVE
- cap-04-securing-your-network — IDS/IPS Cap 4 Gibson
