6 Netzwerkgeräte
<< | < | = | > | >>
6.1 Einführung
Dieses Kapitel hat zugegebenermassen nicht viel mit der Sicherheit von Windows zu tun. Vielmehr geht es um die Sicherheit eines ganzen Netzwerkes; egal, ob dies nun eher UNIX- oder Windows-basierend ist. Denn Netzwerkgeräte gelten nicht umsonst als die Eckpfeiler eines Unternehmens und Lebensadern dessen Netzwerks. Sie verbinden verschiedene Büroräume im LAN (Local Area Network) und Lokationen als WAN (Wide Area Network) miteinander, um Daten austauschen und im Kollektiv effizient Arbeiten zu können. Angriffe auf Netzwerkgeräte werden in erster Linie zum destruktiven Vorgehen degradiert, obwohl unter Umständen ein kompromittierter Router entscheidend zur Übernahme des gesamten restlichen Netzes beitragen kann.

Ist ein Eindringling erst mal im Besitz eines zentralen Netzwerkgerätes, so kann er die an diesem Punkt vorbeirasenden Informationen nach Belieben auslesen, manipulieren oder umleiten. Passwörter im Klartext oder bestehende Sitzungen werden kompromittiert, um sich Schritt für Schritt in der hierarchischen Gesellschaft der Netzwerknutzer nach oben zu klettern: Bis sich das komplette Netz in seinem Besitz befindet.

In diesem Kapitel gehen wir auf die Vorgehensweise zur Entdeckung und Manipulation von Netzwerkgeräten ein. Es werden verschiedene Scanning-, Footprinting- und Angriffs-Möglichkeiten besprochen, die von Angreifern zum eigenen Vorteil genutzt werden. Natürlich werden wir uns auch den Gegenmassnahmen widmen, die zur Absicherung der Netzwerkinfrastruktur beitragen soll. Und denken Sie daran: Ohne Netzwerk ist so manches Unternehmen in kürzester Zeit dem Tode geweiht!

6.2 Entdeckung
An die Entdeckung von Netzwerkgeräten geht man auf ähnliche Weise wie bei der von Hosts heran: Die Suche nach aktiven Ports und das Abgreifen von Bannern haben wir im Kapitel 2 (Scanning) kennengelernt. Eine additionelle Eigenart, die zeitweilens nur Netzwerkgeräte für sich beanspruchen konnten, ist das Manageing über SNMP (Simple Network Management Protocol). Wie nun Router, Hubs und Switches erkannt werden und was es mit SNMP aufsich hat, besprechen wir in diesem Kapitel.

6.2.1 Tracerouting

Um dieses Auskundschaften tätigen zu können, bemächtigen wir uns des Programmstraceroute, das zum Lieferumfang eines
jeden UNIX gehört. Auch unter Windows (alle netzwerkfähigen Versionen) wird dieses Analyse-Tool gern genutzt, trägt dort jedoch aus Gründen der Kompatibelität den Namen tracert.exe.

Traceroute ist ein Diagnosetool für Netzwerke, das ursprünglich von Van Jacobson geschrieben wurde, mit dem die Route eines IP-Pakets zu einem Host erkannt werden kann. Traceroute verwendet die Time-To-Live-Option (TTL) eines IP-Pakets, um die ICMP-Nachricht TIME_EXCEEDED von den jeweiligen Zwischenstationen, meistens sind dies Router, auszulesen. Jeder Router, der das Paket weiterleitet, muss den Zähler des TTL-Felds dekrementieren, wodurch das besagte Feld zum Hop-Zähler degeneriert wird. Neben dem Erkennen der Zeitdauer des Erreichens des Ziels kann auch die Route und indirekt sogar die eingesetzte Netzwerktopologie erkannt werden:
 
MS-DOS-Eingabeaufforderung
C:\WINDOWS>tracert ubs.ch

Route-Verfolgung zu ubs.ch [193.134.254.228]

Über maximal 30 Abschnitte:

  1     1 ms     0 ms     1 ms  gateway.computec.ch [192.168.0.1]
  2    74 ms    14 ms    25 ms  gw.hispeed.ch [62.2.65.254]
  3   290 ms   239 ms   248 ms  rtr1.cablecom.net [62.2.1.1]
  4   285 ms   281 ms   185 ms  fw.ubs.ch [193.134.254.1]
  5   450 ms   495 ms   442 ms  rtr.ubs.ch [193.134.254.11]
  6   288 ms   250 ms   248 ms  ubs.ch [193.134.254.228]

Route-Verfolgung beendet.

C:\WINDOWS>_

Ein Traceroute zu ubs.ch, um Firewall-Systeme ausfindig zu machen: Der Hop 4 scheint ein Firewall-Element zu sein.

Beim zweitletzten Hop können wir uns ziemlich sicher sein, dass es sich um einen Router handelt (Die DNS-Auflösung von 193.134.254.11 zu rtr lässt sowieso das Wort Router vermuten.). Normalerweise ist das erste Element nach einem Firewall-System ein Router. Hop 4 lässt aufgrund des NS-Lookups von 193.134.254.1 in fw.ubs.ch eine Firewall vermuten.

Sobald mehrere Routen zu existierenden Hosts im besagten Netzwerk getätigt wurden, kann man sich an die Auswertung und das Erstellen des daraus resultierende Netzwerkdiagramms machen, das die Architektur der jeweiligen Gateways und Hosts darstellt. Eine solche Skizze wird als Zugriffspfad-Diagramm bezeichnet. Im Gegensatz zur UNIX-Version von traceroute werden bei Windows NT standartmässig ICMP-Echo-Request-Pakete übertragen. Aus diesem Grund können die Resultate unter Umständen stark voneinander abweichen.

6.2.2 Tracerouting: Gegenmassnahme
Bestmöglich sollten abgelaufene TTL-Pakete durch ein zusätzliches Firewall-Element oder den Router direkt geblockt oder verworfen werden. Bei Routern von Cisco wird diese Filterung anhand der folgenden ACL bestimmt:

access-list 101 deny icmp any any 11 0

Diese etwas radikale Methode kann die Fehlersuche durch einen Administrator in gewissen Fällen negativ beeinflussen. So bevorzuge ich die folgenden Zeilen, die ICMP-Pakete von vertrauenswürdigen Netzwerken zulässt und alle anderen sperrt:

access-list 101 permit icmp any 192.168.0.0 0.255.255.255 11 0
access-list 101 deny ip any any log

6.2.3 Portscanning
Unter der Verwendung von nmap können wir feststellen, welche Ports unser Router (z.B. 192.168.0.1) verwendet. Auf der Suche nach Cisco-Routern sollten wir Ausschau nach den offenen TCP-Ports 1 bis 25, 80, 512 bis 515, 2001, 4001, 6001 und 9001 halten:
 
Hersteller Hardware Ressourcen TCP-Ports UDP-Ports
Ascend / Lucent Router http://www.lucent.com/ins/products/index.html 23 (Telnet) 7 (Echo) 
9 (Discard) 
161 (SNMP)
162 (SNMP-Trap)
514 (Shell)
520 (Route)
BayNetworks Router http://www.nortelnetworks.com/products/routers/ 21 (FTP)
23 (Telnet)
7 (Echo) 
9 (Discard) 
67 (BOOTP-Server
68 (BOOPP-Client
69 (TFTP) 
161 (SNMP)
520 (Route)
Cisco Router http://www.cisco.com/warp/public/44/jump/routers.shtml 21 (FTP)
23 (Telnet)
79 (Finger) 
80 (HTTP)
512 (EXEC) 
513 (Login) 
514 (Shell)
1193 (Cisco SNMP)
1999 (Cisco ident) 
2001 
4001 
6001 
9001 (XRemote service)
0 (TCPMUX) 
49 (Domain)
67 (BOOTP-Server
69 (TFTP) 
123 (NTP) 
161 (SNMP)
Cisco Switches http://www.cisco.com/warp/public/44/jump/switches.shtml 23 (Telnet)
7161
0 (TCPMUX) 
123 (NTP) 
161 (SNMP)
Liste der standartmässig offenen Ports bei bekannten Netzwerkgeräten.

Erkennung des Betriebssystems

Wir vermuten anhand der offenen Ports, dass sich hinter dem vorangegangenen Portscan ein Cisco-Router befindet. In einem weiteren Schritt versuchen wir diese hypothetische Aussage mittels der Identifizierung des Betriebssystems durch eine Analyse der TCP-Sequenzen dank nmap in Stein zu meisseln. Da der TCP-Port 13 von uns angesprochen werden kann, können wir bei nmap die Option "-O" verwenden, um das Betriebssystem des Netzwerkgeräts in Erfahrung zu bringen:

Man sollte eine solche Identifizierung nur auf einen Port loslassen, da viele Betriebssysteme allergisch auf diese Scan-Art, aufgrund nicht immer ganz RFC-konformer Pakete, reagieren und sogar abstürzen können: Das wollen wir ja nicht, weil uns dieser destruktive Nebeneffekt im ersten Augenblick nicht wirklich weiterbringen würde.

Erkennung des Betriebssystems: Gegenmassnahme

Die Techniken zur Unterbindung des Erkennens des Betriebssystems haben wir schon eingehend in Kapitel 2 (Scanning) besprochen:

Deaktivieren Sie stets alle unbenötigten Dienste, was nicht nur im Umfang des Informationsschnüffels Positives zur Systemsicherheit beiträgt.

Falls die Möglichkeit besteht, empfiehlt sich ein administrativer manipulativer Eingriff in die Banner-Ausgabe. Sehr schön können so Systeme und Dienste in ihrer Herkunft und Weise vorgetäuscht werden. Es ist zudem ziemlich amüsant und interessant zuzusehen, wie ein Angreifer einen angeblich ihm bekannten Dienst attackiert...

Mit Eingriffen in die Handhabung des Betriebssystems bei Verbindungs-Anforderungen und direkt beim Protokollstapel könnte eine komplett andere Plattform vorgetäuscht werden. Diese Aktion ist jedoch mit dem bitteren Beigeschmack eines möglichen Performance- und Stabilitäts-Verlusts des Betriebssystems in Angriff zu nehmen.

Ausserdem sollte bestensfalls die unerlaubte Einsicht solcher Informationen durch Firewall-Systeme verhindert werden: NAT (Network Adress Translation), IP-Masquerading und eine solide ACL (Access Control List) machen sehr viel her. Diese Lösung ist leider nicht immer realisierbar und bedarf einiges an technischem und finanziellem Aufwand.

6.2.2 SNMP
Das Simple Network Management Protocol wurde mit der Idee entwickelt, die Verwaltung von Netzwerkgeräten durch den Systemverwalter zu vereinfachen. Die erste, in RFC 1157 (A Simple Network Management Protocol (SNMP)) definierte Version des besagten Protokolls war aber von Anfang an mit Sicherheitsproblemen behaftet. Ursprünglich war nur eine schwache Passwort-Beglaubigung, auch unter "Community Name" bekannt, vorgesehen.

Schnell reagierte man mit einer zweiten Version von SNMP, die in RFC 1446 (Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)) spezifiziert wird. SNMPv2 benutzt den kryptographischen Algorithmus MD5 (Message Digest 5) für die Authentifizierung der zu übertragenden Daten zwischen dem SNMP-Server und -Agenten. Die Implementierung von MD5 überwacht die Integrität der Kommunikation und die der involvierten Parteien. Zusätzlich konnte durch das neue Feature auch der Dialog chiffriert werden.

Der momentane Standart schlägt sich jedoch in einer dritten Version nieder, deren Bestimmungen in RFC 2570 (Introduction to Version 3 of the Internet-standard Network Management Framework) publiziert wurden. SNMPv3 bietet einige nette zusätzliche Features, die die Sicherheitsproblematik zu lindern versuchen. Sie werden jedoch feststellen, dass die meisten sich im Einsatz befindlichen Geräte noch immer mit SNMPv1 oder höchstens SNMPv2 agieren können.

Bisher konnte noch keine SNMP-Version dafür sorgen, dass ein Hersteller keine Standart-Passwörter einrichten konnte oder sich die Netzwerk-Verwalter leicht zu erratender Passwörter bedienen. Den Status eines SNMP-Benutzers kann man in zwei Kategorien unterteilen: Lesen und Lesen/Schreiben. Der erste Community-Typ ist für die passive Einsicht der Konfigurationen und anderweitigen Daten (z.B. Log-Dateien) vorgesehen. Der erweiterte Zugriff "Lesen/Schreiben" erlaubt einem Administrator oder Angreifer den aktiven manipulativen Eingriff in die Einstellungen und Auswertungen des Geräts. Sehr schnell lassen sich so Routen ändern oder Log-Einträge löschen.

6.2.3 SNMP: Gegenmassnahmen
Verzichten Sie auf SNMP, wo es nur geht. In grossen Netzwerken kann sich das Deaktivieren dieses Features negativ auf die Auslastung des Netzwerk-Personals auswirken. Versuchen Sie in diesem Fall wenigstens Geräte zu ergattern und nutzen, die mindestens mit SNMPv2 funktionieren. Zusätzlich sollten starke Passwörter für die jeweiligen Community-Typen gewählt werden.
6.3 Hintertüren
Viele Hersteller von passwortgeschützter Soft- und Hardware richten geheime Hintertüren ein, die bei einem Notfall (z.B. hat jemand das Passwort zur Administration vergessen) den darum wissenden Personen Einlass gewähren können. Solche Standartkonten werden nicht publiziert um den Missbrauch nicht offensichtlich zu machen. Schneller als man denkt kursieren jedoch im Untergrund neu bekanntgewordene Default-Logins, die für einen Angreifer viel Wert haben dürfen.

6.3.1 Standartkonten

Eine immerwieder angetroffene und nicht nur deshalb gern genutzte Schwachstelle ist der Standartbenutzername mit dem dazugehörigen Passwort. Eine stets aktuelle Liste mit den bekannten Standartkonten findet sich online unter http://security.nerdnet.com/.
6.3.2 3com-Switch Standartkonten: Gegenmassnahmen
Die Passwörter können mit der Eingabe von "system password" geändert werden.

Mehr Informationen zu dieser Art Sicherheitsprobleme bei 3com-Switches findet sich in der Publikation von Security Bugware.

6.3.3 Baynetwork-Router Standartkonten: Gegenmassnahmen 6.3.2 Cisco-Router Standartkonten: Gegenmassnahmen
Die Standartkonten sollten durch eine Modifikation in den unproblematischen Bereich gedrängt werden können.

Leider werden keine starken Verschlüsselungs-Möglichkeiten für vty-Passwörter geboten, so dass ein Cracker ein gewonnenes Passwort ohne viel Aufwand knacken kann. Trotzdem sollten die Cisco-Geräte durch das Aktivieren von "service password-encryption" mehr geschützt werden. Durch das Ausführen von "enable password 7 <Passwort>" wird das vty-Passwort mit dem schwachen Cisco-Algorithmus chiffriert: Das ist immerhin besser als ein Passwort im Klartext zu lagern.

6.4 SNMP-Angriffe
6.4.1 SNMP-Informationen abfangen
Ein vollwertiger Paket-Analyzer kann sniffenderweise in einem Netzwerksegment zum Abgreifen des SNMP-Datenverkehrs genutzt werden. tcpdump für UNIX eigenet sich für dieses Vorhaben weniger, da lediglich die Paket-Header angezeigt werden. Ein bemerkenswertes Tool aus der UNIX-Ecke ist snmpsniff, dass allen Komfort für das Schnüffeln in SNMP-Dialogen bietet:
 
Welcome to SuSE Linux 7.0 (i386) - Kernel 2.2.16

prometheus login: root
Password: 
Last login: Thu Jan 18 13:14:59 on tty1
Have a lot of phun...
root@prometheus:~ > ./snmpsniff.sh
snmpsniff: listening on eth0
(11:24:07) 192.168.0.13(passwd)-> 192.168.0.7 (ReqID:1537424098) GET: <.iso.org.dod.internet.mgmt.mib-2.system.1.0> (NULL) = NULL
(11:24:08) 192.168.0.7(passwd)-> 192.168.0.13 (ReqID:1537424098) RESPONSE (Err:0): <.iso.org.dod.internet.mgmt.mib-2.syst.1.0> (Octet String) = OCTET STRING- (ascii):     Cisco Internetworking Operating System Software ..IOS (tm) 3500 Software (IGS-I-L), Version 11.0(19), RELEASE SOFTWARE (fc2)..Copyright (c) 1986-1998 by cisco Systems, Inc...Compiled Fri 16-Jan-98 13:07 by mruef

root@prometheus:~ > _

snmpsniff im Einsatz auf einem SuSE Linux 7.0

Wir erkennen im ersten Schritt des Dialogs die Passwortübergabe (passwd) des Rechners 192.168.0.13 an den Cisco-Router mit der IP-Adresse 192.168.0.7. Die zweite Ausgabezeile demonstriert die Antwort durch das Cisco-Gerät. Jetzt können wir uns ohne Probleme an die Kompromittierung des besagten Netzabschnitts durch eine Umkonfigurierung des Routers machen.

6.4.2 SNMP-Befehle einspeisen
Ist der Angreifer durch vorangegangene Aktionen in den Besitz eines Schreibrechts auf einem Router gekommen, so kann er mittels des "set"-Befehls neue statische Routen definieren, um zum Beispiel einen geschickt platzierten Sniffer mit Daten beschenken zu können. Wie solche Kommandos genutzt werden hängt von der eingesetzten Hard- und Software ab. Detaillierte Informationen sind der dazugehörigen Dokumentation zu entnehmen.
6.5 Erweiterte Angriffe
6.5.1 ARP-Angriffe
LAN-Karten bedienen sich einer hardwaremässig definierten MAC-Adresse, die für die Aussendung und den Empfang von Datagrammen über das Netzwerk unerlässlich ist. Sie können nur auf Datagramme antworten, die im Empfänger-Feld eine Rundsende-Adresse, eine bekannte Verteilsende-Adresse oder eine auf die betreffende LAN-Karte hinweisende Individual-Adresse aufweisen. Das Internet Protocol verwendet IP-Adressen, die während der Installation des Netzwerks bzw. dem Aufsetzen des an das LAN anzubindende Systems vom Administrator definiert wird. Eine IP-Adresse ist dem Protokollstapel der Vermittlungsschicht zugeordnet und von der individuellen MAC-Adresse unabhängig. Jede Kommunikation mittels TCP/IP wird durch die IP-Adresse eingeleitet, wodurch für den Aufbau des Dialogs die MAC-Adresse als sekundär zurückgestuft wird. End-zu-End-Kommunikationen bedienen sich also der IP-Adresse, wohingegen bei den dazwischen liegenden Knotenpunkten (Hops) die MAC-Adresse genutzt wird.

In den ersten TCP/IP-fähigen Rechnern wurde eine manuell erstellte Tabelle verwendet, die die Zuordnung zwischen MAC- und IP-Adresse indirekt automatisieren sollte. In den meisten rundsendefähigen Netzen werden davon losgelöst zusätzlich oder ersetzend Routing-Informationen komplett automatisch mittels dem ARP (Adress Resolution Protocol) ausgetauscht, welches in RFC 826 (An Ethernet Address Resolution Protocol) definiert wird. Jeder Knoten verwaltet dabei dynamisch den sogenannten ARP-Cache mit den relationalen IP-/MAC-Einträgen. Wenn das Internet Protokoll die Anforderung erhält ein Datagramm an eine andere IP-Adresse zu senden, sucht es zuerst im ARP-Cache nach der korrespondierenden MAC-Adresse, die von der Datensicherungsschicht bei der Übertragung des Pakets Verwendung finden soll. Falls kein Eintrag vorhanden ist, wird vom Initiator mit der Hilfe von ARP die MAC-Adresse der fraglichen IP-Adresse zu ermitteln versucht. In der Hoffnung diese Frage wenigstens temporär aus der Welt zu schaffen, sendet ARP ein Datagramm inklusive der zu erfragenden IP-Adresse eine sogenannte ARP-Anforderung an alle LAN-Karten mittels der bekannten MAC-Broadcast-Adresse (0xFFFF_FFFF_FFFF). ARP setzt in dieser verhältnismässig globalen Anforderung seinen eigenen Ethernet-Typ 0x08086 ein, damit der Schrei von allen vermeindlich betroffenen Knotenpunkten wahrgenommen wird. Dieses Rundschreiben wird von allen aktiven Maschinen im Netzwerk erkannt und insofern verarbeitet, dass wenn die eigene IP-Adresse in der ARP-Anforderung erkannt wird, das betroffene System die mindestens lokal statisch vermerkte MAC-Adresse retourniert. Diese eingehende Antwort wird im lokalen ARP-Cache vermerkt und steht, solange der Zwischenspeicher nicht aufgrund potentieller Überfüllung überschrieben wird, für eine weitere und vor allem schnellere bzw. effizientere Nutzung bereit. Falls innerhalb eines definierten Timeouts im Sekundenbereich keine Antwort auf die Broadcast-Anfrage eingeht, wird die Anforderung erneut gestellt. Damit jedoch nicht stets das gesamte Netz belästig werden muss, wird aus Gründen der Effizienz eine Kopie der ARP-Anfrage beim Knoten, der auf die ARP-Nachricht antwortet, die Zuordnung von IP- und MAC-Adresse, der geantwortet wurde, zwischengespeichert. Bei der nachfolgenden Anforderung ist es daher auch nicht mehr nötig den ARP-Dialog in umgekehrter Richtung walten zu lassen, da die relevanten Daten beim Zielsystem bereits bekannt sind.

ARP-Datagramme werden von Routern nicht weitergeleitet, da sie in der IP-Schicht operieren und auf MAC-Broadcasts grundsätzlich nicht reagieren können und dürfen. Router stellen daher verwertbare Puffer zwischen einzelnen Rundsende-Subnetzen dar. Mit ihrer Hilfe kann überflüssiger Traffic im gesamten Netzwerk eingedämmt und auf effektiv betroffene Segmente minimiert werden.

ARP-Stürme

Der Denial of Service-Angriff mittels ARP-Sturm hat die Überlastung einer Netzwerkkomponente oder eines Netz(abschnitt)es zur Folge, was unter Umständen einen weiteren weniger destruktiven Angriff erst ermöglicht (z.B. IP-Spoofing). Die Extremsituation tritt ein, wenn ARP-Broadcasts eine non-existente IP-Adresse in Erfahrung bringen versuchen. Alle an das Netzwerk angeschlossenen Gateways beginnen alsdann mit dem Weiterleiten der Anfrage an die Nachbarnetze. Ganz extrem wird dieser Angriff, wenn nach dem ersten Broadcast-Sturm synthetische ARP-Rückantworten der nicht existierenden Adresse versendet werden, die wiederum von den Gateways per Broadcast zur finalen Verstopfung des Netzes weiterverbreitet werden. Solche Broadcast-Stürme belegen rasch einen Grossteil der Netzwerkkapazität und lassen die Performance in den Keller sinken. Wichtig ist in sensiblen Umgebungen im Vorfeld das sogenannte Media-Speed-Verhalten durch experimentell simulierte Extremsituationen in Erfahrung zu bringen. HAVOC für UNIX/Linux ist ein beliebtes Tool zum Erzwingen von ARP-Stürmen.

ARP-Fehlimplementierung

Auch auf Fehlimplementierungen der ARP-Funktionalität können Denial of Service-Attacken abzielen. Diese Angriffs-Form wird im Thread von Joel Jacobson in Bugtraq erstmals vorgestellt. Ähnliche Diskussionen finden sich in den beiden Threads von Andrew Lancashire und Lisa Napier über DoS-Attacken auf Cisco-Systeme, und von Scott Blake über Cabletron-Router, durch das Überfluten der ARP-Tabelle.

ARP-Spoofing

Ein Angreifer versucht beim ARP-Spoofing seine Hardware-Adresse zu behalten, aber die IP-Adresse eines vertrauenswürdigen Hosts anzunehmen. Dazu manipuliert der Bösewicht remote durch falsche Mapping-Informationen den Cache seines Opfers. Verläuft seine Attacke erfolgreich, werden von da an alle Pakete vom Ziel an die Hardware-Adresse des Angreifers geleitet. Das Opfer glaubt nun faktisch daran, dass der Rechner des Angreifers der vertrauenswürdige Host ist. Auf Rootshell publizierte Yuri Volobuev einen interessanten Artikel, der auf solche Redirect-Attacken mittels ARP und ICMP eingeht.

ARP-Spoofing unterliegt jedoch einigen Einschränkungen, die es für viele Angreifer nicht gerade attraktiv macht: Zum einen kann intelligente Hardware solche Attacken im Sande verlaufen lassen, zum anderen verlieren unter Umständen Cache-Einträge von ARP schnell ihre Gültigkeit. Der Angreifer muss daher stets die ARP-Tabelle des Opfers neu überreden, was an der Effizienz des Angriffs zu kratzen vermag. Ausserdem ist ein in den Promiscous-Mode geschaltetes Interface in einem Ethernet-System genauso effizient für das unerlaubte Auslesen von Informationen.

Es existieren diverse Programme - wie zum Beispiel die Linux-Utilities ARP-Fun und ARPMITM -, die solche Angriffe auf einfachste Weise ermöglichen. Für ARPTool, ein weiteres Stück Software dieser Sparte, existiert sogar ein grafisches Frontend mit zusätzlichen Features (z.B. Automatisiertes MAC-Sniffing) namens Switch Fucker. Ein witziges Zusatzfeature bietet das Paket mit den BSD-Utilities conflict-DoS.c und conflictd.c von Noupe: Durch gespoofte ARP-Pakete können WinPopUp-Nachrichten auf Windows-Hosts erzeugt werden. Einen Schritt weiter geht da das simple Smit von Paul Starzetz, welches in ungeswitchten und geswitchten Netzwerken ARP-Hijacking ermöglicht.

Sich ARP-Spoofing bedienenden Angreifern den Gar aus zu machen, bedarf das statische Festlegen der ARP-Tabelle. Dies kann jedoch unter umständen sehr zeitaufwendig und nervenaufreibend sein, wodurch dieser Methode höchstens den Titel Notlösung zugesprochen werden kann. Eine zusätzliche Massnahme oder mindestens gleichwertige Alternative stellt das Utility ARPWatch von Craig Leres dar, welches nach Veränderungen der IP-/Ethernet-Mappings Ausschau hält. Werden Änderungen bemerkt, findet eine Alarmierung per E-Mail statt. Zudem werden die Manipulationen für eine spätere Analyse protokolliert.

6.5.2 ICMP-Angriffe
Denial of Service durch ICMP

ICMP kann für eine sehr generelle DoS-Attacke genutzt werden, welche unter anderem mit den Linux-Programmen pong.c, erect.c und icmp.c realisiert wurden. Die besagten Quelltexte verursachen in ihren kompilierten Formen eine Paketflut, die in einem ICMP-Sturm endet. Der Angreifer sendet ICMP-Anfragen an das Ziel und benutzt eine gefälschte Absender-Adresse für seine Fracht. Um die Wirkung zu verstärken wird vorzugsweise die IP-Adresse des Ziels gewählt. Die korrupte Anfrage wird dann per Broadcast an mehrere Hosts im Netzwerk des Zielrechners gesendet. Diese quittieren die Antwort und überfluten so das Zielsystem. Je grösser das betroffene Netzwerk ist, desto verheerender für den Rechner des Opfers. Weitere Informationen zu dieser Angriffsform finden sich in RFC 2267 (Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing). Einer Verhinderung einer solchen DoS-Attacke kann versucht nachzukommen, indem Router keine Broadcast-Pakete an fremde Ziele weiterleiten.

Ein zusätzliches Problem besteht im Missbrauch der unterschiedlichen ICMP-Datentypen. Folgend nun die Auflistung der potentiellen Gefahren durch Denial of Service-Attacken:
 

  • Destination Unreachable (3): Diese Meldung kann von einem Angreifer missbraucht werden, alle Verbindungen zwischen beteiligten Rechnersystemen aprupt zu beenden. Geschickt eingesetzt ähnelt dieser Angriff einer DoS-Attacke.
  • Source Quench (4): Wird ein versendender Rechner in einem Netzwerk mit solchen Nachrichten überschwemmt, so verringert er zusehends seine Aussenderate. Wiederum kann das Verschicken dieses Typs in einer DoS-Attacke gipfeln.
ICMP-Redirects

Es können mit dem ICMP-Nachrichten Typ 5 sogenannte Redirects erzwungen werden, um unerwünschte Routen zu konfigurieren und die Daten unterwegs abzuhören oder zu manipulieren.

6.5.3 RIP-Spoofing
RIP-Spoofing ist mit unerlaubten ICMP-Redirects vergleichbar: Sind die Router eines Netzwerks identifiziert woren, kann ein Angreifer RIP-Pakete fälschen, um den Router durch Vorspiegelung falscher Tatsachen zur Übermittlung des Datenstromes über ein nicht autorisiertes Netzwerk zu überreden.

RIPv1 besitzt keine Sicherheitsmechanismen zur Beglaubigung von vertrauenswürdigen Informationen, wodurch Angriffe auf von diesem Protokoll-Typ Gebrauch machende Netzwerkgeräte besonders einfach wird. RIPv2 und OSPF (Open Shortest Path First) besitzen ein anständiges Passwort-System, das Spoofing-Attacken einzuschränken vermag.

6.5.4 Erweiterte Angriffe: Gegenmassnahmen
Auf Protokolle sollte bestmöglich verzichtet werden, wo dies erreicht werden kann. Optional können auch unerwünschte Datenpakete durch das Element selber oder im Vorfeld gefiltert werden, um unerlaubte Aus- und Einlesungen vorbeugend entgegenzuwirken.
6.6 Zusammenfassung
Im ersten Teil dieses Kapitels haben wir uns der Techniken zur Entdeckung und Auskundschaftung von Netzwerkgeräten genähert. Zudem haben wir das Gefahrenpotential von Standartkonten und SNMP besprochen, um uns schlussendlich über protokolltechnische Angriffe einen Überblick zu verschaffen.
 
<< | < | = | > | >>