Hacker Angriffsarten

Hacker Angriff: Asynchrone State

Gefahr: Maskerade

Dieser Angriff [Joncheray 95] basiert auf dem Versuch, einen asynchronen Zustand auf beiden Seiten der TCP-Verbindung zu erzwingen, durch den der Angreifer Pakete erstellen kann, die auf beiden Seiten als echte Pakete akzeptiert werden. Dieser Angriff ist durch Verkehrsüberwachung zu erkennen. Die einzige Möglichkeit, sich vor diesem Angriff zu schützen, ist, die Daten zu verschlüsseln und zu signieren.

Hacker Angriff: Ausführbarer Code

Gefahr: Manipulation

Über HTTP können Java-Applets und ActiveX Controls übertragen werden. Außerdem dient das Multipurpose Internet Mail Extensions Protocol (MIME) dazu, den Aufbau einer Seite im HTML-Format zu beschreiben. Somit ist ausführbarer Code eine wesentliche Gefahr, die von HTTP ausgeht. Proxies können HTTP-Nachrichten auf ausführbaren Code untersuchen.

Hacker Angriff: Ausführbarer Code

Gefahr: Manipulation, Eindringen

Je nach Konfiguration könnte Software im FTP-Bereich manipuliert sein - besonders, wenn es sich um ausführbaren Code handelt. Ist ein Angreifer in der Lage, ausführbare Programme auf ein fremdes System zu bringen, so kann er dort “Trojanische Pferde” installieren. Dies können Programme sein, die intern Information sammeln und diese möglichst unbemerkt nach außen zurück zum Angreifer schmuggeln. Sie verstecken sich in einem scheinbar nützlichen ausführbaren Programm. Dieses kann per FTP angeboten oder per Mail verschickt werden - in jedem Fall muss der Empfänger dazu motiviert werden, das Programm zu starten. Es wird i.d.R. dann irgendeine für den Anwender sichtbare Funktion ausgeführt und im Hintergrund laufen die vom Angreifer eigentlich gewünschten Aktionen. Z. B. kann ein Trojanisches Pferd den internen Netzverkehr beobachten (Sniffing) und nach bestimmten Informationen filtern oder es wird bei einem Login aktiv und schreibt Nutzeridentifikation und Paßwort mit. Die gesammelten Informationen können beispielsweise per E-Mail wieder nach außen geschickt werden.

Hacker Angriff: Ausnutzen des anonymous ftp

Gefahr: Eindringen, Maskerade

Anonymous ftp - ein oft genutztes Programm zur Datenverteilung - stellt eine weitere Sicherheitslücke dar. Falls erwünscht, kann man den FTP-Server so konfigurieren, daß Externe ohne vorherige Autorisierung aus einem eingeschränkten Bereich des Systems Dateien kopieren können. Die Benutzer loggen sich mit dem Namen anonymous ein, um den Dienst zu nutzen. Einige Stellen verlangen die Mailadresse als Paßwort.

Der FTP-Dämon besitzt zumindest zu Beginn privilegierte Rechte, da er normalerweise ein Login zu einem Account inklusive der Passwortbehandlung ausführt. Neuere Implementierungen führen anschließend ein change userid durch. Das Protokoll nutzt Port 20. Port 20 gehört zum privilegierten Bereich.

Anonymous ftp ist ein sehr wertvoller Service. Jedoch muß große Vorsicht beim Administrieren ausgeübt werden. So sollte unter anderem keine Datei oder kein Verzeichnis im Bereich des anonymous ftp schreibbar oder im Besitz des FTP-Login sein, da der anonymous ftp mit dieser User-Idläuft. Ferner sollte vermieden werden, eine echte /etc/passwd-Datei im Bereich des anonymous ftp liegen zu lassen. Falls es das System zuläßt, sollten alle Einträge in dieser Datei gelöscht werden. Falls nicht, so sollte eine solche Datei als Dummy-File ohne echte Accounts erstellt werden.

Falls möglich, sollte ein FTP-Server verwendet werden, der die Begriffe “intern” und “extern” versteht. Dateien, die außerhalb erstellt wurden, können gekennzeichnet werden, damit sie für andere Externe nicht lesbar sind.

Hacker Angriff: Ausnützen von Sicherheitslücken, falsche Systemkonfiguration

Gefahr: Maskerade

In zunehmendem Umfang werden Sicherheitslücken in der Implementation oder Konfiguration des Network File System (NFS) von Angreifern ausgenutzt. Die entsprechenden Programme zum Ausnutzen dieser Lücken sind weit verbreitet. In der Regel kann ein erfolgreicher Angreifer jede beliebige Identität außer root annehmen.

Es ist normalerweise nicht notwendig, dass Rechner außerhalb des eigenen Subnetzes auf exportierte Platten zugreifen. Darum sollte der Zugang zu dem NFS-Protokoll auf lokale Maschinen eingeschränkt werden. Der NFS-Dämon läuft üblicherweise auf dem UDP-Port 2049. Ein direkter Zugriff auf den NFS-Dämon kann also unterbunden werden, wenn Pakete zu diesem UDP-Port nicht durch einen Router bzw. eine Firewall gelassen werden. Um das Restrisiko eines NFS-Dämons auf einem anderen Port auszuschalten, müßten alle UDP-Pakete gefiltert werden. Da dies aber entscheidende Auswirkungen auf den Betrieb des gesamten Rechnernetzes hat (alle UDP-Dienste würden abgewiesen), ist dies nur im Rahmen eines umfassenden Firewall-Konzeptes realisierbar.

Um den Zugang zum portmapper einzuschränken, sollten alle Verbindungen von Rechnern außerhalb des eigenen Netzes zu dem Port 111 für beide Transportprotokolle TCP und UDP abgewiesen werden [CA-94:15].

Neben den Sicherheitslücken in den o. g. Programmen kann auch die System-Konfiguration zu Problemen führen. Daher sollte der Zugriff auf Rechner, die den Zugriff zu NFS benötigen, beschränkt werden. Ferner sollten keine Dateisysteme an den eigenen Rechner oder an localhost exportiert werden, damit kein indirekter Zugriff über ein anderes Programm möglich wird. Wenn möglich, sollten die NFS-Zugriffe auf read-only (ro) beschränkt sein. Diese Option ro sollte bei dem Export auf dem Server benutzt werden. Zugriffe für den Benutzer root sollten ebenfalls nur dort erlaubt sein, wo sie unbedingt notwendig sind. Eine Authentisierung des Zugriffes über NFS findet nur statt, wenn man ein entsprechendes Verfahren aktiviert. Unterstützt werden z. B. DES (Option secure) oder Kerberos (Option kerberos). Ein DES-Verfahren wird in der Regel von dem Betriebssystem mitgeliefert. Sollte keine der o. g. Authentisierungsmethoden genutzt werden, so findet keine Überprüfung der zugreifenden Benutzerkennung statt. Somit kann jeder Benutzer (unter Verwendung eines entsprechenden Programms) auf die Daten der anderen Benutzer zugreifen. Besonders gravierend wirkt sich dieses Problem aus, falls der NFS-Server keine Kontrolle der Portnummern durchführt und so auch einen Zugang von nicht-privilegierten Ports (größer 1023) - also von jedem Benutzer - zuläßt. Bei der Aufteilung in privilegierte und nichtprivilegierte Ports ist zu beachten, daß dem Rechner aber auch dem Administrator selbst Vertrauen entgegengebracht werden muß, damit Rechner oder Administrator diese Vereinbarung nicht unterlaufen. Vielfach ist ein solches Vertrauen nicht gerechtfertigt, so daß diese Einteilung obsolet geworden ist. Gleiches gilt analog, falls einem System NFS-Zugang gewährt wird, welches keine Unterscheidung zwischen “privilegierten” und “nicht-privilegierten” Ports kennt (z. B. DOS).

Hacker Angriff: Diebstahl von Dateien, Wörterbuchattacke

Gefahr: Eindringen

Kommt ein Angreifer in den Besitz der Datei, in der Passwörter gespeichert sind, so hat er Zugang zu allen mit diesen Passwörtern geschützten Diensten und Hosts. Passwörter wurden in früheren UNIX-Versionen in der Datei /etc/passwd verschlüsselt gespeichert, die für alle zugänglich war. Somit konnte jeder über eine Wörterbuchattacke die dort gespeicherten Passwörter entschlüsseln. In heutigen UNIX-Versionen sind die Passwörter verschlüsselt in einer so genannten Shadow-Datei abgelegt. Diese ist nur mit privilegierten Rechten lesbar. Eine Wörterbuchattacke verschlüsselt gängige Wörter aus einem Wörterbuch und vergleicht das Ergebnis mit dem verschlüsselten Text. Mittels hoher Anfrageraten kann ein Angreifer so Passwörter entschlüsseln. Daher sollte vermieden werden, daß Unbefugte privilegierte Rechte auf einem System bekommen können. Ferner sollten aktuelle UNIX-Versionen eingesetzt werden. Andernfalls haben sogar Externe Zugriff auf verschlüsselte Passwörter, sofern sie den Domänennamen erraten. Dann ist eine Abfrage des NIS-Servers möglich. In der NIS-Paßwortdatei stehen wiederum die verschlüsselten Passwörter, so daß der Schutz durch die Shadow-Datei unterlaufen wird.

Hacker Angriff: DNS-Spoofing, Maskerade

Gefahr: Maskerade, Eindringen

Gelingt es dem Angreifer, den DNS-Baum, der Systemnamen in IP-Adressen umsetzt, derart zu manipulieren, daß dieser auf eine Anfrage gefälschte IP-Adressen zurückliefert, so kann der Angreifer den Namen eines vertrauenswürdigen Systems in seine IP-Adresse übersetzen. Umgekehrt kann der Angreifer den inversen DNS-Baum zu seinen Gunsten manipulieren, indem er dem inversen Eintrag mit der Adresse des Angreifersystems den Namen eines vertrauten Systems zuordnet. Beide Manipulationen ermöglichen dem Angreifer den Mißbrauch eines Dienstes, der nur anhand von IP-Adressen authentifiziert (z.B. rlogin). Aktuelle Implementierungen sind gegen den zweitgenannten Angriff immun, da sie, nachdem sie von DNS den mutmaßlichen Host-Namen erhalten haben, im Gegenzug die diesem Namen zugeordnete IP-Adresse prüfen. Ist es nicht die Quelladresse, so wird der Verbindungsaufbau abgebrochen und als sicherheitsrelevant protokolliert.

Hacker Angriff: DNS-Spoofing

Gefahr: Maskerade, Eindringen

Um im Internet mit einem anderen Rechner kommunizieren zu können, benötigt man dessen IP-Adresse. Diese Adresse setzt sich aus vier Zahlen zwischen 0 und 255 zusammen, also zum Beispiel 194.95.176.226. Da solche Nummern nicht sehr einprägsam sind, wird einer solchen IP-Adresse fast immer ein Name zugeordnet. Das Verfahren hierzu nennt sich DNS (Domain Name System). So kann der WWW-Server des BSI sowohl unter http://www.bsi.bund.de als auch unter http://194.95.176.226 angesprochen werden, denn der Name wird bei der Abfrage in die IP-Adresse umgewandelt.

Die Datenbanken, in denen Rechner-Namen die zugehörigen IP-Adressen zugeordnet sind und den IP-Adressen entsprechende Rechnernamen, befinden sich auf so genannten Nameservern. Für die Zuordnung zwischen Namen und IP-Adressen gibt es 2 Datenbanken: In der einen wird einem Namen seine IP-Adresse zugewiesen, und in der anderen einer IP-Adresse der zugehörige Name. Diese Datenbanken müssen miteinander nicht konsistent sein! Von DNS-Spoofing ist die Rede, wenn es einem Angreifer gelingt, die Zuordnung zwischen einem Rechner-Namen und der zugehörigen IP-Adresse zu fälschen, d. h. daß ein Name in eine falsche IP-Adresse und umgekehrt umgewandelt wird.

Dadurch sind unter anderem die folgenden Angriffe möglich:

r-Dienste (rsh, rlogin, rsh)

Diese Dienste erlauben eine Authentisierung anhand des Namens des Clients. Der Server weiß die IP-Adresse des Clients und fragt über DNS nach dessen Namen.

Web-Spoofing

Ein Angreifer könnte die Adresse www.bsi.bund.de einem falschen Rechner zuweisen, und bei Eingabe von http://www.bsi.bund.de würde dieser falsche Rechner angesprochen werden.

Wie leicht ist es nun, DNS-Spoofing durchzuführen?

Dies hängt davon ab, wie DNS-Spoofing durchgeführt wird und wie das Netz des Angegriffenen konfiguriert ist. Da kein Rechner alle DNS-Informationen der Welt besitzen kann, ist er immer auf Informationen anderer Rechner angewiesen. Um die Häufigkeit von DNS-Abfragen zu verringern, speichern die meisten Nameserver Informationen, die sie von anderen Nameservern erhalten haben, für eine gewisse Zeit zwischen.

Ist ein Angreifer in einen Nameserver eingebrochen, kann er auch die zur Verfügung gestellten Informationen abändern. Der Fall eines direkten Einbruchs auf einen Nameserver soll hier nicht weiter betrachtet werden. Vielmehr geht es darum, prinzipielle Schwächen im DNS aufzuzeigen.

Anhand zweier Beispiele sollen unterschiedliche Methoden aufgezeigt werden, mit denen DNS-Spoofing möglich ist.

• Ein Anwender am Rechner pc.kunde.de will zuerst auf www.firma-x.de und dann auf den Konkurrenten www.firma-y.de zugreifen. Um auf www.firma-x.de zugreifen zu können, muß er erst die zugehörige IP-Adresse bei seinem Nameserver ns.kunde.de nachfragen. Dieser kennt die Adresse auch nicht und fragt beim Nameserver von ns.firma-x.de nach. Dieser antwortet mit der IP-Adresse, die von ns.kunde.de an den Anwender weitergeleitet und gespeichert wird. Befindet sich in dem Antwortpaket von ns.firma-x.de neben der IP-Adresse von www.firma-x.de auch noch eine beliebige IP-Adresse für den Rechnernamen www.firma-y.de, so wird auch diese gespeichert. Versucht der Anwender nun, auf www.firma-y.dens.kunde.de nicht mehr bei dem Nameserver ns.firma-y.de nach, vielmehr gibt er die Informationen weiter, die ihm von firma-x untergeschoben wurde.
• Firma X weiß, daß ein Anwender mit dem Rechner pc.kunde.de auf den Konkurrenzrechner www.firma-y.de zugreifen will. Firma X verhindert dies, indem sie den Nameserver ns.kunde.de nach der Adresse www.firma-x.de fragt. Dieser muß beim Nameserver ns.firma-x.de nachfragen und bekommt wie in Beispiel 1) auch die falschen Angaben über www.firma-y.de zurück zuzugreifen, fragt der eigene Nameserver

Diese beiden Beispiele beruhen darauf, daß ein Nameserver auch zusätzliche Daten, die er gar nicht angefordert hat, akzeptiert. In den aktuellen Versionen der Nameserver-Software (z.B. bind) ist dieser Fehler beseitigt, so daß diese Art von Angriffen verhindert wird. Es ist allerdings unter Verwendung von IP-Spoofing noch immer möglich, falsche DNS-Einträge zu erzeugen. Dieser Angriff ist allerdings technisch viel anspruchsvoller.

Folgerungen: Falls hostbasierte Authentisierung vorgenommen werden (es sei hier noch einmal dringendst davon abgeraten, da diese Methode keinen Schutz vor IP-Spoofing bietet), sollten eine der drei folgende Konfigurationen (auch in Kombination) verwendet werden:

• Verwendung von IP-Adressen, keine Hostnamen.
• Hostnamen, aber alle Namen können lokal auf dem Rechner aufgelöst werden (Einträge in der /etc/hosts).
• Hostnamen, aber alle Namen werden direkt von einem Nameserver aufgelöst, der für diese Namen der sogenannte primary oder secondary Nameserverist, d. h. er hat sie nicht in einem temporären Cache, sondern dauerhaft abgespeichert.

Auf keinen Fall sollte ein hostbasierter Zugang über einen Hostnamen gewährt werden, wenn die Namensauflösung nicht direkt ausgeführt werden kann, also ein Cache zwischengeschaltet ist.

Hacker Angriff: Firewalls tunneln

Gefahr: Maskerade

Ein lokaler User verbindet sich über anonymous ftp zu einem remote FTP-Server (Port 21). Um eine Datei zu übertragen, wählt der Client des Users zunächst einen beliebigen TCP-Port, an dem er auf die Datei wartet. Der Client sendet ein PORT-Kommando, um diese Wahl dem Server mitzuteilen. Der Server antwortet, indem er eine aktive TCP-Verbindung zu dem angegebenen Host öffnet und die Datei versendet. Ist das Netz des Clients durch einen Paketfilter geschützt, so wird die Datenübertragung fehlschlagen, da der Server ja einen internen Port öffnen möchte. Ein Applikationsfilter untersucht die Daten nach diesem speziellen PORT-Befehl. Hat es diesen entdeckt, so läßt es eine Verbindung zwischen Remote Host und internem Client etablieren, da die Anfrage für eine solche Verbindung ja vom internen Client kam. Ist diese Verbindung erst etabliert, so kann sie beliebig lange bestehen bleiben. Öffnet ein bösartiger interner Nutzer eine FTP-Verbindung nach außen und gibt an, die Datei auf Port 23 (dem Telnet-Port) zu erwarten, so kann der Remote Host eine Telnet Verbindung zum Client erstellen. Dieser Angriff läßt sich mittels Java auch von externen Angreifern ausführen.

Hacker Angriff: Flooding

Gefahr: Denial-of-Service

SMTP kann als Basis für einen Denial-of-Service Angriff dienen. Dieser Angriff zielt darauf ab, die legitime Benutzung einer Maschine zu verhindern. Angenommen, ein Angreifer sendet von 50 Maschinen aus jeweils 1000 1-MB Mails an sein Opfer. Dann ist es wahrscheinlich, daß das System des Opfers dies nicht verarbeiten kann.

Es ist empfehlenswert, dass eine Organisation eine zentrale Einrichtung benennt, die für Mail zuständig ist. Dieser zentrale Mailserver sollte sich in einem Screened Subnet hinter dem äußeren Paketfilter befinden. Ein zusätzlicher innerer Mailserver hinter der Bastion-Host sollte über die Bastion-Host mit dem äußeren Mailserver Mails austauschen.

Hacker Angriff: Flooding, UDP Packet Storm

Gefahr: Denial-of-Service

Da UDP eine Flußkontrolle fehlt, kann es das Datennetz lahmlegen, indem es Router und Hosts mit Paketen überflutet. UDP hält sich an dieselben Konventionen für Port-Nummern und Server wie TCP, jedoch in einem eigenen Adreßraum. Meist verwenden die Server niedrige Port-Nummern. Da es keine virtuellen Verbindungen gibt, werden alle Pakete, die für einen bestimmten Zielport bestimmt sind, unabhängig von Quelladresse oder Quellport an denselben Prozeß weitergereicht.

Ein Denial-of-Service Angriff kann auch durch so genannten UDP packet storm auf einem System oder zwischen zwei Systemen gefahren werden. Auf einem System bewirkt er eine Leistungsminderung. Zwischen zwei Systemen kann er zum Netzzusammenbruch führen. Daher sollten unnötige UDP-Dienste auf jedem Host abgeschaltet werden, insbesondere die Dienste chargen (erzeugt eine lange Folge von Zeichen) und echo. Ferner sollten diese Dienste von einer Firewall abgewiesen werden. Der Angriff erfolgt nach folgendem Muster: Sobald eine Bezeihung zwischen zwei UDP-Diensten besteht, die jeweils Output produzieren, können diese Dienste eine hohe Anzahl an Paketen produzieren, die zu einem Denial-of-Service bei den Maschinen führen, auf denen die Dienste ablaufen. Für die Durchführung dieses Angriffs ist lediglich eine Netzverbindung notwendig. Wird zum Beispiel der chargen-Service eines Hosts mit dem echo-Service der gleichen oder einer anderen Maschine verknüpft, so werden eine sehr große Zahl an UDP-Paketen produziert. Die involvierten Maschinen werden überlastet. Sind mehrere solcher Verknüpfungen auf verschiedenen Rechnern etabliert, so kann die Überlastung das gesamte Netz betreffen. (CERT-Advisory CA:96.01).

Hacker Angriff: Fragmentation Attack

Gefahr: Eindringen

Der Fragmentierungsangriff zielt darauf ab, die Implementierung der IP-Fragmentierung derart auszunutzen, daß Filterregeln von Paketfiltern nicht auf die fragmentierten IP-Pakete passen und somit diese Fragmente durchgelassen werden. Im [RFC 1858] wird der Tiny Fragment Attack beschrieben. Dabei zerlegt der Angreifer seine Nutzdaten (z. B TCP-Pakete) in sehr kleine Fragmente. Dadurch wird z. B ein TCP-Header auf mehrere Fragmente aufgeteilt und kann daher von statischen Paketfiltern nicht analysiert werden. Eine Filterung aufgrund von Regeln, die z. B den TCP-Header betreffen, ist nicht mehr möglich. Als Gegenmaßnahme sollten Implementierungen von Paketfiltern verwendet werden, bei denen die Länge des Tiny Fragments nicht verändert werden kann.

Ein zweiter Angriff, der die IP-Fragmentierung ausnutzt, ist der sogenannte Overlapping Fragment Attack [RFC 1858]. Die derzeitige Internet-Protokoll-Spezifikation [RFC 791] beschreibt einen Reassemblierungsalgorithmus, der neue Fragmente produziert und dabei jeden überlappenden Teil der zuvor erhaltenen Fragmente überschreibt. Wird ein solcher Algorithmus angewendet, so könnte ein Angreifer eine Folge von Paketen konstruieren, in denen das erste Fragment (mit einem Offset der Länge Null) harmlose Daten beinhaltet (und dadurch von einem Paketfilter weitergeleitet werden kann). Ein beliebiges nachfolgendes Paket mit einem Offset, der größer als Null ist, könnte TCP-Header-Informationen (z. B destination port) überlappen. Diese würden durch den Algorithmus modifiziert (überschrieben) werden. Dieses zweite Paket wird von vielen Paketfiltern nicht gefiltert. Gegenmaßnahme hierzu ist, Paketfilter zu verwenden, die ein Minimum an Fragment-Offset für Fragmente verlangen

Hacker Angriff: Hijacking

Gefahr: Eindringen, Denial-of-Service, Maskerade

Wenn es einem Angreifer gelungen ist, privilegierte Rechte auf einem System zu erlangen, so kann er anschließend z. B mit Hilfe eines Tools den Kernel modifizieren. Dies ist auch von fremden Rechner aus möglich. Diese Modifikation erlaubt es ihm, bestehende Verbindungen eines beliebigen Benutzers des Systems zu übernehmen. Indem Angreifer eine bestehende Verbindung auf dem Verbindungsweg übernimmt, können Systeme übernommen werden, ohne daß ein Endknoten der Verbindung dabei direkt angegriffen wird. Man spricht in den beschriebenen Fällen von sogenanntem Hijacking [CERT-Advisory CA-95:01]. Somit umgehen Angreifer die Hürde Einmalpaßwort oder andere starke Authentisierungsmechanismen, denn sie übernehmen die Verbindung nachdem die Authentisierung erfolgt ist. Dieser Angriff läßt sich abwehren, wenn man verhindert, daß privilegierte Rechte erlangt werden können.

Hacker Angriff: IP-Source-Routing

Gefahr: Maskerade

Beim IP-Source Routing bestimmt der Quellknoten die Route eines Paketes im Internet. Der Zielknoten benutzt für seine Antwort die angegebene Route für den Rückweg.Der Quellknoten kann somit Antworten auf einen beliebigen Knoten umleiten. Jeder beliebige Zwischenknoten kann weitere für den Zielhost nicht sichtbare Umleitungen vornehmen. Ein Angreifer kann in diesem Fall jede gewünschte IP-Source-Adresse vorspiegeln. Daher sollten alle Pakete, die IP-Source-Routing-Informationen enthalten, abgewiesen werden.

Hacker Angriff: IP-Spoofing

Gefahr: Abhören, Maskerade

Ein kombinierter Angriff auf DNS und die Routingmechanismen beruht darauf, daß ein Angreifer alle Requests an den DNS, Namen in IP-Adressen zu übersetzen, mithört und stattdessen die IP-Adresse eines zuvor bereits gekaperten Hosts liefert. Dadurch kann der Angreifer die gesamte Kommunikation ausspähen und Paßworte sammeln. Somit sind DNS-Server ein sehr attraktives Angriffsziel. Dies impliziert, daß DNS-Server nur auf gesicherten Rechnern installiert sein sollten.

Hacker Angriff: NOTIFICATION

Gefahr: Denial-of-Service

Alle Authentisierungsfehler führen zum Aussenden der Nachricht NOTIFICATION und zum Abbruch der Border Gateway Protocol(BGP)-Verbindung. Da BGP über TCP und IP läuft, ist BGP verwundbar bezüglich der Angriffe auf TCP und IP. Jüngste Entwicklungen haben algorithmenunabhängige kryptographische Authentisierung für RIP und OSPF Nachrichten entwickelt [Atkinson 97]. Diese verwenden den Keyed MD5 Algorithmus, um den Knoten zu authentifizieren, der das Routingpaket sendet. Hierdurch werden alle Angriffe auf Routingprotokolle abgewehrt mit Ausnahme der Replay-Attacke. Das Inter-Domain Routing Protokoll wird BGP in Zukunft ersetzen. Es übernimmt jedoch die Authentisierungsmöglichkeiten von BGP.

Hacker Angriff: Passworte abhören

Gefahr: Maskerade, Eindringen

Im Gegensatz zu RIP besitzt OSPF ein explizites Authentisierungsfeld. Dies ist jedoch nur begrenzt von Wert: als Authentisierungsmechanismen werden lediglich Passworte benutzt. Jeder, der in der Lage ist, Routing-Protokolle in die Irre zu führen, ist auch in der Lage, Passworte, die über das lokale Ethernet wandern, auszuspähen.

Hacker Angriff: Penetration des DNS-Caches

Gefahr: Denial-of-Service

Ein Angreifer kann vor dem eigentlichen Eindringversuch den DNS-Cache seines Ziels mit Fehlinformationen infiltrieren oder durch Überfluten das DNS verwirren. Dann versagt die Konsistenzprüfung. Daher sollten gefährdete Systeme nicht namensbasiert, sondern adreßbasiert authentifizieren, obwohl Authentisierung durch IP-Adressen selbst einige Schwächen hat.

Hacker Angriff: PORT

Gefahr: Maskerade

Während der Client die Kommandoverbindung zum Port 21 des Servers aufbaut, ist der Server für den Aufbau des Datenkanals von seinem Port 20 zu einem Port (> 1023) des Clients verantwortlich. Dies stellt eine Sicherheitslücke dar, da sich Angreifer als Server ausgeben könnten. Daher sollte der Verbindungsaufbau für den Datenkanal umgekehrt stattfinden und seitens des Clients der Standardbefehl PASV statt PORT verwendet werden. Hierdurch wird erreicht, daß der Client eine zufällige Portnummer berechnet und auf diesem Port die Datenübertragung erwartet. Der Client kann dann eine Verbindung von diesem Port aus aufbauen, der TCP-Verbindungsaufbau findet also vom sicheren ins unsichere Netz statt.

Hacker Angriff: Portscan

Gefahr: Denial-of-Service, Sniffing

Durch systematisches Scannen aller Ports kann ein Angreifer feststellen, welche Dienste und Prozesse auf der Zielmaschine derzeit ablaufen. Das Scannen kann bei einigen Betriebssystemen auf Grund von Implementierungsschwächen zu einem Denial-of-Service oder sogar zu Systemabstürzen führen. Die erhaltenen Informationen können für weitere Angriffe verwendet werden (z. B. Sniffing).

Hacker Angriff: Recursive Zone Transfer Request

Gefahr: Maskerade

DNS besitzt einen Zonen-Transfer Request. Dieser kann dazu benutzt werden, einen Teil der DNS Datenbank zu kopieren [Bellovin 89]. Wendet ein Angreifer diesen Request rekursiv an, so kann er eine komplette Aufzeichnung des Namenraums produzieren. Um dies abzuwehren, besitzt DNS den Fehlercode refused. Jeder Zonen-Transfer Request von einem unbekannten Host sollte mit refused beantwortet werden. Allerdings kann die Authentisierung hier nur mittels IP-Source-Adresse erfolgen.

Jüngste Entwicklungen versuchen, DNS mit Authentisierungsmechanismen auszurüsten. Diese authentifizieren die DNS-Informationen, die ein Knoten als Antwort auf einen DNS-Request erhält. Sie erlauben ferner, unterschriebene öffentliche Schlüssel im DNS und im nachfragenden System zu speichern, um diese zu authentifizieren. Diese Erweiterungen werden derzeit im IETF standardisiert. Die öffentlichen Schlüssel können auch bei der Implementierung eines dynamischen Key-Managements verwendet werden [Atkinson 97].

Hacker Angriff: Replay-Attack

Gefahr: Maskerade

Indem dem Zielsystem eine falsche Uhrzeit vorgetäuscht wird, können bei Authentisierungsverfahren, die Zeitstempel benutzen, alte Authentisierungsnachweise wiederverwendet werden.

NTP sollte über ein Proxy geschaltet werden, damit einerseits eine Synchronisation möglich ist, andererseits eine Manipulation ausgeschlossen werden kann (z. B durch Einsatz von Kryptographie). Sofern eine genaue Zeitquelle im internen Netz vorhanden ist oder der Abgleich der Zeit mit der externen Welt nicht notwendig ist, ist NTP über eine Firewall obsolet. Es reicht aus, NTP intern zu betreiben. Sollte NTP jedoch zum Internet betrieben werden, so ist ein NTP-Server auf einem Bastion-Host als Proxy für einen internen Server empfehlenswert.

Hacker Angriff: Sequence Number Guessing

Gefahr: Einfügen gefälschter Nachrichten

TCP erkennt anhand der für jedes gesendete Paket neuen zufällig bestimmten Initial Sequence Number alte Pakete aus vorangegangenen Verbindungen (identifizierbar durch Quellsocket und Zielsocket). Somit ist ein Man-in-the-Middle-Angriff nicht möglich. Da eine Verbindung erst dann zustande kommt, wenn beide Seiten jeweils den Empfang der Initial Sequence Number der Gegenseite quittiert haben, ist somit ein Sicherheitsmechanismus gegen replay attacks vorhanden. Kann allerdings ein Angreifer die Auswahl der Initial Sequence Number seines Opfers vorhersagen, was nach [Morris, 85; Bellovin, 89] möglich ist, so kann der Angreifer seinem Opfer eine Verbindung mit einer vertrauenswürdigen Maschine vortäuschen. Über Protokolle, die zur Authentisierung lediglich IP-Quelladressen verwenden (z. B. die “r”-Dienste), gelangt der Angreifer somit in das Zielsystem. Dieses Eindringen nach dem Vorherbestimmen der Initial Sequence Number kann durch eine Firewall verhindert werden. Um das Vorhersagen der Initial Sequence Number zu verhindern, empfiehlt [Bellovin 89], den Zeitpunkt der Sequenznummernerhöhung zufällig zu bestimmen, wobei in kleinen Zeitabständen real zu wechseln ist.

Hacker Angriff: Sniffing

Gefahr: Maskerade

DNS ist eine reiche Informationsquelle für Systemnamen und -adressen, Organisationsstrukturen u.ä. Zusätzlich kann ein Angreifer mittels inverser DNS-Anfragen den gesamten Adreßraum des Datennetzes durchsuchen. Er erhält eine Liste von Host-Namen, über die er durch DNS-Anfragen weitere Informationen erhalten kann.

Hacker Angriff: Spoofing

Gefahr: Maskerade, Umleiten

Das Border Gateway Protocol (BGP) bietet schwache Mechanismen zur Authentisierung an. Dabei werden BGP-Sitzungen an Hand des BGP-Identifiers einer Instanz und der Nummer des autonomen Systems, die durch eine Instanz publik gemacht wird, im Marker-Feld authentifiziert. Diese Nummern können vorhergesagt oder ausgetestet werden. In der Open Message sind Felder reserviert für optionale applikationsabhängige Authentisierung. Wird von der Applikation ein starker Authentisierungsmechanismus verwendet, so ist die Gefährdung durch Spoofing abgewendet.

Hacker Angriff: Spoofing

Gefahr: Maskerade

Die meisten TCP- und UDP-Versionen für UNIX stellen sicher, daß nur der Systemverwalter Port-Nummern unterhalb 1024 (privilegierte Ports) benutzen kann. Fremde Systeme sollen der Authentizität von Informationen, die sie von diesen Ports erhalten, vertrauen können. Diese Einschränkung ist allerdings nur eine Konvention, deren Einhaltung von der Protokollspezifikation nicht verlangt wird. Spezifikationskonforme Implementierungen müssen sich also nicht an diese Konvention halten. Auf Einbenutzermaschinen wie PCs ist eine solche Regelung bedeutungslos. Auf Mehrbenutzermaschinen kann man jedoch privilegierten Port-Nummern aufgrund von IP-Spoofing nur dann trauen, wenn zusätzliche Maßnahmen wie Authentisierung oder Verschlüsselung der Adressen und Vertrauen in die Maschine und den Adminstrator insgesamt vorhanden sind.

Hacker Angriff: TCP-SYN-Flooding

Gefahr: Denial-of-Service

TCP-SYN-Flooding [CERT-Advisory CA-96:21] kann auf zwei Arten für denial-of-service-Angriffe auf Server verwendet werden. Zum einen kann ein Angreifer auf Basis von IP-Spoofing halboffene Verbindungen etablieren. Der Angreifer-Client sendet SYN, der Opfer-Server antwortet mit SYN-ACK, aber der Client bestätigt nicht mit ACK. Solange diese Bestätigung fehlt, ist die Verbindung also halboffen. Bei einer gewissen Anzahl von halboffenen Verbindungen ist der Server nicht mehr in der Lage, neue Verbindungen anzunehmen. Dieser Angriff kann verhindert werden, indem z. B. eine Firewall IP-Spoofing nicht zuläßt. Zum anderen ist TCP-SYN-Flooding auch ohne IP-Spoofing möglich, indem der Angreifer als Quelle eine Adresse angibt, zu der das SYN-ACK nicht geroutet werden kann, weil sie nicht existiert, oder für den Server nicht erreichbar ist. Um dies abzuwenden, können zustandsabhängige Filter nur eine begrenzte Anzahl von SYN-Paketen zulassen.

Hacker Angriff: Tunneling

Gefahr: Eindringen, Maskerade

Wenn eine Firewall einen Proxy als HTTP-Server einsetzt, ist auf folgendes zu achten: Da die Authentisierung nicht mit einem Proxy, sondern mit dem eigentlichen Benutzer jenseits des Proxies erfolgen soll, werden sogenannte Tunneling-Protokolle eingesetzt. Der Benutzer unternimmt einen zusätzlichen Handshake mit dem Proxy-Mechanismus. Dieser Handshake teilt dem Proxy die Zieladresse und den Port des Ziels mit. Ist die Firewall nicht Teil der Security-Session, so kann der HTTP-Proxy die verschlüsselten Daten nicht entschlüsseln. Der Proxy kann lediglich eine Transportverbindung zum externen Server aufbauen und diesem die kryptographisch behandelten Daten des internen Clients weiterreichen. Dieses Tunneln der Firewall kann von bösartigen Insidern ausgenutzt werden. Abhilfe schafft hier die Einbeziehung der Firewall in die Security Association zwischen Client und Server oder das Abweisen aller S-HTTP-Daten.

Hacker Angriff: Tunneln

Gefahr: Eindringen

Durch die Fragmentierung von IP-Paketen existiert wenig Information, auf die man eine Filterentscheidung basieren kann, denn bis auf das erste Fragment besitzen die Fragmente keine Portnummern. Besitzt ein Angreifer einen Komplizen im zu schützenden Bereich, so können Fragmente ohne Portnummern zum Tunneln einer Firewall verwendet werden. Das erste Fragment beinhaltet zwar die Portnummer und kann entsprechend gefiltert werden. Wird dies nicht weitergeleitet, so ist das Paket im Inneren unvollständig, und die übrigen Fragmente werden schließlich vom Zielknoten verworfen. Ist der Zielknoten allerdings im Besitz eines Komplizen des Angreifers, so kann dieser die Fragmente zusammensetzen. Analog kann der Komplize im zu schützenden Bereich gefälschte Fragmente ohne Portnummern erstellen, die vom externen Komplizen auf einer äußeren Maschine zusammengesetzt werden können. Um diesen drohenden Infomationsverlust abzuwenden, sollten also Fragmente ohne Portnummern von innen nach außen und umgekehrt bereits an der Firewall verworfen oder dort zusammengesetzt und überprüft werden. Dies ist mit zustandsabhängigen Filtern bzw. Paketfiltern, die Kontext speichern können, realisierbar.

Hacker Angriff: UDP-Spoofing

Gefahr: Maskerade, Eindringen

UDP-Pakete sind leichter zu fälschen als TCP-Pakete, weil es weder Quittungs- noch Laufnummern gibt. Es ist daher äußerste Vorsicht geboten, wenn man die Quelladressen solcher Pakete zur Authentisierung verwendet. Die Applikationen selbst müssen geeignete Sicherheitsvorkehrungen treffen.

Quelle: Bundesamt für Sicherheit in der Informationstechnik