CY376 Blue-Team-Projekt — pfSense-DMZ, Suricata IDS/IPS und automatisierte Host-Härtung gegen CVE-2014-6271
CY376: Netzwerküberwachung, Sicherheit und Auditing — Projekt zum Semesterende Blue Team | University of Mines and Technology, Tarkwa
Autor: Kennedy Kumi Holomah Indexnummer: FCM.41.018.148.23 Studenten-ID: 9013004623
Dieses Projekt erstellt, sichert und überwacht eine demilitarisierte Zone (DMZ), die einen öffentlich erreichbaren Ubuntu/Apache-Webserver hinter einer pfSense-Firewall hostet, vollständig innerhalb eines isolierten VMware-Workstation-Labors. Es wurde als Blue-Team-Übung für CY376 (Netzwerküberwachung, Sicherheit und Auditing) an der University of Mines and Technology, Tarkwa, erstellt und demonstriert einen vollständigen defensiven Lebenszyklus statt nur einer einzelnen Kontrolle: eine segmentierte Netzwerkgrenze, Inline-Erkennung an dieser Grenze, ein realer Exploit-Versuch gegen eine benannte CVE, automatisierte Behebung und eine erneute Validierung, dass der Fix die Lücke tatsächlich geschlossen hat.
Das Projekt kombiniert bewusst jede Verteidigungsebene mit Nachweisen statt nur einem Konfigurations-Screenshot: Es wird gezeigt, wie Suricatas Erkennung einen Live-Shellshock-Exploit-Versuch in Echtzeit abfängt, wie dieselbe Payload nach der Härtung schlichtweg fehlschlägt, und die nicht offensichtlichen Infrastrukturprobleme, die auf dem Weg auftraten (Hardware-Offload-Einstellungen, die stillschweigend die Paketerfassung blockierten, die standardmäßige HOME_NET-Eingrenzung, die stillschweigend gerichtete Signaturen brach, und die eigene Berechtigungssperre eines Härtungsskripts, die den Server, den es schützen sollte, lahmlegte), werden als eigene Befunde dokumentiert und nicht herausredigiert.
HOME_NETscripts/dmz_web_hardening.sh) patcht Bash, deaktiviert den CGI-Handler, auf den Shellshock angewiesen ist, beschränkt SSH auf das LAN, aktiviert eine Host-Firewall (UFW) und fail2ban und sperrt die Berechtigungen des Web-Roots.Vollständiger Bericht, Beweis-Screenshots und Analyse: docs/CY376_DMZ_Report_Kennedy_Kumi_Holomah.pdf.
| Host | Rolle | Schnittstelle / VMnet | IP-Adresse |
|---|---|---|---|
| pfSense | Firewall / Router | WAN (em0) | 192.168.248.138 (DHCP, NAT) |
| pfSense | Firewall / Router | LAN (em2) | 192.168.20.1/24 |
| pfSense | Firewall / Router | DMZ (em1) | 192.168.10.1/24 |
| Kali Linux | Angreifer-Host | VMnet4 (LAN) | 192.168.20.102 |
| LAN-Client | Allgemeiner LAN-Host | VMnet4 (LAN) | 192.168.20.100 |
| DMZ-Webserver | Ziel / geschütztes Asset | VMnet3 (DMZ) | 192.168.10.10 |
| Wazuh-Manager | SIEM-/Protokollplattform | VMnet4 (LAN) | 192.168.20.103 |
Der gesamte Verkehr zwischen den Segmenten läuft ausschließlich über pfSense; kein Pfad umgeht die Firewall.
.
├── README.md
├── .gitignore
├── scripts/
│ └── dmz_web_hardening.sh # Host hardening script for the DMZ web server
├── docs/
│ └── CY376_DMZ_Report_Kennedy_Kumi_Holomah.pdf # Full project report
└── evidence/
└── figure01_lab_topology.png ... figure11_wazuh_dashboard.png
# The 11 captioned screenshots from the report, numbered to match
# the figure numbers used throughout docs/CY376_DMZ_Report_*.pdf
scripts/dmz_web_hardening.sh zielt auf den DMZ-Ubuntu/Apache-Host ab. Es ist so geschrieben, dass es sicher erneut ausgeführt werden kann: Jede Konfigurationsdatei, die es anfasst, wird zuerst gesichert (Suffix .bak-YYYYmmdd-HHMMSS), und alle Aktionen werden in eine mit Zeitstempel versehene Datei unter /var/log protokolliert.
# On the DMZ web server
sudo bash scripts/dmz_web_hardening.sh
Prüfen Sie vor der Ausführung den Abschnitt CONFIG am Anfang des Skripts (LAN-Subnetz, HTTP/HTTPS-Ports), damit er zu Ihrer eigenen Topologie passt.
Was es tut:
mod_cgi/mod_cgid auf (wodurch die Shellshock-Angriffsfläche vollständig entfernt wird) und sperrt Besitz/Berechtigungen des Web-Roots.Am Ende wird eine Zusammenfassung der abgeschlossenen Schritte ausgegeben; die vollständigen Details zu jedem Schritt finden sich im Bericht.
| Test | Vor der Härtung | Nach der Härtung |
|---|---|---|
| Shellshock-Exploit-Versuch | Payload akzeptiert; Suricata-Alarm ausgelöst (SID 2022028) | HTTP 404 — CGI-Handler entfernt |
| SSH aus dem LAN (Kali) | Verfügbar, uneingeschränkt | Verfügbar, auf 192.168.20.0/24 beschränkt |
| Zugriff auf Web-Root | Stellte Standardinhalt bereit | Kurzzeitig 403 während der Härtung, dann wiederhergestellt |
| Benutzerdefinierte Suricata-Drop-Regel | N/A | Aktive Blockierung bei Treffer bestätigt |
Siehe Abschnitt 6 (Analyse und Empfehlungen) des Berichts für die vollständige Diskussion.