Intrusion Detection Systeme prüfen Datenströme mithilfe von Regelwerken auf Auffälligkeiten, die auf Angriffe oder Angriffsversuche hindeuten oder zumindest Indikatoren für mögliche Angriffe sein können.
Die Effektivität von ID-Systemen steht und fällt dabei mit der Qualität und Anzahl der eingesetzten Regelwerke. Dies setzt den Systemen auch in der Praxis Grenzen, weil es für erkennbare Angriffe eindeutige Regeln geben muss, die nur bei einer tatsächlichen oder zumindest sehr wahrscheinlichen Intrusion anschlagen und alarmieren dürfen. Ansonsten käme es zu zu vielen false positive und Falschalarmen, die die Wirkung des gesamten Systems verringern könnten.
Aufgrund der Vielzahl unterschiedlicher Protokolle und Anwendungen, die über Netzwerke miteinander kommunizieren ist es nicht realistisch für alle vorhandenen Angriffe Regeln zu haben, die diese erkennen. Das hat zur Folge, dass man sich beim Bestreben die eigenen IT zu schützen nicht auf IDS-Systeme alleine verlassen sollte. IDS bilden aber einen wichtigen Bestandteil einer effektiven IT-Sicherheitstrategie.
Intrusion Detection Systeme (IDS) sind Systeme die die Protokollierung und Analyse von Datenströmen oder Datensätzen ermöglichen. Durch die Anwendung von Regelwerken auf die Datentröme oder Protokolle können mögliche Angriffe erkannt werden. Diese Regeln vergleichen dazu die Daten mit bekannten Mustern die sich aus Angriffen oder Angriffsversuchen extrapolieren lassen.
Die meisten IDS sind entweder netzwerkbasiert oder hostbasiert.
Netzwerkbasierte IDS überwachen Datenströme in Netzwerken. Dies tun Sie meistens an Netzwerkknotenpunkten, um eine möglichst große Menge an relevanten Daten erfassen zu können.
Hostbasierte IDS überwachen die Datenströme zu und aus einem Endgerät. Beide Formen des IDS haben unterschiedliche Zwecke und Einsatzmöglichkeiten. Netzwerkbasierte IDS werden verwendet um den Traffic innerhalb sowie eingehenden oder ausgehenden Traffic aus einem Netzwerk zu überwachen. Hierbei liegt der Einsatzzweck hauptsächlich darin das Netzwerk und die darin vernetzten Geräte insgesamt zu schützen. Hostbasierte IDS dienen dazu das System auf dem sie installiert werden zu schützen. Idealerweise ergänzen sich beide Systeme beim Schutz von IT-Infrastrukturen.
Intrusion Detection Systeme prüfen Datenströme mithilfe von Regelwerken auf Auffälligkeiten, die auf Angriffe oder Angriffsversuche hindeuten oder zumindest Indikatoren für mögliche Angriffe sein können. Die Effektivität von ID-Systemen steht und fällt dabei mit der Qualität und Anzahl der eingesetzten Regelwerke.
Dies setzt den Systemen auch in der Praxis Grenzen, weil es für erkennbare Angriffe eindeutige Regeln geben muss, die nur bei einer tatsächlichen oder zumindest sehr wahrscheinlichen Intrusion anschlagen und alarmieren dürfen. Ansonsten käme es zu zu vielen false positive und Falschalarmen, die die Wirkung des gesamten Systems verringern könnten. Aufgrund der Vielzahl unterschiedlicher Protokolle und Anwendungen, die über Netzwerke miteinander kommunizieren ist es nicht realistisch für alle vorhandenen Angriffe Regeln zu haben, die diese erkennen. Das hat zur Folge, dass man sich beim Bestreben die eigenen IT zu schützen nicht auf IDS-Systeme alleine verlassen sollte. IDS bilden aber einen wichtigen Bestandteil einer effektiven IT-Sicherheitstrategie.
IDS Systeme können an verschiedenen Stellen innerhalb von IT-Infrastrukturen platziert werden. Wo und wie diese Platzierung erfolgt hat dabei große Auswirkungen auf die Funktionalität des IDS und die Komplexität und Kosten der Implementierung.
Eine der wesentlichsten Fragen bei der Platzierung eines IDS ist dabei das Ziel, dass mit diesem erreicht werden soll. Wenn es darum geht einzelne Systeme oder eine Vielzahl von Systemen dezentral vor Bedrohungen zu schützen, dann ist ein Host-basiertes IDS am besten dafür geeignet. Dieses wird als Applikation, z.B. auch als ein Teil einer eingesetzten Endpointprotection auf dem zu schützenden System installiert und überwacht ein- und ausgehende Netzwerk-Verbindungen.
Firewalls sind aufgrund ihrer Aufgabe in IT-Infrastrukturen als Installationspunkte für IDS geeignet und fast alle modernen Firewall-Systeme bieten eine integrierte IDS/IPS-Lösung an. Firewalls eignen sich deshalb als Netzwerkteilnehmer, auf denen ein IDS eingesetzt wird, weil Sie ohnehin als Knotenpunkt und Zugang zu Netzwerken dienen und ihre primäre Aufgabe darin besteht, den Zugang in und aus dem entsprechenden Netzwerk zu überwachen und zu regeln. Hierbei ist grundsätzlich zwischen zwei verschiedenen Arten von Einsatzgebieten von Firewalls zu unterscheiden, Perimeter-Firewalls und Core-Firewalls.
Unter einer Perimeter-Firewall versteht man eine Firewall, die Netzwerkübergänge zwischen öffentlichen Netzwerken (meistens dem Internet) in ein internes Netzwerk schützt und überwacht. Über eine solche Firewall muss jeder Netzwerkverkehr laufen, der in oder aus dem internen Netzwerk einer Organisation kommt. Als ein solches Gateway kann ein IDS, dass auf der Firewall eingesetzt wird, einen Großteil des Traffics überwachen der über die Firewall fließt. Ausgenommen sind hiervor jedoch i.d.R. verschlüsselte Datenströme, die von der Firewall nicht eingesehen werden können. Ein an einer Perimeter-Firewall platziertes IDS kann somit Angriffe aus dem Internet auf die IT-Infrastruktur oder einzelne Systeme erkennen.
Eine weitere sinnvolle Einsatzmöglichkeit eines IDS besteht an einer sog. Core-Firewall. Diese sind deutlich weniger verbreitet als Perimeter-Firewall. Während nahezu jede Organisation und auch vermutlich alle privaten Haushalte über eine Perimeter-Firewall verfügen (bei privaten Anschlüssen, hat der „Router“ des Anbieters, z.B. eine Fritzbox eine integrierte Firewall, die das private LAN vor ungeregelten Zugriffen aus dem Internet schützt), verfügen nur eine relativ kleine Zahl von Organisationen oder Unternehmen über mindestens einer weitere Firewall, deren Aufgabe nicht die Überwachung des Netzwerkübergangs ins Internet ist sondern die Steuerung von Datenverkehr innerhalb eines Firmennetzes.
Bei einer solchen Firewall spricht man von einer Core-Firewall, weil ihre Aufgabe darin besteht, im Kern des Netzwerkes Zugriffe auf Netzwerke zu regeln und Datenströme zu überwachen. Als Knotenpunkt innerhalb eines internen Netzwerks regelt eine Core-Firewall die Zugriffsrechte von Systemen auf Netzbereiche. Sie wird z.B. dafür genutzt den Zugriff von Clients auf sensible Netzbereiche einzuschränken. Dies hat den Vorteil, dass Systeme im Netzwerk, wie z.B. normale Desktop-Clients oder auch mobile Geräte, die im Homeoffice verwendet werden, keinen Zugriff auf sensible Systeme erhalten. Ein Beispiel hierfür sind z.B. Management-Dienste wie SSH oder RDP die in der Regel für die Administration von Server-Systemen verwendet werden. Der größte Teil der Belegschaft eines Unternehmens wird während seiner Tätigkeit niemals darauf angewiesen sein, sich per SSH an einem Server-System anzumelden. Ein solcher Zugriff ist also nicht notwendig und kann durch ein entsprechendes Regelwerk an der Firewall unterbunden oder gesteuert werden.
Neben dieser Rolle als „Gatekeeper“ innerhalb des Netzwerks, kann die zentrale Stellung der Firewall, über die nahezu der gesamte Netzwerkverkehr innerhalb des Netzwerks fließt auch dazu genutzt werden diesen Datenverkehr mit einem IDS zu analysieren. Das IDS erhält so Zugriff auf die größtmögliche Menge von Daten und kann diese analysieren, ohne dass es zu Einschränkungen bei der Performance der Netzwerkübertragung kommt. Ein weiterer Vorteil beim Einsatz eines IDS an dieser Stelle ist, wie bei der Perimeter-Firewall, dass Firewall-Systeme in den allermeisten Fällen bereits mit den Funktionalitäten eines IDS ausgestattet sind und dieses nur noch entsprechend Aktivierung und konfiguriert werden muss. Auch die Reaktion auf erkannte Vorfälle kann durch die Möglichkeit des Eingriffs der Firewall in den Netzwerkverkehr realisiert werden.
Zusammenfassend kann festgehalten werden, dass Firewalls sehr geignete Systeme für den Einsatz von IDS-Systemen sind.
Die Deep Inspection von Paketen und das damit verbundene “aufbrechen” von Paketen wiederspricht grundsätzlich dem Ansatz von TLS. Perfect Forward Secrecy, welches zur sicheren verschlüsselten Kommunikation beiträgt und in TLS 1.3 sogar notwendig ist, ist somit nicht möglich. Eine große Kontroverse gab es hier auch bei dem Thema ETS. Es empfiehlt sich ein Host basiertes IDS für den entschlüsselten Traffic einzusetzen, und ein Netzwerk basiertes IDS mit dem man nun auch Angriffe auf verschlüsselten Verkehr erkennen kann.
Network Tap-Devices können eingesetzt werden um Datenverkehr der über eine Netzwerkleitung fließt zu kopieren und in der Folge zu analysieren. Sie bieten neben der beschriebenen Platzierung eines IDS auf einer Firewall die Möglichkeit Daten für die Analyse auf Angriffe zu sammeln.
Ein Nachteil gegenüber einer Core-Firewall liegt allerdings darin, dass diese Devices immer nur eine Verbindung, sprich ein Netzwerkkabel überwachen können. Das ist nicht problematisch, wenn es um eine zentrale Datenstrecke, z.B. die Verbindung ins Internet geht. In unserem beschriebenen Fall, in dem wir jedoch auch in der Lage sein wollen, Netzwerkverkehr innerhalb unseres Netzwerks zu analysieren, ist ein einzelnes TAP-Device nicht in der Lage sämtlichen Verkehr abzuzweigen und durch ein IDS zu analysieren.
Um daher einen Einblick in den internen Netzwerkverkehr zu erhalten müssten daher mehrere TAP-Devices eingesetzt werden, die den mitgeschnittenen Netzwerkverkehr an ein zentrales IDS leiten. Hierfür bietet sich die Überwachung der Uplinks zwischen Core- und Access-Switchen an, weil ein großer Teil des internen Verkehrs über diese Verbindungen fließen wird.
Intrusion Detectin Systeme, können, getreu ihrem Namen, nur erkennen, ob Angriffe stattfinden. Sie alarmieren also nur, eine Reaktion muss durch Administratoren oder andere angeschlossene Tools erfolgen. Ein solch weiteres Tool kann z.B. ein Intrusion Prevention System sein. Diese können aufgrund von Meldungen eines IDS, aber auch aufgrund anderer Events, reagieren und z.B. bestimmte IPs vom Zugriff auf das Netzwerk ausschließen.
Die Begriffe IDS & IPS verschwimmen im Kontext vieler moderner Sicherheits-Systeme. Zumindest im betrieblichen Kontext setzen heute viele Organisationen und Unternehmen auf Firewalls mit einer Vielzahl von Features, hierbei fallen häufig die Begriffe Unified Threat Management (UTM) und Next-Gen Firewall.
Moderne Firewall-Systeme vereinen dadurch heute viele der Security-Features, die für ein Unternehmen hilfreich sind. Die Unterscheidung, die wir in diesem Artikel getroffen haben, um die Funktionsweise eines IDS zu erklären und diese von anderen Systemen abzugrenzen wird also in der Realtität häufig nicht mehr so auffindbar sein. So werden z.B. die meisten Firewalls die Funktionalitäten eines IDS und eines IPS vereinen, in dem sie bei entsprechender Konfiguration auffälligen Datenverkehr direkt verwerfen.
Snort ist eine OpenSource Intrusion Detection / Intrusion Prevention Lösung. Es basiert auf Regeln, die ungewollte Pakete identifizieren und melden. Eine andere OpenSource Lösung ist beispielsweise Surricata.
Große Enterprise Lösungen wie Sophos, Checkpoint und Fortinet nutzen Snort Regeln.
Hat man einmal verstanden wie diese Regeln funktionieren und wie diese verknüpft werden können, gibt es keine weiteren Hürden mehr. Diese Grundlagen helfen einem bei jedem Intrusion Detection System.
Überall hört man zu dem Thema Buzzwords wie Künstliche Intelligenz / Artificial Intelligence. Dem allen liegen aber einfach nur Regeln zu Grunde, die aktuellisiert und verknüpft werden. Hier wird aber gern mit viel “Magie” gearbeitet.
In unserem Versuchsaufbau haben wir zwischen Angreifer und Server eine Firewall. Auf dieser können wir mit Wireshark den Traffic analysieren und mithilfe von Snort, Regeln schreiben um Netzwerktraffic zu melden den wir für schadhaft halten.
Als erstes Beispiel wollen wir eine Regel schreiben um JNDI Request (Log4Shell Schwachstelle) im Netzwerktraffic zu finden und eine Meldung in einem Logfile zu erhalten.
Von unserem Angreifer Rechner starten wir netcat auf Port 389 und schicken mit dem curl-Befehl eine HTTP-Request mit dem JNDI-Lookup. Unser Server hat die Log4Shell Schwachstelle im X-Api-Version Header und verbindet sich mit unserem Rechner auf Port 389.
In der snort.conf (bei uns unter /etc/snort/) haben wir alle Community-Rules auskommentiert und nutzen nur unsere eigenen Regeln aus dem File local.rules. Dieses liegt bei uns unter /etc/snort/rules/ ab.
Eine Snort Regel besteht aus zwei Teilen. Einem Rule Header und den Rule Options (alles was in Klammern steht).
alert tcp $HOME_NET any -> any any \
(msg:"IDS: JNDI REQUEST"; content:"${jndi:"; sid:1000001; rev:1;)
Der Header beschreibt was passieren soll (in unserem Fall alert), welches Protokoll betrachtet werden soll (tcp) und von welcher IP/IP Range:Port zu welcher IP/IP Range:Port die Pakete betrachet werden sollen.
In den Rule Options wird angegeben welche Nachricht (msg) im Log auftauchen soll wenn die Regel anschlägt, und nach was in den Paketen gesucht werden soll. In diesem Fall soll Snort einfach nach dem ASCI-Content “${jndi:” suchen und im Log die Nachricht “IDS: JNDI REQUEST” ausgeben.
Im Falle der Log4Shell Schwachstelle reicht es natürlich nicht aus einfach nur nach diesem String zu suchen. Hier gibt es viele Beispiele von Bypasses die betrachtet werden sollten. Zum Erklären einer Snort Regel würde dies an dieser Stelle aber zu weit führen.
Nach dem Start von Snort (mit unserer selbstgeschriebenen Regel) und dem erneuten Testen der Schwachstelle taucht in unserem Log der passende Log-Eintrag auf. Snort hat den JNDI-Lookup erkannt und gemeldet.
In unserem nächsten Beispiel wollen wir zeigen, was man in den Rule Options noch alles konfigurieren kann. In diesem Beispiel wollen wir im Log alarmiert werden wenn jemand 5 fehlerhafte Anmeldungen innerhalb von 30 Sekunden an SMB produziert.
Gucken wir uns das Paket genauer an müssen wir nur herausfinden was das Paket einzigartig macht. In diesem Fall ist es die Meldung “STATUS_LOGON_FAILURE”. Im unteren Fenster von Wireshark sehen wir die HEX-Darstellung der Bytes. Dort benötigen wir den String “SMBs” und die HEX-Darstellung der Meldung “STATUS_LOGON_FAILURE”.
Damit Snort nicht jedes Paket betrachtet spezifizieren wir in unserer Regel wo genau in einem Paket der String “SMBs” und die Bytes “6d 00 00 c0” zu finden sind. Dies machen wir mit der Option “offset” (wieviele Bytes innerhalb des Paketes soll Snort anfangen nach dem Content zu suchen) und “depth” (bis zu welchem Byte muss der Content auftauchen).
alert tcp any any -> $HOME_NET any \
(msg:"IDS: SMB Session Setup Failure"; content:"SMBs"; offset:4; \
depth:5; content:"|6d 00 00 c0|"; within:4; \
detection_filter:track by_dst, count 5, seconds 30; \
sid:1000002; rev:1;)
Ohne weitere Optionen würde aber jede Fehlerhafte Anmeldung an SMB einen Alarm zur Folge haben. Über die Option “detection_filter” kann man jedoch Einstellen nach wieviel Paketen in welchem Zeitfenster Snort einen Alarm ausgeben soll.
In unserem Fall schlägt Snort Alarm wenn ein Paket von einer Destination, fünf mal innerhalb von 30 Sekunden festgestellt wird.
Um Snort Regeln zu schreiben muss man sich mit den Protokollen und Paketen bis aufs letzte Byte auseinandersetzen. Man muss versuchen, die Regel so detailliert wie möglich zu konfigurieren um so wenig wie möglich False-Positives zu produzieren.
Ausführliche Dokumentation: Snort Documentation
