Eigenes Netzwerk-basiertes IDS mit Snort, Vagrant und Syscall-Hooks bauen

Einleitung: Warum ein eigenes NIDS?

In Zeiten von KI-gestützten Angriffen und raffinierter Malware ist ein Netzwerk-basiertes Intrusion Detection System (NIDS) unverzichtbar. Stell dir vor, du bist der Sicherheitsbeauftragte einer Schule – plötzlich tauchen verdächtige Dateien im Netzwerk auf. Mit einem selbst gebauten NIDS kannst du verdächtige Binärdateien automatisch erkennen, isolieren und analysieren. Dieses Tutorial führt dich durch die praktische Umsetzung mit Vagrant, Snort, Syscall-Hooks und rsyslog – inspiriert von aktuellen Themen wie KI-Sicherheit und Schulnetzwerken.

Projektübersicht: Drei Maschinen, ein Ziel

Unser Setup besteht aus drei virtuellen Maschinen:

• mal (IP: 192.168.50.2) – sendet bösartige Binärdateien per FTP.
• vicky (IP: 192.168.50.3) – empfängt Dateien, erzeugt Snort-Logs und leitet sie an sandy weiter.
• sandy (IP: 192.168.50.4) – isolierte Sandbox, die Binärdateien mit einem LKM auf bösartige Syscalls prüft.

Dieses Szenario ist typisch für moderne Netzwerksicherheit in Unternehmen und Bildungseinrichtungen. Du lernst, wie Angreifer vorgehen und wie du dich schützt – ein heißes Thema in der IT-Sicherheit.

Schritt 1: Umgebung mit Vagrant aufsetzen

Zunächst installierst du Vagrant und VirtualBox. Lade das bereitgestellte Vagrantfile herunter und führe vagrant up aus. Damit werden drei headless Maschinen gestartet. Du kannst per vagrant ssh mal, vagrant ssh vicky und vagrant ssh sandy auf sie zugreifen. Dieser automatisierte Aufbau spart Zeit und ist ideal für praktische Übungen in der Hochschule.

Schritt 2: Dateiübertragung per FTP testen

Melde dich auf mal an und verbinde dich per FTP mit vicky:

$ ftp 192.168.50.3

Mit Benutzername vagrant und Passwort vagrant kannst du eine Testdatei senden. Der vsftpd-Dienst läuft bereits. Diese Übung zeigt, wie einfach Dateien im Netzwerk übertragen werden – und warum ein NIDS nötig ist.

Schritt 3: Snort-Regel für ausführbare Dateien

Auf vicky konfigurierst du Snort, um den FTP-Verkehr zu überwachen. Eine Regel könnte so aussehen:

alert tcp any any -> any 21 (msg:"EXE-Datei entdeckt"; content:".exe"; sid:1000001;)

Beachte: Eine der bereitgestellten Beispieldateien ist keine ausführbare Datei – deine Regel sollte sie nicht auslösen. Das testest du, indem du die Datei überträgst und prüfst, ob ein Alert erscheint. Snort-Regeln sind das Herzstück jedes Netzwerk-IDS.

Schritt 4: Daemon für Log-Übertragung (vicky → sandy)

Schreibe einen Daemon (z. B. als Bash-Skript), der neue Snort-Logs (PCAP-Dateien) automatisch per FTP an sandy sendet. Vermeide Duplikate, indem du bereits gesendete Dateien in einer Log-Datei vermerkst. Hier ein einfaches Beispiel:

#!/bin/bash
while true; do
   inotifywait -e create /var/log/snort/*.pcap
   # Sende Datei an sandy
   ftp -inv 192.168.50.4 <> /var/log/sent.log
   sleep 2
done

Dieser Daemon für Log-Übertragung sorgt für eine automatisierte Reaktionskette – ähnlich wie bei modernen SOAR-Systemen in der Cybersicherheit.

Schritt 5: LKM für Syscall-Überwachung auf sandy

Nutze dein bestehendes LKM aus Lab 3 oder das bereitgestellte hooks.c. Es fängt verdächtige Syscalls (z. B. execve, fork) ab und protokolliert sie im Kernel-Log. Passe es an, um die spezifischen bösartigen Syscalls aus Projekt 4 zu erkennen. Dieses Syscall-Hook-Verfahren wird auch in modernen Sandboxing-Lösungen wie Firejail oder Docker eingesetzt.

Schritt 6: Daemon für Binäranalyse auf sandy

Erstelle einen weiteren Daemon, der neue PCAP-Dateien überwacht, die Binärdatei extrahiert (z. B. mit tcpdump oder binwalk) und sie mit dem geladenen LKM ausführt. Die Ergebnisse landen im Kernel-Log. Dieser automatische Malware-Analyse-Daemon ist die Grundlage für erweiterte Bedrohungserkennung.

Schritt 7: rsyslog konfigurieren

Richte rsyslog so ein, dass Kernel-Meldungen deines LKM in die Datei /var/log/ids_alerts.log geschrieben werden. Füge dazu in /etc/rsyslog.conf oder einer neuen Datei in /etc/rsyslog.d/ folgende Zeile ein:

kern.*    /var/log/ids_alerts.log

Starte rsyslog neu: sudo systemctl restart rsyslog. Nun werden alle Syscall-Alarme in einer separaten Logdatei gesammelt – praktisch für die Forensik und Incident Response.

Bonus: Verhalten bösartiger Binärdateien erkennen

Überlege, welche Verhaltensweisen typisch für Malware sind (z. B. häufiges Öffnen von Netzwerkverbindungen, Schreiben in /etc). Du kannst zusätzliche Regeln in deinem LKM oder in rsyslog hinterlegen, um solche Muster zu alarmieren. Ein verhaltensbasiertes IDS ist aktuell ein heißes Thema in der KI-Sicherheit – ähnlich wie bei Next-Gen-AV.

Bonus: Zeek als Alternative zu Snort

Installiere Zeek (früher Bro) auf vicky und konfiguriere es, um die ausführbaren Dateien zu erkennen. Zeek protokolliert Verbindungen und kann Dateien extrahieren. Vergleiche die Ergebnisse mit Snort. Zeek wird oft in Forschungsumgebungen und Hochschulprojekten eingesetzt, da es flexibler ist.

Fazit

Du hast nun ein funktionierendes Netzwerk-basiertes IDS mit Vagrant, Snort, Syscall-Hooks und rsyslog aufgebaut. Dieses Projekt zeigt, wie moderne Netzwerksicherheit in der Praxis aussieht – von der Dateiübertragung bis zur automatischen Analyse. Mit den Bonusaufgaben kannst du dein System noch erweitern. Viel Erfolg bei deinem CS6264-Projekt!