816 tentativi zero successi

Il lab è semplice: Ubuntu con Wazuh, Kali con Hydra, una wordlist da 14 milioni di password. Obiettivo: vedere cosa succede dall'altra parte quando un attaccante tenta il brute force SSH.

Il setup

#

Il laboratorio è composto da due macchine virtuali collegate all'interno dello stesso segmento di rete isolato:

graph LR
    subgraph Kali ["Kali Linux (Attaccante)"]
        A["192.168.64.200"]
        A_Tools["Tools: Hydra, rockyou.txt"]
    end

    subgraph Ubuntu ["Ubuntu Server (Defender)"]
        D["192.168.64.3"]
        D_Agent["Wazuh Agent"]
        D_HIPS["Fail2ban (HIPS)"]
        D_Containers["Docker: Wazuh Cluster
- wazuh-manager
- wazuh-indexer
- wazuh-dashboard"]
    end

    A ===|Rete Virtuale| D
    
    style Kali fill:#2b2b2b,stroke:#ff5555,stroke-width:2px,color:#fff
    style Ubuntu fill:#1e1e1e,stroke:#3b82f6,stroke-width:2px,color:#fff

Sul defender (Ubuntu 192.168.64.3) gira Wazuh in Docker - tre container distinti:

wazuh-manager    ← analizza gli eventi, genera gli alert
wazuh-indexer    ← salva tutto (OpenSearch)
wazuh-dashboard  ← la finestra su quello che succede

Più un agente nativo (wazuh-agent.service) che monitora l'host stesso. Questo agente si chiama HIDS-Barno nella dashboard - è lui che legge i log, controlla i file e manda tutto al manager in tempo reale.

Sull'attaccante (Kali 192.168.64.200): Hydra e la celebre wordlist rockyou.txt decompressa.

L'attacco

#

Avviamo l'attacco da Kali puntando all'interfaccia SSH della nostra vittima:

hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://192.168.64.3 -t 4

Hydra parte a pieno regime: 4 thread paralleli, circa 76 tentativi al minuto. Spostandoci su Ubuntu, il log di sistema /var/log/auth.log inizia immediatamente a riempirsi di fallimenti ad altissima velocità:

Failed password for root from 192.168.64.200 port 40334 ssh2
Failed password for root from 192.168.64.200 port 40335 ssh2
Failed password for root from 192.168.64.200 port 40336 ssh2

Ogni singola riga rappresenta un tentativo fallito. Con ben 14 milioni di combinazioni possibili nel dizionario rockyou.txt, senza alcuna contromisura attiva, Hydra avrebbe tutto il tempo necessario per trovare la chiave d'accesso.

Detection - il HIDS entra in gioco

#

L'agente Wazuh legge /var/log/auth.log in tempo reale. Ogni riga sospetta viene immediatamente inoltrata al manager, che applica le sue regole di correlazione predefinite. In meno di un minuto, la dashboard si accende mostrando la gravità della situazione.

816 eventi registrati in pochissimi minuti. Tutti classificati come authentication_failure. Fortunatamente, zero successi.

Qui risiede la differenza cruciale tra IDS e SIEM:

• L'IDS (il Wazuh agent installato su HIDS-Barno) si occupa di rilevare il singolo evento anomalo a livello locale sull'host.
• Il SIEM (il Wazuh manager centralizzato) correla tali eventi - comprende che 816 fallimenti ravvicinati non sono eventi casuali, bensì un pattern di attacco coordinato.

Dopo pochi minuti di attività, la dashboard popola automaticamente le sezioni relative alla mappatura MITRE ATT&CK:

T1110 - Brute Force (sotto la tattica di Credential Access). Il SIEM ha classificato autonomamente il comportamento rilevato correlandolo con le tattiche reali documentate nel framework MITRE.

Prevention - da HIDS a HIPS

#

La semplice rilevazione (detection) ci dice che siamo sotto attacco, ma non impedisce all'attaccante di continuare a bussare. Per proteggere attivamente la macchina, passiamo alla fase di prevenzione configurando fail2ban come nostro sistema di prevenzione delle intrusioni sull'host:

# /etc/fail2ban/jail.local
[DEFAULT]
banaction = ufw

[sshd]
enabled = true
maxretry = 5
findtime = 60
bantime = 300

La regola è semplicissima: se vengono rilevati 5 tentativi di login falliti entro una finestra temporale di 60 secondi, l'IP dell'attaccante viene bandito per 300 secondi (5 minuti).

Applichiamo la configurazione e rilanciamo Hydra, tenendo d'occhio il log di fail2ban:

sudo tail -f /var/log/fail2ban.log

Il log descrive chiaramente la dinamica in tempo reale:

Found 192.168.64.200  ×8   → fail2ban conta i tentativi
Ban 192.168.64.200         → soglia superata, IP bloccato
...300 secondi...
Unban 192.168.64.200       → ban scaduto
Found 192.168.64.200  ×4   → Hydra riprende
Ban 192.168.64.200         → bannata di nuovo

Su Kali, Hydra si arresta improvvisamente ricevendo una sfilza di errori Connection refused. Il brute force viene troncato all'istante.

Ecco visualizzato l'intero flusso di detection e prevenzione in questo scenario:

sequenceDiagram
    autonumber
    actor Kali as Attaccante (Kali)
    participant SSH as SSH Daemon
    participant HIDS as Wazuh Agent (HIDS)
    participant SIEM as Wazuh Manager (SIEM)
    participant HIPS as Fail2ban (HIPS)
    participant Firewall as UFW/iptables (Firewall)

    Kali->>SSH: Tentativi Brute Force SSH (Hydra)
    SSH->>HIDS: Scrive fallimenti in auth.log
    HIDS->>SIEM: Invia log in tempo reale
    SIEM-->>SIEM: Correlazione eventi (MITRE T1110)
    SIEM-->>SIEM: Genera alert in dashboard

    HIPS->>SSH: Legge auth.log
    Note over HIPS: Rilevati >5 tentativi falliti
    HIPS->>Firewall: Aggiunge regola di BAN per 192.168.64.200
    Kali-XSSH: Tentativi successivi BLOCCATI (Connection refused)

In questo momento il sistema non si limita più a fare reportistica passiva, ma reagisce ed interviene. Wazuh e fail2ban cooperano idealmente per chiudere la falla: fail2ban agisce a livello di firewall di sistema bloccando il traffico dell'IP incriminato alla radice.

fail2ban + UFW: dove appare il ban

#

Per default, fail2ban scrive le regole di ban direttamente in iptables, bypassando UFW. Il ban funziona, ma è invisibile a ufw status - due strumenti che gestiscono lo stesso firewall senza saperlo l'uno dell'altro.

Configurando banaction = ufw in /etc/fail2ban/jail.local, fail2ban delega il blocco a UFW. Il risultato è immediatamente leggibile:

$ sudo ufw status numbered
[ 1] Anywhere   REJECT IN   192.168.64.200   # by Fail2Ban after 5 attempts against sshd
[ 2] 22/tcp     ALLOW IN    Anywhere

La posizione [1] non è casuale. fail2ban usa ufw insert 1 per inserire la regola in cima alla catena. UFW valuta le regole in ordine sequenziale: la prima che fa match vince. Se il REJECT fosse in posizione [3], la regola ALLOW 22/tcp in [2] vincerebbe per prima e il ban non avrebbe effetto. L'ordine è la difesa.

Questo è un vero HIPS (Host-based Intrusion Prevention System) in azione.

Rete vs Host: la distinzione di comportamento

#

Questo laboratorio dimostra che la distinzione tra IDS e IPS non è legata al prodotto software specifico, bensì al suo comportamento e al punto in cui è posizionato nella catena difensiva:

"Inline" significa che il traffico di rete passa fisicamente o logicamente attraverso il dispositivo di sicurezza prima di poter raggiungere la destinazione finale. Solo un NIPS (come Suricata configurato con nfqueue) agisce in modalità inline bloccando i singoli pacchetti malevoli prima che raggiungano la porta del servizio.

Wazuh e fail2ban operano in modo diverso: bloccano i tentativi futuri alterando le regole del firewall, ma i pacchetti dei tentativi che hanno innescato il ban sono già stati interamente ricevuti ed elaborati dall'host.

Nel nostro laboratorio, Wazuh si è fatto carico contemporaneamente di tre ruoli: SIEM (aggregazione e correlazione centralizzata), HIDS (monitoraggio locale dell'host), e grazie all'integrazione e al lavoro congiunto con le regole di sistema, assume le vesti di HIPS bloccando la minaccia. Tre cappelli diversi per un unico grande obiettivo difensivo.

Nel prossimo articolo sposteremo il raggio d'azione sul perimetro di rete, introducendo Suricata come NIDS per intercettare e analizzare il traffico di rete ancora prima che possa toccare il nostro server.

exit 0

#

La sicurezza multilivello non si ottiene installando più software, ma facendoli parlare tra loro. Un HIDS rileva quello che un firewall ignora. Un HIPS blocca quello che un semplice IDS descriverebbe passivamente in un report il giorno dopo.

Quando configuri un server, non chiederti solo quale tool installare, ma come integrare la detection con la response. Il brute force fa rumore; sfruttare quel rumore per sbarrare la porta in faccia all'attaccante in tempo reale è l'inizio di una vera difesa.

Comandi usati: ssh · tail · sudo Concetti correlati: network-defense · observability · iam Approfondimento tecnico: IDS/IPS - Intrusion Detection e Prevention · Wazuh - Architettura e Funzionamento · iptables - Gestione Regole di Rete