entwickler.com

Wie angekündigt geht es diese Woche weiter um Intrusion-Detection-Systeme. Thema ist die Positionierung des Intrusion-Detection-Systems im Netzwerk. Bei hostbasierten IDS ist diese kein Problem, da jeder zu schützende Rechner sein eigenes hostbasiertes IDS bekommt. Die einzige Entscheidung, die zu treffen ist, ist die Auswahl der zu schützenden Rechner. Bei netzwerkbasierten IDS und den netzwerkbasierten Sensoren eines verteilten IDS wird es etwas komplizierter.

Folgendes fiktive Netzwerk soll als Beispiel dienen:
Eine Firewall, bestehend aus zwei Paketfiltern und einem oder mehreren Application Level Gateways, befindet sich zwischen zu schützendem Netz und dem Internet. In der demilitarisierten Zone befinden sich ein Applikationsserver (AS), ein Webserver (WS), ein Datenbankserver (DBS) und ein Mailserver (MS). Ob diese über ein gemeinsames oder jeweils separate Application Level Gateways mit dem Netzwerk verbunden sind ist in diesem Fall unerheblich. Zur Vereinfachung zeigt die Grafik ein gemeinsames Application Level Gateway (ALG).

Ein einzelnes netzwerkbasiertes IDS
Ein netzwerkbasiertes IDS überwacht den gesamten Netzwerkverkehr im jeweiligen Netzwerksegment. Oder salopp formuliert: Es sieht alles, was an seiner Netzwerkschnittstelle vorbeikommt. Soll nur ein einzelnes netzwerkbasiertes IDS eingerichtet werden, scheint die Entscheidung einfach zu sein: Damit das IDS allen ein- und ausgehenden Netzwerkverkehr überwachen kann, muss es am Zugang zum Internet positioniert werden. Aber kommt es vor den äußeren Paketfilter oder besser dahinter in die DMZ?

	NIDS = netzwerkbasiertes IDS

	NIDS = netzwerkbasiertes IDS

Ein vor dem äußeren Paketfilter positioniertes netzwerkbasiertes IDS kann zusätzliche Informationen über den Kontext eines Angriffs liefern und Angriffe auf den Paketfilter erkennen. Dafür muss es aber auch alle Pakete verarbeiten, die der äußere Paketfilter anschließend sofort verwirft. Außerdem wird es selbst nicht durch den Paketfilter geschützt.

Befindet das netzwerkbasierte IDS sich hinter dem äußeren Paketfilter, muss es nur die vom Paketfilter akzeptierten Pakete verarbeiten. Dafür kann es aber keine Angriffe auf den Paketfilter erkennen und sieht unter Umständen nur einen Teil der zu einem komplexen Angriff gehörenden Pakete, wenn der Paketfilter bereits Teile des Angriffs ausgefiltert hat.

Sehr stark vereinfacht kann man sagen, dass ein IDS vor dem Paketfilter (oder allgemein der Firewall) alle Angriffe und dahinter nur Einbrüche erkennen kann.

Wo ein einzelnes netzwerkbasierte IDS positioniert wird, hängt also im Wesentlichen von den gewünschten Informationen ab. Meist reicht eine Positionierung in der DMZ aus.

Ein so positioniertes netzwerkbasiertes IDS kann den Netzwerkverkehr innerhalb des geschützten Netzes nicht überwachen. Nur die Daten, die vom inneren Paketfilter in die DMZ weitergeleitet werden, können beobachtet werden. Um Angriffe im geschützten Netz zu erkennen, die nicht von außen kommen, müsste das IDS im geschützten Netz positioniert werden.

Mehrere netzwerkbasierte IDS
Eine optimale und lückenlose Überwachung ist nur mit mehreren netzwerkbasierten IDS möglich. Da jedes IDS nur das eigene Netzwerksegment überwachen kann, wird für jedes Segment ein eigenes netzwerkbasiertes IDS benötigt. Im Beispiel muss also ein netzwerkbasiertes IDS im geschützten Netz positioniert werden. Besteht dies aus mehreren Teilnetzen, wird für jedes Teilnetz ein IDS benötigt. Ein weiteres IDS ist für die demilitarisierte Zone zuständig. Besteht das Netzwerk in der demilitarisierten Zone aus mehreren Teilnetzen, ist wieder für jedes Teilnetz ein IDS notwendig. Insgesamt könnte dies z.B. folgendermaßen aussehen:

Je ein netzwerkbasiertes IDS überwacht die beiden Teilnetze im geschützten Netz, das Teilnetz aus Applikationsserver, Datenbankserver und Webserver sowie die demilitarisierte Zone. Dadurch können auch Angriffe innerhalb der einzelnen Teilnetze erkannt werden.

Erweiterung des Beispiels um hostbasierte IDS
Zusätzlich zu den netzwerkbasierenden IDS sollen hostbasierte IDS für den Applikationsserver, den Webserver, den Datenbankserver, den Mailserver sowie zwei wichtige Rechner im geschützten Netz verwendet werden:

	HIDS = hostbasiertes IDS

Sensoren eines verteilten IDS
Für die Positionierung der netzwerkbasierten und hostbasierten Sensoren eines verteilten Intrusion-Detection-Systems gilt das Gleiche wie bei den netzwerkbasierten und hostbasierten IDS. Zusätzlich wird ein Managementsystem benötigt, dass die gesammelten Daten zusammenfasst und auswertet. Die Kommunikation zwischen den verschiedenen Sensoren und dem Managementsystem kann entweder über das normale Netzwerk, in einem separaten IDS-Netz oder einer separaten DMZ erfolgen. Entsprechend befindet sich auch das Managementsystem im jeweiligen Netz. Vor- und Nachteile dieser Ansätze werden in der nächsten Woche beschrieben.

Carsten Eilers

• About Security (#1): IT-Sicherheit – Was ist das eigentlich?
• About Security (#2): Angriffsszenarien
• About Security (#3): Eindringlinge abwehren
• About Security (#4): Gefährdung aus der Peripherie
• About Security (#5): Der Pufferüberlauf
• About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security (#7): Gegenwehr – Pufferüberläufe verhindern
• About Security (#8): Vorbeugung – Pufferüberläufe verhindern
• About Security (#9): Sourcecode Audit – Pufferüberläufe finden
• About Security (#10): Software-Audit – Schwachstellensuche in Binaries
• About Security (#11): SQL-Injection
• About Security (#12): SQL-Injection verhindern
• About Security (#13): Mit Stored Procedures gegen SQL-Injection
• About Security (#14): Cross-Site Scripting
• About Security (#15): Cross-Site Scripting verhindern
• About Security (#16): Skriptcode einschleusen
• About Security (#17): HTTP Request Smuggling
• About Security (#18): Spielarten des HTTP Request Smuggling, 1
• About Security (#19): Spielarten des HTTP Request Smuggling, 2
• About Security (#20): HTTP Request Smuggling erkennen und verhindern
• About Security (#21): HTTP Response Splitting, 1
• About Security (#22): HTTP Response Splitting, 2
• About Security (#23): Caches vergiften
• About Security (#24): Caches indirekt vergiften
• About Security (#25): Entführen von Webseiten
• About Security (#26): Gefahren für Webanwendungen
• About Security (#27): Gefahren für Webserver
• About Security (#28): Standorte für Webserver
• About Security (#29): Die Firewall, 1
• About Security (#30): Die Firewall, 2
• About Security (#31): Die Firewall, 3
• About Security (#32): Die Firewall, 4
• About Security (#33): Die Firewall, 5
• About Security (#34): Die Firewall, 6
• About Security (#35): Die Firewall, 7
• About Security (#36): Die Firewall, 8
• About Security (#37): Logfiles – Welche Daten speichern?
• About Security (#38): Logfiles – Wie auswerten?
• About Security (#39): Paketfilter-Logfiles manuell auswerten
• About Security (#40): HTTP-Proxy-Logfiles manuell auswerten,1
• About Security (#41): HTTP-Proxy-Logfiles manuell auswerten, 2
• About Security (#42): Intrusion-Detection-Systeme – Grundlagen