Das Cyber Attack Defense System analysiert Beobachtungen verschiedener Komponenten und agiert bei Bedarf.
Die medienwirksamen Attacken auf Server renommierter Firmen haben gezeigt, dass Hacker ihre Ziele nicht mehr nur mit konventionellen Mitteln verfolgen, sondern komplett neue Wege einschlagen. Klassisch wurde ein Angriff meist von einem oder wenigen Rechnern aus durchgeführt. Im Gegensatz dazu kann man heute feststellen, dass Cyber-Terroristen nicht mehr kleckern, sondern klotzen: Distributed Denial of Service Attacken, also gleichzeitige Angriffe von mehreren Orten aus auf ein Ziel, verwenden unzählige Rechner parallel, um eine Internet-Site in die Knie zu zwingen.
Dabei installieren die Hacker so genannte Agents auf vorher ausgespähten Rechnern, die vorzugsweise unbedeutend bzw. ungeschützt und schlecht überwacht sind. Der Angreifer teilt diesen Agents über eine verschlüsselte Verbindung mit, welches Ziel sie wann und wie angreifen sollen. Nach vollbrachter Fernwartung der automatisierten Helfer ist eine direkte Verbindung zwischen dem Urheber des Angriffs und den Agents fast nicht mehr herzustellen. Zum Zeitpunkt der eigentlichen Attacke muss der Hacker nicht einmal aktiv mit den Agents verbunden sein. Zusätzlich erschwert wird die Rückverfolgung durch die Tatsache, dass der Angreifer auch die Agents nicht direkt, sondern über eine Managementstation anspricht.
Da sämtliche Kommunikation zwischen den Hackertools verschlüsselt abläuft, lassen sich diese Tools auch in eigenen Netzen nur sehr schwer aufspüren. In der Folge können auch seriöse Unternehmen mit ihren Systemen ungewollt eine DDoS-Attacke unterstützen - was dem eigenen Ruf nicht gerade zuträglich sein dürfte.
Beim Angriff schicken die Agents üblicherweise eine hohe Anzahl von Verbindungsanfragen an den entsprechenden Server. Fatal sind dabei nicht die vielen dort ankommenden Anfragen oder deren Inhalt, sondern der extrem große Datenstrom, der schlagartig an den WAN-Verbindungen des angegriffenen Ziels ansteht. Kommt durch eine DDoS-Attacke ein volles Gigabyte Daten pro Sekunde an, so ist selbst eine ATM-Verbindung hoffnungslos überlastet - ganz zu schweigen von den Routern, die diese Datenlast verarbeiten sollen. Als Folge die-ses Overkills dringen keine Anfragen mehr bis zum eigentlichen Dienst vor.
Daher steht auch eine reine Firewall-Implementierung mit automatischer Rekonfigurierung des Gateways und der entsprechenden Router einem solchen Angriff machtlos gegenüber: Dem Angreifer den Zugang zum eigentlichen Ziel zu versperren, ist wirkungslos, da dieser auf Grund der Überlast auf den WAN-Verbindungen bereits gewonnen hat.
Das Cyber Attack Defense System analysiert Beobachtungen
verschiedener Komponenten und agiert bei Bedarf.
Gute Chancen, sich vor solchen Attacken zu schützen, hat man mit dem Cyber Attack Defense System (CADS) - einem kombinierten System aus unterschiedlichen Lösungen, die oft bereits im Einsatz sind, aber nicht interagieren. Außerdem bezieht CADS auch Internet Service Provider (ISP) mit ein. Da nur diese letztendlich die Möglichkeit haben, den ankommenden Datenstrom im Backbone zu sperren, muss das System einen ISP automatisch informieren können, um die Reaktionszeit auf einen Angriff zu minimieren. Ein solches Abwehrsystem muss also in der Lage sein, "normale" Angriffe und DDoS-Attacken selbstständig zu erkennen und entsprechende Gegenmaßnahmen einzuleiten.
Die erste Komponente eines CADS ist das Einbruchs-Erkennungssystem, auch Intrusion Detection System (IDS) genannt.
Auf der Grundlage der Datenpakete, die das Netzwerk passieren, erkennt und meldet dieser Netzwerkanalysator unterschiedliche Angriffsarten. Unter anderem können IDS heute folgende Angriffe erkennen:
Damit das IDS alle Pakete auf dem Netzwerksegment prüfen kann, schaltet es den eigenen Netzwerkadapter in den so genannten "Promiscuous Mode". In diesem Modus reagiert die Karte nicht nur auf Pakete, die an ihre eigene Hardwareadresse gerichtet sind, sondern empfängt sämtliche Daten auf dem Segment und überwacht so den gesamten Verkehr im Netzwerk. Dabei vergleicht das IDS die Pakete mit Angriffssignaturen, die wie bei einem Virenscanner immer auf dem neuesten Stand sein müssen.
Das System sitzt direkt vor der Firewall, um frühzeitig auf Probleme aufmerksam machen zu können. Ein IDS entdeckt nicht nur auf Netzwerkprotokollen beruhende Angriffe, sondern auch Applikations-basierte "Hacks", wie das sehr beliebte und weit verbreitete CGI-Hacking. Bei dieser speziellen Attacke versucht der Angreifer, Schwachpunkte in den CGI-Skripten auf Webservern auszunutzen, um diese zum Absturz zu bringen oder Zugriff auf die Betriebssystemebene zu erhalten.
Zu den am häufigsten angewendeten Methoden zählen hier sicherlich die Buffer Overflow Attacken. Der Angreifer setzt dabei auf Schwachstellen innerhalb der Speicherverwaltung in Kombination mit schlecht implementierten CGI-Programmen: Für eine Eingabemaske (z.B. Suchfelder, Kommentarfelder usw.) muss das System einen gewissen Speicherbereich (Buffer) reservieren, der zur Aufnahme der eingegebenen Zeichen dient. Hat der Entwickler der Programme vergessen, eine Überprüfung der maximal zulässigen Zeichenmenge zu implementieren, so können Angreifer diese Speicherbereiche überladen. Hierzu gibt man einfach mehr Zeichen ein, als der Buffer aufnehmen kann. Sobald er komplett gefüllt ist, bringt jedes weitere Zeichen den Buffer zum Überlaufen und die zuerst eingegebenen Zeichen werden in einen Systembereich geschoben. Bei genauen Kenntnissen über das System kann auf diesem Weg ein Angriffsprogramm platziert oder der Server mit wirren Zeichen einfach "abgeschossen" werden.
Erkennt das IDS einen Angriff, werden umgehend entsprechende Gegenmaßnahmen eingeleitet und Warnmeldungen verschickt. Dies geschieht nicht über den Adapter im Promiscuous Mode, da dieser keine IP-Adresse besitzt, sondern über einen getrennten zweiten Anschluss. Dieser ist mit der Firewall verbunden und dient ausschließlich zur Übertragung von Alarmen und zur Administration. Darüber wird zunächst auf der Cyber Attack Defense Konsole ein Alarm für den Systemadministrator ausgelöst. Dieser Alarm kann ein einfaches Pop-up-Fenster, eine E-Mail, ein SNMP-Trap oder der Start eines selbst definierten Programms sein, das zum Beispiel einen Pager aktiviert.
Als aktive Gegenmaßnahme teilt das IDS über die Protokoll-Schnittstelle Suspicious Activity Monitor Protokoll (SAMP) der Firewall mit, dass es gerade einen Angriff erkannt hat. Die Firewall selbst baut daraufhin dynamische Regeln auf, um zu verhindern, dass der Angriff das Gateway passieren kann und um bereits etablierte Verbindungen zu unterbrechen. Zudem werden die Access Listen der betroffenen Router rekonfiguriert. Da diese Listen schon vor der Firewall den Zugang vom Internet her regeln, können Attacken bereits hier über die Paketfilter abgeblockt werden.
Nach dem IDS bildet die schon erwähnte Firewall die nächste Komponente des CADS. Die Firewall enthält ebenfalls Systeme zur Erkennung und Abwehr verschiedener Angriffe. Eine beliebte Methode der Denial of Service Attacken ist beispielsweise das SYN-Flooding. Hier bedient sich der Hacker einer fast menschlichen Eigenart von Computern - des so genannten 3-Way Handshake, der beim Aufbau von TCP-Verbindungen verwendet wird. Wie wir Menschen kommunizieren auch Computer erst dann, wenn sie sich erfolgreich "per Handschlag" begrüßt haben. Der Hacker leitet bei dieser Methode unzählige Handschläge ein, schließt sie aber nicht ab.
Der angegriffene Server reserviert nun für jeden eingeleiteten TCP-Verbindungsaufbau Speicher, um die einzelnen Anfragen später abschließen zu können. Ist diese so genannte Backlog Queue voll, kann der Server keine weiteren Verbindungsanfragen mehr annehmen und ist damit zum Opfer einer klassischen Denial of Service Attacke geworden. Handelt es sich zudem um eine Distributed DoS Attacke, können Angreifer damit selbst große Serverfarmen in kürzester Zeit "dichtmachen".
Die FireWall kann SYN-Attacken mit zwei unterschiedlichen Verfahren entgegenwirken. Bei jedem Verbindungsaufbau - egal ob er zu einem Angriff oder einer ganz normalen Anfrage gehört - täuscht das SYN Defender Gateway dem angesprochenen Ziel immer eine erfolgreiche Durchführung der Verbindungsanfrage vor: Der 3-Way Handshake wird vom Gateway immer vollständig beim Server hinter der Firewall abgeschlossen. Dieser kann dann die Verbindungsanfrage wieder aus seiner Backlog Queue entfernen und sie als reguläre offene Verbindung behandeln. Die meisten Server verwalten im Gegensatz zu den halb offenen Verbindungen in der Queue problemlos mehrere tausend etablierte Verbindungen gleichzeitig.
Ein SYN Defender Gateway in der Firewall schließt
zunächst selbst alle halboffenen Verbindungen zu internen
Servern und reicht dann entweder die Pakete von außen durch
oder schließt die Verbindung zum Server durch Reset (RST),
wenn kein Acknowledge (ACK) von außen eintrifft.
Das Gateway schreibt für sich nun einen Eintrag über diese offene Verbindung in seine internen Statetables. Diese Eintragungen enthalten zu jeder Verbindung Informationen über Quelle, Ziel und Dauer der Inaktivität einer etablierten bzw. noch nicht vollständig etablierten Session. Stellt das Gateway nun nach einem gewissen Zeitraum fest, dass über eine bestimmte Verbindung seit geraumer Zeit keine Daten übertragen wurden oder der Handshake nicht abgeschlossen ist, terminiert es automatisch die Session in Richtung des Servers mit einem TCP-Reset. Die offene Verbindung wird dadurch aus den Server-Tabellen gelöscht bzw. aus der Backlog Queue ausgetragen.
Ein passives SYN Defender Gateway funktioniert ganz ähnlich, aber mit dem Unterschied, dass hier das Gateway den erfolgreichen Handshake nicht simuliert. Es merkt sich, dass ein Handshake eingeleitet wurde und prüft, ob er innerhalb einer bestimmten Zeitspanne vom Absender der Anfrage korrekt abgeschlossen wird. Ist dies nicht der Fall, sendet das Gateway dem Server eine Abbruchmeldung für diesen Verbindungsaufbau, so dass dieser wiederum seine Backlog Queue leeren kann. Dieser Vorgang läuft jedoch wesentlich schneller ab, als ein Server üblicherweise die Eintragung aus seiner Backlog Queue löschen würde.
Passive SYN Defender Gateways reichen die Kontrollbotschaften
einfach nur durch, reagieren aber bereits nach kurzer Zeit mit
RST-Anweisungen auf ausbleibende Bestätigungen von
außen.
Jede Verbindung, die über das Firewall-Gateway läuft, erzeugt einen Eintrag in die Protokolldatei. Diese Log-Informationen werden permanent von der nächsten Komponente des CADS, dem Malicous Activity Detection (MAD) Monitor, analysiert. Auf Basis der zahlreichen Informationen in dieser Log-Datei kann der Monitor eine ganze Gruppe von Angriffen und fragwürdigen Aktivitäten erkennen und eine bzw. mehrere automatische Gegenmaßnahmen einleiten. So erkennt die MAD zum Beispiel, ob ein Angreifer systematisch versucht, offene Serviceports mittels Port-Scanning zu finden, oder eine hohe Zahl erfolgloser Login-Versuche erzeugt. Die automatische Analyse der Log-Dateien hat im Gegensatz zu einem IDS den Vorteil, dass auch Angriffe auffallen, die eine längere Zeitspanne beanspruchen. Ein IDS muss sämtliche Netzwerkpakete analysieren und kann aus diesem Grund "langfristige" Attacken nicht erkennen, da hierfür extrem viel Speicher und vor allem Rechenkapazität erforderlich wären.
Um massiv parallele Angriffe aus dem Internet aufdecken zu können, überwacht auf der FireWall der NetQuota Häufigkeit und Ursprung aller Verbindungsanfragen. Bemerkt die Komponente, dass ausgehend von einer oder mehreren bestimmten IP-Adressen unverhältnismäßig viele Anfragen das Gateway passieren wollen, so sendet NetQuota sofort einen Alarm an die Cyber Attack Defense Kon-sole. Diese löst wiederum die oben beschriebenen Alarmfunktionen aus. NetQuota arbeitet auch direkt mit ServerQuota zusammen, das auf dem Dienste-Server läuft. Wie Net Quota ist Server Quota in der Lage, das Verhalten der Verbindungsanfragen im Hinblick auf Denial of Service Attacken zu untersuchen.
Wichtig bei diesen beiden Systemen ist die korrekte Parametrisierung. Eine zu "scharfe" Konfiguration der Schwellwerte hätte zur Folge, dass auch der normale Betrieb laufend für Alarme sorgen würde, wenn das Verbindungsaufkommen kurzzeitig ansteigt, ohne dass aber ein Angriff stattfindet. Bei der Implementierung dieser Tools ist es daher wichtig, zuvor eine ausführliche Analyse des üblichen Netzwerkverkehrs durchzuführen, um so genau definieren zu können, was normal und was eine DDoS Attacke ist.
Zur Programmierung der Stateful Inspection Engine in
Firewall-1-Systemen hat Check Point eine spezielle
"Maschinensprache" für diesen virtuellen Prozessor
entwickelt.
Sowohl Net- als auch ServerQuota sind als Programme in der von Check Point entwickelten und patentierten Stateful Inspection Engine implementiert - dem Herz einer jeden FireWall-1. Diese Engine überwacht alle Netzwerkaktivitäten, abhängig von den definierten Regeln des Administrators. Man kann sich diese Engine als virtuellen Prozessor im Firewall Gateway vorstellen. Dieser Prozessor arbeitet ein Programm ab, das ankommende IP-Pakete analysiert und in einen logischen Kontext zueinander stellt. Dieses Pseudocode-Programm besteht, wie es sich für einen richtigen Prozessor gehört, aus den Inspect Machine Language Befehlen - einem Befehlssatz, der große Ähnlichkeit mit den Befehlssätzen realer Prozessoren aufweist, jedoch spezielle Eigenheiten für die Bearbeitung und Analyse von IP-Paketen enthält.
Über eine grafische Benutzeroberfläche lassen sich
für die meisten Anwendungsfälle jedoch automatisch
Inspect-Scripts erzeugen.
Der Administrator der FireWall-1 hat zwei Möglichkeiten, das Gateway zu konfigurieren: Zum einen kann er die Programme für die Inspect Engine von Hand in der Inspect Script Sprache programmieren und kompilieren. Oder - was in 99% aller Fälle genügt - er verwaltet das System einfach mittels der grafischen Benutzeroberfläche und definiert so das Regelwerk des Gateways. Ein Codegenerator erstellt dann aus dem grafisch aufgebauten Regelwerk automatisch ein entsprechendes Script, das der Compiler anschließend in ein lauffähiges Programm für den Inspect Prozessor umwandelt. Dabei stützt sich der eingebaute Compiler auf diverse bestehende Libraries, in denen vordefinierte Programmteile für die Absicherung der verschiedenen Dienste sowie für die speziellen Sicherheitsfunktionen wie NetQuota und ServerQuota implementiert sind.
Zur exakten Gateway-Programmierung kann der Administrator
Inspect-Scripts von Hand programmieren.
Der Codegenerator stützt sich bei der Script-Erstellung auf
vordefinierte Programmteile.
Das gesamte System würde im bis jetzt beschriebenen Umfang jedoch nur den Angriff bis zum eigenen Router abwehren. Die Datenflut auf der WAN-Verbindung wäre so noch nicht in den Griff zu bekommen. Aus diesem Grund löst die CADS-Konsole selbst bei einem Alarm zwei weitere Aktionen aus, die so genannten Intrusion Response und den Internet Alert.
Intrusion Response ist eine offene Protokollschnittstelle, mittels derer Sicherheitsprodukte, die nicht zum Kern von CADS gehören, über einen Angriff informiert werden können. Zum jetzigen Zeitpunkt findet man vor allem Lösungen aus dem Bereich des Loadbalancing, die diese Informationen nutzen, um Reaktionen einzuleiten. Mit diesen Produkten ist es dann möglich, eine Lastverteilung auf mehrere Server und Firewall-Gateways zu aktivieren, um so das Problem des hohen Datenaufkommens zu entschärfen.
Über den Internet Alert landen die Information über einen Angriff beim Internet Service Provider (ISP). Damit kann dieser direkt auf den Angriff reagieren, zum Beispiel durch Rekonfiguration seiner Firewalls, Router und Loadbalancer. So wird die Attacke vom ISP schon am eigenen Knotenpunkt abgewehrt. Erst durch diese Maßnahme ist es möglich, auch den ankommenden Datenverkehr der DDoS-Attacke zu unterbinden. Bis vor kurzem war dies, wenn überhaupt, nur mit erheblichem Zeitverlust manuell zu realisieren. Vorstellbar wäre hier auch eine automatisierte Kooperation der unterschiedlichen ISPs, um so bereits die Quellen des Angriffs global abzublocken.
Das Zusammenspiel zwischen den einzelnen Komponenten und den ISPs ist nur mittels der OPSEC-Allianz möglich (Open Platform for Security, www.opsec.com). In dieser von der Firma Check Point 1996 ins Leben gerufenen Allianz sind heute mehr als 250 der führenden Unternehmen aus allen Bereichen der Netzwerk- und Sicherheitstechnologie vertreten. Die einzelnen Lösungen können mit den Check Point Komponenten über die OPSEC APIs kommunizieren (Application Programming Interfaces). Durch diese Protokollschnittstellen verfügen Anwender nicht über eine isolierte Firewall, sondern über eine komplette Sicherheitsplattform, die offen für zusätzliche spezialisierte Lösungen ist. Die breite Unterstützung der Internet Service Provider für CADS ergibt sich ebenfalls aus der OPSEC Allianz, in der Check Point eng mit den weltweit führenden Anbietern zusammenarbeitet. Bis zum gegenwärtigen Zeitpunkt haben sich die Unternehmen British Telecom's Concert, GTE Internetworking, ESOFT Global, Intermedia und Telenisus der CADS Initiative angeschlossen. Für die nahe Zukunft werden weitere Teilnehmer erwartet.
Mit CADS ist man heute in der Lage, die gefürchteten DDoS Attacken besser in den Griff zu bekommen. Von zentraler Bedeutung ist hier aber, inwieweit die ISPs solche Systeme auf globaler Ebene unterstützen werden. Den Angreifer selbst zu finden, wird jedoch weiterhin ein schwieriges - wenn nicht sogar unmögliches - Unterfangen bleiben. Diese Personen sind meist nicht dumm genug, um einen solchen Angriff vom eigenen Internetzugang oder dem eines Bekannten/Verwandten aus zu planen und durchzuführen. Die bekannten Tools wie zum Beispiel "Stacheldraht" bieten zudem auch einem absoluten Anfänger die Möglichkeit, solche Angriffe zu starten. Daher muss die IT-Welt wohl leider davon ausgehen, auch zukünftig mit DDoS-Aktionen schmerzvoll konfrontiert zu werden, ohne auf abschreckende Schadenersatzprozesse verweisen zu können.
Thomas Winter ist Regional Technical Manager bei Check Point Software Technologies GmbH.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2000, Seite 64
