|
2.1.1 ARP - Adress Resolution Protocolr />
Im allgemeinen werden IP-Pakete über ein Ethernet verschickt. Die Ethernet Geräte verstehen allerdings die 32 Bit breiten IP-Adressen nicht: Sie übertragen Ethernet-Pakete mit 48 Bit breiten Ethernet-Adressen. Daher müssen die IP-Treiber die IP Zieladressen mittels einer Tabelle in Ethernet-Zieladressen umsetzten. Das ARP liefert derartige Zuordnungen.
Dazu sendet ARP einen Ethernet-Broadcast, der die gewünschte IP-Adresse enthält. Der Host mit dieser Adresse oder ein stellvertretendes System antwortet mit einem Paket, welches das IP-Ethernet-Adresspaar enthält. Dieses merkt sich das fragende System, um unnötige ARP-Anfragen zu vermeiden.
Das Verfahren ist nur solange sicher, solange ausschließlich vertrauenswürdige Maschinen auf dem lokalen Datennetz senden können. Es ist nämlich möglich, daß einen Maschine getürkte ARP-Antworten gibt und auf diese Weise allen Datenverkehr auf sich selbst umlenkt. Dann kann sie sich sowohl als andere Hosts ausgeben als auch Datenströme en passant modifizieren.
Gewöhnlich schaltet man das automatisch ARP aus, und verwendet für sein Netzwerk fixierte Tabellen, um solche Attacken zu vereiteln.
2.1.2 TCP - Transmission Control Protocol
TCP stellt gesicherte virtuelle Verbindungen bereit. Verlorene oder verstümmelte Pakete werden nochmal übertragen und die Pakete in der gleichen Reihenfolge abgeliefert, in der sie gesendet wurden.
Abbildung Seite 26
Die Reihenfolge der Pakete wird durch die Laufnummer bestimmt. Jedes übermittelte Byte wird gezählt. Alle TCP-Pakete, außer dem allerersten einer Sitzung, enthalten eine Quittungsnummer, welche die Laufnummer des letzten in Folge korrekt empfangenen Byte zurückgibt. Die Startlaufnummer (initial sequence number) wird zeitabhängig zufällig bestimmt. Das sich die Startlaufnummer für neue Verbindungen ständig ändert, ist es TCP möglich, alte Pakete aus vorangegangenen Inkarnationen derselbsen virtuellen Verbindung zu erkennen.
Jede TCP-Nachricht enthält den4-Tupel
Durch diese Kombination aus Quell- und Zielsystem und jeweiligen Port-Nummern wird sie eindeutig einer bestimmten virtuellen Verbindung zugeordnet.
Es ist nicht nur erlaubt, sondern durchaus üblich, mehrere verschiedene Verbindungen über die gleiche lokale Port-Nummer abzuwickeln. Solange sich Zielsystem oder Zielport dieser Verbindungen unterscheiden, gibt es keine Probleme.
Server-Prozesse, die einen Dienst über TCP anbeiten, lauschen auf bestimmten Port-Nummern. Dies wird TCP-listen genannt. Per stiller Übereinkunft haben die Server-Ports niedrige Nummern. Diese Übereinkunft wird allerdings nicht immer eingehalten, was zu Sicherheitsproblemen führen kann.
Die Port-Nummern der Standarddienste werden als bekannt vorausgesetzt. Ein Port im Listen-Modus stellt im gewissen Sinn eine halboffene Verbindung dar: Nur Quellsystem und Quellport sind bekannt. Geht ein Paket mit einer Verbindungsanfrage ein, so werden die fehlenden Einträge ergänzt. Der Server-Prozeß kann vom Betriebssystem dupliziert werden, so daß weitere Anfragen auf den selben Port auch behandlet werden können.
Port Dienst
25 smtp
80 http
119 nntp
Die meisten TCP Versionen für UNIX Systeme stellen sicher, daß nur der Systemverwalter (root) Port-Nummern unterhalb von 1024 nutzen kann. Dies sind die priviligierten Ports. Fremde System 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. Die Konsequenz ist klar: Sie können privilegierten Ports nur dann trauen, wenn sie absolut sicher sind, daß das Quellsystem die Konvention einhält und korrekt administriert wird.
Die schon erwähnten Laufnummern haben auch einen gewissen Sicherheitseffekt: Eine Verbindung kommt erst dann zustande, wenn beide Seiten jeweils den Empfang der Startlaufnummern quittiert haben.
Da lauert aber auch die Gefahr: Wenn ein Angreifer die Auswahl der Startlaufnummern bei seinem Opfer vorhersagen kann - Erfahrungen haben gezeigt, daß dies unter bestimmten Bedingungen tatsächlich möglich ist -, dann kann er seinem Opfer eine Verbindung mit einer vertrauenswürdigen Maschine vortäuschen.
2.1.3 UDP - User Datagram Protocol
UDP stellt Applikationen die Datagram-Dienste von IP direkt zur Verfügung. Die Paketzustellung erfolgt ungesichert: verlorene, duplizierte oder in der Reihenfolge vertauschte Pakete werden nicht erkannt, selbst die Erkennung von Übertragungsfehlern ist optional und eine Fehlerkorrekture nicht vorhanden.
UDP tendiert zu ungünstigem Verhalten, wenn es für umfangreiche Übertragungen benutzt wird. Da dem Protokoll eine Flußkontrolle fehlt, kann es das Datennetz lahmlegen, indem es Router und Hosts mit Paketen überflutet. Durch diese Überflutungen steigen die Paketverluste im Netz drastisch.
UDP-Pakete sind viel leichter zu fälschen als TCP-Pakete, weil es weder Quittungs- noch Laufnummern gibt. Es ist daher äußerste Vorsicht geboten, wenn man die Quelladresses solcher Pakete verwendet. Die Applikationen selbst müssen geeignete Sicherheitsvorkehrungen treffen.
2.1.4 ICMP - Internet Control Message Protocol
Mit ICMP läßt sich das Verhalten von TCP- und UDP-Verbindungen beeinflussen. Es dient dazu, Hosts günstigere Routen zu einem Ziel bekannzugeben, über Routing-Probleme zu informieren oder Verbindungen wegen Problemen im Datennetz abzubrechen.
Viele ICMP Nachrichten, die einen Host erreichen, sind nur für eine bestimmte Verbindung relevant oder durch ein bestimmtest Paket ausgelöst. So sollte eine Redirect- oder Destination Unreachable-Nachricht sich bloß auf eine bestimmte Verbindung beziehn. Unglücklicherweise nutzen alte ICMP-Implementierungen diese zusätzliche Information nicht. Wenn solche Nachrichten empfangen werden, wirken sie auf alle Verbindungen zwischen den beteiligten Hosts. Wenn ihr Hostals Antwort auf ein Paket zum Host PING.CO.AT ein Destination Unreachable erhält, weil dieses eine Paket PING.CO.AT nicht erreichen konnte, dann werden alle Verbindungen zu PING.CO.AT abgebrochen. Manche Hacker finden sogar Gefallen daran, durch Mißbrauch von ICMP Verbindungen zu kappen.
Router sollten niemals einer Redirect Message Glauben schenken, da es dadurch einem Angreifer möglich ist, den Verkehr zu sich selbst umzuleiten.
2.1.5 RIP - Routing Information Protocol
RIP ist ein Protokoll zur Steuerung der Wegwahl im Datennetz.
Es ist recht einfach, falsche Nachrichten für RIP in ein Datennetz einzuschleusen. Befindet sich der Angreifer näher am Ziel als das Quellsystem, so kann er den Datenverkehr leicht umlenken. Folgeversionen von RIP stellen, um dem entgegenzuwirken, ein Authentifikationsfeld zur Verfügung.
2.1.6 DNS - Domain Name System
Das DNS ist ein verteiltes Datenbanksystem, welches (leicht merkbare, wir zB PING.CO.AT) Host-Namen in verwendbare IP-Adressen umsetzt und umgekehrt. Im Normalbetrieb senden Hosts UDP-Anfragen an DNS-Server. Dieses entworten entweder mit der richtigen Antwort oder verweisen auf besser informierte Server.
Im DNS wird eine Reihe verschiedener Datensätze gespeichert:
Typ Funktion
A Adresse eines bestimmten Hosts
NS Name-Server. Verweist auf den für den Teilbaum zuständigen Server
SOA Start of authority. Markiert den Anfang eines Teilbaumes, enthält neben Caching und Konfigurationsparametern auch die Adresse der für diese Zone verantwortlichen Person.
MX Mail Exchange. Name des Systems, welches die eingehende Post für das angegebene Ziel annimmt. Bei der Zielangabe können Jokerzeichen, wie etwa *.ATT.COM, verwendet werden, so daß ein einziger MX-Eintrag Post für einen ganzen Teilbaum umlenken kann.
HINFO Information über Betriebssystem und Maschinentyp eines Hosts.
CNAME Alternative Namen für einen Host.
PTR Umsetzung von IP-Adressen in Host-Namen
Der Namesnadreßraum von DNS ist baumförmig. Um den Betrieb zu erleichtern, können genze Teilbäume, sogenannte Zonen, an andere Server delegiert werden. Es werden zwei logisch getrennte Bäume verwendet. Der eine setzt Systemnamen wie etwa PING.CO.AT auf IP-Adressen wie 192.20.225.3 um. Es können weitere Informationen über den Host vorhanden sein, beispielweise HINFO- oder MX-Einträge. Der andere Baum enthält PTR-Datensätze und beantwortet inverse queries, also Anfragen in die Gegenrichtung, bei denen auf eine IP-Adresse mit dem Namen geantwortet wird. Zwischen beiden Bäumen wird keine Konsistenz garantiert.
Dieser Mangel an Konsistenz kann Probleme bereiten. Erlangt ein Hacker Kontrolle über den inversen DNS-Baum, kann er ihn für seine Zwecke mißbrauchen. Enthält der inverse Eintrag mit der Adresse des Angreifersystems den Namen eines Hosts, dem das System vertraut (.rhosts), so wird es einem rlogin-Versuch des Angreifers stattgeben, weil es dem gefälschten Eintrag Glauben schenkt.
Die meisten neueren Systeme sind gegen diesen Angriff immun. Nachdem sie von DNS den mutmaßlichen Host-Namen erhalten haben, prüfen sie im Gegenszug die diesem Namen zugeordneten IP-Adressen. Ist die Quelladresse der Verbindung nicht dabei, platzt der Verbindungsversuch und wird als sicherheitsrelevant protokolliert.
Eine weitere Gefahr liegt in der Eigenschaft vieler Implementierungen von DNS-Resolvern, fehldende Teile eines Namens aus dem eigenen Namen versuchsweise abzuleiten.
Beispielsweise versucht FOO.DEPT.BIG.EDU das Ziel BAR.COM anzusprechen. Der DNS-Resolver wird Teile des eigenen Namens ergänzen, um Benutzern abkürzende Schreibweisen zu erlauben, und erst
. BAR.COM.DEPT.BIG.EDU,
. BAR.COM.BIG.EDU
. BAR.COM.EDU
probieren, ehe er (korrekt) BAR.COM verwendet. Darin liegt die Gefahr: Erzeugt jemand eine Domain COM.EDU, könnte er allen Datenverkehr für .COM abfangen.
|
