Eine Bewertung von Angriffsszenarien auf IT-Strukturen und Gegenmaßnahmen

Inhaltsverzeichnis

1 Einleitung
1.1 Aktuelle Situation und Entwicklung

2 Grundlagen
2.1 OSI-Schichtenmodell
2.2 Internet-Schichtenmodell
2.3 Internet Protocol Version 4
2.4 Internet Control Message Protocol
2.5 User Datagram Protocol
2.6 Transmission Control Protocol
2.7 Internet Protocol Version 6

3 Angriffe
3.1 Sniffer
3.1.1 Anwendungsgebiete von Sniffern
3.1.2 Funktionsweise von Sniffern
3.1.3 Gefahren durch Sniffer
3.1.4 Beispielprogramme
3.2 Scanner
3.2.1 Legalität von Portscans
3.2.2 Scan-Verfahren
3.2.3 Beispielprogramme
3.3 Denial-of-Service-Angriffe
3.3.1 Einige DoS-Attacken
3.3.2 Distributed Denial of Service - DDoS
3.3.3 Bekannte DDoS-Angriffswerkzeuge
3.4 Malware – Viren, Würmer und Trojaner
3.4.1 Viren
3.4.2 Trojanische Pferde
3.4.3 Würmer
3.4.4 Hoaxes
3.4.5 Beispiele von Malware

4 Gegenmassnahmen
4.1 Schutz vor Sniffern
4.2 Schutz vor Scannern
4.3 Schutz vor DoS und DDoS
4.4 Schutz vor Malware
4.5 Kryptographie
4.5.1 Ziele
4.5.2 Klassische Verfahren
4.5.3 Verschlüsselungsschema
4.5.4 Symmetrische Verschlüsselungsalgorithmen
4.5.5 Asymmetrische Verschlüsselungsalgorithmen
4.5.6 Kryptographie in der Praxis
4.6 Firewall
4.6.1 Desktop-Firewall vs. Netzwerk-Firewall
4.6.2 Firewall Funktionen
4.6.3 Kerio Personal Firewall
4.7 Intrusion Detection Systeme
4.7.1 Was ist ein IDS ?
4.7.2 Was ist eine Intrusion ?
4.7.3 Hostbasierte IDS
4.7.4 Netzwerkbasierte IDS
4.7.5 Snort
4.7.6 Honeypots

5 Schlusswort

Literaturliste

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

1.1 Aktuelle Situation und Entwicklung

Das Internet ist in unserer heutigen Zeit in sämtlichen Lebensbereichen, egal ob in der Wirtschaft oder im privaten Bereich, fest verankert und nicht mehr wegzudenken. Daten von Unternehmen, Regierungsbehörden, Bildungs- und Forschungseinrichtungen werden über dieses Netz gesendet und ausgetauscht.

Dabei präsentiert sich die derzeitige Situation in etwa wie folgt:

Das Internet wächst seit Jahren mit einer rasanten Geschwindigkeit. Waren im Januar 1993 lediglich ca. 1,3 Millionen Hosts an das Internet angeschlossen, sind es im Januar 2003 fast 172 Millionen. Das Internet Software Consortium^[1] ermittelt in regelmässigen Abständen die ungefähre Anzahl der mit dem Internet verbundenen Computersysteme. Die Ergebnisse der letzten Jahre sind in nachfolgender Tabelle aufglistet^[2]:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Internetwachstum

Trotz der Schwäche des IT-Gewerbes und der allgemeinen Weltwirtschaft in den letzten Jahren scheint das Wachstum anzuhalten. Auch die Zahl der Computersysteme scheint bald wieder zu wachsen. Die Analysten von IDC^[3] rechnen in Kürze mit einer Erholung des IT-Marktes^[4].

Die Softwareindustrie kann mit dieser Geschwindigkeit Schritt halten. Ein ähnliches Wachstum lässt sich nämlich bei der Softwareentwicklung beobachten. Windows 3.11 wurde auf zehn 1,44MByte-Disketten ausgeliefert. Ein modernes Windows XP benötigt in der Home-Edition mindestens ein Gigabyte an Festplattenspeicherplatz.

Mit der zunehmenden Grösse der Programme nimmt auch die Komplexität des Quellcodes zu. Er wird unübersichtlich, es schleichen sich Fehler ein. Diese werden aufgrund der Masse an Codezeilen leicht übersehen. Damit steigt die Zahl an Sicherheitslücken in Betriebssystemen, Programmen und Protokollen.

Symantec veröffentlichte eine Studie über die Sicherheit im Internet. In dem „Internet Security Threat Report Volume III“ werden die Angriffstrends der zweiten Jahreshälfte 2002 untersucht. Das Fazit: Die Anzahl der entdeckten Schwachstellen hat zugenommen, während die Anzahl der Angriffe zurückgeht^[5]. Diese Angaben sind mit Vorsicht zu geniessen. Es muss davon ausgegangen werden, dass auch die Zahl der Angriffe am Steigen ist. Die offizielle Anzahl wird aus offiziell gemeldeten Fällen gebildet. Die Dunkelziffer dürfte aber weit über diesen Zahlen liegen.

Sicherheitslücken sind weit weniger bedrohlich, wenn Softwareupdates schnell veröffentlicht werden. Doch nicht alle Hersteller von Softwareprodukten verhalten sich hier vorbildlich^[6]. Manchmal sind selbst die eigenen Produkte nicht auf dem neuesten Stand der Sicherheit^[7].

Sicherheitslücken sind ein grosses Problem, doch der Computerbenutzer ist durch sein grob fahrlässiges Verhalten für Schäden am System häufig mitverantwortlich. In einer Studie von „Pew Internet and American Life Project“ z.B. wurden Internet-Surfer zu ihrer Ansicht zum Datenschutz im Internet befragt. Das Ergebnis: 86 Prozent der Befragten forderten, dass ihre persönlichen Daten nur mit Ihrer Zustimmung verwendet werden dürfen, aber lediglich 24 Prozent vermeiden persönliche Angaben und nur 9 Prozent verwenden Verschlüsselungssoftware zum Schutz ihrer Emails^[8].

Diese Diplomarbeit soll gebräuchliche Angriffsformen auf Computersysteme vorstellen und Wege aufzeigen, wie man sich schützen kann. Zuerst sollen häufige Angriffstechniken vorgestellt und beschrieben werden. Im zweiten Teil der Arbeit sollen dann Abwehrmassnahmen besprochen werden. Begonnen wird mit Massnahmen gegen die im ersten Teil vorgestellten Angriffe, denen sich allgemeine Schutzmassnahmen anschliessen.

2 Grundlagen

2.1 OSI-Schichtenmodell

Das OSI-Schichtenmodell wurde 1978 von der International Organization for Standardization (ISO) entworfen und im Jahre 1984 nochmals verbessert. OSI steht für Open Systems Interconnection.

Das ISO-/OSI-Schichtenmodell beschreibt den theoretischen Aufbau eines Netzwerks. Es bildet den theoretischen Rahmen für sämtliche Abläufe innerhalb des Netzes. Das Modell ist allgemein gestaltet und geht nicht auf bestimmte, existierende Protokolle oder Hard- und Software ein. Es beschreibt lediglich wie die Kommunikation zwischen den verschiedenen Partnern abläuft. Ob es sich um eine einfache Modemverbindung oder ein schnelles Gigabit-Netzwerk handelt spielt keine Rolle.

Das OSI-Modell besteht aus sieben Schichten. Jeder Schicht ist ein bestimmtes Protokoll zugeordnet, welches Dienste und Funktionen für den Datenaustausch bereitstellen muss.

Dabei ist zu beachten, das eine Schicht nicht frei auf andere Schichten zugreifen kann. Der Zugriff bleibt auf die unmittelbaren Nachbarn eingeschränkt, so kann z.B. die Transportschicht (4) nur auf die Netzwerkschicht (3) und die Kommunikationssteuerschicht (5) zugreifen. Der Zugriff auf die anderen Schichten
(1, 2, 6 und 7) bleibt verwehrt. Die Kommunikation erfolgt über klar definierte Schnittstellen. Die Abstraktion nimmt nach oben immer weiter zu. Das Modell beginnt in Schicht 1 in der Hardware mit dem eigentlichen Übertragungsmedium und endet in Schicht 7 mit der Anwendungssoftware.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Das ISO-/OSI-Schichtenmodell

Es folgt eine Beschreibung der einzelnen Schichten^[9]:

Anwendungsschicht – Application Layer (7)

Sie stellt die Spitze des Modells dar. Die Anwendungsschicht ist die Schnittstelle zwischen Anwendung, Betriebssystem und Netzwerk. Hier sind Programme, wie der Browser oder der Email-Client angesiedelt. Aber auch die Windows-Netzwerkumgebung hat hier ihren Platz. Hier laufen die übergeordneten Protokolle, wie z.B. das File Transfer Protocol (FTP), das Post Office Protocol (POP) oder das Hypertext Transfer Protocol (HTTP).

Darstellungsschicht Presentation Layer (6)

Hier wird sichergestellt, dass beide Partner in Bezug auf den Zeichensatz dieselbe Sprache sprechen (verschiedene Datenformate sollen rechnerunabhängig darstellbar sein). Auf PC-Systemen ist das in der Regel der ASCII (American Code for Information Interchange). Auf grösseren Servern (Mainframes) von IBM ist es der Extended Binary Coded Decimal Interchange Code (EBCDIC). Dabei werden gleiche Zeichen mit unterschiedlichen Zahlen dargestellt. Unter ASCII lautet der Wert für den Buchstaben „a“ beispielsweise 97, während bei EBCDIC ein anderer Wert, nämlich 129, ist. Die Darstellungsschicht überprüft und korrigiert gegebenenfalls diese Parameter.

Kommunikationssteuerschicht (Sitzungsschicht) – Session Layer (5)

In dieser Schicht wird die eigentliche Verbindung zwischen den Kommunikationspartnern initiiert. Ausserdem agiert sie als Aufsicht, als Schiedsrichter zwischen den Partnern. Sie gewährt der einen oder anderen Station die Sende- oder Empfangsrechte. Hier setzen Protokolle wie das NetBIOS Extended User Interface (NetBEUI) auf.

Transportschicht - Transport Layer (4)

Der Name dieser Schicht ist etwas unglücklich gewählt. Der eigentliche Transport findet nämlich weiter unten im Modell statt. Aber die Transportschicht stellt Funktionen und Ressourcen für die Datenübertragung bereit. Beispielsweise werden hier Datenpakete fragmentiert, um sie über Netzwerkgrenzen hinweg problemlos transportieren zu können. Die Transportschicht ist der Übergang der hardwarenahen Schichten 1 bis 3 und den anwendungsbezogenen Schichten 5 bis 7. Hier ansässige Protokolle sind das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP).

Netzwerkschicht (3)

Diese Schicht ist verantwortlich für die Adressierung und effiziente Übertragung der einzelnen Datenpakete. Sie legt z.B. den effektivsten Weg zum Senden einer Nachricht fest. Notwendige Parameter für die Datenübertragung werden hier festgelegt, zum Beispiel die Maximum Transmission Unit (MTU), welche die maximale Rahmengrösse der Datenpakete regelt. Ausserdem wandelt die Netzwerkschicht logische Adressen (z.B. 192.168.1.10) in Physikalische (MAC-Adresse der Netzwerkkarte) um. Hier befindet sich das Internet Protocol (IP).

Datensicherungsschicht (2)

Aus den in der Netzwerkschicht gewonnenen Informationen wird hier der Header, der Datenkopf, der Pakete erstellt. Anschliessend wird das Datenpaket, nachdem die eigentlichen Daten von Schicht 3 und 4 angehängt und das Paket ausserdem mit einer Prüfsumme versehen wurde, an die unterste Schicht zum Versand übertragen. Die zweite wichtige Funktion dieser Schicht ist die Handhabung fehlerhaft gesendeter Pakete. Sie ist für das wiederholte Senden von korrupten Paketen verantwortlich.

Bitübertragungsschicht (1)

Hier kommt es zum eigentlichen Transfer der Datenpakete. Die einzelnen Bytes der in Schicht 2 zusammengestellten Pakete werden in Bits und dann in analoge Signale umgewandelt. Das Signal geht an alle am Netzwerk angeschlossenen Stationen, wo sie das Schichtenmodell in umgekehrter Reihenfolge durchlaufen.

2.2 Internet-Schichtenmodell

Mit dem Siegeszug des Internet kommt dem TCP/IP-Protokollstack eine neue Bedeutung zu. Mittlerweile hat es sich vom reinen Internetprotokoll zum führenden Netzwerkprotokoll entwickelt.

TCP/IP lässt sich in vier Schichten unterteilen, wobei sie sich teilweise in das OSI-Modell eingliedern lassen. Die Daten werden in kleinen Einheiten, den Paketen oder Datagrammen, übertragen. Jedes Paket enthält einen Kopf (Header), in dem Steuerinformationen enthalten sind. Jede Schicht fügt einen eigenen Header hinzu, was am Ende der Übertragung folgenden Aufbau ergibt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbau eines Pakets

Die Schichten im Einzelnen^[10]:

- Linkschicht: Sie stellt funktional eine Verbindung zwischen den Schichten eins und zwei des OSI-Modells dar. Hier wird die Weiterleitung eines Pakets zwischen 2 Knoten ermöglicht. Ein Beispiel für diese Schicht ist das Ethernet-Protokoll mit seinen MAC-Adressen.
- Internetschicht: Diese Schicht stell Funktionen der dritten OSI-Schicht bereit. Mit den hier sitzenden IP-Adressen wird die dynamische Weiterleitung von Datenpaketen, dem Routing, ermöglicht. Auf dieser Schicht aufsitzende Protokolle sind das Internet Protocoll (IP) und das Internet Control Message Protocoll (ICMP).
-
Transportschicht: Diese Schicht entspricht der vierten OSI-Schicht. Auf dieser Stufe wird eine Ende-zu-Ende-Verbindung zwischen zwei Rechnern bereitgestellt. Hier heimische Protokolle sind Transmission Control Protocol (TCP) und User Datagram Protocol (UDP).
- Anwendungsschicht: Auf dieser Ebene werden Daten zwischen Anwendungen ausgetauscht. Dabei gilt es zwischen Vordergrunddiensten (mit denen der Anwender aktiv interagiert, z.B. Mailprogramm oder Webbrowser) an denen und Hintergrunddiensten (ohne direkte Beteiligung des Benutzers, z.B. DNS) zu unterscheiden.

Die folgende Abbildung zeigt das Schichtenmodell mit der Anwendungsschicht an oberster- und der Linkschicht an unterster Stelle.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: TCP/IP-Protokollstack

2.3 Internet Protocol Version 4

Das Internet Protokoll (IP) in der Version 4 (IPv4), festgelegt in RFC791^[11], ist das aktuelle, Internet-Protokoll^[12]. Ältere Versionen haben keine Bedeutung mehr. Version 5 wird es nicht geben, die zukünftige Version wird die Versionsnummer 6 tragen und wird später noch vorgestellt. Bei IP handelt es sich um ein verbindungsloses Protokoll, welches zum Austausch von Paketen zwischen zwei Rechnern dient. Verbindungslos bedeutet, dass keine Vorkehrungen getroffen werden, die die Ankunft der Daten beim Ziel garantieren. Jeder Rechner ist durch eine eindeutige Adresse, der IP-Adresse, festgelegt. Die IP-Adresse ist eine Zahl mit einer Länge von 32Bit, d.h. es können maximal 2^32=4294967296 verschiedene Adressen vergeben werden. Die wirkliche Zahl verwertbarer Adressen ist in der Praxis allerdings deutlich kleiner, da durch reservierte Bereiche und aufgrund der starren Strukturen bei der Adressvergabe viele Adressen wegfallen oder „verschwendet“ werden.

Dargestellt wird die Zahl durch Aufteilung in 4 Oktetten (8Bit), getrennt durch einen Punkt, also z.B. 192.168.1.1. Die IP-Adresse besteht aus zwei Teilen. Dem Netzteil, der das Netz bezeichnet, in dem der Rechner sich befindet und dem Rechnerteil, der für den Rechner in seinem Netz steht. Der Netzteil wird von nationalen Organisationen (in Deutschland DE-NIC^[13])an Internet-Provider, Institutionen, Unternehmen, Bildungseinrichtungen und Endanwender vergeben. Man teilt fünf Klassen von Netzen ein:

- Klasse A (Class A)

Mit den IP-Adressen 0.0.0.0 bis 127.255.255.255. Die ersten 8 Bit stehen für den Netzteil, wobei das erste Bit „0“ ist. Die restlichen 24 Bit bilden den Rechnerteil. Damit sind maximal 27=128 Netze und 223=Rechner je Netz möglich.

- Klasse B (Class B)

Mit den IP-Adressen 128.0.0.0 bis 191.255.255.255. Die ersten 16 Bit stehen für den Netzteil, wobei die ersten beiden Bits „10“ sind. Die restlichen 16 Bit bilden den Rechnerteil. Damit sind maximal 214= Netze und 216=Rechner je Netz möglich.

- Klasse C (Class C)

Mit den IP-Adressen 192.0.0.0 bis 223.255.255.255. Die ersten 24 Bit stehen für den Netzteil, wobei die ersten drei Bit „110“ sind. Die restlichen 8 Bit bilden den Rechnerteil. Damit sind maximal 221= Netze und 28=Rechner je Netz möglich.

- Klasse D (Class D)

Mit den IP-Adressen 224.0.0.0 bis 239.255.255.255. Bei Klasse D-Netzen handelt es sich um Multicast-Adressen. Mit ihnen können nicht nur einzelne Rechner adressiert werden, sondern alle Rechner eines Multicast-Netzes zur gleichen Zeit. Verwendet wird Multicast beispielsweise beim Videostreaming.

- Klasse E (Class E)

Bei Klasse E handelt es sich um einen reservierten Adressbereich.

Ein TCP/IP-Netz lässt sich durch Subnetting, festgelegt in RFC950^[14], in kleinere Teilnetze unterteilen. Dabei wird der Rechnerteil der IP-Adresse in einen weiteren Rechner- und einen Subnetzteil (Subnet) aufgeteilt. Ein Subnetz kann eine beliebige Gösse annehmen, allerdings sind die beiden Adressen „0.0.0.0“ und „255.255.255.255“ reserviert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: IP-Adresse – Netz-, Subnetz- und Rechnerteil

Eine weitere spezielle IP-Adresse ist die Broadcast-Adresse, welche alle Rechner in einem Netz oder Subnetz adressiert. Bei einem Netz wird die Broadcast-Adresse gebildet, in dem man alle Bits des Rechneranteils der IP-Adresse auf „1“ setzt. Die Broadcast-Adresse eines Klasse C-Netzes wäre dann beispielsweise 192.168.1.255. Bei einem Subnetz gilt es zu beachten, dass nur der Rechneranteil, nicht auch der Subnetzanteil, verwendet wird.

Mit den privaten IP-Adressen, festgelegt in RFC1596 und RFC1918, stellt die IANA einige Adressbereiche zur Verfügung, die beliebig verwendet werden können. Sie eignen sich besonders für private, lokale Netzwerke und Ihr Einsatz muss nicht offiziell beantragt werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: private IP-Adressbereiche

Zu beachten ist, dass diese IP-Adressen von Routern nicht weitergeleitet werden, also nur im lokalen Netz Gültigkeit besitzen. Soll ein Netz mit privaten Adressen an das Internet angeschlossen, oder zwei solcher Netze miteinander verbunden werden, so müssen die Adressen umgesetzt werden. Die dazu benötigte Technik nennt sich Network Adress Translation oder kurz NAT. NAT, festgelegt in RFC1631^[15], ist sowohl in Software- (z.B. Proxies) als auch in Hardwarelösungen (z.B. Router oder Application-Gateways) vorhanden.

Abbildung 4 zeigt den Header eines IPv4-Pakets^[16].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: IPv4-Header

2.4 Internet Control Message Protocol

Das ICMP, beschrieben in RFC792^[17], liefert den Protokollen TCP und UDP eine Reihe von Fehler- und Diagnosemeldungen. Wie auch IPv4 ist es auf der Internetschicht angesiedelt.

Der Header eines ICMP-Packets ist in Abbildung 5 zu sehen^[18].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: ICMP-Header

Einige wichtige ICMP-Meldungen im Überblick^[19]:

Abbildung in dieser Leseprobe nicht enthalten^[20]

Tabelle 4: ICMP-Typen

2.5 User Datagram Protocol

Das UDP-Protokoll ist ein verbindungsloses Protokoll zwischen zwei Netzwerkdiensten. Es existiert keine Benachrichtigung über den erfolgreichen Empfang eines Pakets. Sollte solch ein Sicherheitsmechanismus erwünscht sein muss dieser von Protokollen der höheren Schichten erbracht werden. UDP ist in RFC768^[21] festgeschrieben. Der Vorteil der Verbindungslosigkeit ist eine höhere Geschwindigkeit von UDP im Vergleich mit TCP. Angewendet wird UDP beispielsweise für den Domain Name Service (DNS) sowie für das Streamen von Multimediainhalten.

Der Header eines UDP-Packets ist in Abbildung x zu sehen^[22].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: UDP-Header

2.6 Transmission Control Protocol

Beim in RFC793 festgelegten Transmission Control Protocol (TCP) handelt es sich um ein verbindungsorientiertes Protokoll der Transportschicht. Bevor Daten ausgetauscht werden, muss zunächst eine Verbindung zwischen Quelle und Ziel aufgebaut sein. Die Verbindung hat die Möglichkeit verlorengegangene Pakete erneut zu senden. Damit ist eine sichere Übertragung der Daten gewährleistet. Nach Abschluss einer Datenübertragung wird die Verbindung geregelt beendet.

Der TCP-Verbindungsaufbau, auch als „Drei-Wege-Handshake“ bekannt, wird in Kapitel 4.2, Scanner, beschrieben.

Dem Datenverlust wird durch Sequenz- und Quittungsnummern entgegengewirkt: Die Sequenznummern werden von beiden Teilnehmern beim Verbindungsaufbau erstellt und für jeden Empfang von Daten hochgezählt. Die Quittungsnummer quittiert den korrekten Empfang der Pakete.

Der TCP-Header ist in Abbildung 7 zu sehen^[23].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: TCP-Header

Viele Server im Internet bieten gleichzeitig mehr als einen Dienst an. Dazu wird ein Mechanismus benötigt, der eintreffende Datenpakete eindeutig für einen bestimmten Dienst kennzeichnet. Dies geschieht bei TCP mit Hilfe der Ports. Jedem Standarddienst ist eine bestimmte Portnummer zugeordnet. So werden Emails an einen SMTP-Mailserver an Port 25 gesendet, Email beim Provider wird entweder auf Port 110 (POP3) oder 143 (IMAP) abgeholt, und ein Browser verbindet mit dem Webserver auf Port 80. Insgesamt gibt es 65535 verschiedene Ports. Dabei werden die Ports unter 1024 oft als „privilegierte Ports“ bezeichnet, da hier meistens Server auf Verbindungen warten. Die Ports zwischen 1024 und 65535 sind die „unprivilegierten Ports“. Ein Dienst ist aber nicht zwingend an einen bestimmten Port gebunden, es ist auch möglich, dass ein Webserver nicht auf Port 80 läuft. Auch mehrere gleiche Dienste auf unterschiedlichen Portnummern, z.B. mehrere FTP-Server, sind möglich.

Eine Liste mit Portnummern wichtiger Dienste:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Portnummern

2.7 Internet Protocol Version 6

Durch die Knappheit der IP-Adressen in IPv4, begann die Internet Engineering Task Force relativ früh, nämlich im Jahr 1992, mit der Ausschreibung für den Nachfolger des Internet-Protokolls. So ist IPv6 entstanden. Funktionen, die sich in IPv4 bewährt hatten, kommen auch bei der neuen Version zum Einsatz, während weniger praktikable Funktionen entweder ersetzt oder ganz weggelassen wurden.

Wichtige Neuerungen in IPv6^[24]:

- Grosser Adressraum mit einer Länge von 16Byte.
- Anzahl der Felder im Header von 12 (IPv4) auf 8 reduziert. Dadurch weniger Paket-Overhead.
- Autokonfiguration beim Installieren neuer Rechner im Netz möglich.
- Erweiterte Unterstützung beim Versand von Multimedia-Inhalten.
- Beibehaltung der IP-Adresse, auch bei Wechsel zu anderen Providern.
- Vertraulichkeit und Authentizität auf IP-Ebene durch Aufnahme des IPSec-Projektes (secure IP) der IETF^[25].

3 Angriffe

3.1 Sniffer

Eine der grössten Gefahren im Netzwerk sind Sniffer^[26], auch bekannt als Protocol Analyzer.

3.1.1 Anwendungsgebiete von Sniffern

Für Sniffer gibt es verschiedene Anwendungsgebiete:

Sie dienen Netzwerkadministratoren zum Aufspüren von Problemen und möglichen Gefahren. Kommt es in Teilbereichen eines Netzes zu unerwarteten Problemen (z.B. Verlangsamung der Datenübertragungsrate), können mögliche Ursachen mit Hilfe eines Sniffers eingekreist und ermittelt werden.

Mit Sniffern lässt sich aber auch der komplette Datenverkehr in einem Netzwerk abhören. Sniffer werden auf einem beliebigen Computer installiert, empfangen den über diesen Rechner laufenden Datenstrom, und schreiben die analysierten Daten in eine Datei. Es können die verschiedensten Protokolle abgehört werden.

3.1.2 Funktionsweise von Sniffern

Jede Netzwerkschnittstelle eines Rechners hat im LAN seine eigene Adresse, die MAC-Adresse. Über diese Adresse kann der Computer im Netzwerk angesprochen werden, ähnlich der Identifikation von Rechnern im Internet über IP-Adressen^[27]. In der Regel hören und reagieren Computer nur auf Daten, die direkt an Sie adressiert sind, also die eigene MAC-Adresse als Ziel haben. Allerdings lässt sich ein Netzwerkinterface in den sogenannten Promiscuous-Mode^[28] versetzen. In diesem Zustand kann der gesamte Datenstrom überwacht werden, unabhängig davon, für welches Ziel die durchgehenden Daten bestimmt sind. Dies wird durch die heute verbreitete LAN-Struktur erheblich vereinfacht: Zur Verteilung der Daten werden häufig Hubs verwendet. Eine versandte Nachricht wird an den Hub gesendet, der sie an alle angeschlossenen Rechner weiterleitet. Switches dagegen bauen eine direkte Verbindung vom Sender zum Empfänger auf, da Sie wissen, welche MAC-Adresse mit welchem Port verbunden ist. Switches sind zwar generell sicherer als Hubs, aber auch hier ist es mit den richtigen Werkzeugen, wie z.B. dsniff, möglich Daten abzugreifen.

3.1.3 Gefahren durch Sniffer

Da mit Hilfe eines Sniffers der gesamte Datenverkehr des Netzwerkes abgefangen werden kann, stellen Sie eine grosse Gefahr dar^[29].

Sniffer können zum Beispiel für folgende Zwecke eingesetzt werden^[30]:

- Authentifizierungsdaten (Benutzernamen und Passwörter) abfangen
- Vertrauliche oder geschützte Daten erlangen
- Zugriff zu Netzwerken erhalten oder die Sicherheit derselben unterwandern

Beispiele von abgegriffenen Authentifizierungsdaten^[31]:

Überwachung von Telnet (Port 23)

Telnet wird genutzt um sich über ein Netzwerk an einem anderen Computer anzumelden. Es überträgt Benutzernamen und Passwort im Klartext über das Netzwerk.

Überwachung von FTP (Port 21)

Auch das FTP-Protokoll, das zur Datenübertragung im Netzwerk benutzt wird, überträgt Authentifizierungsdaten im Klartext. FTP kann auch für den anonymen Zugriff auf Daten benutzt werden, dann mit dem Benutzernamen „anonymous“ und einem beliebigen Passwort. Administratoren sehen es gerne, wenn die eigene Email-Adresse als Passwort angegeben wird.

Überwachung von POP (Port 110)

POP ist das Übertragungsprotokoll zum Abrufen von Emails von einem Mailserver auf den eigenen Computer. POP-Authentifizierungsdaten werden normalerweise nicht verschlüsselt, sondern im Klartext übertragen. Benutzername und Passwort werden mit den Befehlen „USER“ und „PASS“ übermittelt.

Es existieren POP-Erweiterungen, welche eine verschlüsselte Übertragung ermöglichen.

Überwachung von IMAP (Port 143)

IMAP ist eine Alternative zu POP. Bei IMAP werden die Email nicht heruntergeladen, sondern verbleiben auf dem Mailserver und können dort bearbeitet werden. Die Authentifizierung erfolgt durch eine Zeichenkette, die aus einem festgelegten Token, dem LOGIN-Befehl sowie dem Benutzernamen und Passwort besteht. Auch bei IMAP werden die Authentifizierungsdaten häufig im Klartext übermittelt. Und auch hier gibt es Erweiterungen, die die verschlüsselte Übertragung ermöglichen.

Überwachung von SMTP (Port 25)

SMTP ist für die Übertragung von Emails im Internet zuständig.

Es gibt Sniffer, die ganze Emails abfangen und speichern können. Als Beispiel sei hier mailsnarf, Bestandteil des Sniffing-Toolkits Dsniff, genannt, aber auch das FBI Programm Carnivore gehört dazu.

Überwachung von HTTP (Port 80)

Per HTTP werden Webdaten vom Webserver an den Webbrowser auf dem Client gesendet. Besonders interessant für einen Sniffer sind Formulardaten, wie z.B. Kreditkartennummern, Adressen, Benutzernamen und Passwörter.

3.1.4 Beispielprogramme

3.1.4.1 BUTTSniffer

Bei BUTTSniffer handelt es sich um einen Sniffer für die Kommandozeile auf Windows-Systemen. Es wurde von DilDog, einem Mitglied der Hackergruppe Cult of the Dead Cow, geschrieben. BUTTSniffer ist auf der Homepage^[32] von Cult of the Dead Cow erhältlich.

Ein Aufruf von BUTTSniffer ohne Parameter liefert einen Überblick über die möglichen Optionen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: BUTTSniffer Optionen

BUTTSniffer kennt drei Betriebsmodi:

- Device-List (Geräteliste)
- Interactive (Interaktiv)
- Disk-Dump (Speicherauszug)

Besonders interessant ist der Interaktive Modus, der an dieser Stelle kurz vorgestellt werden soll.

Mit dem Modus Device-List (buttsniff –l) wird eine Liste aller Netzwerkschnittstellen ausgegeben, die von BUTTSniffer erkannt wurden. Jede Schnittstelle erhält eine Nummer. Diese Nummer wird für den Aufruf der anderen beiden Modi benötigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: BUTTSniff - erkannte Netzwerkschnittstellen

Als nächstes muss ein Daemon auf einem beliebigen Port (im Beispiel 9999) eingerichtet werden, der sich dann per Telnet ansprechen lässt (buttsniff –i 0 0999).

Jetzt kann eine Telnet-Verbindung mit dem Daemon gestartet werden.

Über „MonitorConnections“ erhält man eine Liste aller IP-Sessions, die über die überwachte Schnittstelle gehen. Im Beispiel sieht man lediglich eine aktive Session, eine Verbindung zwischen Client 192.168.1.1 Port 1056 und 192.168.1.2 Port 22.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: BUTTSniffer - Hauptmenü

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: BUTTSniffer - Liste aktiver IP-Sessions

3.1.4.2 Ethereal

Bei Ethereal^[33] handelt es sich um einen relativ neuen Protocol-Analyzer, der erst 1998 veröffentlicht wurde. Das Programm steht kostenlos für Windows und Unix bereit. Da die Ethereal-Quellen frei verfügbar sind (Open Source) entwickelte sich das Programm schnell zu einem mächtigen Werkzeug und ist mittlerweile einer der beliebtesten Sniffer.

Zum Betrieb ist die GTK-Bibliothek^[34] (Gimp Toolkit) erforderlich, die sich um die grafische Schnittstelle kümmert.

Ethereal kann mitgeschnittene Daten von anderen Programmen, wie z.B. tcpdump^[35] oder WinDump^[36], analysieren. Mit der pcap-Bibliothek besteht zusätzlich die Möglichkeit selber Pakete zu sniffen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Ethereal – dreigeteiltes Hauptfenster

Ethereal verfügt über eine geordnete grafische Benutzeroberfläche. Das eigentliche Programmfenster ist dreigeteilt. Im oberen Bereich befindet sich eine Liste aller gesnifften Pakete. Der mittlere Bereich bietet Detailinformationen zum im oberen Fenster ausgewählten Paket, inklusive der Ethernet- und TCP/IP-Header. Im unteren Bereich schliesslich wird ein ASCII- und Hexdump des Pakets gezeigt.

Über den Menüpunkt „Capture – Start“ (CTRL + K) wird eine neue Sniffersitzung gestartet. Ethereal benötigt die Angabe der Netzwerkschnittstelle, welche abgehört werden soll. Wichtige Konfigurationspunkte sind die Begrenzung der einzelnen Pakete auf eine bestimmte Grösse („Limit each packet to xx bytes“), um die Sitzung nicht unnötig aufzublähen (z.B. bei der Fehlersuche im Netzwerk) und der Aktivierung des Promiscuous-Modus („Capture packets in promiscuous mode“), um an alle durchgehenden Pakete zu gelangen. Sehr hilfreich ist auch die Aktivierung

Der MAC-Namensauflösung („Enable MAC name resolution“).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Ethereal – Capture-Voreinstellungen

Ethereal ermöglicht die Erstellung von Paketfiltern. Beim Einsatz von bereits gesnifften Datenströmen verwendet man den Menüpunkt „Edit – Display Filters“, beim eigenen Live-Einsatz „Edit – Capture – Filters“. Die einzelnen Filter können mit Namen versehen werden, was eine Wiedererkennung bei späterer Verwendung erleichtert. Es sind Filter für fast alle Protokoll-, Paketeigenschaften- und Werte möglich. Einzelne Bedingungen lassen sich mit Boolschen Ausdrücken kombinieren. Zur Auswahl der eingerichteten Filter dient der Button „Filter“ in der linken unteren Ecke des Ethereal-Hauptfensters. Dort stellt man bei Bedarf den gewünschten Filter ein und beeinflusst damit die Ausgabe der Daten auf dem Bildschirm.

In der folgenden Abbildung wird als Beispiel für einen Paketfilter eine FTP-Sitzung gezeigt. Nachdem sich der Benutzer am FTP-Server angemeldet hat, wird die Verbindung auch schon beendet („Too many users“). Der eingestellte Filter zeigt lediglich FTP-Protokoll-Pakete.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Ethereal – Session mit aktiviertem Filter

Im Menü „Tools“ bietet Ethereal einige nützliche Werkzeuge. Über „Tools – Protocol Hierarchy Statistics“ lässt sich eine Statistik über die Zusammensetzung der Sitzung nach Protokollen abrufen. Die Statistik zeigt detaillierte Paket- und Byteinformationen für jeden Pakettyp einer Verbindung. In der folgenden Abbildung wird die Statistik für die im letzten Abschnitt (Paketfilter) gewählte FTP-Sitzung gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Ethereal – Protokollstatistik

Über „Tools – Follow TCP Stream“ kann der komplette Ablauf einer TCP-Sitzung zusammengefügt und angezeigt werden. In der folgenden Abbildung wieder die bereits bekannte FTP-Sitzung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Ethereal – Follow TCP Stream

3.2 Scanner

Das Scannen eines Zielsystems ist eine der wichtigsten Methoden zum Aufspüren von Schwachstellen und damit Angriffspunkten^[37]. Dabei versucht man, sich durch Zusammentragen von Informationen ein möglichst genaues Bild des Ziels zu verschaffen. Mit den neu gewonnenen Erkenntnissen lässt sich das weitere Vorgehen besser planen.

Scannen lässt sich mit dem Abklopfen von Wänden auf der Suche nach Türen und Fenstern vergleichen.

Scannen stellt für Angreifer ein wichtiges Werkzeug dar, kann aber auch von Administratoren zur Sicherheitsüberprüfung der eigenen Systeme eingesetzt werden. So finden sie mittels Portscans, ob nicht doch ein Dienst läuft, der gar nicht gebraucht wird. Auch Internet Service Provider machen Gebrauch von Portscans, z.B. um sicher zu stellen, dass ihre Kunden nicht durch einen gerade aktuellen Trojaner (z.B. Netbus) infiziert wurden^[38].

Beim Portscanning werden bestimmte Ports des Ziels kontaktiert, um herauszufinden, welche davon Verbindungen akzeptieren (offene Ports) und welche keine Verbindungen annehmen (geschlossene Ports). Hinter einem offenen Port wartet irgendein Dienst auf eine Verbindung. Da die meisten Dienste typische Ports öffnen (z.B. 80 für Webserver, 25 für Mailserver) kann man umgekehrt aus einem gefundenen offenen Port auf den dahinter laufenden Dienst schliessen. Mit diesem Wissen kann ein Angreifer systematisch alle möglichen Ports (1-65535) durchprobieren. Findet er einen oder mehrere Offene Ports, kann er versuchen, das dahinter laufende Programm anzugreifen.

Im Folgenden eine kleine Auswahl von Informationen, die sich über ein Ziel sammeln lassen^[39]:

- Erkennung von TCP- und UDP-Diensten, die ausgeführt werden
- Erkennung welches Betriebssystem das Ziel verwendet
- Erkennung der Serveranwendungen und deren Versionsnummern
- Erkennung ob bestimmte Dienste Authentifizierung erfordern
- Erkennung ob anonymer Login möglich ist

3.2.1 Legalität von Portscans

Anfragen an einen Rechner zu stellen, mit dem Ziel zu erfahren welche Dienste dieser Rechner anbietet, ist bei TCP/IP ein normaler Vorgang. Es handelt sich dabei nicht um einen „Hack“. Der ganze Vorgang ist vergleichbar mit dem Anklopfen an einer Haustür. Das Klopfen selber ist keine kriminelle Handlung. Erst das Aufhebeln der Tür ist der Beginn eines Einbruchs und damit strafbar. Beim Chaos Computer Club Köln findet sich ein interessanter Beitrag^[40] mit Pro und Kontra zum Thema Portscanner.

3.2.2 Scan-Verfahren

Es gibt verschiedene Möglichkeiten ein Computersystem zu scannen. Die verschiedenen Varianten unterscheiden sich in ihrer Ausführungsgeschwindigkeit, Auffälligkeit gegenüber Entdeckungsversuchen seitens des gescannten Systems und Präzision der erzielten Ergebnisse.

Im Folgenden eine Auswahl bekannter Verfahren:

3.2.2.1 TCP-Connect-Scan (voller TCP-Connect)

Beim TCP-Connect-Scan wird die Verbindung zum Ziel über den regulären „Drei-Wege-Handshake“ aufgebaut:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: TCP-Connect-Scan

Ein voller TCP-Connect ist sehr auffällig und daher leicht zu entdecken. Die Wahrscheinlichkeit, dass sich der Scan in den Logdateien des Ziels niederschlägt ist hoch. Ausserdem ist dieses Verfahren sehr langsam. Über eine „Multi-Socket-Methode“ (viele Anfragen werden gleichzeitig gestellt) lässt es sich aber beschleunigen.

Ein TCP-Connect-Scan ist der einzige Scan, der zur Ausführung keine Root-Rechte benötigt. Alle anderen TCP-Scans erfordern das Manipulieren von TCP-Flags, welches auf einer systemnahen Ebene geschieht, und deshalb dementsprechend weitreichende Berechtigungen erfordert^[41].

3.2.2.2 Stealth Scan: TCP-SYN-Scan (halboffener TCP-Scan)

Beim TCP-SYN-Scan wird keine vollständige Verbindung aufgebaut. Zunächst wird ein SYN an das Ziel gesendet. Der Port ist offen, wenn eine SYN/ACK-Antwort erfolgt. Daraufhin erwidert der Angreifer das Paket des Ziels mit RST/ACK, um die Verbindung vorzeitig zu beenden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: TCP-SYN-Scan. Port offen

Der Port ist geschlossen, wenn SYN sofort mit RST/ACK beantwortet wird:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: TCP-SYN-Scan. Port geschlossen

TCP-SYN-Scans sind im Vergleich zu TCP-Connect-Scans viel unauffälliger. Dementsprechend sinkt auch die Wahrscheinlichkeit einer Protokollierung des Vorgangs durch das Ziel.

3.2.2.3 Stealth Scan: TCP-FIN-Scan (Stealth-Scan)

Dieser Scan wird erst durch die Empfehlungen von RFC793 in der TCP-Implementierung auf Unix-Systemen möglich. Der Angreifer sendet ein FIN-Paket an das Ziel. Normalerweise dient das FIN-Flag zum regulären beenden einer Verbindung. Laut RFC793^[42] reagieren geschlossene Ports mit einem RST-Paket. Offene Ports tun dies nicht:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: TCP-FIN-Scan

Beim TCP-FIN-Scan handelt es sich um ein sehr unauffälliges Scanverfahren. Der Scan ist nicht auf Windows-Betriebssysteme anwendbar, da ihre TCP-Implementierung die Empfehlungen von RFC793 nicht befolgt^[43].

3.2.2.4 Stealth Scan: TCP-Null-Scan

Beim TCP-Null-Scan werden alle Flaggen ausgeschaltet. Nach RFC793 antworten geschlossene Ports mit einem RST:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: TCP-Null-Scan

3.2.2.5 Stealth Scan: TCP-Xmas-Tree-Scan

An das Ziel wird ein Paket mit allen TCP-Flags (URG, ACK, PSH, RST, SYN, FIN), mindestens aber FIN, URG und PUSH gesendet^[44] (daher auch der Name Xmas-Tree: Das Paket „leuchtet“ wie ein Weihnachtsbaum^[45]). Auch hier antworten geschlossene Ports nach RFC793 mit einem RST:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22: TCP-Xmas-Tree-Scan

3.2.2.6 TCP-ACK-Scan

Mit diesem Verfahren untersucht man Firewalls nach gefilterten und ungefilterten Ports. Man sendet ACK-Pakete an bestimmte Ports der Firewall. Wird das Paket vom Ziel mit einem RST beantwortet, wird der Port nicht gefiltert. Erhält man keine Antwort oder lediglich eine ICMP-Destination-Unreachable-Meldung wird dieser Port gefiltert. Man erhält somit einen Überblick über die Firewallregeln. Ausserdem erfährt man, ob es sich um einen einfachen Paketfilter (der nur bestätigte Verbindungen mit gesetztem ACK-Flag durchlässt und SYN-Pakete abblockt) oder um fortgeschrittene Filtertechniken handelt. Informationen über offene Ports erhält man mit diesem Scanverfahren nicht.

TCP-ACK-Scans funktionieren nicht mit allen Firewalls.

TCP-ACK-Scans können auch als „Ping-Ersatz“ dienen, wenn ICMP vom Ziel geblockt wird. Man sendet ein ACK-Paket. Wird das Paket mit RST erwidert, ist das Ziel „alive“^[46].

3.2.2.7 TCP-Window-Scan

Dieses Verfahren eignet sich sowohl zur Erkennung von offenen als auch gefilterten und ungefilterten Ports mancher Systeme, z.B. AIC oder FreeBSD. Möglich wird dieser Scan durch eine Anomalie der gemeldeten TCP-Fenstergrösse^[47].

3.2.2.8 Fragmentierter Scan

Beim Fragmentierten Scan werden fragmentierte Pakete an das Ziel gesendet. Der TCP-Header des Pakets wird auf mehrere Paketfragmente verteilt. Dieser Scan ist von Firewalls und IDS-Systemen schwieriger zu entdecken, da manche nur eines der Fragmente inspizieren und dann als vertrauenswürdig einstufen. Allerdings haben manche Programme Probleme bei der Verarbeitung von fragmentierten Paketen und stürzen ab.

Mittlerweile haben viele Entwickler reagiert und so werden von aktuellen Firewalls alle Fragmente abgefangen, zusammengesetzt und analysiert^[48]. So kann z.B. im Linux-Kernel das Zwischenspeichern und Auswerten von Paketfragmenten aktiviert werden (CONFIG_IP_ALWAYS_DEFRAG)^[49]

3.2.2.9 UDP-Scan: UDP-ICMP-Port-Unreachable-Scan

Bei dieser Art von Scan wird ein UDP-Paket an das Ziel gesendet. Ein inaktiver Port wird das Paket seinerseits mit einer „ICMP-Port-Unreachable“-Meldung
(ICMP-PORT-UNREACH) beantworten, ein Aktiver nicht.

Da es sich bei UDP um ein verbindungsloses Protokoll handelt, ist die Genauigkeit der Ergebnisse von mehreren Faktoren abhängig, z.B. von der Netzwerkauslastung oder den vorhandenen Systemressourcen des Ziels. Daher ist diese Art von Scan sehr ungenau und sehr langwierig. Es kann auch vorkommen, dass wegen eines ICMP Nachrichtenlimit des Ziels keine ICMP-Meldung zurückgegeben wird^[50]. Dadurch kann das Scanergebnis verfälscht werden (keine Meldung zurück lässt auf offenen Port schliessen)^[51]. Der Linux-Kernel zum Beispiel limitiert die Anzahl an ICMP-Destination-Unreachable-Meldungen auf 80 pro 4 Sekunden, mit einer Viertelsekunde Wartezeit, falls der Wert überschritten wurde^[52]. Des weiteren besteht die Gefahr, dass das Zielsystem ICMP-Datenverkehr durch eine Firewall filtert, wodurch das Ergebnis ebenfalls ungenau wird.

Auch für diesen Scan sind Superuser-Rechte erforderlich.

3.2.2.10 UDP-Scan: UDP-Recvform-and-Write-Scan

Dieser Scan^[53] ähnelt dem UDP-ICMP-Port-Unreachable-Scan, nur kann er auch von normalen Benutzern ausgeführt werden, und liefert diesen aufgrund eines weiteren Fehlers, interessante Meldungen.

Versucht man einen Port zu kontaktieren, der zuvor bei einem UDP-ICMP-Port-Unreachable-Scan mit ICMP-PORT-UNREACH geantwortet hat (was ein normaler Anwender nicht erfährt), erhält man meist die Meldung „Error 13 – Try Again“ anstatt der normalen Fehlermeldung „Error 111 – Connection refused“. Bei diesem Scanverfahren wird also jeder Port zweimal gescannt. Beim ersten Mal generiert das Ziel eine Antwort, die leider verborgen bleibt. Beim zweiten Scan erfolgt dann die informative Rückmeldung: Lautet diese „Error 13“ ist der Port geschlossen.

Dieses Verfahren ist unzuverlässig und zeitraubend.

3.2.2.11 ICMP-Echo-Scan (Ping-Scan)

Hierbei handelt es sich um den einfachsten Scan überhaupt. Ziel ist lediglich in Erfahrung zu bringen, welche Hosts überhaupt „alive“, also erreichbar sind.

Man sendet einen einfachen Ping, einen ICMP-Echo-Request an das Ziel. Das Ziel beantwortet diesen in der Regel (wenn ICMP nicht durch eine Firewall geblockt wird) mit einem „ICMP-Echo-Reply“.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: ICMP-Echo-Scan

3.2.2.12 Reverse-Ident-Scan

Ident^[54] dient zur Feststellung der Identität des Benutzers einer beliebigen TCP-Verbindung. Der Dienst läuft auf Port 113. Ident gibt als Antwort den Eigentümer eines Prozesses, der auf einem bestimmten Port läuft. Somit lassen sich schnell Dienste erkennen, bei denen die Sicherheit vernachlässigt wurde, wie z.B. ein Webserver, der anstatt mit unbedeutenden Rechten (z.B. Benutzer „nobody“ oder „www“) mit den vollen Superuser-Rechten („root“) läuft^[55].

3.2.2.13 RPC-Scan

Beim RCP-Scan werden alle untersuchten Ports nach RPC-Diensten (dem Vorhandensein eines Portmappers) abgetastet^[56]. RPC ist ein Subsystem für die Vereinfachung und Standardisierung der Interprozess-Kommunikation. Bekannte RPC-Dienste sind z.B. das Network File System NIS oder der Network Information Service NIS. Da der RPC-Scan einen vollen TCP-Handshake ausführt, wird der Scanvorgang mit grosser Wahrscheinlichkeit in den Logdateien des Zielsystems protokolliert.

3.2.2.14 FTP-Bounce-Scan

Dieser Scan ist durch einige Schwächen im FTP-Protokoll^[57] möglich. Er wurde im Jahr 1995 von „Hobbit“ bekannt gemacht.

Bei einem normalen Verbindungsaufbau mit einem FTP-Server kontaktiert der Client den Server auf Port 21. Dies ist die Steuerungsverbindung. Zusätzlich ist eine eigenständige Datenverbindung nötig, die vom Server mit einem Port des Clients aufgebaut wird. Anschliessend sendet der Client einen PORT-Befehl, in dem er den Server anweist, die Datenverbindung mit dem eben geöffneten Port aufzubauen. Dies ist der sogenannte „aktive Transfer“^[58]. Wichtig für den Missbrauch ist der PORT-Befehl. Da dem PORT-Befehl sowohl Portnummer als auch die zu nutzende IP-Adresse übergeben werden, kann man den Server dazu anweisen, mit einer beliebigen Adresse zu verbinden. Also wird dem Server die IP-Adresse und die Portnummer übergeben, die gescannt werden soll. Ist der PORT-Befehl erfolgreich, wird versucht einen LIST-Befehl auszuführen. Ist auch dies erfolgreich, gilt der Port als geöffnet. Antwortet der Server aber mit der Meldung „425 Can’t build data connection“ ist der Port geschlossen.

Es handelt sich um keinen Fehler in der Implementierung, sondern um einen Fehler in der FTP-Spezifikation. Damit muss dieses Verhalten von allen FTP-Servern eingehalten werden, die sich an RFC959 halten wollen.

Der Scan bietet eine Möglichkeit, den Scan anderen (nämlich dem FTP-Server) anzulasten. Ausserdem können Portfilter und Firewalls umgangen werden, da es sich bei FTP um einen bekannten Dienst handelt, der selten geblockt wird. Es besteht natürlich immer noch die Gefahr, dass sich die Vorgänge in den FTP-Logs niederschlagen.

FTP-Bouning ist sehr zeitintensiv. Und da die Methode mittlerweile weit verbreitet ist, haben viele Administratoren aus Sicherheitsgründen damit begonnen, sich nicht länger an die Vorgaben aus RFC959 zu halten und die FTP-Proxy-Funktion zu deaktivieren^[59], z.B. lassen manche FTP-Server beim PORT-Befehl nur noch die Verbindung zurück zum ursprünglichen Host zu^[60].

3.2.2.15 Banner-Scan

Ziel des Bannerscanning ist nicht die Suche nach offenen Ports, sondern die Versionsnummern der installierten Serverdienste (Deamons). Durch die Versionsnummer lässt sich schnell bestimmen, ob der Dienst für eine bekannte Schwachstelle anfällig ist oder ob es sich um eine aktuelle, als „fehlerfrei“ zu bezeichnende Version handelt. Ist eine Schwachstelle gefunden kann die Suche nach dem dazugehörigen Exploit beginnen.

Im Grunde funktionieren Bannserscan und Portscan gleich. Beim Portscan wird die Verbindung spätestens nach dem Drei-Wege-Handshake abgebrochen. Beim Bannerscan dagegen wird noch der Willkommensbanner des Serverdienstes abgewartet, bzw. durch Eingabe von speziellen Zeichenfolgen- und Befehlen (z.B. GET bei http) empfangen. Dem Banner lassen sich oftmals viele interessante Informationen, wie z.B. Versionsnummer und Betriebssystem entnehmen.

Da Bannerscans einen vollen TCP-Connect benötigen, sind sie leicht zu entdecken und hinterlassen Spuren in den Logs. Ausserdem ist die Geschwindigkeit nicht sehr hoch, da der Banner erst abgewartet werden muss.

Nicht alle Dienste geben einen Willkommensbanner aus. Banner finden sich meistens bei Standarddiensten, wie FTP (Port 21), SSH (Port 22), Telnet (Port 23), SMTP (Port 25), und POP3 (Port 110).

Bannerscans lassen sich durch Manipulation des Banners abwehren. Man ersetzt den Originalbanner durch eigene, fiktive oder falsche Angaben. Am effektivsten ist die Entfernung der Versionsnummer sowie des Namens des Serverdienstes. So wissen Angreifer nicht, welche Software läuft und erhalten somit keine wertvollen Informationen für das weitere Vorgehen. Um den Banner zu ändern muss der Quellcode der Software geändert werden.

Beispiel:

Originalbanner: 220 ProFTPD 1.2.4a Server (FTP_Server) [serv1.universe.com]

Geänderter Banner: 220 FTP Server (FTP_Server) [serv1.universe.com]

[...]

---

^[1] http://www.isc.org

^[2] Vgl. Internet Software Consortium - Internet Domain Survey
http://www.isc.org/ds (Zugriff am 03.07.2003)

^[3] http://www.idc.com

^[4] Vgl. ZDNet.de - IT-Markt: Welchen Prognosen soll man glauben? http://techupdate.zdnet.de/story/0,,t419-s2132698,00.html (Zugriff am 02.07.2003)

^[5] Vgl. Heise Newsticker - Sicherheit im Internet: Weniger Angriffe, mehr Schwachstellen
http://www.heise.de/newsticker/data/anw-04.02.03-004 (Zugriff: 22.05.2003)

^[6] Vgl. Heise Newsticker - Verirrt in Microsofts Patch-Dschungel
http://www.heise.de/newsticker/data/pab-07.02.03-000 (Zugriff: 12.05.2003)

^[7] Vgl. Heise Newsticker - SQLSlammer: Millionenschaden durch lahm gelegte Netze
http://www.heise.de/newsticker/data/pab-27.01.03-000 (Zugriff: 01.07.2003)

^[8] Vgl. Heise Newsticker - Datenschutz im Internet - Wunsch und Wirklichkeit
http://www.heise.de/newsticker/data/axv-21.08.00-001 (Zugriff: 11.06.2003)

^[9] Vgl. Manhart 1999, S.12f.

^[10] Vgl. Fuhrberg 2000, S.9f.

^[11] Request for Comments 791 - http://www .faqs.org/rfcs/rfc791.html

^[12] Vgl. Fuhrberg 2000, S.11ff.

^[13] http://www.denic.de

^[14] Request for Comments 950 - http://www .faqs.org/rfcs/rfc950.html

^[15] Request for Comments 1631 - http://www .faqs.org/rfcs/rfc1631.html

^[16] Vgl. Fuhrberg 2000, S.145

^[17] Request for Comments 792 - http://www .faqs.org/rfcs/rfc792.html

^[18] Vgl. Fuhrberg 2000, S.145

^[19] Vgl. Ziegler 1999, S.75f

^[20] Vgl. Fuhrberg 2000, S.18

^[21] Request for Comments 768 - http://www .faqs.org/rfcs/rfc768.html

^[22] Vgl. Fuhrberg 2000, S.146

^[23] Vgl. Fuhrberg 2000, S.146

^[24] Vgl. Fuhrberg 2000, S.19

^[25] Vgl. Scott 1999, S.7

^[26] Vgl. Vosseberg 2002, S.248

^[27] Vgl. Mack 2000, S.4

^[28] Aus dem englischen: promiscuous - sexuell ausschweifend leben; häufig den Partner wechselnd

^[29] Vgl. Vosseberg 2002, S.250

^[30] Vgl. Anonymous 1999-2, S.217

^[31] Vgl. Russel 2002, S.371

^[32] http://www.cultdeadcow.com/~dildog/BUTTSniffer

^[33] http://www.ethereal.com

^[34] http://gtk.org

^[35] http://www.tcpdump.org

^[36] http://windump.polito.it

^[37] Vgl. Vosseberg 2002, S.204

^[38] Vgl. http://www.speeddoesmatter.ch/showdocument.php3 (Zugriff am 23.06.2003)

^[39] Vgl. Kurtz 2001, S.73

^[40] http://koeln.ccc.de/c4/portscan-policy.html

^[41] Vgl. Jones 2003, S.137f.

^[42] Vgl. Request for Comments 793 – http://www.faqs.org/rfcs/rfc793.html

^[43] Vgl. Rodrigues 2001, S.11

^[44] Vgl. Anthraxx 2000

^[45] Vgl. Jones 2003, S.138

^[46] Vgl. Anthraxx 2000

^[47] Vgl. Kurtz 2001, S.75

^[48] Vgl. Anthraxx 2000

^[49] Vgl. Fyodor 0002

^[50] Anmerkung des Verfassers: RFC 1812 rät zum Limitieren der ICMP-Meldungen.

^[51] Vgl. Möller, Klaus. Scan-Techniken - Ein Überblick, S.11

^[52] Vgl. Fyodor.0002

^[53] Vgl. Vosseberg 2002, S.207f.

^[54] Vgl. Request for Comments 1413 – http://www.faqs.org/rfcs/rfc1413.html (Zugriff am 12.06.2003)

^[55] Vgl. Kurtz 2001, S.81

^[56] Vgl. Jones 2003, S.136f.

^[57] Vgl. Request for Comments 959 - http://www .faqs.org/rfcs/rfc959.html (Zugriff am 12.06.2003)

^[58] Anm. d. Verfassers: Es gibt auch noch den passiven Transfer, bei dem der Client beide Verbindungen aufbauen kann. Dies verhindert Probleme, die sonst durch Firewalls und NAT entstehen können.

^[59] Vgl. Fyodor 0002

^[60] Vgl. Jones 2003, S.142