network-security-snort

Snort 3 IDS → IPS Labor auf Kali. Benutzerdefinierte Erkennungsregeln + iptables-Durchsetzung gegen ICMP-Aufklärung, Nmap-SYN-Scans, Hydra FTP Brute-Force und vsftpd 2.3.4 Hintertür (CVE-2011-2523).

Netzwerktopologie

Der gesamte Datenverkehr zwischen Angreifer und Metasploitable wird durch den Analysator geleitet, was ihn zum natürlichen Engpass sowohl für die Überwachung als auch für die Durchsetzung macht.

Ersetzen Sie diese ASCII-Skizze durch screenshots/01-network-topology.png, sobald die Abbildung vorhanden ist: Topologie

Methodik

Das Labor wird in zwei Phasen mit einer identischen Vier-Vektor-Angriffskette durchgeführt:

1. ICMP-Aufklärung – ping zur Host-Erkennung
2. Nmap SYN-Scan – nmap -sS zur Port-Enumeration (1000 Ports)
3. Hydra FTP-Brute-Force – Angriff auf Zugangsdaten gegen den vsftpd-Dienst
4. vsftpd 2.3.4 Backdoor – Metasploit-Exploit für CVE-2011-2523

Phase 1 (IDS) führt Snort passiv auf dem Analysator mit fünf benutzerdefinierten Regeln aus – beobachten Sie die Alarme in Echtzeit, bestätigen Sie, dass der Angriff trotzdem erfolgreich ist.

Phase 2 (IPS) kombiniert Snort mit einer iptables-Durchsetzungsschicht mittels präziser Drop-Regeln – bestätigen Sie, dass Angriffe blockiert werden, während ICMP-Ping und legitime FTP-Anmeldung funktionsfähig bleiben.

Vorbereitende Einrichtung

1. Konfigurieren Sie den Analysator mit drei NICs in VMware (zwei Host-only, eine NAT/Bridged).
2. Aktivieren Sie IP-Weiterleitung und fügen Sie MASQUERADE + FORWARD-Regeln hinzu, damit der Analysator zwischen Subnetzen und zum WAN routet – siehe scripts/router_config.sh.
3. Überprüfen Sie die End-to-End-Konnektivität von jeder VM mit scripts/ping_check.sh, bevor Sie Snort installieren.

Snort-Konfiguration

Snort wird über den Kali-Paketmanager installiert (sudo apt install snort -y) und in /etc/snort/snort.conf konfiguriert:

HOME_NET deckt beide internen Subnetze ab, sodass Snort den gesamten verkehr zwischen Subnetzen auf dem Analysator als prüfenswert betrachtet. alert_fast erzeugt kompakte einzeilige Alarme (paketweise Protokollierung würde übermäßiges Volumen erzeugen).

Konfigurationsvalidierung:

Benutzerdefinierte Erkennungsregeln

Fünf Regeln in /etc/snort/rules/local.rules (vollständige Datei in scripts/local.rules):

Phase 1 – IDS-Modus

Snort läuft im passiven Modus auf beiden internen Schnittstellen:

Die Startausgabe bestätigt pcap DAQ configured to passive – Snort sieht jedes Paket, kann aber keines verwerfen oder modifizieren.

IDS-Ergebnisse

Nach Ausführung von scripts/attack_simulator.sh vom Angreifer:

Das IDS hat alles erkannt und nichts gestoppt. Dies ist die zentrale Lehre aus Phase 1: Ein funktionierendes IDS ohne Durchsetzung ist ein Alarmsystem, kein Schloss. Wenn ein menschlicher Analyst die Alarme liest, ist der Angreifer bereits Root.

Eine sekundäre Beobachtung: Snorts integrierte Regeln (116:408, 116:414) schlagen bei DHCP-Broadcast-Verkehr an – nicht böswillig, aber in einer Produktionsumgebung bräuchte es Unterdrückungsregeln, um das Alarmprotokoll handhabbar zu halten.

Phase 2 – IPS-Modus

Die IPS-Schicht wird mit scripts/ips_setup.sh bereitgestellt, welche:

1. Bestehende iptables-Regeln leert
2. IP-Weiterleitung wieder aktiviert und Basis-Routing erneut anwendet
3. Vier präzise Drop-Regeln anwendet, die auf bestimmte Angriffssignaturen abzielen
4. Snort im Daemon-Modus (-D) für fortlaufende Protokollierung startet

iptables-Regeln

IPS-Ergebnisse

Das gleiche Angriffsskript wurde erneut vom Angreifer ausgeführt:

Normaler Datenverkehr erhalten

Zwei manuelle Überprüfungen bestätigten die selektive Durchsetzung:

• ping -c 4 192.168.50.10 → 4 Pakete gesendet, 4 empfangen, 0% Verlust
• ftp 192.168.50.10 mit msfadmin:msfadmin → 220 (vsFTPd 2.3.4) … 230 Login successful

Quantitativer Nachweis aus iptables-Paketzählern während des Laufs: 2051 Pakete akzeptiert, 12 Pakete durch die FTP-Connlimit-Regel verworfen, 808 ICMP-Pakete akzeptiert – selektive Durchsetzung in Zahlen.

Fortlaufende Snort-Protokollierung

Selbst im IPS-Modus löste Snort weiterhin SID 1000002 / 1000003-Alarme bei Paketen aus, die seinen passiven Inspektionspunkt erreichten, bevor iptables nachfolgende Pakete verwarf – das bedeutet, iptables sorgt für Durchsetzung, während Snort für Audit-Protokollierung sorgt, und beide arbeiten zusammen.

IDS vs. IPS – Nebeneinander-Ergebnisse

Diskussion

Wurden alle simulierten Angriffe im IDS-Modus erkannt?

Ja – jede der SIDs 1000001–1000004 feuerte während der Angriffssimulation korrekt:

• ICMP-Ping (1000001) – bidirektionale Alarme für jedes Echo/Antwort.
• Nmap SYN-Scan (1000003) – Flut von Alarmen innerhalb von Millisekunden, charakteristische Quellport-Zufallsauswahl.
• FTP-Brute-Force (1000002) – sauberer Audit-Trail der parallelen Verbindungsversuche von Hydra mit genauen Zeitstempeln.
• vsftpd-Backdoor (1000004) – die :)-Inhaltsübereinstimmung erfasste die exakte Exploit-Bytesequenz.

Aber Erkennung ≠ Prävention. Der vsftpd-Exploit öffnete eine Root-Meterpreter-Shell, während alle Alarme feuerten. Ein SOC-Analyst, der das IDS in Echtzeit beobachtet, hätte die Kompromittierung gesehen – aber mit dem Angreifer bereits innerhalb von Sekunden als Root reicht allein das Alarmieren nicht. Dies ist der operative Kern, warum IPS existiert.

Wie effektiv war IPS bei der Blockierung von Angriffen, ohne normalen Verkehr zu beeinträchtigen?

Die Implementierung erreichte eine vollständige Angriffsminderung ohne beobachtbare Auswirkungen auf legitimen Verkehr. Die Effektivität beruht auf präzisem Regeldesign – jede iptables-Regel zielt auf eine Verhaltenssignatur, nicht auf ein breites Protokoll:

• SYN-Ratenbegrenzung unterbricht das Flutmuster von Portscans, ohne normale Handshakes zu beeinträchtigen.
• connlimit pro Quelle blockiert die Parallelität von Brute-Force-Werkzeugen, ohne Einzelsitzungs-FTP zu unterbrechen.
• STRING-Übereinstimmung verwirft die exakte Exploit-Payload, ohne legitimen FTP-Anmeldeverkehr zu filtern.

Eine anerkannte Einschränkung: ICMP ist vollständig erlaubt, was bedeutet, dass ein Angreifer immer noch bestätigen kann, dass Metasploitable lebt. In einer Umgebung mit höheren Sicherheitsanforderungen würde dies ratenbegrenzt oder auf vertrauenswürdige Quellen beschränkt. In diesem Labor ist ICMP der primäre Konnektivitätsprüfmechanismus, daher bleibt es offen.

Dedizierte Snort-Maschine vs. pfSense/OPNsense-Plugin

Dieses Labor verwendet eine dedizierte Snort-Maschine. Im Vergleich zur Ausführung von Snort als Plugin in einer Firewall-Appliance wie pfSense oder OPNsense:

Vorteile des dedizierten Ansatzes:

• Leistungsisolation – volle CPU und RAM exklusiv für die Paketinspektion verfügbar; keine Konkurrenz mit Routing, DHCP, VPN, DNS.
• Positionierungsflexibilität – das IDS/IPS kann inline, an einem SPAN/Spiegelport oder an einer internen Segmentgrenze platziert werden, um Ost-West-Verkehr zu überwachen, der nie die Perimeter-Firewall erreicht.
• Volle Konfigurationskontrolle – jeder Preprocessor, DAQ-Einstellung, Ausgabe-Plugin und Regelaktualisierungsplan ist über die CLI konfigurierbar. pfSense gibt nur eine Teilmenge über seine GUI frei.
• Resilienz – die IDS/IPS-Maschine kann unabhängig vom Router fehleroffen oder fehlergeschlossen ausfallen. In pfSense bringt ein Snort-Absturz sofort sowohl Routing als auch Erkennung zum Erliegen.

Kompromisse:

• Steilere Lernkurve – erfordert CLI-Kenntnisse und direktes Regel-Set-Management.
• Wartungsaufwand – Regelaktualisierungen, Versionsupgrades, Log-Rotation, alles manuell.

Die dedizierte Snort-Maschine ist die richtige Wahl für Unternehmensumgebungen, die Leistung, Positionierung und Anpassung benötigen. Der pfSense/OPNsense-Plugin-Ansatz ist sinnvoller für kleine Unternehmen oder Heimlabor-Umgebungen, die Benutzerfreundlichkeit priorisieren.

Architekturhinweis

Phase 2 ist technisch passives Snort + iptables-Durchsetzung, nicht Snort im echten Inline-Modus – Snort selbst protokolliert (pcap DAQ configured to passive), und iptables führt das Verwerfen basierend auf Ratenbegrenzungen, String-Übereinstimmungen und Verbindungszahlen durch.

Dies ist ein legitimes und verbreitetes Bereitstellungsmuster (so arbeiten viele reale Linux-basierte IDS/IPS-Stapel). Ein natürlicher nächster Schritt wäre die Migration von Phase 2 zu einer echten Inline-Konfiguration mit snort --daq nfq (oder afpacket im Inline-Modus) mit Snorts reject / drop-Regelaktionen, sodass Snort selbst das Verwerfen basierend auf vollständiger Signaturübereinstimmung durchführt, anstatt es an iptables zu delegieren.

Repository-Struktur

Nachvollziehen des Labors

⚠️ Nur für Laboreinsatz. Diese Skripte führen echte Exploits und Brute-Force-Werkzeuge gegen ein absichtlich verwundbares Ziel aus. Führen Sie sie nicht gegen ein System aus, das Sie nicht besitzen und für das Sie keine ausdrückliche schriftliche Genehmigung zum Testen haben.

1. Bauen Sie drei VMs in VMware gemäß der obigen Topologie (VMnet9 und VMnet10 als Host-only).
2. Auf dem Analysator: Führen Sie scripts/router_config.sh aus, dann scripts/ping_check.sh, um die vollständige Konnektivität zu bestätigen.
3. Installieren Sie Snort 3 auf dem Analysator:
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. Platzieren Sie scripts/local.rules unter /etc/snort/rules/local.rules und setzen Sie HOME_NET = "10.10.10.0/24,192.168.50.0/24" in /etc/snort/snort.conf.
5. Validieren: sudo snort -T -c /etc/snort/snort.conf – erwarten Sie 652 geladene Regeln, 0 Warnungen.
6. Phase 1 – IDS:
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # In einem anderen Terminal:
   sudo tail -f /var/log/snort/alert_fast.txt
   

   Auf dem Angreifer: sudo ./scripts/attack_simulator.sh – beobachten Sie, wie Alarme ausgelöst werden und die Meterpreter-Shell erscheint.
7. Phase 2 – IPS: auf dem Analysator sudo ./scripts/ips_setup.sh ausführen, dann erneut die Angriffskette auf dem Angreifer ausführen. Bestätigen Sie die Blockierungen, dann manuell testen:
   root@kitploit:~

   ping -c 4 192.168.50.10        # sollte erfolgreich sein
   ftp 192.168.50.10              # msfadmin / msfadmin – sollte erfolgreich sein
   

Ethischer Haftungsausschluss

Alle in diesem Repository dokumentierten Aktivitäten wurden ausschließlich innerhalb einer eigenständigen VMware-Virtualisierungslaborumgebung für beaufsichtigte akademische Lernzwecke durchgeführt. Es wurden keine externen, produktions- oder realen Systeme anvisiert, gescannt oder in irgendeiner Weise beeinflusst. Metasploitable 2 ist eine absichtlich verwundbare virtuelle Maschine, die speziell für Sicherheitstrainings entwickelt wurde.

Dieses Material darf nicht verwendet werden, um diese Aktivitäten gegen ein reales System zu replizieren, ohne eine ausdrückliche schriftliche Genehmigung des Systemeigentümers. Unautorisierte Portscans, Zugangsdatenangriffe oder die Ausnutzung von Netzwerkdiensten sind in den meisten Rechtsordnungen illegal.

Lizenz

MIT — siehe LICENSE. Der Laborbericht selbst wird zu Bildungszwecken bereitgestellt.