Methoden zur Unterbindung einer Kommunikation zwischen zwei
Werbung
Lehrstuhl für Datenverarbeitung Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber Studienarbeit 282 Methoden zur Unterbindung einer Kommunikation zwischen zwei Rechnern Für die Sicherheit ist der Status des aktuellen Netzwerkverkehrs von Interesse. Eine Absicherung findet durch eine Firewall statt, indem der Datenstrom sofort restriktiv gesperrt werden kann. Eine interne Kommunikation innerhalb eines Sub-Netzes kann hingegen durch eine Firewall nicht unterbunden werden. Das Ziel ist es nun, Methoden zur Unterbindung einer Kommunikation zwischen zwei Rechnern zu entwickeln. Hierfür sind zunächst die möglichen Mechanismen zur prinzipiellen Trennung und Blockierung von Verbindungen auf TCP- und UDP-Basis zu untersuchen. Die Realisierung soll mittels eines geeigneten Mechanismus erfolgen, wobei die Möglichkeit bestehen soll, die Kommunikation auf bestimmten Ports zu unterbinden. Die Software soll ein GUI Interface zur Steuerung und zum Sperren der einzelnen Kommunikationkanäle erhalten. Zum Testen der Software sollen geeignete Testprogramme entwickelt und die einzelnen Testdurchläufe entsprechend protokolliert werden. Die Software ist mit MS Visual C++ unter MS Windows NT zu realisieren. Alle Entwicklungsschritte sind zudem projektbegleitend zu dokumentieren. (Prof. Dr.-Ing. Wolfgang Weber) Bearbeiter: Matrikel-Nummer: Betreuer: Bearbeitungszeitraum: cand.-Ing. Oliver Thomas Bethge 108 093 215 210 Dipl.-Ing. Thomas Droste WS 1999/2000 Inhalt Inhalt 1 2 3 4 5 6 7 Einleitung ................................................................................................................ 3 Mögliche Angriffsmethoden ................................................................................... 5 2.1 Datenstrom-Mitschnitt ........................................................................................ 5 2.2 Trojanische Pferde .............................................................................................. 6 2.3 Winnuke Angriffe ............................................................................................... 6 2.4 Teardrop Angriffe ............................................................................................... 7 2.5 Juggernaut Angriffe ............................................................................................ 8 Netzwerkprotokolle................................................................................................. 9 3.1 ISO/OSI-Modell .................................................................................................. 9 3.1.1 Funktionen der einzelnen Schichten.......................................................... 10 3.2 TCP/IP-Modell .................................................................................................. 11 3.3 Transmission Control Protocol ......................................................................... 12 3.3.1 Funktionsumfang ....................................................................................... 12 3.3.2 Header........................................................................................................ 13 3.4 User Datagram Protocol .................................................................................... 16 3.4.1 Funktionsumfang ....................................................................................... 16 3.4.2 Header........................................................................................................ 18 3.5 Vergleich zwischen TCP- und UDP-Verbindungen ......................................... 19 3.6 TCP-Zustandsdiagramm.................................................................................... 19 3.6.1 Verbindungsaufbau.................................................................................... 20 3.6.2 Verbindungsabbau ..................................................................................... 21 3.7 NetBEUI............................................................................................................ 22 3.7.1 Header........................................................................................................ 23 Problemstellung..................................................................................................... 24 Erkennung bestehender Verbindungen ................................................................. 25 Lösungsansatz ....................................................................................................... 28 6.1 Windows Sockets .............................................................................................. 28 6.2 Network Driver Interface .................................................................................. 29 6.3 Verbindungsübernahme .................................................................................... 30 Realisierung........................................................................................................... 32 7.1 Windows Sockets .............................................................................................. 32 7.1.1 ClosePort ................................................................................................... 32 7.1.2 ServiceScannner ........................................................................................ 33 7.1.3 ServiceServer ............................................................................................. 34 7.2 Network Driver Interface .................................................................................. 35 1 Inhalt 7.3 Verbindungsübernahme .................................................................................... 36 8 Zusammenfassung................................................................................................. 37 9 Ausblick ................................................................................................................ 38 10 Literatur................................................................................................................. 39 Anhang .......................................................................................................................... 43 2 Kapitel 1 Einleitung 1 Einleitung In der Zeit der modernen Informationsgesellschaft gewinnt die Netzwerksicherheit immer mehr an Bedeutung. Schäden durch mißbräuchliche Nutzung der Informationsressourcen können finanzielle Schäden und Image-Schäden von enormem Ausmaßen verursachen. Die vom Computer Emergency Response Team Coordination Center (CERT-CC) verzeichneten sicherheitsrelevanten Vorfälle steigen ständig. 1989 waren es weltweit weniger als 200, 1991 etwa 400, 1993 schon 1400 und 1994 sogar 2241 bekannte Fälle. Die Anzahl dieser sicherheitsrelevanten Vorfälle kann jedoch kein genaues Bild über den Verlauf geben, da viele Firmen Vorfälle erst gar nicht melden. Ein nicht abzuschätzender Teil sicherheitsrelevanter Vorfälle wird zudem von den Betroffenen erst gar nicht bemerkt. Zudem existiert keine Statistik, wie viele Vorfälle überhaupt entdeckt werden. Firmen bieten ihren Kunden Sicherheitstests ihrer Computernetze an. Dabei wird versucht, mit Erlaubnis der Computernetzbetreiber in die Netze einzudringen. Der Test wird dabei mit den gleichen Methoden und Werkzeugen vorgenommen, welche auch Hacker1 benutzten, dabei werden nur 4 Prozent der durchgeführten Eindringversuche überhaupt bemerkt. Zu einem sicheren System gehöhrt folglich nicht nur die Abschottung des Systems gegen unberechtigte Zugriffe, sondern ebenso Methoden um Eindringversuche festzustellen und zu unterbinden. In dieser Arbeit soll die Möglichkeit untersucht werden, eine Verbindung zwischen zwei Rechnern zu beenden (vgl. Abbildung 1-1). Rechner A Kommunikation Rechner B Rechner A Kommunikation Rechner B Abbildung 1-1: Unterbinden der Kommunikation zwischen zwei Rechnern 1 Hacker - Jemand der sich unberechtigt Zugriff zu Informationen verschafft. 3 Kapitel 1 Einleitung Dabei soll eine bestehende Verbindung zwischen zwei Rechnern, die von zwei verschiedenen Prozessen aufgebaut worden ist, durch einen dritten Prozeß abgebaut werden. Es handelt sich immer um die Interaktion zwischen zwei Rechnern, d.h. der Prozeß zum Beenden der Verbindung wird immer auf einem der beiden Rechner ausgeführt. Der gezielte Abbau einer Kommunikation ist nötig, um Angriffe auf einen Rechner abwenden zu können. Es ist notwendig verschiedene Vorgehensweisen zu behandeln, die als Ergebnis die Unterbrechung der Verbindung mit sich führen. Der Benutzer des Rechners steht dabei außen vor. 4 Kapitel 2 Mögliche Angriffsmethoden 2 Mögliche Angriffsmethoden In diesem Kapitel werden einige Angriffsmethoden exemplarisch erläutert, diese gilt es entsprechend zu erkennen und abzufangen. 2.1 Datenstrom-Mitschnitt Eine Angriffsmethode ist das Mitlesen des Datenstroms (vgl. Abbildung 2-1), welcher über ein Netzwerk übertragen wird. Mitlesen Angreifender Rechner Rechner A Datenstrom Rechner B Abbildung 2-1: Mitlesen des Datenstroms einer Verbindung Werden Daten unverschlüsselt übertragen, ist es möglich aus dem gewonnenen Informationen weitergehende Angriffsversuche einzuleiten. Bei der Nutzung von bestimmten Diensten, wie z.B. bei Zugriffen über Telnet2, FTP3 , POP4 und HTTP5, werden Paßwörter im Klartext übertragen. Durch den Mitschnitt des Datenstroms sind die Paßwörter für diese Dienste direkt im Klartext lesbar. Diese unverschlüsselten Dienste werden als gefährliche Dienste eingestuft, da sie die Datenübertragung unverschlüsselt durchführen. Sichere, verschlüsselte Dienste sind z.B. SSH6 und HTTPs7. 2 Telnet - Terminal Emulation 3 FTP - File Transfer Protocol 4 POP - Post Office Protokoll 5 HTTP - Hyper Text Transport Protocol 6 SSH - Secure Shell 7 HTTPs - Secure Hyper Text Transport Protocol 5 Kapitel 2 Mögliche Angriffsmethoden 2.2 Trojanische Pferde Trojanische Pferde8 werden über Wirt-Programme in Systeme eingeschleust. Der Benutzer installiert das Wirt-Programm und gleichzeitig das Trojanische Pferd selbst auf dem Rechner. Die Wirt-Programme könne z.B. per Email verschickt werden oder ein Benutzer lädt sie sich selbst aus dem Internet herunter. Das Wirt-Programm täuscht nützliche Anwendungen (Bildschirmschoner, Spiele, usw.) vor, verheimlichen aber ihren eigentlichen Sinn (vgl. Abbildung 2-2). Wirt-Programm Trojanisches Pferd Abbildung 2-2: Verkapselung eines Trojanischen Pferdes Die Trojanischen Pferde sammeln z.B. nach der Installation gezielt Daten auf dem Rechner. Die gewonnen Informationen gespeichert, bis sich eine geeignete Möglichkeit ergibt, sie zum Angreifer zu übertragen. Eine Übertragung zum Angreifer geschieht z.B. als Anhang an eine Email oder über eine neu aufgebaute Netzwerk-Verbindung. 2.3 Winnuke Angriffe Mittels eines „denial of service“-Angriffs wird versucht die Netzwerkschnittstelle eines Rechners mit überhöhtem Netzwerkverkehr zu blockieren. Die unter dem Namen Winnunke bekannt gewordenen Programme können dadurch das Betriebssystem eines Rechner zum Absturz bringen. Betroffen sind verschiedene Betriebsysteme, wie z.B. Microsoft Windows 95 und Windows NT. Diese Betriebssysteme besitzen eine fehlerhafte Implementation der Netzwerkschnittstelle, welche von Winnuke Programmen ausgenutzt wird. 8 Trojanisches Pferd – analog zur gr. Geschichte um den Kampf um Troja 6 Kapitel 2 Mögliche Angriffsmethoden Angreifer OOB Daten Zielrechner Abbildung 2-3: Winnuke Angriff Durch Senden von OOB9-Datenpaketen (vgl. Abbildung 2-3) an die Netzwerkschnittstelle werden unvorhersehbare Ereignisse ausgelöst, wodurch ein Rechner zum Absturz gebracht werden kann. Ein Angriff auf z.B. ein Microsoft Windows 95 oder Windows NT-System erfolgt durch senden der Daten an den Zielport 139 (NetBEUI). 2.4 Teardrop Angriffe Die unter dem Namen Teardrop bekannten Programme können die Betriebssysteme verschiedener Plattformen zum Absturz bringen. Es handelt sich um einen „denial of service“-Angriff. Betroffen sind u.a. die Betriebssysteme der Firma Microsoft und das Betriebssystem Linux. Die Teardrop Programme nutzen einen Fehler bei der TCP/IPProtokoll-Implementierung der Betriebssysteme aus. Es werden überlappende ICMP10/IP11 Fragmente (vgl. Abbildung 2-4) an die Netzwerkschnittstelle eines Rechners gesendet. Dadurch erreicht die Netzwerkschnittstellenimplementierung der Betriebssysteme einen nicht definierten Zustand und kann das Betriebssystem zum Absturz bringen. Angreifer überlappende ICMP/IP Fragmente Zeilrechner Abbildung 2-4: Teardrop Angriff 9 OOB - Out of Band 10 ICMP – Internet Control Message Protocol 11 IP – Internet Protocol 7 Kapitel 2 Mögliche Angriffsmethoden 2.5 Juggernaut Angriffe Durch einen Juggernaut12 Angriff wird das Übernehmen einer existierenden Verbindung beschrieben. Dafür schaltet sich das Programm Juggernaut in die bestehende Kommunikation zwischen zwei Rechnern ein (vgl. Abbildung 2-3). Übernehmen Angriffsrechner Rechner A Kommunikation Trennen der Verbindung Rechner B Abbildung 2-5: Funktionsweise von Juggernaut Diese Angriffe funktionieren unabhänig von dem auf dem angegriffen Rechner verwendeten Betriebssystem. Anfällig von dieser Angriffsmethode sind besonders die Telnet- und FTP-Verbindungen. Eine zwischen den Rechnern A und B bestehende Verbindung wird z.B. vom Angreifer zum Rechner B abgebaut. Dem Rechner A wird vorgetäuscht der ursprüngliche Kommunikationspartner, vormals Rechner B, zu sein. Durch das Übernehmen der Verbindung ist es möglich, gezielt Informationen von dem Rechner A auszuspähen. Wird z.B. eine Telnet Verbindung übernommen, hat der ursprüngliche Kommunikationspartner sich bereits am Rechner A mit Namen und Paßwort angemeldet. Der Angreifer hat mit Übernahme der Verbindung so die Sicherheitsmechanismen des Dienstes umgangen und kann ungehindert die gewünschten Informationen ausspähen. 12 Juggernaut - Moloch 8 Kapitel 3 Netzwerkprotokolle 3 Netzwerkprotokolle 3.1 ISO/OSI-Modell Das ISO13/OSI14-Modell ist 1978 entworfen worden, um eine Kommunikation zwischen verschiedenen Systemen und unterschiedlichen Herstellern mit ihren eigenen Netzwerkprotokollen zu definieren. In Abbildung 3-1 ist das ISO/OSI-Modell dargestellt. Schicht 7 Anwendungsschicht Schicht 6 Darstellungsschicht Schicht 5 Sitzungsschicht Schicht 4 Transportschicht Schicht 3 Netzwerkschicht Schicht 2 Sicherungsschicht Schicht 1 Physikalische Schicht Abbildung 3-1: Schichten des ISO/OSI-Modells Es gliedert sich in sieben Schichten, welche jeweils unterschiedliche Funktionen besitzen. Die Kommunikation geschieht schichtweise. Jede Schicht überträgt immer nur Daten zur nächst höheren und nächst unteren Schicht. 13 ISO - International Standart Organisation 14 OSI - Open Systems Interconnection 9 Kapitel 3 Netzwerkprotokolle 3.1.1 Funktionen der einzelnen Schichten • Schicht 7, Anwendungsschicht (Application Layer): Diese Schicht ist das Bindeglied zwischen den Netzwerkfunktionen und der eigentlichen Anwendung. Die Anwendung kommuniziert nur mit der Anwendungsschicht. Alle anderen Schichten bleiben der Anwendung verborgen. • Schicht 6, Darstellungsschicht (Presentation Layer): In der Darstellungsschicht werden die Darstellungsformate der übertragenen Nachrichten betrachtet. Sie übersetzt verschiedene Codes und Formate so, daß eine gemeinsam bekannte Darstellungsart zwischen den Systemen zur Verfügung steht. • Schicht 5, Sitzungsschicht (Session Layer): Die Sitzungsschicht ist die unterste Schicht des Anwendungssystems15. Ihre Aufgabe ist das Aufrechterhalten der Verbindungen. In dieser Schicht können logische Benutzer gleichzeitig über mehrere Verbindungen kommunizieren. Bricht eine Verbindung zusammen, so baut diese Schicht sie wieder auf. • Schicht 4, Transportschicht (Transport Layer): Diese Schicht ist die oberste Schicht des Transportsystems16. Die Transportschicht stellt den höheren Schichten ein Kommunikationssystem zur Verfügung. Die höheren Schichten sehen nur die Transportschicht. Diese baut logische Verbindungen zwischen Rechnern auf. Diese werden durch Transportadressen gekennzeichnet. • Schicht 3, Netzwerkschicht (Network Layer): Die Aufgabe dieser Schicht ist der Austausch von Paketen von nicht direkt miteinander verbundenen Rechner-Stationen. Hier wird das Routing, d.h. die Wegwahl, bestimmt und es werden die Sicherungsschicht-Verbindungen gemultiplext. Die Pakete die zu Sicherungsschicht gegeben werden, werden auf eine einheitliche Länge geschnitten (Sequenzbildung). Es wird eine Flußkontrolle und Fehlerbehandlung durchgeführt. • Schicht 2, Sicherungsschicht (Data Link Layer): In dieser Schicht werden Verbindungen aufgebaut und beendet. Informationen werden in Datenpakete zerteilt. Die Schicht führt mittels Prüfsummen eine Erkennung von Übertragungsfehlern durch und steuert die Reihenfolge der Datenpakete. 15 Anwendungssystem - Das Anwendungssystem beinhaltet die Schichten 5-7 im ISO/OSI Modell 16 Transportsystem - Das Transportsystem beinhaltet die Schichten 1-4 im ISO/OSI Modell 10 Kapitel 3 Netzwerkprotokolle • Schicht 1, Physikalische Übertragungsschicht (Physical Layer): Die Übertragungsschicht ermöglicht die physikalische Kommunikation. Die Datenpakete werden auf die Leitung (z.B. Kupfer, Glasfaser, Luftschnittstelle) umgesetzt. Die Realisierung der Schicht hängt von der gewählten Netzwerktopologie ab. 3.2 TCP/IP-Modell Das TCP17/IP- Modell ist aufgrund seiner großen Verbereitung ein De-facto-Standard. Es läßt sich komplett in das ISO/OSI-Modell einbinden (vgl. Abbildung 3-2), das Internet Protokoll deckt dabei die Schicht 3 und das Transmission Control Protocol die Schicht 4 im ISO/OSI-Modell ab. ISO/OSI-Modell TCP/IP-Modell Anwendungen Anwendungsschicht Standart: Erweiterte Anwendunge: Systemmeldungen: NFS Darstellungsschicht FTP Telnet Drucker Server Fehlerbehandlung SMTP Sitzungsschicht Transportschicht Trnsmission Control Protocol (TCP) User Datagram Delivery Protocol (UDP) Netzwerkschicht Internet Protocol (IP) Addres Resolution Protocol (ARP) Internet Control Message Protocol (ICMP) Sicherungsschicht Übertragungsmedium Physikalische Schicht Abbildung 3-2: Einordung des TCP/IP-Modells in das ISO/OSI-Modell 17 TCP - Transmission Control Protocol 11 Kapitel 3 Netzwerkprotokolle 3.3 Transmission Control Protocol Das Transmission Control Protocol (TCP) ist ein verbindungsorientiertes Punkt-zuPunkt-Protokoll. Es garantiert eine folgerichtige und zuverlässige Übertragung. Die Sender- und Empfängeradressen werden weltweit nur einmal vergeben und mittels vier durch Punkte getrennte Zahlentupel angegeben. Jede dieser Zahlentupel kann einen maximalen dezimalen Wert von 255 annehmen. Eine eindeutige Netzwerkadresse setzt sich aus der Sender- oder Empfängeradresse und einer Portnummer (vgl. Anhang-B) zusammen. Es wird zwischen reservierten und nicht reservierten Ports unterschieden. Reservierte Ports liegen unterhalb von 1024, alle darüber liegenden werden als die nicht reservierten Ports bezeichnet. Eine Verbindung zwischen zwei Rechnern wird von einem nicht reservierten Port zu einem reservierten Port aufgebaut. Ein reservierter Port übernimmt eine bestimmte Aufgabe. So steht z.B. der Port Nummer 23 für eine Telnet-Verbindung, oder Port Nummer 25 für eine FTP-Verbindung. Da Übertragung paketweise erfolgt, muß der Protokollstack des Empfängers die erhaltenen Pakete der Reihe nach sortieren, um die Information zu erhalten. Pakete die den Empfänger nicht erreichen müssen erneut gesendet werden. 3.3.1 Funktionsumfang Das Transmission Control Protocol besitzt mehrere Funktionen: • End-to-End-Kontrolle: Um eine korrekte Datenübertragung zu gewährleisten, existiert beim TCP ein Quittierungsmechanismus. Dabei wird jedes beim Empfänger ankommende Paket bestätigt. Erreicht ein Paket den Empfänger nicht, so wird es erneut vom Sender geschickt. • Verbindungsmanagement: Das Verbindungsmanagement des TCP besteht aus drei Teilen: dem gesicherten Aufbau, dem Aufrechterhalten während der gesamten Kommunikation zwischen Sender und Empfänger sowie dem gesicherten Abbau der Verbindung. • Flußkontrolle: Die Flußkontrolle besteht aus der fortlaufenden Numerierung der Datenpakete, der Bestätigung der empfangenen Daten durch dem Empfänger und einem Fenstermechanismus. Mit der Flußkontrolle wird ein Datenverlust und der Überlauf von Datenpuffern verhindert. • Multiplexen von Verbindungen: Damit mehrere Verbindungen gleichzeitig über das TCP aufgebaut werden können, d.h. damit mehrere Anwendungen gleichzeitig auf das TCP zugreifen können, werden den einzelnen Anwendungen Ports zugeordnet. 12 Kapitel 3 Netzwerkprotokolle • Zeitüberwachung von Verbindungen: Es findet beim TCP eine Zeitüberwachung statt. Werden Datenpakete innerhalb eines zeitlich definierten Zeitraums nicht quittiert, so werden diese vom Sender erneut gesendet. • Spezialfunktionen: Beim TCP existieren zwei spezielle Funktionen Urgent Data und der PushMechanismus. Mit diesen Funktionen können Vorrang-Daten gekennzeichnet werden, die bevorzugt übertragen werden. • Fehlerbehandlung: Das TCP führt eine Fehlerkontrolle durch. Entsteht ein Fehler, so wird dies der nächst niedrigeren Schicht mitgeteilt, und das verlorengegangene Paket wird erneut angefordert. 3.3.2 Header In Abbildung 3-3 ist der TCP Header dargestellt. 1 Abstand 4 8 Sendeport Reserviert 12 16 20 Sequenznummer Quittungsnummer Kontrollbits Prüfsumme 24 28 Empfängerport 32 Fenstergröße Urgent-Zeiger Optionen Füllzeichen Abbildung 3-3: TCP Header • Sendeport: Das Feld hat eine Länge von 16 Bit und zeigt die Absenderadresse eines Prozesses an. Durch den Sendeport wird angegeben, von welchem Dienst eines höheren Protokolls Daten übermittelt worden sind. Der Sendeport und die IP-Adresse bilden zusammen einen Socket. Wird eine Verbindung über einen Socket aufgebaut, so kommunizieren die Kommunikationspartner beide während der gesamten Zeit über die gleichen Ports. Diese Ports bleiben aber nur für die Dauer einer Verbindung identisch. • Empfängerport: Das Feld ist ein 16 Bit Datenwort und zeigt die Zieladresse auf dem Zielrechner an. Eine Verbindung wird eindeutig aus der IP-Adresse des Senders und Empfängers sowie dem Sendeport und Empfängerport gebildet. 13 Kapitel 3 Netzwerkprotokolle • Sequenznummer: Das Feld besteht aus 32 Bit. Jedem einzelnen Datenpaket bei einer TCPVerbindung wird eine Sequenznummer zugeordnet. Im Laufe der Kommunikation wird die Sequenznummer mit jedem Datenpaket um eins erhöht. • Quittungsnummer: Die Quittungsnummer (Acknowledge-Nummer) hat eine Länge von 32 Bit und ist ein Mechanismus zur Flußkontrolle. Jedes Paket wird bei der Übertragung fortlaufend numeriert (Sequenznummer). Es wird eine Quittungsnummer erzeugt, die den Empfang des Paketes bestätigt und so gleichzeitig anzeigt, welches Paket als nächstes erwartet wird. • Abstand: Der Abstand hat einen Umfang von 4 Bit und gibt die Anzahl der 32-Bit-Datenworte im TCP Header an. Das Abstandsfeld ist wegen der veränderlichen Größe des Optionenfelds notwendig. • Reserviert: Das Feld ist 6 Bit lang. Es ist für zukünftige Einstellungen reserviert und wird auf „0“ vordefiniert. • Kontrollbits: In diesem Feld (vgl. Abbildung 3-4) sind eine Reihe von Flags, die zum Aufbau, Abbau und zur Aufrechterhaltung einer Verbindung dienen. 1 URG 2 ACK 3 PSH 4 RST 5 SYN 6 FIN Abbildung 3-4: TCP Kontrollbits • Urgent-Zeiger-Bit (URG): Ist das Urgent-Zeiger-Bit-Feld auf „1“ gesetzt so zeigt es an, daß das UrgentZeiger-Feld im TCP Header beachtet werden muß. Dieses dient zur Markierung von Vorrangdaten. • Acknowledge-Bit (ACK): Ist das Acknowledge-Bit auf „1“ gesetzt, so zeigt es an, daß das AcknoledgeFeld im TCP Header zu beachten ist. Das Acknowledge-Feld bestätigt empfangene Daten. • Push-Bit (PSH): Das Push-Bit zeigt, auf „1“ gesetzt, an, daß die empfangenen Daten direkt an die nächsthöhere Schicht weitergeleitet werden sollen. Diese Funktion ist auch als Push-Mechanismus bekannt. 14 Kapitel 3 • • • • Netzwerkprotokolle • Reset-Bit (RST): Das Reset-Bit zeigt, auf „1“ gesetzt, an, daß der eine Verbindungspartner die Verbindung beenden will. • Synchronisation-Bit (SYN): Mit dem auf „1“ gesetzten Synchronisations-Bit teilt der Sender dem Empfänger mit, daß eine Verbindung aufgebaut werden soll. • Final-Bit (FIN): Ist das Final-Bit auf „1“ gesetzt, so ist die Verbindung endgültig beendet und der Sender überträgt keine Pakete mehr von höheren Protokollen. Fenstergröße: Das Feld hat einen Umfang von 16 Bit und dient zur Flußkontrolle zwischen dem Sender und dem Empfänger. Der Fenstermechanismus teilt dem Sender mit, wie groß der verbleibende Puffer beim Empfänger ist. So wird verhindert, daß Pakete unbestätigt versendet werden und der Empfänger-Puffer überläuft. Prüfsumme: Die Prüfsumme ist ein Datenfeld von 16 Bit Länge und wird aus dem TCP Header und einem 96 Bit Pseudo-Header gebildet. Sie besteht aus dem 16-Bit-Einerkomplement der Einerkomplementsumme aller 16-Bit-Wörter im Header und in den Daten. Folgende Teile sind im Pseudo Header vorhanden: • IP-Sendeadresse (32 Bit) • IP-Empfängeradresse (32 Bit) • Leerfeld (8 Bit) • Protokollindentifikator (8 Bit) • Information über die Länge des TCP Segmentes (16 Bit) Urgent-Zeiger: Die Feldlänge des Urgent-Zeiger beträgt 16 Bit. Dringliche Daten werden mit dem Urgent-Zeiger(URG)-Bit und dem Urgent-Zeiger versehen und stehen immer am Anfang eines TCP-Paketes. Der Urgent-Zeiger zeigt die Position des letzten dringenden Pakets an. Wird zu der Sequenznummer der Urgent-Zieger addiert, ergibt sich die Nummer des letzten dringenden Pakets. Optionen: Das Feld hat eine veränderliche Länge. In dem Optionen Feld ist es möglich Service-Optionen zu definieren. Die TCP Optionen setzen sich aus einem Oktett Optionsart und optional einen Oktett Optionslänge und Optionsdaten zusammen. Folgende TCP Optionen existieren bis jetzt: • End of Option List: Für diese Option ist die Optionsart auf „0“ festgelegt worden. Sie zeigt das Ende aller zu übertragenden Optionen an und hat eine Länge von 8 Bit. 15 Kapitel 3 Netzwerkprotokolle • No Option List: Für diese Option wurde die Optionsart „1“ festgelegt. Sie dient zur Trennung zwischen zwei Optionen und besitzt eine Länge von 8 Bit. • Maximum Segment Size: Die Option hat die Optionsart „2“. Durch sie wird die maximale Segmentlänge zwischen den Kommunikationspartnern festgelegt. Die Option wird bei einem Verbindungsaufbau benutzt und hat eine Länge von 16 Bit. • Füllzeichen: Das Feld Füllzeichen stellt sicher, daß die Länge des TCP Headers immer ein Vielfaches von 32 Bit beträgt. Ist der Header zu kurz so werden in diesem Feld Füllzeichen eingefügt. Die Option hat einen Umfang von 8 bis 24 Bit. 3.4 User Datagram Protocol The Department of Defense’s User Datagram Protocol (UDP) ist ein verbindungsloses Protokoll. Es ist in RFC18 768 definiert. Das UDP hat im Gegensatz zum TCP einen kleineren Daten-Overhead für die Adressierung. Es ist deshalb schneller und wird oft zur Übermittlung großer Datenmengen eingesetzt. 3.4.1 Funktionsumfang Das UDP übernimmt mehrere Funktionen: • Transportdienst: Der wesentliche Unterschied zwischen dem TCP und dem UDP liegt in der Verbindungsüberwachung. Im Gegensatz zum TCP überprüft das UDP nicht die korrekte Übergabe der Daten an den Empfänger, d.h. die gesendeten Pakete werden vom Empfänger nicht quittiert. Erreichen bei der Übertragung Pakete den Empfänger nicht, werden diese nicht wie beim TCP noch einmal geschickt. Beim UDP muß die über dem UDP liegende Applikationsschicht die Aufgabe der Transportkontrolle übernehmen. • Verbindungs-Management: Das UDP baut keine aktive Verbindung zwischen Sender und Empfänger auf. Es werden, wie bei dem darunterliegenden IP-Protokoll, die einzelnen Pakete völlig unabhängig voneinander versendet. Die Applikationsschicht steuert hierbei die Daten zwischen Sender und Empfänger. 18 RFC - Request for Comment 16 Kapitel 3 Netzwerkprotokolle • Flußkontrolle: Es existiert beim UDP keine Flußkontrolle. Es gibt keine Sequenz- und Acknowledge-Nummern wie beim TCP. Die höheren Schichten übernehmen die Flußkontrolle. • Multiplexen von Verbindungen: Damit mehrere Verbindungen gleichzeitig über das UDP aufgebaut werden können, d.h. damit mehrere Anwendungen gleichzeitig auf das UDP zugreifen können, werden den einzelnen Anwendungen Ports zugeordnet. Eine Verbindung ist immer durch die IP-Adresse des Empfängers und die Portnummer beim Empfänger gekennzeichnet. Das UDP wird insbesondere für folgende Anwendungen benutzt: • Name Service Protokoll (EIN 116) • Trivial File Transfer Protokoll (TFTP) • Network File System (NFS) • Boot Protokoll (BootP) • Simple Network Management Protokoll (SNMP) • Domain Name Service Protokoll (DNS) • Zeitüberwachung der Verbindung: Eine Zeitüberwachung findet beim UDP im Gegensatz zum TCP nicht statt, d.h. Datenübertragung wird nicht zeitlich geprüft. Die höheren Schichten müssen die Zeitüberwachung abdecken. • Spezialfunktionen: Die vom TCP her bekannten speziellen Funktionen wie z.B. Urgent Data werden vom UDP nicht unterstützt. Hier ist es wieder Aufgabe der höheren Schichten, diese Funktionen zu erfüllen, wenn sie benötigt werden. • Fehlerbehandlung: Je nach Implementation des UDP in den verschiedenen Betriebssystemen wird eine minimale Fehlerkontrolle durchgeführt. Entstehen Fehler, so kann das UDP diese an die höhere Schicht mitteilen. Ist keine Fehlerkontrolle implementiert, so ist es Aufgabe der höheren Schicht, diese zu übernehmen. 17 Kapitel 3 Netzwerkprotokolle 3.4.2 Header Der UDP Header besteht aus dem Sendeport, dem Empfängerport, der Paketlänge und der Prüfsumme (vgl. Abbildung 3-5). 1 4 8 Sendeport Paketlänge 12 16 20 24 28 Empfängerport Prüfsumme 32 Abbildung 3-5: UDP Header • Sendeport: Der Sendeport ist ein optionales Feld mit einer Länge von 16 Bit. Es dient dazu, daß bei Antworten die Sendeport-Adresse direkt angesprochen werden kann. Setzt ein Sender keinen Wert für dieses Feld, so wird es auf „0“ gesetzt. • Empfängerport: Der Empfängerport ist ein Feld mit einer Länge von 16 Bit. Dieser stellt den Port des Empfängers an den der Sender das Paket schickt dar. • Paketlänge: Das Feld hat eine Länge von 16 Bit und zeigt die gesamte Länge des UDP-Pakets inklusive Headers an. Ein UDP-Paket hat immer eine minimale Länge von 8 Oktetten, dies entspricht genau der Länge des Headers. • Prüfsumme: Die Prüfsumme ist ein optionales Feld von 16 Bit Umfang. Nicht jede Implementation des UDP berücksichtigt diese Feld. Wird keine Prüfsumme berechnet, so wird das Feld automatisch auf „0“ gesetzt. Die Prüfsumme wird aus dem UDP-Header und einem 96 Bit Pseudo-Header gebildet. Sie setzt sich aus dem 16 Bit Einerkomplement der Einerkomplementsumme aller 16 Bit Wörter im Header und Daten zusammen. Folgende Teile werden im Pseudoheader zusammen gefaßt: • IP Sende Adresse (32 Bit) • IP Empfänger Adresse (32 Bit) • Leerfeld (8 Bit) • Protokollindentifikator (8 Bit) • Informationen über die Länge des UDP Segmentes (16 Bit) 18 Kapitel 3 Netzwerkprotokolle 3.5 Vergleich zwischen TCP- und UDP-Verbindungen Die Tabelle 3-1 zeigt die wesentlichen Unterschiede zwischen dem TCP und dem UDP. Es wird deutlich, daß das UDP besser zur schnellen Übertragung von großen Datenmengen geeignet ist, wogegen des TCP eine gesicherte Übertragung gewährleisten kann. Funktion Ende-zu-Ende-Kontrolle Zeitüberwachung der Verbindung Spezialfunktionen (z. B. „Urgent Data“) Flußkontrolle über das Netz hinweg Zuverlässige Datenübertragung Geschwindigkeit Erkennung von Paketduplikaten Reihenfolgerichtige Übertragung Verbindung wird aufgebaut Multiplexen von Verbindungen TCP ja ja ja ja ja mittel ja ja ja ja UDP nein nein nein nein nein hoch nein nein nein ja Tabelle 3-1: Vergleich von TCP- und UDP-Protokoll 3.6 TCP-Zustandsdiagramm In Abbildung 3-6 sind die möglichen TCP-Zustände mit ihren Übergängen dargestellt. Segmentaustausch Closed Passive Open Passive Open Aktive Open Open Fehler Active Open Closing Established Passive Open Send Abbildung 3-6: Vereinfachtes TCP Zustandsdiagramm 19 Kapitel 3 Netzwerkprotokolle Ein Service kann dabei folgende Zustände besitzen: • Closed: Es besteht keine Verbindung. • Passive Open: Der Port nimmt durch Passiv Open initialisierte Verbindungsaufrufe entgegen. Es wird auf den Verbindungsaufbau gewartet. Dabei werden Vorrangdaten und Sicherheitsstufen berücksichtigt. • Active Open: Der Port nimmt eine durch Active Open initialisierte Verbindungsaufrufe entgegen. Es wird ein aktiver Verbindungsaufbau gestartet. Dabei werden Vorrangdaten und Sicherheitsstufen berücksichtigt. • Established: Die Verbindung ist aufgebaut. • Closing: Die Verbindung wird durch den Nutzer kontrolliert abgebaut. Eine Verbindung kann über Active Open oder Passive Open initialisiert werden. Dieser Zustand geht in den Established-Zustand über, d.h. die Verbindung ist aufgebaut und Daten können gesendet werden. Sollen keine Daten mehr gesendet werden, so wird der Zustand Closing angenommen. Die Verbindung wird kontrolliert abgebaut. Ist die Verbindung abgebaut, ist der Zustand Closed erreicht und eine neue Verbindung kann über Active Open oder Passive Open aufgebaut werden. Für den Verbindungsaufbau können folgende Serviceroutinen genutzt werden: • Active Open • Active Open mit Daten • voll spezifiziertes Passive Open • unspezifiziertes Passive Open Eine TCP-Verbindung wird immer von einem Port auf dem Quellrechner zu dem Port auf dem Zielrechner aufgebaut. Diese Verbindung kann aktiv oder passiv aufgebaut werden. Wird die Verbindung passiv aufgebaut, wartet der Rechner auf den Verbindungsaufbau über einen bestimmten Port. Der passive Verbindungsaufbau kann voll spezifiziert, nur zu einem bestimmten Port, oder unspezifiziert, zu einem beliebigen Port, geschehen. Beim aktiven Verbindungsaufbau baut der Quellrechner eine Verbindung zu einem Empfängerrechner auf. Der Empfängerrechner ist dabei im Passive Open-Modus, oder er baut eine Active Open-Verbindung zum gleichen Port auf. 3.6.1 Verbindungsaufbau Der Verbindungsaufbau ist in Abbildung 3-7 dargestellt. 20 Kapitel 3 Netzwerkprotokolle Active Open SYN senden Passive Open Closed Close Close SYN gesendet Listen SYN empfangen Established SYN empfangen SYN gesendet Abbildung 3-7: Verbindungsaufbau Eine Verbindung wird immer von dem Zustand Closed aus aufgebaut. Sie kann mit Active Open oder Passive Open initialisiert werden. Wird die Verbindung mit Passive Open initialisiert, wird der Zustand Listen erreicht. Beim aktiven Aufbau wird das SYN-Zeichen gesendet und der SYN-Zustand wird angenommen. Dieser Zustand wird so lange aufrecht erhalten, bis ein Timer abgelaufen ist. Danach wird automatisch wieder der Zustand Closed angenommen. Wenn das SYN-Zeichen hingegen vom Empfänger positiv beantwortet wird, wechselt der Zustand zu Established. Der Empfänger, der mit Passive Open im Listen-Zustand war, erreicht den Established-Zustand. Bekommt ein Empfänger kein SYN-Zeichen gesendet, kann er wieder in den ClosedModus übergehen. Im Established-Zustand können die Daten übertragen werden. 3.6.2 Verbindungsabbau Der Verbindungsabbau ist in Abbildung 3-8 dargestellt. Close FIN senden Established FIN Wait FIN empfangen Close Wait FIN Empfangen Closed Close FIN senden Abbildung 3-8: Verbindungsabbau 21 Kapitel 3 Netzwerkprotokolle Eine Verbindung wird immer vom Sender mit dem FIN-Bit beendet und gelangt damit den FIN-Wait-Status. Wird das FIN positiv beantwortet, so wird wieder der ClosedModus angenommen. Ist das FIN empfangen worden, so gelangt ein Empfänger direkt in den Close-Wait-Status. Nach Versenden des FIN wird die Verbindung abgebaut und der Closed-Zustand angenommen. Es existieren zwei Möglichkeiten, eine Verbindung zu beenden: Graceful Close und Abort. Beim Graceful Close schließen die höheren Übertragungsprotokolle auf beiden Seiten die Verbindung. Dies kann gleichzeitig oder nacheinander geschehen, das TCP koordiniert den Verbindungsabbau. Die Verbindung wird erst abgebaut, wenn alle restlichen Daten übertragen worden sind, um Datenverlust zu vermieden. Die zweite Möglichkeit ist der Abort. Eine Verbindung wird mit Abort beendet, wenn die Verbindung einseitig abgebaut werden muß, z.B. bei einem fehlgeschlagenen Authentifizierungsversuch bei einem sicheheitsrelevantem Dienst. Dabei baut ein höheres Protokoll eines Kommunikationspartners die Verbindung einseitig ab. Das TCP koordiniert den Abbau der Verbindung in diesem Fall nicht und es kann zu Datenverlust kommen. 3.7 NetBEUI Das NetBEUI ist ein nicht routingfähiges Protokoll. Es besteht die Möglichkeit die Routing-Fähigkeit der Protokolle TCP/IP- oder IPX zu nutzen in dem NetBEUI-Pakete an diese gebunden werden. NetBEUI arbeitet auf den TCP/IP Ports 137 bis 139 (vgl. Tabelle 3-2). Ursprünglich ist NetBEUI von der Firma IBM entwickelt worden, um kleine Netzwerke zu verbinden. Es können maximal 254 Rechner auf einmal miteinander verbinden. Name NetBEUI-ns NetBEUI-ns NetBEUI-dgm NetBEUI-dgm NetBEUI-ssn NetBEUI-ssn Port 137/tcp 137/udp 138/tcp 138/udp 139/tcp 139/udp Beschreibung Name Service Name Service Datagram Service Datagram Service Session Service Session Service Tabelle 3-2: NetBEUI Ports 22 Kapitel 3 Netzwerkprotokolle 3.7.1 Header In Abbildung 3-9 ist der NetBEUI Header dargestellt 1 4 8 Länge 12 Kommando Datenlänge Reserviert Empfänger-Session Sender-Session 16 20 24 28 Signatur Resyncindikator Antwortverknüpfung Beginn Datenbereich 32 Abbildung 3-9: NetBEUI Header • Länge: Das Feld ist 16 Bit lang und zeigt die Anzahl der zu übermittelnden Daten an. • Signatur: Die Signatur wird zum Identifizieren der übertragenen Pakete eingesetzt. Sie hat eine Länge von 16 Bit. • Kommando: Das Feld ist 8 Bit lang und zeigt die Netzwerkaktion an, die ausgeführt werden soll (Daten anfordern, Verbindung aufbauen). • Datenlänge: Das Feld hat einen Umfang von 8 Bit und zeigt an, wie viele 32-Bit-Datenworte im Header vorhanden sind. • Resyncindikator: Das Feld hat eine Länge von 16 Bit. Die Funktion dieses Feldes ist ein Mechanismus zur Flußkontrolle. Um eine gesicherte Übertragung zu ermöglichen können hier fehlende oder nicht korrekt übertragene Datenpakete ermittelt werden. • Reserviert: Das Feld erstreckt sich über 16 Bit. Dieses Feld ist für zukünftige Funktionen reserviert und wird immer auf „0“ gesetzt. • Antwortverknüpfung: Das Feld hat eine Länge von 16 Bit. Die Funktion dieses Feldes ist es, die richtige Reihenfolge der empfangenen Pakete herzustellen. • Empfänger-Session: Dieses Feld zeigt an, welche Anwendung oder welcher Dienst die Pakete erhalten soll und ist 8 Bit lang. • Sender-Session: Das Sender-Session-Feld zeigt an, von welcher Anwendung oder von welchem Dienst die Pakete stammen. Es hat einen Umfang vom 8 Bit. 23 Kapitel 4 Problemstellung 4 Problemstellung Zwischen zwei Rechnern besteht eine aktive Kommunikation. Diese wird im Normalfall systematisch wieder von beiden Kommunikationspartnern abgebaut. Ziel ist es jetzt, die Kommunikation von einem externen Prozeß auf einem der beiden Rechner zu unterbinden bzw. zu beenden. Dazu sind verschiedener Mechanismen, die als Ergebnis die Unterbrechung dieser Kommunikation (vgl. Abbildung 4-1) zwischen den beiden Rechnern mit sich führen, zu untersuchen. Die geeignet zu entwickelnde Routine soll die Kommunikation zwischen zwei Rechnern beenden. Rechner A Kommunikation Rechner B Befehl zum Abbau der Verbindung Rechner A Kommunikation Rechner B Kommunikation ist beendet Rechner A Rechner B Abbildung 4-1: Problemstellung Abbau einer Verbindung Als Eingangsparameter werden die Daten der vorhanden Kommunikation zwischen zwei Rechnern übernommen, welche zuvor festgestellt werden müssen (vgl. Kapitel 5). Die Routine soll als Modul realisiert werden, um diese in mehreren Programmen nutzen zu können. 24 Kapitel 5 Erkennung bestehender Verbindungen 5 Erkennung bestehender Verbindungen Um eine Verbindung zwischen zwei Rechnern abbauen zu können ist es notwendig, die bestehenden Verbindungen eines Rechners zu kennen. Zu einer Verbindung gehören Informationen, welche diese eindeutig identifizieren. Dazu gehören z.B.: • aktive Verbindungen • Protokolltyp • Quellrechner • Zielrechner • Sende und Empfängerport • Status (Listening, Established, ...) Eine einfache Möglichkeit diese Informationen zu erhalten wird z.B. mittels des Programms Netstat (MS Windows 9x/NT) erreicht, welches für die Verbindungsanalyse zur Verfügung steht. Die möglichen Eingabeparameter sind in Abbildung 5-1 mit den jeweiligen Funktionen aufgelistet. Abbildung 5-1: Netstat /? Alle aktiven Verbindungen eines Rechners werden mit Netstat -a angezeigt. Abbildung 5-2 zeigt die aktuellen Verbindungen des Rechners thread. 25 Kapitel 5 Erkennung bestehender Verbindungen Abbildung 5-2: Netstat -a Die neunte Zeile von oben zeigt z.B. einen TCP Socket auf dem Rechner thread am NetBEUI-Port 137 der den Status Listening besitzt. D.h. der Rechner thread erwartet auf dem Port 137 einen Verbindungsaufbau. In der zwölften Zeile ist eine TCP-Verbindung vom Port 1027 des Rechners thread zum Port nbsession des Rechners thing mit dem Status Time Wait. Der Rechner thread wartet auf Daten vom Rechner thing. Eine Schnittstellenstatistik für die Netzwerkkarte wird mittels Netstat -e ausgegeben (vgl. Abbildung 5-3). Abbildung 5-3: Netstat -e 26 Kapitel 5 Erkennung bestehender Verbindungen Die dritte Zeile zeigt die Menge der übertragenen Bytes an. Es wird die Anzahl der Unicast-19 (Zeile 4) und Nicht-Unicast-Pakete (Zeile 5) sowie die der verworfenen (Zeile 6) und fehlerhaften Pakete (Zeile 7) angezeigt. Bei der Ausgabe wird zwischen gesendeten und empfangenen Paketen unterschieden. Unten wird die Menge der unbekannten Protokolle angegeben. Die Routing-Tabelle sowie alle aktiven Verbindungen wird mit Netstat -r ausgegeben. Eine Routing-Tabelle beschreibt den Weg, mit der Pakete im Netzwerk verschickt werden. Abbildung 5-4: Netstat –r Abbildung 5-4 zeigt in der dritten Zeile alle Pakete, die in die Netzwerkmaske 0.0.0.0 mit der Subnetzmaske 0.0.0.0 übereinstimmen, an das Gateway20 mit der Adresse 134.147.40.7 weitergeleitet werden. Alle Pakete, die an einen Rechner in dem lokalen Netz 134.147.40.0 mit der Subnetzmaske 255.255.255.128 adressiert sind werden nicht über das Gateway 134.147.40.7 geschickt, sondern lokal versendet (Zeile 6). Pakete, die nur für den Rechner mit der IP-Adresse 134.147.40.88 bestimmt sind, werden auf das Loopback Device21 geschickt (Zeile 7). Dieser Rechner (134.147.40.88) ist der lokale Rechner selbst. Der zweite Teil zeigt die aktiven Verbindungen. Die Darstellung ist analog zum Ergebniss vom Netstat –a. 19 Unicast - nur zu einem Empfänger 20 Gateway - Netzknoten, der Pakete in ein anderes Netz transportiert 21 Loopback Device - Internes Netzwerkinterface auf dem eigenen Rechner. Wird genutzt, um den eigenen Rechner über das Netz anzusprechen. 27 Kapitel 6 Lösungsansatz 6 Lösungsansatz Das Problem eine Netzwerkverbindung zu kennen (vgl. Kapitel 5) kann durch drei Ansätze gelöst werden: mittels Windows Sockets, auf der Netzwerkschnittstelle oder durch Verbindungsübernahme. 6.1 Windows Sockets Der erste Ansatz ist im ISO/OSI-Modell auf der Ebene 7 (Anwendungsebene) einzuordnen und soll die Windows Socket Routinen nutzen. Die Microsoft Sockets basieren auf der Spezifikation der Sockets der Berkeley Software Distribution (BSD) der University of California in Berkeley. Die Implementation umfaßt die Socket-Routinen von der BSD und ist um spezielle Windows-Routinen erweitert. Viele Netzwerk-Software Hersteller unterstützen die Windows Sockets. Im Prinzip kann jedes Netzwerk-Protokoll mit den Windows Sockets kompatibel sein. Dafür bedarf es einer speziellen DLL22-Version. Für den Zugriff auf die Internet Protokolle TCP, UDP und IP stellt Microsoft unter den 16-Bit-Betriebssystemen die Programmierschnittstelle winsock.dll und unter den 32-Bit-Betriebssystemen wsock32.dll zur Verfügung. Eine allgemeine Schnittstelle zur Internetprogrammierung ist die Microsoft Foundation Classes (MFC). Sie kann grundsätzlich in vier Gruppen eingeteilt werden: • Low Level Protokolle (TCP/UDP/IP) • Anwendungsprotokolle • Dateidienste • Ausnahmebehandlungen Die MFC lassen sich unterteilen in: Low Level Win Socket-Klassen (vgl. Abbildung 6-1) und den Klassen auf der Anwendungsprotokoll-Schicht (vgl. Abbildung 6-2). CAsyncSocket CSocket CAsyncSocket CSocket WinSocket WinSocket TCP-/UDP-/IPDatenpakete Internet TCP-/UDP-/IPDatenpakete Abbildung 6-1: Schichten der Low Level Win Socket Klassen 22 DLL - Dynamic Link Libery 28 Kapitel 6 Lösungsansatz Die einzelnen Klassen setzen auf den Netzwerkschichten auf. Dabei stellt TCP-/UDP-/IP-Datenpakete die TCP/UDP/IP-Implementierung von Windows dar. Auf die Low Level-Ebene greifen die Klassen CSocket und CAsyncSocket zu. Beide Klassen unterstützen die Protokolle TCP und UDP. CFtpConnection CHttpConnection CGopher Connection CFtpConnection CHttpConnection CGopher Connection WinInet WinInet WinSocket WinSocket TCP-/UDP-/IPDatenpakete Internet TCP-/UDP-/IPDatenpakete Abbildung 6-2: Schichten der Anwendungsprotokoll-Klassen Die Anwendungsprotokoll-Klassen besitzen eine höhere Abstraktion in der Programmierung. Es wird nicht direkt auf TCP- oder UDP-Ebene zugegriffen, sondern mit den Anwendungsprotokoll-Klassen direkt auf die Anwendungsschicht im ISO/OSI-Modell zugegriffen. Zu den Anwendungsprotokoll-Klassen gehören die Klasse CFtpConnection zur Datenübertragung, die Klasse CHttpConnection zur Übertragung von HTML-Dokumenten und die Klasse CGopherConnection für GopherÜbertragungen. 6.2 Network Driver Interface Der zweite Ansatz setzt auf die unteren Schichten des ISO/OSI-Modells auf. Es ist zu untersuchen ob eine Verbindung zwischen zwei Rechnern auf den untersten Ebenen beendet werden kann. Für die Realisierung ist die Network Interface Card-Ebene des Betriebssystems MS Windows NT zu betrachten. Dies entspricht in dem ISO/OSIModell der Physikalischen Schicht (Schicht 1) und einem Teil Sicherungschicht (Schicht 2). In Abbildung 6-3 ist die Einordnung der MS Windows NT Netzwerkebenen in das ISO/OSI-Modell abgebildet. 29 Kapitel 6 Lösungsansatz IOS/OSI-Modell Microsoft Modell Anwendungen Anwendungsschicht Darstellungsschicht Standart: Erweiterte Anwendunge: Systemmeldungen: FTP NFS Fehlerbehandlung Telnet Drucker Server SMTP Sitzungsschicht Transportschicht Netzwerkschicht Transport Driver Interface Ebene TDI Ebene Sicherungsschicht Logical Link Control Sicherungsschicht Media Access Control Physikalische Schicht Network Interface Card Ebene NIC Ebene Abbildung 6-3: Eingliederung der Windows NT Netzwerkebenen ins ISO/OSIModell 6.3 Verbindungsübernahme Die Idee des dritten Ansatzes besteht darin, eine TCP-Verbindung, die zwischen zwei Kommunikationspartnern besteht, zu übernehmen und die Verbindung zu beenden. Analog zum Juggernaut-Angriff (vgl. Kapitel 2.5) wird von einem dazwischen liegenden Prozeß die Verbindung übernommen. Der Unterschied hier liegt in der Initiierung der Übernahme, da die Übernahme vom eigenen System erfolgen soll (vgl. Abbildung 6-4). Dem zweiten Verbindungspartner der bestehenden Verbindung (Rechner B) wird vorgetäuscht, der richtige Kommunikationspartner dieser Verbindung zu sein. Dies geschieht indem durch den Prozeß zur Verbindungsübernahme auf dem Rechner B Pakete mit einer höheren Sequenznummer an den gleichen Sende- und Empfangsport geschickt werden. Dadurch kann die Verbindung übernommen werden. 30 Kapitel 6 Lösungsansatz Rechner A Rechner B Prozeß zum Übernehmem der Verbindung Prozeß 1 an Rechner B, Port 23, Sequneznr. 45 Port 1024 Sequneznr.44 Verbindung Port 23 Sequneznr.44 Prozeß 2 Abbildung 6-4: Verbindung durch einen anderen Prozeß übernehmen Mit senden des Abort-Signals von Rechner A aus wird die Verbindung mit Rechner B korrekt abgebaut (Abbildung 6-5). Abort Signal zu Recher 2 senden Prozeß zum beenden der Verbindung Prozeß 1 Ver- bindung Prozeß 2 Beenden der Verbindung Abbildung 6-5: Beenden einer Verbindung durch einen anderen Prozeß Dieser Ansatz läßt sich nicht mit den MFC-Klassen programmieren, da diese nur die exklusive Verwendung eines Ports für eine Anwendung erlauben. Weiterhin ist mit dem MFC-Klassen nicht möglich, die aktuelle Sequenznummer eines Paketes festzustellen. Es ist deshalb notwendig, für die Programmierung auf tieferen Netzwerkschichten zuzugreifen. 31 Kapitel 7 Realisierung 7 Realisierung 7.1 Windows Sockets Es sind drei Programme entwickelt worden: ClosePort, ServiceScanner und ServiceServer. Diese Programme werden folgend weiter erläutert. 7.1.1 ClosePort Das Ziel des Programms ist es alle Ports zu blockieren, um eine Verbindung für eine Kommunikation direkt abblocken zu können. Das Programm ClosePort (Abbildung 7-1) belegt sukzessiv alle Ports von 1 bis 10000 mit einem Windows Socket. Abbildung 7-1: ClosePort Es wird eine Schleife durchlaufen, welche nacheinander zunächst eine Socket erstellt und anschließend auf dem Socket hört (vgl. Abbildung 7-2). Schleife von 1 bis 10000 Erzeuge Socket Höre auf Socket Abbildung 7-2 Struktogramm ClosePort Wenn ein Port bereits von einem anderen Programm belegt ist, kann dieser Port nicht erneut belegt werden. Mit den MFC-Klassen ist es nicht möglich einen Socket aus einem anderen Programm heraus zu schließen. So bleibt das andere Programm auf dem Port aktiv. Wenn z.B. ein Http-Server auf dem Port 80 aktiv ist und ClosePort gestartet wird, bleibt der Server weiterhin aktiv, da der Port nicht mehrfach belegt 32 Kapitel 7 Realisierung werden kann. Wird hingegen ClosePort vor dem Http-Server gestartet, kann der Server den Port nicht belegen. Durch ClosePort werden alle freien Sockets bis Port Nummer 10000 belegt. Die Grenze Port Nummer 10000 ist frei gewählt. Ein Problem besteht darin, daß ClosePort für jeden Port einen eigenen Socket öffnet. Unter Microsoft Windows 95 kann es zu einer graduellen Vermehrung des durch das Betriebssystem beanspruchten Speicherplatzes kommen. Dies ist durch einen Fehler in dem Microsoft Windows 95 Kernel (Kernel32.dll) bedingt, der die Freigabe kleiner Datenstrukturen verhindert, welche durch das Öffnen und Schließen von Windows Sockets resultieren. Die Folge ist eine enorme Verringerung des Betriebssystemspeichers. Eine aktualisierte Version der Datei Kernel32.dll wird zur Lösung des Problem von Microsoft zur Verfügung gestellt. Microsoft Windows NT hat dieses Problem nicht. Ferner ist es jedoch, bedingt durch das Betriebssystem, nur möglich eine bestimmte Anzahl von Sockets gleichzeitig zu öffnen. Deshalb kann das Programm ClosePort nicht alle Ports eines Rechners blockieren. 7.1.2 ServiceScannner Der ServiceScanner (vgl. Abbildung 7-3) ist ein Programm zum systematischen Überprüfen eines Rechners nach belegten Ports. Das Programm arbeitet ebenso wie ClosePort (vgl. Kapitel 7.1.1) mit den MFC-Funktionen. Abbildung 7-3: ServiceScanner 33 Kapitel 7 Realisierung In das Feld Zielrechner wird die IP-Adresse oder der Netzwerk-Name des Zielrechners eingegeben. Durch betätigen des Start-Knopfes wird der Prüfvorgang eingeleitet. Wenn Eingabe Zielrechner und Taste Start gedrückt ja nein Schleife von 1 bis 10000 Verbindung zum Zielrechner aufbauen % Wenn Port auf Zielrechner antwortet nein % ja Portnummer ausgeben Abbildung 7-4: Struktogramm ServiceScanner Das Programm arbeitet dabei eine Schleife von 1 bis 10000 ab und versucht, zu jedem Port des Zielrechners eine Verbindung aufzubauen (vgl. Abbildung 7-4). Kann eine Verbindung aufgebaut werden, so wird die Portnummer, der Servicename und das verwendete Protokoll im Feld Konnektierbare Ports angezeigt. Das Programm eignet sich dazu, die Funktionsweise von ClosePort bzw. die belegten Ports eines Rechners zu überprüfen . 7.1.3 ServiceServer Ziel des Programms ServiceServer ist es gezielt einen Port belegen zu können, um ihn so für andere Anwendungen zu sperren bzw. einen Verbindungsaufbau zu diesem Port zu erkennen. Abbildung 7-5: ServiceServer Durch betätigen der Start-Taste wird ein Windows Socket für die angegebene Portnummer mit dem Status Listen erzeugt. 34 Kapitel 7 Realisierung Wenn Eingabe Portnummer und Taste Start gedrückt nein ja Erzeuge Socket (Portnummer) % Höre auf Socket (Portnummer) Abbildung 7-6 Struktogramm ServiceServer Initiiert ein Kommunikationspartner z.B. eine Telnet-Sitzung über den Port, so wird in dem Statusfeld die IP-Adresse des Kommunikationspartners ausgegeben. Der Status der Verbindung ist dann Established. Besteht bereits eine Verbindung zu einem Rechner und eine zweite Anfrage auf einen Port trifft ein, so wird die erste Verbindung geschlossen und die neue Verbindungsanfrage angenommen. Dieses Programm eignet sich dazu einzelne Ports zu sperren. Ist der ServiceServer auf einem Port aktiv, kann kein anderes Programm auf diesem Port eine Verbindung aufbauen. 7.2 Network Driver Interface Die Network Driver Interface Spezifikation greift direkt auf die Hardwareressourcen der Netzwerkkarte zu. Sie ist das unterste Bindeglied zwischen Netzwerkkarte Protokollimplementierung des Betriebssystems. Die Hardware wird nur von den NDISFunktionen angesprochen, alle anderen Netzwerkprotokollebenen greifen auf die NDIS-Funktionen zu. Die NDIS-Funktionen stellen eine fest spezifizierte Schnittstelle zwischen Netzwerkkarte und den über der NDIS liegenden Schichten dar. Microsoft stellt mit MS Windows 9x und MS Windows NT eine Reihe von NDIS-Bibliotheken zur Verfügung. Mit diesen Bibliotheken ist es möglich, ohne Wissen der Funktionsweise der Netzwerkkarte, auf standardisierte Funktionen zurückzugreifen. So ist eine einfache Programmierung der Netzwerkkarte gewährleistet. Diese standardisierten Funktionen stellen aber keine Möglichkeit zur Verfügung eine Verbindung zwischen zwei Rechnern zu terminieren. Die NDIS-Schnittstelle erlaubt auch den direkten Zugriff auf die Netzwerkkarte, d.h. es besteht die Möglichkeit direkt auf die hardwareabhängigen Funktionen der Netzwerkkarte zurückzugreifen. 35 Kapitel 7 Realisierung 7.3 Verbindungsübernahme Die Übernahme einer Verbindung ist bereits als Basement Research Kill (BRkill) bekannt. Durch ein Fehler in der TCP/IP-Implementierung von MS Windows 95 und MS Windows NT wird es einem Dritten erlaubt eine bestehende Verbindung auf diesen Rechnern zu beenden. Dafür wird nur die IP-Adresse und der TCP Port der Verbindung des Windows Rechners benötigt. Mit diesen Informationen ist es möglich, ein Connection Reset an den Windows Rechner zu senden. Beim BRkill wird ein Push Acknowledge (vgl. Kapitel 3.3.2) benutzt, um ein Connection Reset zu generieren. Das zurückgesendete Acknowledge-Feld enthält die letzte Acknowledge-Nummer der bestehenden TCP-Verbindung. Mit diesem Wissen ist es möglich, dem Windows Rechner ein Reset-Bit mit der letzten Acknowledge-Nummer als Sequenz-Nummer zu schicken. Das Acknowledge-Feld wird dabei auf „0“ gesetzt. Die bestehende Verbindung wir dann abgebaut. Das Senden des Reset-Bits muß in einer relativ kurzen Zeitspanne geschehen. Es darf kein weiteres neues Paket mit einer höheren Acknowledge-Nummer vom Windows Rechner gesendet werden. Andernfalls würde die Sequenz-Nummer des Paketes mit dem Reset-Bit nicht mehr akzeptiert, weil sie zu niedrig wäre, und das Paket würde verworfen. Die Realisierung von BRkill enthält die Möglichkeit eine Reihe von höheren Sequenz-Nummern (Acknowledge-Bit + n) zu senden, um das Problem zu umgehen. Wenn auf dem Zielrechner viele bestehende TCP-Verbindungen existieren, ist es schwer eine bestehende Verbindung zu beenden, da eine Reihe von AcknowledgeNummern existieren und nicht bekannt ist welche benötigt wird, um die Verbindung zu beenden. Mit steigender Anzahl von bestehenden Verbindungen wird es somit schwieriger eine bestimmte Verbindung auf diese Art zu beenden. Es ist nicht empfehlenswert diese Realisierung zur Verbindungsunterbrechung in der Praxis einzusetzen. Der entscheidende Nachteil besteht darin, daß sie auf einem Fehler in der TCP-Protokoll-Implementierung des Microsoft Betriebssystems aufbaut. Dieser Fehler ist in den Betriebssystemen MS Windows 95 und MS Windows NT 4.0 noch vorhanden, wird aber durch entsprechende Service Packs beseitigt. Desweiteren wird beim Beenden einer Verbindung mit BRkill auf dem Windows Zielrechner die Fehlermeldung „The connections has been reset by the remote host“ ausgegeben. Dies stellt in dem Fall des Beendens der Verbindung durch einen Dritten nicht den Sachverhalt dar. 36 Kapitel 8 Zusammenfassung 8 Zusammenfassung Bei der Nutzung der MFC-Klassen scheiterte die Lösung an einem Fehler von Windows, der den Betriebssystemspeicher zum Überlauf bringt, und an der Möglichkeit nicht beliebig viele Sockets öffnen zu können. Zusätzlich stellen die MFC-Klassen keine Möglichkeit zur Verfügung, eine Netzwerkverbindung zwischen zwei Prozessen durch einen dritten zu beenden. Mit NDIS-Schnittstelle besteht die beste Chance die Beendung einer Verbindung zwischen zwei Rechnern zu realisieren, da diese die unterste Schnittstelle in der Netzwerkprotokollimplementierung der Microsoft Betriebssysteme darstellt. Keine andere Programmierung der Netzwerkschittstelle ist grundlegender als die Programierung der NDIS-Schnittstelle. Nur bei dieser Lösung scheint es möglich eine Verbindung zwischen zwei Rechnern von außen her zu beenden. Die Möglichkeit der Verbindungsübernahme zeigt keine Lösung der Problematik. Diese Realisierung baut auf einem Fehler in der TCP-Protokoll-Implementierung des Microsoft Betriebssystemen auf. Das es grundsätzlich möglich ist eine Verbindung zwischen zwei Rechnern zu beenden, zeigt das im Anhang-A beschriebene Programm AtGuard. Hier ist eine Routine zur Beendung einer Kommunikation zwischen zwei Rechnern implementiert worden. Keine der vorgestellten Ansätze stellt somit ein zufriedenstellendes Ergebnis zur Lösung dar. 37 Kapitel 9 Ausblick 9 Ausblick Es sind Möglichkeiten zur Unterbrechung einer Kommunikation zwischen zwei Rechner untersucht worden. Dabei stellte sich kein zufriedenstellendes Ergebnis ein. Eine Möglichkeiten zur Lösung des Problems stellt die direkte Analyse des Netzwerkstroms dar. Problematisch ist hierbei die nicht ausführliche Dokumentation der Netzwerkschnittstelle von Microsoft Windows NT. Eine weitere Möglichkeit ist der Zugriff auf hardwareabhänige Funktionen der Netzwerkkarte. Problem hierbei in die proprietäre Architektur der erweiterten Netzwerkartenfunktionen. Durch eine zu entwickelnde Routinen ist es dann möglich, Verbindungen zwischen zwei Rechnern auf unterer Ebene im ISO/OSI-Modell zu beenden. Diese Routine kann im weiteren Programmen zur Netzwerksicherheit eingebunden werden. Eine fortgeschrittene Entwicklung könnte die Programmfunktionen „Netzwerkanalyse“ bzw. „Netzwerküberwachung“ und das Terminieren von Netzwerkverbindungen beinhalten. Die einzelnen Programmfunktionen würden dabei miteinander interagieren. Die Netzwerküberwachung meldet der Routine zum Beenden einer Verbindung die sicherheitskritischen Netzwerkverbindungen. Die Terminierungsroutine trennt daraufhin die kritischen Verbindungen und sendet eine Statusmeldung an die Überwachungsroutine zurück. Die Terminierungsroutine kann unabhängig in weiteren Programmen zur Anwendung kommen. Denkbar sind z.B. Sicherheitstools die nur gewissen Nutzern Zugriff auf bestimmte Daten erlauben oder Programme die bestimmte Netzwerkverbindungen, z.B. solche mit rechtlich kritischem Inhalt, filtern. 38 Kapitel 10 Literatur 10 Literatur [BAL98] Balzert, Helmut Lehrbuch der Softwaretechnik, Software-Entwicklung Spektrum Akademischer Verlag, Heidelberg 1998 ISBN 3-8274-0042-2 [BAU99] Baumann, Heiko Entwicklung eines Softwaretools zur Protokollierung und Analyse des Datenstroms in Netzwerken Diplomarbeit 344, Lehrstuhl für Datenverarbeitung Ruhr-Universität Bochum, Bochum 1999 [BAS99] Basemnet Research Brkill Basement Research, 1999 http://deep.ee.siue.edu/br [BRA95] Bradner, S. / Mankin, A, Request for Comments 1752, The Recommendation for the IP Next Generation Protocol Network Working Group, Havard 1995 [CHA95] Chapman, D. Brent / Zwicky, Elisabeth D. Einrichten von Internet Firewalls O’Reilly, Köln 1995 ISBN 3-930673-31-2 [CHA92] Chapman, D. Brent Networking (In)Security Through IP Packet Filtering The Third USENIX UNIX Security Symposium, Baltimore 1992 [CHP98] Chapman, Davis Visual C++ 6 in 21 Tagen SAMS, Haar 1998 ISBN 3-8272-2035-1 39 Kapitel 10 Literatur [COD99] Codeguru Codeguru Internetseite Codeguru, 1999 http://www.codeguru.com [DEE95] Deering, S / Hinden, R. Request for Comments 1883, Internet Protocol Version 6 Specifikation Network Working Group, 1995 [DDK99] Microsoft Device Driver Kit Onlinehilfe Microsoft Corperation, Redmond 1999 [HEI98] Heim, Mathias TCP/IP, Internetprotokolle im Einsatz International Thomson Publishing, Bonn 1998 ISBN 3-8266-4035-7 [HEI99] Heise Heise Internetseite Verlag Heinz Heise, Hannover 1998 http://www.heise.de [HOR99] Horster, Patrik Systemsicherheit - Sicherheit in komplexen IT-Systemen Folien zur Vorlesung WS 1999/2000 Ruhr-Universittät Bochum, Bochum 1999 [MFC99] MfC Professional MfC Professional Internetseite MfC Professional, 1999 http://www.visionx.com/mfcpro/ [MIC97] Microsoft Coperation Visual C++ Online-Hilfe Microsoft, Redmond 1997 40 Kapitel 10 Literatur [MIC99] Microsoft Coperation Microsoft Coperation Internetseite Microsoft, Redmond 1999 http://www.microsoft.com/ [MIR99] Microsoft Coperation MSDN Internetseite Microsoft, Redmond 1999 http://msdn.microsoft.com/default.asp [NWG87] Network Working Group Request for Comments 1001, Protocol Standard for a NetBIOS Service on a TCP/UDP Transport Network Working Group, 1987 [POS80] Postel, J. Request for Comments 768 User Datagram Protocoll Network Working Group, 1980. [RAY81] del Ray, Marina Request for Comment 791, Internet Protocol Universität Southern California, California 1981 [RAZ81] del Ray, Marina Request for Comment 793, Transmission Control Protocol Universität Southern California, California 1981 [RIE99] Riebl, Rosa Visual C++ 6, Professionelle Windows Programmierung C&L, Vaterstetten 1999 ISBN 3-932311-20-5 [ROT99] Rootshell Rootshell, Sicherheitslücken http://www.rootshell.com [SDK99] Microsoft Software Development Kit Onlinehilfe Microsoft Corp., Redmond 1999 41 Kapitel 10 Literatur [SOL98] Solomon, David A. Inside Windows NT Second Edition Microsoft Press, Redmond 1998 ISBN 1-57231-677-2 [WRQ99] WRQ AtGuard WRQ Inc., Seattle 1999 http://www.atguard.com [ZEN95] Zenk, Andreas Lokale Netze, Kommunikationplattform der 90er Jahre Addison-Wesley, Bonn 1997 ISBN 3-8273-1020-2 42 Anhang-A AtGuard Anhang-A AtGuard AtGuard ist ein Produkt der Firma WRQ mit einer Reihe von sicherheitsrelevanten Routinen. Es enthält Sicherheitseinstellungen für die Nutzung des WWW1 und eine Implementierung einer Firewall2. Das Programm arbeitet im Hintergrund und schaltet sich bei sicherheitsrelevanten Ereignissen automatisch in den Vordergrund. In Abbildung A-1 ist das Optionsmenü für die Konfiguration von AtGuard abgebildetet. Hier lassen sich die Sicherheitseinstellungen für die WWW-Nutzung und die Einstellungen der Firewall vornehmen. Abbildung A-1: ATGuard-Konfigurationsmenü Die Firewall unterstützt die Protokolle TCP, UDP und ICMP. In einem Menü können Filterregeln wie bei bekannten Paketfiltern, z.B. dem Ipfwadm bei Linux, eingestellt werden. Es stehen die Regeln PERMIT, BLOCK und IGNORE für ein und ausgehende Pakete zur Verfügung. Zusätzliche Funktionen sind das Sperren von Anwendungen oder das Festlegen von Filterregeln für bestimmte Zeiträume. Zur Auswertung der sicherheitsrelevanten Ereignisse können diese protokolliert werden, zudem steht ein Ereignismonitor zur Verfügung. 1 WWW – World Wide Web 2 Firewall - [engl.] Brandschutzmauer. Gerät zum Schutz von Netzen nach außen. 43 Anhang-A AtGuard Tritt ein sicherheitsrelevantes Ereignis ein, so öffnet sich ein PopUp-Dialog (vgl. Abbildung A-2). Dieser erlaubt das einmalige Blockieren oder Freigeben der Verbindung. Falls die Verbindung immer freigegeben oder blockiert werden soll, kann dies über die dialoggeführte Einstellung vorgenommen werden. Abbildung A-2: ATGuard Sicherheits PopUp Menü Das Programmpaket bietet eine Statistikfunktion (vgl. Abbildung A-3) an. Diese Statistik zeigt die Menge der in Netz übertragenen Daten und der durch die einzelnen Filterregeln geblockten Verbindungen an. Im Fenster werden unten links die vorhanden Verbindungen angezeigt. Eine bestimmte Verbindung zwischen zwei Rechnern kann beendet werden, indem diese mit der Maus markiert und durch drücken der rechten Maustaste terminiert wird Abbildung A-3: ATGuard-Statistik 44 Anhang-B Portzuordnung Anhang-B Portzuordnung Name tcpmux echo echo discard discard systat daytime daytime netstat qotd chargen chargen ftp-data ftp telnet smtp time time rlp name whois domain domain mtp bootps bootpc tftp gopher rje finger http link kerberos Nummer/Protokoll 1/tcp 7/tcp 7/udp 9/tcp 9/udp 11/tcp 13/tcp 13/udp 15/tcp 17/tcp 19/tcp 19/udp 20/tcp 21/tcp 23/tcp 25/tcp 37/tcp 37/udp 39/udp 42/udp 43/tcp 53/tcp 53/udp 57/tcp 67/udp 68/udp 69/udp 70/tcp 77/tcp 79/tcp 80/tcp 87/tcp 88/udp Aliasname users quote ttytst source ttytst source mail timeserver timeserver resource nameserver nicname ttylink kdc 45 Anhang-B kerberos supdup hostnames iso-tsap x400 x400-snd csnet-ns pop-2 pop-3 pop sunrpc sunrpc sunrpc sunrpc auth sftp uucp-path nntp ntp ntp NetBEUI-ns NetBEUI-ns NetBEUI-dgm NetBEUI-dgm NetBEUI-ssn imap NeWS snmp snmp-trap exec biff login who shell syslog printer talk Portzuordnung 88/tcp 95/tcp 101/tcp 102/tcp 103/tcp 104/tcp 105/tcp 109/tcp 110/tcp 110/tcp 111/tcp 111/tcp 111/udp 111/udp 113/tcp 115/tcp 117/tcp 119/tcp 123/tcp 123/udp 137/tcp 137/udp 138/tcp 138/udp 139/tcp 143/tcp 144/tcp 161/udp 162/udp 512/tcp 512/udp 513/tcp 513/udp 514/tcp 514/udp 515/tcp 517/udp kdc hostname portmapper portmapper ident usenet nbns nbns nbdgm nbdgm nbssn news comsat whod cmd spooler 46 Anhang-B ntalk efs route timed tempo courier conference netnews netwall uucp klogin kshell new-rwho remotefs rmonitor monitor pcServer mount pcnfs bwnfs kerberos-adm kerberos-adm kerberos-sec kerberos-sec kerberos_master kerberos_master krb5_prop cddbp listen nterm kpop ingreslock tnet cfinger nfs eklogin krb524 Portzuordnung 518/udp 520/tcp 520/udp 525/udp 526/tcp 530/tcp 531/tcp 532/tcp 533/udp 540/tcp 543/tcp 544/tcp 550/udp 556/tcp 560/udp 561/udp 600/tcp 635/udp 640/udp 650/udp 749/tcp 749/udp 750/udp 750/tcp 751/udp 751/tcp 888/tcp 1025/tcp 1026/tcp 1109/tcp 1524/tcp 1600/tcp 2003/tcp 2049/udp 2105/tcp 4444/tcp router routed timeserver newdate rpc chat readnews uucpd cmd new-who rfs Server rfs rmonitord listener rfs remote file sharing remote login network terminal 47 Anhang-B irc dos Portzuordnung 6667/tcp 7000/tcp msdos 48
