Sicherheit ist etwas für Banken und Versicherungen –warum soll ich mich als Unternehmen überhaupt mit mehr als meiner Firewall und Antivirus beschäftigen? Diese Frage stellen sich heute viele IT-Administratoren und auch Entscheidungsträger. Im Rahmen der Kostenreduktion wird auf alles verzichtet, was «nicht unbedingt notwendig ist». Und es läuft ja auch –meist. Neue gesetzliche Regelungen zeichnen hier aber ein anderes Bild. Der Sarbanes Oxley Act (SOX) zum Beispiel spricht bei Compliance von Echtzeit-Überwachungssystemen. Schon allein damit wird klar, dass eine kontinuierliche Überwachung der gesamten IT im Hinblick auf Angriffe notwendig wird.
Auch aus der Sicht potentieller neuer Risiken spricht vieles für eine Investition in Sicherheitstechnologie: Nach den aus der Vergangenheit gut bekannten und massenhaft durchgeführten Angriffen (Viren, Würmer usw.) geht der Trend zu gezielten Aktionen, beispielsweise mit Spyware. Dabei spielt der Einfluss von kriminellen Gruppierungen auf den Markt eine immer grössere Rolle. Es werden auch immer häufiger Schadprogramme gezielt zur Spionage oder zur Erpressung der Wirtschaft entwickelt. Traditionelle Antiviren-Ansätze versagen hier typischerweise.
Was sollte nun zum Einsatz kommen –IDS oder IPS? Der Trend geht klar in Richtung Prävention. Fast alle Hersteller von Intrusion-Detection-Systemen (IDS) haben sich auch in diese Richtung entwickelt. Laut Gartners Magic Quadrant sind Intrusion-Prevention-Systeme (IPS) prinzipiell ebenfalls IDS, die zusätzlich zu deren Funktion (die oft auf Signaturen zur Erkennung der Angriffstools beruht) auch Signaturen für die eigentlichen Schwachstellen der Systeme und eine Anomalie-Erkennung enthalten. Weiterhin besitzen IPS typischerweise eine höhere Performance für den Betrieb im Datenstrom (Inline-Betrieb). Dieser Betriebsmodus ist für IPS erforderlich, um Angriffe automatisch blockieren zu können.
Einige IPS sind mit weiteren Sicherheitstools kombiniert. Dies erscheint zwar sinnvoll, bei näherem Hinschauen entpuppt sich aber die IPS-Funktion in solchen Geräten als sehr limitiert gegenüber dedizierten Appliances; meist sind darin nur Bruchteile einer typischen IPS-Funktion vorhanden. Ausserdem wird es damit einem Angreifer leichter gemacht, indem dieser nur ein System überwinden muss –ganz abgesehen davon, dass ein solches System unter Performance-Implikationen leidet. Daher sind dedizierte, verteilte Systeme zu bevorzugen, die zentral über ein Security-Management-System zusammengefasst sind und deren Ereignisse effektiv korreliert werden können.
Das amerikanische National Institute of Technology (NIST) empfiehlt den Einsatz von IDS oder IPS überall dort, wo Netzwerkverkehr aus «öffentlichen Bereichen in kontrollierte oder private Bereiche» eintritt –der Perimeter-Security-Ansatz zwischen Internet/Extranets und dem eigenen Intranet in der demilitarisierten Zone (DMZ). Im Prinzip ist das richtig für den Start einer Implementierung. Wenn man sich jedoch den Perimeter genauer anschaut, wird man feststellen, dass dieser immer mehr verwässert wird. So kommt Netzwerk-Verkehr nicht mehr bloss rund um die DMZ und Remote-Access-Zugänge (RAS) ins eigene Netz. Es werden auch Systeme, die zuvor in öffentlichen Bereichen angeschlossen waren und somit potentielle Risiken in sich tragen, direkt im eigenen Netzwerk angeschlossen. Beispiele sind die viel diskutierten Laptops von Aussendienstmitarbeitern, aber auch von Gästen oder Servicetechnikern. Daher sollte im Konzept auch die Überwachung und der Schutz des internen Netzwerks enthalten sein. Hier kann der Schaden besonders gross sein, da im eigenen Netz oft wenige Beschränkungen für den Netzwerkverkehr gelten. Der Positionierung kommt daher eine grosse Bedeutung zu, damit auch der gesamte relevante Verkehr kontrolliert werden kann.
Der Einsatz von IDS/IPS ist wie alles in der Informationssicherheit ein Prozess: Ein entsprechendes Sicherheitsniveau kann nur erhalten werden, wenn kontinuierlich das System überwacht und auf dem neuesten Stand gehalten wird. Man sollte sich diesbezüglich nicht von «vollautomatischen» Intrusion-Prevention-Systemen täuschen lassen.
Wer übernimmt die Konfiguration und das Tuning, die Überwachung des Betriebs, das Update der Signaturen und die Analyse der protokollierten Ereignisse? Wie sieht die Vorgehensweise beim Auftreten von Ereignissen bestimmter Kategorien aus: Protokollierung von Angriffsversuchen (Logging der Datenpakete eines Angriffs inklusive Quell-/Zielinformation) aus Compliance-Gründen heraus, Ignorieren von Ereignissen, zugehörige Pakete verwerfen, System abschalten etc.? Diese Fragen müssen bereits vor der Konfiguration und Inbetriebnahme vollständig geklärt sein.
Die Aufgaben können in einem Computer Incident Reponse Team (CISRT) zusammengefasst werden: Damit kann auf Security Incidents durch zuvor klar definierte Abläufe effektiv reagiert werden. Zu den weiteren Aufgaben eines CISRT gehören die Suche nach und Isolation von kompromittierten Systemen, die Sammlung und Speicherung von Beweismitteln sowie die Kommunikation mit den betroffenen Stellen. Ausserdem gehören die Wiederherstellung des Ausgangszustandes und die Verhinderung weiterer Angriffe auf die entsprechenden Systeme dazu.
Um Intrusion Detection effektiv einzusetzen, sollte man sich zuvor nochmals alle Aktionen der Gegenseite bewusst machen. Diese geht immer in bestimmten Schritten vor, und jeder davon kann bei entsprechender Interpretation zur Erkennung eines Angriffs führen.
Am Anfang steht immer das Footprinting, die Analyse der potentiellen Ziele. Danach erfolgt das Scanning, um aktive Dienste auf den Zielsystemen zu ermitteln. Eine Erkennung von Scans im Intranet kann ein Hinweis auf einen Angriff oder eine Virus-Ausbreitung sein. Im nächsten Schritt wird der Angreifer zur Enumeration übergehen, die Ermittlung von Benutzerkonten und Schwachstellen von Diensten und Betriebssystemen, die beim Scanning ermittelt wurden. Dies ist zum Beispiel durch unerlaubte Logon-Versuche erkennbar. Ausserdem wird dabei die Gesamttopologie des Netzes bestimmt.
Darauf folgen der Login und die Erweiterung der Rechte durch die Ausnutzung von Schwachstellen. Insbesondere hier kann das ID/IP-System eingreifen. Im nächsten Schritt werden oft Backdoors installiert, damit der Angreifer später problemlos wieder vollen Zugriff auf das System erlangen kann. Ein Einfügen zusätzlicher Benutzerkonten geht oft damit einher, und somit ist dies auch erkennbar. Am Schluss versucht der Angreifer, die Spuren zu verwischen, etwa indem er Einträge aus Log-Dateien löscht. Deshalb kann eine Alarmierung bei kleiner werdenden Log-Dateien durch ein Host-IDS helfen.
Um die Rate der Fehlalarme bei IDS/IPS gering zu halten, sollte man beim Einsatz von Systemen in Richtung Internet –vor der Firewall –unter anderem folgende Einstellungen beachten: Es sollte keine Alarmierung respektive Aktion bei Netzwerk-Scans erfolgen. Diese sind für sich allein nicht aussagekräftig, sie sollten aber mitprotokolliert werden. Dies kann beispielsweise für eine spätere Beweismittelsicherung oder zu Troubleshooting-Zwecken wichtig werden. Weiterhin ist keine Alarmierung oder Aktion bei der Erkennung von Windows-Backdoors wie Back Orifice oder Netbus notwendig, solange die Firewall selbst nicht auf einem Microsoft-Betriebssystem läuft. Jedoch ist auch hier eine Mitprotokollierung zu empfehlen.
Ein Angreifer sucht aktiv nach Schwachstellen. Eine Alarmierung oder eine andere Aktion sollte deshalb bei Angriffen auf die Firewall selbst sowie bei DoS-Angriffen erfolgen. Ebenfalls ist eine Protokollierung von HTTP-, E-Mail-, CGI- und RPC-Angriffen zu empfehlen, wenn diese Dienste in der Firewall vorhanden sind.
Diese Einstellungen sollten hinter der Firewall im eigenen Netz und auch generell im Intranet wesentlich sensitiver sein. Hier wird ein IDS oft zur Überprüfung der Firewall-Konfiguration genutzt. Eine empfehlenswerte Konfiguration sieht hier wie folgt aus: Eine Alarmierung oder Aktion erfolgt bei jeglicher Spyware-Erkennung sowie bei Backdoor-Angriffen –insbesondere bei einer externen Quelle. Ebenfalls ist eine Alarmierung bei allen verfügbaren DoS-Angriffsmustern zu spezifizieren, um nachvollziehen zu können, wenn derartige Attacken durch die Firewall hindurchgekommen sind. Das gleiche gilt bei allen Buffer-Overflow-Angriffen, auch wenn das Zielsystem keine Schwäche für diesen Angriff hat –es könnte sich ja auch um einen Angriff auf Dritte aus dem eigenen Netz handeln oder ein System wurde kompromittiert und wird nun als Host für neue Angriffe genutzt. Auch ist eine Protokollierung aller Netzwerk-Scans, Probes etc. sowie eventuell die automatische Quarantäne des Endsystems durch zusätzliche Verfahren am Access-Switch sinnvoll. Die Protokollierung aller sonstigen verdächtigen Ereignisse wie Source-Routes, IP-Fragmentation, doppelte IP- Adressen etc. sollte ebenfalls nicht vergessen werden. Hingegen sollten die zentralen Management-Plattformen gefiltert werden, die durch ihre Arbeitsweise sonst öfter False Positives erzeugen.
Generell können zur Optimierung der Performance sowie zur Erkennung von Umgehungsversuchen der Sicherheitsmassnahmen ebenfalls einige sinnvolle Einstellungen vorgenommen werden. So können beispielsweise Pakete mit kleinem TTL-Wert (Time To Live) ignoriert werden, da diese sowieso am nachfolgenden Router verworfen werden. Dies gilt ebenfalls für Pakete mit falschen IP- und TCP-Prüfsummen. TCP-Sessions müssen immer vollständig reassembliert werden, da Angriffe oft verteilt auf viele Pakete in einer Session sind. Bei sehr kleinen IP-Fragmenten sowie überlappenden Fragmenten sollte deshalb auch alarmiert werden. Des weiteren lassen sich Pakete verwerfen, die grösser als die maximale Paketgrösse im Segment sind und das DF-Bit (Don’t Fragment) gesetzt haben.
Die gesamte Ereignisprotokollierung sollte auch regelmässig überprüft werden, um daraus Daten für eine kontinuierliche Optimierung der gesamten Sicherheitsumgebung zu gewinnen. Dazu gehört auch ein effektiver Change-Management-Prozess, der sicherheitsrelevante Konfigurationen vornimmt und Systeme regelmässig mit Security Patches nach vorgehenden Tests versieht.
Ein weiteres Augenmerk muss auf verschlüsseltem Datenverkehr liegen. Wie soll damit umgegangen werden? Eine Lösung kann der Einsatz eines hostbasierten ID/IP-Systems sein. Es sollte mit dem netzwerkbasierten System sehr gut integriert sein. Für eigene Server kann auch der Einsatz eines SSL-Beschleunigers interessant sein, der den Verkehr vor dem Server ver-/entschlüsselt, sodass ein netzbasierter Ansatz funktioniert. Für externe Verbindungen sollte auf alle Fälle ein Proxy mit Content-Filter eingesetzt werden.
Systeme mit dauerhafter Quarantäne-Funktion (durch Änderung von Router- oder Firewall-Regeln, Abschalten von Switch-Ports etc.) für einzelne IP-Adressen sollten nur zum Einsatz kommen, wenn das Spoofing von IP-Adressen im Netz ausgeschlossen werden kann. IP-Spoofing täuscht eine Quell-IP-Adresse vor, die dem Angreifer gar nicht gehört. Eventuell aber gehört sie dem potentiellen Ziel, das damit durch DoS-Angriffe oder durch eigene Quarantäne-Massnahmen ausser Gefecht gesetzt werden kann. Insbesondere in Richtung Internet sollte man ausschliesslich IPS-Systeme verwenden, die nur die Pakete eines Angriffs verwerfen. Quarantäne-Massnahmen gegen einzelne IP-Adressen sollten hier nur nach sehr genauer Prüfung ergriffen werden.
Es gibt einiges zu beachten beim Einsatz eines Intrusion-Detection-Systems. Fehler in der Planungsphase schlagen hier noch mehr als bei anderen Projekten im Betrieb voll durch. Daher sollte auf diesem Aspekt ein besonderes Augenmerk liegen, damit das Projekt ein voller Erfolg werden kann.
Viele Systeme bieten schon Voreinstellungen zur Angriffserkennung an. Jedes Unternehmen und jede Organisation sind aber verschieden: Applikationen, die beispielsweise in einer Umgebung für Forschung und Lehre gang und gäbe sind, können im Bereich Banken und Versicherungen als völlig unsicher klassifiziert sein und dürfen dementsprechend auch nicht eingesetzt werden.
IDS sind typischerweise so gestaltet, dass sie alle verdächtigen Ereignisse im Netzwerk protokollieren können. Eine Kategorie von Organisationen und Unternehmen muss eventuell aus Audit-Gründen auch Hacking-Versuche mitprotokollieren, eine andere Kategorie ist nur an erfolgreichen Angriffen interessiert. IDS/IPS müssen daher hoch konfigurierbar und transparent sein, um diesen Anforderungen gerecht zu werden. Auto-Learning und -Konfiguration sind mehr Wunschdenken als Realität: Nur am Anfang eines Projektes scheint es Vorteile für Systeme zu geben, die sich «automatisch» konfigurieren. Spätestens bei der ersten Ausnahme ertönt der Schrei nach einem flexibel konfigurierbaren System. Durch ein gut geplantes Projekt lässt sich der Tuning-Aufwand jedoch effektiv minimieren.
Markus Nispel ist Director Technology Marketing EMEA, Office of the CTO, Enterasys Networks.
