Home SOC: Laboratorio di Rilevamento Minacce con Wazuh + Suricata

Un laboratorio autogestito di Security Operations Center progettato per rilevare tecniche di attacco reali contro un target deliberatamente vulnerabile, utilizzando Wazuh come SIEM e Suricata come sensore IDS basato sulla rete. Costruito per dimostrare competenze di detection engineering — non solo l'implementazione di strumenti.

Panoramica

Il lavoro moderno in un SOC non si limita a "installare un SIEM e guardare la dashboard." Si tratta di capire perché esiste un gap di rilevamento, e sapere come colmarlo. Questo laboratorio simula un piccolo ambiente realistico: un box attaccante, un target legacy/vulnerabile senza supporto nativo per il logging, e uno stack SIEM che deve aggirare questo vincolo utilizzando la visibilità a livello di rete invece di agent host.

Decisione architetturale chiave: il target (Metasploitable 2) esegue un sistema operativo troppo vecchio per supportare un agente Wazuh moderno o anche un forwarder syslog con accesso a internet. Invece di considerarlo un blocco, il progetto si orienta verso il rilevamento completo basato sulla rete tramite Suricata — un pattern realistico per asset legacy, IoT o OT che non possono essere strumentati direttamente.

Architettura

┌─────────────┐         attacks          ┌──────────────────────┐
│   Kali VM   │ ────────────────────────▶│   Metasploitable 2   │
│ (attacker + │                           │  (unmonitored victim, │
│  Suricata   │                           │   no agent, no       │
│  sensor +   │                           │   internet access)   │
│  Wazuh agent│                           └──────────────────────┘
└──────┬──────┘
       │ eve.json (Suricata alerts/events)
       │ forwarded via Wazuh agent
       ▼
┌─────────────────────┐
│   Wazuh Manager      │
│   (Amazon Linux 2023)│
│   Indexer + Dashboard│
└─────────────────────┘

Tutte e tre le VM girano su VirtualBox, in rete NAT su 192.168.0.0/24.

Perché Suricata gira sul box attaccante

Suricata ha bisogno di visibilità sul traffico tra l'attaccante e il target. Esistono due opzioni: una VM sensore dedicata con interfaccia promiscua/rispecchiata, o eseguire il sensore su uno dei due host già nel percorso del traffico. Poiché il manager Wazuh (Amazon Linux 2023) non ha supporto EPEL e rendeva poco pratica l'installazione di Suricata, e il target non può eseguire alcun agente, Suricata gira direttamente sul box Kali. Ciò significa che vede il 100% del traffico di attacco sulla propria interfaccia senza necessità di modalità promiscua o porta span, e invia i suoi eventi al manager tramite l'agente Wazuh già registrato su Kali.

Rilevamenti

1. Ricognizione — Rilevamento Scan Nmap

Attacco:

nmap -sV -A 192.168.0.138

Rilevamento: Il ruleset Emerging Threats di Suricata ha segnalato in tempo reale diverse firme relative a scan e anomalie di protocollo man mano che lo scan toccava ogni porta aperta, incluso il traffico sul servizio UnrealIRCd esposto di Metasploitable (ET CHAT IRC USER command).

Risultato: 132+ eventi IDS generati e correttamente classificati sotto i gruppi di regole ids, suricata nella vista Threat Hunting di Wazuh entro secondi dal completamento dello scan.

2. Sfruttamento — Backdoor vsftpd 2.3.4 (CVE-2011-2523)

Attacco:

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 > set RHOSTS 192.168.0.138
msf6 > set LHOST 192.168.0.200
msf6 > run

Il vsftpd 2.3.4 di Metasploitable contiene una backdoor attivata da una stringa di login FTP malformata, che apre una shell root sulla porta TCP 6200. L'exploit è atterrato pulito e ha restituito una sessione Meterpreter come root.

Rilevamento: La firma GPL ATTACK_RESPONSE id check returned root di Suricata (SID 2100498) è scattata 11 secondi dopo l'apertura della shell, corrispondendo alla stringa in chiaro uid=0(root) nell'output dei comandi della shell mentre attraversava il cavo sulla porta 6200.

"signature": "GPL ATTACK_RESPONSE id check returned root",
"signature_id": 2100498,
"src_ip": "192.168.0.138",
"src_port": 6200,
"dest_ip": "192.168.0.200",
"direction": "to_client"

Perché è importante: questa è la conferma a livello di rete di un compromesso root su un asset con zero logging host-based — lo scenario esatto per cui l'architettura è stata progettata.

3. Attacco alle Credenziali — Brute Force FTP (MITRE ATT&CK T1110)

Attacco:

hydra -l msfadmin -P /tmp/quicklist.txt -t 4 ftp://192.168.0.138

Hydra ha tentato più login FTP in rapida successione, identificando correttamente la coppia di credenziali valida msfadmin:msfadmin dopo diversi tentativi falliti.

Stato del rilevamento: Il parser del protocollo FTP di Suricata ha catturato ogni singolo comando USER/PASS e codice di risposta del server in eve.json (event_type: ftp), confermato presente nell'archivio eventi raw del manager:

{"event_type":"ftp","src_ip":"192.168.0.200","dest_ip":"192.168.0.138",
 "dest_port":21,"ftp":{"command":"PASS","command_data":"root",
 "completion_code":["530"],"reply":["Login incorrect."]}}

Il ruleset predefinito di Suricata non ha una firma dedicata per il brute-force FTP, poiché è un pattern di protocollo piuttosto che una stringa nota come dannosa. È stata progettata una regola di correlazione personalizzata di Wazuh per colmare questa lacuna:

<group name="suricata,ftp,brute_force,">
  <rule id="100100" level="5">
    <if_sid>86600</if_sid>
    <field name="event_type">^ftp$</field>
    <field name="data.ftp.command">^PASS$</field>
    <description>Suricata: FTP password attempt detected on $(data.dest_ip)</description>
  </rule>

  <rule id="100101" level="10" frequency="4" timeframe="60">
    <if_matched_sid>100100</if_matched_sid>
    <description>Suricata: Possible FTP brute force attack detected - multiple password attempts within 60 seconds</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Stato: in corso — i dati degli eventi sottostanti arrivano confermatamente al manager, e la sintassi delle regole è stata validata tramite wazuh-logtest, ma la regola di correlazione (100101) non sta ancora scattando in modo affidabile end-to-end. Il prossimo passo di debug è confermare il percorso del campo decodificatore assegnato ai campi FTP annidati di Suricata al momento del parsing tramite wazuh-logtest su un campione live. Tracciato come lavoro futuro qui sotto.

Lezioni Apprese

• I target legacy cambiano la tua architettura, non solo i tuoi comandi. La toolchain obsoleta di Metasploitable 2 ha escluso un agente Wazuh moderno e persino il semplice forwarding syslog (nessun rsyslog, nessun accesso a internet). Invece di forzare un approccio basato su host, il progetto si è orientato verso il rilevamento basato sulla rete — probabilmente un pattern più realistico per asset legacy/IoT del mondo reale.

• Gli ecosistemi dei pacchetti non sono intercambiabili. La base Amazon Linux 2023 del manager Wazuh non supporta il classico EPEL, il che ha bloccato un'installazione diretta di Suricata lì. Spostare il sensore sul box Kali basato su Debian, che già si trovava nel percorso del traffico, ha aggirato completamente il problema.

• I ruleset IDS predefiniti sono basati su firme, non comportamentali. Suricata ha catturato l'exploit vsftpd all'istante perché esisteva una firma nota, ma non aveva nulla per il brute-force FTP perché quello è un pattern, non una stringa statica. Questa è la vera giustificazione per scrivere regole di correlazione personalizzate in un SIEM piuttosto che affidarsi solo ai contenuti IDS out-of-the-box.

• archives.log/archives.json non sono abilitati per impostazione predefinita (logall/logall_json sono no out of the box) e sono essenziali per il debug di ciò che un SIEM ha effettivamente ricevuto rispetto a ciò che ha scelto di segnalare.

Lavori Futuri

• Completare il debug end-to-end della regola di correlazione per brute-force FTP (100100/100101)
• Aggiungere lo sfruttamento della backdoor UnrealIRCd (CVE-2010-2075) come quarto rilevamento, poiché Suricata sta già segnalando traffico IRC sul target
• Aggiungere la RCE usermap_script di Samba (CVE-2007-2447) come quinta tecnica
• Collegare gli avvisi ad alta severità a TheHive o Shuffle per la creazione automatizzata di casi
• Aggiungere una risposta attiva per bloccare automaticamente l'IP attaccante in caso di rilevamenti ripetuti di brute-force

Strumenti Utilizzati

• Wazuh 4.14.6 — SIEM (manager, indicizzatore, dashboard)
• Suricata 8.0.5 — IDS di rete
• Metasploit Framework / Hydra / Nmap — simulazione di attacco
• VirtualBox — virtualizzazione laboratorio

Mappatura MITRE ATT&CK