Da Angriffe sich auf Software-Schwächen konzentrieren, greifen reaktiven Abwehrmaßnahmen zusehends zu kurz. Anomalie-Detection lernt das Verhalten des Netzwerks und meldet jede abnorme Situation, um daraufhin reaktive Maßnahmen anzustoßen.
Kämpfe wurden schon immer geführt um Wissen und Besitz. Denn beides bedeutet Macht. Die Aufgabe, diese Werte in der digitalen Welt zu schützen, liegt beim IT-Sicherheitsverantwortlichen. Er muss ein Bollwerk errichten und pflegen, an dem die Angriffswellen abperlen. Die Geschichte hat leider oft genug gezeigt, dass selbst das zu seiner Zeit modernste Abwehrsystem vor neuen Angriffstechniken, List und Tücke kapitulierte. Der Niedergang Trojas in Homers Odyssee ist wohl der berühmtes-te Fall, bei dem die List des Odysseus den Fall der Stadt herbeiführte. Als Anfang des 14. Jahrhunderts historisch belegt zwei Ritter erstmals Me-tallstücke mit Schießpulver aus Pulverbüchsen katapultierten und auf ihre Gegner richteten, hat dies die Kriegsführung radikal revolutioniert. Bisherige Abwehrmaßnahmen und -strategien waren dem nicht gewachsen.
Der IT-Sicherheitsverantwortliche ist in der schwierigen Lage, dass beides, dreister Erfindungsgeist und Tücke, sein Bollwerk auszuhebeln versucht. Dabei sind die Innovationszyklen dem Internettempo angepasst. Wenn etwas Neues gefunden wird, ist es in wenigen Wochen weltweit bekannt und in automatisierte Tools einprogrammiert. Der Sicherheitsadministrator steht einer anonymen Front aus Crackern gegenüber, die ihre Angriffswerkzeuge ständig verändern, um neue Wege um und durch die Abwehrmechanismen zu finden.
Die Qualität der Angriffsmaßnahmen ist eng an Wissen und Intelligenz der Cracker gekoppelt. Den Löwenanteil machen Skript-Kiddies aus, die dickfingrig automatisierte, leicht zu bedienende Werkzeuge aus dem Internet laden. Ihr Aktionsradius ist verhältnismäßig beschränkt, da ihre Angriffsmethoden auf bekannten Verfahren basieren. Ihre Schritte sind leicht zu durchschauen und greifende Gegenmittel längst entwickelt, auch wenn es nervenaufreibend bleibt, ihre Versuche immer von Neuem abzuwehren. Eine große Gefahr bedeuten sie aber nicht.
Anders die Spezialisten auf diesem Feld: Sie brechen nicht zum Selbstzweck in ein Netz ein, um ihr Ego mit Trophäen aufzupolieren. Sie missbrauchen interne Ressourcen vielmehr für andere kommerzielle Zwecke. Sei es als Spam-Relay oder als Redirection-Proxy, um vom Unternehmensnetz aus getarnt andere Umgebungen zu attackieren. Mark Sunner, Chief Technology Officer beim E-Mail-Security-Dienstleister MessageLabs, warnt, dass gerade diese kommerzielle Interessen den Charakter des Hackings veränderten. »Die Gemeinde versucht, viele Wirtsysteme im Internet zu erschaffen, um sie als Spam-Relay zu missbrauchen.« Sie tarnen sich mit den infizierten Systemen, damit juristische Ansprüche nicht sie, sondern den Besitzer korrumpierter Plattformen treffen. Heikel ist die Situation deswegen, weil Spam Geld macht, auch wenn man das bei all den teils skurrilen Inhalten von »Enlarge your Dig« bis hin zu »Business Offern« kaum glauben mag. Die Spammer machen nach Messagelabs genug Umsatz, um ein bis zwei professionelle Techniker zu beschäftigen, die für genügend Wirte sorgen sollen. Diese Cracker kennen die Schwachstellen, wissen um Konfigurations- und Software-Lücken in Firewalls, Applikationsservern und Diensten. Sie kennen den Alltag der Gegenseite mit seinen Schwierigkeiten und Engpässen. Sie wissen genau, wie sie ein Netzwerk ernsthaft verletzen können.
Mit welchen Mitteln kann man sie aufhalten, ihre Aktionen im Keim ersticken? Intrusion-Detection-Scanner erkennen nur das, worauf sie per Konfiguration angesetzt sind. Detaillierte Informationen über das legale Verkehrsmuster generieren sie nicht. Konventionelle Werkzeuge wie RMON und Netzwerkmanagement-Tools sind gut darin, Link-relevante Daten zu sammeln. Sie sind aber nicht fähig, den Administrator permanent über geänderte Verkehrsmuster und -profile auf dem Laufenden zu halten. Man kann den langen Weg über Netzwerk-Analysatoren gehen, um das Verkehrsverhalten im Detail zu durchleuchten. Werkzeuge wie die Sniffer von Network Associates oder »tcpdump« müssen die protokollierten Daten allerdings mit einer Reihe von Prozessen überarbeiten, um das tatsächliche Verkehrsmuster zu extrahieren. Die Industrie hat daher Network-Anomalie-Detection-Produkte entwickelt, die sich auf das Verkehrsmuster im Ganzen spezialisieren. Sie sollen als interner Nachrichtendienst Indizien sammeln, die in Berichten aufgearbeitet einen potenziellen Angriff dokumentieren. Sie versprechen, dass sie aufkeimende Angriffe in ihrer Entstehungsphase identifizieren. In der Odyssee hätten sie sicher einen Blick in das trojanische Pferd geworfen und die Griechen enttarnt.
Der Begriff Anomalie-Erkennung ist mehrere Jahre alt und wird für verschiedene Zwecke verwendet. Im Prinzip sind Anomalien gleichzusetzen mit abnormem Verkehr. Hinter diesem Begriff verbirgt sich eine Reihe von Symptomen, seien es halb offene TCP-Sessions, ein hoher Anteil von ICMP-Paketen, unvertraute Paketfragmente oder Daten mit Quell- und Zielinformationen, die einen reservierten Adressbereich oder lokalen Host zu erreichen versuchen.
Jede Anomalie für sich lässt andere Schlüsse zu. So geben ungewöhnlich hohe Anteile von ICMP-Daten ein Echo des Angriffs ab und sind entsprechend zu interpretieren. Sie aufzudecken bedeutet, Grenzwerte für die verschiedenen Protokollvarianten zu bestimmen, die bei jedem Netzwerk natürlich anders ausfallen. Paketfragmente oder viele halbgeöffnete TCP-Verbindungen dagegen weisen direkt auf Angriffe hin und sollten sofort Alarm auslösen. Andere Angriffssymptome verstoßen gegen Protokollregeln. Sie lassen sich direkt auf dem Netzwerk-Layer erkennen oder sind in Layer-7-Protokollen eingebettet.
In der Praxis zeigen Anomalien verschiedene Symptome: Veränderte Bandbreitenmuster im Allgemeinen oder bezogen auf einen speziellen Dienst; missgebildete Verkehrsströme; inkonsistente Verkehrsmuster, beispielsweise eine Vielzahl unbestätigter TCP-SYN-Pakete; Client-Nodes, die einen Dienst anbieten, den sie vorher nicht unterstützten; Server, die sich wie Clients verhalten; Nodes, die eine statische Policy verletzen wie »Nur Webserver dürfen Daten an die Datenbank schicken und von ihr erhalten«.
Gerade letztere Kategorie »Regelverstoß« ist ein eindeutiger Indikator eines Angriffs, weil sie eindeutig beweist, dass das Netzwerk definitiv korrumpiert wurde. Sie ist inhaltsvoller als jeder IDS-Alarm, weil sie ausgehend von grundlegenden Messungen aufdeckt, dass sich das Verhalten des Netzwerks ohne explizites, legales Zutun interner Personen verändert hat. Sie beweist, dass beispielsweise Anwender auf eine Applikation zugreifen, für die sie nicht berechtigt sind. Zum besseren Verständnis dieser Kategorie einige Beispiele: Die Protokolle Telnet und SNMP sind für Netzwerk-Managementbelange unverzichtbar. Allerdings ist es in der Regel nicht zulässig, dass diese Protokolle von extern ansteuerbar sind oder nach außen hin kommunizieren. Der Webserver, der nur Verkehr über den Port 80 aufbauen darf, beginnt auf einmal, Verbindungen über den FTP-Port zu akzeptieren. Wie soll ein Administrator all diese Verstöße aufdecken, wenn die Firewall am Rand seines Netzwerks eine verhältnismäßig gemäßigte Policy fährt – das ist die Regel – und all diese Dienste zulässt?
Die Sache klingt simpel, läuft aber auf eine prinzipielle Anforderung hinaus: Man muss wissen, was im Netzwerk vor sich geht, diesen Istzustand in Echtzeit mit ausformulierten Verhaltensbedingungen abgleichen, um auf dieser Basis auffällige Situationen zu erkennen und sie im Detail untersuchen zu können.
Um das Netzwerkverhalten zu lernen, zeichnen Anomalie-Detection-Geräte die Verkehrsflüsse, im Fachterminus Flows, auf. Gewöhnlich sind Flows als Datenstrom zwischen zwei und mehr Nodes definiert. Die Geräte protokollieren die Ströme, indem sie die Flows in Metadaten übersetzen. Darin sind Adressen, Ports, Flags und Bytes enthalten. Ein Flow beginnt typischerweise, sobald das erste einzigartige Paket auftaucht, beispielsweise das erste, einzigartige Tupel in UDP- oder TCP-Flows. Weil verbindungslose Protokolle keine Endsequenz senden, greifen die Geräte in dem Fall auf Timer und Timeout-Werte zurück. Die Werte legen einen Zeitraum fest, in dem eine Verbindung keine weiteren Daten mehr austauscht und demzufolge beendet sein muss. Bei TCP-Strömen liegt der Fall komplizierter. Da diese Sessions keinen eindeutigen Schlusspunkt setzen, müssen die Produkte Mutmaßungen darüber anstellen, wann die Verbindung tatsächlich endete. Verbindungen, die, obwohl sie über einen langen Zeitraum keine Daten austauschen, durchaus noch aktiv sind, verkomplizieren den schätzenden Messungsansatz. Der Test der Real-World Labs auf Seite 18ff zeigt, wie sich drei dieser Tools in der Praxis geschlagen haben. [ nwc, pm ]