Laboratorio di Cyber Security: Infrastruttura Blue Team e Difesa di Rete

Questo progetto di laboratorio dimostra la creazione di un'infrastruttura "Blue Team" integrata, focalizzata sulla sicurezza di rete centralizzata, sui sistemi di rilevamento/prevenzione delle intrusioni (IDS/IPS) e sulla gestione delle informazioni e degli eventi di sicurezza (SIEM) utilizzando pfSense.

---

1. Configurazione dell'Ambiente e Architettura di Rete

L'ambiente di laboratorio è progettato in un contesto virtualizzato (VMware) utilizzando principi di segmentazione della rete:

Specifiche delle Macchine Virtuali

• pfSense (Firewall): 1 GB di RAM, 4 vCPU | Schede di rete: Bridged + VMnet1 + VMnet2
• Ubuntu Server (ELK): 192.168.10.55 | 2-4 GB di RAM (con allocazione minima delle risorse per Elasticsearch)
• Windows (Vittima): 4 GB di RAM, 4 vCPU | Scheda di rete: VMnet1 (LAN)
• Kali Linux (Attaccante): 2 GB di RAM, 4 vCPU | Scheda di rete: VMnet2 (OPT1/Attack)

Interfacce di Rete e Allocazione degli IP

Per garantire la sicurezza, le macchine dell'attaccante e della vittima sono collocate in sottoreti separate:

---

2. Meccanismi di Sicurezza e Difesa

Configurazione di Suricata IDS/IPS

• Modalità Operativa: Suricata è abilitato in modalità Inline IPS (netmap) per bloccare le minacce. Per garantire la stabilità, il tipo di scheda di rete della VM è stato impostato su E1000 con Promiscuous mode abilitato.
• Set di Regole: L'ispezione profonda dei pacchetti (DPI) viene applicata utilizzando i set di regole emerging-exploit, emerging-scan e emerging-malware.
• Regola Personalizzata: Se vengono rilevati 20 o più tentativi di connessione SYN verso il target entro 10 secondi, viene attivato un avviso "Nmap Scan" e l'IP dell'attaccante (192.168.20.50) viene automaticamente aggiunto alla lista "Block Offenders".

SIEM (Elastic Stack) e Gestione dei Log

• Inoltro dei Log: I log di pfSense vengono inoltrati tramite Remote Syslog al server 192.168.10.55 sulla porta 5140. I log di Suricata vengono esportati in formato EVE JSON e inseriti in ELK tramite Filebeat.
• Criteri di Controllo di Windows: "Audit Logon Events" (Event ID 4625) è stato attivato sulla macchina Windows per consentire il monitoraggio dei tentativi di accesso non riusciti (Brute-Force) all'interno del SIEM.

---

3. Test, Validazione e Risoluzione dei Problemi

Le principali sfide e le soluzioni implementate durante la configurazione del laboratorio includono:

• Problema: Gli attacchi non erano visibili nel firewall o in Suricata.
  • Soluzione: L'attaccante (Kali) e la vittima (Windows) erano sulla stessa sottorete, impedendo al traffico di passare attraverso il firewall. Kali è stata spostata su un'interfaccia isolata separata (OPT1).
• Problema: Gli attacchi brute-force non comparivano nel SIEM.
  • Soluzione: Sono stati abilitati i criteri di controllo nei criteri di sicurezza locali di Windows per garantire la generazione dei log con Event ID 4625.
• Problema: Il server ELK andava in crash durante l'afflusso di dati.
  • Soluzione: L'allocazione di RAM per la macchina host e per la Java Virtual Machine (JVM) di Elasticsearch è stata aumentata a 2-4 GB.

---

4. Scenari di Verifica del Progetto

1. Connettività di Rete: Il routing è stato verificato tramite pfSense, confermando il traffico inter-rete e le regole di isolamento.
2. Simulazione di Attacco: Le scansioni nmap -sS da Kali Linux sono state rilevate istantaneamente da pfSense e l'IP dell'attaccante è stato bloccato con successo.
3. Monitoraggio: Le simulazioni di brute-force tramite Hydra e gli avvisi di Suricata sono stati monitorati con successo in tempo reale tramite la dashboard di Kibana.

---

Nota: Questo progetto è un ambiente di laboratorio di cybersicurezza completo, realizzato esclusivamente a scopo educativo e pratico.