Von: Bernd Reder
Immer wieder kommt es vor, dass Hacker die Websites von Unternehmen und Behörden angreifen. Teils wollen sie auf diese Weise gegen die Kommerzialisierung des Internet protestieren, teils stecken eher "sportive" Motive dahinter, sprich manche Angreifer betrachten es als Herausforderung, die Sicherungsmechanismen von Firmen wie AOL, Microsoft oder Amazon.com zu überwinden.
Solche Attacken können im E-Business-Zeitalter fatale Auswirkungen für die Betroffenen haben: Sie verhindern entweder, dass Kunden auf die Site gelangen oder beeinträchtigen zumindest die Performance des Web-Auftrittes.
Es gibt viele Gründe, weshalb Angriffe auf Websites schwer abzuwehren sind. Sie lassen sich zu fünf Schlüsselfaktoren zusammenfassen:
- fehlerhafte Software,
- Standards,
- Anonymität der Internet-Nutzer,
- Schwächen von Internet-Protokollen sowie
- die Tatsache, dass Unbeteiligte als Basis für Attacken missbraucht werden.
Der erste Faktor - Fehler in Programmen - hängt damit zusammen, dass keine Software perfekt ist. Komplexe Anwendungen oder Systemprogramme bestehen oft aus mehreren Millionen Zeilen Code. Deshalb ist es so gut wie unmöglich, alle denkbaren Einsatzszenarien durchzuspielen und jedes Sicherheitsloch zu stopfen. Eine weitere Ursache für die Verwundbarkeit von Websites sind, so paradox dies auch klingen mag, "richtige" oder De-facto-Standards. Das Rückgrat des Web ist eine relativ geringe Zahl von Protokollen, Betriebssystemen und Servern. Gleiches gilt für die Backend-Systeme, wie Datenbanken und Applikationsserver. Sobald also ein Hacker bei einem System einen Schwachpunkt ausgemacht hat, kann er dieses Wissen mehrfach nutzen.
Angreifer tauchen im Internet ab
Der dritte Punkt betrifft die Anonymität des Internet. Was auf der einen Seite gut ist, sprich das weitgehende Fehlen staatlicher Überwachung, erweist sich andererseits als Segen für User mit bösen Absichten. In vielen Fällen ist es kaum möglich, die Spur eines Angreifers bis zu dessen Heimatsystem zurückzuverfolgen. Teilweise nutzen Hacker fremde Rechner, um von dort aus ihre Aktionen zu starten, oder sie manipulieren die Quelladresse der IP-Pakete (Spoofing) und verwischen so ihre Spuren.
Der letztgenannte Faktor hängt mit dem vierten Punkt zusammen: systembedingten Schwachpunkten der Protokolle, die in IP-Netzen zum Einsatz kommen. Das Internet baut auf einer verbindungslosen (connectionless) Kommunikationsstruktur auf. Einige Protokolle, wie TCP, müssen jedoch verlässliche Punkt-zu-Punkt-Verbindungen etablieren können. Dies erfolgt im Rahmen eines TCP-Synchronisierungsprozesses zwischen Sender und Empfänger. Das Zielsystem erhält in diesem Fall vom Sender eine Anfrage (Synchronization Request) und wartet dann, dass der Empfänger darauf reagiert. In dieser Zeit befindet sich die TCP-Sitzung quasi in einem "embryonalen" Zustand: Die Session ist noch nicht aufgebaut, aber der Zielrechner (Empfänger oder Client) und der Server haben bereits Kontakt zueinander und warten in der Regel mehrere Minuten ab, ob die Sitzung zustande kommt. Ein Server lässt sich jedoch lahm legen, indem ein Angreifer innerhalb kurzer Zeit viele solcher "embryonaler" Sitzungen startet.
Der fünfte Grund, weshalb es häufig schwerfällt, eine Abwehrfront gegen Hackerattacken zu bilden, liegt darin, dass diese oft von Systemen unbeteiligter Dritter aus erfolgen. Dies war beispielsweise Anfang des Jahres der Fall, als einige der größten Websites angegriffen wurden. Zu den "bewährten" Techniken zählt, fremde Rechner zu veranlassen, auf vorgetäuschte Requests des "Opfer-Systems" zu antworten. Dieses wird dann von einer Flut von Antworten überrollt.
Angriffstechniken gegen Websites
Um eine Website lahm zu legen, gibt es mehrere Möglichkeiten. Ein beliebtes Mittel sind "Giftanschläge" (Poison Attacks). In diesem Fall übermittelt der Angreifer an den Zielrechner Daten, mit denen dieser nichts anfangen kann. Dies können verstümmelte Pakete oder solche mit Überlänge sein. Damit lassen sich die Pufferspeicher des Opfers zum Überlaufen bringen. Außerdem können die Daten "Malicious Code" enthalten, also Programme, die eine zerstörerische Wirkung entfalten.
Eine Alternative sind "State Resource Attacks". Sie zielen darauf ab, einen Server dazu zu bringen, eine Unmenge von Statusabfragen zu verarbeiten. Eines der bekanntesten Beispiele ist die TCP-SynAttacke. Speziell E-Business- und E-Commerce-Sites lassen sich angreifen, indem Server mit SSL-Session-Requests (Secure Socket Layer) bombardiert werden. SSL dient dazu, Bezahlvorgänge, etwa die Übermittlung von Kreditkartennummern, abzusichern. Die Daten werden zu diesem Zweck verschlüsselt. Es liegt auf der Hand, was passiert, wenn ein Server gleichzeitig zu viele solcher rechenintensiven Vorgänge abwickeln soll. Eine dritte Angriffstechnik besteht schlichtweg darin, die Ressourcen von Servern und die Verbindungsleitungen derart zu überfordern, dass das System letztendlich zusammenbricht oder nicht mehr erreichbar ist.
Um solche Attacken abzuwehren, müssen der Internet-Serviceprovider und der Systemverwalter des Anwenders zusammenarbeiten. Ein absolutes Muss ist, auch wenn das vielen Firmen noch immer nicht bewusst ist, eine möglichst stringente Sicherheitspolitik, inklusive eines Notfallplanes für den Fall, dass ein Angriff erfolgt. Das Ziel sollte sein, die Server "sauber" zu halten, also zu verhindern, dass ein Hacker sie mit schädlichen Programmen (Malicious Code) infiziert. Um Malicious Code aufzuspüren, können Virenscanner eingesetzt werden. Dass auch diese keinen 100-prozentigen Schutz bieten, zeigte unter anderem der Melissa-Virus.
Wenn ein Hacker Fremdrechner als Ausgangspunkt für Attacken nutzen möchte, muss er auf diesen nicht nur Malicious Code, sondern auch Anweisungen deponieren, welche Ziele angegriffen werden sollen. Er verwandelt damit den Fremdrechner in ein "Zombie-System". Diese Informationen sind meist in normalem TCP/IP-Verkehr versteckt, etwa in ICMP-Antwortmeldungen (ICMP = Internet Control Message Protocol). Solche "Marschbefehle" lassen sich mit Hilfe von Firewalls abblocken.
Abwehr stärken durch Einsatz von Web-Switches
Zu den gefährlichsten Angriffsformen zählen solche, die Adressen-Spoofing verwenden. Dabei wird teilweise die Source-Adresse des Angriffssystems durch einen Fantasiewert ersetzt, um zu verhindern, dass die Spur bis zum Hacker zurückverfolgt werden kann. Wie oben erwähnt, lässt sich auch die Source-Adresse gegen die des Zielsystems austauschen. Die Folge: Statt des Angreifers wird das Opfer mit Antwortmeldungen anderer Systeme überschüttet. Eine Möglichkeit, Web-Server gegen Poison Attacks resistent zu machen, besteht darin, den TCP/IP-Stack des Systems zu "härten". Das bedeutet:
- alle unnötigen Dienste und Daemons deaktivieren,
- Patches und neue Software-Releases umgehend einspielen,
- hereinkommenden Verkehr zu filtern.
Diese Aufgaben lassen sich auf die Firewall oder einen Web-Switch verlagern, der den Servern vorgelagert ist. Der Vorteil dabei ist, dass nicht jeder einzelne Server abgesichert werden muss, sondern nur der Switch. Er lässt sich auch gegen State Resource Attacks einsetzen. So ist ein Web-Switch beispielsweise in der Lage, eingehenden Verkehr nach unzulässigen Adressen oder defekten Paketen zu durchsuchen. Zudem sind diese Geräte meist für mehrere Tausend TCP-Verbindungen pro Sekunde ausgelegt. Das heißt, sie sind nicht so schnell an ihre Leistungsgrenze zu treiben wie ein Server.
Ein weiterer Vorteil ist, dass sich Web-Switches so konfigurieren lassen, dass sie Schwachpunkte der TCP-Protokollfamilie kompensieren. Statt, wie im TCP-Standard vorgegeben, Sitzungen im Anfangsstadium ("embryonale" Sessions") mehrere Minuten lang zu unterhalten, können Web-Switches eine Sitzung bereits nach wenigen Sekunden für "tot" erklären. Dies entspricht auch eher der gängigen Praxis. Denn diverse Studien haben ergeben, dass kein Internet-Nutzer bereit ist, mehr als acht bis zehn Sekunden zu warten, bis eine Verbindung zu einer Website etabliert ist.
Verteidigung gegen Resource Attacks
Schwieriger ist es, eine Website beziehungsweise die dahinter liegenden Server gegen "Resource Attacks" zu schützen. Die einfachste, aber auch teuerste Methode besteht darin, die Ressourcen so auszubauen, dass sie auch groß angelegte Angriffe verkraften. Eine Alternative bietet das "Global Server Load Balancing" (GSLB), also das Verteilen von Web-Services auf mehrere Server oder Sites. Dies hat den Vorteil, dass ein Angreifer nicht einen Dienst komplett blo-ckieren kann: Die Anfragen normaler User werden zu entfernten anderen Systemen weitergeleitet, die den gleichen Service anbieten.
Die Grundlage von GSLB ist ein zweischichtiges DNS-Modell. Jedem Dienst sind mehrere Namens-Server zugeordnet. Wenn ein User einen bestimmten Dienst nachfragt, prüft ein DNS-Server, welche Site diese Anfrage bedienen kann und übermittelt die entsprechende Adresse. Die Voraussetzung ist, dass ein Dienst auf mehreren Websites implementiert ist, jede Site mit einem anderen ISP verbunden ist und jede über eine virtuelle IP-Adresse (VIP) verfügt.
Eine Anfrage eines Client-Rechners nach einem bestimmten Service beziehungsweise einer URL wird in mehreren Schritten bearbeitet:
- Zuerst geht die Anfrage zum lokalen DNS-Server des Client.
- Dieser ermittelt über den Internic-Root-DNS-Server einen "Authoritative Name Server", welcher die gewünschte URL auflösen kann.
- Der Domain-Name-Server des Client erhält dann vom Authoritative Name Server eine VIP.
- Im letzten Schritt wird die VIP zum Browser des Users übertragen, der dann auf die gewünschte Web-Seite zugreifen kann.
Im Beispiel von Bild 2 stehen dem Internic-DNS vier IP-Adressen zur Verfügung, die auf die vier Authoritative-DNS-Server verweisen. Bei jedem dieser Server handelt es sich um einen Web-Switch mit WAN-Anbindung. Eine Anfrage durch einen Client läuft folgendermaßen ab:
- Der DNS des Client wählt einen der vier Einträge (ns1.mysite.com bis ns4.mysite.com) und stellt eine Verbindung zu einem Authoritative Name Server her.
- Wenn die Anfrage des Client-DNS an einen der vier Authoritative Name Server mit einem Time-out endet (Zeitüberschreitung), versucht er automatisch, mit einem der drei anderen Namensserver Kontakt aufzunehmen.
- Sobald der Domain-Name-Server des Clients versucht, die URL "www.mysite.com" mit Hilfe des ausgewählten Namensservers (beispielsweise ns3.mysite.com) aufzulösen, übermittelt dieser eine VIP, die diese Site bezeichnet.
- Wenn ein Angreifer versucht, www.mysite.com anzugreifen, wird bei dem angegebenen Verfahren dem "Zombie-Rechner", den er dazu einsetzt, nur eine IP-Adresse mitgeteilt.
- Sobald der Angriff angelaufen ist, werden Anfragen anderer Clients zu einer Site umgeleitet, die nicht attackiert wird. Dies erfolgt aus zwei Gründen: Zum einen erkennt der Web-Switch, dass die atta-ckierte Website überlastet ist und vergibt deshalb an nachfolgende Anfragen andere IP-Adressen. Zweitens kommt es zu einem Time-out, wenn ein Client-DNS die Adresse mit Hilfe eines DNS aufzulösen versucht, der gerade angegriffen wird. Die Folge: Der Client-DNS versucht es bei einem anderen Namensserver aus der Liste.
Das beschriebene Modell funktioniert gut bei Web-Diensten, die auf physikalisch getrennten Sites residieren. Das ist in der Praxis nicht immer der Fall. Der Hintergrund ist, dass das DV-Equipment von Sites mit großen Datenbanken typischerweise an einem zentralen Ort zusammengefasst wird (Collocation). Ein Hacker muss somit nur ein Ziel angreifen, um einen Web-Auftritt zu torpedieren oder zumindest den Datenabgleich zwischen den Servern zu stören.
Auch diese Klippe lässt sich mit Web-Switches umschiffen. Allerdings sind dazu Links zu internen "Peering Points" in unterschiedlichen Netzen erforderlich. In diesem Fall wird mit Hilfe der Switches quasi der Eindruck erweckt, dass ein Server-Cluster aus vielen einzelnen Systemen an unterschiedlichen Orten besteht, die auf einen zentralen Datenbestand zugreifen. Jeder Web-Switch benötigt dazu einen überlappenden und einen separaten Adressblock. Der DNS nutzt den überlappenden Adressenbestand, während die einzelnen Instanzen eines Web-Service - mit unterschiedlichen VIPs - auf den separaten Block zugreifen.