Auf die Schliche kommen

von Markus Stubbig

Eine Firewall lässt keine bösartigen IP-Pakete durch und schützt das interne Netz vor Gefahren. Was aber, wenn sich der Angreifer bereits im LAN befindet? Hier helfen Systeme zur Intrusion Detection, die das interne Netz nach ungewöhnlichen IP-Paketen absuchen. Suricata ist eine Open-Source-Software für netzwerkbasierte Einbruchserkennung. Wir schildern die Installation und den Umgang mit dem Tool.

Ein Intrusion Detection System (IDS) ist ein Baustein im Sicherheitskonzept. Das netzwerkbasierte IDS (NIDS) untersucht IP-Pakete und vergleicht deren Inhalt mit bekannten Angriffsmustern. Das Ganze erinnert an einen Virenscanner: Inhalt lesen und mit bekannten Signaturen vergleichen. Bei einer Übereinstimmung schlägt die Software Alarm und meldet den Fund an den Admin oder ein Security Information and Event Managementsystem (SIEM).

Daneben gibt es noch das hostbasierte IDS (HIDS), das als Software auf einem Server läuft. Die Software erkennt ungewollte Änderungen im Dateisystem, ungewöhnliche Zugriffe von Anwendungen sowie merkwürdige Netzzugriffe auf den Server. HIDS und NIDS schließen sich nicht aus, sondern ergänzen sich: Das HIDS schützt die Server und das NIDS scannt das Netz zwischen den Servern. Das NIDS Suricata lernt über eine Signaturdatenbank die gängigsten Protokolle und erkennt, welche Clients vom gewünschten Verhalten abweichen. Bei leichten Differenzen meldet das Tool eine Information, bei groben Verstößen einen Alarm.

Suricata installieren

Suricata ist bereits in den Repositorys enthalten, womit eine Installation per Paketmanager schnell abgeschlossen ist. Ein Roll-out als Container ist ebenfalls eine Option – dazu später mehr. Für Red-Hat-basierte Distributionen wie Fedora, CentOS und Rocky übernimmt dnf die Installation:

Unter Debian und Ubuntu klappt es so:

Leider haben die meisten Repositorys noch nicht auf das Major Release 7 umgestellt, sodass Sie für die jüngste Version den Compiler bemühen müssen. Das folgende Beispiel installiert die Abhängigkeiten unter Rocky 9 und kompiliert dann Suricata 7.0:

Den Startschuss gibt der Servicemanager mit systemctl restart suricata. Zu Beginn ist die Signaturdatenbank jedoch leer und das IDS somit wirkungslos. Die lokale Datenbank benötigt einen aktuellen Stand, mit dem Suricata arbeiten kann:

Wenn alles läuft, bunkert Suricata eine fünfstellige Anzahl Regeln im Speicher und hält auf dem lokalen Netzadapter Ausschau nach IP-Paketen.

Alarme auswerten

Suricata formuliert die Alarme im JSON-Format unter dem Namen EVE (Extensible Event Format). Die Felder jeder Meldung verwenden selbsterklärende Namen wie "timestamp", "src_ip" oder "category". Durch die festgelegte Struktur ist eine Alarmmeldung für den menschlichen Betrachter als auch für ein Tool gleichermaßen leicht erkennbar.

Suricata schreibt seine Meldungen in die Logdatei "eve.json". Im Texteditor ist die Ansicht mühsam, da alle JSON-Felder in einer einzelnen Zeile stehen. Hier hilft der Aufhübscher jq, der eine JSON-Meldung für die Konsole optisch aufbereitet (Listing 1). Der Befehl tail -f in Verbindung mit jq zeigt die Meldungen zwar gut lesbar an, aber bei aktivem Netzverkehr flitzen die Alarme in der Konsole nur so durch. Für eine sinnvolle Analyse müssen weitere Tools helfen.

Dazu schicken die Suricata-Entwickler EveBox ins Rennen: den "Suricata Event Manager". EveBox liest die Datei "eve.json" aus dem Dateisystem ein, erkennt die Struktur und legt die Alarme in einer Datenbank ab. Die Auswertung erfolgt webbasiert unter "http://suricata:5636". Die Webseite erfordert weder Anmeldung noch Einarbeitung. Auf der Startseite sind alle Alarme farblich gekennzeichnet (Bild 1). Jede Meldung lässt sich anklicken und zeigt sogleich alle Details an.

In Sachen Graphen präsentiert EveBox unter "Stats und Reports" die Anzahl der jeweiligen Ereignisse über die Zeit. Wenn der Chart an einzelnen Tagen ungewöhnlich hoch ist, dann ist etwas im Busch und einer genaueren Untersuchung wert. EveBox ist die Standardroute für eine Suricata-Installation. Leider lässt sich das Tool nicht anpassen oder mit Plug-ins aufbohren. Wenn es etwas mehr sein darf, kommt Scirius CE in die engere Wahl, dazu später mehr.

Im Netz platzieren

Suricata ist installiert, horcht am LAN-Adapter nach Paketen, aber EveBox zeigt nichts an? Das hat einen einfachen Grund, denn die Netzkomponenten wie Firewall oder Switch müssen die Pakete in Kopie an das IDS weiterleiten. Bei Switches heißt diese Funktion Mirror-Port, Portspiegelung oder Switched Port Analyzer (SPAN). Bietet der Switch diese Funktion nicht an, dann muss das IDS als Router oder Bridge im Datenpfad sitzen.

Der SPAN-Port erhält eine Kopie aller Datenpakete eines anderen Switchports, beispielsweise vom Uplink zur Firewall oder zum Internetrouter. Weder Firewall, Router noch Clients erfahren etwas von der Kopiererei. Im folgenden Beispiel spiegelt ein Catalyst-Switch von Cisco alle ein- und ausgehenden Pakete von Port 1 zu Port 16, an dem der Suricata-Host angeschlossen ist.

In virtuellen Umgebungen ist die Situation anders. Ein VMware-ESXi-Server verwendet Portgruppen, um virtuelle Maschinen mit virtuellen Switches zu verbinden. Der vSwitch nutzt einen oder mehrere physische Netzadapter seines Hosts und kann darüber die restliche Infrastruktur erreichen. Die VM mit Suricata benötigt eine NIC zur Portgruppe und die Erlaubnis, Pakete von anderen VMs zu empfangen.

Ob die (virtuelle) Maschine mit Suricata richtig platziert ist, prüft ein beliebiger Client mit einem Webzugriff auf die präparierte Adresse "http://testmynids.org/ uid/index.html". Wenn Suricata die Anfrage mitbekommt, triggert es den Alarm "GPL ATTACK_RESPONSE id check returned root", der sogleich bei EveBox auftaucht. Die Anfrage ist ungefährlich. Es handelt sich dabei um eine Testseite ähnlich der EICAR-Testdatei für Virenscanner.

Wenn Suricata stumm bleibt, kann dies mehrere Ursachen haben. Möglicherweise läuft der IDS-Prozess nicht oder die Signaturdatenbank ist nicht auf dem neuesten Stand. Am wahrscheinlichsten ist jedoch, dass die IP-Pakete der Webanfrage nicht bei der Suricata-Maschine eintrudeln. In diesem Fall ist zu prüfen, ob der HTTP-Zugriff am Netzadapter des IDS sichtbar ist. Wireshark und tcpdump sind hervorragende Detektive, wenn es um den Nachweis von Netzverbindungen geht.

Regelwerk optimieren

Standardmäßig ist das kostenlose Regelwerk von Emergingthreats ausgewählt und suricata-update holt sich die knapp 35.000 Regeln vom Download-Server. Dies ist für viele Konfigurationen eine akzeptable Vorauswahl, aber nicht in jedem Szenario optimal. Betreiben Sie Suricata als IDS vor einem Datenbankserver, sind viele Regelgruppen unnötig wie beispielsweise solche für SMTP, POP3 und VoIP.

Wer sein Regelwerk optimieren möchte, kann weitere dazu buchen oder einzelne Regeln deaktivieren. Der Befehl suricata-update list-sources gibt einen Überblick über die voreingestellten Quellen, von denen lediglich "et/open" aktiv ist. Die Angabe der Lizenz verrät bereits, welche Regeln kostenfrei sind und welche einen Obolus erfordern.

Weiterführende Informationen zu den Quellen bietet die Datei "index.yaml". Das Regelwerk "etnetera/aggressive" führt beispielsweise eine ausschweifende Liste von bösartigen IP-Adressen, denen kein Nutzer im eigenen Netz begegnen möchte. Binden Sie diese IP-Liste mit den folgenden Befehlen in Ihre Suricata-Engine ein:

Bei einem Fehlalarm wirft Suricata eine Meldung aus, die entweder harmlos oder schlicht falsch ist. Das Chrome-Update bewirkt eine Meldung, dass ein Client eine Binärdatei aus dem Internet heruntergeladen hat. Diese Aussage ist zwar korrekt, aber kein Grund zur Aufregung. Wenn EveBox nur noch aus Fehlalarmen und Infos besteht, gehen die ernsthaften Alarme darin unter. Das folgende Beispiel deaktiviert Wischiwaschi-Regelgruppen und die Chrome-Update-Regel:

Wer die Signatur für EXE- und DLL-Downloads nicht deaktivieren möchte, kann das Chrome-Update auch über reguläre Ausdrücke von der Alarmierung ausnehmen. In der Datei "disable.conf" steht dann der Eintrag "re:GoogleUpdateSetup".

Suricata direkt ansprechen

EveBox macht einen hervorragenden Job und visualisiert Alarme und Statistiken. Es gibt aber auch einen direkten Draht zu Suricata über den CLI-Befehl suricatasc. Im Hintergrund läuft die Kommunikation über einen Unix-Socket. Die Syntax ist denkbar einfach und besteht aus suricatasc gefolgt vom gewünschten Befehl. Ohne diese Angabe verrät die Shell alle verfügbaren Kommandos, allerdings ohne weitere Beschreibung. Glücklicherweise sind viele Schalter selbsterklärend: "reload-ruleset", "shutdown", "iface-list" oder "dump-counters", wobei Letzteres eine Menge Output erzeugt.

Ob das Regelwerk vollständig und fehlerfrei geladen ist, erfahren Sie mit suricatasc -c ruleset-stats. Stellen Sie sicher, dass der Netzadapter mit den eintrudelnden Paketen nicht überfordert ist. Im besten Fall sind die Zähler von "iface-stat" auf null, mit Ausnahme von "pkts":

Pakete transparent durchreichen

Wenn das IDS transparent im Datenpfad sitzt, ähnelt seine Arbeitsweise der eines Ethernet-Switches. Es gibt keine Routing-Funktionen und das Gerät ist für ping und traceroute unsichtbar. Eine eigene IP-Adresse benötigt das IDS nur für das Management. Somit erfordert das transparente IDS keine Änderung an Adressen der vorhandenen Server und Router. Dieser Modus ist der ideale Beschützer von Netzbereichen, die nicht verändert werden dürfen. Das Ergebnis ist dasselbe wie bei den anderen Deployments: Das IDS untersucht die Datenströme und alarmiert bei bösartigen Paketen.

Für den transparenten Modus benötigt Suricata kein unnötiges Hantieren mit den Bridge-Tools – dies übernimmt der Capture-Modus "AF_PACKET". Die Konfigurationsdatei von Suricata erwartet dafür zwei Netzadapter, die eine Netzbrücke bilden. Was in den ersten Adapter hineinfließt, kommt am zweiten Adapter heraus und umgekehrt. Und dazwischen sitzt das IDS und beschnüffelt die Pakete.

Die Settings liegen in der Konfigurationsdatei unter "/etc/suricata/suricata.yaml" im Abschnitt "af-packet". Prüfen Sie vorab mit dem Shell-Kommando ip address, wie die Netzadapter Ihrer Suricata-Maschine heißen. Das folgende Beispiel nutzt die generischen Namen "eth0" und "eth1":

Starten Sie anschließend Suricata mit suricata --af-packet. Mit dem suricatasc-Schalter capture-mode lässt sich prüfen, ob Suricata erfolgreich im transparenten Modus arbeitet.

Betrieb im Container

Die Entwickler von Suricata pflegen ein Docker-Image und stellen es über [1] bereit. Laden Sie das Image auf Ihre lokale Maschine und starten Sie den Container:

Die Option "--volume" bewirkt, dass die Logdateien nicht im Container, sondern im Dateisystem des Hosts liegen. Dies hat nicht nur den Vorteil, dass sie einen Neustart des Containers überleben, sondern dass ein weiterer Container mit EveBox darauf zugreifen kann. Doch zuerst braucht der Suricata-Container die neuesten Signaturen. Das passende Kommando ist dasselbe wie bei der paketbasierten Installation, muss aber im Container stattfinden. Hier hilft "docker exec", das den Update-Befehl an den passenden Container übergibt und dort ausführt:

Suricata läuft im Container und die Signaturen sind up-to-date. Wer sich an EveBox gewöhnt hat, kann die Analysesoftware in einem weiteren Container starten. Die Auswertung erfolgt wie gewohnt per Webbrowser. Über die Option "--publish" gibt der EveBox-Container den TCP-Port 5636 an den Host weiter und ermöglicht den Webzugriff über "http://host_ip:5636":

Schlüsselfertige Appliance

Die dritte Option nach Paketmanager und Docker ist eine Netzwerk-Appliance, die Suricata bereits an Bord hat. Dazu gehören beispielsweise die Firewall-Distributionen OPNsense und pfSense. Bei OPNsense ist Suricata automatisch dabei, bei pfSense kommt es als Plug-in hinzu. OPNsense integriert die Konfiguration von Suricata in die eigene Weboberfläche und gestaltet die Einrichtung damit besonders einfach. Der Admin entscheidet sich für einen oder mehrere Netzadapter, die das IDS überwachen soll. Die Regelwerke sind nach Themen sortiert und lassen sich einzeln aktivieren, sodass die Firewall nicht unnötig viel Last für das IDS ausgeben muss. Die Auswertung erfolgt ebenfalls webbasiert.

Die All-in-One-Variante des Open-Source-IDS ist der SELKS-Stack des kommerziellen Anbieters Stamus Networks. SELKS vereint Suricata, Elasticsearch, Logstash und Kibana in der Stamus Community Edition [2]. Das Bundle ist kostenfrei, steht unter der GPL-Lizenz und ist ein gelungenes Rundum-IDS. Alle Komponenten laufen als Docker-Container und präsentieren ihre Webseiten über die IP-Adresse des Hosts (Bild 2). Konfigurationsgefummel auf der Kommandozeile ist - bis auf den ersten Start der Container - nicht nötig.

Zur Visualisierung und Analyse greift Stamus Networks auf die bekannten Player Kibana und EveBox zurück. Die Eigenentwicklung Scirius geht noch einen Schritt weiter und liefert Trends, Graphen und jede Menge visuelle Aufhübschungen.

Auch als IPS verwendbar

Bisher beschränkt sich Suricata auf die Erkennung und bemerkt damit den Einbruch, verhindert ihn aber nicht. Wenn Sie den erkannten Einbruch auch direkt stoppen wollen, wird das System zum Intrusion Prevention System (IPS). Der Unterschied zwischen IPS und IDS liegt im letzten Arbeitsschritt: Das IDS petzt jede verdächtige Aktivität und das IPS blockiert die Aktion, indem es Pakete nicht weiterleitet oder Verbindungen aktiv trennt.

Ein IPS begnügt sich nicht mit einem Spiegelport, sondern muss bei Bedarf auch in den Datenstrom eingreifen, um Schlimmeres zu verhindern. Ein IPS sitzt normalerweise direkt im Datenpfad und untersucht den Inhalt der Pakete in Echtzeit.

Als IPS arbeitet Suricata eng mit den üblichen Paketfiltern zusammen: iptables und nftables unter Linux sowie ipfw unter FreeBSD. Bei iptables bewirkt ein zusätzlicher Eintrag im Regelwerk, dass die Pakete über die NFQueue zur Inspektion bereitstehen. Suricata lauscht an der NFQueue und führt die Untersuchung wie gewohnt durch. Neu ist: Wenn eine Signatur zutrifft und die Aktion auf Drop oder Reject steht, verwirft Suricata das Paket (Drop) oder beendet die Session aktiv (Reject). Genau genommen macht das Tool das nicht selbst, sondern informiert den Kernel über das Urteil.

Ein Linux-Router mit vorhandenem iptables-Regelwerk benötigt eine weitere Direktive in der FORWARD-Chain, die die Pakete an die NFQueue weiterleitet. Suricata startet mit der Option "-q" und wählt damit den NFQueue-Modus. Bei nftables funktioniert die Technik genauso, nur die Syntax ist anders:

Suricata kann über die NFQueue jetzt die durchfließenden Pakete "bewerten", aber anfangs stehen alle Signaturen auf "Allow". Damit ist vom IPS noch keine Rede. Soll die beispielhafte Regel 2100498 auf "drop" oder "reject" umschalten, ist ein Eingriff in die Datei "suricata.rules" nötig.

Ob der erweiterte Schutz funktioniert, zeigt erneut der Zugriff durch den Linux-Router auf die Webseite von "testmynids.org", die der Browser diesmal nicht anzeigen sollte.

Wer keine Lust hat, zigtausend Regeln von Hand zwischen "alert", "pass", "drop" und "reject" umzuswitchen, ist mit einem Werkzeug zur Regelverwaltung wie PulledPork [4] gut beraten. Genau wie suricata-update holt sich PulledPork die Signaturen aus dem Netz und modifiziert im zweiten Schritt die Regelaktion nach den Vorgaben des Admins.

Nach oben skalieren

Gibt es eine einzige Stelle im Netzwerk, an der alle IP-Pakete vorbeikommen? In kleinen Umgebungen ist das denkbar, aber Unternehmensnetze sind stark verzweigt und meist auch durch Firewalls getrennt. Ein einzelnes IDS bleibt da ziemlich ahnungslos. Da weder Suricata noch Linux das Budget belasten, darf ein IDS in jedem Netzsegment Platz nehmen und den Verkehr beobachten.

Den Wunsch nach zentraler Auswertung aller Alerts kann EveBox erfüllen. Auf jedem der verteilten IDS läuft neben Suricata ein EveBox-Agent. Dieser sichtet die Suricata-Meldungen und leitet sie an die zentrale EveBox-Instanz weiter. Sie sammelt die Alarme und zeigt sie über eine Webseite an. Die Auswertung funktioniert genau wie bei der kleinen Variante. Je nach Größe der Umgebung stößt SQLite als Datenbank an seine Grenzen. Hier kann Elasticsearch einschreiten, das bei der Suche nach Alerts deutlich besser skaliert - Storage und Performance vorausgesetzt.

Das Ergebnis ist eine Armee von IDS-Sensoren, die überall im Firmennetz, in Außenstellen oder im Home Office vertreten sind. Die Sensoren berichten ihre Funde an die Zentrale, die auch in der Cloud laufen kann.

Fazit

Einbruchserkennung im Netzwerk muss nicht von einem teuren Hersteller kommen. Das kostenlose und quelloffene Suricata läuft gerade erst warm, wenn es um die Aufklärung in Netzsegmenten geht. Die Installation und der erste Start gehen einfach von der Hand. Das Fein-tuning ist durch die vielen Möglichkeiten zur Konfiguration aber durchaus anspruchsvoll. Suricata meldet Einbrüche, ungewöhnliche Pakete und leider auch False-Positives in einer Textdatei. Daraus bedient sich EveBox und stellt die Meldungsflut farblich markiert als Webseite dar. Wer viele Suricata-Sensoren in seinem Netzwerk aufbauen möchte, kann die Alarme mit Bordmitteln zentral speichern und auswerten.

Einbruchserkennung mit Suricata

Auf die Schliche kommen

Suricata installieren

Suricata installieren

Alarme auswerten

Im Netz platzieren

Regelwerk optimieren

Suricata direkt ansprechen

Pakete transparent durchreichen

Betrieb im Container

Schlüsselfertige Appliance

Auch als IPS verwendbar

Nach oben skalieren

Fazit