Online Ratgeber des DFN-FWL - uni-hamburg.de · 2016. 4. 18. · Die hier vorgestellten Vorschläge zur Implementierung und Konﬁguration von Firewalls und anderen Sicherheitsmechanismen

Online Ratgeber des DFN-FWL

Sicherheit in ATM-Netzen

Carsten Benecke

Online Ratgeber des DFN-FWL: Sicherheit in ATM-Netzenvon Carsten Benecke

Copyright © 1999-2001 von DFN Firewall-Labor für Hochgeschwindigkeitsnetze

Alle Rechte an diesem Dokument liegen beim DFN-Projekt TK 602 - SD 110 „Sicherheit in ATM-Netzen“der Universität Hamburg, Fachbereich Informatik, Rechenzentrum

Die hier vorgestellten Vorschläge zur Implementierung und Konfiguration von Firewalls und anderenSicherheitsmechanismen beruhen auf sorgfältig von uns erhobenen Daten und experimentellen Studien.Gleichwohl können weder die an den zugrundeliegenden Forschungen beteiligten Institutionen (DFN-Verein,Universität Hamburg), noch der Autor selbst eine Haftung für die Richtigkeit der Angaben undLösungsvorschläge übernehmen, sie stellen lediglich eine unverbindliche, nach bestem Wissen undGewissen gegebene Empfehlung dar.

InhaltsverzeichnisVorwort .............................................................................................................................................. 11

1. Einleitung....................................................................................................................................... 13

1.1. Aufbau des Ratgebers ........................................................................................................ 131.2. Hinweise für den Leser ...................................................................................................... 131.3. Ein Online Ratgeber für ATM-Sicherheit .......................................................................... 13

2. Einführung in ATM und generische Sicherheitsprobleme ....................................................... 15

2.1. Einführung in ATM............................................................................................................ 152.1.1. Die ATM-Zelle ...................................................................................................... 152.1.2. Virtuelle Verbindungen.......................................................................................... 162.1.3. Dienstgüte (QoS) und Anpassungsschichten......................................................... 172.1.4. Die drei Ebenen des ATM-Referenzmodells ......................................................... 192.1.5. Endgeräte und Switches ........................................................................................ 202.1.6. Netztopologien und Routing.................................................................................. 20

2.2. Allgemeine Sicherheitsprobleme in ATM-Netzen ............................................................. 212.2.1. Angriffe auf die Verfügbarkeit .............................................................................. 222.2.2. Angriffe auf die Vertraulichkeit............................................................................. 222.2.3. Angriffe auf die Integrität und Authentizität ......................................................... 23

3. „Security Framework“ und Spezifikationen .............................................................................. 25

3.1. ATM Security Framework 1.0............................................................................................ 253.1.1. Potentielle Bedrohungen für ein ATM-Netz.......................................................... 253.1.2. Sicherungsziele und Anforderungen an Sicherheitsdienstgüte ............................. 27

3.1.2.1. Identitätskontrolle ..................................................................................... 273.1.2.2. Zugriffskontrolle und Autorisierung......................................................... 273.1.2.3. Wahrung der Vertraulichkeit ..................................................................... 273.1.2.4. Wahrung der Datenintegrität ..................................................................... 273.1.2.5. Sichere Rechnungserstellung („Accounting“) .......................................... 283.1.2.6. Protokollierung („Logging“)..................................................................... 283.1.2.7. Reporterstellung........................................................................................ 283.1.2.8. Audit ......................................................................................................... 293.1.2.9. Wiederherstellung eines ordentlichen Betriebs, Sicherheitsmanagement 29

3.1.3. Bewertung des ATM Security Frameworks........................................................... 293.2. ATM Forum Security Specification 1.0 ............................................................................. 29

3.2.1. Dienste für die User Plane..................................................................................... 303.2.1.1. „Entity Authentication“ ............................................................................ 303.2.1.2. Vertraulichkeit........................................................................................... 303.2.1.3. Datenintegrität und -authentizität ............................................................. 31

3.2.2. Dienste für die Control Plane ................................................................................ 313.2.3. Unterstützende Dienste.......................................................................................... 32

3.2.3.1. Drei-Wege Protokoll für „in-band“ Einsatz .............................................. 323.2.3.2. „Signaling-based“ zwei-Wege Protokoll .................................................. 34

3.2.4. Zusammenfassung und offene Punkte ................................................................... 36

5

4. Standardprotokolle in ATM-Netzen ........................................................................................... 37

4.1. ‘Integrated Local Management Interface’ (ILMI 4.0) ....................................................... 374.1.1. Funktionsweise von ILMI ..................................................................................... 374.1.2. ILMI-Protokoll ...................................................................................................... 384.1.3. Angriffsmöglichkeiten........................................................................................... 44

4.1.3.1. Emulieren eines ATM-Switches ............................................................... 444.1.3.2. Registrieren nicht-konformer ATM-Adressen .......................................... 45

4.1.4. Gegenmaßnahmen................................................................................................. 464.1.4.1. Verhindern der Switch-Emulation an UNI-Schnittstellen......................... 464.1.4.2. Verhindern beliebiger Adreßregistrierungen............................................. 46

4.2. ‘User Network Interface 3.1/4.0’ (UNI) ............................................................................ 484.2.1. Funktionsweise von UNI ....................................................................................... 48

4.2.1.1. Aufbauen einer Punkt-zu-Punkt-Verbindung............................................ 494.2.1.2. Aufbauen einer Punkt-zu-Mehrpunkt-Verbindung................................... 504.2.1.3. Abbauen einer Punkt-zu-Punkt-Verbindung............................................. 514.2.1.4. Abbauen einer Punkt-zu-Mehrpunkt-Verbindung..................................... 52

4.2.2. Angriffsmöglichkeiten........................................................................................... 544.2.2.1. Angriff auf die Authentizität der Signalisierungsnachrichten .................. 554.2.2.2. Angriffe auf die Integrität der Zellen........................................................ 554.2.2.3. DoS-Angriffe basierend auf UNI.............................................................. 55

4.2.2.3.1. DoS durch Reservieren von Netz-Betriebsmitteln ....................... 564.2.2.3.2. DoS durch exessives Signalisieren ............................................... 574.2.2.3.3. DoS durch Aufbrauchen der Endsystembetriebsmittel ................ 57

4.2.3. Gegenmaßnahmen................................................................................................. 584.2.3.1. Verhindern von Angriffen auf die Authentizität ....................................... 58

4.3. ‘Private Network Network Interface’ (PNNI).................................................................... 664.3.1. Funktionsweise von PNNI..................................................................................... 66

4.3.1.1. Wegwahl (Routing) in ATM-Netzen......................................................... 664.3.1.2. Switch-übergreifende Verbindungsverwaltung in ATM-Netzen............... 67

4.3.2. Angriffsmöglichkeiten........................................................................................... 674.3.3. Gegenmaßnahmen................................................................................................. 68

4.4. Zusammenfassung: Absicherung der Standardprotokolle ................................................. 69

5. ‘Classical IP and ARP over ATM’ (CLIP) ................................................................................. 71

5.1. Funktionsweise von CLIP .................................................................................................. 715.1.1. Format der Dateneinheiten bei CLIP..................................................................... 745.1.2. Verbindungsmanagement für CLIP ....................................................................... 755.1.3. ATM- zu IP-Adreßauflösung ................................................................................. 77

5.1.3.1. Registrierung eines Clients (RFC2225) .................................................... 785.1.3.2. Anfrage eines Clients (RFC2225)............................................................. 80

5.2. Angriffsmöglichkeiten ....................................................................................................... 825.2.1. Angriffe auf den ATMARP-Server........................................................................ 835.2.2. Angriffe auf den LIS-Client .................................................................................. 865.2.3. Angriffe durch Umgehen von IP-Firewalls ........................................................... 89

5.3. Gegenmaßnahmen.............................................................................................................. 90

6

5.3.1. Absichern des ATMARP-Servers.......................................................................... 905.3.2. Integration eines IP-Firewalls................................................................................ 92

6. ‘Server Cache Synchronization Protocol’ (SCSP) ..................................................................... 95

6.1. Funktionsweise des SCSP.................................................................................................. 956.1.1. Hello Protocol........................................................................................................ 956.1.2. Cache Alignment Protocol .................................................................................... 976.1.3. Cache State Update Protocol ................................................................................. 98

6.2. Angriffsmöglichkeiten ....................................................................................................... 996.2.1. Generische Angriffsmöglichkeiten........................................................................ 996.2.2. Indirekte Angriffsmöglichkeiten ......................................................................... 101

6.2.2.1. Beispiel: DoS-Angriff auf ATMARP-SG ............................................... 1016.3. Gegenmaßnahmen............................................................................................................ 102

6.3.1. Generische Angriffe abwehren............................................................................ 1026.3.2. Protokollspezifische Angriffe abwehren ............................................................. 103

7. ‘Local Area Network Emulation’ (LANE) ............................................................................... 105

7.1. Funktionsweise von LANE.............................................................................................. 1067.1.1. LEC-Initialisierung.............................................................................................. 108

7.1.1.1. LEC Startzustand .................................................................................... 1097.1.1.2. LEC kontaktiert den LECS ..................................................................... 1107.1.1.3. LEC erfragt die LES-Adresse ................................................................. 1107.1.1.4. LEC meldet sich beim LES an................................................................ 1117.1.1.5. Initiale Adreßregistrierungen .................................................................. 1137.1.1.6. LEC kontaktiert den BUS ....................................................................... 114

7.1.2. Typische LEC-Kommunikationsabläufe ............................................................. 1157.1.2.1. Adreßauflösung bei der LANE ............................................................... 1167.1.2.2. MAC-Datenaustausch zwischen zwei LECs........................................... 116

7.2. Angriffsmöglichkeiten ..................................................................................................... 1197.2.1. Angriffe auf die Dienste ...................................................................................... 120

7.2.1.1. DoS-Angriff auf einen BUS.................................................................... 1207.2.1.2. DoS-Angriff auf einen LES .................................................................... 120

7.2.2. Angriffe auf die Clients ....................................................................................... 1217.2.2.1. Angreifer manipuliert die LECS-Konfiguration (DoS) .......................... 1217.2.2.2. Angreifer manipuliert die LECS-Konfiguration (MiM) ......................... 1217.2.2.3. Angreifer benutzt BUS für Spoofing ...................................................... 1237.2.2.4. Angreifer benutzt LES für DoS-Angriff auf LEC .................................. 124

7.3. Gegenmaßnahmen............................................................................................................ 1247.3.1. Angriffe auf die Dienste abschwächen................................................................ 124

7.3.1.1. Verringern der Auswirkungen von DoS auf den BUS ............................ 1247.3.1.2. Verringern der Auswirkungen von DoS auf den LES............................. 1257.3.1.3. Abschwächen der Proxy-LEC-basierten DoS-Angriffe auf BUS/LES... 128

7.3.2. Angriffe auf die Clients abschwächen................................................................. 1297.3.2.1. Angriffe basierend auf kompromittierten LECS verhindern .................. 129

7.3.3. Weitere Gegenmaßnahmen.................................................................................. 133

7

7.4. Zusätzliche Probleme bei redundanter Auslegung der LANE-Server ............................. 1337.4.1. Die Sicht des LEC ............................................................................................... 1337.4.2. Redundante Auslegung der LECS....................................................................... 1337.4.3. Redundante Auslegung der LES und der BUS.................................................... 1347.4.4. Selective Multicast Server ................................................................................... 1347.4.5. Angriffsmöglichkeiten......................................................................................... 1347.4.6. Gegenmaßnahmen............................................................................................... 135

8. Zusammenfassung und Ausblick............................................................................................... 137

Glossar ............................................................................................................................................. 139

Literaturverzeichnis ....................................................................................................................... 155

8

Abbildungsverzeichnis2-1. ATM-Zellkopf ............................................................................................................................. 162-2. Schematische Darstellung des ‘Switching’ ................................................................................. 172-3. ATM-Anpassungsschichten......................................................................................................... 193-1. „Three-Way Security Message Exchange Protocol“ (vgl. AFo99b) ........................................... 323-2. „Two-Way Security Message Exchange Protocol“ (vgl. AFo99b) ............................................. 344-1. ILMI-Protokollstapel................................................................................................................... 384-2. ILMI-Connectivity Procedures.................................................................................................... 394-3. ILMI Automatic Configuration Procedures (User-Side)............................................................. 404-4. ILMI Automatic Configuration Procedures (Network-Side) ...................................................... 414-5. ILMI ATM-Adreßregistrierung ................................................................................................... 434-6. Endsystem gibt sich als Switch aus............................................................................................. 444-7. Signalisierung einer Punkt-zu-Punkt-Verbindung....................................................................... 494-8. Signalisierung einer Punkt-zu-Mehrpunkt-Verbindung .............................................................. 504-9. Abbauen einer Punkt-zu-Punkt-Verbindung ............................................................................... 524-10. (Teil-)Abbauen einer Punkt-zu-Mehrpunkt-Verbindung........................................................... 534-11. DoS durch CBR-Reservierung .................................................................................................. 565-1. IP-Netz mit mehreren Subnetzen ................................................................................................ 725-2. ATM-Netz mit zwei LIS.............................................................................................................. 735-3. CLIP Protokollstapel ................................................................................................................... 755-4. CLIP-Client registriert sich beim Server..................................................................................... 795-5. CLIP-Client befragt den Server................................................................................................... 815-6. Angreifer reserviert IP-Adresse als Vorbereitung für ‘Man-in-the-Middle’-Angriff.................. 845-7. Aktiver ‘Man-in-the-Middle’-Angriff ......................................................................................... 875-8. Umgehung eines IP-Firewalls ..................................................................................................... 896-1. Zustände des ‘Hello’-(Protokoll-)Automaten (aus LAH98) ....................................................... 967-1. Zwei ELANs koppeln Ethernet- und Token Ring LANs über einem physikalischen ATM-Netz

1057-2. Initialisierung eines LEC (aus AFo97)...................................................................................... 1087-3. Lokale LEC Initialisierung und Anfrage an den LECS ............................................................ 1107-4. Registrierung beim LES ............................................................................................................ 1127-5. Registrierung beim BUS............................................................................................................ 1147-6. Adreßauflösung beim LES ........................................................................................................ 1167-7. Kommunikation zwischen zwei LECs ...................................................................................... 1177-8. Kommunikation über BUS mit anschließendem ‘Flush’-Protokoll .......................................... 118

Beispiele4-1. Deaktivieren der Auto-Konfiguration und Konfigurieren des Schnittstellentyps........................ 464-2. Deaktivieren der Adreßregistrierung und der Signalisierung...................................................... 474-3. Fixieren der Prefixe registrierbarer ATM-Adressen .................................................................... 474-9. Dedizierte Adresse des Internetzugangs (IZ) .............................................................................. 65

9

4-10. Löschen des PNNI-PVCs .......................................................................................................... 697-1. LECS-Datenbank konfigurieren ................................................................................................ 1277-2. LECS aktivieren ........................................................................................................................ 1277-3. LEC/BUS einrichten.................................................................................................................. 1287-4. Broadcast via Proxy-LEC eindämmen ...................................................................................... 129

10

VorwortDieser Online-Ratgeber diskutiert Sicherheitsprobleme in ATM-Netzen. Der Schwerpunkt liegt hier-bei auf der Analyse der protokollinhärenten Sicherheitsmängel der ATM-Protokolle. Es werden Pro-tokolle untersucht, die mittelbar oder direkt der Unterstützung der TCP/IP-Protokollfamilie über ATMdienen. Hiermit wird zwei wichtigen Aspekten in der Netzwerkwerksicherheit nachgekommen: Er-stens steigt der Anteil des über ATM transportierten Datenvolumens.Diese Daten werden jedoch nichtdirekt von ATM übertragen, sondern meist durch das Internetprotokoll (IP), das sich als der Standardfür die Datenübertragung etabliert hat. Zweitens gibt es nach wie vor erhebliche Sicherheitsmän-gel bei der Verwendung der TCP/IP-Protokollfamilie, die nun durch die Verwendung von ATM alsÜbertragungsmediumdurch die ATM-inhärenten Sicherheitsmängel verstärkt werden. Es ist daher er-forderlich, die neuen Sicherheitsprobleme durch ATM zu analysieren, um rechtzeitig Lösungsansätzeaufzuzeigen bzw. verbleibende Probleme zu benennen.

An dieser Stelle möchte ich den folgenden (Ex-)Kollegen und (ehemaligen) Studenten für die vielen,nützlichen Hinweise und Verbesserungsvorschläge danken (alphabetisch sortiert): Herr Dr. Uwe El-lermann, Herrn Gregor Goldbach,Herrn Stephan Holst, HerrMichael Krooß, Herrn Dr. Hans-JoachimMück und Herrn Heino Peters.

11

Vorwort

12

Kapitel 1. EinleitungDies ist der Online Ratgeber des Firewall-Labors für Hochgeschwindigkeitsnetze. Dieser Ratgeber istin zwei Online-Versionen verfügbar:

• als HTML-Version (http://www.fwl.dfn.de/fwl/ratgeber/ratgeber.html)

• als Postscript Version (.gz) (http://www.fwl.dfn.de/fwl/ratgeber/ratgeber.ps.gz)

Bitte beachten Sie die beiden folgenden organisatorischen Hinweise.

1.1. Aufbau des RatgebersIn Abschnitt 2.1 wird eine kurze Einführung in die wichtigsten Konzepte und Begriffe der ATM-Technik gegeben. Dieser Abschnitt legt die Grundlage für die Diskussion der konzeptionellen Sicher-heitsrisken in ATM-Netzen, die in Abschnitt 2.2 diskutiert werden.

Neben den konzeptionellen Schwächen von ATM gibt es zusätzliche Probleme beim Einsatz bestimm-ter Dienste im ATM-Netz. Diese speziellen Problemewerden anhand der zu verwendenden Protokollein den einzelnen Abschnitten aufgezeigt. Die Diskussion von Lösungsansätzen und Empfehlungen zurAbsicherung der Dienste werden ebenfalls in diesen Abschnitten diskutiert.

1.2. Hinweise für den LeserFalls noch keine Kenntnisse im Bereich ATM vorhanden sind, sollte in jedem Fall die Einführung inATM gelesen werden. In den darauf folgenden Abschnitten werden viele der dort eingeführten Be-griffe vorausgesetzt. Der Abschnitt über konzeptionelle Sicherheitsrisiken bei ATM ist in jedem Falllesenswert, da hier die grundsätzlichen Probleme diskutiert werden, die in den späteren Abschnittenimmer wieder auftauchen und beachtet werden müssen.

Die Diskussion der einzelnen Protokolle und Dienste kann je nach Leserinteresse erfolgen. Zu be-achten ist hierbei allerdings, daß es zwischen einigen Protokollen Abhängigkeiten gibt. Da einigeProtokolle andere voraussetzen, deren Dienste sie nutzen, sollten die einleitenden Hinweise zu denAbhängigkeiten in den jeweiligen Kapiteln beachtet werden.

1.3. Ein Online Ratgeber für ATM-SicherheitATM („Asynchronous Transfer Mode“) ist eine weit verbreitete Netztechnik, die aus der modernenKommunikationslandschaft nicht mehr wegzudenken ist. ATM wird von vielen Providern weltweit

13

Kapitel 1. Einleitung

eingesetzt. Darüber hinaus gibt es viele Unternehmen, die ebenfalls ein ATM-Netz unterhalten, bei-spielsweise als schnelles „Backbone“-Netz.

In diesem Online Ratgeber werden jedoch keine allgemeinen Betrachtungen zu den Vor- oder Nach-teilen eines Einsatzes von ATM im Vergleich mit einer anderen Netzwerktechnologie angestellt. Viel-mehr wird von folgender Konstellation ausgegangen:

• Es ist bereits eine Entscheidung für die ATM-Technik gefallen, bzw. es ist bereits eine ATM-Installation vorhanden.

• ATM wird nicht nur im „Backbone“-Netz eingesetzt, sondern mehrere Produktionsrechner sinddirekt an das ATM-Netz angeschlossen und tauschen auf Basis des Internet Protokolls (IP) Datenaus.

• Es gibt verschiedene Sicherheitsdomänen mit unterschiedlichen Schutzbedürfnissen. Es ist somitdie Notwendigkeit für die Integration von Sicherheitsmechanismen in die Netzwerkinstallation ge-geben.

Sind die obigenAnnahmen nicht zutreffend, ist dieser Online Ratgeber nur von sehr geringemNutzen.

ATM ist für den Transport unterschiedlicher Daten konzipiert worden. Neben der herkömmlichenDatenkommunikation, die vor allem im LAN eingesetzt wird, unterstützt ATM auch den Transportvon multimedialen Daten, beispielsweise Video und Sprache. Hier ist es wiederum von Vorteil, einphysikalisches Netz für verschiedene Informationsarten zu benutzen. Unternehmen können sich durchATM sowohl Internet-Dienste als auch Telephonie über „ein Kabel“ erschließen.

Zur Unterstützung von multimedialen Diensten bietet ATM das Aushandeln von Dienstgüte (vgl.„Quality of Service“, QoS) an. So wird es möglich, Reservierungen von Netzkapazitäten durchzufüh-ren, um beispielsweise die bei Sprachdiensten kritischen Verzögerungen durch das Netz in den Griffzu bekommen, oder sich für wichtige Datenübertragungen eine bestimmte Übertragungsgeschwin-digkeit zu reservieren.

Durch den zunehmenden Einsatz dieser Technik werden jedoch auch die damit verbundenen Sicher-heitsrisiken erkennbar. Dieser Online Ratgeber soll daher für gängige ATM-Protokolle die konzeptio-nellen Schwächen aufzeigen und helfen, typische Einsatzszenarien gegen potentielle Angriffe abzu-sichern.

Dazu ist es erforderlich, sowohl eine Einführung in ATM zu geben, als auch jedes einzelne Proto-koll hinreichend genau zu beschreiben. Nur so kann anschließend eine Risikoanalyse die inhärentenSicherheitsrisiken aufzeigen. Es wird darüber hinaus versucht, wenn möglich, Hinweise für Gegen-maßnahmen zu geben.

14

Kapitel 2. Einführung in ATM und generischeSicherheitsprobleme

Die folgenden Grundlagen sind für ein Verständnis der nachfolgenden Kapitel wichtig. Falls Kennt-nisse in ATM vorhanden sind, kann dieses Kapitel jedoch übersprungen werden. Es werden lediglichdie wesentlichen Konzepte der ATM-Technologie vorgestellt.

2.1. Einführung in ATMIn diesem Abschnitt wird eine knappe Einführung in die ATM-Technik gegeben, um die Diskus-sion in den folgenden Abschnitten vorzubereiten. Insbesondere wird versucht, die Unterschiede zuklassischen LAN Protokollen und Netzen herauszuarbeiten. Eine allgemeinere Darstellung der ATM-Technik findet man beispielsweise in Hei97 und Gin99.

2.1.1. Die ATM-ZelleIm Gegensatz zu anderen Protokollen, bei denen die Paketlänge innerhalb protokollspezifischer Gren-zen variabel ist, wird bei ATM mit einer festgelegten Paketgröße gearbeitet. Eine ATM-Dateneinheitist genau 53 Byte lang. 48 Byte sind Nutzdaten, die verbleibenden 5 Byte sind Kontrollinformationen.Man bezeichnet ATM-Dateneinheiten im allgemeinen als Zellen (‘Cells’).

Die feste Länge hat Vorteile gegenüber einer variablen Größe:

Einfacher Hardware-Aufbau

Durch die feste Größe vereinfacht sich der Hardware-Aufbau von aktiven Netzkomponenten(Switches und ATM-Schnittstellen der Endgeräte). Es wird beispielsweise keine Funktion benö-tigt, die die Länge der Dateneinheit bestimmt.

Konstante Verzögerung in Switches

Die Bearbeitungszeit einer Zelle in einem Switch kann exakt angegeben werden. Außerdemist diese Zeit für alle Zellen gleich. Daraus ergeben sich besser kalkulierbare Ende-zu-EndeVerzögerungszeiten, wovon besonders Anwendungenmit isochronem1 Datenverkehr profitieren.

Leichtes Multiplexen von vielen ‘virtuellen Verbindungen’

Das Multiplexen von Zellen verschiedener Verbindungen über ein physikalisches Medium wirdebenfalls erleichtert. Durch die geringe Größe der Zellen ist ein Mixen von verschiedenenDaten-strömen einfach. Die Verzögerungszeiten bis zum Senden der nächsten Zelle eines Datenstroms

15

Kapitel 2. Einführung in ATM und generische Sicherheitsprobleme

kann wiederum berechnet werden, bzw. bei einer festgelegten Scheduling-Strategie in einemSwitch kann der benötigte Speicherplatz berechnet werden, der für Zellen der Verbindungen be-nötigt wird. Dies ist ein Vorteil gegenüber den Vorgängern von ATM, wie beispielsweise X.25oder Frame Relay mit jeweils variabler Paketlänge.

Im Gegensatz zur synchronen Übertragung, bei der die Informationen jeder Verbindung in festenZeitabständen gesendet werden müssen, können bei ATM-Verbindungen die Zellen auch asyn-chron versendet werden (daher der Name!). Hierzu trägt jede Zelle die entsprechendenMultiple-xinformationen im Zellkopf (VPI,VCI s.u.). Dies ist ein Vorteil gegenüber den Vorgängern ausdem Telefonbereich, wie beispielsweise STM.

In der folgenden Abbildung ist der Aufbau der ATM-Zellköpfe dargestellt (vgl. Abbildung 2-1).Dieses Zellformat ist an der Schnittstelle zwischen Endgeräten und Switch gültig. An der Schnitt-stelle zwischen zwei Switches gilt ein etwas anderes Zellformat. In diesem Fall ist der ‘Virtual PathIdentifier’ 12 statt 8 Bit lang, die ‘General Flow Control’ Bits entfallen dafür. Hinter diesem Zellkopffolgen immer genau 48 Byte Nutzdaten.

Abbildung 2-1. ATM-Zellkopf

Byte 3Byte 2Byte 1 Byte 4 Byte 5

GFC HECCLPPT

GFC VPI Virtual Path Identifier

VCI Virtual Channel Identifier

General Flow Control

PT Payload Type

CLP Cell Loss Priority HEC Header Error Check

VCIVPI

2.1.2. Virtuelle VerbindungenDie in jeder Zelle vorhandenen Multiplexinformationen setzen sich zusammen aus dem sogenann-ten ‘Virtual Path Identifier’ (VPI) und dem ‘Virtual Channel Identifier’ (VCI). Diese insgesamt 24Bit reichen nicht aus, um ATM-Endgeräte zu identifizieren. Vielmehr haben die Paare aus (VPI,VCI)nur lokale Bedeutung zwischen zwei Switches bzw. zwischen Switch und Endgerät. Die Werte für

16


(VPI,VCI) der Zellen einer Verbindung können sich in jedem Switch ändern. Jeder Switch führt dazueine Tabelle mit Zuordnungen von Schnittstellennummer und (VPI,VCI) zu einer weiteren Schnitt-stelle (Port) mit möglicherweise anderen Werten von (VPI,VCI). Diese Tabelle wird durch Nach-richten aktualisiert, deren Zellen standardisierte, vorkonfigurierte (VPI,VCI)-Kennungen verwendenmüssen (vgl. Abschnitt 4.2).

Trifft nun eine Zelle an einem Port ein, durchsucht der Switch seine Tabelle, trägt das Tupel von(VPI,VCI) des Ausgangsport in die Zelle ein und versendet die Zelle auf demAusgangsport. In Abbil-dung 2-2 ist dies für eine Verbindung zwischen zwei Rechnern (A,B) schematisch dargestellt. SendetRechner A Zellen mit dem (VPI,VCI) Tupel (0,50), dann empfängt der Switch diese Zellen (undmög-licherweise weitere Zellen anderer Verbindungen) über Port 3. Aus seiner Tabelle erkennt der Switch,daß er diese Zellen an Port 5 ausgeben muß. Außerdem kopiert der Switch das neue Tupel (7,22) indie Zelle. Der zweite Switch geht analog vor, so daß bei Rechner B die Zellen dieser Verbindung mitdem (VPI,VCI) Tupel (7,101) eintreffen.

Entscheidend ist, daß aufgrund der lokalen Bedeutung der Multiplexinformation, diese in wenigenBits untergebracht werden kann. Rechner B kann an A über dieselbe Verbindung zurücksenden. Dazuträgt B in die Zellen das Tupel (7,101) ein. A erhält diese Zellen mit (0,50).

Abbildung 2-2. Schematische Darstellung des ‘Switching’

1

2

4

5

3 6

1

2

3

4

6

5

1

1A B

Port, VPI, VCI Port, VPI, VCI Port, VPI, VCI Port, VPI, VCI

3, 0, 50 <-> 5, 7, 22 2, 7, 22 <-> 4, 7, 101 1, 7, 1011, 0, 50

Die Verbindung zwischen A und B wird ‘virtuelle Verbindung’ genannt. Die Verbindung ist virtuell,da es sich weiterhin um Paketvermittlung (‘Zellswitching’) handelt. Verbindungscharakter hat ATM,da das Einrichten der Tabelle in den Switches und den Endgeräten analog zu einem ‘Durchwählen’beim Telefonnetz vor dem Senden der Daten stattfinden muß. Dies kann statisch2 durch Konfigurierender beteiligten Switches erfolgen. In diesem Fall spricht man auch von ‘Permanent Virtual Connec-tions’ (PVC). Wird der Verbindungsaufbau hingegen dynamisch3 bei Bedarf durchgeführt, sprichtman von ‘Switched Virtual Connections’ (SVC). Der dynamische Verbindungsauf- und -abbau wirdals ‘Signalisierung’ bezeichnet. Die Geräte in einem ATM-Netz benutzen zur Signalisierung eigensentwickelte Protokolle, deren Zellen voreingestellte (VPI,VCI) Zuordnungen benutzen.

2.1.3. Dienstgüte (QoS) und Anpassungsschichten

17


Bei der Signalisierung können auch bestimmte Anforderungen der Anwendungen an das Netz aus-gehandelt werden. Diese als Dienstgüte (QoS, ‘Quality of Service’) spezifizierten Parameter werdensowohl dem Netz, als auch dem Kommunikationspartner bei der Signalisierung mitgeteilt. Das Netzund der Kommunikationspartnermüssen beide den Anforderungen zustimmen, bevor die Verbindungbenutzt werden kann. Kann eine der beteiligten Instanzen (Netz, Endgeräte) die Betriebsmittel fürdie geforderte QoS nicht bereitstellen, wird die Verbindung mit einer entsprechenden Fehlermeldungabgelehnt.

Neben typischen QoS Parametern,wie beispielsweise die tolerierbare Ende-zu-EndeVerzögerung vonZellen oder auch die benötigte Übertragungsgeschwindigkeit, wird bei der Signalisierung auch eineAnpassungsschicht (AAL, ‘ATM Adaption Layer’) ausgewählt, über die Dateneinheiten der höherenProtokolle (z.B. IP) versendet werden sollen. Die Hauptaufgabe der Anpassungsschicht ist die Be-reitstellung eines von den Zellen unabhängigen Paketformates, das den Anforderungen der höherenProtokolle entgegenkommt. Der wichtigste Dienst dieser Anpassungsschicht ist daher das Segmen-tieren von Dateneinheiten der Anpassungsschicht in Zellen bzw. das Zusammenfügen von Zellen zuDateneinheiten der jeweiligen Anpassungsschicht.

Es gibt verschiedene AAL-Typen. Für das Signalisieren von ATM-Verbindungen gibt es eine eige-ne AAL, die die gesicherte Übertragung des jeweiligen Signalisierungsprotokolls bereitstellt. FürLAN-Kommunikation gibt es zwei verschiedene Anpassungsschichten: Die AAL3/4 und die AAL5.Die AAL5 ist besonders auf den bei IP üblichen ‘Best Effort Dienst’ ausgerichtet. Der Dienst die-ser Schicht besteht in der Übertragung von Paketen unter Beibehaltung der Reihenfolge und in derErkennung von Übertragungsfehlern. Fehlerhafte Daten werden erkannt und vernichtet jedoch nichtautomatisch neu angefordert. Eine Zusammenfassung der möglichen AALs und deren Eignung fürAnwendungsklassen ist in Abbildung 2-3 dargestellt. Die Anwendungsklassen unterscheiden sich indrei wesentlichen Merkmalen:

Zeitrelation

Wenn die Anwendungen (Sender und Empfänger) synchron arbeiten müssen, beispielsweise beider Übertragung von isochronen Daten (z.B. Sprache über Telefon), dann ist eine Synchronisa-tion der Endgeräte/Anwendungen nötig.

Bitrate

Ist hierbei eine feste Bitrate erforderlich? Beispielsweise brauchen Telefongespräche 64Kbit/spro Richtung. Ein MPEG kodierter Videostrom benötigt abhängig vom Bildinhalt eine variableBitrate. Beide Anwendungen erfordern jedoch eine Synchronisation der Anwendungen.

Verbindungsart

Die Art der Kommunikationsbeziehung ist das dritte Merkmal. Benötigen die beiden Kommu-nikationspartner eine Verbindung oder werden Dateneinheiten zustandslos als Datagramme ver-

18


sendet? Eine Verbindung bietet grundsätzlich mehr Möglichkeiten, z.B. Erkennen von Datenver-lust, ist aber auch deutlich aufwendiger als ein Datagrammdienst.

Hieraus resultieren insgesamt vier Dienstklassen, die in nicht eindeutiger Weise den vier AALszugeordnetwerden können. Beispielsweise kann AAL 3/4 sowohl einen verbindungslosen (‘Message-Mode’) als auch einen verbindungsorientierten (‘Stream-Mode’) Dienst anbieten.

Abbildung 2-3. ATM-Anpassungsschichten

keine festgelegte Zeitrelationfeste Zeitrelation

Anwendung ist verbindungsorientiert

AAL 1

Klasse DKlasse A

verbindungs-los

AAL 3/4AAL 5

feste Bitrate

AAL 2

Klasse B Klasse C

variable Bitrate

2.1.4. Die drei Ebenen des ATM-ReferenzmodellsDas ATM-Referenzmodell ordnet die Funktionen, Dienste und physikalischen Übertragungsverfah-ren drei Ebenen zu. Es handelt sich hierbei um die Nutzerebene (Userplane), die Managementebene(Managementplane) und die Steuerungsebene (Controlplane).

Nutzerebene

Die Nutzerebene stellt den einzelnen Anwendungen den Zugang zu den verschiedenen obendiskutierten Anpassungsschichten zur Verfügung.

Managementebene

Die Managementebene koordiniert den Zugriff der Nutzer des ATM-Netzwerks auf die einzelnenManagementeinheiten der ATM-Schicht. Beispielsweise gibt es für jedes Modul zur physikali-

19


schen Signalübertragung auf der ATM-Schicht ein eigenes Managementmodul. Darüber hinausgibt es Managementfunktionen, die unabhängig von physikalischenÜbertragungsverfahren sind.Hierzu zählen die Funktionen des Fehler- und Leistungsmanagements, die mit Hilfe der „OAMflows“ (Operation, Administration and Maintenance) erbracht werden.

Steuerungsebene

Hier sind die Funktionen für die Signalisierung zusammengefaßt. Die Steuerungsebene kannman sich auch als Teil der Managementebene vorstellen. Häufig wird die Signalisierung daherauch als Verbindungsmanagement bezeichnet.

2.1.5. Endgeräte und SwitchesEin ATM-Netz besteht aus ATM-fähigen Endgeräten und ATM-Switches. Die ATM-Switches sindaus der Sicht der Endgeräte die Zugangspunkte zum ATM-Netz. Da ATM, wie oben dargestellt, of-fen für verschiedenste Anwendungen ist, gibt es auch eine Vielzahl verschiedener ATM-Endgeräte.Beispielsweise gibt es Telefonanlagen für ATM-Netze oder auch Computer-Schnittstellen (‘ATM-Karten’). Der Anschluß an das ATM-Netz erfolgt über eine Vielzahl möglicher Medien, beispielswei-se Glasfaserkabel oder Kupferkabel.

Die Switches gestatten in der Regel das individuelle Konfigurieren von Subnetzen. Beispielsweiseerfolgt das Einrichten von PVCs auf den Switches durch Konfigurieren der entsprechenden Tabellenmit der Zuordnung von (VPI,VCI) Tupel zu Ports. Außerdem können für beliebige PVCs auf denSwitches bestimmte QoS-Merkmale konfiguriert werden.

2.1.6. Netztopologien und RoutingDer Verbindungsaufbau von ATM erfordert eine eindeutige Identifizierung von Endgeräten. Dazuwird eine 20 Byte lange ATM-Adresse verwendet, die einem der drei standardisierten Formate genü-gen muß:

‘Data Country Code’ (DCC)

Teile der Adresse (die ersten zwei Byte) identifizieren ein Land, in dem die jeweilige Adresseregistriert ist. Darauf folgt ein 18-Byte langer ‘Domain Specific Part’ (DSP). Die Struktur undBedeutung dieses DSPs ist länderspezifisch.

20


‘E.164’

Hierbei handelt es sich um eine internationale, maximal 15-stellige ISDN-Nummer.

‘International Code Designator’ (ICD)

Internationale Organisationen können eine Kodenummer registrieren lassen, die als BCD-Zahl4

in die ATM-Adresse ihrer Geräte konfiguriert wird. Da die Kodenummer maximal 2 Byte langist, werden bei der BCD-Kodierung keine 20 Byte benötigt, so daß freie Stellen mit ’FF’ (255)aufgefüllt werden. Typischerweise sind Switches mit ICD-Adressen vorkonfiguriert und kön-nen vom Administrator andere Adressen zugewiesen bekommen. Ähnlich der DCC-Adressen istdann die Interpretation der folgenden DSP-Byte firmenspezifisch.

Entscheidend ist, daß eine ATM-Adresse 20 Byte lang ist und sich abhängig vom Adreßformat dieInterpretation dieser 20 Byte ändert.

Die Formate DCC und E.164 eignen sich durch ihren Aufbau besonders gut für ein hierarchischesRouting. Ein Switch kann aufgrund eines Adreßprefixes entscheiden, welcher Ausgang bei der Si-gnalisierung benutzt werden muß. Der nächste Switch trifft eine weitere Entscheidung aufgrund eineslängeren Prefixes der Adresse. Nimmt man beispielsweise an, daß jeder Switch immer ein Byte mehrals Adreßprefix interpretiert als sein Vorgänger5, dann kann man mit den 20 Byte der ATM-Adresseeine 19 stufige Hierarchie aufbauen. Das 20. Byte der Adresse wird nicht für die Wegwahl benutzt,sondern dient der Unterauswahl auf einem Gerät.

Für eine dynamische Wegwahl bei der Verbindungseröffnung werden die Switches nicht mit stati-schen Zuordnungen von Adreßprefixen zu Ports konfiguriert, sondern es werden Routing-Protokolleeingesetzt, die diese Zuordnung dynamisch anhand vonMetriken erlauben. Ein Beispiel ist das ‘Priva-te Network-to-Network’ (PNNI) Protokoll, das den Switches ein dynamisches hierarchisches Routingermöglicht.

Wesentlich ist hierbei, daß die Routing-Entscheidung in jedem Switch nur einmal bei der Signalisie-rung getroffen werden muß. Danach ist die virtuelle Verbindung etabliert und die Zellen werden nurnoch entlang der Verbindung weitergeleitet (‘forwarding’ bzw. ‘switching’), wie in Abschnitt 2.1.2dargestellt. Dies ist ein Unterschied gegenüber der Paketvermittlung von IP, bei der die Wegwahlent-scheidung für jedes Datagramm getroffen werden kann.

2.2. Allgemeine Sicherheitsprobleme in ATM-NetzenEs gibt allgemeine Sicherheitsprobleme beim Einsatz von ATM, die in dieser oder ähnlicher Formauch für andere Netztechnologien gelten.

21


Bei den untersuchten Protokollen werden grundsätzlich Aussagen zu Angriffen auf die

• Verfügbarkeit,

• Vertraulichkeit,

• Integrität und Authentizität

gemacht. Diese Angriffe können sich gegen Dateneinheiten, Nachrichten, Netzequipment und End-geräte richten. In den folgenden Unterabschnitten (vgl. Abschnitt 2.2.1 bis Abschnitt 2.2.3) werdendaher allgemeine Beispiele für diese Angriffe vorgestellt. Die protokollspezifischenAngriffsmöglich-keiten sind sozusagen Spezialfälle dieser allgemeinen Kategorien.

2.2.1. Angriffe auf die VerfügbarkeitSicherheitsmechanismen werden typischerweise entwickelt, um den unerlaubten Zugriff auf Netzbe-triebsmittel zu verhindern. Es ist jedoch mindestens genauso wichtig, daß die Netzbetriebsmittel fürden erlaubten Zugriff verfügbar sind.

Beispielsweise soll ein Sachbearbeiter jederzeit Zugriff auf alle für seine Arbeit erforderlichenDaten,Rechner, Drucker und sonstigen EDV-Geräte erhalten. Dies ist ein Grund für den Betrieb sogenannter„hochverfügbarer Systeme“, bei denen durch redundante Auslegung von Komponenten, Erkennen derAusfälle und Umschalten auf die Reserve-Komponente(n) die Ausfallzeiten minimiert werden.

Angriffe mit dem Ziel, den erlaubten Zugriff auf Netzbetriebsmittel zu unterbinden, zu stören oder zubehindern, werden als „Angriffe auf die Verfügbarkeit“ (neudeutsch: „Denial of Service“, DoS) be-zeichnet. Ein Angreifer versucht bei dieser Art von Angriffen den Betrieb zu behindern. Ein typischesBeispiel für diese Art von Angriffen ist der sogenannte „Ping of Death“.

Bei diesem Angriff sendet ein Angreifer ein ungültiges Datagramm (beispielsweise ein zu lan-ges) an einen Rechner. Aufgrund eines Implementierungsfehlers kann der Empfänger diesesnicht-protokollkonforme Datagramm nicht verarbeiten und es kommt zu einem Systemabsturz.Durch Versenden einer einzigen Dateneinheit wird ein ganzer Rechner außer Betrieb genom-men!

• Weiterführende Informationen vom CERT-CC (http://www.cert.org/advisories/CA-1997-28.html)zu "Ping of Death"

• Weiterführende Informationen vom CERT-CC (http://www.cert.org/tech_tips/denial_of_service.html)zu "Denial of Service"-Angriffen.

22


2.2.2. Angriffe auf die VertraulichkeitAngriffe auf die Vertraulichkeit sind weit verbreitet. Ein Angreifer benutzt ein Endgerät oder eineNetzkomponente, um Dateneinheiten mitzulesen. Typischerweise werden Kommunikationsbeziehun-gen zwischen Rechnern nicht verschlüsselt. Die Kenntnis der standardisierten Kommunikationsproto-kolle reicht daher aus, um die übertragenen Informationenmaschinell auszuwerten. Typische Vertreterdieser Angriffe auf die Vertraulichkeit sind die sogenannten „Sniffer-Attacks“.

Hierbei verwendet ein Angreifer einen beliebigen Computer in einem lokalen „broadcast“ Netz undkann die gesamte Kommunikation in diesem Netzsegment passiv abhören, ohne daß dies von denanderen Stationen am Netz bemerkt werden könnte.

2.2.3. Angriffe auf die Integrität und AuthentizitätAngriffe auf die Integrität und auf die Authentizität der Daten werden vom Angreifer aktiv durch-geführt, indem er entweder Informationen in zuvor abgehörten Dateneinheiten verändert (Integritäts-verletzung) und diese manipulierten Dateneinheiten weitersendet oder Dateneinheiten mit gefälsch-ten Adreßinformationen (Authentizitätsverletzung) erstellt und versendet. Diese Verfälschungen sindohne zusätzliche Maßnahmen nicht erkennbar, die Integrität der übertragenen Daten ist somit kom-promittiert.

Eine besondere Art der Integritätsverletzung stellt die Verfälschung von Adreßinformationen in denDateneinheiten dar. Ein Angreifer kann sich so als ein anderer ausgeben, indem er als Absenderadres-se nicht die eigene Adresse angibt, sondern eine andere Adresse. Hierbei handelt es sich um einenAngriff auf die Authentizität, da die Fälschung der Absenderadresse dazu dient, die Identität einesanderen vorzutäuschen (auch unter dem Namen „Spoofing“ bekannt).

DerartigeAngriffe sind weit verbreitet. Insbesondere bei der Verwendung des TCP/IP-Protokollskann ein Angreifer durch Angabe einer ‘vertrauenswürdigen Absenderadresse’ bei ungesicher-ten Installationen Zugriff auf die Systeme erlangen.

• Weiterführende Informationen zum ‘Spoofing’ bei TCP/IP (http://www.deter.com/unix/papers/tcpip_problems-bellovin.ps.gz).

• Weiterführende Informationen zum ‘Spoofing’ bei ATM (http://www.fwl.dfn.de/eng/team/cb/eng_natm/).

23


Fußnoten1. Bei isochronenVerbindungen bestehen zeitliche Abhängigkeiten zwischen den einzelnenDatenein-

heiten, die durch das Netz oder die Endgeräte möglichst nicht verändert werden sollten.

2. Bei Telefonnetzen ist dies vergleichbar mit ‘Standleitungen’.

3. Sozusagen eine Wählleitung.

4. ‘Binary CodedDecimal’ (BCD). Zahlenkodierung, bei der jede Dezimalziffer durch eine entsprechende4-bit Binärzahl dargestellt wird. Ein Byte kann demnach zur Kodierung von zwei Ziffern verwen-det werden.

5. Vorgänger im Sinne der Richtung, aus der die Signalisierung eintrifft.

24

Kapitel 3. „Security Framework“ undSpezifikationen

Das ATM Forum (http://www.atmforum.com) ist eine internationale Organisation mit dem Ziel, dieVerbreitung von ATM zu fördern. Teil der Gremienarbeit im ATM Forum ist die Spezifikation vonProtokollen für ATM Netze. Auch die in Kapitel 4 und in einigen darauf folgenden Kapiteln disku-tierten Protokolle sind vom ATM Forum spezifiziert worden.

In den folgenden Abschnitten sollen kurz die wesentlichen Aussagen des ATM Forums zum Stand derSicherheit von ATM-Netzen dargestellt werden. Dazu wird in Abschnitt 3.1 das „ATM Security Fra-mework“ vorgestellt. Darüber hinaus gibt es eine „ATM Security Specification“, die in Abschnitt 3.2vorgestellt wird und detailliert beschreibt, durch welche Erweiterungen bereits im Einsatz befindlicheProtokolle des ATM Forums zukünftig abgesichert werden sollen.

Die Kenntnis dieser Spezifikationen ist hilfreich, um im Einzelfall entscheiden zu können, welcheSicherungsaufgaben im Rahmen der vom ATM Forum spezifizierten Protokolle auch längerfristignicht erbracht werden. Ergibt sich hieraus ein großes Risiko, müssen andere Lösungen erarbeitetwerden. Die Arbeit des ATM-Forums ist sehr wichtig für die zukünftigeAbsicherung der ATM-Netze.Die Diskussion der entsprechenden Vorschläge nimmt daher einen breiten Raum ein, obwohl zur Zeitder Entstehung dieses Online-Ratgebers (Mitte 1999 bis Ende April 2001) noch keine wesentlichenDienste aus diesen Spezifikationen in Produkte umgesetzt worden sind. Dies ist eine Motivation fürdie Anfertigung des Online-Ratgebers. Längerfristig könnten jedoch wesentliche Sicherheitsaspektein ATM-Netzen durch die Implementierung der folgenden Dienste umgesetzt werden.

3.1. ATM Security Framework 1.0In dem „ATM Security Framework“ beschreibt das ATM Forum generische Anforderungen an die Si-cherheitsdienstgüte in ATM-Netzen AFo98. Diese Anforderungen ergeben sich aus den allgemeinenBedrohungen (Threats), denen ein ATM-Netz ausgesetzt ist.

Aus den generischen Sicherheitsanforderungen leitet das ATM Forum schließlich Sicherheitsfunk-tionen ab, die auf den verschiedenen ATM-Ebenen (Control-, User- und Management-Plane, vgl.Abschnitt 2.1.4) eingesetzt werden sollen, um die Sicherheitsanforderungen umzusetzen bzw. um dieZiele dieses Sicherheitsmanagements durchzusetzen.

3.1.1. Potentielle Bedrohungen für ein ATM-NetzDas ATM Forum erkennt neben vorsätzlichen Angriffen (intentional threats) Unfälle und schlechteAdministration als mögliche Ursachen für Sicherheitsvorfälle in ATM-Netzen an. Unfälle und unge-nügende Administration werden im weiteren Standardisierungsprozeß jedoch weitgehend ignoriert,können jedoch betrachtet werden, falls die Auswirkungen einem vorsätzlichen Angriff gleichkom-men.

25

Kapitel 3. „Security Framework“ und Spezifikationen

Als „generische Angriffe“ wird vom ATM Forum identifiziert:

Identitätsfälschung

Eine Instanz gibt sich als eine andere Instanz aus („spoofing“).

Abhören

Mit Hilfe eines Netzwerkmonitors werden Kommunikationsbeziehungen abgehört.

Unerlaubter Zugriff

Eine Instanz versucht auf Daten zuzugreifen, für die sie keine Zugriffsberechtigung hat.

Verlust oder Verfälschung von Informationen

Während der Datenübertragung kommt es zu unerlaubten Löschungen, Einfügungen, Modifika-tionen, Vertauschungen und Mehrfacheinspielungen von Daten.

Leugnen von Handlungen

Eine Instanz bestreitet ihre Teilnahme an einer Kommunikationsbeziehung.

Behaupten von Handlungen

Eine Instanz erstellt Informationen und behauptet, sie seinen an eine andere Instanz gesendetbzw. von dieser empfangen worden.

„Denial of Service“

Eine Instanz wird bei der Erfüllung ihres Dienstes gestört oder stört selber andere Dienste.

Diese Angriffe bedrohen direkt die grundlegenden Sicherungsziele bei der Datenverarbeitung: Eshandelt sich laut ATM Forum hierbei um Vertraulichkeit, Integrität und Verfügbarkeit sowie um diesichere Berechnung der Benutzung von Betriebsmitteln (Accountability). Die Authentizität (von In-stanzen oder der Herkunft von Nachrichten) wird nicht direkt genannt aber implizit gefordert bzw.vorausgesetzt.

26


3.1.2. Sicherungsziele und Anforderungen anSicherheitsdienstgüte

Das ATM Forum definiert eine Anzahl von Sicherungsfunktionen, die einzeln oder in Kombinationeingesetzt werden können, um die oben beschriebenen Angriffe zu verhindern oder zu erkennen.Diese Funktionen werden auch als „Security Services“ bezeichnet und stellen somit die von einemATM-Netz zu unterstützende Sicherheitsdienstgüte (SQoS) dar.

In den folgenden Unterabschnitten werden die verschiedenen Sicherheitsdienste aufgelistet und dieAnforderungen (zu erbringende Funktionalität) an diese Dienste kurz dargestellt.

3.1.2.1. Identitätskontrolle

Die Anforderungen an den Dienst zur Identitätskontrolle (Verification of Identities) sind:

• Authentifikation von Benutzern: sichere Identifizierung von (menschlichen) Benutzern.

• Authentifizierung von Instanzen: sichere Identifizierung einer Partnerinstanz während einer Kom-munikationsbeziehung.

• Authentifizierung der Herkunft: sichere Identifizierung der Herkunft übertragener Dateneinheiten.

3.1.2.2. Zugriffskontrolle und Autorisierung

Die Anforderung an diesen Dienst ist:

• Zugriffskontrolle: sicherstellen, daß auf (gespeicherte) Objekte nur autorisierte Instanzen mit denihnen zugeteilten Privilegien Zugriff erhalten.

3.1.2.3. Wahrung der Vertraulichkeit


• Vertraulichkeit: sicherstellen, daß vertraulicheDaten und Nachrichten geheim bleiben. Die Vertrau-lichkeit bezieht sich bei Nachrichten sowohl auf den Inhalt bei der Übertragung als auch auf dieGeheimhaltung der Verbindung. Die Vertraulichkeit von gespeicherten Daten soll mittelbar durchdie oben genannte Zugriffskontrolle durchgesetzt werden.

27


3.1.2.4. Wahrung der Datenintegrität

Die Anforderungen an diesen Dienst sind:

• Integrität gespeicherter Daten: sicherstellen, daß Manipulation an gespeicherten und übertragenenDaten erkannt oder verhindert wird. Für gespeicherte Daten wird wiederum die Zugriffskontrolleeingesetzt (autorisierte Manipulationen stellen keinen Angriff auf die Integrität dar).

• Integrität von Teilnachrichten: sicherstellen, daß Manipulation an ausgewählten Informationen ei-ner Nachricht erkannt werden.

3.1.2.5. Sichere Rechnungserstellung („Accounting“)

Die Anforderung an diesen Dienst ist sicherzustellen, daß alle im Netz ausgeführten Aktionen dendafür verantwortlichen Instanzen berechnet werden können. Dazu ist es erforderlich, beim Datenaus-tausch:

• nicht-Abstreitbarkeit des Ursprungs sicherzustellen. Zu jeder Zeit muß einer Instanz das Versendeneiner Nachricht nachgewiesen werden können.

• nicht-Abstreitbarkeit des Empfangs sicherzustellen. Zu jeder Zeit muß einer Instanz der Empfangeiner Nachricht nachgewiesen werden können.

3.1.2.6. Protokollierung („Logging“)


• Logging sicherheitsrelevanter Informationen. Hiermit soll eine Kontrolle der Sicherheitsrichtlinien(„Security Policy“) ermöglicht werden. Voraussetzung für die Kontrolle ist, daß alle als „sicher-heitsrelevant“ einzustufenden Aktionen und Aktivitäten auch notiert werden.

• Erkennen von Manipulationen an diesen Logdaten. Die Einhaltung der Richtlinien durch die re-gelmäßige Kontrolle von Logdaten kann nur dann erfolgreich sein, wenn sichergestellt ist, daßdie Logdaten selber nicht manipuliert wurden. Es ist daher sicherzustellen, daß die Manipulation(Löschen, Ändern) von Logdaten erkannt werden.

3.1.2.7. Reporterstellung


28


• Die automatische Generierung eines Sicherheits-Alarms bei Eintreten zuvor konfigurierter sicher-heitsrelevanter Ereignisse.

3.1.2.8. Audit


• Die Unterstützung eines Operators bei der Analyse von Audit-Daten. Das Netz muß hiernach nichtnur die Logdaten speichern, sondern Analysefunktionen für deren Auswertung bereitstellen.

3.1.2.9. Wiederherstellung eines ordentlichen Betriebs,Sicherheitsmanagement

Die Anforderung an diese beiden Dienste sind:

• Unterstützung für eine geordneteWiederaufnahme des Betriebs nach erfolgreichen und versuchtenAngriffen auf die Sicherheit des Netzes. Ziel ist es, geeignete Verfahren für ein „Recovery“ bereit-zustellen, um mit möglichst geringen Leistungseinbußen zum sicheren Betrieb zurückzukommen.

• Allgemeine Unterstützungsfunktionen für das Sicherheitsmanagement. Unter diesem Punkt faßtdas ATM-Forum alle erdenklichen Funktionalitäten zusammen, die zum Verwalten der obigen Si-cherheitsfunktionen benötigt werden.

3.1.3. Bewertung des ATM Security FrameworksDas ATMSecurity Framework ist als Wunschkatalog für zukünftige Entwicklungen des ATM-Forumsin Hinblick auf Sicherheit anzusehen. Es werden die wesentlichen Aspekte (Sicherheitsanforderun-gen) des ISO 7498/2 Standards aufgegriffen.

Da ausdrücklich darauf hingewiesen wird, daß die einzelnen Sicherheits-Dienste und Funktionen op-tional sind, ist kaummit einer schnellen Umsetzung bei den einzelnen Herstellern zu rechnen, obwohldurch die „Security Specifikation“ (vgl. AFo99b) konkrete Hinweise für die Implementierung gege-ben werden.

3.2. ATM Forum Security Specification 1.0

29


Die „ATM Forum Security Specification 1.0“ definiert Sicherheitsdienste für die „User Plane“, diesomit für die Endgeräte in einem ATM-Netz zur Verfügung stehen, sowie für die „Control Plane“,so daß auch für die Kommunikation zwischen Netzkomponenten (Switches) Sicherheitsfunktionalitätbereitgestellt wird.

In den folgenden Abschnitten wird kurz zusammengefaßt, welche Funktionen bereits spezifiziert sindund welche Sicherungsziele damit erreicht werden können. Eine kurze Bewertung rundet den Ab-schnitt über die vom ATM Forum spezifizierten Mechanismen ab.

3.2.1. Dienste für die User PlaneInnerhalb der „User Plane“ sind Dienste für die Authentisierung, die Verschlüsselung und die Integri-tätsprüfung vorgesehen.

3.2.1.1. „Entity Authentication“

Innerhalb der „User Plane“ sind Dienste für die einseitige und gegenseitige Authentisierung von Be-nutzern („entity authentication“) vorgesehen. Die Authentisierung erfolgt beim Verbindungsaufbau.Es können sowohl symmetrische als auch asymmetrische („public key“) Verfahren eingesetzt werden(vgl. Abschnitt 3.2.3), um die Angaben in den „Calling/Called Party“ IEs zu authentisieren. Daherkommt auch die Bezeichnung „peer authentication“. Die Endpunkte einer ATM-Verbindung werdenauthentisiert.

Hierbei ist zu beachten, daß die Authenthisierung genau einmal für jede virtuelle Verbindung erfolgt.Zwei Mechanismen sind hierfür vorgesehen:

1. Während der Signalisierung („signaling-based“) kann durch zusätzliche Informations-Elemente,die in AFo99 festgelegt sind, die Authentisierung erfolgen.

2. Nach der Signalisierung wird das Versenden von Benutzerdaten so lange verzögert, bis auf demgerade etablierten SVC mit zusätzlichen Nachrichten („in-band“) eine Authentisierung erfolgenkonnte.

Die Authentisierung während der Signalisierung erfordert eine Unterstützung durch die Switches.Sie müssen die zusätzlichen Informations-Elemente, die an der UNI-Schnittstelle zwischen Endgerät(ATM-Terminal) und Switch ausgetauscht werden, an der NNI-Schnittstelle in entsprechende PNNI-Informations Elemente umsetzen. Es ist daher auch eine Erweiterung der PNNI-Spezifikation (vgl.AFo96) durch ein „Security Information Element“ erforderlich (vgl. AFo99a).

3.2.1.2. Vertraulichkeit

Vertraulichkeit kann ebenfalls für jede einzelne virtuelle Verbindung ausgehandelt werden. Dies er-folgt ebenfalls durch die im letzten Abschnitt vorgestellten Mechanismen. Die Teilnehmer verhandelnentweder während oder unmittelbar nach der Verbindungsetablierung über den Verschlüsselungsmo-dus.

30


Bei dieser Verhandlung kann der Algorithmus für die Verschlüsselung ausgewählt werden und es wirdfestgelegt, in welche Richtung (gar nicht, uni-direktional, bidirektional) verschlüsselt werden soll.Die Verschlüsselung findet anschließend auf der ATM-Ebene statt: Die Nutzdaten aller Zellen („CellPayload“) (mit Ausnahme von einiger OAM-Zellen) werden verschlüsselt. Hierbei sind ausschließlichsymmetrische Verfahren standardisiert, da diese schneller sind als vergleichbar sichere asymmetrischeVerfahren.

Die bisher spezifizierten Verschlüsselungsalgorithmen sind DES, DES mit 40-bit Schlüssellänge,Triple-DES und FEAL (vgl. Sch96). Es handelt sich hierbei um blockbasierte Algorithmen, die dieDaten in Stücken von 64-bit verschlüsseln. Für die Verschlüsselung einer Zelle werden daher sechsdieser 64-bit Stücke gebildet und verschlüsselt, um die 48-„Payload“ Byte abzudecken.

3.2.1.3. Datenintegrität und -authentizität

Die Datenintegrität kann durch den Empfänger einer AAL-SDU überprüft werden, wenn bei oderunmittelbar nach der Verbindungseröffnung diese Option für die virtuelle Verbindung ausgehandeltwurde. Auch in diesem Fall können die ATM-Teilnehmer mit den in Abschnitt 3.2.1.1 dargestelltenMechanismen einen von mehreren „Message Authentication Codes“ aushandeln. Der gewählte Algo-rithmus wird eingesetzt, um jede AAL-SDU der Verbindung vor der Übergabe an die ATM-Schichtmit einem „Message Authentication“-Code (MA-Code) auszustatten.

Hierbei werden zwei verschiedeneModi unterschieden. Im einfachen Fall wird jede AAL-SDUmit ei-nem MA-Code versehen und anschließend gesendet. Die Partnerinstanz überprüft den MA-Code undverwirft die Dateneinheit, falls der übertragene Code nicht mit dem lokal berechneten Code überein-stimmt. Im zweiten Fall wird zusätzlich eine streng monoton steigende Sequenznummer (Länge von6-Byte) an die AAL-SDU angehängt, bevor der MA-Code über die Daten und die Sequenznummerberechnet wird. Dadurch sind auch Angriffe durch Reihenfolgevertauschungen und Wiedereinspielenbereits gesendeter Dateneinheiten erkennbar.

Durch den MA-Code können zwei Sicherungsziele erreicht werden. Erstens kann verifiziert wer-den, daß die Dateneinheit vom angegebenen Sender kommt, also von der Instanz, die sich bei odernach dem Verbindungsaufbau authentisiert hat. Zweitens kann überprüft werden, ob die Datenein-heit während der Übertragung manipuliert, vertauscht oder wieder eingespielt wurde. Die Prüfsumme(MA-Code) sichert somit die Authentizität des Senders der Dateneinheit als auch die Integrität dergesendeten Daten.

3.2.2. Dienste für die Control PlaneFür die „Control Plane“ sind lediglich Dienste für die Authentisierung und Integritätsprüfung der Si-gnalisierungsnachrichten zwischen zwei Switches spezifiziert. Es werden die selben Algorithmen wiein Abschnitt 3.2.1.3 diskutiert benutzt. Die Authentisierung und die Integritätsprüfung beziehen sichhier jedoch auf die Signalisierungsnachrichten (SAAL-SDUs) und haben somit nur lokalen Charakter(also von Switch zu Switch, nicht Endsystem zu Endsystem).

31


Ein weiterer wesentlicher Unterschied ist, daß die symmetrischen oder asymmetrischen Schlüssel„offline“ vor der Authentisierung installiert werden müssen. Es ist kein Austausch von Zertifikateninnerhalb der „Control Plane“ vorgesehen. Die hierfür erforderlichenManagementfunktionenwerdenim Standard jedoch nicht spezifiziert.

3.2.3. Unterstützende DiensteUm die oben aufgelisteten Sicherungsziele zu erreichen, werden einige unterstützende Funktionenbenötigt. Hierbei handelt es sich im wesentlichen um die Protokolle zumAustausch des erforderlichenkryptographischen Materials und zum Aushandeln der einzusetzenden Verschlüsselungs- und MA-Algorithmen. Während der Kommunikation der Teilnehmer werden dann u.U. weitere Funktionenbeispielsweise zum Aktualisieren der eingesetzten Verbindungsschlüssel benötigt.

In den folgenden Unterabschnitten werden zwei Protokolle vorgestellt, die das ATM Forum für dasAushandeln und Übertragen der notwendigen kryptographischen Parameter spezifiziert hat. Es gibtein drei-Wege Protokoll, das „in-band“ (s.u.) verwendet wird und ein zwei-Wege Protokoll, das alsErgänzung bei der Signalisierung eingesetzt wird.

3.2.3.1. Drei-Wege Protokoll für „in-band“ Einsatz

Das drei-Wege Protokoll erfordert eine bereits etablierte Verbindung zwischen den beteiligten ATM-Teilnehmern. Bevor die Anwendungen Daten gesichert austauschen können, werden drei zusätzlicheNachrichten über diese bereits etablierte Verbindung („in-band“) versendet, durch die sowohl eineAuthentisierung der Teilnehmer und das Aushandeln der einzusetzenden Verschlüsselungs- und MA-Algorithmen als auch ein initialer Schlüsselaustausch erfolgen kann.

Einige der Parameter sind optional und müssen nur für bestimmte Sicherungsziele mitgesendet wer-den. Beispielsweise ist das Versenden von Zertifikaten nur dann erforderlich, wenn eine zertifikats-basierte Authentisierung erfolgen soll. In Abbildung 3-1 sind alle Angaben eingetragen, die für ei-ne vollständige Absicherung (Authentisierung, Verschlüsselung und Integritätsprüfung) erforderlichsind.

Abbildung 3-1. „Three-Way Security Message Exchange Protocol“ (vgl. AFo99b)

32


atm_sec_spec_3way_sec_message_exchange_protocol

FLOW1-3WE ( A, B, Ra, SecNega, Certa )

FLOW2-3WE ( A, B, SecNegb, Certb, Ra, Rb, EncKa (ConfParb),SigKb (Hash (A, B, Ra, Rb, SecNega, SecNegb, ConfParb)) )

FLOW3-3WE ( A, B, Ra, EncKb (ConfPara), SigKa (Hash (A, B, Rb, ConfPara)) )

A

ATM_TERMINAL

VC-etabliertVC-etabliert

’pruefen von:Zertifikat,

Ra,Signatur und Hash’

B istauthentisiert,

Master- und Session-Keysfuer A->B bekannt

/* erster Session-Key fuer Verschluesselung und erster Session-Key fuer Integritaetspruefung */

B

ATM_TERMINAL

VC-etabliert

’Zertifikat pruefen’

’pruefen von:Rb,

Signatur und Hash’

A istauthentisiert,

Master-und Session-Keysfuer B->A bekannt

/* erster Session-Key fuer Verschue�sselung und erster Session-Key fuer Integritaetspruefung */

Bei „A“ und „B“ handelt es sich um eindeutige Bezeichner für die ATM-Terminals. Hierbei kann essich entweder um eine global eindeutigeATM-Adresse handeln (beispielsweise eine nach E-164) oderum einen X.500-„distinguished name“, der ein X.509-Zertifikat des Teilnehmers kennzeichnet. „Ra“und „Rb“ sind 32-bit Zufallszahlen der kommunizierenden Instanzen. Diese Zufallszahlen werden

33


beispielsweise verwendet, um unterscheidbare Hash-Werte zu erhalten, falls dieselben Instanzen zeit-gleich mehrere Verbindungen mit identischen Sicherheitseinstellungen (SecNeg) unterhalten. Ohnediese Zufallswerte wären die Hash-Werte im zweiten und dritten Schritt (FLOW2-3WE und FLOW3-3WE) gegebenenfalls identisch.

Mit „SecNega“ und „SecNegb“ werden die Wunschlisten der Teilnehmer bezeichnet, in denen diezur Verfügung stehenden Algorithmen zur Authentisierung, Verschlüsselung und Integritätprüfungeingetragen sind. Teilnehmer „B“ sollte aus der Liste von „A“ jeweils den ersten Algorithmuswählen,der lokal unterstützt wird. „A“ hat somit die Möglichkeit, seine Prioritäten anzugeben.

Mit „Certa“ und „Certb“ versenden die Teilnehmer sowohl Zertifikatslisten als auch Rückrufzertifi-kate („Certificate Revocation List“, CRL). „Enc“, „Sig“ und „Hash“ sind die Anwendung von Ver-schlüsselung, digitaler Signatur und Prüfsummenberechnung auf den jeweiligen Parametern.

Nachdem die drei Nachrichten „in-band“ ausgetauscht wurden, können die Anwendungen der Teil-nehmer „A“ und „B“ mit der gewählten Sicherheitsdienstgüte kommunizieren. Während dieses drei-Wege Protokoll abläuft, können diverse Fehler auftreten, die zu einem Abbruch führen. Fehlermel-dungen werden jedoch zuvor mit entsprechenden Nachrichten versendet. Beispiele für mögliche Feh-lersituationen sind: „A“ und „B“ können sich nicht auf einen gemeinsamen Algorithmus einigen, dieÜberprüfung der Hash-Werte liefert ein unerwartetes Ergebnis oder einer der Teilnehmer akzeptiertkeines der Zertifikate des anderen Teilnehmers.

3.2.3.2. „Signaling-based“ zwei-Wege Protokoll

Alternativ zur Vereinbarung der Sicherheitsdienstgüte mit dem drei-Wege Protokoll kann die Ver-einbarung auch während der Signalisierung beim ATM-Verbindungsaufbau erfolgen. Da es bei derSignalisierung für den ATM-Verbindungsaufbau nur zwei Nachrichten gibt, die zwischen den ATM-Teilnehmern ausgetauscht werden (SETUP und CONNECT, vgl. Abschnitt 2.1.2), stehen auch nurzwei Nachrichten für die Verhandlung der Sicherheitsdienstgüte zur Verfügung.

Die erforderlichen Angaben über Zertifikate, Algorithmen und die initialen Schlüssel werden in ei-nem zusätzlichen Informations-Element, dem „Security Services Information Element, SSIE“ inner-halb der SETUP- und CONNECT-Nachrichten kodiert. In Abbildung 3-2 ist durch die „...,“-Notationangedeutet, daß neben dem SSIE sowohl in der SETUP- als auch in der CONNECT-Nachricht weitereInformations-Elemente (IEs) kodiert sind.

Abbildung 3-2. „Two-Way Security Message Exchange Protocol“ (vgl. AFo99b)

34


atm_sec_spec_2way_message_exchange_protocol

FLOW1-2WE:SETUP (...,A,B,SecOpt,Certa,Ta,Ra, EncKb(ConfPara), SigKa (Hash (A,B,Ta,Ra,SecOpt,ConfPara))

,...)

FLOW2-2WE:CONNECT_(...,A, B, Ra, Certb, EncKa (ConfParb), SigKb (Hash (A, B, Ra, ConfParb))

,...)

A

ATM_TERMINAL

’pruefen von:Zertifikat,Signatur,

Hash’

B istauthentisiert,

Master- und Session-Keysfuer A->B bekannt

VC-etabliertVC-etabliert

B

ATM_TERMINAL

’pruefen von:Zertifikat,Signatur,

Hash,Zeitstempel’

A istauthentisiert,

Master-und Session-Keysfuer B->A bekannt

VC-etabliert

Die übertragenen Daten entsprechen denen beim drei-Wege Protokoll. Neu ist lediglich ein Zeit-stempel, den „A“ zusätzlich versendet. Dieser Zeitstempel muß eindeutig für jede von „A“ nach „B“eröffnete Verbindung sein. Damit sind für „B“ auch zwei unmittelbar aufeinanderfolgende Signa-lisierungen von „A“ unterscheidbar. „A“ kann mehrere Signalisierungen von „B“ (FLOW2-2WE)weiterhin durch die „Nonces“ 1 (Ra) unterscheiden. „Rb“ wurde in diesem Protokoll durch den strengmonoton steigenden Zeitstempel ersetzt. Dieses Protokoll erfordert möglichst synchrone Uhren. Jegrößer die Zeitabweichungen der Uhren voneinander ist, desto mehr Zeitstempel muß „B“ speichern,um eintreffende Nachrichten mit kleiner oder gleichem Zeitstempel desselben Senders als solche er-kennen zu können. Trifft von demselben Sender ein weiterer „Flow“ (FLOW2-1WE) ein, der einen

35


kleineren Zeitstempel hat, dann scheitert die Authentisierung und „B“ vernichtet die Nachricht.

Die beiden vorgestellten Protokolle bilden den Kern der unterstützenden Dienste. Zusätzlich gibt esNachrichten für die Autorisierung („Security Label Transport“) und Mechanismen zum Aktualisierenund Synchronisieren von Sitzungsschlüssel.

3.2.4. Zusammenfassung und offene PunkteDie Sicherheitsspezifikation des ATM Forums ist ein wichtiger Schritt, um herstellerübergreifendeSicherheitsmechanismen in ATM-Netzen zu ermöglichen. Es bleiben jedoch ein paar Punkte offen,die Anlaß zur Kritik geben.

Am auffälligsten sind die fehlenden Spezifikationen für Sicherheisfunktionalität innerhalb der „Ma-nagement Plane“. Dadurch ist nicht klar, wie das Management von Switches und anderen aktivenATM-Netzkomponentengesichert werden soll. Dies ist insbesondere ein Problem, weil die Integritäts-sicherung der Daten auf der „Control Plane“ vorinstallierte Schlüssel benötigen. Durch Sicherungs-mechanismen innerhalb der „Management Plane“ wäre gerade für die Installation von vertraulichemkryptographischenMaterial viel gewonnen.

Ein weiteres Problem stellt die sehr ungenaue Angabe zu den verwendeten Zertifikaten dar. Die Vali-dierung der Zertifikate ist immer durch den Empfänger durchzuführen. Die Erstellung der Zertifikateund die Verwaltung dieser mit geeigneten Zertifikatsservern ist die Aufgabe einer entsprechenden„Public Key Infrastuctur“. Diese ist nicht einmal ansatzweise vom ATM Forum angedacht worden,obwohl gerade das ATM Forum hierfür prädestiniert wäre.

Somit ist völlig unklar, welche Angaben in einem X.509-Zertifikat enthalten sein sollten, was dieseZertifikate aussagen und wer diese Zertifikate ausstellt. Darüber hinaus brauchen die Teilnehmer Zu-griffsmöglichkeiten auf die hinterlegten Zertifikate, um online eine Kontrolle oder Abfrage vorneh-men zu können. Das ist nicht möglich, solange keine ATM-basierten Zugriffsprotokolle existieren.Denkbar wäre beispielsweise ein „LDAP over ATM“.

Alles in allem ist unklar, ob bzw. wann sich diese Spezifikationen durchsetzen werden. In erster Liniesind die Hersteller aufgefordert, entsprechende Möglichkeiten in ihrer ATM-Software vorzusehen.Zusätzlich müssen die heute im Einsatz befindlichen ATM-Installationen durch andere Mechanismenabgesichert werden, da sich die Vorschläge des ATM-Forums sicherlich nicht kurzfristig durchsetzenwerden.

Fußnoten1. Nonce bezeichnet einen frischen, noch nicht dagewesenen zufälligen Wert. Die Generierung der-

artiger Werte ist nicht ganz trivial, da die hierfür benötigten Zufallszahlengeneratoren eine extremgeringe Periodizität vorweisen müssen, um als kryptographisch sicher zu gelten.

36

Kapitel 4. Standardprotokolle in ATM-Netzen

Es gibt eine Reihe von Protokollen, die zwar nicht essentiell für den Betrieb von ATM-Netzen sind,aber dennoch in jeder nicht trivialen Installation eingesetzt werden. Diese Protokolle werden folglichauch von anderen Protokollen wie beispielsweise der LAN-Emulation (vgl. Kapitel 7) vorausgesetzt.Es ist daher notwendig, bereits diese Protokolle zu verstehen und richtig zu konfigurieren, damit die‘höherwertigen Dienste’ vernünftig abgesichert werden können.

Die heutigen ATM-Switches werden in der Regel mit mindestens drei Protokollen ausgeliefert. Das‘Integrated Local Management Interface’ (ILMI) ist ein Protokoll zum automatischen Konfigurierender einzelnen Switch-Schnittstellen.

Das ‘User Network Interface 3.1/4.0’ (UNI) und das ‘Private Network Network Interface 1.0’ (PN-NI) sind Protokolle zur Verbindungsverwaltung zwischen Switch und Endgerät (UNI) und zwischenmehreren Switches (PNNI). Darüber hinaus ist PNNI auch ein hierarchisches ‘Routing’-Protokoll.

In den folgenden Abschnitten werden kurz die Funktionen der einzelnen Protokolle vorgestellt, umdarauf aufbauend die Angriffsmöglichkeiten und Gegenmaßnahmen zu diskutieren. Hierbei ist eswichtig, die Protokolle nicht als getrennte Regelsätze zu verstehen, sondern die Gesamtfunktionalitätdieser Protokolle so abzusichern, daß ein Mißbrauchmöglichst unterbunden oder zumindest erschwertwird. Zur Verdeutlichung werden daher Konfigurationsbeispiele für die CISCO Lightstream 1010ATM-Switches angegeben. Diese Switches sind bei den DFN-Mitgliedern weit verbreitet und bietensich daher für die Diskussion der Fallbeispiele an.

4.1. ‘Integrated Local Management Interface’ (ILMI 4.0)Das ‘Integrated Local Management Interface’ (ILMI) ist ein Protokoll, das zwischen Switch und End-gerät und zwischen zwei benachbarten Switches eingesetzt wird. ILMI ermöglicht den verbundenenInstanzen, bidirektional Statusinformationen auszutauschen. Hierfür wird eine Untermenge der ‘Sim-ple Network Management Protocol, SNMP’-Funktionen CFS90 benutzt.

4.1.1. Funktionsweise von ILMIAuf den ATM-Geräten gibt es eine ‘Interface Management Entity, IME’, die mit der Partner-IME aufdem anderen ATM-Gerät mit dem ILMI-Protokoll kommuniziert. Die IMEs benutzen einige SNMP-Methoden (GET, GET-NEXT, SET und TRAP), um eine Reihe von Diensten bereitzustellen. Hierzuzählen vor allem:

• ILMI-Autokonfiguration:Die IMEs teilen sich gegenseitigmit, auf welcher Art vonATM-Komponentedie IME-Instanz läuft. Aus den beiden Möglichkeiten ATM-Endgerät und ATM-Switch ergeben

37


sich die zwei IME-Betriebsmodi: User-Side-IME bei einemATM-Endgerätmit Network-Side-IMEbeim ATM-Switch oder ‘symmetrische’-IMEs im Falle zweier benachbarter Switches.

• Periodisches Überprüfen der Erreichbarkeit der IMEs. Hierzu stellen sich die IMEs gegenseitig vonZeit zu Zeit SNMP-GET oder SNMP-GET-NEXT-Anfragen. Antwortet die Partner-IME rechtzei-tig (innerhalb einer Sekunde) mit einer SNMP-GetResponse-PDU, darf angenommen werden, daßdie Instanzen noch miteinander verbunden sind.

• Registrieren von ATM-Adressen auf dem Switch. User-IMEs können eine oder mehrere ATM-Adressen registrieren. Die Partner-IME auf dem Switch konfiguriert das Routing dementsprechend.Eingehende Verbindungswünsche für eine registrierte ATM-Adresse können dann zum Endgerätweitergeleitet werden.

• Abfragen diverser Parameter und Statistiken über die angeschlossenen Komponenten. Es könnenumfangreiche Informationen zu den physikalischen Eigenschaften der verbundenen Komponentenabgerufen werden. Darüber hinaus können zu jeder aktiven virtuellen Verbindung Informationen(beispielsweise VPI- und VCI-Wert) abgerufen werden. Ist die IME-Teil eines LANE-Netzes, kannsie außerdem die ATM-Adresse des LANE-Configuration-Servers (LECS) abrufen. Die Definitionder vollständigen MIB befindet sich in AFo96a.

Die IMEs verwenden für das Abfragen und Setzen dieser Parameter das SNMP. Die SNMP-PDUs(GetRequest-, GetNextRequest-, GetResponse-, SetRequest- und Trap-PDU) werden direkt in AAL5-Rahmen eingebettet, die wiederum über fest konfigurierte virtuelle Verbindungen übertragen werden.Per Vorgabe wird ein PVC mit (VPI=0, VCI=16) für ILMI verwendet. Falls in den SNMP-PDUsIP-Adressen angegeben werden müssen (Trap-PDU), ist immer ‘0.0.0.0’ statisch einzusetzen. AlsSNMP-Community-Name wird der String ‘ILMI’ verwendet. Eine einzelne SNMP-PDU sollte nichtgrößer als 484 Byte sein.

Auf der ATM-Ebene gelten weitere Einschränkungen, die alle darauf abzielen, das ILMI-Verkehrsaufkommenmöglichst gering zu halten. Beispielsweise wird die maximale ‘burst’-Länge gerade so festgelegt, daßeine 484 Byte lange SNMP-PDU zugüglich dem AAL5-Overhead gesendet werden kann. Dabei darfdie ‘peak cell rate’ maximal 5% der physikalischen Übertragungsgeschwindigkeit gemessen an derlokalen ATM-Schnittstelle betragen.

4.1.2. ILMI-ProtokollDie oben aufgeführten Dienste werden durch Nachrichtenaustausch zwischen den beteiligten IMEserbracht. In diesem Abschnitt wird der eingesetzte Protokollstapel vorgestellt und die wichtigstenNachrichten als ‘Message Sequence Chart’ (MSC) dargestellt.

ILMI-IMEs versenden die Daten als SNMP-Nachrichten. Diese werden direkt (ohne Einbettung inUDP/IP-PDUs) in AAL-5 Rahmen übertragen. Auf der ATM-Ebene werden diese Rahmen in Zellenmit dem VPI/VCI-Paar (0,16) übertragen. Typischerweise werden Zellen wiederum in SDH-Rahmeneingepackt und schließlich über ein physikalisches Übertragungsmedium versendet (beispielsweiseGlasfaserleitung). Daraus resultiert der folgende Protokollstapel (vgl. Abbildung 4-1).

38


Abbildung 4-1. ILMI-Protokollstapel

SNMP ILMI-IMEs

AAL-5 ATM Adaption Layer

ATM LayerVCI = 16 VPI = 0

MediumSDH + "Kabel"

Bei der Initialisierung (z.B. nach dem Einschalten eines Endgerätes) sendet die lokale IME eineSNMP-Trap-PDU des Typs ‘coldstart’. Damit wird der Partner-IME mitgeteilt, daß eine neue IME-Instanz initialisiert wurde. Danach wird periodisch die Verbindung zur Partner-IME geprüft, indembestimmte Attribute (s.u.) der Partner-IME abgefragt werden. Dies wird als ‘ILMI Connectivity Pro-cedures’ (CP) bezeichnet.

Um den Typ der Partner-IME festzustellen, kann z.B. im Rahmen der CP nach den Attributen atmfPort-MyIdentifier und atmfMySystemIdentifier gefragt werden. Per Vorgabe werden diese Anfra-gen jede Sekunde gesendet, bis die Auto-Konfiguration abgeschlossen ist. Danach wird die Verbin-dung nur noch alle fünf Sekunden getestet. Bleiben vier aufeinanderfolgende Anfragen unbeantwor-tet, wird die Verbindung als verloren angesehen und die CP müssen erneut durchlaufen werden. InAbbildung Abbildung 4-2 ist die ‘Connectivity Procedure’ graphisch dargestellt.

Abbildung 4-2. ILMI-Connectivity Procedures

39


ilmicp

SNMP-TRAP (coldstart)

SNMP-TRAP (coldstart)

SNMP-GetRequest (atmfPortMyIdentifier)

SNMP-GetRequest (atmfMySystemIdentifier)

SNMP-GetRequest (atmfPortMyIdentifier)

SNMP-GetRequest (atmfMySystemIdentifier)

SNMP-GetResponse (atmfPortMyIdentifier,....)

SNMP-GetResponse (atmfPortMyIdentifier,....)

SNMP-GetResponse (atmfMySystemIdentifier,....)

SNMP-GetResponse (atmfMySystemIdentifier,....)

TERMINAL

IME

START

AUTOCONFIG

SWITCH

IME

START

AUTOCONFIG

Ist eine Verbindung mit Hilfe der CP hergestellt, können die IMEs mit Hilfe der ‘Automatic Con-figuration Procedures’ (Auto-Konfiguration) den Schnittstellentyp der Partnerinstanz bekanntgeben(User-Side-IME oder Network-Side-IME). Dazu werden die zwei Attribute atmfAtmLayerUniTy-pe und atmfAtmLayerDeviceType abgefragt. Abbildung 4-3 und Abbildung 4-4 geben Beispielemit Werten, die von einer ‘User-Side-IME’ und einer ‘Network-Side-IME’ gesendet werden können.Andere Werte sind hier möglich, falls andere Protokolle eingesetzt werden sollen (vgl. AFo96a).

Abbildung 4-3. ILMI Automatic Configuration Procedures (User-Side)

40


ilmiac

SNMP-GetRequest (atmfAtmLayerUniType)

SNMP-GetRequest (atmfAtmLayerDeviceType)

SNMP-GetResponse (atmfAtmLayerUniType, private )

SNMP-GetResponse (atmfAtmLayerDeviceType, node)

TERMINAL

IME

AUTOCONFIG

User-Side-IME

(Private UNI)

SWITCH

IME

AUTOCONFIG

Abbildung 4-4. ILMI Automatic Configuration Procedures (Network-Side)

41


ilmiac1




SNMP-GetResponse (atmfAtmLayerDeviceType, user)

TERMINAL

IME

AUTOCONFIG

SWITCH

IME

AUTOCONFIG

Network-Side-IME

(Private UNI)

Eine weitere wichtige Funktion von ILMI ist die automatischeAdreßregistrierungan der UNI-Schnittstelle.Wie bereits in Abschnitt 2.1.6 diskutiert ist eine ATM-Adresse ein 20-Byte langer Wert, der in dreiverschiedenen Formaten (DCC, E.164 und ICD) angegeben werden kann. Je nachdem, wo ein ATM-Terminal an ein ATM-Netz angeschlossen wird, bekommt es eine andere Adresse zugeteilt. Ursäch-lich hierfür ist, daß der Switch in der Regel einen gemeinsamen Adreßprefix von 13-Byte Längean alle angeschlossenen ATM-Endgeräte vorgibt. Die Endgeräte ergänzen lediglich einen Prefix (7-Byte), um eine vollständige ATM-Adresse zu erhalten. Wird ein ATM-Endgerät an einen anderenSwitch angeschlossen, erhält es somit eine andere Adresse, obwohl es den gleichen Prefix ergänzt.

Der Hauptvorteil dieses Verfahrens liegt darin, daß durch die Adreßzuweisung durch den Switch dasRouting zu den Endgeräten in großen hierarchischen ATM-Netzen vereinfacht wird. Durch den ein-heitlichen Prefix kann eine Aggregierung der Adreßinformationen stattfinden, die zwischen den Swit-ches ausgetauscht werden müssen, da nur noch der lokale Switch die vollständige Adresse kennenmuß. Außerdem kann der lokale Switch auf einfache Weise verhindern, daß Adreßkonflikte auftre-ten, da er die mehrfache Registrierung derselben Adresse auf mehreren Schnittstellen unterbindenkann. Nach der oben vorgestellten Auto-Konfiguration kann ein ATM-Terminal eine oder mehrereATM-Adressen am lokalen Switch reservieren. Durch diese Reservierung können eingehende Ver-bindungswünsche für die registrierten Adressen vom Switch an das Terminal weitergeleitet werden.

Die Network-Side IME (NSIME) sendet eine SNMP-Anfrage an die User-Side IME (USIME) umfestzustellen, ob es bereits registrierte Adressen gibt. Ist dies der Fall, wird ein weiterer ‘Coldstart-

42


Trap’ ausgelöst und die CP und Auto-Konfigurationsprozeduren müssen wiederholt werden. Danachsollten die Adreßtabellen der USIME leer sein. Die NSIME kann nun mit einer Folge von SNMP-Anfragen einen oder mehrere Adreßprefixe beim Terminal registrieren. Sie kann aber auch zu einemspäteren Zeitpunkt neue Prefixe registrieren oder registrierte Prefixe als ungültig markieren.

Die USIME entscheidet, für welche Adreßprefixe sie eine ATM-Adresse registrieren will, und hängtdafür einen 7-Byte langen Suffix an den gewählten Prefix. Danach kann die USIME versuchen, dieneu gebildetet ATM-Adresse beim Switch mit einer SNMP-Nachricht zu registrieren. Der Switchsollte der Registrierung zustimmen, falls die Adresse nicht schon vergeben ist. Eine USIME kannbeliebig viele ATM-Adressen registrieren. Der 7-Byte lange Suffix muß dabei nicht derselbe sein,kann aber bei allen registrierten Prefixen identisch sein. In Abbildung 4-5 ist eine Adreßregistrierungabgebildet, bei der die NSIME einen Prefix registriert und die USIME danach versucht, zwei ATM-Adressen zu registrieren. Der Switch stimmt jedoch nur der ersten Adreßregistrierung zu.

Abbildung 4-5. ILMI ATM-Adreßregistrierung

ilmiaddrreg

GetNextRequest (atmfNetPrefixStatus)

pruefen, ob die USIME- Adresstabelle leer ist.

GetResponse (atmfNetPrefixStatus, invalid)

falls die USIME hier einen gueltigen Wert liefert, sollte mit einem ’coldstart- Trap’ die Tabelle geloescht werden.

SetRequest (atmfNetPrefixStatus.x.prefix=valid)

auf dem Port x soll der ’prefix’ (13-Byte) registriert werden. ’invalid’ entspricht einer ’Deregistrierung’GetResponse (atmfNetPrefixStatus.x.prefix,noerror)‘noerror’ bestaetigt

die Registrierung

SetRequest (atmfAddressStatus.0.addrA=valid) Versuch, die Adresse ’addrA’ auf dem Port 0 zu registrieren. Port 0 bezeichet den ’lokalen Port’ und ist somit der ’default’GetResponse (atmfAddressStatus.0.addrA,noerror)Registrierung

war erfolgreich

SetRequest (atmfAddressStatus.0.addrB=valid)

GetResponse (atmfAddressStatus.0.addrA,badvalue)Registrierung war nicht erfolgreich

TERMINAL

IME

User-Side-IME

(Private UNI)

SWITCH

IME

Network-Side-IME

(Private UNI)

43


Neben den oben beschriebenen Aktionen beim Anschließen von ATM-Terminals an Switches, kannauch während des laufenden Betriebs eine IME jederzeit Anfragen an die Partner-IME stellen. Dieoben beschriebenen Aktionen stellen sozusagen den Sonderfall dar. Sie werden nach Störungen odernach dem Einschalten der Geräte ausgeführt. ILMI ermöglicht durch diese Prozeduren somit einen‘Plug-and-Play’-Betrieb von ATM-Endgeräten.

4.1.3. AngriffsmöglichkeitenIn diesemAbschnitt werdenAngriffsmöglichkeiten aufgezeigt, die wesentlich auf dem ILMI-Protokollberuhen. Die eingesetzten Mechanismen sind dabei trivial. Der daraus resultierende Schaden ist auchvernachlässigbar. Ziel eines Angriffs mit ILMI ist es vielmehr, andere Angriffe vorzubereiten oderbereits existierende Sicherungsmechanismen unwirksam zu machen.

In den beiden unteren Abschnitten wird dargestellt, wie ein Endgerät einerseits versuchen kann, sichals Switch auszugeben, um als Teil der ATM-Netzinfrastruktur agieren zu können. Andererseits kannein Endgerät versuchen, nicht konforme ATM-Adressen zu registrieren. Der jeweilige Nutzen füreinen Angreifer wird ebenfalls diskutiert.

4.1.3.1. Emulieren eines ATM-Switches

Es gibt für ATM-Netze hierarchische Routing-Protokolle (beispielsweise das PNNI), die zum Aus-tausch vonWegwahlinformationen eingesetzt wird. Angriffemit diesem Protokoll bzw. auf Grundlagedieses Protokolls sind als besonders gefährlich zu bewerten. Derartige Angriffe auf die Infrastrukturdes gesamten Netzes sind besonders schädlich, da viele Rechner und aktive Netzkomponenten gleich-zeitig betroffen sind. Ein Angreifer, der einen möglichst großen Schaden (z.B. einen breit angelegten‘Denial of Service’) erreichen will, wird daher versuchen, die Netzinfrastruktur direkt anzugreifen,anstelle einzelner Endsysteme 1 im Netz.

Da in ATM-Netzen nur Switches (in der ILMI-Terminologie sogenannte ‘nodes’) miteinander überRouting-Protokolle kommunizieren, muß sich ein Angreifer als ‘Switch’ ausgeben, um derartige An-griffe durchzuführen. Hierzu kann ein Endsystem verwendet werden, das sich dem Switch an derUNI-Schnittstelle durch die oben beschriebenen Auto-Konfigurationsprozeduren als Switch zu er-kennen gibt. Der Angreifer erreicht dadurch möglicherweise., daß der Switch PNNI-Informationenmit dem Endsystem des Angreifers austauscht. Diese Informationen bilden die Grundlage für weitereAngriffe. In Abbildung 4-6 ist dargestellt, wie ein Angreifer in Anlehnung an Abbildung 4-4 einenSwitch täuscht.

Abbildung 4-6. Endsystem gibt sich als Switch aus

44


ilmipnnifake




SNMP-GetResponse (atmfAtmLayerDeviceType, node)

SNMP-GetRequest (atmfAtmLayerLayerNniSigVersion) Peer fragen, welchesRouting-Protokoll eskennt.

SNMP-GetResponse (atmfAtmLayerLayerNniSigVersion, pnniVersion1.0)

Angreifer will PNNImit dem Switch reden

ATTACK_TERMINAL

IME

AUTOCONFIG

SWITCH

IME

AUTOCONFIG

PEER istein SWITCH !

SYMMETRICIME,PNNI

4.1.3.2. Registrieren nicht-konformer ATM-Adressen

Die Adreßregistrierung wurde in Abschnitt 4.1.1 besprochen. Es ist eigentlich vorgesehen, daß ATM-Endgeräte nur Adressen mit einem zuvor vom Switch zugeteilten Prefix registrieren. Je nach Her-steller kann es aber durchaus möglich sein, daß Angreifer mit Hilfe des ILMI-Protokolls weitereATM-Adressen registrieren, die nicht mit einem von Switch vorgegebenen Prefix beginnen.

Eine solche Registrierung zusätzlicher Adressen kann dann schädlich sein, wenn es dadurch dem An-greifer gelingt, Adreßfilter auf dem Switch zu umgehen. In Abschnitt 4.2 wird noch ausführlicher aufdie Filtermöglichkeiten eingegangen. Bei richtigem Einsatz können diese Adreßfilter die Sicherheit inATM-Netzen deutlich erhöhen. Bei unzureichender Konfiguration kann es jedoch durch Reservierenvon zusätzlichen Adressen gelingen, diese Filter zu umgehen.

45


Der Angriff ist trivial und eine simple Abwandlung der ‘ordentlichen’ Adreßregistrierung aus Abbil-dung 4-5. Der Angreifer versucht einfach eine weitere, beliebige ATM-Adresse für seine Zwecke zuregistrieren. Hierbei erkennt der Angreifer durch die vom Switch zurückgesendete GetResponse-Nachricht unmittelbar, ob der Versuch erfolgreich war. Ein Fehlercode noError bestätigt die erfolg-reiche Registrierung. Danach ist der Angreifer auch unter der neuen Adresse erreichbar.

4.1.4. GegenmaßnahmenDie hier vorgestellten Gegenmaßnahmen erfordern ein manuelles Konfigurieren der Switches undsind somit zumindest teilweise gegenläufig zum ‘Plug and Play’-Konfigurieren mit ILMI. Anderer-seits ist es offensichtlich so, daß durch eine vernünftige Einschränkung der mit dem ILMI-Protokollaushandelbaren Parameter und Protokolle die oben vorgestellten Angriffe abwendbar sind.

Das ILMI-Protokoll ist im Switch als Teil der Betriebssoftware implementiert. Es kommt daherauf den Hersteller an, ob und wie sich die einzelnen automatischen Konfigurationsschritte von IL-MI beeinflussen lassen. Wie bereits in der Einleitung erläutert, werden die Beispiele für ‘CiscoLightStream’-Switches vorgestellt, da diese ATM-Switches bei der DFN-Klientel weit verbreitet sind.

4.1.4.1. Verhindern der Switch-Emulation an UNI-Schnittstellen

Der Netzadministrator sollte die Schnittstellenbelegung der einzelnen Switchports kennen. Für jedenPort (ATM Schnittstelle auf dem Switch) kann dann statisch festgelegt werden, ob es sich um einenUNI-Port oder um einen NNI-Port handelt und welche Protokolle benutzt werden dürfen. Das fol-gende Beispiel zeigt, wie ILMI auf einem Port aktiviert wird, die automatische Konfiguration jedochdurch statisch konfigurierte Werte überschrieben wird. Der Angreifer hat somit keine Möglichkeit,einen Switch zu veranlassen, von UNI auf NNI umzuschalten. Der erste Befehl wählt die zu konfigu-rierende Schnittstelle. Der zweite Befehl aktiviert das ILMI-Protokoll auf dieser Schnittstelle. Dies isterforderlich, um beispielsweise die ‘Connectivity Procedures, CP’ weiterhin benutzen zu können. Derdritte Befehl schaltet daraufhin die Automatik-Konfiguration ab und der vierte Befehl konfiguriert dienun nicht mehr verhandelbaren Werte statisch. In diesem Fall wird dem Switch mitgeteilt, daß aufdem Port das UNI 4.0 Protokoll als Schnittstellentyp ‘Private UNI’ eingesetzt werden soll und dieIME sich wie eine ‘Network-Side’-IME zu verhalten hat.

Beispiel 4-1. Deaktivieren der Auto-Konfiguration und Konfigurieren des Schnittstellentyps

Switch(config)# interface atm 0/1/2Switch(config-if)# atm ilmi-enableSwitch(config-if)# no atm auto-configurationSwitch(config-if)# atm uni side network version 4.0 type private

Diese statische Konfiguration sollte für alle Schnittstellen eingetragenwerden, an denenATM-Endgeräteangeschlossen sind.

46


4.1.4.2. Verhindern beliebiger Adreßregistrierungen

Das Verhindern beliebiger Adreßregistrierungen ist nicht trivial. Ideal wäre eine Konfiguration vonzulässigen ESI-Adreßteilen, mit denen sich ein ATM-Terminal zusammen mit dem Switch-Prefix re-gistrieren darf. Dadurch kann sichergestellt werden, daß keine zusätzlichen unbekannten Adressenauf der Schnittstelle des Switches für ein ATM-Endgerät registriert werden. Eine radikale Methodebesteht im Abschalten der Adreßregistrierung auf dem Switch für einzelne oder alle Schnittstellen.Wird ein Netz jedoch ohnehin nur mit PVCs betrieben, dann sollte die ILMI-Adreßregistrierung aufden entsprechenden Schnittstellen abgeschaltet werden. Bei der Gelegenheit kann auch gleich diebeim Einsatz von PVCs obsolete und gegebenenfalls sogar sicherheitskritische Signalisierung abge-schaltet werden.2 Die folgenden Konfigurationskommandos zeigen, wie die Adreßregistrierung unddie Signalisierung auf einer Switch-Schnittstelle deaktiviert werden.

Beispiel 4-2. Deaktivieren der Adreßregistrierung und der Signalisierung

Switch(config)# interface atm 0/1/2Switch(config-if)# atm manual-well-known-vc deleteOkay to delete well-known VCs for this interface? [no]: yesSwitch(config-if)# atm pvc 0 16 interface atm2/0/0 0 any-vci encap ilmiSwitch(config-if)# no atm address-registration% Please ’shut/no shut’ this interface for this command to take effect.

Switch(config-if)# shutdownSwitch(config-if)# no shutdown

Durch die obige Konfiguration sind die Endgeräte nicht mehr mit SVCs ansprechbar, was in vielenFällen unakzeptabel ist. Sollen weiterhin SVCs benutzt werden, schafft eine Kombination andererMe-chanismen Abhilfe: Zuerst sollte auf allen Schnittstellen konfiguriert werden, daß nur ATM-Adressenmit dem vom Switch zugeteilten Prefix(en) registriert werden dürfen. Dadurch erreicht man eineFixierung der ersten 13-Byte der ATM-Adressen, die von den Endgeräten gewählt werden können.Dieses Vorgehen verhindert nicht, daß ein über die UNI-Schnittstelle angeschlossenes ATM-Endgerätmassiv Adressen registriert und so gegebenenfalls einen DoS auf anderen Switch-Schnittstellen aus-löst. Das Problem wird jedoch lokal gehalten, da der Switch-Prefix nur für diesen Switch gültig istbzw. für eine kleine Gruppe von Switches. Das folgende Kommando fixiert die ersten 13-Byte derregistrierbaren ATM-Adressen auf die konfigurierten Adreßprefixe.

Beispiel 4-3. Fixieren der Prefixe registrierbarer ATM-Adressen

Switch(config)# atm ilmi default-access permit matching-prefix

Falls es nicht möglich ist, die zu verwendenen ATM-Adressen genau festzulegen, dies aus Sicher-heitsgründen jedoch als erforderlich angesehen wird, sollte die Signalisierung eingeschränkt werden.Dadurch kann ein ATM-Terminal weiterhin ATM-Adressen registrieren jedoch nicht mehr verwen-den. Das Einschränken der Signalisierung wird in Abschnitt 4.2 genauer diskutiert.

47


4.2. ‘User Network Interface 3.1/4.0’ (UNI)Das ‘User Network Interface’ (UNI) ist die Schnittstelle zwischen Switch und ATM-Endgerät. DieVerbindungsverwaltung (Verbindungsmanagement) wird an dieser Schnittstelle mit dem gleichnami-gen Protokoll in der Version 3.1 oder 4.0 implementiert. Bei den folgenden Ausführungen ergibt sichaus dem Kontext, ob mit UNI die Schnittstelle oder das Protokoll zwischen Endgerät und Switch andieser Schnittstelle gemeint ist.

Bereits in Abschnitt 2.1.2 wurden wesentliche Aspekte der Verbindungsverwaltung dargestellt. Vorder eigentlichen Datenübertragungmuß in einem ATM-Netz eine Verbindung zwischen den Endgerä-ten geschaltet werden. Nach Abschluß der Datenübertragung kann diese Verbindung wieder abgebautwerden. Die für den Verbindungsauf/-abbau und die Fehlerbehandlung erforderlichen Protokolle im-plementieren somit die verteilte Verbindungsverwaltung in einemATM-Netz. Im folgendenAbschnittwird die Funktionsweise eines dieser Protokolle dargestellt, um später die Angriffsmöglichkeiten undGegenmaßnahmen diskutieren zu können. Die Darstellung des PNNI-Protokolls baut hierauf auf, sodaß wesentliche Informationen zur Funktionsweise nur in Abschnitt 4.2.1 genannt werden.

4.2.1. Funktionsweise von UNIDas UNI-Protokoll wird an der Schnittstelle zwischen Switch und Endgerät eingesetzt. Da mit diesemProtokoll erst weitere Verbindungen (SVCs) aufgebaut werden können, muß für den Betrieb ein PVCzwischen Switch und Endgerät konfiguriert werden. Der Vorgabewert (‘Default’) für diesen PVC ist(VPI, VCI) = (0,5). Sowohl der Switch als auch die angeschlossenen Endgeräte sind in der Regel sokonfiguriert, daß sie Zellen mit diesen VPI/VCI-Tupel an die Signalisierungssoftware (UNI 3.1/4.0)weiterreichen.

Die Haupaufgabe von UNI ist es, die spezifischen Anforderungen eines Benutzers an eine zu erstel-lende Verbindung an den nächsten Switch zu übertragen und Bestätigungen bzw. Fehler vom Switchzum Benutzer zurückzusenden. Die wichtigsten Protokollabläufe sind in diesem Zusammenhang:

• Aufbauen einer Punkt-zu-Punkt-Verbindung

Hierbei wird dem Switch von einem Endgerät mitgeteilt, zu welchem anderen Endgerät eine Ver-bindung aufzubauen ist. Der Switch ist dann für die Wegwahl zuständig und leitet die Anfrage indas ATM-Netz weiter. Schließlich teilt der Switch dem Endgerät mit, welches VPI/VCI-Paar fürden neuen SVC zu verwenden ist.

• Aufbauen einer Punkt-zu-Mehrpunkt-Verbindung

Dies verläuft in zwei Phasen. Die erste Phase ist dem Aufbauen einer Punkt-zu-Punkt-Verbindungsehr ähnlich. In der zweiten Phase können dannweitere Teilnehmermit den selben QoS-Merkmalenwie die des ersten Teilnehmers hinzugefügt werden. Der wesentliche Unterschied zu einer Punkt-zu-Punkt-Verbindung besteht darin, daß die Punkt-zu-Mehrpunkt-Verbindung unidirektional ist(nur ein Sender), dafür aber mehrere Empfänger haben kann.

48


• Abbauen einer Punkt-zu-Punkt-Verbindung

Die aufgebauten Verbindungen müssen nach der Benutzung wieder abgebaut werden. Dabei wirddie Zuordnung der VPI/VCI-Tupel zur virtuellen Verbindung wieder aufgehoben und die reser-vierten Betriebsmittel für den SVC können sowohl auf den beteiligten Switches als auch auf denEndsystemen wieder freigegeben werden.

• Abbauen einer Punkt-zu-Mehrpunkt-Verbindung

Beim Abbau einer Punkt-zu-Mehrpunkt-Verbindung können einzelne Teilnehmer (Empfänger) ab-gemeldet werden, falls die Punkt-zu-Mehrpunkt-Verbindung ohne diese Teilnehmer fortgesetztwerden soll. Während dieser Phase können allerdings andere oder der gerade abgemeldete Teilneh-mer erneut angemeldet werden. Die vollständige Abmeldung der Punkt-zu-Mehrpunkt-Verbindungwird durch Abmelden des letzten Teilnehmers erreicht.

4.2.1.1. Aufbauen einer Punkt-zu-Punkt-Verbindung

In diesem Abschnitt wird der Aufbau einer Punkt-zu-Punkt-Verbindung anhand des Nachrichten-verlaufs dargestellt. Die einzelnen Signalisierungsnachrichten sind durch sogenannte ‘InformationElements, IEs’ aufgebaut, die sowohl erforderliche als auch optionale Informationen für die Verbin-dungsverwaltung transportieren. Im weiteren Verlauf wird immer dann auf diese IEs eingegangen,falls dies für die Darstellung der Sicherheitsimplikationen erforderlich ist. Ansonsten werden nur dieNachrichtentypen angegeben. Dieser Nachrichtentyp ist selber wieder durch ein IE festgelegt, daszur Unterscheidung der verschiedenen Signalisierungsnachrichten benutzt wird. Dieses IE (‘messagetype IE’) ist daher auch in jeder Signalisierungsnachricht erforderlich.

In Abbildung 4-7 ist der Verbindungsaufbau dargestellt. Ein ATM-Endgerät (Terminal) sendet da-zu eine ‘SETUP’-Nachricht an den lokalen Switch. Wesentlich an dieser Nachricht sind die Angabenzum Empfänger und zur angefordertenDienstgüte. Die Empfangsadresse wird für die Wegwahl durchdas ATM-Netz benötigt, damit die virtuelle Verbindung durch die Switches geschaltet werden kann.Die Dienstgüteanforderungen (beispielsweise zur erforderlichen Übertragungsgeschwindigkeit) wer-den von den Switches benötigt, um eine Reservierung vorzunehmen. Jeder Switch auf dem Weg zumEmpfänger kann die Verbindung ablehnen, falls die erforderlichen Betriebsmittel nicht mehr zur Ver-fügung stehen.

Auch der Empfänger muß nach Eingang der ‘SETUP’-Nachricht entscheiden, ob die erforderlichenBetriebsmittel zur Verfügung stehen und die Verbindung angenommen werden soll. Ist dies der Fallsendet der Empfänger eine ‘CONNECT’-Nachricht zurück. Diese ‘CONNECT’-Nachricht wird vondem lokalen Switch bestätigt (‘CONNECT_ACK’) und durch das ATM-Netz zurück zum Initiatorder Signalisierung gesendet. Dieser bestätigt den Empfang der ‘CONNECT’-Nachricht seinem lo-kalen Switch ebenfalls mir einer ‘CONNECT_ACK’-Nachricht. Danach ist die virtuelle Verbindunggeschaltet und kann bidirektional mit der vereinbarten Dienstgüte benutzt werden.

49


Abbildung 4-7. Signalisierung einer Punkt-zu-Punkt-Verbindung

standard-sig

SETUP

Call_Proceeding*

CONNECT

CONNECT_ACK

SETUP

CONNECT

SETUP

Call_Proceeding*

CONNECT

CONNECT_ACK

ATM-Terminal ATM-Switch ATM-Switch ATM-Terminal

Der in Abbildung 4-7 beschriebene Ablauf ist der Regelfall. Es gibt verschiedene Fehlerszenarienund alternative Abläufe, auf die hier nicht weiter eingegangen wird. Wichtig ist allerdings, daß jederSwitch und auch das Endgerät beim Eintreffen einer ‘SETUP’-Nachrichtmit einer ‘RELEASE_COMPLETE’-Nachricht sofort den Verbindungsaufbau ablehnen kann. Die ‘RELEASE_COMPLETE’-Nachrichtwürde in diesem Fall die Ursache für die Verweigerung (beispielsweise ‘nicht genügend Bandbreiteverfügbar’) in einem ‘cause IE’ an den Initiator melden. In diesem Fall könnte keines der EndgeräteInformationen an das andere Terminal senden, da keine SVC geschaltet wurde!

4.2.1.2. Aufbauen einer Punkt-zu-Mehrpunkt-Verbindung

Die erste Phase des Aufbaus einer Punkt-zu-Mehrpunkt-Verbindungentspricht weitgehend der geradedargestellten Signalisierung für eine Punkt-zu-Punkt-Verbindung. Nach Abschluß der ersten Phasebesteht eine unidirektionale Verbindung vom Initiator (‘ROOT-Terminal’) der Punkt-zu-Mehrpunkt-Verbindung zum ersten Empfänger (‘LEAF-Terminal’). Auch hierbei werden im wesentlichen dieDienstgüte-AnforderungendemNetz bekanntgegeben, um auf den beteiligten Switches die benötigtenBetriebsmittel reservieren zu können.

In der zweiten Phase können nun weitere Empfänger (‘LEAF-Teminals’) hinzugefügt werden. Derwesentliche Unterschied zur ersten Phase besteht darin, daß die Dienstgüte-Anforderungen bereits in

50


der ersten Phase für alle weiteren ‘LEAF-Terminals’ festgelegt wurden und hier nicht geändert werdenkönnen. Das ‘Root-Terminal’ sendet anstelle der ‘SETUP’-Nachricht eine ‘ADD_PARTY’-Nachricht.Wesentlicher Bestandteil dieser Nachricht ist die ATM-Adresse des hinzuzufügenden ‘LEAF-Terminals’.Die Dienstgüte-Parameter können optional wiederholt werden. Erforderlich ist die Angabe jedochnicht, da der Switch diese Parameter bereits mit dem ersten ‘SETUP’ erhalten hat und selbstän-dig zu der ‘ADD_PARTY’-Nachricht hinzufügen kann. In Abbildung 4-8 ist der Ablauf graphischdargestellt. Die Zustimmung zur Verbindung bzw. die Ablehnung der Verbindung wird dem ‘Root-Terminal’ durch die Nachrichten ‘ADD_PARTY_ACK’ bzw. ‘ADD_PARTY_REJECT’ vom Switchmitgeteilt.

Abbildung 4-8. Signalisierung einer Punkt-zu-Mehrpunkt-Verbindung

standard-mp-sig

SETUP

CONNECT

CONNECT_ACK

ADD_PARTY

ADD_PARTY_ACK

SETUP

CONNECT

SETUP

CONNECT

SETUP

CONNECT

CONNECT_ACK

CONNECT_ACK

ATM-Terminal ATM-Switch

ATM-Terminal

ATM-Switch ATM-Terminal

51


4.2.1.3. Abbauen einer Punkt-zu-Punkt-Verbindung

Das Abbauen einer Punkt-zu-Punkt-Verbindung dient dem Freigeben der reservierten Betriebsmittel.Nach dem Verbindungsabbau können keine Daten mehr über den (abgebauten) SVC versendet wer-den. Der Verbindugsabbau kann von jedem der beiden Teilnehmer initiiert werden. Dazu versendet derTeilnehmer eine ‘RELEASE’-Nachricht, in der ein eindeutiger Bezeichner die abzubauende Verbin-dung kennzeichnet. Der Switch bestätigt den Verbindungsabbaumit einer ‘RELEASE_COMPLETE’-Nachricht und sendet die ‘RELEASE’-Nachricht gegebenenfalls über weitere Switches an das andereTerminal. Aufgrund der ‘RELEASE’-Nachricht können alle beteiligten Switches die Betriebsmittelfreigeben, die zuvor für den SVC reserviert wurden. In Abbildung 4-9 ist das Beenden einer Punkt-zu-Punkt-Verbindung noch einmal graphisch dargestellt.

Abbildung 4-9. Abbauen einer Punkt-zu-Punkt-Verbindung

standard-rel

RELEASE

RELEASE_COMPLETE

RELEASE

RELEASE

RELEASE_COMPLETE

ATM-Terminal

SVCetabliert

SVCabgebaut

ATM-Switch ATM-Switch ATM-Terminal

SVCetabliert

SVCabgebaut

4.2.1.4. Abbauen einer Punkt-zu-Mehrpunkt-Verbindung

Das Abbauen einer Punkt-zu-Mehrpunkt-Verbindung kann sowohl von dem ‘Root’-Terminal als auchvon einem der ‘LEAF’-Terminals erfolgen. Während die einzelnen ‘LEAF’-Terminals sich selber ab-

52


melden können, kann das ‘ROOT’-Terminal die Verbindung zu jedem beliebigen ‘LEAF’-Terminalabbauen. ImGegensatz zu der symmetrischen Signalisierung bei der Punkt-zu-Punkt-Verbindungsverwaltung(gleiche Nachrichtenabläufe unabhängig vom Terminal) ist die Signalisierung im Falle der Punkt-zu-Mehrpunkt-Verbindung auch beim Abbauen der Verbindung asymmetrisch und daher komplexer.

Ein Terminal, das aus einer Punkt-zu-Mehrpunkt-Verbindungausscheidenmöchte, sendet eine ‘RELEASE’-oder eine ‘RELEASE-COMPLETE’-Nachricht. Ein ‘LEAF’-Terminal verhält sich somit wie beimAbbauen einer Punkt-zu-Punkt-Verbindung. Das Netz generiert für das ‘Root’-Terminal hieraus eine‘DROP_PARTY’-Nachricht, falls noch andere ‘LEAF’-Nodes zu der Punkt-zu-Mehrpunktverbindunggehören.Andernfalls generiert das Netz eine ‘RELEASE’-Nachricht, da kein weiteres ‘LEAF’-Terminalmehr an der Verbindung beteiligt ist, so daß die Verbindung vollständig abgebaut werden kann.

Ein ‘ROOT’-Terminal sendet eine ‘DROP_Party’-Nachricht, um ein bestimmtes ‘LEAF’-Terminalaus der Punkt-zu-Mehrpunkt-Verbindungherauszunehmen.Das Netz generiert für das ‘ROOT’-Terminaleine ‘DROP_PARTY_ACK’-Nachricht und für das ‘LEAF’-Terminal eine ‘RELEASE’-Nachricht.Dem letzten ‘LEAF’-Terminal sollte bereits vom ‘ROOT’-Terminal eine ‘RELEASE’-Nachricht ge-sendet werden. Hiermit gibt das ‘ROOT’-Terminal gleichzeitig an, daß die Punkt-zu-Mehrpunkt-Verbindung vollständig abzubauen ist. Sendet das ‘ROOT’-Terminal eine ‘RELEASE’-Nachricht,während weitere ‘LEAF’-Terminals noch zur Verbindung gehören, dann baut das Netz die Punkt-zu-Mehrpunkt-Verbindung stellvertretend für das ‘ROOT’-Terminal ab. Dies entspricht in etwa demSenden von einzelnen ‘DROP_PARTY’-Nachrichten an die ‘LEAF’-Terminals mit dem Unterschied,daß das ‘ROOT’-Terminal nicht mehr selektiv die Teilnehmer benachrichtigt und daher auch nur eine‘RELEASE_COMPLETE’-Nachricht vom Netz bekommt anstelle mehrere ‘DROP_PARTY_ACK’-Nachrichten für jedes einzelne ‘LEAF’-Terminal. In Abbildung 4-10 sind die verschiedenen Abläufenoch einmal graphisch dargestellt.

Abbildung 4-10. (Teil-)Abbauen einer Punkt-zu-Mehrpunkt-Verbindung

53


unimpabbau

DROP_PARTY

DROP_PARTY_ACK

DROP_PARTY

DROP_PARTY_ACK

DROP_PARTY

DROP_PARTY_ACK

RELEASE

RELEASE_COMPLETE

RELEASE

RELEASE_COMPLETE

ROOT

ATM-Terminal

P-to-MPetabliert

P-to-MPetabliert

P-to-MPetabliert

ATM-Switch ATM-Switch

LEAF2

ATM-Terminal

P-to-MPetabliert

SVCabgebaut

LEAF1

ATM-Terminal

P-to-MPetabliert

SVCabgebaut

4.2.2. AngriffsmöglichkeitenIn diesem Abschnitt werden die an der UNI-Schnittstelle erkennbaren Angriffe diskutiert. Einige An-griffe werden jedoch nicht unmittelbar an dem lokalen Switch stattfinden, sondern können durchausauch über das Netz erfolgen.

An der UNI-Schnittstelle sind Angriffe auf die Vertraulichkeit, Integrität und Authentizität der Daten

54


möglich. Diese Angriffe erfolgen entweder direkt durch die Signalisierung, im Zuge der Signalisie-rung oder werden durch die Signalisierung vorbereitet.

Das in Kapitel 3 diskutierte ‘Security Framework’ entstand aus der Erkenntnis, daß insbesondere dieVerbindungsverwaltung in ATM-Netzen als sicherheitskritisch zu bewerten ist. Daher ist es sehr wün-schenswert, daß die diskutierten Dienste baldmöglichst umgesetzt werden. Bis das jedoch geschieht,muß jeder Betreiber eines ATM-Netzes versuchen, mit eigenen Maßnahmen die folgenden Angriffezu erkennen und möglichst einzudämmen.

4.2.2.1. Angriff auf die Authentizität der Signalisierungsnachrichten

Ein wesentliches Problem in ATM-Netzen ist, daß es kein IE innerhalb der Signalisierungsnachrichtengibt, das verbindlich über die Herkunft (Initiator) einer Signalisierungsnachricht informiert. Konkreterbedeutet dies, daß die Switches keine Möglichkeit haben, die Herkunft der Signalisierung zu verifi-zieren. Dies drückt sich schließlich auch darin aus, daß das IE zur Übertragung der Absenderadresse(Adresse des Initiators einer Verbindung) nur optional in der ‘SETUP’- und der ‘ADD_PARTY’-Nachricht eingetragenwird. Hieraus resultiert auch, daß die vom Initiator optional angegebeneAdres-se nicht automatisch überprüft wird. Die Adresse kann demnach frei gewählt werden, so daß es inATM-Netzen geradezu trivial ist, Adreß-Spoofing zu betreiben (vgl. BeE98).

Die Herkunftsangabe (‘Calling Party’-IE) ist somit nicht geeignet, um die Herkunft der Signalisierungzu authentisieren. In diesem Sinne ist der Angriff vergleichbar mit ‘IP-Spoofing’. Das Problem ist je-doch bei ATM dramatischer, da es nur einmal zu Beginn der Signalisierung in der ‘SETUP’-Nachrichterforderlich ist, eine falsche Adresse anzugeben. In den später übertragenen Zellen sind keine Endsy-stemadreßinformationenmehr vorhanden, so daß die einmalige Vortäuschung einer fremden Identitätfür die Dauer der ATM-Verbindung ausreicht und nicht wie bei IP in jedem Datagramm wiederholtwerden muß.

4.2.2.2. Angriffe auf die Integrität der Zellen

Es ist bei ATM nicht vorgesehen, daß einzelne Zellen durch kryptographische Mechanismen abge-sichert werden. Insbesondere gibt es keine standardisierte Möglichkeit, intentionale Verfälschungeneinzelner Zellen mit Hilfe von ‘Message Authentication Codes, MAC’ zu erkennen. Es ist daherdenkbar, daß einzelne Zellen gezielt manipuliert werden, um die übertragenen Informationen zu ver-fälschen.

Die Manipulation am Nutzdatenteil einer Zelle kann auch als einfacher DoS-Angriff benutzt werden.Wird nur ein Bit im Nutzdatenteil einer Zelle verändert, fällt diese Manipulation im ATM-Netz nichtauf. Die Zelle und alle weiteren Zellen, die zur jeweiligen AAL-PDU gehören, werden demnach biszum Endgerät weiter gesendet. Hier ist die Manipulation u.U. anhand der Prüfsumme der AAL-PDUerkennbar, nachdem die AAL-PDU aus den einzelnen Zellen reassembliert wurde. Auf der ATM-Ebene bzw. an der UNI-Schnittstelle sind derartige intentionale Manipulationen jedoch nicht erkenn-bar.

55


4.2.2.3. DoS-Angriffe basierend auf UNI

Im Vergleich zu ‘Broadcast’-Netzen mit relativ einfachen Netz-Zugriffsmechanismen, wie beispiels-weise CSMA/CD bei Ethernet, ist die Verwaltung der Ressourcen sowohl im ATM-Netz als auch inden Endgeräten deutlich komplexer und somit zeitaufwendig. Aus der Sicht eines Angreifers eignensich ATM-Netze daher in besonderemMaße für DoS-Angriffe.

Bei dieser Art von DoS-Angriffen nutzt der Angreifer entweder die Reservierungsmöglichkeiten desATM-Netzes aus, um möglichst viele Ressourcen zu binden und somit anderen Benutzern die Be-triebsmittel vorzubehalten. Oder aber der Angreifer simuliert die Reservierung der Betriebsmittel nur,um so aufwandsarm sehr komplexe Verwaltungsoperationen im ATM-Netz anzustoßen, die wiederumden Zugriff anderer Benutzer verlangsamen.

4.2.2.3.1. DoS durch Reservieren von Netz-Betriebsmitteln

Bei diesem Angriff fordert der Angreifer beim Verbindungsaufbau möglichst viele Betriebsmittelvom Netz an. Das einfachste Beispiel für diese Art von DoS-Angriff besteht in der Reservierung ei-ner ‘Constant-Bit-Rate’ (CBR), die möglichst der maximalen Übertragungsgeschwindigkeit an derlokalen UNI-Schnittstelle entspricht. Gelingt der Verbindungsaufbau, kann bis zum Abbau der Ver-bindung kein weiterer Benutzer auf den betroffenen Teilabschnitten eine weitere (CBR-)Reservierungvornehmen, da das Netz die Ressourcen bereits an den Angreifer vergeben hat. In Abbildung 4-11 istgraphisch dargestellt, wie durch die geschickte Wahl eines Endsystems ein Angreifer durch die Re-servierung gezielt ein Teilnetz an der Kommunikation hindern kann. Das Teilnetz ‘intern’ benutztzusammen mit den beiden Teilnetzen ‘extern1’ und ‘extern2’ einen gemeinsamen Zugang zum Inter-net. Ein Angreifer (hier ‘Host 1, H1’) kann nun durch Aufbauen einer Verbindung zu einem anderenEndsystem (hier H2 in ‘extern2’) und Anfordern der maximalen Übertragungsgeschwindigkeit aufdem Teilabschnitt zwischen den Switches in ‘extern1’ und ‘extern2’ das Teilnetzt ‘intern’ massiv ander Kommunikation mit dem Internet oder den anderen Teilnetzen behindern.

Abbildung 4-11. DoS durch CBR-Reservierung

H2

WAN(Internet)

H1

ATM-Switch

Virtuelle Verbindung (H1 = Angreifer)

extern2

extern1

intern

56


Gelingt die Reservierung der maximalen Übertragungsgeschwindigkeit als CBR-Verbindung, dannkann kein Endgerät aus den Teilnetzen eine weitere CBR-Verbindung aufbauen, die auch nur teilwei-se parallel zur virtuellen Verbindung des Angreifers verlaufen würde (z.B. von ‘intern’ zu ‘extern1’).Dies gilt auch für andere exklusiv reservierende Verkehrsklassen wie beispielsweise ‘Available BitRate’. Der einzige Ausweg bestünde im Aufbauen einer ‘Unspecified Bit Rate, UBR’-Verbindung.Aber auch in diesem Fall könnten die Endgeräte nur dann Daten austauschen, wenn der Angreiferkeinen Gebrauch von seiner Reservierung macht und nicht über seine CBR-Verbindung sendet. DerAngreifer hätte auf Grund der früheren, exklusiven Reservierung in jedem Fall Vorrang vor der Über-tragung auf der UBR-Verbindung.

4.2.2.3.2. DoS durch exessives Signalisieren

Messungen im DFN-FWL haben ergeben, daß bei einem LS 1010 Switch nur ca. 100 Verbindungsauf-und -abbau-Abläufe pro Sekunde möglich sind. Dieser, im Verhältnis zur enorm hohen Zellrate (beimSwitchen erreichbarer Durchsatz an Zellen pro Sekunde) verschwindend geringe Durchsatz bei derVerbindungsverwaltung, liegt darin begründet, daß die Signalisierung in Software implementiert istund gleichzeitig sehr komplexe, zeitaufwendige Operationen durchführen muß.

Bei einer eintreffenden ‘SETUP’-Nachricht muß ein Switch vor dem Weiterleiten der Nachricht prü-fen, ob die zu reservierenden Betriebsmittel zur Zeit (noch/wieder) vorhanden sind oder bereits ver-geben sind. Sind lokal alle Betriebsmittel für den Aufbau der Verbindung vorhanden, werden siereserviert und die ‘SETUP’-Nachricht wird an den nächsten Switch oder das Endgerät weiterge-reicht. Die Überprüfung und Reservierung der Betriebsmittel ist so aufwendig, daß ein Angreiferaufwandsarm durch Senden von ‘SETUP’-Nachrichten einen DoS auf dem lokalen Switch und wei-teren Switches (abhängig von der Wahl der Empfängeradresse in der ‘SETUP’-Nachricht!) auslösenkann. Dazu ist nicht einmal ein vollständiger Protokollautomat für die Signalisierung beim Angreifererforderlich. Beim Eintreffen einer ‘CONNECT’-Nachricht kann der Angreifer vielmehr gleich mit‘RELEASE_COMPLETE’ antworten, um auf den Switches unmittelbar weitere Aufträge zur Verbin-dungsverwaltung zu generieren.

Andere Benutzer werden durch diesen DoS-Angriff beim Auf- und Abbauen von eigenen Verbin-dungen behindert. Besonders störend ist dieser Angriff dadurch, daß bei Kenntnis der Topologie eineEndsystemadresse in der ‘Called Party-IE’ vom Angreifer eingetragen werden kann, die ein aufwen-diges Routing über viele Switches erfordert, so daß möglichst viele Switches an der Signalisierungbeteiligt sind. Der Aufwand für den Angreifer steigt dadurch nicht, die Anzahl der betroffenen Netz-komponenten und Endgeräte jedoch erheblich.

4.2.2.3.3. DoS durch Aufbrauchen der Endsystembetriebsmittel

Die bereits diskutierten DoS-Angriffe sind kritisch, da sich die Angriffe auf die Infrastruktur, also aufdas ATM-Netz als solches, richten. Es ist jedoch auch möglich, gezielt ein bestimmtes Endgerät ineinem ATM-Netz anzugreifen, beispielsweise um einen wichtigen Dienst zu blockieren.

57


Ziel eines solchen Angriffs ist es daher, die Betriebsmittel des angegriffenen Endsystems auf derATM-Ebene zu blockieren, so daß das Endgerät (temporär) nicht mehr über das ATM-Netz ansprech-bar ist oder zumindest deutlich in der Reaktionszeit eingeschränkt ist.

Der Angreifer kann hierfür wiederum versuchen, durch massives Signalisieren die Verarbeitung aufdem Endgerät zu stören. Hierbei wird jedoch nicht durch Reservieren von exklusiven Netzbetriebs-mitteln der DoS ausgelöst (dann wären im wesentlichen die Switches betroffen, s.o.), sondern durchAufbrauchen der für die Verbindungsverwaltung auf dem Endsystem benötigten Ressourcen.

Ein Beispiel für diese Art vonAngriff nutzt die Implementierung vieler ATM-Schnittstellenprozessorenaus, nur eine begrenzte Anzahl von zeitgleichen Verbindungen zuzulassen. Das Zellformat an derUNI-Schnittstelle unterstützt zwar prinzipiell 2**24 parallele virtuelle Verbindungen zu einem End-gerät (vgl. Abbildung 2-1), jedoch können die Signalprozessoren auf gängigenATM-Endgeräteschnittstellen(‘ATM-Karte’ für PC oder Workstation) in der Regel nur einige hundert bis wenige tausend gleich-zeitige Verbindungen unterstützen. Der Grund hierfür ist, daß für die Reassemblierung der AAL-Dateneinheiten aus den eintreffenden Zellen nur eine begrenzte Anzahl von parallelen Funktionsein-heiten auf diesen Chips zur Verfügung steht, für jede virtuelle Verbindung aber eine dieser Funktions-einheiten benötigt wird.

Ein Angreifer kann daher versuchen, durch Öffnen von vielen Verbindungen zu einem Endsystem,dessen Ressourcen für die Verwaltung paralleler Verbindungen aufzubrauchen. Der Angreifer selberbraucht dafür nur die Signalisierung durchzuführen ohne selber eigene Betriebsmittel für die Verbin-dungen zu reservieren. Dem angegriffenen System gehen jedoch die Betriebsmittel aus, so daß späterkommende Verbindungswünsche anderer Endsysteme abgelehnt werden müssen.

Zu beachten ist bei dieser Art von Angriffen noch, daß der Angreifer durch Signalisieren mit be-triebsmittelschonenden Anforderungen (beispielsweise UBR-Verbindung) das dazwischenliegendeNetz kaum belastet und so tatsächlich gezielt ein Endsystem angreifen kann.

4.2.3. GegenmaßnahmenOhne die Implementierung der ATM Forum Sicherheitsempfehlungen (vgl. Kapitel 3) gibt es vor-aussichtlich keine standardisierten Methoden zur kryptographischen Absicherung der Kommunika-tion. Es gibt jedoch einige herstellerspezifische (proprietäre) Ansätze und Möglichkeiten, um in derZwischenzeit die Sicherheit bei der Kommunikation durch einfachere administrative Maßnahmen zuerhöhen.

Mittlerweile haben die Switch-Hersteller eine Reihe von Funktionen in ihre Switches aufgenommen,mit denen sich zumindest ein Teil der oben beschriebenen Angriffe eindämmen oder gar verhindernlassen. Voraussetzung für die folgenden Schritte ist wie bereits bei der Darstellung von Gegenmaß-nahmen für ILMI basierte Angriffe (vgl. Abschnitt 4.1.4), daß die lokalen Switches vollständig undausschließlich unter der Kontrolle des Sicherheitsadministrators sind.

4.2.3.1. Verhindern von Angriffen auf die Authentizität

58


Da die Absenderadresse beliebig vomAngreifer gewählt werden kann, ist eine Absicherung gegen dasFälschen von ‘Calling-Party-IEs’ ohne kryptographischeMechanismen eigentlich nicht möglich. AmÜbergang von unsicheren öffentlichen Netzen zu internen Firmennetzen ist daher grundsätzlich denAdreßinformationen bei eingehenden Signalisierungen zu mißtrauen. Auf keinen Fall sollten dieseAdressen für eine Authentifizierung des Kommunikationspartners verwendet werden.

Innerhalb eines Firmennetzes hat der Sicherheitsadministrator jedoch die Möglichkeit, die beliebigeVerwendung von ATM-Adressen zu verhindern. Es besteht sogar die Möglichkeit, die Signalisierungsoweit einzuschränken, daß pro ATM-Endgerät nur noch eine bestimmte, vordefinierte ATM-Adresseverwendet werden kann. Unter der Voraussetzung, daß nur der/die Sicherheitsadministrator(en) dieSwitch-Konfigurationen ändern können, ist dann sogar eine schwache Authentisierung auf Basis derATM-Adressen möglich.

Bei der Beschränkung der Signalisierung lohnt es sich systematisch vorzugehen. Wird konsequentjede Switch-Schnittstelle so konfiguriert, daß nur noch mit einer bestimmten Anzahl von Adressensignalisiert werden kann, ergibt sich zusätzlich die Möglichkeit, das physikalische ATM-Netz mitmehreren voneinander getrennten virtuellen Netzen zu überlagern, die nur über dedizierte Übergänge(Firewalls) miteinander verbunden sind. Die Vorgehensweise ist dann folgendermaßen:

• Feststellen der Endgeräteadresse an jedem Port

Die an einen Switch angeschlossenen Endgeräte melden sich in der Autokonfigurationsphase üb-licherweise mit einem herstellerspezifischen ESI-Adreßanteil beim Switch an. Dies entspricht inetwa der Verwendung der Herstelleradresse bei Ethernet- oder Fast-Ethernet-Schnittstellen. Beider ersten Inbetriebnahme eines Gerätes sollte diese Adresse festgestellt werden. Falls aus der Do-kumentation nicht bekannt ist, um welche Adresse es sich handelt, dann kann mit folgenden Kom-mandos für die einzelnen Schnittstellen die Default-Adresse am Switch angezeigt werden (vgl.Beispiel 4-4):

Beispiel 4-4. ILMI-Adreßinformationen abrufen

Switch# atm ilmi-status

Interface : ATM0/0/1 Interface Type : Private UNI (Network-side)

ILMI VCC : (0, 16) ILMI Keepalive : Disabled

Addr Reg State: UpAndNormal

Peer IP Addr: 192.168.16.71 Peer IF Name: ba0

Peer MaxVPIbits: 0 Peer MaxVCIbits: 10

Configured Prefix(s) :

47.0091.8100.0000.0010.11ba.8f01

Registered Address(s) (Scope):

47.0091.8100.0000.0010.11ba.8f01.0800.2082.7e61.00 (global)



Addr Reg State: UpAndNormal

Peer IP Addr: 192.168.16.78 Peer IF Name: ba0


59



47.0091.8100.0000.0010.11ba.8f01


47.0091.8100.0000.0010.11ba.8f01.0800.2084.f231.00 (global)

Man erkennt sowohl den konfigurierten Netzprefix als auch die vollständige ATM-Adresse, mitder sich das ATM-Endgeträt angemeldet hat. Zusätzlich muß die Portnummer- (Interface-) Angabenotiert werden. Im obigen Beispiel sind das die Schnittstellen ATM0/0/1 und ATM1/1/0.

• Festlegen der VLAN-Zugehörigkeit

Danach ist eine Entscheidung zu treffen, welche ATM-Endgeräte mit welchen anderen ATM-Endgeräten kommunizieren dürfen. Hierzu werden Mengen von ATM-Adressen gebildet, die dieVLAN-Zugehörigkeit der ATM-Terminals anhand der oben festgestellten ATM-Adreß/Port-Belegungfestlegen. Ein ATM-Terminal kann dabei durchaus in mehreren VLANs vorkommen. Dieses Ter-minal ist dann beispielsweise ein Router oder Firewall zwischen den verschiedenen VLANs undmuß entsprechend abgesichert werden.

• Konfigurieren der Adreßfilter

Die einzelnen Adressen werden als sogenannte ‘Filter-Sets’ (FS) zusammengefaßt und anschlie-ßend werden diese FS benutzt, um die Signalisierung an den einzelnen Switch-Ports auf die ihnenzugeordneten ‘Filter-Sets’ zu beschränken.

Die Konfiguration wird am Beispiel von drei virtuellen Netzen diskutiert. In Abbildung 4-12 ist dieTopologie dargestellt und die drei VLANs (a=rot, b=blau, d=grün) sind gekennzeichnet. Zusätzlichgibt es einen Firewall und einen Anschluß an das Internet. Das physikalische ATM-Netz ist aus dreimiteinander verbundenen Switches (S1, S2, S3) aufgebaut. Die einzelnen Ports (Schnittstellen) derSwitches sind durchnumeriert. Falls an einem Port eine Workstation (ATM-Terminal, als Kreisedargestellt) angeschlossen ist, ist der jeweilige Port farblich hervorgehoben. Zur einfacheren Dar-stellung nehmenwir an, daß die ATM-Adresse eines ATM-Terminal gleich der eingetragenenNum-mer ist. Weiterhin werden die Ports der Switches nicht in der ATM Slot/Modul/Port-Notationangegeben, sondern einfach durch die Angabe der entsprechenden Nummer.

Abbildung 4-12. VLANs überlagern ein ATM-Netz

60


Internet

2

1

3

7b

8b

4c

Firewall

5d

6d

a

a

b

3

4

1 5

1

2

5

34

2

1 5

32 4

S3

S1 S2

Es soll folgende Policy gelten:

1. Sämtlicher Internetverkehr wird nur über den Firewall zugelassen.

2. Endgeräte des roten VLANs dürfen mit keinem anderen VLAN und auch nicht mit dem Inter-net kommunizieren.

3. Das blaue VLAN darf mit dem grünen VLAN kommunizieren, jedoch nicht mit dem Internet.

4. Das grüne VLAN darf mit dem blauen VLAN und über den Firewall mit dem Internet kom-munizieren.

Auf allen Switches sollte zuerst die VLAN-Zugehörigkeit der einzelnen Rechner konfiguriert wer-den. Die Konfiguration wird hier am Beispiel in aller Ausführlichkeit vorgenommen. Zu beachtenist, daß hinter den Schlüsselwörtern permit und deny eigentlich die ATM-Adressen stehen, diedurch die Schritte aus Beispiel 4-4 herausgefunden wurden. Im folgenden Beispiel werden anstel-

61


le der 20-Byte langen ATM-Adressen nur die Zahlen der ATM-Terminals aus obiger Abbildungverwendet.

Beispiel 4-5. VLANs benennen

VLANa benennen:

Switch# atm filter-set VLANa permit 1Switch# atm filter-set VLANa permit 2Switch# atm filter-set VLANa deny defaultSwitch# atm filter-set H1 permit 1Switch# atm filter-set H1 deny defaultSwitch# atm filter-set H2 permit 2Switch# atm filter-set H2 deny default

VLANbd benennen. Die VLANs b und d können zusammengefaßt werden, da sich die Policy nurim Zugriff auf den Firewall unterscheidet. Dieser Fall wird weiter unten durch die Boolesche-Verknüpfung in einer filter-expression behandelt.

Switch# atm filter-set VLANbd permit 3Switch# atm filter-set VLANbd permit 7Switch# atm filter-set VLANbd permit 8Switch# atm filter-set VLANbd permit 5Switch# atm filter-set VLANbd permit 6Switch# atm filter-set VLANbd deny defaultSwitch# atm filter-set H3 permit 3Switch# atm filter-set H3 deny defaultSwitch# atm filter-set H7 permit 7Switch# atm filter-set H7 deny defaultSwitch# atm filter-set H8 permit 8Switch# atm filter-set H8 deny defaultSwitch# atm filter-set H5 permit 5Switch# atm filter-set H5 deny defaultSwitch# atm filter-set H6 permit 6Switch# atm filter-set H6 deny default

Firewall und Blockregeln benennen:

Switch# atm filter-set FWL permit 4Switch# atm filter-set FWL deny defaultSwitch# atm filter-set BLOCK deny default

Anschließend kann definiert werden, ob die vereinbarten „filter-sets“ (als Mengen von ATM-Adressen)bei der Signalisierung auf die ‘Calling-Party-IE’ oder die ‘Called-Party-IE’ angewendet werdensollen. Die Bezeichnung ist hierbei allerdings source für ‘Calling-Party-IE’ und destination

für ‘Called-Party-IE’. Bei der Definition der nun folgenden ‘filter-Ausdrücke’ (filter-expressions)ist daher zu beachten, daß sich diese nur auf die ‘Called-Party-IEs’ beziehen, da die Senderadressen(source bzw. ‘Calling-Party-IE’) fälschbar sind!

62


Mit anderen Worten, die nun folgende Definitionen erlauben das Signalisieren zu bestimmtenAdressen, deren Verfälschung keinen Sinn ergeben würde. Alle anderen Signalisierungen sinddurch die oben angegebenen default deny Ausdrücke ohnehin nicht erlaubt.

Beispiel 4-6. Empfangsadressen zulassen

Signalisierung zu VLANs erlauben

Switch# atm filter-expr toVLANa destination VLANaSwitch# atm filter-expr toVLANb destination VLANbSwitch# atm filter-expr toVLANbdFWL destination VLANbd or destination FWLSwitch# atm filter-expr toVLANd destination VLANdSwitch# atm filter-expr toVLANbd destination VLANbdSwitch# atm filter-expr toFWL destination FWLSwitch# atm filter-expr toBLOCK destination BLOCK

Signalisierung zu Endgeräten erlauben

Switch# atm filter-expr toH1 destination H1Switch# atm filter-expr toH2 destination H2Switch# atm filter-expr toH3 destination H3Switch# atm filter-expr toFWL destination FWLSwitch# atm filter-expr toH5 destination H5Switch# atm filter-expr toH6 destination H6Switch# atm filter-expr toH7 destination H7Switch# atm filter-expr toH8 destination H8

Signalisierung vom Firewall zum Internet erlauben.

Hierbei handelt es sich um eine Sonderregel. Es wird ein Filter auf die ‘Calling-Party-Number’definiert, da in das Internet zu à priori unbekannten Adressen signalisiert werden muß. Allerdingsdarf der Initiator dieser Verbindungen ausschließlich der Firewall sein. Der Firewall hat somit eineSonderrolle.

Switch# atm filter-expr toInternet source FWL

Nachdem mit den ‘filter-expressions’ (Filter-Ausdrücke) auf Basis der ‘filter-sets’ die zulässigenZiele unabhängig von den jeweiligen Schnittstellen der Switches spezifiziert worden sind, kann dieindividuelle Festlegung der Switchschnittstellen die VLAN-Konfiguration abschließen. Es ist erfor-derlich, die vorher spezifizierten Filter-Ausdrücke in Bezug zu den eingehenden bzw. ausgehendenSignalisierungsnachrichten (hier: SETUP-Nachrichten) an jedem individuellen Port der Switcheszu setzen. Aus Sicht des Switches können Signalisierungsnachrichten entweder vom Endgerät zumSwitch (‘incoming call’) oder vom Switch zu einem Endgerät gesendet werden (‘outgoing call’).

Durch die folgenden Konfigurationsschritte wird den Rechnern die Signalisierung nur zu anderenTeilnehmern in ihrem VLAN(s) erlaubt und gleichzeitig verhindert, daß zu einem Rechner miteiner anderen Adresse signalisiert wird, als die bereits vom Administrator zugewiesene Adresse.Dadurch ist auch das offene Problem aus Abschnitt 4.1.3.2 bezüglich der beliebigen Adreßreser-vierung durch ein ATM-Terminal weitgehend gelöst, da die Adreßreservierung mittels ILMI zwar

63


möglich ist, die zusätzlichen Adressen jedoch aufgrund der nun folgenden Einschränkung der Si-gnalisierung nicht verwendet werden können.

Beispiel 4-7. Filter mit den Switch-Schnittstellen verknüpfen

VLANs auf Switch S1 konfigurieren

Switch_S1# interface atm 1Switch_S1(config-if)# atm access-group toVLANa inSwitch_S1(config-if)# atm access-group toH1 outSwitch_S1(config-if)# ^ZSwitch_S1# interface atm 2Switch_S1(config-if)# atm access-group toVLANa inSwitch_S1(config-if)# atm access-group toH2 outSwitch_S1(config-if)# ^ZSwitch_S1# interface atm 5Switch_S1(config-if)# atm access-group toVLANbd inSwitch_S1(config-if)# atm access-group toH7 outSwitch_S1(config-if)# ^Z


Switch_S2# interface atm 5Switch_S2(config-if)# atm access-group toVLANbd inSwitch_S2(config-if)# atm access-group toH8 outSwitch_S2(config-if)# ^ZSwitch_S2# interface atm 4Switch_S2(config-if)# atm access-group toVLANbdFWL inSwitch_S2(config-if)# atm access-group toH6 outSwitch_S2(config-if)# ^ZSwitch_S2# interface atm 3Switch_S2(config-if)# atm access-group toVLANbdFWL inSwitch_S2(config-if)# atm access-group toH5 outSwitch_S2(config-if)# ^Z


Switch_S3# interface atm 2Switch_S3(config-if)# atm access-group toVLANbd inSwitch_S3(config-if)# atm access-group toH3 outSwitch_S3(config-if)# ^ZSwitch_S3# interface atm 3Switch_S3(config-if)# atm access-group toFWL outSwitch_S3(config-if)# ^ZSwitch_S3# interface atm 4Switch_S3(config-if)# atm access-group toFWL inSwitch_S3(config-if)# atm access-group toInternet out

Abschließend sollten alle unbelegten Schnittstellen des Switches deaktiviert werden, wie in Bei-spiel 4-2 dargestellt. Alternativ kann durch die folgende Konfiguration das Signalisieren auf den

64


unbelegten Schnittstellen der Switches unterbunden werden. Die Befehle müssen für alle unbeleg-ten Schnittstellen eingetragen werden!

Beispiel 4-8. Verhindern der Signalisierung auf unbenutzten Switch-Schnittstellen

Switch# interface atm 1/2/3Switch(config-if)# atm access-group toBLOCK inSwitch(config-if)# atm access-group toBLOCK out

Durch dieses Vorgehen wird erreicht, daß innerhalb des ATM-Netzes nur noch mit den vom Admi-nistrator vorgegebenen Adressen zu den ebenfalls vom Administrator vorgegebenen Endgeräten Ver-bindungen aufgebaut werden können. Dies ermöglicht die oben genannte ‘schwache Authentisierung’mit Hilfe der ATM-Adressen. Wichtig ist hierbei, die Adreßinformationen in einer Positiv-Liste zuführen. Zusammenfassend bedeutet dies, daß eigentlich sämtliche Signalisierungen verboten werdenund nur noch die explizit freigeschalteten ATM-Adressen angesprochen werden dürfen.

In dem Beispiel muß allerdings die Sonderrolle des Firewalls beachtet werden. Es können keine Filterdefiniert werden, die die Signalisierung vom Firewall einschränken (keine atm access-group xyz

in auf dem Firewall-Port). Dies hat zur Folge, daß die Trennung der VLANs b und d bei Signalisie-rung aus dem Internet auch durch den Firewall übernommenwerden muß. Der Firewall muß also auchKenntnis über die VLANs haben und darf keine Daten aus dem Internet zu Teilnehmern im VLAN bweiterleiten.

Für den Fall, daß der Internet-Provider eine bestimmte ATM-Adresse als Zugangspunkt zum Inter-net festgelegt hat, sollte eine entsprechende atm access-group auch auf dem Firewall-Port desSwitches definiert werden. In diesem Fall muß dann auch die Signalisierung zu VLAN d explizitfreigeschaltet werden:

Beispiel 4-9. Dedizierte Adresse des Internetzugangs (IZ)

Switch# atm filter-set FWLout permit IZSwitch# atm filter-set FWLout permit 5Switch# atm filter-set FWLout permit 6Switch# atm filter-set FWLout deny defaultSwitch# atm filter-expr toFWLout destination FWLout

Zusätzlich auf Switch 3:

Switch_S3# interface atm 3Switch_S3(config-if)# atm access-group toFWL outSwitch_S3(config-if)# atm access-group toFWLout in

65


Restrisiken der dargestellten Absicherung

Das Beispiel beschränkt wirksam die Signalisierung der einzelnen ATM-Terminals untereinan-der. Wird über die virtuellen Verbindungen anschließend mittels TCP/IP kommuniziert, dann istsicherzustellen, daß die Policy nicht durch die IP-Konfiguration der Workstations verletzt wird.Beispielsweise muß auf den Rechnern in VLAN d das IP-Routing (ip_forwarding) abgeschaltetwerden, damit die Dateneinheiten von Rechnern aus VLAN b nicht über VLAN d in das Internetgelangen können. Am einfachsten ist dies durch Kenntnis der VLAN-Zugehörigkeit auf dem Fi-rewall zu erreichen. Eine Packet Screen könnte hier den Zugriff von IP-Adressen aus VLAN b indas Internet verhindern, unabhängig von dem Weg der Dateneinheiten über einen ‘Router’ ausVLAN d.

4.3. ‘Private Network Network Interface’ (PNNI)Das ‘Private NetworkNetwork Interface’ beschreibt eine Spezifikation (vgl. AFo96) des ATM-Forumsfür ein Protokoll, das an der NNI-Schnittstelle zwischen ATM-Switches eingesetzt wird. Dieses Pro-tokoll kann von einem Angreifer ausgenutzt werden, um den Verbindungsaufbau in größeren ATM-Netzen zu stören.

4.3.1. Funktionsweise von PNNIDas PNNI-Protokoll ist sehr komplex und kann deshalb nicht in der Ausführlichkeit dargestellt wer-den, wie die bereits diskutierten Standardprotokolle. Es wird eine kurze Beschreibung der Aufgabendieses Protokolls vorgenommen, um anschließend die möglichen Angriffe kurz zu skizzieren.

4.3.1.1. Wegwahl (Routing) in ATM-Netzen

Eine Hauptfunktion des PNNI-Protokolls ist die Wegfindung durch ein beliebig vermaschtes ATM-Netz. Ähnlichwie bei IP-Netzenwird dazu ein Protokoll eingesetzt, das demAustausch vonWegwahl-Informationen (sogenannten „Metriken“) dient.

Vereinfacht dargestellt werden zwischen benachbarten Switches periodisch Informationen über dieerreichbaren Adressen ausgetauscht. Dadurch erfährt schließlich jeder Switch im ATM-Netz, überwelche Wege (Routen) ein bestimmtes Zielsystem erreicht werden kann.

Die ausgetauschten Informationen können sehr schnell erheblich anwachsen. Daher versucht dasPNNI-Protokoll die Informationen so zu vereinfachen, daß jeder Switch nur die unbedingt erfor-derlichen Informationen erhält und unwesentliche Informationen nicht gespeichert werden müssen.Dazu richtet der Administrator sogenannte „Peer Groups“ ein. Hierbei handelt es sich um eine Grup-

66


pe von Switches, die über denselben Adreßprefix verfügen. Es ergibt sich schließlich eine Hierar-chie von „Peer Groups“, die über gewählte „Peer Group Leader“ nur noch die Adreßinformationenbezüglich der Erreichbarkeit der „Peer Groups“ austauschen, anstelle alle Adreßinformationen allerSwitches untereinander auszutauschen. Durch diese komprimierte Darstellung der Erreichbarkeit, inAbhängigkeit vom jeweiligen Adreßprefix, ist es möglich, auch in großen, unstrukturiert vermaschtenATM-Netzen, Wegwahlinformationen auf allen Switches vorzuhalten. Dies ist die Voraussetzung fürdie zweite Aufgabe des PNNI-Protokolls.

4.3.1.2. Switch-übergreifende Verbindungsverwaltung in ATM-Netzen

Die zweite Aufgabe des PNNI-Protokolls ist die Switch-übergreifende Verbindungsverwaltung. InATM-Netzen wird ein sogenanntes „Source Routing“ vorgenommen. Ein ATM-Endgerät, das eineVerbindung aufbauen möchte, signalisiert dies mit dem in Abschnitt 4.2 vorgestellten UNI-Protokoll.Ist der Empfänger an denselben Switch angeschlossen, ist die Wegwahl trivial. Der Switch erkenntdie angesprochene ATM-Adresse aufgrund der ILMI-Registrierung.

Ist der Empfänger nicht am selben Switch angeschlossen, dann muß der lokale Switch beim Eintreffender „SETUP“-Nachricht die Wegwahl für diese Nachricht durch das ATM-Netz durchführen. Dazuwandelt der Swicht die UNI-Signalisierungsnachricht in eine entsprechendePNNI-Signalisierungsnachrichtum, die weitere PNNI-spezifische Informations-Elemente enthält. Im wesentlichen werden in den zu-sätzlichen Informations-Elementen die Adressen der auf dem Weg liegenden Switches eingetragen.Der lokale Switch (an der Quelle des Verbindungsaufbaus, daher „Source Routing“) wählt aufgrundder QoS-Parameter der UNI-Signalisierungsnachricht einen geeigneten Weg zum Endsystem auf-grund der gesammelten PNNI-Informationen (s.o.) und gibt diesenWeg in der PNNI-Signalisierungsnachrichtan, bevor die PNNI-Nachricht an den nächsten Switch weitergeleitet wird.

Die beiden dargestellten Funktionen von PNNI (Verarbeiten von Wegwahl-Informationen und Fest-legen des Weges bei Switch-übergreifender Signalisierung) werden um diverse Mechanismen zumFehlermanagement komplettiert. Dadurch ist es beispielsweise möglich, daß bei Ausfall eines Swit-ches automatisch ein alternativer Weg durch das ATM-Netz von dem Switch gewählt wird, der einePNNI-Signalisierung nicht über den ausgefallenen Switch weiterleiten kann. Dieser Switch korrigiertdann die „Source Routing“-Informationen, so daß ein alternativer Weg durch das ATM-Netz benutztwird und verkündet die Änderungen innerhalb der Topologie über das PNNI-Routing-Protokoll. Dar-auf folgende Signalisierungen anderer Switches können dann selbständig einen neuen Weg unter Be-rücksichtigung der neuen Routing-Informationen wählen.

4.3.2. AngriffsmöglichkeitenDie knappe Darstellung der wesentlichen PNNI-Aufgaben sollte verdeutlichen, daß Angriffe basie-rend auf dem PNNI-Protokoll potentiell Auswirkungen auf das gesamte ATM-Netz haben und nichtnur einzelne Switches oder Endgeräte betreffen. Derartige Angriffe sind somit sehr gefährlich, da siemit einem Schlag großen Schaden (Verfügbarkeitsprobleme, Integritätsprobleme) anrichten.

67


Angriffe basierend auf dem PNNI-Protokoll könnenmit einemmaliziösen Switch erfolgen, der gezieltfalsche Routing-Informationen in das Netz einspielt und somit die Wegwahl erheblich stören kann.Dadurch ergeben sich Verfügbarkeitsprobleme. Bei einer anderen Angriffsart würde dieser Switchdurch Manipulieren der verschiedenen Metriken, die mit PNNI ausgetauscht werden, sich selber alsbesonders günstig für eine Signalisierung in bestimmte Teilnetze (zu bestimmten Peer Groups) dar-stellen. Damit kann ein Angreifer erreichen, daß Verbindungen über seinen Switch aufgebaut werden,für die normalerweise ein anderen Weg gewählt werden würde. Der Angreifer hat somit die Möglich-keit, einen „Man in the Middle (MiM)“-Angriff auf alle über ihn kommunizierenden ATM-Endgerätezu starten. Dies wäre ein Angriff auf die Integrität und auf die Vertraulichkeit.

Die beiden skizzierten Angriffe verdeutlichen, welches Schadenspotential in PNNI-basierten Angrif-fen liegt. Vereinfacht werden diese Angriffe noch dadurch, daß nicht einmal ein richtiger ATM-Switch(hohe Kosten für den Angreifer) benötigt wird, sondern durch den in Abschnitt 4.1.3.1 dargestelltenAngriff auch Endgeräte (eine Größenordnung preiswerter als ATM-Switches) ausreichen, um die An-griffe durchzuführen.

4.3.3. GegenmaßnahmenDa auch beim PNNI keine Authentifikation der Kommunikationspartner untereinander stattfindet,sind die möglichen Gegenmaßnahmen begrenzt.

Um die oben dargestellten Manipulationen der PNNI-Nachrichten durch dritte zu verhindern, sind diefolgenden Voraussetzungen erforderlich:

• Alle Switches sind so gesichert, daß lediglich der Administrator Ports umbelegen kann. Sowohldas Austauschen von Leitungen zu den Endgeräten als auch das Konfigurieren der Switches ist nurdem Administrator (oder gleichermaßen vertrauenswürdigen Personen) möglich.

• Alle Switches, die untereinander PNNI-Informationen austauschen, gehören zur selben Sicherheits-domäne. Das bedeutet, für alle diese Switches gelten einheitliche Sicherheitsrichtlinien (einheitli-che Policy).

Sind diese beiden Voraussetzungen erfüllt, muß der Administrator auf allen Switches diejenigenSchnittstellen überprüfen, an die keine von ihm als vertrauenswürdig eingestuften PNNI-Switchesangeschlossen sind. Auf diesen Schnittstellen muß der für das PNNI vorgesehene PVC (0,18) deakti-viert werden, so daß über diese Schnittstelle keine PNNI-Informationen angenommen werden.

Auch mit dieser Gegenmaßnahme ist wieder ein erheblicher Konfigurationsaufwand verbunden, dain der werksseitig erstellten Konfiguration die PVCs für das PNNI-Protokoll typischerweise auf allenSchnittstellen eingerichtet sind. Endsystembasierte Angriffe (vgl. Abschnitt 4.1.3.1) wären mit derWerkseinstellung von jedem angeschlossenen Endgerät möglich.

Als Gegenmaßnahme sollten somit mindestens die in Abschnitt 4.1.4.1 vorgestellten Konfigurations-schritte durchgeführt werden, um das Signalisierungsprotokoll (UNI oder PNNI) explizit an den Portsvorzugeben. Darüber hinaus kann man auf den Ports an denen Endgeräte angeschlossen sind den PVCfür PNNI folgendermaßen löschen, um ganz sicher zu gehen, daß keine PNNI-Dateneinheiten überdiese Schnittstelle eintreffen können:

68


Beispiel 4-10. Löschen des PNNI-PVCs

Switch(config)# interface atm 0/1/2Switch(config-if)# atm manual-well-known-vc keepSwitch(config-if)# no atm pvc 0 18Switch(config-if)# ^ZSwitch(config)# copy running-config startup-config

Der letzte Befehl muß nur einmal nach dem Konfigurieren aller Ports eingegeben werden, um eineautomatische Neuerstellung des PNNI-PVCs (0,18) nach einem Neustart des Switches zu verhindern.

4.4. Zusammenfassung: Absicherung derStandardprotokolle

Das Sichern der Standard-Protokolle in einem ATM-Netz ist die Grundlage für die weitere Absiche-rung. Es sollten in jedem Fall der ILMI-Dienst derart eingeschränkt werden, daß nur noch Adreß-prefixe von Endgeräten reserviert werden können, die für den ordentlichen Betrieb erforderlich sind.Die Signalisierung sollte ebenfalls entsprechend der geplanten Überdeckung des ATM-Netzes mitVLANS eingeschränkt werden. Diese Sicherungsmöglichkeiten sind nur auf der ATM-Ebene gege-ben und können von keinem der noch zu diskutierenden Protokolle übernommen werden. Da fast alleKonfigurationsschritte auf den beteiligten ATM-Switches vorgenommen werden müssen, sind die-se ATM-Switches selber hochgrachdig empfindlich gegen Angriffe und müssen besonders geschütztwerden.

Fußnoten1. Es gibt auch hier Ausnahmen von dieser allgemeinen Aussage. Kennt ein Angreifer einzelne

besonders sensitive Rechner, lohnt ein Angriff auf diese möglicherweise doch, um großen Schadenanzurichten. Beispielsweise wäre ein erfolgreicher Einbruch auf einem dedizierten Netzwerk-managementsystem sicherlich ebenso schädlich, wie ein Angriff auf die Netzinfrastruktur. Fallsder Angreifer von diesem System aus die administrierbaren Switches gezielt ‘verwirrt’, ist derangerichtete Schaden deutlich größer als der vorausgegangene Einbruch auf dem Netzwerkman-agementsystem.

2. Falls ein Netz ausschließlich über PVCs betrieben werden soll, dann muß die Signalisierung imZuge des PVC-Konfigurierens abgeschaltet werden. Andernfalls können ATM-Endgeräte weiter-hin SVCs zu Zielen aufbauen, für die eigentlich kein PVC vorgesehen ist. Dies ist insbesonderedann brisant, wenn durch diese zusätzlichen SVCs Sicherheitskomponenten umgangen werden!

69


70

Kapitel 5. ‘Classical IP and ARP over ATM’(CLIP)

In diesem Abschnitt werden die Sicherheitsrisiken und möglichen Lösungsansätze beim Einsatz von‘Classical IP and ARP over ATM’ (CLIP) diskutiert. CLIP ist eines von mehreren Protokollen, diezur Übertragung von IP-Dateneinheiten über ATM-Netze eingesetzt werden können. Beim Einsatzvon ATM ist besondere Sorgfalt bei der Integration eines IP-Firewalls gefordert. Es wird daher auchbeschrieben, wie ein IP-Firewall beim Umstieg von einer anderen LAN-Technologie sicher in einATM-Netz integriert werden kann.

CLIP ist im Vergleich zu LANE (vgl. Kapitel 7) und dessen Erweiterung MPOA ein vergleichsweiseeinfaches Protokoll und wurde von der IETF bereits zweimal standardisiert. Die ursprüngliche Ver-sion (vgl. Lau94) und die überarbeitete Version (vgl. LaH98) können parallel zueinander und sogarmiteinander eingesetzt werden. Das Hauptanliegen der beiden RFCs ist die Beschreibung der erforder-lichen IEs für die Signalisierung einer CLIP-Verbindung und die Spezifikation eines ‘ATM-Address-Resolution-Servers’ (ATMARP-Server). Dieser Server übernimmt die Registrierung und Adreßauflö-sung für die Zuordnung von IP-Adressen zu ATM-Adressen.

Im folgenden Abschnitt 5.1 wird die Funktionsweise von CLIP kurz vorgestellt, um anschließendin Abschnitt 5.2 die möglichen Angriffe auf Basis dieses Protokolls und des ATMARP-Dienstes zubeschreiben. Schließlich werden Gegenmaßnahmen zu einigen Angriffen in Abschnitt 5.3 vorgestellt.

5.1. Funktionsweise von CLIPDas Anliegen bei der Spezifikation von CLIP war, einen möglichst einfachen Weg für die Bereitstel-lung eines IP-Dienstes über ATM zu finden. Die IETF sieht ATM als eine von vielen alternativenNetzwerktechnologien für die Übertragung von IP-Dateneinheiten an. Insbesondere bedeutet dies,daß auch beim Einsatz von ATM als Netzwerktechnologie alle Eigenschaften von IP-Netzen erhaltenbleiben sollten.

Eine der Eigenschaften von IP ist gerade die Abstraktion von physikalischen (Netzwerk-)Technologiendurch Bereitstellen eines von diesen Technologien unabhängigen Paketformats und der Festlegungglobal eindeutiger Adressen. Diese Adreßfestlegung ermöglicht eine globale Adressierung von End-geräten und eine Wegwahl (Routing) über diverse Teilnetze hinweg. Die globale Adressierung unddas Routing sind somit inhärente Eigenschaften von IP-Netzen. Wie bereits in den letzten Abschnittendargestellt wurde, ist die globale Adressierung (beispielsweise mit E.164 Adressen) und das Routing(beispielsweise mit PNNI) auch eine inhärente Eigenschaft von ATM-Netzen. Auf welcher Ebenesollen Adressierung und Routing beim Einsatz von IP über ATM stattfinden?

Für die IETF war die Antwort eindeutig. So lange es mehr als eine Netztechnologie gibt, über dieIP betrieben werden kann, muß die Funktionalität selbstverständlich auf der IP-Ebene erbracht wer-

71

Kapitel 5. ‘Classical IP and ARP over ATM’ (CLIP)

den. Gerade dadurch wird die Unabhängigkeit von einer Netzwerktechnologie erreicht. Für den Ein-satz von CLIP bedeutet dies allerdings, daß die entsprechenden Funktionen von ATM nicht erbrachtwerden müssen und das ATM-Netz lediglich als ein schnelles physikalisches Übertragungsmediumangesehen wird.

In der Praxis führt dieses Vorgehen dazu, daß IP-Workstations aus verschiedenen IP-Subnetzen injedem Fall über einen Vermittlungsrechner (Router) kommunizieren müssen, auch dann, wenn ei-ne direkte ATM-Verbindung zwischen diesen Rechnern möglich wäre. In den oben genannten RFCs(Lau94, LaH98) wird diese Situation durch den Begriff logisches IP-Subnetz (logical IP subnet, LIS)beschrieben: Mehrere IP-Subnetze (durch Angabe von Netzadresse und Netzwerkmaske bestimmt)sind in einem ATM-Netz nicht mehr physikalisch durch einen Router voneinander getrennt, sondernsind Teil desselben ATM-Netzes. Ein Router kann in einem solchen CLIP-Netz beispielsweise übereine einzige ATM-Schnittstelle (’single leg router’) ein, mehrere oder alle LIS verbinden. Das Wei-terleiten von Dateneinheiten geschieht immer dann über diesen Router, wenn die kommunizierendenEndsysteme nicht im selben LIS sind. Andererseits könnten die selben Rechner für andere (nicht-IP)Kommunikationsbeziehungen eine direkte ATM-Verbindung etablieren, da sie am selben physikali-schen ATM-Netz angeschlossen sind.

In Abbildung 5-1 ist ein IP-Netz bestehend aus den vier IP-Subnetzen 192.168.13.0, 192.168.14.0,192.168.15.0 und 192.168.16.0 dargestellt. Die zwei IP-Netze 192.168.15.0 und 192.168.16.0 sindbeide Teil desselben ATM-Netzes und somit zwei LIS. Dies führt dazu, daß die Workstations mitden IP-Adressen 192.168.16.1 und 192.168.16.2 direkt miteinander kommunizieren dürfen, mit derWorkstation 192.168.15.1 jedoch nur indirekt über den Router, obwohl eine direkte ATM-Verbindungmöglich wäre.

Abbildung 5-1. IP-Netz mit mehreren Subnetzen

72


Ethernet

Ring-Netz

Token-

ATM-Netz

Router

192.168.16.1

192.168.16.2

192.168.15.1

192.168.14.1 192.168.13.1

192.168.14.0/24192.168.13.0/24

192.168.15.0/24

192.168.16.0/24

In Abbildung 5-2 ist das ATM-Netz noch einmal verfeinert dargestellt. Die eingezeichneten Linienverdeutlichen die nach RFC1577 und RFC2225 erlaubten Kommunikationsbeziehungen (intra-LISohne Router, inter-LIS über den Router).

Abbildung 5-2. ATM-Netz mit zwei LIS

73


ATM-Netz

Router

192.168.16.1

192.168.16.2

intra-LIS Kommunikation

inter-LIS Kommunikation

192.168.15.1

Möchte man IP-Dateneinheiten über ein ATM-Netz versenden, muß für eine interoperable Lösungvorher festgelegt werden, wie:

• IP-Dateneinheiten in AAL-Rahmen eingebettet werden,

• Verbindungen zwischen IP-Stationen in ATM-Netzen verwaltet (auf- und abgebaut) werden sollen,

• die in ‘shared medium’-LANs durch „broadcasts“ einfach erreichbare Adreßauflösung in einemleitungsvermittelnden ATM-Netz erfolgen kann.

Genau diese Festlegungen erfolgen in den oben genannten RFCs. In dem folgenden Unterabschnittwird kurz die Einbettung von IP-Dateneinheiten in AAL-Rahmen dargestellt. Danach erfolgt die Dis-kussion der beiden möglichen Betriebsmodi für CLIP. CLIP kann sowohl über PVCs als auch überSVCs betrieben werden. Anschließend folgt die Beschreibung des ATMARP-Dienstes, der für dieangesprochene Andreßauflösung beim Betrieb von CLIP über SVCs unerläßlich ist.

74


5.1.1. Format der Dateneinheiten bei CLIPIn Abbildung 5-3 ist die Einbettung von Dateneinheiten der TCP/IP-Protokollfamilie in AAL-5 Rah-men dargestellt. Die Werte für den SNAP-Header sind in den beiden oben genannten RFCs festgelegt.Sie sind für beide Versionen identisch, so daß auch ein gemischter Betrieb zwischen RFC1577- undRFC2225-kompatiblen Installationen möglich ist. Die maximale IP-Datagrammgröße von 9180 Byteist in Anlehnung an Pis91 festgelegt und als Vorgabewert anzusehen. Beim Betrieb über SVCs kanndiese Größe für jeden SVC individuell ausgehandelt werden und ist dann nur durch die maximaleGröße eines AAL-5 Rahmens von 65535 Byte beschränkt.

Abbildung 5-3. CLIP Protokollstapel

48 Byte

SNAP-Header

20 Byte IP-Header

Anwendungsschicht

schichtATM- 5 Byte Zell Kopf Zelle 192Zelle 1

9140 Byte Anwendungsdaten bei TCP

9152 Byte Anwendungsdaten bei UDP

MAX-MTU= 9180 Byte

Netzwerkschicht

Transportschicht8 Byte

UDP-Header

20 ByteTCP-Header 9140 Byte Anwendungsdaten bei TCP

9152 Byte Anwendungsdaten bei UDP

schichtATM-Adaptions- 8 Byte

8-Byte AAL-5 Trailer20 Byte PAD

53 Byte

��

��

��

��

��

��

Im Vergleich zur MTU-Größe von 1500 Byte bei Verwendung von (Fast)Ethernet ist bereits dieStandard-MTU von CLIP mit 9180 Byte mehr als sechs mal so groß. Diese deutlich größeren Da-tenmengen, die pro PDU versendet werden können, reduzieren den Verarbeitungsaufwand in denEndsystemen erheblich. Dies ist eine wesentliche Eigenschaft beim Einsatz im Hochgeschwindig-keitsbereich. Das Format für Anfragen und Antworten an den ATMARP-Server wird weiter unten

75


beschrieben.

5.1.2. Verbindungsmanagement für CLIPIm einfachsten Fall kann man CLIP über PVCs (vgl. Abschnitt 2.1.2) betreiben. Hierfür ist es erfor-derlich, die einzelnen Workstations im Netz durch manuelle Konfiguration der ATM-Switches unter-einander zu verbinden. Sollen beispielsweise (n) Endgeräte vollständig über PVCs verbundenwerden,so daß jedes beliebige Endgerät mit jedem beliebigen anderen Endgerät kommunizieren kann, dannwären hierfür (n * (n-1))/2 PVCs zu konfigurieren1. Zusätzlich müßten auf allen (n) Rechnern die(n-1) IP-Adressen der anderen Rechner manuell mit den konfigurierten VCIs verknüpft werden. Füralle nicht trivialen ATM-Netze ist dies sicherlich ein nicht akzeptabler Aufwand. Sollen dennoch aus-schließlich PVCs verwendet werden, beispielsweise wenn das ATM-Netz lediglich als Backbone füreine Router-Kopplung eingesetzt werden soll, dann sollte in jedem Fall die Signalisierung auf denjeweiligen Schnittstellen der ATM-Switches abgeschaltet werden (vgl. Beispiel 4-8), damit Endge-räte keine zusätzlichen Verbindungen zur Umgehung der durch die Router vorgegebenen Topologieschalten können.

Bei größeren Netzen ist die Verwendung von SVCs wesentlich praktikabler. Hierbei wird von einemRechner bei Bedarf dynamisch eine Verbindung zum jeweiligen Endsystem geschaltet. Die RFCsspezifizieren für diesen Betriebsmodus sehr genau, welche IEs bei der Signalisierung vorhanden seinsollen und welche QoS-Merkmale für einen CLIP-SVC angefordert werden können. Nach PLM95sind die folgenden IEs beim SETUP anzugeben:

• AAL Parameters

Hiermit wird der AAL-Typ auf AAL-5 festgelegt und die AAL-SDU-Größe kann festgelegt wer-den. Soll die Standard-IP-MTUvon 9180Byte verwendetwerden, dann ist hier sowohl für fwd_max_sdu_sizeals auch für bkw_max_sdu_size eine Größe von 9188Byte einzutragen, da neben der IP-Dateneinheitnoch weitere acht Byte für den SNAP-Kopf reserviert werden müssen (vgl. Abbildung 5-3)

• ATM Traffic Descriptor

Da IP normalerweise einen ‘best effort’-Dienst anbietet, ist es eigentlich nicht erforderlich, fürCLIP-SVCs eine konstante oder variable Übertragungsgeschwindigkeit zu reservieren. Dies istzwar in Kombination mit weiteren IEs (Broadband Bearer Capability IE und QoS Parameter IE)durchaus möglich, aber nur in wenigen Szenarien sinnvoll. Typischerweise wird der ‘best effort’-Dienst durch ein entsprechendes Flag in diesem IE ausgewählt.

• Broadband Bearer Capability

Dieses IE muß in Abhängigkeit von demATMTrafficDescriptor und den gewähltenQoS-Merkmalengesetzt werden. CLIP-Implementierungen müssen mindestens die beiden ‘bearer_classes’ BCOC-X und BCOC-C unterstützen. Darüber hinaus wird hier der Typ des SVCs auf ‘Punkt-zu-Punkt’festgelegt, da z.Z. keine Punkt-zu-Mehrpunkt-Verbindungen von CLIP unterstützt werden.

76


• Broadband Low Layer Information

Mit diesem IE wird das Protokoll ausgewählt, für das letztendlich die AAL-5-SDUs bestimmtsind. Wie bereits oben dargestellt, sieht CLIP das ATM-Netz lediglich als ein schnelles Schicht-2Medium an. Daher wird in diesem IE in der ‘layer_2_id’ die ISO-Identifikation für ein ‘LogicalLink Control (LLC)’ Endpunkt eingetragen. Dies bedeutet, daß alle AAL-5-SDUs vom Empfän-ger entsprechend der eingetragenen SNAP-Kopfeinträge an höher liegende Protokolle weiterge-reicht werden. Es handelt sich hierbei also um eine Multiplexinformation, die die Übertragung vonverschiedenen Pakettypen auch unterschiedlicher Protokolle über dieselbe Verbindung ermöglicht.Dieses Vorgehen ist auch im Zusammenhang mit CLIP sinnvoll, da sich Endgeräte so unterein-ander über denselben SVC sowohl IP-Dateneinheiten als auch InATMARP-Dateneinheiten (s.u.)zusenden können.

Wird in diesem IE zusätzlich als nächst höheres Protokoll IP angegeben (layer_3-Bezeichner be-kommt den Wert für ‘ISO/IEC TR 9577 IPI’ zugewiesen), dann muß in den AAL-5-SDUs dennochim SNAP-Kopf die Protokollbezeichnung eingetragen werden.

• QoS Parameter

Diese IE wird in Abhängigkeit von dem ‘Traffic Class IE’ gesetzt (s.o.). Für den Fall, daß der ‘besteffort’-Dienst ausgewählt wurde, muß hier die QoS-Klasse 0 eingetragen werden.

• Called Party Number

Hier ist die ATM-Adresse des Empfängers einzutragen. Die Zuordnung von IP-Adressen zu ATM-Adressen wird weiter unten beschrieben.

• Calling Party Number

Die ATM-Adresse des Absenders muß hier eingetragen werden. Diese Adresse ist für das Routingeigentlich nicht erforderlich, sie muß aber beim Signalisieren eines CLIP-SVCs zusätzlich angege-ben werden.

Weitere Details zur Signalisierung von CLIP-SVCs sind in PLM95 und in Mah98 angegeben.

5.1.3. ATM- zu IP-AdreßauflösungEine wesentliche Funktion jedes IP-basierten Netzes ist die Adreßauflösung. IP abstrahiert von dendarunterliegendenNetzwerkprotokollen, muß aber gleichzeitig diese Protokolle einsetzen, um entwe-der direkt den Empfänger im eigenen Subnetz anzusprechen oder indirekt über einen Vermittlungs-rechner (Router). Daher ist ein Mechanismus erforderlich, der zu der IP-Adresse des Empfängersoder des nächsten Routers eine Netzwerkadresse liefert, so daß die IP-Dateneinheit im jeweiligen

77


Netzwerk-Rahmen versendet werden kann. In den ‘shared medium’-LANs wird hierfür in der Re-gel ein auf ‘broadcasts’ basierender Mechanismus verwendet: Eine Anfrage mit der IP-Adresse desEmpfängers wird an alle Teilnehmer im Netz gesendet. Der Empfänger erkennt, daß seine IP-Adresseangefragt wurde und beantwortet die Anfragemit einer Dateneinheit, die seine eigene Netzwerkadres-se der IP-Adresse zuordnet (vgl. Plu82).

Da ATM-Netze dedizierte Verbindungen zwischen einem Sender und einem oder mehreren Empfän-gern vermitteln, es also keinen ‘broadcast’-Mechanismus gibt, muß die Adreßauflösung durch einenzentralen Dienst erbracht werden. Die Spezifikation dieses Dienstes ist der wesentliche Bestandteilder RFCs Lau94 und LaH98.

Auf jedem Endsystem (Workstation, Router) in einemLISmuß die ATM-Adresse eines ‘ATM-Address-Resolution’ (ATMARP) Servers konfiguriert werden. Dieser ATMARP-Server erledigt zwei Aufga-ben:

1. Speichern der Zuordnungen von ATM-Adressen zu IP-Adressen

Jedes Endsystem, das mit SVCs mit anderen LIS-Endsystemen kommunizieren will, kontak-tiert zuerst den ATMARP-Server und registriert hier die Zuordnung der eigenen ATM-Adressezur eigenen IP-Adresse. Es können auch mehrere dieser Zuordnungen gespeichert werden, bei-spielsweise wenn das Endsystem über mehrere IP-Adressen verfügt. Die Endsysteme kennen dieeigene ATM-Adresse entweder durch das ILMI-Protokoll (vgl. Abschnitt 4.1) oder die eigeneATM-Adresse wurde genau wie die ATMARP-Server-Adresse und die eigene IP-Adresse vomAdministrator festgelegt.

2. Antworten auf Anfragen nach anderen ATM-Adressen

Will ein Endsystem eine virtuelle Verbindung zu einem anderen LIS-Teilnehmer aufbauen, dannkann über die im ersten Schritt zum ATMARP-Server aufgebaute Verbindung eine ATMARP-Anfrage gesendet werden. Da sich alle zur Zeit im LIS befindlichen Endsysteme im ersten Schrittmit ihren ATM-Adressen beim Server registriert haben, kann dieser über die IP-Adresse in derAnfrage die richtige ATM-Adresse heraussuchen und an den Anfragenden als Antwort zurück-senden. Der Anfragende benutzt die ATM-Adresse in der Antwort, um über den normalen CLIP-Verbindungsaufbau einen direkten SVC zum anderen LIS-Teilnehmer aufzubauen.

In Erweiterung zu Plu82 sendet der ATMARP-Server auch negative Antworten. Falls also nacheiner IP-Adresse gefragt wird, für die (noch) keine Registrierung vorliegt, sendet der ATMARP-Server ein negative Antwort (ein sogenanntesARP_NAK) zurück an den Anfragenden2.

5.1.3.1. Registrierung eines Clients (RFC2225)

In Abbildung 5-4 ist die erfolgreiche Anmeldung eines CLIP-Clients nach RFC2225 dargestellt. Nacheinem ATM-Verbindungsaufbau, bei dem die oben dargestellten IEs zu verwenden sind, registriert

78


sich ein Client durch Anfragen seiner eigenen Adresse.

Der Client generiert hierzu ein ATMARP_Request-Paket, das als Quell- und Empfängeradresse dieeigene IP-Adresse enthält. Die Quell-ATM-Adresse entspricht der eigenen ATM-Adresse und alsTarget-ATM-Adresse setzt der Client die ATM-Adresse des Servers ein. Der Server prüft, ob er fürdie angegebene IP-Zieladresse (targetIP) bereits eine gültige ATM-Adresse gespeichert hat. Ist diesder Fall, sendet er in der Antwort diese Adreßinformationen in den Feldern für Quell-IP-Adresseund Quell-ATM-Adresse zurück. Der Client würde durch einen Vergleich mit seiner eigenen ATM-Adresse feststellen können, daß die IP-Adresse bereits vergeben ist. Dies wäre somit eine erfolgloseRegistrierung.

In Abbildung 5-4 sendet der Server allerdings in den Quell-Adreßfelderndie angefragten Ziel-Adreßinformationenzurück. Diese entsprechen den eigenen Angaben des Clients. Durch die Übereinstimmung der Adre-ßinformationen weiß der Client, daß er mit der angegebenen IP-Adresse und seiner ATM-Adressebeim Server registriert ist.

79


Abbildung 5-4. CLIP-Client registriert sich beim Server

clientreg2225

SETUP

CONNECT

CONNECT_ACK

ATMARP_Request (sourceIP= self , sourceATM= self ,targetIP= self , targetATM=server)

Server erstellt einen neuen Tabelleneintrag:(sourceIP, sourceATM,VCI, localtime)

Client versucht sichzu registrieren,indem er die eigeneAdresse erfragt,also sowohl die SourceIP- als auch die TargetIP-Adressemit der eigenen IP-Adresse fuellt.

ATMARP_Reply (....,sourceIP=targetIP,sourceATM=targetATM)

Antwort enthaelt einesourceIP- und einesourceATM-Adresse,die mit den eigenen Adressen uebereinstimmenund in den target-Feldernwiederholt werden.

Client

ARP_CLIENT

UNREGISTRIERT

REGISTRIERT

Server

2225_SERVER

localtime+20Minuten

In Abbildung 5-4 ist auch dargestellt, daß der ATMARP-Server einen Zeitgeber (Timer) startet, dernach 20 Minuten abläuft. Laut den RFCs ist dies die maximale Gültigkeitsdauer eines registriertenEintrags. Nach diesen 20 Minuten verwirft der Server den Eintrag, es sei denn der Client hat innerhalbder Zeit seinen Eintrag aufgefrischt. Dies kann der Client entweder durch Anfragen nach Adressenerreichen (s.u.), oder durch wiederholtes Senden einer Anfrage nach seinen eigenen Adreßinforma-tionen (s.o.). Laut LaH98 sollte ein Client mindestens alle 15 Minuten einmal seinen Eintrag beimServer auffrischen.

5.1.3.2. Anfrage eines Clients (RFC2225)

80


Nach der Registrierung kann der Client ATM-Adressen erfragen, indem er weitereATMARP_Requestsan den Server sendet. Die Quell-Adreßinformationen beinhalten immer die eigene ATM- und IP-Adresse. Die Ziel-Adreßinformation enthält die bekannte IP-Adresse, zu der die ATM-Adresse ge-sucht.

Der Server antwortet mit der gesuchten Information, indem er die Quell-Adreßinformationen desanfragendenClients in die Ziel-Adreßinformationenkopiert und in den Quell-AdreßinformationendiegefundeneZuordnung von IP- zu ATM-Adresse aus seinemARP-Cache einträgt. Diese Informationenwerden als ATMARP_Reply-Paket an den Client zurückgesendet.

Fragt ein Client nach einer dem Server unbekannten Adresse, so antwortet dieser mit einem AT-MARP_NAK. Der Client kann keine ATM-Verbindung zu dem gesuchten Endsystem aufbauen. InAbbildung 5-5 sind die beiden diskutierten Fälle dargestellt. Der registrierte Client fragt nach einerIP-Adresse und erhält die Antwort. Eine zweite Anfrage kann vom Server nicht beantwortet werden,so daß dieser mit einem ATMARP_NAK-Paket antwortet.

81


Abbildung 5-5. CLIP-Client befragt den Server

clientquery2225

ATMARP_Request (sourceIP=192.168.16.1,

sourceATM="ATM-Adresse des Clients",targetIP=192.168.16.2, targetATM="server")

ATMARP_Reply (sourceIP=192.168.16.2,

sourceATM="ATM-Adresse von IP-Host 192.168.16.2",targetIP=192.168.16.1, targetATM="ATM-Adresse des Clients")


sourceATM="ATM-Adresse des Clients",targetIP=192.168.16.250, targetATM="server")

Timer wird nicht aktua-lisiert, wenn die letzteAktualisierung vor weniger als 10 MinutenerfolgteATMARP_NAK

(sourceIP=192.168.16.1,sourceATM="ATM-Adresse des Clients",

targetIP=192.168.16.250, targetATM="server")

Client

ARP_CLIENT

REGISTRIERTals

192.168.16.1

Server

2225_SERVER

Timer fuer 192.168.16.1zuruecksetzen...

localtime+20 Minuten

Timer wieder auf20 Minuten ein-stellen.

Zu beachten ist, daß bei der negativenAntwort die Quell- und Ziel-AdreßinformationenvomATMARP-Server nicht ausgetauscht werden. Der Pakettyp wird auf ATMARP_NAK gesetzt, das Paket wirddavon abgesehen unverändert an den Client zurückgesendet.

Der Server nutzt Anfragen von Clients darüber hinaus, um die Tabelleneinträge zu aktualisieren.Wie in Abbildung 5-5 bereits angedeutet, setzt der ATMARP-Server den jeweiligen Timer für einenanfragenden Client zurück, sofern mindestens 10 Minuten seit der letzten Aktualisierung vergangensind. Damit bleibt der Client für weitere 20 Minuten beim ATMARP-Server registriert.

82


5.2. AngriffsmöglichkeitenDie größte Gefahrenstelle in einem CLIP-Netz ist der ATMARP-Server. Aus der Darstellung im letz-ten Kapitel sollte ersichtlich sein, daß dieser Dienst essentiell für den Betrieb von CLIP in einemATM-Netz ist3. Ein weiteres Problem entsteht bei der Integration von IP-Firewall-Komponenten.Hier-bei muß durch sorgfältige Planung und Konfiguration des CLIP-Netzes verhindert werden, daß derFirewall umgangen werden kann.

Die Angriffe auf den ATMARP-Server nutzen Lücken in der Spezifikation der RFCs aus. Die RF-Cs beschreiben, daß Sicherheitsaspekte in ATM-Netzen noch nicht vollständig verstanden sind unddaher noch nicht Teil der jeweiligen Spezifikationen sind. Es erfolgt daher die Beschreibung deserwünschten Verhaltens4 sowohl von Client als auch von Server, ohne auf die bereits bekannten Si-cherheitsmängel einzugehen.

Bei der Integration einer Firewallkomponente in ein CLIP-Netz besteht die Gefahr, daß der Fire-wall durch das Aufbauen von Verbindungen umgangen wird. Diese Möglichkeit besteht in allen lei-tungsvermittelnden Netzen, die über eine komplexe Topologie mit mehr als einem Weg zwischenden Endsystemen verfügen. Diese Gefahr ist bei CLIP besonders groß, da beispielsweise Paketfilterauf Routern immer dann umgangen werden können, wenn die Router für inter-LIS-Kommunikationzuständig sind.

5.2.1. Angriffe auf den ATMARP-ServerDa der ATMARP-Server durch die zentrale Rolle für die Adreßauflösung im CLIP-Netz unersetzlichist, lohnen sich Angriffe auf diesen Dienst besonders zum Auslösen von DoS. DoS-Angriffe aufden ATMARP-Server beruhen auf einer massiven Beanspruchung dieses Dienstes auf verschiedenenEbenen:

• Ausführen der generischen Angriffe basierend auf der Signalisierung

Es können vom Angreifer viele ATM-Verbindungen zum Server aufgebaut werden. Diese Art desAngriffes entspricht im wesentlichen dem in Abschnitt 4.2.2.3 beschriebenen Angriff. Ziel ist eshier jedoch, durch das massive Signalisieren die Adreßauflösung für andere Teilnehmer zu erschwe-ren oder gar zu verhindern.Bei ATMARP-Server, die auf Endsystemen installiert sind, können auchdie anderen dort beschriebenen Reservierungsangriffe zum Erfolg führen.

• Ausführen von spezialisierten Angriffen basierend auf dem ATMARP-Protokoll

Ein Angreifer hat auch dieMöglichkeit, einen ATMARP-Server direkt unter Ausnutzung des ATMARP-Protokolls anzugreifen. Hierbei kann er versuchen, diverse ATM/IP-Adreßbindungen zu reservie-ren, um die Verwaltung dieser Informationen auf dem ATMARP-Server zu verlangsamen. Er kannaber auch versuchen, zuvor gelernte Adreßzuordnungen zu übernehmen. Ein Client, der sich an-schließend mit seiner IP-Adresse (wieder) registrieren möchte, kann die Adreßzuordnung nichteintragen lassen, da sie schon vom Angreifer reserviert wurde. Diese zweite Art des Angriffes istbesonders gefährlich, da sie als Vorbereitung für einen ‘Man-in-the-Middle’-Angriff dienen kann.

83


Dieser Angriff kann immer dann erfogreich sein, wenn sich Clients nur bei Bedarf beim ATMARP-Server anmelden. In der Zwischenzeit stehen ihre Adressen für die Reservierung durch einen An-greifer zur Verfügung.

In Abbildung 5-6 ist dargestellt, wie sich ein Angreifer als Client in einem LIS ausgibt. Der Client mitder IP-Adresse 192.168.16.2 kann sich nicht beim Server registrieren, da der Angreifer bereits die IP-Adresse eingetragen hat. Zusätzlich verdeutlicht das Beispiel, daß der Angreifer die Möglichkeit füreinen ‘Man-in-the-Middle’-Angriff hat, wenn ein Dritter nach der von ihm reservierten Adresse fragt.Darüber hinaus ist eine Rückverfolgung aufgrund der ATM-Adresse gegebenenfalls sehr aufwendig,falls der Angreifer eine zusätzliche Adresse an der UNI-Schnittstelle frei gewählt hat. Ist die Adressegeschickt gewählt, funktioniert die Verbindungseröffnung zum Angreifer hin, ohne daß aufgrund derAdresse direkt auf die Lokalität des Angreifers geschlossen werden kann.

Möchte der Angreifer lediglich einen DoS gegen einige Clients auslösen, kann er wie oben vorgehenund versuchen, deren IP-Adresse zu reservieren. Darüber hinaus kann sich der Angreifer weiter tar-nen, indem er für die Verbindung zum ATMARP-Server die ATM-Absenderadresse so fälscht, daß esden Anschein hat, die Verbindung wäre von einem legitimen Client eröffnet worden. Ein Auffindendes Angreifers ist dann noch schwieriger. Verbindungen können jedoch nicht zum Angreifer aufge-baut werden, da ein Anwählen der vom Angreifer ‘gespooften’ Adresse zum jeweiligen Client führt,dessen ATM-Adresse der Angreifer verwendet hat.

84


Abbildung 5-6. Angreifer reserviert IP-Adresse als Vorbereitung für ‘Man-in-the-Middle’-Angriff

arpresattack2225


sourceATM= self ,targetIP=192.168.16.2,targetATM="server")

ATMARP_Reply (sourceIP=192.168.16.2,

sourceATM="eine Adresse des Angreifers",...) Adresse ist bereits

vergeben, also die aktuelle Zuordnung zuruecksenden!

ATMARP_Request ()

ATMARP_Reply () Registrierungdes Clients

ATMARP_Reques (192.168.16.2) Gib mir die ATM-Adresse von 192.168.16.2

ATMARP_Reply ("eine Adresse desAngreifers")

SETUP(Called_Party="eine Adresse des Angreifers")

ATMARP_Request (sourceIP=192.168.16.2, sourceATM="eine Adresse des Angreifers",

targetIP=192.168.16.2, targetATM="server")

ATMARP_Reply (...)

Client 192.168.16.2

ARP_CLIENT

UNREGISTRIERT

UNREGISTRIERT

Client 192.168.16.1

ARP_CLIENT

REGISTRIERT

Server

2225_SERVER

Angreifer

ARP_CLIENT

UNREGISTRIERT

REGISTRIERT

PotentiellerMan- in-the-

Middle

85


Die oben dargestellten Angriffe sind möglich, weil keine Authentisierung bei der Verbindungser-öffnung stattfindet. Darüber hinaus sind viele heute im Einsatz befindlichen ATMARP-Server nichtrestriktiv genug eingestellt. Gegen viele DoS-Angriffe würde schon eine Plausibilitätskontrolle beider Reservierung genügen. Die gängige Praxis, den ATMARP-Server auf einem Switch zu betrei-ben, verhindert aber meist einfache Plausibilitätskontrollen, da entweder dieselbe ATMARP-Instanzfür mehrere LIS verwendet wird und somit der Switch nicht unbedingt unter der Verwaltung des Si-cherheitsadministrators steht, oder die Switch-Software gar nicht in der Lage ist, eine restriktivereHandhabung bei der Adreßregistrierung und -auflösung zu unterstützen.

Ein weiteres Problem der Protokollspezifikation besteht darin, daß der essentielle ATMARP-Dienstnicht-redundant ausgelegt ist. Gelingt ein DoS-Angriff, so daß die LIS-Clients keine Adressen mehrauflösen können, ist die gesamte CLIP-Kommunikation im LIS in Mitleidenschaft gezogen: Die Cli-ents können zu keinem redundant vorhandenen Server ausweichen.

5.2.2. Angriffe auf den LIS-ClientEin Angreifer kann wie oben dargestellt einen ‘Man-in-the-Middle’-Angriff auf einen LIS-Client vor-bereiten, indem er eine oder mehrere Adressen von LIS-Clients reserviert. Wann immer ein andererClient an eine der vom Angreifer reservierten IP-Adressen Dateneinheiten senden will, kontaktiert erden ARP-Server und wird die ATM-Adresse des Angreifers erhalten. Wie bereits in BeE98 darge-stellt wurde, helfen in diesem Fall auch keine einfachen Gegenmaßnahmen. ident-Anfragen mit demauth-Protokoll können ebenso einfach gefälscht werden wie eine ATM- oder eine IP-Adresse. Dar-über hinaus ist diese Fälschung sehr schwer zu enttarnen, da die Verbindungen zwischen Angreiferund Server, als auch zwischen Angreifer und den Clients immer exklusiv sind. Das Versenden vongefälschten Informationen fällt auf den anderen Stationen im LIS daher nicht auf. Außerdem errei-chen alle Antworten des Angegriffenen über die virtuelle Verbindung den Angreifer, so daß dieser beiVerwendung von TCP noch nicht einmal die Sequenznummern erraten muß, sondern direkt mit demAngegriffenen kommuniziert.5.

In Abbildung 5-7 ist ein gezielter Angriff auf einen LIS-Client dargestellt. Der Angreifer möchteerreichen, daß der Client seine Dateneinheiten an ihn sendet und nicht direkt an den Datenbank-Server. Dazu geht der Angreifer folgendermaßen vor:

1. Erfragen der ATM-Adresse des anzugreifenden Clients beim ATMARP-Server

Der Angreifer will diesen Angriff aktiv führen, beispielsweise weil der Client wie hier schonregistriert ist und sich der Angreifer daher nicht selber als Client ausgeben kann, oder weil derAngreifer gerade Informationen vom Client manipulieren möchte. Daher braucht er die Adreßin-formationen, um selber eine Verbindung zum Client aufbauen zu können.

2. Erfragen der ATM-Adresse des Datenbank-Servers beim ATMARP-Server

86


Der Angreifer muß für einen ‘Man-in-the-Middle’-Angriff später eine eigene Verbindung zumServer herstellen können. Dafür sind diese Adreßinformationen erforderlich.

3. Aufbauen einer CLIP-Verbindung zum Client.

Als ATM-Absenderadresse ‘spooft’ der Angreifer die Adresse des Datenbank-Servers.Auf InATMARP-Anfragen, die der Client über die Verbindung an den Angreifer sendet, antwortet der Angreifermit der IP-Adresse des Datenbank-Servers, die wie oben dargestellt vom ATMARP-Server ange-fragt wurde. Anschließend kann der Angreifer beispielsweise mit einem ICMP-Echo_Requestprüfen, ob der Client mit einem ICMP-Echo_Reply antwortet. Ist dies der Fall, dann hat derClient zuvor keine Verbindung zum Datenbank-Server aufgebaut bzw. er wird die vom Angreiferaufgebaute Verbindung als Verbindung zum Datenbank-Server ansehen.

4. Client will mit dem Datenbank-Server kommunizieren

Will nun jemand vom Client aus auf den Datenbank-Server zugreifen, gibt es zwei Möglich-keiten, wie sich die Client-CLIP-Software verhalten kann. Im einfachsten Fall verläßt sich dieSoftware auf den ARP-Cache-Eintrag und benutzt unmittelbar die Verbindung, die bereits zumvermeintlichen Server besteht, sendet also direkt an den Angreifer. Die zweite Möglichkeit ist,daß die Software zuvor noch eine ATMARP-Anfrage an den ATMARP-Server stellt, um dieAdreßinformationen noch einmal zu validieren. In diesem Fall sendet der ATMARP-Server dieAdreßinformationen des Datenbank-Servers zurück. Auch in diesem Fall wird der Client darauf-hin die bereits etablierte Verbindung zum Angreifer benutzen, denn die Adreßmerkmale stimmenmit den Adreßinformationen vom ATMARP-Server überein.

Dies hat der Angreifer bereits in den zurückliegenden Schritten vorbereitet, da er mit der ATM-Adresse des Datenbank-Servers signalisiert hat und auf die InATMARP-Anfragen des Clientsmit der IP-Adresse des Datenbank-Servers geantwortet hat.

5. ‘Man-in-the-Middle’ durch den Angreifer

Der Angreifer empfängt Dateneinheiten vomClient über den SVC. Aufgrund der IP-Adreßinformationenerkennt er das eigentliche Ziel, nämlich den Datenbank-Server. Der Angreifer kann nun mit denin 2 und 1 gesammelten Informationen eine eigene Verbindung zum Datenbank-Server aufbauenund sich dort als Client ausgeben. Danach kann er die Informationen des Clients an den DB-Server und vice versa nach Belieben manipulieren.

Die Abbildung 5-7 verdeutlicht die Schritte noch einmal graphisch. In den eingezeichneten Nach-richten sind nur noch die wesentlichen Informationen eingetragen. Zu beachten ist auch, daß dieNachrichten auf verschiedenen Protokollebenen versendet werden. Die Verbindungsverwaltung (SE-TUP, CONNECT, CONNECT_ACK) findet auf der ATM-Ebene statt (vgl. Abschnitt 4.2). Der An-greifer fälscht hier die ATM-Absenderadressen (Calling-Party-IEs). Die ICMP-Nachrichten werdenin IP-Datagrammen versendet. Auch in diesen Datagrammen werden vom Angreifer die Adressengefälscht. Zum Client sendet er IP-Dateneinheiten mit der Absenderadresse des DB-Servers (hier

87


192.166.16.222). Zum DB-Server sendet er IP-Dateneinheiten mit der Absenderadresse des Clients(hier 192.168.16.1). Eventuell stellen Client und Server die angedeuteten InATMARP-Anfragen.Auch in diesem Fall sendet der Angreifer die entsprechend gefälschten Adreßinformationen in denInATMARP-Antworten zurück. In diesem Fall durch Fälschen der RFC2225-ARP-PDUs.

Abbildung 5-7. Aktiver ‘Man-in-the-Middle’-Angriff

lisclientattack2225

SETUP (Calling-Party-IE="ATM-Adresse des DB-Servers")

CONNECT ()

CONNECT_ACK()

InATMARP_Request()

Wer bist du ?

InATMARP_Reply(192.168.16.222)Client merktsich vermeint-lichen SVC zumDB-Server

ICMP-Echo_Request("ping")

ICMP-Echo-Reply("pong")

ODBC-Query("Auth=bla, Passwd=fasel, Action=update..")

Anfrage uebervermeintlichenSVC zum DB-Server

manipulierte ODBC_Reply()

Antwort uebervermeintlichenSVC vom DB-Server

ATMARP_Request ("Client")

ATMARP_Reply ("IP- und ATM-Adresse des Clients")

ATMARP_Request ("DB-Server")

ATMARP_Reply ("IP- und ATM- Adresse des DB-Servers")

SETUP ()

Verbindungsaufbau zum Server, spoofen der ATM-Adresse, Server glaubt anVerbindung zum Client

CONNECT ()

CONNECT_ACK()

manipulierte-ODBC-Query()

ODBC_Reply()

Client

ARP_CLIENT

REGISTRIERTals

192.168.16.1

Server

2225_SERVER

Angreifer

ARP_CLIENT

SPOOFINGERFOLGREICH

DB-Server

ARP_CLIENT

REGISTRIERTals

192.168.16.222

88


Der Angriff sieht in dieser Darstellung möglicherweise sehr kompliziert aus. Der Programmierauf-wand zum Durchführen des Angriffes mit normalen Workstations ist jedoch gering. Die Entwicklungvon geeigneten ‘Tools’ durch ‘Cracker’ zur Automatisierung eines solchen Angriffs sind bei weiterzunehmender Verbreitung von ATM daher nur eine Frage der Zeit. Wie bei vielen anderen „Cracker-Tools“ braucht der Angreifer die eben dargestellten Abläufe noch nicht einmal zu verstehen, um dieseoder ähnliche Angriffe durchzuführen.

5.2.3. Angriffe durch Umgehen von IP-FirewallsDurch die oben dargestellte Diskussion ist deutlich geworden, daß Spoofing-Angriffe in ATM-Netzenweitaus einfacher sind als beispielsweise in Ethernet-basierten IP-Netzen. Gegen Angriffe, die auffalschen Adreßinformationen in den vom Angreifer versendeten Paketen beruhen, wurden in eini-gen Szenarien bereits erfolgreich Firewalls eingesetzt, um diese Adreßfälschung zu erkennen. EineAdreßfälschung ist durch einen Firewall immer dann erkennbar, wenn Adressen verwendet werden,die dem Firewall bekannt sind. So kann der Firewall entdecken, daß ein Angreifer versucht, Daten-einheiten von einem unsicheren Netz in ein von ihm gesichertes Netz einzuschleusen, indem er prüft,ob die Dateneinheiten auf der Schnittstelle zum unsicheren Netz mit internen Adressen empfangenwurden.

Neben dem Abweisen von offensichtlich ‘gespooften’ Dateneinheiten werden Firewalls ganz allge-mein dazu eingesetzt, interne Richtlinien (Policies) bei der Kommunikation durch Zugriffskontrollenauf den Datenstom durchzusetzen (vgl. ChZ95, ChB94, Ell94).

Problematisch ist der Einsatz von IP-Firewalls beispielsweise in Abbildung 5-1 auf dem Router. Hierkönnte ein Administrator beispielsweise Paketfilter installiert haben, die das Subnetz 192.168.16.0/24gegen willkürliche Zugriffe aus den anderen Netzen schützen sollen. Dieses Vorgehen ist in den her-kömmlichen LANs auch völlig legitim, da der Router die einzige Übergangsstelle zwischen den Net-zen darstellt. In Abbildung 5-1 müssen tatsächlich alle Dateneinheiten aus dem Token-Ring-Netz unddem Ethernet-Netz über den Router an an das LIS 192.168.16.0/24 gesendet werden. Die installierte‘Packet Screen’-Filterregeln würden angewendet werden.

Für einen Angreifer aus dem LIS 192.168.15.0/24 ist es jedoch ohne weiteres möglich, den Rou-ter und somit den Paketfilter zu umgehen. Zwar fordern die RFCs (Lau94, LaH98), daß inter-LIS-Kommunikation über einen Router erfolgen sollte, es wird aber offen gelassen, wie diese Forderungdurchzusetzen ist.

In Abbildung 5-8 ist dargestellt, wie der Angreifer aus Subnetz 192.168.15.0/24 eine direkte ATM-Verbindung zu seinem Opfer im Subnetz 192.168.16.0/24 aufbaut. Der kontaktierte Client fragt wiebereits oben dargestellt mit InATMARP_Request nach der IP-Adresse des Verbindungsinitiators.Der Angreifer muß hier lediglich eine unbenutzte Adresse aus dem LIS 192.168.16.0/24 wählen.Dann wird der Angegriffene direkt über die etablierte Verbindung antworten. Er verhält sich völ-lig konform zu den RFCs, da die vom Angreifer gewählte Adresse im LIS des Angegriffenen liegt.Durch diese direkte Kommunikation wird jedoch der Router und somit der dort installierte Paketfil-

89


ter umgangen. Die Überlagerung eines ATM-Netzes mit mehreren LIS ist daher beim Einsatz vonIP-Firewalls problematisch.

Abbildung 5-8. Umgehung eines IP-Firewalls

fwlpass

SETUP

CONNECT

CONNECT_ACK

InATMARP_Request ()Client fragt nach der IP-Adresse desKommunikationspartnerszum Aktualisieren der eigenen ARP-Tabelle

InATMARP_Reply(192.168.16.5)

Angreifer ‘spooft’die IP-Adresse und gibt sich als LIS-Client des Netzes192.168.16.0/24 aus.

IP

IP

IP

Direkte Kommunikationohne Verwendung einesVermittlungsrechners

Client

192.168.16.2

Angreifer

192.168.15.1

5.3. GegenmaßnahmenDie oben vorgestellten Probleme beim Einsatz von CLIP sind schwerwiegend und lassen sich nichtvollständig beseitigen. In den folgenden Abschnitten werden dennoch einige Gegenmaßnahmen dis-kutiert, die die oben beschriebenen Angriffe deutlich erschweren. Die Maßnahmen lassen sich in zweiKategorien einteilen. Der ATMARP-Dienst muß abgesichert werden und zusätzlich muß die in denRFCs geforderte LIS-Trennung durchgesetzt werden. Dadurch besteht die Möglichkeit, die LIS nachSicherheitsgesichtspunkten zu strukturieren und Kommunikation zwischen den LIS über einen (odermehrere) Firewall(s) zu lenken.

5.3.1. Absichern des ATMARP-Servers

90


Bei der Absicherung des ATMARP-Servers muß man versuchen, den Zugriff auf diesen Dienst soweit wie möglich einzuschränken. Diese Maßnahme alleine verhindert die Angriffe nicht, schränktaber den potentiellen Täterkreis ein. Weitere Absicherungsmöglichkeiten ergeben sich durch eineEndgeräte-basierte Implementation, die entsprechend den eigenen Sicherheitsanforderungen konfigu-riert werden kann.

Die erste Methode, den Zugriff auf den ATMARP-Server einzuschränken, besteht darin, diesen Dienstvom ATM-Switch auf ein Endsystem im LIS zu verlagern. Der Vorteil besteht darin, daß die Kommu-nikation zu diesem LIS-Endsystemmit den in Abschnitt 4.2 vorgestellten Mechanismen entsprechendden Sicherheitsanforderungen des jeweiligen LIS vorgenommen werden können. Konkret bedeutetdies:

1. Zusammenfassen von Endsystemen mit der gleichen Policy zu einem LIS.

Dieses Vorgehen ist nicht neu. Auch in herkömmlichen IP-Installationen wurden die Rechnerbereits in Subnetze u.a. entsprechend ihrer Sicherheitsanforderung strukturiert.

2. Konfigurieren eines ATMARP-Servers auf einem Endsystem im LIS

Hierbei wird pro LIS ein eigener ATMARP-Server repliziert. Die typische Vorgehensweise inMulti-LIS-Umgebungen ist die gleichzeitige Benutzung eines ATMARP-Servers auf einemATM-Switch durch mehrere LIS. Dadurch kann die Kommunikation zu ATMARP-Server jedoch nichtweit genug eingeschränkt werden (s.u.). Die Replizierung bietet darüber hinaus den Vorteil, daßbei einem DoS-Angriff nur ein LIS betroffen ist. Die Ausfallsicherheit wird somit erhöht.

3. Einschränken der Kommunikation zum ATMARP-Server

Hierbei wird lediglich den LIS-Angehörigen erlaubt, überhaupt eine Verbindung zum ATMARP-Server aufzubauen. Dies geschieht durch Konfigurieren von Adreßfiltern (vgl. Abschnitt 4.2.3).

Durch diese Maßnahmen ist sichergestellt, daß Angriffe nur noch lokal erfolgen können. Ist diesnicht ausreichend,muß der ATMARP-Server selber weiter eingeschränkt werden. Eine im DFN-FWLin der Entwicklung befindliche Version eines „policy driven ATM address resolution daemon“ (vgl.paarpd (http://www.fwl.dfn.de/fwl/paarpd/paarpd.html) sowie SourceForge (http://paarpd.sourceforge.net))bietet u.a. folgende Möglichkeiten:

1. Einschränken der ATM-Adressen

Durch diese Maßnahmen wird erreicht, daß nur à priori bekannte ATM-Adressen in den ‘Calling-Party-IEs’ erlaubt sind. Versucht jemand mit einer anderen ATM-Adresse zum Server zu signali-sieren, wird der Aufbau eines CLIP-SVCs unterbunden.

91


2. Einschränken der IP-Adressen

Wurde von einer gültigen (aber möglicherweise gefälschten) ATM-Adresse ein CLIP-SVC zumATMARP-Server aufgebaut, dann kann nur eine à priori konfigurierte IP-Adresse bzw. ein IP-Adreßbereich reserviert werden. Weitere Abhängigkeiten können vom Administrator spezifiziertwerden, beispielsweise gültige Anmeldezeiten und maximale Anzahl der reservierbaren Adres-sen.

3. Einschränken der ATMARP-Abfragen

Darüber hinaus ist es sinnvoll, die Abfragemöglichkeiten der einzelnen LIS-Clients zu kontrol-lieren und die Abfragefrequenz zu überwachen. Eine hohe Abfragefrequenz nach Adressen, dieaußerhalb der eigenen LIS liegen, kann als Indiz für eine Fehlkonfiguration des Clients dienenoder sogar auf einen versuchten DoS-Angriff hindeuten.

Lokale Kenntnis über den Typ der Clients (RFC1577 oder RFC2225 kompatibel) können wei-tere Indizien für Angriffe liefern. Auffällig sind beispielsweise Abfragen von Adressen ohnevorherige Anmeldung, nicht RFC-konformes Verhalten, das von anderen Implementationen ge-gebenenfalls toleriert wird und auch eine hohe Abfragefrequenz (ARP-Anfragen) über denselbenSVC.

4. Konfigurierbare Reaktionen und Audit

Wann immer ungewöhnliches Verhalten seitens des ATMARP-Servers entdeckt wird, kann einevom Administrator konfigurierte Aktion ausgelöst werden. Beispielsweise kann ein Eintrag ausdem ARP-Cache gelöscht und die Verbindung zum Client beendet werden, falls ein Client durchzu häufige Anfragen den Verdacht erregt, böswillig zu sein.

Falls zu viele Verbindungen zum ATMARP-Server innerhalb eines bestimmten Zeitintervallsaufgebaut werden, schützt sich der ATMARP-Server selber, indem er die Annahme weiterer Ver-bindungen eine gewisse Zeit lang verweigert. Bereits etablierte Verbindungen bleiben davon un-berührt, d.h. die bereits registrierten Clients können weiterhin Anfragen stellen. Hierdurch kannwirksam den DoS-Angriffen entgegen gewirkt werden, die durch massives Signalisieren versu-chen, den Server voll auszulasten.

5.3.2. Integration eines IP-FirewallsDie Integration eines Firewalls in ein ATM-Netz wurde bereits in Abschnitt 4.2.3 beschrieben. Fallsmehrere LISs über demselben ATM-Netz betrieben werden sollen und diese LISs zu verschiedenenSicherheitszonen gehören, dann muß unbedingt daran gedacht werden, die Signalisierung zwischenEndgeräten verschiedener LISs zu unterbinden.

92


Bei der Integration eines IP-Firewalls in ein ATM-Netz sind die folgenden Punkte auf jeden Fall zubeachten:

• Gibt es redundante Verbindungen zwischen den LISs?

Falls zwischen Switches verschiedener LISs redundante physikalische Verbindungen gelegt wur-den, beispielsweise um eine erhöhte Verfügbarkeit zu erreichen, dann müssen auch diese redun-danten Verbindungen abgesichert werden. Auch auf den Schnittstellen, von denen die zusätzlichenLeitungen ausgehen, muß die Signalisierung wie in Abschnitt 4.2.3 dargestellt eingeschränkt wer-den.

• Sind LIS-Mitglieder über alternative Netze angeschlossen?

Auf einer typischen ATM-Schnittstelle für Endgeräte können mehrere logische IP-Adressen kon-figuriert werden. Es ist daher möglich, daß ein LIS-Mitglied über dieselbe Schnittstelle in mehrals einem LIS eingebunden ist. Ein Firewall zwischen diesen beiden LISs könnte dann leicht um-gangen werden, wenn andere LIS-Mitglieder Dateneinheiten über den Rechner mit der mehrfachenLIS-Zugehörigkeit ‘routen’. Dies ist leicht möglich, wenn auf dem entsprechenden Rechner dieIP-Vermittlung (IP-Routing) aktiviert ist.

Die gleicheMöglichkeit zur Umgehung eines Firewalls besteht, falls ein odermehrere LIS-Mitgliederzusätzlich als LANE- oder MPOA-Clients registriert sind. Auch in diesem Fall kann eine LIS-Trennung eventuell durch ein Routing über diese Rechner umgangen werden.

Die Integration eines IP-Firewalls ist technisch mit den in Abschnitt 4.2.3 dargestellten Mechanismenmöglich. Die Wirksamkeit dieser Mechanismen muß jedoch im Einzelfall betrachtet werden, insbe-sondere bei redundanterNetzauslegung und Zugehörigkeit einzelner Rechner zu mehreren Subnetzen.

Fußnoten1. Von jedem der (n) Rechner zu jedem anderen außer zu sich selbst (n-1). Dabei ist ein PVC bidi-

rektional, so daß nur die Hälfte benötigt wird (/2).

2. Dies bietet dem Anfragenden die Möglichkeit, zwischen einem nicht mehr operablen ATMARP-Server, der nicht mehr antwortet, und einer nicht vorhandenen Adreßregistrierung zu unterschei-den.

3. Es wird davon ausgegangen, daß CLIP mit SVCs betrieben wird.

4. Es handelt sich hierbei um die normale Vorgehensweise bei der Protokollspezifikation. Es sollim wesentlichen festgelegt werden, wie sich die konformen Teilnehmer (hier CLIP-Client undATMARP-Server) zu verhalten haben, damit der jeweilige Dienst interoperabel erbracht werdenkann. Sicherheitsprobleme entstehen u.a. dadurch, daß Angreifern die Möglichkeit gegeben wird,

93


sich nicht-konform zu verhalten. Die Protokolle sind in der Regel unterspezifiziert, sie reagierennur dann korrekt, solange auch die Umgebung (hier der Angreifer) konform zum gewünschten(spezifizierten) Verhalten reagiert.

5. In Paket-orientierten Netzen, beispielsweise in über Router gekoppelten Ethernet-Segmenten,besteht eine Schwierigkeit für einen Angreifer darin, das „spoofing“ geheim zu halten. Da dieAntwortpakete des Angegriffenen vom Router zu dem Rechner zurückgesendet werden, dessenAdresse der Angreifer für das „spoofing“ benutzt, muß der Angreifer durch weitere Maßnahmendiesen Rechner ausschalten. Typischerweise macht der Angreifer dies durch eine gleichzeitigeDoS-Attacke auf eben diesen Rechner. Der Angreifer verhindert dadurch, daß der unbeteiligteDritte durch Senden von ‘Reset’-Segmenten die aus seiner Sicht unvollständige TCP-Verbindungzu dem anderen angegriffenen Client beendet. Darüber hinaus muß der Angreifer die Sequen-znummern der vomAngegriffenen zurückgesendeten Pakete erraten, da diese wie oben dargestelltnicht bei ihm, sondern bei einem anderen Client ankommen. Weitere Details zu diesen Angriffenbefinden sich u.A. in Bel89 und BeE98

94

Kapitel 6. ‘Server Cache SynchronizationProtocol’ (SCSP)

Ein Problem durch die zusätzlichen Dienste in ATM-Netzen, beispielsweise bei Verwendung des inKapitel 5 diskutierten ATMARP-Servers, besteht in der geringeren Verfügbarkeit dieser ‘single pointof failure’ im Vergleich zu verteilten Lösungen, die auf einfachen ‘broadcast’-Mechanismen basieren.

Dieses Problem sollte durch die Spezifikation eines universellen ‘Cache-Update’-Protokolls für alledenkbaren Dienste in einem ATM-Netz gelöst werden. Durch ein solches Protokoll sollen redundan-te Server ihre Informationen zeitnah abgleichen können. Gleichzeitig soll das verwendete Protokollunabhängig von einem bestimmten Servertyp und somit allgemein verwendbar sein.

Probleme ergeben sich in den Fällen, wo die Sicherungsmechanismen des zu replizierenden Serversund des eingesetzten ‘Cache-Update’-Protokolls unausgewogen sind. In diesem Fall kann der Angrei-fer die Systeme über das jeweils schwächste Glied in dieser Kette angreifen.

6.1. Funktionsweise des SCSPEin solches allgemeines Protokoll wurde von der IETF unter dem Namen ‘Server Cache Synchro-nization Protocol’ (SCSP) in LAH98 spezifiziert. In den folgenden Unterabschnitten wird kurz dieFunktionsweise dargestellt, um dann auf die Angriffsmöglichkeiten einzugehen. Diese Darstellungist eine knappe Zusammenfassung der wesentlichen Mechanismen, wie in LAH98 beschrieben.

Das SCSP ist grob in drei Phasen eingeteilt, die im Normalfall nacheinander durchlaufen werden.Jede dieser Phasen bedient sich eines eigenen (Sub-)Protokolls. In der ersten Phase sollen die Serverihre unmittelbaren Nachbarn erkennen und feststellen, ob sie mit diesen ihre Daten abgleichen wol-len. Hierzu wird das sogenannte ‘Hello Protocol’ verwendet. In der darauffolgenden Phase kann einneu hinzugekommener Server seine Daten mit den bereits in der Server-Gruppe existierenden Ser-vern abgleichen. Der neue Server muß sich sozusagen den ‘aktuellen Stand’ der verteilten Datenbankaneignen und gegebenenfalls lokale Einträge den anderen Servern mitteilen. Hierzu wird das ‘Ca-che Alignment’ Protokoll verwendet. Die dritte Phase beginnt nach diesem initialen Abgleich. DurchVersenden von Nachrichten kann im Bedarfsfall eine lokal vorgenommene Änderung den anderenServern mitgeteilt werden. Hierfür wird das sogenannte ‘Cache State Update’ Protokoll verwendet.

Die einzelnen Phasen werden jetzt kurz anhand der jeweils in der Phase verwendeten Protokolledargestellt.

6.1.1. Hello ProtocolNach dem (Neu-)Start eines Servers versucht dieser, jeweils eine ATM-Verbindung zu allen anderenServern in der Server Gruppe (SG) aufzubauen. Die jeweiligen ATM-Adressen der Mitglieder dieser

95

Kapitel 6. ‘Server Cache Synchronization Protocol’ (SCSP)

SG muß diesem Server à priori bekannt sein. Für jeden dieser Nachbarn (Directly Connected Server,DCS) führt der lokale Server (LS) einen eigenen Zustandsautomaten. Konnte eine ATM-Verbindungzum Nachbarn aufgebaut werden, dann geht dieser Zustandsautomat vom Zustand down in den Zu-stand waiting über.

Zu jedem DCS sendet der LS periodisch eine ‘Hello’-Dateneinheit, die dem Nachbarn mitteilt, daßder lokale Server noch in der SG ist. Der lokale Server identifiziert sich durch eine eindeutige ID.Empfängt der lokale Server über die Verbindung ‘Hello’-Dateneinheiten seines Nachbarn, so kanner in den Zustand unidirectional connection wechseln. Empfängt er mit einer der ‘Hello’-Dateneinheiten in der dort mitgeführten Liste der Empfänger (repräsentiert durch die eindeutigenServer-IDs) auch seine eigene ID, dann kann der LS in den Zustand bidirectional connec-

tion wechseln, da der Nachbar offensichtlich erkannt hat, daß der lokale Server ihm eine ‘Hello’-Dateneinheit gesendet hat.

Empfängt die lokale Instanz eine ‘Hello’-Nachricht von einem DCS, dann nimmt sie dessen ID mit indie eigene Liste der Empfänger auf, die mit jeder neuen ‘Hello’-Nachricht an den DCS gesendet wird.Die nächste eigene Nachricht bestätigt dem DCS somit den rechtzeitigen Empfang seiner ‘Hello’-Nachricht.

Aus dem Zustand bidirectional connection wechselt die lokale Instanz in den Zustand wai-ting zurück, falls eine ‘Hello’-Nachricht des Nachbarn zu lange ausbleibt. Das maximale Intervallzwischen zwei aufeinanderfolgenden ‘Hello’-Nachrichten kann der DCS selber wählen und in jeder‘Hello’-Nachricht neu setzen. Das Ausbleiben dieser Nachricht deutet somit an, daß der DCS zur Zeitnicht am Austausch von Informationen teilhaben kann, also keine ‘Cache-Updates’ empfangen kann.

Die lokale Instanz wechselt in den Zustand unidirectional connection, falls die empfangeneNachricht vom DCS die eigene ID nicht (mehr) in der Liste der Empfänger aufweist. Hiermit deutetder DCS an, daß die lokale Instanz zu lange keine ‘Hello’-Nachricht mehr gesendet hat.

Sollte in irgendeinem Zustand die ATM-Verbindung zu einem DCS beendet werden (absichtlich oderunabsichtlich), dann wechselt der lokale Zustandsautomat sofort in den Zustand down. In diesemZustand können von dem betroffenen DCS keine ‘Cache-Updates’ empfangen werden.

Zusammenfassend ist die Aufgabe des ‘Hello’-Protokolls somit die erste Kontaktaufnahme zu denDCS herzustellen und die zugrundeliegende ATM-Verbindung zu jedem einzelnen DCS während dernachfolgenden Phasen zu überwachen. Dateneinheiten aus den nachfolgenden Phasen (bzw. PDUsdes ‘Cache Alignment’ Protokolls oder des ‘Cache State Update’ Protokolls) dürfen daher nur verar-beitet werden, wenn sie über eine Verbindung empfangen wurden, dessen zugehöriger Zustandsauto-mat bidirectional connection anzeigt. Der Zustandsautomat ist in Abbildung 6-1 noch einmalgraphisch dargestellt.

Abbildung 6-1. Zustände des ‘Hello’-(Protokoll-)Automaten (aus LAH98)

96


DOWN

WAITING

UCONNBCONN

6.1.2. Cache Alignment ProtocolDas ‘Cache Alignment’ Protokoll dient dem ersten Abgleich von ‘Cache Einträgen’ mit einem Nach-barn (DCS). Auch dieses Protokoll ist wieder in mehrere Zustände eingeteilt. Aus dem initialenZustand down wird in den Folgezustand master/slave negotiation gewechselt, wenn der Zu-standsautomat des ‘Hello’ Protokolls den Zustand bidirectional connection erreicht hat. ImZustand master/slave negotiation verständigen sich die beiden Server darauf, wer währenddes folgenden ‘Cache Alignment’ die Rolle des ‘Masters’ übernimmt. Der Server mit der größerenID wird ‘Master’, derjenige mit der kleineren ID wird ‘Slave’. Das Aushandeln erfordert lediglich dasSenden von jeweils einer Dateneinheit (‘Cache Alignment’ Nachricht, CA) in jede Richtung. Mit die-ser ersten Dateneinheit senden sich die Kommunikationspartner erneut (also unabhängig vom ‘Hello’Protokoll) ihre eigene ID zu, um daraufhin zu entscheiden, wer die Rolle des ‘Masters’ übernimmt.Teil der initialen CA-Nachricht ist jeweils eine lokal frei wählbare Sequenznummer, die der Slavenach der Rollenvergabe vom Master übernimmt. Nach der Rollenvergabe wird in den Folgezustandcache summarize gewechselt.

Im Zustand cache summarize erhöht der ‘Master’ mit jeder CA-Nachricht an den ‘Slave’ die Se-quenznummer in der CA-PDU. Der ‘Slave’ muß solange warten, bis er eine CA-PDU vom ‘Master’bekommt, die eine um eins (1) erhöhte Sequenznummer beinhaltet. Sind in dieser Nachricht ‘Ca-

97


che State Advertisement Summary’ (CSAS) Einträge enthalten, gleicht der ‘Slave’ diese Einträgemit seiner Datenbank ab. Der ‘Slave’ kann nun seinerseits CSAS-Einträge in einer als Antwort anden ‘Master’ zurückgesendeten CA-Nachricht eintragen. Dieser Nachrichtenaustausch geht so langeweiter, bis beide Instanzen (Master/Slave) durch ein Flag in den CS-Nachrichten anzeigen, daß siekeine weiteren CSAS-Einträge zu versenden haben. In diesem Fall gehen beide in den Folgezustandupdate cache über.

Über den oben dargestellten Sequenzmechanismus gibt es zu jeder Zeit genau eine ausstehende Nach-richt zwischen ‘Master’ und ‘Slave’, da der ‘Master’ erst wieder sendet, wenn er vom ‘Slave’ eineNachricht mit der eigenen Sequenznummer erhält und der ‘Slave’ nur dann sendeberechtigt ist, wenner zuvor eine Nachricht mit einer neuen (frischen) Sequenznummer erhalten hat. Dies ist ein sehreinfacher Flußkontrollmechanismus, der beiden Instanzen die Möglichkeit gibt, die jeweiligen Nach-richten ‘in Ruhe’ zu verarbeiten.

Nachrichtenverluste werden durch ablaufende Zeitgeber erkannt. In diesem Fall wechselt eine Instanzin den Zustand master/slave negotiation zurück und zwingt die Partnerinstanz durch Sendeneiner CA-Nachricht mit einem gesetzten ‘Initialisierungs-Flag’ ebenfalls wieder in diesen Zustand.Der initiale ‘Cache Update’ muß dann von neuem beginnen. Durch diesen einfachen Mechanismuswird letztendlich eine vollständige Übertragung aller CSAS-Einträge beider lokaler Datenbanken er-reicht. Auf das Versenden von negativen Bestätigungen für offensichlich ausgebliebene Dateneinhei-ten (beispielsweise wenn der ‘Slave’ eine Dateneinheit mit einer um mehr als eins erhöhten Sequenz-nummer erhält) wurde somit verzichtet.

Im Zustand update cache state fordern ‘Master’ und ‘Slave’ durch Senden von ‘Cache StateUpdate Solicit’ (CSUS)-Nachrichten gegenseitig die vollständigen ‘Cache-Einträge’ des anderen an,die in den obigen ‘Summary’-Einträgen (CSAS) als neuer als die lokalen Informationen zu erkennenwaren. Der Kommunikationspartner sendet daraufhin die vollständigen CSA-Einträge (also nicht nurdie ‘Summaries’ (CSAS)) in einer oder mehreren ‘Cache State Update Reply’-Nachrichten zurückund fordert seinerseits vollständige CSA-Einträge an (falls erforderlich).

Bei ausbleibenen Antworten können diese erneut angefragt werden. Auch in diesem Zustand werdendafür Zeitgeber verwendet. Nachdem bei beiden Kommunikationspartnern die lokalen Datenbankenauf den neuesten Stand gebracht worden sind, wechseln ‘Master’ und ‘Slave’ in den Zustand alignedund die dritte Phase des SCSP kann beginnen.

6.1.3. Cache State Update ProtocolNach dem ersten Abgleich von Datenbankeinträgen mit den DCSs müssen nur noch bei Veränderun-gen an den lokalen Datenbanken (‘Caches’) Nachrichten an die Partner gesendet werden, um sie überdie Veränderungen zu informieren.

Eine Veränderung tritt immer lokal auf einem Server in der SG auf. Diese Veränderung muß den an-deren Servern in der SG mitgeteilt werden. Hierzu sendet der LS, der die Veränderung an seinem ‘Ca-che’ bemerkt, eine cache state update request (CSU-Request)-Nachricht an alle DCS. DieVeränderung am ‘Cache’ wird in einem CSA-Eintrag mit dem CSU-Request versendet.

98


Die DCS empfangen die Nachricht und prüfen, ob die CSA-Einträge aktuellere Informationen ent-halten als die in ihren lokalen Datenbanken. In diesem Fall senden die Empfänger eine CSU-Reply-Nachricht an den Sender zurück, die einen CSAS-Eintrag für jeden verarbeiteten CSA-Eintrag alsBestätigung enthält. Darüber hinaus sendet jeder DCS die neuen Informationen mit eigenen CSU-

Requests an alle seine DCS weiter. Es wird lediglich der DCS ausgelassen, von dem die neuenInformationen empfangen wurden (also der DCS, dem stattdessen die Bestätigung für den Empfangder neuen Informationen in Form einer CSU-Reply-Nachricht gesendet wurde). Durch diesen einfa-chen Mechanismus werden neue Informationen zu allen Servern innerhalb der SG weitergeleitet.

Erneut wird mit Hilfe von Zeitgebern überprüft, ob für alle gesendeten CSA-Einträge eine Bestätigungin Form eines CSAS-Eintrags in einer CSU-Reply-Nachricht empfangenwurde. Falls die Bestätigungnicht rechtzeitig empfangen wird, sendet der jeweilige LS erneut eine CSU-Request-Nachricht mitnoch nicht bestätigten CSAS-Einträgen. Bleiben die Bestätigungen mehrfach aus, wechselt der Zu-standsautomat für die Verbindung zu diesem DCS in den Zustand waiting (vgl. Abbildung 6-1), dadavon ausgegangen werden kann, daß der betroffene DCS ernsthafte Probleme hat (‘abnormal event’,S.15 in LAH98).

6.2. AngriffsmöglichkeitenEs gibt generische Angriffsmöglichkeiten auf das SCSP bzw. auf die jeweiligen Server in der SG.Diese generischen Angriffe sind bekannt und werden teilweise in LAH98 schon genannt. Generischbedeutet im Zusammenhang mit dem SCSP, daß die Angriffe unabhängig vom zu unterstützendenProtokoll1 2 möglich sind.

Darüber hinaus sind Angriffsmöglichkeiten dadurch gegeben, daß das zu unterstützende Protokolleingesetzt wird, um die verteilte Datenbank (den verteilten ‘Cache’) indirekt über das SCSP zu kom-promittieren.

6.2.1. Generische AngriffsmöglichkeitenDie generischen Angriffsmöglichkeiten ergeben sich dadurch, daß die einzelnen Nachrichten desSCSP nicht zwingend verschlüsselt und authentifiziert werden. Es ist jedoch möglich, daß die Nach-richten zwischen zwei Instanzen mit einer optionalen ‘Authentication Extension’ versehen werden.Dadurch lassen sich Manipulationen an den Dateneinheiten erkennen. Unmittelbar einsichtig ist da-her, daß beliebige Manipulationen möglich sind, so lange diese ‘Authentication Extensions’ nichtverwendet werden.

Es ergeben sich konkret die folgenden Probleme:

‘Peer-to-Peer’-Authentifikation und implizites Vertrauen

Der in Abschnitt 6.1.3 vorgestellte Mechanismus zum ‘Cache-Update’ propagiert neue Infor-mationen innerhalb der SG von einem LS über einen oder mehrere DCS zu den RS (remoteservern), bis alle Server der SG die aktuellen Daten erhalten haben. Falls es nur einen Server

99


gibt, bei dem die Authentifizierungsfunktion mittels ‘Authentication Extension’ nicht aktiviertist, können über diesen Server der ganzen SG falsche Informationen zugespielt werden. Der An-greifer wendet sich mit vermeintlich neuen Informationen an diesen einen Server, der dann überdie Verbindungen zu seinen jeweiligen DCS die nicht authentifizierten Informationen weiterver-teilt. Auch wenn der Server für die DCS eine ‘Authentication Extension’ hinzufügt, propagierter potentiell falsche/manipulierte Informationen.

Ursächlich für dieses Problem sind Entwurfsschwächen beim SCSP. Es findet eine ‘Peer-zu-Peer’-Authentifizierung der SCSP-Dateneinheiten anstelle einer Server-basierten Authentifizie-rung der ‘Cache-Daten’ statt. Der qualitative Unterschied ist erheblich: Die Authentifizierungder Dateneinheiten besagt lediglich, daß während der Übertragung keine Manipulationen an denPDUs stattgefunden hat. Es wird jedoch nichts darüber ausgesagt, woher die Daten kommen undob der DCS, von dem die Daten empfangen wurden, diese selber produziert hat oder lediglichweitergeleitet hat. Es wird bei dieser ‘Peer-zu-Peer’-Authentifizierung somit ein transitives, im-plizites Vertrauensverhältnis vorausgesetzt; eine sehr problematische Entwurfsentscheidung, daso entweder jedem innerhalb der SG getraut werden muß oder niemandem getraut werden kann.

Würden die einzelnen Server hingegen die Informationen mit eigenen öffentlichen Schlüsselnsignieren, dann könnte jede Instanz lokal prüfen, von wem die Daten kommen und ob an denDaten bei der Übertragung manipuliert wurde. Somit bräuchte eine Instanz den DCS nicht mehrzu trauen als jedem beliebigen RS innerhalb der SG. Das Vertrauensverhältnis wäre selektivund es könnte die Integrität der Daten unabhängig vom Übertragungsweg verifiziert werden.Außerdem würde die Notwendigkeit entfallen, auf jedem LS die PDUs für jeden DCS mit demjeweiligen ‘peer key’ erneut zu ‘signieren’.

‘Bootstrap’-Problem beim Einsatz von IKE-Protokollen

Für den oben diskutierten ‘Peer-zu-Peer’-Authentifizierungsmodus ist es bei einer vollständigvermaschten SG erforderlich, auf jedem Server (n^2-n)/2 symmetrische Schlüssel vorzuhalten.Dies ist bei nicht trivialen SG (beispielsweise n>10) und manueller Schlüsselverwaltung hoch-gradig aufwendig und fehleranfällig. LAH98 empfiehlt daher den Einsatz von IKE-Protokollenfür eine maschinelle Schlüsselverwaltung.

Problematisch an dieser Empfehlung ist allerdings, daß im Umfeld von ATM (und dies ist dasHaupteinsatzgebiet des SCSP) kein IP-Dienst zur Verfügung steht, der von den gängigen IKE-Protokollen zum initialen Schlüsselaustausch benutzt wird. Mit anderenWorten, der Einsatz vonIKE-Protokollen benötigt IP, das durch LANE oder CLIP bereitgestellt wird. LANE und CLIPbenutzen bei größeren Installationen jedoch das SCSP, um die ‘Cache-Daten’ der essentiellenServer zu synchronisieren (LNNI bzw. ATMARP als SCSP-Protokollkennung), so daß sich zy-klische Abhängigkeiten ergeben. Es entsteht somit ein ‘bootstrap’-Problem.

Keine Wahrung der Vertraulichkeit

Da lediglich eine Authentifizierung durch die ‘Authentication Extension’ ermöglicht wird unddas SCSP keinen Mechanismus für die Verschlüsselung der PDUs bereitstellt, ist die Vertrau-

100


lichkeit der übertragenen Daten nicht gesichert. Bei den ‘Cache Daten’ der zur Zeit vom SCSPunterstützten Dienste mag die Argumentation möglich sein, daß diese Daten ohnehin öffentlichsind, eine Verschlüsselung somit nicht erforderlich sei. Der Verzicht auf Verschlüsselungsalgo-rithmen verhindert jedoch den breiteren Einsatz dieses Protokolls für den Abgleich von ver-traulicheren Daten, beispielsweise in Szenarien, bei denen verteilte Datenbank-Server für eineschnelle Synchronisationen über ein breitbandiges ATM-Netz gekoppelt werden.

Neben diesen Problemen, die letztendlich auf den ungenügenden Einsatz von kryptographischenMe-chanismen zurückzuführen sind, entstehen weitere Probleme durch DoS-Angriffe auf die verteilteDatenbank. Wird keine Authentifizierung eingesetzt, ist es für einen Angreifer trivial, die Server ei-ner SG mit sich selber zu beschäftigen, indem zwei oder mehreren Teilnehmern jeweils leicht unter-schiedliche Informationen zum selben „Cache-Datensatz“ innerhalb kurzer Zeit zugespielt werden.Jeder Teilnehmer wird versuchen, diese vermeintlich neuen Daten an alle anderen zu senden, so daßneben einem erheblichen Kommunikationsaufkommendie Server möglicherweise durch das ständigeAbgleichen ihrer ‘Cache-Informationen’ ausgelastet werden.

6.2.2. Indirekte AngriffsmöglichkeitenBei den indirekten Angriffsmöglichkeiten verwendet der Angreifer nicht direkt das SCSP, sondern ergreift einen wichtigen Dienst im ATM-Netz an. Falls der angegriffene Server seinerseits das SCSPverwendet, um seine Daten mit redundanten Servern zu teilen, kann ein Angreifer das SCSP somitausnutzen, um indirekt alle Server der SG anzugreifen.

6.2.2.1. Beispiel: DoS-Angriff auf ATMARP-SG

Am Beispiel eines ATMARP-Servers, der das SCSP zum Abgleich seiner ‘Cache-Daten’ mit redun-daten ATMARP-Servern verwendet, wird dieser indirekte Angriff (aus Sicht des SCSP) verdeutlicht.Hierzu ist es lediglich erforderlich, sich einen Angreifer vorzustellen, der willkürlich (IP-Adresse,ATM-Adresse)-Tupel bei dem Server reserviert. Findet dies mit genügend hoher Geschwindigkeitstatt, so ist dies, wie in Abschnitt 5.2 bereits diskutiert, ein DoS-Angriff.

Ist dieser ATMARP-Server jedoch in eine SG mittels SCSP eingebunden, wird er versuchen, dieseInformationen an seine DCS und somit schließlich an alle Server der SG weiterzureichen. Der Angrei-fer veranlaßt den Server somit stellvertretend die anderen Server ebenfalls mit falschen/irrelevantenAdreßinformationen zu überfluten. In einem ATM-Netz entsteht dadurch zusätzlich noch eine erheb-liche Netzlast, da die ‘Peer-zu-Peer’-Verbindungen des SCSP im allgemeinen Fall ein Kopieren dervom Angreifer erstellten ‘Cache-Daten’ über mehrere Verbindungen bewirkt.

Besonders mißlich wird der Angriff durch die bereits oben diskutierte Vorgehensweise, auf zwei odermehreren verschiedenen Servern ähnliche (aber verschiedene) ‘Cache-Einträge’ zu erzeugen. Im kon-kreten Fall des ATMARP-Dienstes würde ein Angreifer auf Server A einen Eintrag der Form (IPa,ATMa) erzeugen und auf Server B einen Eintrag der Form (IPa, ATMb) oder auch (IPb, ATMa). So-wohl Server A als auch Server B würden daraufhin versuchen, ihre ‘Sicht der Dinge’ innerhalb derSG zu verteilen. Das Nachrichtenaufkommen ist um so größer, je weiter die beiden Server topolo-

101


gisch auseinander liegen, da die Informationen sich erst weit ausbreiten müssen, bevor ein Abgleicherfolgen kann.

Es ist somit unmittelbar einsichtig, daß ein nicht gesicherter ATMARP-Server, der mit anderen redun-danten ATMARP-Servern in Kontakt steht, somit auch die anderen – möglicherweise deutlich bessergesicherten – Server gefährdet. Auch unter der Voraussetzung, daß alle Server in einer SG untereinan-der die oben beschriebenen Authentisierungs-Erweiterungen benutzen und von niemanden außerhalbihrer SG Informationen annehmen, kann die gesamte Server-Gruppe durch einen DoS-Angriff aufnur einen Server beeinträchtigt werden. Das hier am Beispiel von ATMARP diskutierte Szenario istnatürlich auf die anderen Dienste, die das SCSP ebenfalls unterstützen soll, mit geringem Aufwandübertragbar und braucht hier nicht näher erläutert zu werden.

Im speziellen Fall des eigentlich schon in Kapitel 5 behandelten ATMARP-Servers ist nun zu fragen,wie die vom Angreifer erzeugten, verschiedenen Sichten zwischen zwei oder mehreren Servern abzu-gleichen sind. Zum einen ist fraglich, ob vor Ablauf des ‘Timeouts’ von 20 Minuten bei ‘ATMARP-Cache’-Einträgen einer der beiden betroffenen Server überhaupt seine lokale Sicht korrigieren darf,falls er vermeintlich neuere Einträge von einem anderen Server via SCSP bekommt. Vermutlich wür-de so ein Server versuchen, den eigenen ‘Cache-Eintrag’ mittels ‘InATMARP-Request’ beim Clientzu verifizieren. Bestätigt ein Angreifer daraufhin die vermeintliche Gültigkeit dieses Eintrags, müßteder ATMARP-Server seinerseits einen neuen SCSP-basierten ‘Cache-Update’ veranlassen. Die Spe-zifikation für einen verteilten ATMARP-Server ist zur Zeit bei der IETF noch in Arbeit. Es ist jedochfraglich, ob die hier diskutierten Probleme dort zur Kenntnis genommen werden.

6.3. GegenmaßnahmenViele der unter ATM neu hinzugekommenen Dienste sind nicht redundant ausgelegt. Es ist dahernaheliegend, die diese Dienste bereitstellenden Server durch Protokolle wie beispielsweise dem SCSPredundant auszulegen und somit die Verfügbarkeit zu erhöhen.

Aus der Sicht eines Fehlermanagements, bei dem es primär um die Schadensbegrenzung von tech-nisch bedingtem Fehlverhalten geht, ist das SCSP für viele Fälle ausreichend. Die einfachen Mecha-nismen sind in hoch zuverlässigen ATM-Netzen mit sehr geringen Bit-Fehlerraten angemessen. Ausder Sicht des Sicherheitsmanagements, das sich primär mit intentionalen Angriffen auf diese Infra-struktur auseinandersetzen muß, ist das SCSP aus den oben genannten Gründen eher nicht geeignet.Will man es dennoch verwenden (beispielsweise um keine proprietären Lösungen einzusetzen) odermuß man es verwenden (beispielsweise weil es keine besseren proprietären Lösungen gibt), dannsollten möglichst die folgenden Sicherungsmechanismen verwendet werden.

6.3.1. Generische Angriffe abwehrenEs ist unbedingt erforderlich, die Server derart in Gruppen einzuteilen, daß innerhalb einer SG al-le Server die SCSP-Nachrichten signieren und keine Nachrichten von anderen SGs annehmen. Die

102


Signierungen/Integritätsprüfsummen können bei den oben beschriebenen ‘Bootstrap’-Problemen le-diglich mit manuell konfigurierten Schlüsseln erfolgen. Diese Schlüssel müssen zwischen jedem LSund allen seinen DCS konfiguriert werden. Zur zusätzlichen Erhöhung der Sicherheit sollte für jedeKommunikationsrichtung ein eigener Schlüssel verwendet werden. Der Konfigurationsaufwand steigtdadurch natürlich an.

Nur durch diese homogene Partitionierung in eine geschlossene SG ist sichergestellt, daß keine Falsch-informationen eingespielt werden können. Zusätzlich sind die unten beschriebenen protokollspezifi-schen Sicherungsmechanismen durchzuführen.

6.3.2. Protokollspezifische Angriffe abwehrenDie jeweils für die einzelnen Dienste besprochenen Sicherungsmechanismen sind ebenfalls durchzu-führen. Läßt sich ein Dienst (beispielsweise der ATMARP-Server) nicht wie in den entsprechendenKapitel beschrieben absichern, dann sollte auf eine Verteilung dieses Dienstes auf Basis des SCSP ver-zichtet werden. Der nicht gesicherte Server könnte andernfalls dazu benutzt werden, die oben disku-tierten protokollspezifischen Angriffe trotz der generischen Absicherung durchzuführen. Am bestenkann dies durch eine homogene Wahl von Server-Software mit identisch konfigurierten Sicherungs-mechanismen erfolgen. Müssen verschiedene, unterschiedlich anfällige Softwareversionen eingesetztwerden, sollte überlegt werden, ob man auf eine Verteilung mit dem SCSP lieber verzichtet.

Abschließend ist zu der Verteilung von Diensten mit dem SCSP anzumerken, daß dies aus Sicherheits-gründen nur dann erfolgen sollte, wenn die zu verteilenden Dienste selber abgesichert werden könnenund die eingesetzte SCSP-Version zusätzlich die ‘Authentication Extension’, wie in Abschnitt 6.3.1beschrieben, verwendet. In jedem anderen Fall handelt man sich zusätzlich Sicherheitsprobleme ein.Es muß dann in Abhängigkeit vom jeweiligen Einsatzszenario entschieden werden, ob dieses zusätz-liche Risiko tragbar ist.

Bei dieser Abwägung ist dann jedoch immer zu bedenken, daß die Verfügbarkeit des mit SCSP verteil-ten Dienstes bei einem DoS-Angriff niedriger ist, als bei einem nicht redundant ausgelegten Dienst.

Fußnoten1. Das SCSP benutzt Protokollkennungen innerhalb der Nachrichten, um die Daten zu identifizieren.

Eine ‘Protokollkennung’ für ATMARP bedeutet daher, daß die Instanz imAuftrag eines ATMARP-Servers dessen ‘Cache-Daten’ abgleichen möchte. Es wird somit nicht das ‘Protokoll’ unterstützt,sondern die verteilte Datenhaltung für einen Dienst, der das Protokoll mit der jeweiligen Kennungverwendet.

2. LAH98 sieht eine Unterstützung für die folgenden Server – gekennzeichnet durch die Protokoll-namen – vor: ATMARP, NHRP, MARS, DHCP, LNNI

103


104

Kapitel 7. ‘Local Area Network Emulation’(LANE)

Viele Programme, die in verteilten Systemen eingesetzt werden, sind für die weit verbreiteten LAN-Protokolle Ethernet, Fast Ethernet, Token Ring oder FDDI programmiert worden und benutzen dievon diesen Schicht-2-Protokollen bereitgestellten ‘Broadcast’-Mechanismen. ATM-Netze unterstüt-zen keinen ‘Broadcast’, so daß viele dieser Programme, APIs oder Schicht-3-Protokolle in einemATM-Netz nicht mehr einsetzbar wären. Die ‘Local Area Network Emulation’ (LANE) des ATM-Forums ist eine Dienst- und Protokollspezifikation, die die transparente Verwendung von diesen Pro-grammen über ein ATM-Netz ermöglichen soll. Dazu wird den Endsystemen im wesentlichen ein‘Broadcast’-Mechanismus zur Verfügung gestellt, so daß diese das ATM-Netz als schnelles Schicht-2-Netz verwenden können. Dadurch ist es sowohl möglich, mehrere LANs über ein ATM-Netz trans-parent zu koppeln, als auch zwischen ATM-Endgeräten und nicht-ATM-Endgeräten in diesen LANszu kommunizieren, ohne daß die Anwendungssoftware auf den Endgeräten an die Besonderheiteneines ATM-Netzes angepaßt werden muß.

Ein LANE-Client (LEC) repräsentiert eine oder mehrere Netzwerkadressen (Schicht-2 Adressen), dieüber ein ATM-Netz von anderen LECs erreichbar sein sollen. Durch die Benutzung dieser herkömm-lichen Netzwerkadressen (beispielsweise Ethernet-Adressen oder Token Ring-Adressen) kann hieraufaufbauende Software auch in ATM-Netzen weiterverwendet werden.

Ein LEC kann beispielsweise auf einer Workstation mit einer ATM-Schnittstelle eingesetzt werden,auf der Software ausgeführt werden soll, die ursprünglich für Ethernet-Netze entwickelt wurde. DerLEC würde dieser Software dann eine Ethernet-Adresse bereitstellen, die zum Senden und Empfan-gen von IEEE802.3-Nachrichten bzw. Ethernet-Nachrichten verwendet werden kann. Ein LEC kannaber auch auf einem Ethernet-Switch installiert werden, der über eine weitere Schnittstelle an einATM-Backbone angeschlossen ist. Die auf dem Switch installierte LEC-Software repräsentiert dannalle lokal über den Switch erreichbaren Ethernet-Adressen.

Über diesen Mechanismus können dann beispielsweise mehrere Ethernet-Switches VLANs über einATM-Netz ausdehnen und ATM-Endsysteme (Workstations mit ATM-Schnittstellen) können eben-falls mit in dieses VLAN aufgenommen werden. Auf dem ATM-Netz wird somit ein LAN emuliert.Die LANE ermöglicht die gleichzeitige Emulation mehrerer LANs über demselben physikalischenATM-Netz (vgl. Abbildung 7-1). Sowohl durch diese Überlagerung als auch durch die noch zu be-schreibenden LANE-Server entstehen vielfältige Angriffsmöglichkeiten.

Abbildung 7-1. Zwei ELANs koppeln Ethernet- und Token Ring LANs über einem physikali-schen ATM-Netz

105

Kapitel 7. ‘Local Area Network Emulation’ (LANE)

TokenRing

Ethernet

TokenRing

ATM

EthernetELAN1

ELAN2

Im Vergleich zu CLIP werden bei der LANE deutlich aufwendigere Mechanismen benötigt. Der Vor-teil der LANE gegenüber CLIP ist, daß durch die Bereitstellung eines Schicht-2-‘broadcast LANs’alle auf solchen LANs aufsetzenden Protokolle über ATM verwendet werden können. Dies kann bei-spielsweise IPX/SPX oder AppleTalk sein, aber auch jedes andere Schicht-3 Protokoll, insbesondereauch IP. An das ATM-Netz angeschlossene Ethernets können so beispielsweise über ein ATM-Netzgekoppelt werden. Es ist auch möglich, daß ein ATM-Endgerät, ohne einen Router zu verwenden, miteinem Endgerät in einem solchen Ethernet kommuniziert. Die LANE gruppiert dafür die verschie-denartigen Endgeräte in ein gemeinsames ‘emuliertes LAN’ (emulated LAN, ELAN) und sorgt fürdie erforderliche Protokollumsetzung.

Der Hauptnachteil der LANE ist die große Komplexität und die daraus resultierenden schlechtenDurchsätze im direkten Vergleich mit CLIP. Ein weiterer Nachteil der LANE in ihrer ersten Ver-sion (LANEv1) ist die große Anzahl nicht redundant ausgelegter Dienste (LANE-Server, LANE-Configuration-Server, LANE-BUS-Server, s.u.), die für einen ordentlichen Betrieb jedoch alle erfor-derlich sind. LANEv2 ermöglicht hingegen die redundante Auslegung der genannten Server. Diesegroße Anzahl an LANE-Diensten bringt jedoch zusätzliche Sicherheitsrisiken mit sich.

Es wird zunächst wieder die Funktionsweise des Protokolls und der Dienste vorgestellt, um anschlie-ßend die möglichen Angriffe und Gegenmaßnahmen zu diskutieren. Es wird hierbei primär die Vor-gehensweise eines LANE-Clients beschrieben. Das im folgenden dargestellte LEC-Protokoll ist inAFo97 spezifiziert.

7.1. Funktionsweise von LANE

106


Für den Betrieb emulierter LANs über ein ATM-Netz werden mehrere Dienste benötigt, die einetransparente Anpassung des verbindungorientierten ATM-Netzes an die von der Software erwartete‘Broadcast’-Eigenschaft eines Schicht-2 Protokolls durchführen. Diese Dienste werden von drei ver-schiedenen Servern erbracht und mehreren hiermit kommunizierendenClients. Es handelt sich hierbeium die folgenden logischen Komponenten:

• LAN Emulation Client (LEC)

Der LEC bietet höheren Protokollen (beispielsweise AppleTalk, SPX/IPX oder auch TCP/IP) eineSchicht-2 konforme Schnittstelle an (beispielsweise DLPI, NDIS oder ODI). Die höheren Proto-kolle können somit transparent über ATM betrieben werden.

• LAN Emulation Configuration Server (LECS)

LECs kontaktieren diesen Server, um Informationen über die verfügbaren emulierten LANs zubekommen. Insbesondere teilt der LECS den LECs die ATM-Adresse eines oder mehrerer LESmit.

• LAN Emulation Server (LES)

Alle LECs müssen sich bei mindestens einem LES mit einer ATM-Adresse und den von ihnen ver-wendeten Schicht-2-Protokoll-Adressen (beispielsweise Ethernet-Adressen) registrieren. Der LESist für die Adreßauflösung zuständig. Anfragen bezüglich unbekannterMAC-Adressen können vonden LECs an den LES gesendet werden, der eine hierzu passende ATM-Adresse zurückliefert. DieAufgabe des LES ist somit der eines ATMARP-Servers bei CLIP sehr ähnlich.

• Broadcast and Unknown Server (BUS)

Der BUS wird verwendet, wenn ein LEC an Schicht-2-‘Broadcast’/‘Multicast’-Adressen sendenmuß. Der BUS unterhält eine Punkt-zu-Mehrpunkt-Verbindung zu allen LECs eines ELANs, um‘Broadcasts’ der einzelnen LECs an alle anderen zu verteilen. Der BUS emuliert somit eine we-sentliche Eigenschaft herkömmlicher ‘broadcast’-Netztechnologien.

Der BUS kann darüber hinaus von den LECs verwendet werden, um Dateneinheiten an einen be-stimmten anderen LEC zu senden, dessen ATM-Adresse noch nicht bekannt ist. Dadurch ist esbeispielsweise möglich, schon während einer Adreßauflösung beim LES zeitgleich die ersten Da-teneinheiten über den BUS an den Empfänger zu senden. Nachdem die ATM-Adresse des Emp-fängers vom LES geliefert wurde, kann der LEC eine direkte ATM-Verbindung zum anderen LECaufbauen, um weiter Dateneinheiten an diesen Empfänger zu senden.

Die Kooperation dieser Komponenten untereinander wird durch den LEC initiiert. Will ein LEC inein emuliertes LAN aufgenommen werden, sind diverse Konfigurationsphasen zu durchlaufen. Inaufeinanderfolgenden Phasen werden dann auch die Server nacheinander kontaktiert, bis der LEC

107


schließlich den Zustand ‘Operational’ erreicht. Danach können die von LEC beim LES registriertenMAC-Adressen von anderen LECs über das emulierte LAN erreicht werden.

7.1.1. LEC-InitialisierungDie Initialisierung eines LEC hat zum Ziel, alle notwendigen ATM-Verbindungen zwischen LEC,LES und BUS zu eröffnen und die primären Adressen beim LES zu registrieren. Danach kann derLEC höheren Protokollen einen Schicht-2-Dienst über das ATM-Netz anbieten.

In Abbildung 7-2 ist die Initialisierung in verschiedenen Phasen dargestellt, die im folgenden genauerbeschrieben werden. Der ‘Normalfall’ ist der Durchlauf von ‘Initial State’ direkt zu ‘Operational’.Wird in einer Phase ein Fehler erkannt, muß der Client wieder in den ‘Initial State’ wechseln, um dieAufnahme in ein emuliertes LAN erneut zu versuchen.

Abbildung 7-2. Initialisierung eines LEC (aus AFo97)

108


Verbindungzum BUSverloren

im F

ehle

rfal

l

Initial State

LECS Connect

Configure

Join

Init. Registration

BUS Connect

Operational

7.1.1.1. LEC Startzustand

Jeder LEC muß vorkonfiguriert werden, da im Startzustand bereits diverse Parameter bekannt seinmüssen, die im weiteren Verlauf dem LES mitgeteilt werden. Die wichtigsten Parameter beschrei-ben beispielsweise den LAN-Typ (Ethernet oder TokenRing), der emuliert werden soll. Wichtig istauch die Liste der lokal zu verwendenden ATM-Adressen und die bereits bekannten, lokalen MAC-Adressen. Weitere vom Administrator konfigurierbare Parameter ermöglichen eine Optimierung desTimings bei bestimmten Protokollabläufen, beispielsweise wie lange auf eine Adreßauflösung gewar-tet werden soll, bevor eine weitere Anfrage versendet wird.

109


7.1.1.2. LEC kontaktiert den LECS

In der ‘LECS Connect Phase’ baut der LEC eine Verbindung zum LECS auf. Die dazu erforderlicheATM-Adresse erfährt der LEC entweder dadurch, daß diese Adresse lokal vorkonfiguriert ist, überdas ILMI-Protokoll (vgl. Abschnitt 4.1) oder der LEC verwendet eine in AFo97 definierte Adres-se. Die Verwendung dieser ‘well-known address’ durch den LEC kann natürlich nur funktionieren,wenn zuvor auf dem lokalen Switch diese Adresse statisch einem Port mit angeschlossenem LECSzugeordnet wurde.

7.1.1.3. LEC erfragt die LES-Adresse

Ist die ATM-Verbindung zu einem LECS hergestellt, kann der LEC die Adresse eines LES beimLECS erfragen. In einfachen Netzen, beispielsweise wenn ohnehin nur ein einziger LES vorhandenist, kann diese Phase auch entfallen.

Für den Aufbau von komplexen Netzen ist es jedoch möglich, daß mehrere ELANs auf demselbenATM-Netz betrieben werden und ein LECS für alle ELANs benutzt wird. Der LECS kann dann auf-grund der Parameter in der vom LEC an ihn gesendeten LE_CONFIGURE_REQUEST entscheiden, wel-chem ELAN der LEC zugeordnet werden soll. Der LEC muß dazu in der LE_CONFIGURE_REQUEST-Nachricht einige Angaben machen, insbesondere die eigenen ATM-Adresse, die gewünschte SDU-Größe für die zukünftige ELAN-Kommunikation und den gewünschten Typ des emulierten LANs(Ethernet oder TokenRing). Es können daneben noch weitere Angaben gemacht werden, beispiels-weise ob der LEC in der Lage ist, das LANEv2-Protokoll zu unterstützen oder nur das LANEv1-Protokoll. Gibt es mehrere ELANs gleichen Typs, dann kann ein LEC einen ELAN-Namen angeben(sofern bekannt), um seine Preferenz für ein bestimmtes ELAN auszudrücken.

Der LECS antwortet mit einer LE_CONFIGURE_RESPONSE-Nachricht, in der dem LEC die zu ver-wendenen Parameter für die nächsten Phasen mitgeteilt werden. Dies ist insbesondere die Adressedes LES, der ELAN-Typ und ELAN-Name sowie die maximale Rahmengröße, die in diesem ELANverwendet werden darf.

Diese Phase wird abgeschlossen, indem der LEC die ATM-Verbindung zum LECS wieder abbaut. InAbbildung 7-3 sind die bisher diskutierten Phasen noch einmal graphisch dargestellt.

Abbildung 7-3. Lokale LEC Initialisierung und Anfrage an den LECS

110


Initial_State

SETUP ("Parameters for LE Configuration Direct VCC")

CONNECT ()

LE_CONFIGURE_REQUEST ("...,ELAN-Name, Framesize...")

LE_CONFIGURE_RESPONSE ("..., Preferred LES Address,..")

RELEASE

RELEASE_COMPLETE

ein Client

LEC

Initial_State

"local init"

LECS_CONNECT

CONFIGURE

LES_CONNECT

ein Konfigurations-Server

LECS

7.1.1.4. LEC meldet sich beim LES an

Der LECS hat dem LEC die ATM-Adresse des LANE-Servers (LES) mitgeteilt. In der ‘Join’-Phasekontaktiert der LEC den LES, indem er eine bidirektionale ATM-Verbindung zum Austausch von

111


Kontrollinformationen (Control Direct VCC) zum LES aufbaut. In Abbildung 7-4 geschieht diesim Zustand LES_CONNECT.

Der LEC versucht nun, sich im emulierten LAN anzumelden. Auch hierfür ist es erforderlich, be-stimmte Parameter anzugeben, die der LES für Plausibilitätskontrollen verwenden kann. Die Pa-rameter ermöglichen dem LES auch die Auswahl eines geeigneten ELANs für den LEC, falls derLES gleichzeitig mehrere ELANs unterstützt. Die wichtigsten Parameter für diese Auswahl sind derLAN-Typ, falls bekannt der ELAN-Name, die gewünschte Rahmengröße und eine erste lokale MAC-Adresse, die mit der primären ATM-Adresse des Clients für spätere Adreßauflösungen registriertwerden soll. Darüber hinaus können noch weitere Flags angegeben werden, beispielsweise ob die-ser LEC als Proxy für andere nicht registrierte MAC-Adressen als Stellvertreter bei Adreßanfragen(ARP-Anfragen) agiert. In diesem Fall erhält der LEC später ARP-Anfragen vom Server, falls derServer die Anfragen von anderen Clients nicht lokal auflösen kann. Dieser Mechanismus wird z.B.verwendet, wenn ein Ethernet-Switch sich stellvertretend beim LES für alle auf seinen Segmentenbenutzten MAC-Adressen anmeldet. Diese können sich über die Zeit ändern (neue Geräte werdenangeschlossen, andere ausgeschaltet), so daß eine Registrierung aller dieser Adressen beim LES nichtsinnvoll wäre.

Diese Informationenwerden in einer LE_JOIN_REQUEST-Nachricht an den LES gesendet. Dieser ant-wortet mit einer entsprechenden LE_JOIN_RESPONSE-Nachricht, in der dem Client die endgültigenParameter mitgeteilt werden, die für das ELAN benutzt werden sollen (beispielsweise den ELAN-Namen und die maximale Frame-Größe).

Die LE_JOIN_RESPONSE-Nachricht kann entweder über die bereits vom LEC zum LES aufgebau-te Verbindung an den LES zurückgesendet werden oder über eine alternativ vom LES an den LECaufzubauende Control Distribute-Verbindung. Dem Server wird damit die Möglichkeit gege-ben, anstelle mehrerer Kopien der selben Anfrage über alle Kontroll-Verbindungen zu senden, beiBedarf über diese Punkt-zu-Mehrpunkt-Verbindung eine Anfrage an alle LECs zu senden. Schicktder Server seine Antwort über diese neue Verbindung, dann muß der Client auch zukünftig mit weite-ren Kontroll-Nachrichten des Servers über diese Punkt-zu-Mehrpunkt-Verbindung rechnen. Falls derServer die LE_JOIN_RESPONSE-Nachricht jedoch über die Control Direct Verbindung an denClient zurücksendet, dann werden alle zukünftigen Anfragen des Servers an den Client auch überdiese Verbindung eintreffen.

Abbildung 7-4. Registrierung beim LES

112


Join

SETUP("Parameters for LE Control Direct VCC")

CONNECT

LE_JOIN_REQUEST(..., ELAN Name, Client ATM address, LAN Type , Proxy...)

SETUP/ADD_PARTY("Parameters for LE Control Distribute VCC")

CONNECT /ADD_PARTY_ACK

LE_JOIN_RESPONSE(..., ELAN Name, Framesize, LAN Type , ...)

LE_REGISTER_REQUEST(..., Local Unicast MAC Address, ...)

LE_REGISTER_RESPONSE

ein Client

LEC

LES_CONNECT

JOIN

ValidateJoin Response

Init. Registration

BUS Connect

ein LANE-Server

LES

113


7.1.1.5. Initiale Adreßregistrierungen

Nach der Kontaktaufnahmemit dem LES in der JOIN-Phase kann der LEC sofort weitere zusätzlicheAdressen beim LES registrieren. Hierbei handelt es sich um lokale MAC-Adressen des Clients, alsonicht um Proxy-Adressen1. Bei einem LEC, der auf einem Endsystem mit ATM-Schnittstelle instal-liert ist, kann eine solche Adresse beispielsweise zu einer zusätzlich konfigurierten virtuellen MAC-Adresse auf derselben ATM-Schnittstelle gehören. Ein TCP/IP basiertes Endsystem wäre dadurchbeispielsweise in der Lage, mehrere IP-Adressen über diese virtuellen MAC-Adressen zu benutzen.Verschiedene Dienste könnten somit über verschiedene IP-Adressen (und damit verbunden über ver-schiedene DNS-Namen) angeboten werden, obwohl die Maschine nicht ‘multi-homed’ ausgelegt ist.

Diese Phase kann somit entfallen, falls der LEC nur eine einzigeMAC-Adresse registrieren muß. Dieskann bereits mit der oben beschriebenen LE_JOIN_REQUEST-Nachricht in der JOIN-Phase erfolgen.

7.1.1.6. LEC kontaktiert den BUS

Nach der Kontaktaufnahme zum LES kann der LEC die ATM-Adresse des BUS erfragen, indem ereine LE_ARP_REQUEST-Nachricht an den LES sendet und nach der für ‘broadcast LANs’ typischen‘broadcast address’ fragt. Bei dieser MAC-Adresse sind typischerweise alle Adreßbits auf logisch ‘1’gesetzt, also im Falle von Ethernet-Adressen 0xffffffffffff. Diese Adresse ist in herkömmlichen‘broadcast LANs’ ad hoc benutzbar und braucht nicht erfragt zu werden. Bei der LAN-Emulationmußdiese Adresse wie alle anderen MAC-Adressen an eine ATM-Adresse gebunden sein. Diese ATM-Adresse gehört zum ‘broadcast and unknown server, BUS’ und wird, wie jede andere MAC-Adresseauch, beim LES erfragt.

Der Server antwortet im Normalfall unmittelbar mit einer LE_ARP_RESPONSE-Nachricht, da dieATM-Adresse des BUS dem LES immer bekannt ist2. Diese ATM-Adresse benutzt der LEC wieder-um für den ATM-Verbindungsaufbau zum BUS. Der LEC baut die sogenannte Default Multicast

Send Verbindung zum BUS auf. Über diese Verbindung kann der LEC jederzeit alle Dateneinheitensenden, die für die jeweilige ‘broadcast’-Adresse des emulierten LANs bestimmt sind. Der BUS sen-det diese Dateneinheiten dann an alle LECs weiter.

Um nicht jedem Client über seine individuelle Verbindung zum BUS alle Anfragen der anderen Cli-ents senden zu müssen, wird der BUS nach der Kontaktaufnahme zu diesem Client eine oder meh-rere Punkt-zu-Mehrpunkt-Verbindungen aufbauen. Der neue Client wird somit als weiterer Teilneh-mer in die Multicast Forward-Gruppe des BUS aufgenommen. Der Client muß diese Punkt-zu-Mehrpunkt-Verbindungen vom BUS akzeptieren und damit rechnen, daß hierüber beliebige Daten-einheiten anderer Clients eintreffen können (ein Beispiel dafür wird in Abschnitt 7.1.2 gegeben).

Nachdem der BUS eine oder mehrere Multicast Forward-Verbindungen zum LEC aufgebaut hat,ist der LEC einsatzbereit. Zu beachten ist, daß hier die normale, fehlerfreie Anmeldung eines LECdargestellt wurde. Tritt während einer der Phasen ein Fehler auf, muß der LEC einen oder mehre-re dieser Schritte wiederholen. Die Kontaktaufnahme zum BUS ist noch einmal in Abbildung 7-5graphisch dargestellt.

Abbildung 7-5. Registrierung beim BUS

114


Init. Registration

SETUP("Parameters for Default Multicast Send VCC")

CONNECT

SETUP/ADD_PARTY("Parameters for Multicast Forward VCC")

CONNECT /ADD_PARTY_ACK

ein Client

LEC

Determine ATMBUS address

BUS Connect

Operational

ein Broadcast/Unknown-Server

BUS

7.1.2. Typische LEC-KommunikationsabläufeNachdem die Anmeldungwie oben beschrieben erfolgt ist, kann der LECmit anderen LECs desselbenELANs Dateneinheiten austauschen. In diesem Abschnitt werden kurz die typischen Kommunikati-onsabläufe vorgestellt.

Ein LEC muß typischerweise vor dem Versenden von MAC-Dateneinheiten eines ‘legacy’-Protokollsan einen anderen LEC dessen ATM-Adresse bestimmen. Danach wird eine direkte Verbindung zumanderen LEC aufgebaut und die MAC-Dateneinheiten können über diese neue Verbindung übertragenwerden.

115


7.1.2.1. Adreßauflösung bei der LANE

Bevor der LEC seine MAC-Dateneinheiten versenden kann, muß die ATM-Adresse für einen direktenVerbindungsaufbau zumEmpfänger bestimmt werden. Der Empfänger ist ein anderer LEC, der bereitsseine ATM-Adresse beim LES mit seiner MAC-Adresse registriert hat. Für die Adressauflösung wirddaher eine LE_ARP_REQUEST-Anfrage an den LES gesendet. Der LES durchsucht die registriertenEinträge und sendet die zur gesuchten MAC-Adresse gehörende ATM-Adresse zurück an den LEC.Dieser Vorgang ist noch einmal graphisch in Abbildung 7-6 dargestellt.

Abbildung 7-6. Adreßauflösung beim LES

Datentransfer zwischen Clients (1)

LE_ARP_REQUEST

LE_ARP_RESPONSE

Client 1

LEC

Operational

Destination ATMaddress unknown

Setup DataDirect VCC

LE Server

LES

7.1.2.2. MAC-Datenaustausch zwischen zwei LECs

Der LEC kann nun zum eigentlichen Empfänger der MAC-Dateneinheit eine ATM-Verbindung auf-bauen, um darüber ein oder mehrere MAC-Frames zu senden. Der Empfänger muß mit der Annahmeder Verbindung und dem anschließenden Senden der CONNECT-Nachricht so lange warten, bis er be-reit ist, über diese VerbindungMAC-Dateneinheiten zu empfangen. Der Initiator der Verbindung kann

116


unmittelbar nach Erhalt dieser CONNECT-Nachricht mit dem Senden von MAC-Dateneinheiten überdie neue Verbindung beginnen.

Unabhängig davon, ob der Initiator der Verbindung nach Empfang der CONNECT-Nachricht sofort Da-teneinheiten sendet, muß er dem anderen LEC seine Bereitschaft zum Empfang vonMAC-Dateneinheitendurch Senden einer READY_IND-Nachricht mitteilen. Der andere LEC darf nach Empfang dieserNachricht seinerseits LANE-Dateneinheiten mit MAC-Frames an den Initiator senden3.

Der Nachrichtenaustausch für die Eröffnung einer Datenverbindung zwischen zwei LECs ist in Ab-bildung 7-7 noch einmal graphisch dargestellt.

Abbildung 7-7. Kommunikation zwischen zwei LECs

Datentransfer zwischen Clients (2)

SETUP("Parameters for Data Direct VCC")

CONNECT

READY_IND

RELEASE

RELEASE_COMPLETE

Client 1

LEC


Exchange Data

Operational

Client 2

LEC

Über diese Verbindung kann bidirektional kommuniziert werden. Falls der Empfänger seinerseits Da-teneinheiten an den Sender schicken möchte, darf er die bereits vorhandene Verbindung benutzen,kann aber auch eine weitere Verbindung (gegebenenfalls mit anderen Dienstgüteparametern) eröff-

117


nen. Nach dem Senden von Dateneinheiten dürfen beide Kommunikationspartner die Verbindungabbauen. Dies sollte jedoch frühestens nach Ablauf eines (per Vorgabe auf 20 Minuten eingestellten)‘Timeouts’ passieren. Wird zwischenzeitlich wieder eine Dateneinheit gesendet/empfangen, beginntder ‘Timeout’ von neuem.

Da vor dem Aufbau einer direkten Verbindung erst die ATM-Adresse des anderen LEC beim LESnachgefragt werden muß, darf ein LEC, während er auf die Antwort des LES wartet, die ersten Daten-einheiten über den BUS an den anderen LES senden. Diese Vorgehensweise soll die Latenzzeit durchdie Adreßauflösung und den anschließenden Verbindungsaufbau verringern. Möglich ist diese Vorge-hensweise, da jeder LEC auch über eine Verbindung zum BUS verfügen muß, dieser also in jedemFall den anderen LEC erreichen kann, falls dieser im ELAN überhaupt erreichbar ist4. Macht ein LECvon der Möglichkeit Gebrauch, vorübergehend Dateneinheiten über den BUS an einen anderen LECzu senden, dann sollte vor dem Senden über eine parallel dazu aufgebaute direkte Verbindung zumselben Client sichergestellt werden, daß alle bisher über den BUS weitergeleiteten Dateneinheitenbereits beim Empfänger angekommen sind. So kann vermieden werden, daß nachfolgende Datenein-heiten über die direkte Verbindung die bereits an den BUS gesendete Dateneinheiten für denselbenEmpfänger überholen. Hierfür wird das sogenannte ‘Flush’-Protokoll eingesetzt, das in Abbildung7-8 dargestellt ist.

Abbildung 7-8. Kommunikation über BUS mit anschließendem ‘Flush’-Protokoll

118


Datentransfer zwischen Clients (1), mit Flush

LE_ARP_REQUEST

Daten auf Multicast Send VCC

Daten

LE_ARP_RESPONSE

LE_FLUSH_REQUEST(..., Transaction ID, destination ATM address, ...)

LE_FLUSH_RESPONSE

Daten

Daten

LE_FLUSH_REQUEST

LE_FLUSH_RESPONSE

Client 1

LEC

Operational

Destination ATMaddress unknown


ein Broadcast/Unknown Server

BUS

Client 2

LEC

Während der LEC die Adresse des Empfängers beim LES anfragt, eventuell auch noch währenddes anschließenden Verbindungsaufbaus zum Empfänger, werden bereits Daten über den BUS an denEmpfänger gesendet. Der BUS kann für dieWeitervermittelung,wie in der Abbildung dargestellt, auchdie Punkt-zu-Mehrpunkt-Verbindung zu den LEC benutzen, so daß andere Clients gegebenenfallsauch die Dateneinheiten empfangen.

Wann immer der Client sich versichern will, daß keine bisher gesendeten Dateneinheiten mehr aufdem Weg zwischen BUS und Empfänger sind, sendet er eine FLUSH_REQUEST-Nachricht über denBUS an den Empfänger. Der Empfänger sendet als Antwort eine FLUSH_RESPONSE-Nachricht zu-rück. Da es sich hierbei um eine reine Kontroll-Nachricht handelt, wird diese Nachricht jedoch überden LES an den Kommunikationspartner zurückgesendet5.

119


7.2. AngriffsmöglichkeitenWie die obige Darstellung verdeutlicht hat, ist die LANE im direkten Vergleich zu CLIP deutlichkomplexer. Diese Komplexität wirkt sich in zwei Bereichen besonders mißlich aus. Zum einen leidethierunter die Leistungsfähigkeit bei der Datenübertragung. Dieser Aspekt spielt hier nur eine unter-geordnete Rolle und wird nicht weiter betrachtet. Zum anderen steigt durch die höhere Komplexitätauch das Fehler- und Sicherheitsrisiko.

Bei CLIP wurden bereits bei nur einem Dienst (ATMARP-Dienst) viele Schwächen und Angriffs-möglichkeiten aufgedeckt. Es ist zu befürchten, daß durch die drei Dienste bei der LAN-Emulationnoch mehr potentielle Sicherheitsprobleme bestehen. Der folgende Abschnitt diskutiert daher die An-griffsmöglichkeiten auf den LECS, den BUS und den LES. Im darauf folgenden Abschnitt werdendie Möglichkeiten diskutiert, einen LEC anzugreifen.

7.2.1. Angriffe auf die DiensteDie Angriffe auf die Dienste entsprechen in wesentlichen Zügen den bereits diskutierten Angriffenauf einen ATMARP-Server. Auch bei der LAN-Emulation sind DoS-Angriffe besonders geeignet, umdie Server und somit den LANE-Dienst als solchen anzugreifen.

7.2.1.1. DoS-Angriff auf einen BUS

Der „Broadcast and Unknown Server“ (BUS) ist in großen ELANs ohnehin ein potentieller Engpaß.Falls viele Proxy-LECs an einem ELAN partizipieren, dauern die Adreßauflösungen über den LES beiAnfragen nach einer nur dem Proxy bekannten Adresse relativ lange. Senden die anfragenden Clientsin der Zwischenzeit alle über den BUS, um die Latenzzeit bei der Datenübertragung zu verringern,kann dieses normale Verhalten bereits zu einer erheblichen Belastung des BUS führen.

Dieser potentielle Engpaß kann von einem Angreifer ausgenutzt werden, um die Leistungsfähigkeiteines ELANs durch Überlasten des BUS zu verringern. Hierzu ist es lediglich erforderlich, über eineVerbindung zum BUS (vgl. Abschnitt 7.1.2.2) schnell aufeinanderfolgend Dateneinheiten zu sen-den, die der BUS dann weiterleiten muß. Es kann sich hierbei sowohl um Unicast- als auch umMulticast-Dateneinheiten handeln. Typischerweise wird ein BUS bei bekannten Emfangsadressen diejeweilige Default Multicast Send Verbindung zum passenden LEC für das Weiterleiten der Da-teneinheiten benutzen. Bei unbekannten Empfangsadressen wird er hingegen über den Multicast

Forward-SVC senden, so daß die Dateneinheiten des Angreifers von anderen LECs ebenfalls emp-fangen werden können.

7.2.1.2. DoS-Angriff auf einen LES

Da der LES für die Bearbeitung aller Adreßauflösungen im ELAN zuständig ist, muß dieser Serversehr leistungsfähig sein. Er muß zu jedem LEC im ELAN eine ATM-Verbindung aufrechterhaltenund über jede dieser Verbindungen möglichst viele Anfragen pro Sekunde beantworten.

120


Ein Angreifer hat zwei Möglichkeiten, den LES zu belasten. Einerseits kann er versuchen, selber vielezusätzliche MAC-Adressen zu reservieren. Die Verarbeitung dieser zusätzlichen Reservierungswün-sche in der Phase „Init. Registration“ (vgl. Abschnitt 7.1.1) stellt eine zusätzliche Belastung des LESdar, weil für jede weitere MAC-Adresse, die der Angreifer angibt, in einer Datenbank ein Verweis aufdie dazugehörende ATM-Adresse eingetragen werden muß. Zusätzlich sollten robust implementierteLES die Adressen vor dem Eintragen dahingehend überprüfen, ob sie konform mit der zu unter-stützenden Netztechnologie sind6 und ob die Adresse nicht schon anderweitig vergeben ist. DiesePlausibilitätskontrollen belasten den LES zusätzlich.

Die zweite Möglichkeit, einen LES zu belasten, ist das häufige Anfragen von Adressen. Ein Angreiferwürde möglichst nach nicht verwendetetenAdressen fragen, da der LES in diesem Fall keinen Cache-Eintrag finden kann und somit die vergleichsweise aufwendigen Anfragen an die bei ihm registriertenProxy-LECs stellen muß, da diese die unbekannten Adressen möglicherweise kennen könnten. Fürjede an einen Proxy-LEC gestellte Anfrage sind natürlich Kontextinformationen zu verwalten, bei-spielsweise Timer, die bei Ausbleiben einer Antwort ablaufen.

7.2.2. Angriffe auf die ClientsEs gibt eine Vielzahl von Angriffsmöglichkeiten auf einzelne LECs. Neben DoS-Angriffen gibt eshier wiederum die Möglichkeit für „Spoofing“ und sogar für „Man-in-the-Middle“-Angriffe. Die hiervorgestellten Angriffe sind nicht immer einem bestimmten Typ zuzuordnen, da die LANE aufgrundihrer Komplexität durch ein und den selben Angriff in mehrfacher Hinsicht bedroht ist. Die Über-schriften der folgenden Klassifikation benennen daher gegebenenfalls nur Teilaspekte eines Angriffs.

7.2.2.1. Angreifer manipuliert die LECS-Konfiguration (DoS)

Im Zuge der LEC-Initialisierung (vgl. Abschnitt 7.1.1) gibt es die Möglichkeit, daß der LEC dieAdresse des LECS mit Hilfe des ILMI-Protokolls (vgl. Abschnitt 4.1) vom Switch erfragt. Falls es ei-nem Angreifer gelingt, den Switch zu kompromittieren und hier eine nicht existierende ATM-Adresseals LECS-Adresse einzutragen, kann kein an diesem Switch angeschlossener LEC mehr in ein ELANaufgenommen werden. Dieser Angriff ist besonders beim Einsatz von Proxy-LECs brisant, da so ge-gebenenfalls ganze Subnetze nicht mehr an ein ELAN angeschlossen werden können.

7.2.2.2. Angreifer manipuliert die LECS-Konfiguration (MiM)

Dieser Angriff erfolgt analog zum gerade diskutierten Vorgehen. Anstelle einer im ATM-Netz nichtvorhandenenAdresse konfiguriert der Angreifer als LECS-Adresse jedoch eine Adresse, die zu einemvon ihm kompromittierten (LECS)-Server gehört. Dann sind folgende Möglichkeiten gegeben:

Angreifer erfährt die verschiedenen ELAN-Parameter

121


Die an dem kompromittierten Switch angeschlossenen LECs würden eine Verbindung zum ver-meintlichen LECS aufbauen und über diese Verbindung nach ihrem LES fragen. Dazu über-mitteln sie gegebenenfalls den Namen und/oder die ID des gewünschten ELANs aber auch dieeigene ATM-Adresse (vgl. Abschnitt 7.1.1.3). Hierdurch erfährt der Angreifer die verschiedenengültigen ELAN-Parameter für weitere Angriffe.

Denkbar wäre beispielsweise, daß der Angreifer versucht, sich mit diesen Informationen selberim ELAN anzumelden. In jedem Fall erfährt er aber ATM-Adressen von potentiellen ELAN-Mitgliedern, die er zum „Spoofen“ der eigenen Adressen bei direkten Verbindungen zu anderenMitgliedern dieses ELANs verwenden kann.

Angreifer konfiguriert LECs mit falscher LES-Adresse

Der Angreifer kann einen Schritt weiter gehen und sich wie ein richtiger LECS verhalten. Fallses nur sein Ziel war, die oben genannten Konfigurationsparameter von Clients für spätere An-griffe zu sammeln, kann der Angreifer in diesem Schritt die LES-Adresse des für das ELANzuständigen LES an den LEC zurücksenden. Der LEC würde sich dann beim LES anmelden.

Der vom Angreifer installierte LECS könnte hingegen auch die Adresse eines ebenfalls vomAngreifer kontrollierten LES an die LECs senden. In diesem Fall hätte der Angreifer alle Mög-lichkeiten für weitere „Man-in-the-Middle“-Angriffe. Es sollte bereits ersichtlich sein, daß dervom Angreifer kontrollierte LES alle Möglichkeiten zur Manipulation der Datenübertragung imELAN hat, da er bei Adreßanfragen jederzeit Adressen angeben kann, die zu weiteren kompro-mittierten Systemen gehören. In Abbildung 7-9 ist dieser Angriff noch einmal als Zeit-Ablauf-Diagramm dargestellt.

Abbildung 7-9. MiM-Angriff ermöglicht durch kompromittierten LECS

122


lane_mim_attack

LEC erfragt Adressedes LECS mithilfe

des ILMI-Protokolls

Switch gibt Adresseeines vom Angreiferkontrollierten LECS

zur�ck

LEC erfragt LES-Adresse

LECS gibt Adresse einesvom Angreifer kontrollierten

LES zur�ck

kompromittierterSwitch

SWITCH

Ein Client

LEC

LECS_CONNECT

CONFIGURE

LES_CONNECT

JOIN

LECS des Angreifers

LECS

LES des Angreifers

LES

7.2.2.3. Angreifer benutzt BUS für Spoofing

123


Ein Angreifer baut eine Verbindung (Typ: Multicast Send) zum BUS auf. Falls der BUS eine Vali-dierung der ATM-Adresse vornimmt, muß eine ATM-Absender-Adresse verwendet werden, die zu ei-nem angemeldeten LEC gehört. Danach kann der Angreifer beliebige MAC-Frames an den BUS sen-den, die dieser an alle LECs über die Multicast Forward Verbindung weiterleitet. Dieser Angriffist vielversprechend, da die anderen LECs normalerweise keine Überprüfung von MAC-Absender-Adressen vornehmen, die in vom BUS gesendeten Dateneinheiten vorkommen. Der Angreifer hatsomit die Möglichkeit, den BUS zum Fälschen seiner Absenderadresse zu mißbrauchen.

Falls der BUS keine Validierung der vom Angreifer verwendeten ATM-Adresse durchführt, kann einAngreifer mit einer beliebigen von ihm am Switch reservierten Adresse eine Verbindung zum BUSaufbauen. Der BUS wird daraufhin den Angreifer in seine Multicast ForwardGruppe aufnehmenund auch ihm alle „Broadcast“-Nachrichten sowie weitere „initiale Unicast“-Nachrichten zusenden.Der Angreifer kann dadurch die Kommunikation innerhalb des ELANs teilweise abhören.

7.2.2.4. Angreifer benutzt LES für DoS-Angriff auf LEC

Ein Angreifer kann versuchen, anstelle eines anderen LEC in ein ELAN aufgenommen zu werden.Der Angreifer muß dazu versuchen, die Anmeldung beim Server durchzuführen und im Zuge derinitialen Adreßregistrierung (vgl. Abschnitt 7.1.1.5) die IP-Adresse des Clients (der an der Kommu-nikation gehindert werden soll) für sich zu beanspruchen. Der LEC könnte sich anschließend mitdieser Adresse nicht mehr im ELAN anmelden. Hieraus resultiert typischerweise ein DoS für denbetroffenen Client, da Clients in der Regel zwar die Möglichkeit haben, eine andere MAC-Adressefür eine erneute Anmeldung zu wählen, die zu verwendene IP-Adresse aber meist nicht dynamischsondern statisch auf den LECs konfiguriert ist.

7.3. GegenmaßnahmenBei der LAN-Emulation kann man durch vorsichtige, restriktive Konfiguration der Server und derbeteiligten ATM-Switches einige der obigen Angriffe verhindern oder zumindest abschwächen. Es istjedoch auch im Falle der LAN-Emulation erforderlich, teilweise herstellerspezifische und somit pro-prietäre Maßnahmen zur Absicherung einzusetzen. Derartige Beispiele werden wiederum für Kom-ponenten der Firma CISCO diskutiert.

7.3.1. Angriffe auf die Dienste abschwächenDie LAN-Emulation spezifiziert keine eigenen Mechanismen, um den oben dargestellten Mißbrauchzu unterbinden. In diesem Abschnitt werden die erforderlichen Gegenmaßnahmen dargestellt, die dieAuswirkungen der oben beschriebenen Angriffe zumindest abmildern können.

7.3.1.1. Verringern der Auswirkungen von DoS auf den BUS

124


Ein Angreifer, dem es gelingt, einen LEC zu imitieren und eine Verbindung zum BUS aufzubauen,kann den oben beschriebenen DoS-Angriff leicht durchführen. Es ist daher für eine Absicherung derLANE unbedingt erforderlich, administrativ festzulegen, wer sich überhaupt in einem bestimmtenELAN anmelden darf. Ähnlich wie bei der Absicherung des ATMARP-Servers ist ein Wissen derDienste über die potentiellen Teilnehmer die Grundlage für eine Absicherung der LAN-Emulation.

In diesem Sinne darf ein Zugriff auf den BUS nur von LECs aus erfolgen, die sich vorher im jewei-ligen ELAN angemeldet haben. Eine erfolgreiche Anmeldung sollte die Grundvoraussetzung für dieKommunikation mit dem BUS sein. Diese Zugriffskontrolle muß der BUS selbst durchführen, undkann mehrstufig erfolgen:

1. Der LEC baut eine Default Multicast Send-Verbindung zum BUS auf. Der BUS sollte andieser Stelle verifizieren, ob in dem von ihm unterstützten ELAN ein LEC mit dieser Adressebeim LES angemeldet ist. Ist dies nicht der Fall, kann von einem Angriff ausgegangen werden,da der LEC während der Initialisierung (vgl. Abschnitt 7.1.1) immer erst eine Anmeldung beimLES durchführen muß.

2. Ist die erste Überprüfung erfolgreich, sollte geprüft werden, ob von dem LEC mit dieser Absen-deradresse bereits eine Verbindung existiert. Auch in diesem Fall kann von einem Angriff ausge-gangen werden. Auf einer der beiden Verbindungen wurde eine falsche ATM-AbsenderadressebeimVerbindungsaufbauverwendet, da ein LEC genau eine Default Multicast Send-Verbindungzum BUS aufbaut.

3. Handelt es sich um einen LANEv2-Client, muß dieser vom BUS eine Multicast Forward-Verbindung entgegen nehmen. Falls es dem BUS nicht gelingt, diese Verbindung zum LEC auf-zubauen, handelt es sich vermutlich auch um einen Angriffsversuch.

4. Während der drei erstgenannten Überprüfungen sollten alle Dateneinheiten, die der LEC zwi-schenzeitlich über die Default Multicast Send-Verbindung zum BUS sendet, vom BUSignoriert (also mit minimalem Aufwand bearbeitet) werden.

Die vorgeschlagenen Maßnahmen helfen jedoch nicht, falls Endgeräte an einem Proxy-LEC für den„Broadcast“-Sturm verantwortlich sind. Alle Anfragen von legitimen LECs werden vom BUS verar-beitet. Ein maliziöser Rechner, der über eine Ethernet-Schnittstelle an einem solchen „Edge-Device“(Proxy-LEC) angeschlossen ist, könnte bis ca. 140.000 (bei Fast Ethernet) „Broadcasts“ pro Sekundeversenden und so den BUS erheblich belasten. Hierauf wird in Abschnitt 7.3.1.3 noch einmal nähereingegangen.

Außerdem ist zu beachten, daß der BUS den LES nur mit herstellerspezifischen Protokoll-Erweiterungenkontaktieren kann, da dies in dem LANE-Standard nicht vorgesehen ist (vgl. Beispiel 7-1).

7.3.1.2. Verringern der Auswirkungen von DoS auf den LES

Im letzten Abschnitt wurde argumentiert, daß der BUS eine schwache Zugriffskontrolle erreichenkann, wenn er vor dem Verarbeiten von Dateneinheiten, die über eine neue Default Multicast

Send-Verbindung eintreffen, die Absenderadresse der dazugehörenden ATM-Signalisierung beim

125


LES validiert. Dadurch wird das eigentliche Problem der Authentifizierung von LECs gegenüber denanderen LANE-Diensten letztendlich nur auf den LES verschoben. Dieser Umweg ist jedoch dadurchzu rechtfertigen, daß im Zuge der LEC-Anmeldung beim LES mehr Informationen vorliegen, die füreine Zugriffskontrolle verwendet werden können.

Im Zuge der LEC-Initialisierung sollte der LES die Angaben des LEC prüfen, und der Aufnahme indas emulierte LAN nur dann zustimmen, wenn die Angaben, die der LEC macht, mit den vorher amLES konfigurierten Angaben übereinstimmen. Wie auch schon bei der Absicherung des ATMARP-Dienstes (vgl. Abschnitt 5.3.1) gezeigt wurde, ist dies nur durch eine aufwendige, manuelle Kon-figuration möglich. Folgende Schritte sind auf dem LES möglichst durchzuführen, um wenigstensrudimentäre Plausibilitätskontrollen durchführen zu können:

1. Für jeden potentiellen LANE-Client sollte vor der Inbetriebnahme eine möglichst statische Kon-figuration der wichtigsten ELAN-Parameter auf dem Server erstellt werden. Die primäre ATM-Adresse des LEC und die von ihm für die Anmeldung zu benutzende MAC-Adresse solltenstatisch konfiguriert werden. Zusätzliche Angaben wie Rahmengröße, LAN-Typ und eventuellweitere, von diesem Client anforderbare Adressen, sollten ebenfalls statisch konfiguriert werden.Falls möglich sollte auch konfiguriert werden, ob der jeweilige Client als Proxy-LEC fungie-ren darf. All diese Angaben können für die Plausibilitätkontrolle im nächsten Schritt verwendetwerden.

2. Baut ein LEC eine Control Direct-Verbindung zum LES auf, muß der LES prüfen, ob die inSchritt 1 gemachtenAngaben vom Client für die Anmeldung verwendet werden. Der Client solltein der LE_JOIN_REQUEST-Nachricht alle Angaben entsprechend der Konfiguration des Serversmachen. Bei Abweichungen kann von einemAngriff ausgegangenwerden. Die Verbindung solltedann abgelehnt werden.

3. Der LES prüft zusätzlich, ob bereits eine Registrierung mit diesen Parametern vorliegt. Auch indiesem Fall kann von einem Angriff ausgegangen werden. Die Verbindung (und somit auch dieRegistrierung) sollte abgelehnt werden.

4. Falls es dem LES nicht gelingt, eine Control Distribute-Verbindung zum Client aufzu-bauen, sollte die Control Direct-Verbindung ebenfalls abgebaut werden. In diesem Fall hatein Angreifer versucht, sich mit den (möglicherweise abgehörten oder geratenen) Angaben ei-nes legitimen LEC und dessen ATM-Adresse beim Server anzumelden. Da der eigentliche Clientaber bisher nicht angemeldet ist (sonst wäre der Versuch bereits in 3 aufgefallen), scheitert dieEröffnung der Verbindung zum legitimen Client in diesem Moment. Falls es dem Angreifer je-doch gelungen sein sollte, mit Hilfe des ILMI-Protokolls die Adresse eines legitimen LECs aufseiner ATM-Schnittstelle zu reservieren, dann würde auch dieser Verbindungsaufbau erfolgreichsein, da der Angreifer nun auf den Verbindungswunsch des LES antworten kann. Auch bei derLAN-Emulation sollte daher die Signalisierung so weit wie möglich mit den Mechanismen ausAbschnitt 4.2.3 eingeschränkt werden.

Die folgenden Beispiele (Beispiel 7-1 bis Beispiel 7-3) zeigen die Konfigurationsschritte für die Ein-richtung eines LES/BUS-Paares auf einem CISCO-WS5000-Switch. Durch die Koppelung der lo-gischen Komponenten BUS und LES auf einer physikalischen Komponente ist die Zugriffskontrolle

126


möglich, die in Abschnitt 7.3.1.1 diskutiert wurde. Der BUS validiert hier in der Tat, ob sich ein Clientmit der jeweiligen ATM-Adresse zuvor beim LES angemeldet hat. Der LES verläßt sich seinerseitsauf die Datenbank des LECS. Wird dort ein ELAN als restricted definiert, dann dürfen nur LECsdem ELAN beitreten, die vorher mit ihrer ATM-Adresse in die Datenbank aufgenommen wurden.

Beispiel 7-1. LECS-Datenbank konfigurieren

ATM(config)#lane database fwl3-baseATM(lane-config-database)#name fwl3 server-atm-address \

47.00918100000000E0F7DF1901.00900CCB5432.03 restrictedATM(lane-config-database)#client-atm-address \

47.0091.8100.0000.00e0.f7df.1901.0800.2098.4d70.00 na-me fwl3ATM(lane-config-database)#client-atm-address \

47.0091.8100.0000.00e0.f7df.1901.0800.2098.4d60.00 na-me fwl3ATM(lane-config-database)#client-atm-address atmadresse name elannameATM(lane-config-database)#^Z

In dem Beispiel wird eine LECS-Datenbank mit dem Namen „fwl3-base“ angelegt. Danach wird einELANmit dem Namen „fwl3“ vereinbart, das vom LES verwaltet wird, der die hinter dem Schlüssel-wort server-atm-address angegebene Adresse hat. Das Schlüsselwort resticted deutet an, daßnur die nachfolgenden LECs in das ELAN „fwl3“ vom LES aufgenommen werden dürfen. Danachwerden zwei LECs mit ihren ATM-Adressen in die Datenbank eingetragen. Die Einträge bedeuten,daß ein LEC mit einer der angegebenen ATM-Adressen in das ELAN mit dem angegebenen Namen(hier „fwl3“) aufgenommen werden darf. Alle potentiellen Clients mit anderen als den angegebenenATM-Adressen dürfen nicht in das ELAN aufgenommen werden.

Die Implementation von CISCO unterstützt nicht die Festlegung des ELAN-Typs in der LECS-Datenbank. Die Clients müssen somit den richtigen Namen eines zu ihnen passenden ELANs kennen,um vom LECS an einen LES weitervermittelt zu werden, der den gewünschten ELAN-Typ emuliert.

Beispiel 7-2. LECS aktivieren

ATM(config)#interface atm0ATM(config-if)#lane config fwl3-baseATM(config-if)#lane config auto-config-atm-addressATM(config-if)#^ZATM#show lane config briefLE Config Server ATM0 config table: fwl3-base

Admin: up State: operational

LECS Mastership State: active master

list of global LECS addresses:

47.00918100000000E0F7DF1901.00900CCB5433.00

ATM Address of this LECS: 47.00918100000000E0F7DF1901.00900CCB5433.00 (auto)

127


Es wird ein LECS auf einer ATM-Schnittstelle gestartet, der die Konfigurationsinformationen gemäßder voher unter dem Namen „fwl3-base“ angelegten Datenbank verwaltet. Das Schlüsselwort auto-config-atm-address legt fest, daß dieser LECS unter der ATM-Adresse zu erreichen ist, die derlokalen ATM-Schnittstelle vom ATM-Switch mittels ILMI-Protokoll (vgl. Abschnitt 4.1) mitgeteiltwurde. Der letzte Befehl dient zum Anzeigen dieser automatisch zugeordneten Adreßinformationen.

Beispiel 7-3. LEC/BUS einrichten

ATM(config)#interface atm 0.3 multipointATM(config-subif)#lane server-bus ethernet fwl3 elan-id 3ATM(config-subif)#lane config-atm-address \

47.00918100000000E0F7DF1901.00900CCB5433.00ATM(config-subif)#^Z

Auf der logischen Schnittstelle 0.3wird ein LES/BUS Paar eingerichtet. Die beiden Server sollen dasELAN „fwl3“ mit der ELAN-ID „3“ verwalten. Dem LES wird mit dem letzten Befehl die Adressedes LECS mitgeteilt. Dies ist die Adresse, die mit dem letzten Befehl aus Beispiel 7-2 ausgegebenwurde. Die Wahl der ATM-Adressen für BUS und LES auf diesem Subinterface ist grundsätzlich frei.Wird wie hier keine Angabe gemacht, verwendet der LES/BUS den Switch-Prefix mit den Vorgabe-werten (Default-Werten) der Schnittstellen und Setzen des SEL-Wertes auf die logische Schnittstel-lennummer (hier SEL=03).

7.3.1.3. Abschwächen der Proxy-LEC-basierten DoS-Angriffe aufBUS/LES

Ungelöst ist bisher das Problem der DoS-Angriffe auf BUS und LES durchmaliziöse Rechner, die mitHilfe von Proxy-LECs die LANE-Dienste übermäßig belasten. Typische Proxy-LECs sind Ethernet-Switches, die über eine ATM-Schnittstelle an einen ATM-Backbone angeschlossen werden und mitHilfe der LAN-Emulation lokale (Ethernet-)VLANS über das ATM-Netz ausdehnen.

Diese Proxy-LECs sind selbstverständlich legitime ELAN-Clients und werden in das ELAN aufge-nommen. Gibt es nun ein oder mehrere maliziöse Rechner, die in einem solchen Ethernet-VLANangeschlossen sind, können sie mit normalen ARP-Anfragen den LES mittelbar über den Proxy-LEC belasten oder durch gehäufte „Broadcasts“ wiederum mittelbar über den Proxy-LEC den BUSbelasten. Diese Vorgehensweise ist wiederum nur durch herstellerspezifische Gegenmaßnahmen ein-zuschränken.

Das folgende Beispiel zeigt, wie solchen Angriffen begegnet werden kann. Auf dem Proxy-LECmüssen die Ethernet-Schnittstellen derart konfiguriert werden, daß die Anzahl der zulässigen „Broad-casts“ eine bestimmte obere Schranke nicht überschreitet. Beispielsweise wird konfiguriert, daß ma-ximal ein Prozent der verfügbaren Übertragungskapazität für „Broadcasts“ verwendet werden darf.An diese Schnittstelle angeschlossene Endsysteme bzw. Subnetze könnten dann nur noch mit maxi-mal 1 Megabit pro Sekunde „Broadcasts“ an das ELAN weiterreichen. Treffen mehr als die erlaubten„Broadcasts“ (gemessen in Megabit/s) an einer der angegebenen Ethernet-Schnittstellen des Proxy-LECs ein, werden diese Dateneinheiten verworfen.

128


Beispiel 7-4. Broadcast via Proxy-LEC eindämmen

Etherman2> (enable) set port broadcast 2/1-24 1%Port 2/1-24 broadcast traffic limited to 1%.

In dem Beispiel wird angenommen, daß die Ports 1 bis 24 auf dem Modul 2 alle zu dem VLANgehören, das der Switch als Proxy-LEC im ELAN vertritt. Zu beachten ist hierbei, daß durch einen„verteilten“-Angriff (Distributed Denial of Service, DDoS), bei dem alle angeschlossenen Rechnerdieses VLAN-Segmentes kooperieren, immerhin noch bis zu 24 Megabit/s „Broadcast“-Verkehr überden Proxy-LEC an BUS/LES abgegeben werden können.

7.3.2. Angriffe auf die Clients abschwächenAngriffe auf einzelne Clients in einem ELAN sind sicherlich nicht so brisant wie die Angriffe auf dieKommunikationsinfrastruktur (hier die LANE-Server). Trotzdem sollten auch einzelne LECs best-möglich gesichert werden, insbesondere dann, wenn dies durch globale Konfigurationsmaßnahmenerreicht werden kann, so daß davon alle LECs profitieren.

7.3.2.1. Angriffe basierend auf kompromittierten LECS verhindern

Die in Abschnitt 7.2.2.1 und Abschnitt 7.2.2.2 vorgestellten Angriffe basieren darauf, daß den LECsfalsche Informationen bezüglich ihres LECS gegeben werden. Es gibt die folgenden drei Möglichkei-ten, die Adresse des LECS festzulegen:

1. Durch lokale Konfiguration ist die Adresse des LECS auf den einzelnen Clients eingetragen.Dies ist eine aufwendige aber sichere Möglichkeit, den richtigen LECS festzulegen. Angreifernbliebe nur noch die Möglichkeit, in den jeweiligen Client einzubrechen, um die Konfigurationzu ändern. Die Absicherung der einzelnen Rechner kann dies verhindern, mehr dazu in DFN00,DaS96.

Die folgenden Absicherungsmaßnahmen sollten jedoch zusätzlich durchgeführt werden, um zuverhindern, daß die Clients beim Ausfall des LECS über eine der alternativen Möglichkeiten(s.u.) eine möglicherweise gefälschte LECS-Adresse erlangen.

2. Durch das ILMI-Protokoll teilt der Switch den LECs die Adresse eines oder mehrerer LECS mit.Die LECs müssen nicht einzeln konfiguriert werden. Es ist jedoch erforderlich, auf jedem Switchdie Adressen der potentiellen LECS einzutragen. Wie in allen bisherigen Beispielen setzt auchdiese Vorgehensweise voraus, daß die ATM-Switche selber abgesichert sind. Der Administratorkonfiguriert dann auf allen Switches die Adressen der LECS (in derselben Reihenfolge):

Beispiel 7-5. Konfigurieren von LECS-Adressen auf den ATM-Switches

hurricane(config)#atm lecs-address-default \

129


47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5433.00hurricane(config)#atm lecs-address-default \

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5533.00hurricane(config)#atm lecs-address-default \

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5633.00hurricane(config)#exithurricane#show atm ilmi-configurationLECS Address(es):

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5433.00

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5533.00

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5633.00

Auch in diesem Fall sollten die Konfigurationsschritte aus dem folgenden Beispiel zusätzlichverwendet werden, da ein Client eventuell erst versucht, die „well-known-address“ anzusprechen.

3. Durch eine Verbindung zu einer „well-known-address“ erreichen die Clients den LECS. Unab-hängig davon, ob der Administrator die LECS-Adressen auf jedem Client statisch konfiguriert hatoder wie eben dargestellt, das ILMI-Protokoll dafür verwenden möchte, sollte er zusätzlich da-für sorgen, daß die „well-known-address“ (eigentlich sind es zwei) tatsächlich von seinen LECSreserviert werden.

Falls dies nicht geschieht, könnte ein Angreifer diese Adressen für einen maliziösen LECS reser-vieren. Es wäre von der Implementation der LEC-Software auf den Endgeräten und Proxy-LECsabhängig, ob sie tatsächlich die konfigurierten Adressen, die ILMI-basierten Adressen oder viel-leicht doch die „well-known-addresses“ verwenden. Man sollte sich nicht darauf verlassen, daßeine Implementation die „well-known-address“ zuletzt versucht! Das gleiche gilt für LES undBUS, die möglicherweise auch eine Verbindung zum LECS aufbauen möchten (proprietäre Er-weiterung).

Auch in diesem Fall kann man sich mit den Mechanismen aus Abschnitt 4.1.4.2 behelfen. Le-diglich die Switch-Ports, an die ein LECS angeschlossen ist, sollten die Möglichkeit haben, eine„well-known-address“ zu reservieren.Man erreicht dies, indem auf den Switch-Ports, über die einLECS erreicht werden kann, die beiden Präfixe der „well-known-address“ zusätzlich konfiguriertwerden. Danach wird die Reservierung von ATM-Adressen auf allen Ports auf die konfiguriertenPräfixe eingeschränkt. In Beispiel 7-6 ist dieses Vorgehen dargestellt.

Beispiel 7-6. Verhindern der Reservierung von ‘Well-Known-Adressen’ durch nicht-LECS

Das erste Kommando zeigt die Adressen der konfigurierten LECSs an. In diesem Fall ist nurein LECS konfiguriert. Mit dem zweiten Kommando überzeugt man sich davon, den richti-gen Switch-Port zu kennen, an dem der LECS angeschlossen ist. In diesem Fall ist es der PortATM0/1/1, da dort der LECS seine Adresse reserviert hat (letzte Adresse).

tornado#show atm ilmi-configuration

LECS Address(es):

130


47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5433.00

tornado#show atm ilmi-status atm 0/1/1



ILMI State: UpAndNormal

Peer IP Addr: 192.168.16.246 Peer IF Name: ATM4/0



47.0091.8100.0000.00e0.f7df.1901


47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5430.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5431.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5432.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5433.00 (global)

tornado#

Mit den folgenden Kommandos konfiguriert man für den obigen Port die beiden Präfixe der„well-known-addresses“ und den globalen Switch-Präfix als lokal verwendbar. Das letzte Kom-mando konfiguriert global (auf allen Ports), daß nur noch die konfigurierten Präfixe angemeldetwerden dürfen. Es können also nur noch auf den ausgewählten Ports die „well-known-addresses“reserviert werden.

tornado#config tEnter configuration commands, one per line. End with CNTL/Z.

tornado(config)#interface atm 0/1/1tornado(config-if)#atm prefix C5007900000000000000000000tornado(config-if)#atm prefix 47007900000000000000000000tornado(config-if)#atm prefix 4700918100000000e0f7df1901tornado(config-if)#exittornado(config)#atm ilmi default-access permit matching-prefix

Erneutes Anzeigen der ILMI-Kofiguration für den ausgewählten Port zeigt, daß lokal die beidenPräfixe konfiguriert sind.








47.0091.8100.0000.00e0.f7df.1901

Configured Interface Prefix(s) :

47.0091.8100.0000.00e0.f7df.1901

c5.0079.0000.0000.0000.0000.0000

47.0079.0000.0000.0000.0000.0000


47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5430.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5431.03 (global)

131


47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5432.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5433.00 (global)

Anschließend erweitert man die Konfiguration des LECS, so daß dieser die „well-known-addresses“reserviert.

ATM(config)#interface atm0ATM(config-if)#lane config fixed-config-atm-addressATM(config-if)#^ZATM#show lane configLE Config Server ATM0 config table: fwl3-base

Admin: up State: operational

LECS Mastership State: active master

list of global LECS addresses (26 seconds to update):

47.00918100000000E0F7DF1901.00900CCB5433.00 <----- me

ATM Address of this LECS: 47.007900000000000000000000.00A03E000001.00 (well known)

ATM Address of this LECS: 47.00918100000000E0F7DF1901.00900CCB5433.00

vcd rxCnt txCnt callingParty

851 0 0 47.00918100000000E0F7DF1901.00900CCB5431.03 LES fwl3 0 active

869 0 0 47.00918100000000E0F7DF1901.00900CCB5431.04 LES fwl4 0 active

cumulative total number of unrecognized packets received so far: 0

cumulative total number of config requests received so far: 31338

cumulative total number of config failures so far: 500

Das Beispiel zeigt, daß der LECS neben seiner eigenen Adresse (gekennzeichnet durch <-----me) nun auch eine „well-known-address“ reserviert hat (in diesem Beispiel die der LANEv1).Hiervon sollte man sich noch einmal durch Validieren dieser Reservierung auf dem ATM-Swichtüberzeugen:








47.0091.8100.0000.00e0.f7df.1901

Configured Interface Prefix(s) :

47.0091.8100.0000.00e0.f7df.1901

c5.0079.0000.0000.0000.0000.0000

47.0079.0000.0000.0000.0000.0000


47.0079.0000.0000.0000.0000.0000.00a0.3e00.0001.00 (localNetwork)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5430.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5431.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5432.03 (global)

47.0091.8100.0000.00e0.f7df.1901.0090.0ccb.5433.00 (global)

132


Diese Konfigurationsschritte sind natürlich für alle (redundanten) LECS durchzuführen, die aufden Switches in der ILMI-Konfiguration als solche eingetragen wurden (vgl. Beispiel 7-5).

7.3.3. Weitere GegenmaßnahmenDie Sicherheit läßt sich weiter erhöhen, wenn mit den Mechanismen aus Abschnitt 4.2.3 die Signali-sierung der LECs so eingeschränkt wird, daß nur von bekannten ATM-Adressen (also die, die auch inder LECS-Datenbank eingetragen sind, vgl. Beispiel 7-1) zu den LANE-Diensten signalisiert werdendarf. Dies ist sicherlich mit einem erheblichen Konfigurationsaufwand verbunden, erhöht die Sicher-heit jedoch maßgeblich, falls es keine der hier vorgestellten proprietären, herstellerspezifischen Über-prüfungen gibt. Ein Spoofing über den BUS wird beispielsweise durch die CISCO-Implementierungverhindert, weil der BUS nur Verbindungen von LECs annimmt, die sich zuvor beim LES angemeldethaben. Diese Validierung ist jedoch nur deshalb möglich, weil CISCO die logischen KomponentenBUS und LES immer auf einem physikalischen Gerät zusammenlegt. Falls dies in anderen Imple-mentationen nicht der Fall ist und keine anderen herstellerspezifischen Überprüfungen vorhandensind, dann muß die Signalisierung in jedem Fall weiter eingeschränkt werden.

7.4. Zusätzliche Probleme bei redundanter Auslegungder LANE-Server

Die Spezifikation der LAN-Emulation in der Version 2 erlaubt die redundante Auslegung der bereitseingeführten Server LECS, LES und BUS. Aus der Sicht der LANE-Server wird dabei nach demPrinzip der aktiven Redundanz vorgegangen: Fällt ein Server aus, werden dessen Aufgaben von denanderen Servern dieser Klasse mit übernommen.

7.4.1. Die Sicht des LECDie redundante Auslegung der LANE-Server ist aus Sicht der LECs transparent: Aus der Sicht einesLEC gibt es weiterhin immer nur genau einen LECS, einen LES und einen BUS. Sie führt insbeson-dere zu keinen Veränderungen in den bereits behandelten Aspekten der Kommunikation zwischen denLECs und den LANE-Servern. Ein LEC richtet auch weiterhin seine Anfragen nur an einen Servereiner Klasse. Damit alle Anfragen eines LECs beantwortet werden können, ist es daher notwendig,daß die Server einer Klasse ihre Informationen abgleichen und gegebenenfalls Anfragen weiterleitenkönnen.

133


7.4.2. Redundante Auslegung der LECSJeder aktive LES unterhält eine „Configuration Direct VCC“ zu einem LECS, über die der LES nachfestgelegten Zeiträumen eine Statusmeldung („Keep Alive“ Nachricht) an den LECS versendet. DieLECS geben die so erhaltenen Statusinformationen über ein voll vermaschtes Netz aus „LECS Syn-chronization“ Verbindungen an alle anderen LECS weiter. Dadurch ist es jedem LECS möglich einemLECs in dessen „Configuration Phase“ einen aktiven und nicht bereits ausgelasteten LES in dem ent-sprechenden ELAN zuzuweisen.

7.4.3. Redundante Auslegung der LES und der BUSSeit LANE Version 2 können LES und BUS innerhalb eines ELANs redundant ausgelegt werden.Wie schon in LANE Version 1 wird aber weiterhin jeder LES und jeder BUS für genau ein ELANkonfiguriert. Je ein LES und ein BUS eines ELANs werden einander logisch zugeordnet. LECs, diesich bei einem LES angemeldet haben, heißen lokale Clients des LES und des dem LES logischzugeordneten BUS.

Wie bereits erwähnt hat der LES die Aufgabe der Auflösung vonMAC-Adressen nach ATM-Adressen.LECs registrieren und erfragenAdressen jedoch nur bei dem LES, bei dem sie sich angemeldet haben.Die LES eines ELANs müssen daher ihre Cache-Einträge untereinander abgleichen. Dazu wird das inKapitel 6 eingeführte SCSP verwendet. Die LES unterhalten zu diesem Zweck „Cache Synchroniza-tion“ Verbindungen zu ihren SCSP-Nachbarn. Die Liste der Nachbarn bekommen die LES von demLECS, zu dem sie ihre „Configuration Direct“ Verbindung unterhalten.

Des weiteren sind alle LES eines ELANs über „Control Coordinate“ Verbindungen voll vermaschtverbunden. Über diese Verbindungen werden z.B. von lokalen LECs erhaltene „LE_ARP Requests“nach lokal nicht registrierten Adressen verbreitet.

Jeder BUS eines ELAN unterhält zu allen lokalen LECs und zu allen anderen BUS des ELANs „Mul-ticast Forward“ Verbindungen. Die LANE-Spezifikation in der Version 2 setzt voraus, daß jeder BUSZugriff auf die Datenbasis des ihm zugeordneten LES hat, definiert aber nicht, wie dieser Zugrifferfolgen soll (implementationsspezifisch). Der Zugriff auf die Datenbasis des LES versetzt den BUSin die Lage, die von lokalen LECs gesendeten Pakete von solchen Paketen zu unterscheiden, dievon anderen BUS des ELANs gesendet wurden. Die Pakete können somit in Abhängigkeit von ihrerHerkunft verarbeitet werden.

7.4.4. Selective Multicast ServerDer „SelectiveMulticast Server“ (SMS) wurde mit LNNI Version 2 eingeführt und entlastet die BUSsdadurch, daß er das Senden von „Multicast“-Paketen übernimmt. Hierfür verwendet der SMS Teil-funktionalitäten von LES (Abgleich der Registrierungsdaten per SCSP) und BUS (Verteilen über„Multicast Send VCC“). ObMulticast-Pakete von einem BUS oder SMS verbreitet werden, wird vomLES bei der Auflösung der Multicast-MAC-Adresse entschieden. Ein LEC kann einen SMS nicht von

134


einem BUS unterscheiden und verhält sich gegenüber dem SMS somit genauso wie gegenüber einemBUS.

7.4.5. AngriffsmöglichkeitenDer Verbund der LES und SMS kann dadurch gestört werden, daß ein Angreifer eine Verbindung zumLECS aufbaut und sich als LES bzw. SMS ausgibt. Der Angreifer ist dann ein Knoten im Netz derServer und kann SCSP-spezifische Angriffe ausführen. Die Möglichkeiten hierfür wurden bereits inKapitel 6 bei der Vorstellung des SCSP dargestellt.

Ein den SCSP-spezifischen Angriffen sehr ähnlicher Angriff kann auch auf der Ebene der LECSdurchgeführt werden. Werden die Adressen der LECS dynamisch über ILMI verwaltet, besteht füreinen Angreifer die Möglichkeit, die Adressen der anderen LECS per ILMI zu erfragen und sichin das voll vermaschte Netz der LECS einzugliedern. Dadurch wird der Angreifer über alle aktivenLESs und SMSs informiert und ist nun in der Lage, falsche Meldungen über die aktiven Server zuverbreiten.

7.4.6. GegenmaßnahmenUm zu verhindern, daß sich ein Angreifer als LES oder LECS anmeldet, ist jeweils eine Liste derbekannten Server zu konfigurieren und zu verhindern, daß diese Adressen von einem Angreifer regi-striert werden. Außerdem sind die in Abschnitt 6.3 empfohlenen Gegenmaßnahmen einzuleiten, umdie Sicherheit des benutzten SCSP zu erhöhen.

Fußnoten1. Proxy-Adressen sind beispielsweise die von einem Ethernet-Switch gelernten MAC-Adressen.

Diese werden nicht registriert, sondern bei Bedarf fragt der LES alle als Proxies konfiguriertenLES nach den MAC-Adressen. Diese Vorgehensweise ist sinnvoll, da sich die Kontrolle überdie Erreichbarkeit der jeweiligen MAC-Adresse dem Proxy weitgehend entzieht und ein relativhäufiger Wechsel dieser Adressen erwartet wird. Der Proxy verifiziert die Erreichbarkeit einersolchen Adresse daher erst bei einer Anfrage des LES.

2. Der BUS stellt einen für die LANE essentiellen Dienst zur Verfügung. Er muß also in jedem Fallund in jedem ELAN vorhanden sein und die ATM-Adresse muß in jedem Fall dem LES bekanntsein.

3. Die READY_IND-Nachricht kannman sich als letzte Nachricht einer drei-Wege-Verbindungseröffnungvorstellen. Der Initiator sendet die SETUP-Nachricht. Der Empfänger antwortet mit der CONNECT-Nachricht, die implizit seine Empfangsbereitschaft signalisiert. Mit einer CALL_PROCEEDING-Nachricht hätte der Empfänger die Möglichkeit, den Empfang noch etwas hinauszuzögern. DerInitiator muß jedoch nach Empfang der CONNECT-Nachricht u.U. noch weitere Initialisierun-gen lokal vornehmen, bevor er selber in der Lage ist, eintreffende Dateneinheiten über diese

135


Verbindung zu empfangen.Diese Empfangsbereitschaft kann jedoch nicht mit einer Signalisierungs-Nachricht an den Kommunikationspartner übermittelt werden, da es beimATM-Verbindungsaufbaunur die zwei Nachrichten SETUP und CONNECT mit globalem Scope gibt. Daher wird mit derREADY_IND-Nachricht sozusagen ‘inline’ auf der bereits etablierten ATM-Verbindung die Emp-fangsbereitschaft signalisiert.

4. Es kann natürlich auch der Fall eintreten, daß ein Rechner überhaupt nicht erreichbar ist, beispiel-sweise weil er zur Zeit nicht im ELAN angemeldet ist.

5. Diese asymmetrische Kommunikation – einmal über den BUS und auf dem Rückweg über denLES – mag auf den ersten Blick verwirrend sein, ist zumindest aber konsistent mit den Vorstel-lungen des ATM-Forums. Die FLUSH_REQUEST-Nachricht muß über den BUS gesendet werden,da dieser die Reihenfolge der über dieselbe Verbindung empfangenen Dateneinheiten bei derWeitervermittlung beibehält. Wenn also die Flush-Aufforderung beim Empfänger angekommenist und der Sender nach dem ‘Flush’ keine weiteren Dateneinheiten über den BUS an denselbenEmpfänger gesendet hat, dann ist sicher, daß keine weiteren Dateneinheiten von diesem Sendernach dem Flush beim Empfänger vom BUS eintreffen werden. Die FLUSH_RESPONSE-Nachrichtist hingegen lediglich als Bestätigung gedacht und kann daher unabhängig von anderen Datenein-heiten über die vorhandenenKontrollverbindungen zum LES vermittelt werden. Das Senden überden BUS wäre auch denkbar, ist in der Spezifikation jedoch nicht vorgesehen.

6. Wenn das ELAN von Typ „Ethernet“ sein soll, dann muß beispielsweise geprüft werden, ob dieAdresse eine Länge von sechs Byte hat. Zusätzlich sollte geprüft werden, ob es sich nicht um eineMulticast-Adresse handelt, da diese eigentlich nur vom BUS reserviert werden können.

136

Kapitel 8. Zusammenfassung und AusblickDie ATM-Technik birgt eine Vielzahl von Sicherheitsrisiken. Die Ursache dafür ist die große Anzahlan neuen, unsicheren Protokollen, die direkt oder mittelbar den Einsatz dieser Technologie ermögli-chen.

Bereits die essentiellen Protokolle, die für alle nicht trivialen ATM-Installationen unbedingt erforder-lich sind, ermöglichen neue, sehr gefährliche ATM-spezifische Angriffe auf Endsysteme, Server undATM-Netzinfrastruktur (vgl. Kapitel 4). Als besonders kritisch muß die einfache Möglichkeit zumFälschen der ATM-Absenderadresse („ATM-Spoofing“) angesehen werden.

Darüber hinaus gibt es eine Vielzahl weiterer Sicherheitsrisiken, die durch unsichere Protokolle undDienste zur „IP über ATM“-Migration entstehen. Will man IP über ATM betreiben, muß eines derbeiden Protokolle CLIP oder LANE eingesetzt werden (vgl. Kapitel 5 und Kapitel 7). Diese beidenProtokolle bergen eigene, zusätzliche Risiken. Darüber hinaus muß beachtet werden, daß einige be-kannte IP-Sicherheitslücken (beispielsweise das IP-Spoofing) über ATM noch leichter durchzuführensind, als über die klassischen „legacy LANs“. IP-inhärente Risiken werden durch den Einsatz vonATM als Übertragungsmedium nicht verringert, sondern tendenziell vergrößert.

Aufgrund der analysierten Risiken wurde versucht, Gegenmaßnahmen zu erarbeiten. Hierzu läßt sichzusammenfassend sagen:

• Die standardisierten Sicherungsvorschläge des ATM-Forums (vgl. AFo98 und AFo99b) sind zurZeit nicht implementiert. Es müssen demnach herstellerspezifische Sicherungsmöglichkeiten erar-beitet werden.

• Herstellerspezifische Sicherungsmöglichkeiten erfordern in der Regel manuelles Konfigurieren derATM-Switches. Dies ist aufwendig und fehleranfällig. ATM-Sicherheit verträgt sich jedoch nichtmit der voreingestellten „Plug-and-Play“-Konfiguration, die typisch für den Auslieferzustand die-ser Switches ist. Die Switche sind vielmehr selber sicherheitskritische Komponenten und müssendementsprechend geschützt werden.

• Die Absicherung ist nur partiell möglich. Sowohl bei den Standardprotokollen für ATM als auchbei den zusätzlichen Protokollen für einen „IP über ATM“-Betrieb bleiben viele Probleme ungelöst.

Probleme treten vor allem durch die unberechtigteReservierung von Betriebsmitteln und die Schwie-rigkeiten bei der Firewall-Integration auf.

• ATM-Netze lassen sich beliebig mit verschiedenartigen virtuellen Netzen überlagern. BesondereVorsicht ist dann geboten, wenn einzelne Endsysteme (typischerweise Server) in mehrere dieservirtuellen Netze gleichzeitig integriert werden. Dies bietet sich unter ATM an, um auf aufwendi-ges IP-Routing zu verzichten, suggeriert aber eine nicht vorhandene physikalische Trennung dervirtuellen Netze. Auf diesen Endsystemen ist daher besonders darauf zu achten, daß durch sie vor-handene Firewalls nicht umgangen werden können.

137

Kapitel 8. Zusammenfassung und Ausblick

Für die zukünftige Entwicklung der ATM-Technik lassen sich hieraus unmittelbar zwei wesentlicheAnforderungen ableiten:

1. In den Folgeversionen der hier diskutierten Protokolle muß bereits als Teil der Spezifikation einedem jeweiligen Dienst entprechende Sicherheitsfunktionalität angegeben werden. Die teilweiseoffensichtlichen Sicherheitsrisiken der vorhandenen Spezifikationen sind in zukünftigen Versio-nen nicht tragbar.

2. Die Hersteller von ATM-Switches müssen der aktiven Rolle, die dem Switch bei der Zugriffskon-trolle in ATM-Netzen zukommt, durch entsprechende Konfigurationsmöglichkeiten nachkom-men. Dies ist eine relativ leicht umzusetzende Forderung, da im Zuge der Verarbeitung vonSignalisierungsnachrichten ohnehin auf den für die Zugriffskontrolle relevanten Informationen(Informations-Elementen) gearbeitet wird. Der Administrator hat z.Z. jedoch nur sehr einge-schränkte Möglichkeiten, diese Informationen für eine Zugriffskontrolle einzusetzen.

Allein die Umsetzung der zweiten Forderung würde bereits ausreichen, um ATM-Netze sehr sichergestalten zu können. Zusammen mit den unbestreitbaren Vorteilen bezüglich Skalierbarkeit und Ver-fügbarkeit spräche dann nichts mehr gegen die Verwendung von ATM auch in sicherheitskritischenBereichen.

138

Glossar

AAAL ’ATM Adaption Layer’

Die ’ATM Adaption Layer’ ist eine Schicht des ATM-Referenzmodells. Sie ist zwischen derATM-Schicht und der höheren Schicht der Anwendungen plaziert. Die Aufgabe des AAL istdie Anpassung der Funktionen der ATM-Schicht an die dienstespezifischen Anforderungen derhöheren Schichten. Um die dienstespezifischen Anforderungen zu kategorisieren wurden vierAAL-Typen definiert, die verschiedene Transportcharakteristika emulieren.

AAL1 ’ATM Adaption Layer’ Typ 1

Anpassungstyp für isochronen, verbindungsorientiertenDatenverkehrmit konstanter Bitrate, wieunkomprimierte Sprach- und Video-Übertragungen.


Anpassungstyp für isochronen, verbindungsorientierten Datenverkehr mit variabler Bitrate, wiekomprimierte Sprach- und Video-Übertragungen.

AAL3/4 ’ATM Adaption Layer’ Typ 3/4

Anpassungstyp für asynchronen Datenverkehr mit variabler Bitrate, verbindungslos oder ver-bindungsorientiert. Diese Anpassungsschicht erzeugt im Vergleich zu AAL5 (s.u.) relativ vielOverhead.


Anpassungstyp für asynchronen, verbindungsorientiertenDatenverkehrmit variabler Bitrate. Er-zeugt weniger Overhead als AAL 3/4 stellt aber weitgehend dieselbe Funktionalität bereit.

API ’Application Programming Interface’

Schnittstellenbeschreibung zur Programmierung. Ein API spezifiziert Syntax und Sematik vonFunktionen.

139

Glossar

ABR ’Available Bit Rate’

Eine der vier von ATM angebotenen Serviceklassen. Beim Aufbau einer Verbindung werdeneine maximale Rate an gesendeten Zellen (Peak Cell Rate, PCR) und eine minimale Rate angesendeten Zellen (Minimum Cell Rate, MCR) spezifiziert. ABR stellt eine Flußkontrolle zurVerfügung.

ARP ’Address Resolution Protocol’

Protokoll zur Auflösung von Protokoll-Adressen nach Netzwerkadressen (Schicht-2 Adressen)

ATM ’Asynchronous Transfer Mode’

ATM ist eine verbindungsorientierte Übertragungstechnik, bei der die Daten in kleinen Paketen(Zellen) fester Länge und einheitlicher Struktur übertragen werden. Sie ist asynchron in demSinne, daß für die Zellen einer Verbindung keine festen Zeitslots vorgegeben werden. Die Infor-mationsübertragung findet somit asynchron zu einer Taktung im Netz statt.

ATMARP ATM ’Address Resolution Protocol’

Protokoll zur Adreßauflösung von IP-Adressen nach ATM-Adressen, daß bei CLIP verwendetwird. Da es in ATM-Netzen keinen ’broadcast’-Mechanismus gibt, wird die Adreßauflösungdurch einen zentralen Dienst, einem ATMARP-’Server’ erbracht, der Zuordnungen zwischenIP- und ATM-Adressen speichert und auf Anfragen nach ATM-Adressen antwortet.

ATMARP-’Server’

Wird bei CLIP als zentraler Dienst zur Adreßauflösung verwendet. Ein ATMARP-Server spei-chert Zuordnungen zwischen IP- und ATM-Adressen und antwortet auf Anfragen nach ATM-Adressen. In jedem LIS muß mindestens ein ATMARP-Server konfiguriert sein.

ATM-Forum

Zusammenschluß von Herstellern und Netzbetreibern, mit dem Ziel die ATM-Technik im nicht-öffentlichen Bereich voran zu treiben. Die vom ATM-Forum herausgegebenen Spezifikationenwerden inzwischen als De-facto-Standards angesehen.

ATM-Referenzmodell

140

Glossar

Das ATM-Referenzmodell definiert die drei Ebenen (User Plane, Control Plane, ManagementPlane) und die drei Schichten (Physical Layer, ATM Layer, ATM Adaption Layer (AAL)) derATM-Technik.

BBCD ’Binary Coded Decimal’

Zahlenkodierung, bei der jede Dezimalziffer durch eine entsprechende 4-bit Binärzahl dargestelltwird. Ein Byte kann demnach zur Kodierung von zwei Ziffern verwendet werden.Wird z.B. beimE.164 Adreßformat verwendet.

BUS ’Broadcast and Unknown Server’

Einer der drei ’Server’ der LAN Emulation. Der BUS emuliert das Versenden von Daten anSchicht-2-’Broadcast’/’Multicast’-Adressen.Dazu unterhält er Punkt-zu-Mehrpunkt-Verbindungenzu allen ’Clients’ des emulierten LANs, über die ’Broadcast’- und ’Multicast’-Nachrichten wei-ter vermittelt werden. Ferner kann der BUS von einem ’Client’ der LAN Emulation genutztwerden, um bereits während der Adreßauflösung beim LES Dateneinheiten an einen anderen’Client’ zu schicken.

CCBR ’Constant Bit Rate’

Eine der vier von ATM angebotenen Serviceklassen. Bei dieser Klasse werden eine maximaleRate an zu übermittelnden Zellen (Peak Cell Rate, PCR), maximale erlaubte Verzögerung derZellen (Cell Transfer Delay, CTD) zwischen den Endpunkten, maximale Veränderung der Ver-zögerung (Cell Delay Variation, CDV) und maximale Zell-Verlustrate (Cell Loss Ratio, CLR)festgelegt. Anwendungsbeispiele sind die Emulation einer physikalischen Leitung, Video- undAudio-Konferenz.

CERT ’Computer Emergency Response Team’

Ein Computer-Notfall-Team (CERT) bearbeitet ihm gemeldete Sicherheitsprobleme (-vorfälle)und gibt den Betroffenen Hilfestellung zum Einsatz von Sicherheitsmechanismen zum Schutzihrer EDV-Infrastruktur.

141

Glossar

CLIP ’Classical IP and ARP over ATM’

Eine Methode um die Anforderungen des Internetprotokoll (IP) auf einem ATM-Netz zu emulie-ren. Dazu werden auf demATM-Netz logische IP-’Subnets’ (LIS) konfiguriert. Alle IP-Stationenaußerhalb des LIS müssen über einen ’Router’ angesprochen werden, innerhalb des LIS fin-det Kommunikation über direkte ATM-Verbindungen statt. Zur Auflösung von IP- zu ATM-Adressen (ATMARP) wird für jedes LIS ein zentraler ATMARP-Server eingerichtet. IP-Paketewerden auf Basis des AAL5 per ’LLC Encapsulation’ oder ’Virtual Circuit (VC) Multiplexing’übertragen.

DDCC ’Data Country Code’

Eines der drei ATM-Adreßformate. Beim DCC wird das Land, in dem die Adresse registriertist, im ’Initial Domain Part’ (IDP) spezifiziert. Innerhalb des spezifizierten Landes vergibt dieOrganisation, die Mitglied der ’International Standards Organisation’ (ISO) ist, die Adressen.

DES ’Data Encryption Standard’

Standard eines Algrorithmus zum Ver- und Entschlüsseln von Binärcode, herausgegeben vom’American National Institute of Standards’ (ANSI).

DHCP ’Dynamic Host Configuration Protocol’

Das DHCP stellt einen Mechanismus bereit, mit dem ’Hosts’ (DHCP-’Clients’), die TCP/IPbenutzen, Konfigurationsparameter, wie IP-Adresse und ’Subnet’-Maske, automatisch über dasNetzwerk von einem DHCP-’Server’ beziehen können.

DoS ’Denial of Service’

Angriff auf die Verfügbarkeit vonDiensten. Bei einem ’Denial of Service’-Angriffwird versucht,die Verfügbarkeit von Diensten für die Teilnehmer zu unterbinden, indem der Dienst durch einegroße Anzahl von Anfragen des Angreifers überlastet oder durch nicht korrekte Anfragen desAngreifers zum Absturz gebracht wird.

142

Glossar

DSP ’Domain Specific Part’

Jede ATM-Adresse, egal ob sie dem ’Data Country Code’ (DCC), dem ’International Code De-signator’ (ICD) oder E.164-Format entspricht, besteht aus einem ’Initial Domain Part’ (IDP) undeinem ’Domain Specific Part’ (DSP). Der DSP besteht wiederum aus zwei Teilbereichen: dem’High Order Part’ (HO-DSP), der von der im IDP spezifizierten Organisation vergeben wird, unddem ’Low Order Part’, der das Endgerät identifiziert.

EE.164

Eines der drei ATM-Adreß-Formate. Beim E.164-Formatwird eine ISDN-Adresse mit höchstens15 Stellen als ’Binary Coded Decimal’ (BCD) im ’Initial Domain Part’ (IDP) eingetragen.

ELAN ’Emulated Local Area Network’

Logischer Zusammenschluß von Endgeräten, der entsteht, wenn man die vom ATM-Forum spe-zifizierte LAN-Emulation in einem Netzwerk konfiguriert. Mitglieder eines ELAN können so-wohl ATM-Endgeräte, als auch Switches mit angeschlossenen Endgeräten eines ’Ethernet’- oder’Token Ring’-LANs sein.

FFDDI ’Fiber Distributed Data Interface’

Eine vom ANSI (American National Standards Institute) standardisierte 100 Megabit/s LAN-Technik (Schicht 2), auf optischen Übertragungsmedien. FDDI basiert auf einer doppelt ausge-legten Ringtopologie mit Mechanismen zur Erkennung von Stationsausfällen und Kabelbrüchenund anschließender Rekonfiguration des Ringes.

HHSN ’High Speed Networks’

143

Glossar

Was man unter Hochgeschwindigkeits-Netzwerke (High Speed Networks) versteht ändert sichim Laufe der Zeit. Zur Zeit kann man Netze mit einer Übertragungsrate von 100MBit/s undhöher zu dieser Klasse zählen.

IICD ’International Code Designator’

Eines der drei ATM-Adreßformate. Beim ICD wird die internationale Organisation, bei der dieAdresse registriert ist, im ’Initial Domain Part’ (IDP) spezifiziert. Das Verzeichnis, in dem Orga-nisationen und ihre Codierung enthalten sind, wird von dem ’British Standards Institute’ geführt.

IDP ’Initial Domain Part’

Jede ATM-Adresse, egal ob sie dem ’Data Country Code’ (DCC), dem ’International Code De-signator’ (ICD) oder E.164-Format entspricht, besteht aus einem ’Initial Domain Part’ (IDP) undeinem ’Domain Specific Part’ (DSP). Der IDP besteht aus dem ’Authority and Format Identifier’(AFI) und dem ’Initial Domain Identifier’ (IDI). Der AFI enthält die Information welches derdrei Formate benutzt wird. Der IDI spezifiziert das Land (DCC) bzw. die Organisation (ICD),wo die Adresse registriert ist oder enthält eine ISDN-Nummer (E.164).

IE ’Information Element’

’Information Elements’ sind Bestandteile von Signalisierungsnachrichten. In ihnen sind für denAufbau der Verbindung relevante Informationen codiert, wie z.B. die gewünschten Eigenschaf-ten der Verbindung und die ATM-Adressen.

IEEE ’Institute of Electrical and Electronics Engineers’

Dachverband amerikanischer Ingenieure. Hat u.a. Standards für ’Ethernet’- und ’Token Ring’-Netze (IEEE-802-Spezifikationen) herausgegeben.

IETF ’Internet Engineering Task Force’

Internationale Organisation, die Spezifikationen im Zusammenhang mit der Weiterentwicklungdes Internets erarbeitet. Die Spezifikationen werden in ’Request for Comments’ (RFCs) veröf-fentlicht.

144

Glossar

ILMI ’Integrated Local Management Interface’

VomATM-Forumdefiniertes Protokoll zum bidirektionalenAustausch vonManagement-Informationen(z.B. Status- und Konfigurationsinformationen) zwischen Endgerät und Netzknoten bzw. zwi-schen zwei Netzknoten. ILMI verwendet eine Untermenge der ‘Simple Network ManagementProtocol’ (SNMP)-Funktionen.

IME ’Interface Management Entity’

IMEs sind auf ATM-Endsystemen und auf ATM-’Switches’ konfiguriert. Sie kommunizierenüber das ILMI-Protokoll und tauschen so Managementinformationen aus.

IP Internet Protokoll

Teil des TCP/IP-Protokollstapels. Das IP entspricht der Schicht 3 (Netzwerkschicht) des OSI-Referenzmodells. Die Hauptaufgabe des IPs ist die Wegefindung (Routing) in einem Netz. DasIP bietet der Transportschicht (in diesem Fall TCP) eine nicht gesicherte, verbindungslose Da-tenübertragung.

IPX/SPX ’Internetwork Packet Exchange’/ ’Sequential Packet Exchange’

Protokolle der ’Novell NetWare’, die der Schicht 3 (IPX) und Schicht 4 (SPX) des OSI-Referenzmodellsentsprechen. IPX bietet einen verbindungslosenDatagramm-Service, SPX einen verbindungsori-entierten Service, der die Reihenfolge der Pakete erhält.

ISDN ’Intergrated Services Digital Network’

Volldigitale Netze, die die analogen Telefonnetze ablösen sollen. Es sollen dabei verschiedeneKommunikationsdienste, wie Sprache, Text, Standbild, Bewegtbilder usw. in dieses Netz in-tegriert und über einheitliche Schnittstellen unter Verwendung eines einzigen (physikalischen)Anschluß zugänglich gemacht werden. Bei ISDN gibt es eine konsequente Trennung von Zei-chengabe (Signalisierung) und Nutzdatenübertragung.

ISO ’International Organisation for Standardisation’

Internationale Standardisierende Organisation. Hat u.a. das OSI-Referenzmodell standardisiert.

ITU-T ’International Telecommunication Union’ - ’TelecommunicationStandardization Sector’

145

Glossar

Die ITU ist eine Tochterorganisation der Vereinten Nationen, deren stimmberechtigte Mitgliederdiejenigen nationalen Organisationen sind, die die hoheitlichen Telekommunikationsaufgabenwahrnehmen. ITU-T ist ein Sektor der ITU. Früher bekannt unter CCITT. Die ITU-T erarbeitetweltweit gültige Standards für öffentliche Telekommunikationsentze.

LLAN ’Local Area Network’

Netz in einem privaten, lokalen Bereich, z.B. unternehmensintern, mit relativ geringer Ausdeh-nung. Herkömmliche LANs beruhen i.A. auf einem ’Shared Medium’.

LANE LAN Emulation

Die LAN Emulation wurde vom ATM-Forum spezifiziert. Sie emuliert über dem ATM-Serviceeine MAC-Schicht, um herkömmlichen Protokollen, die der Schicht 3 des OSI-Refernzmodellsentsprechen, eine klassische MAC-Schnittstelle eines LANs zur Verfügung zu stellen. Ein ATM-Netz kann hierbei in logische ELANs aufgeteilt werden. Um die Dienste eines herkömmlichen’Broadcast’-Netzes zu emulieren, stellt die LANE drei Server bereit: den ’LAN Emulation Ser-ver’ (LES), den ’Broadcast and UnknownServer’ (BUS) und den ’LANEmulation ConfigurationServer’ (LECS).

LDAP ’Leightweight Directory Acces Protocol’

LDAP ist eine Vereinfachung eines ITU-T Protokolls mit dem Namen ’Directory Access Proto-col’, das über TCP/IP arbeitet.

LEC ’LAN Emulation Client’

Auf jedem ATM-Endgerät, daß Mitglied eines ELAN der LANE ist, muß ein LEC konfigu-riert werden. Dieser stellt den Protokollen der höheren Schichten eine MAC-Schnittstelle zurVerfügung. Auch auf ’Switches’, an denen Endgeräte mit herkömmlichen LAN-Techniken an-geschlossen sind, muß ein LEC konfiguriert werden. Dieser LEC stellt für die Endgeräte einen’Proxy’ gegenüber dem ATM-Netz dar.

LECS ’LAN Emulation Configuration Server’

Der LECS ist einer der drei Server der LAN Emulation (LANE). Ein LECS wird nicht für jedesELAN, sondern i.A. nur einmal pro ATM-Netz eingerichtet. Der LECS verwaltet Informatio-

146

Glossar

nen darüber, welcher LEC sich bei welchen ELANs anmelden darf und wie die Adressen derfür diese ELANs konfigurierten LES sind. LECs erfragen diese Informationen während ihrerInitialisierungsphase beim LECS.

LES ’LAN Emulation Server’

Der LES ist einer der drei Server der LAN Emulation (LANE). Ein LES verwaltet genau einELAN. Ein LECs melden sich beim LES eines ELAN an, um Teilnehmer dieses ELANs zuwerden. Außerdem hat der LES die Aufgabe, innerhalb des ELANs MAC-Adressen von LECsnach entsprechenden ATM-Adressen aufzulösen.

LIS ’Logical IP Subnetwork’

Bei CLIP werden auf einem ATM-Netz logische IP-’Subnets’ (LIS) konfiguriert. Alle Ressour-cen außerhalb eines LIS müssen über ’Router’ angesprochen werden, innerhalb des LIS findetKommunikation über direkte ATM-Verbindungen statt. Es handelt sich hierbei um logische Sub-netze, da das darunterliegende ATM-Netz keine physikalsiche Trennung zwischen diesen Sub-netzen vornimmt.

LUNI ’LAN Emulation User Network Interface’

LUNI meint die LUNI-Spezifikation des ATM-Forums, die das Verhalten von BUS, LES, LECSgegenüber dem LEC spezifiziert.

MMIB ’Management Information Base’

MIBs speichern Konfigurationsinformationen, auf die mit dem SNMP oder anderen Netzwerk-Management-Protokollen zugegriffen wird. Bei ATM wird hierzu das ILMI-Protokoll verwen-det, das ohne TCP/IP direkt über ATM betrieben werden kann.

MPEG ’Motion Picture Experts Group’

Gruppe der ISO, die sich mit Video- und Audiokompressionstechniken beschäftigt. Hier: EinKompressionsverfahren für Videodaten.

147

Glossar

MiM ’Man in the Middle’

Bei einem MiM-Angriff versucht ein Angreifer den Datenverkehr zwischen zwei Endgeräten(z.B. einem Server und einem Client) über ein Endgerät, das er kontrolliert, umzulenken. Dasversetzt ihn in die Lage, die Dateneinheiten mitzulesen (Angriff auf die Vertraulichkeit von Da-ten) und zu verfälschen (Angriff auf die Integrität von Daten).

MPOA ’Multi-Protocol over ATM’

Spezifikation des ATM-Forums. Ziel von MPOA ist der effiziente Transfer von Daten zwischenverschiedenen (logischen) Subnetzen (ELANs) in einer LAN Emulations Umgebung, durch Er-mittlung von ’Shortcuts’ innerhalb des ATM-Netzes.

NNDIS ’Network Driver Interface Specification’

Spezifikation einer Schicht-2-Diensteschnittstelle, ursprünglich von Microsoft und 3Com

NHRP ’Next Hop Resolution Protocol’

Mit dem NHRP soll ein Host, der über ein Netz ohne ’Broadcast’-Mechanismus kommunizierenmöchte, in die Lage versetzt werden, die Schicht-3- und Schicht-2-Adressen des ’Next Hop’ inRichtung eines Zielhost ermitteln zu können. Ist der Zielhost an dieses Netz angeschlossen, soist der ’Next Hop’ der Zielhost. Ist der Zielhost nicht an dieses Netz angeschlossen, so ist der’Next Hop’ der Router, der dem Zielhost am ’nächsten’ ist.

NNI ’Network Node Interface’ bzw ’Network Network Interface’

Schnittstelle zwischen zwei ATM-’Switches’ (Netzwerkknoten)

OOAM ’Operation, Administration, and Maintenance’

Netzwerkmanagementfunktionen für Einstellungs-, Verwaltungs- und Entstörmaßnahmen

148

Glossar

ODI ’Open Data-Link Interface’

Spezifikation einer Schicht-2-Diensteschnittstelle von Novell

PPDU Protocol Data Unit

Im OSI-Schichtenmodell tauschen Protokollinstanzen derselben Schicht Nutzdaten (SDUs) einerhöheren Schicht über Protokoll-Dateneinheiten (PDUs) aus. Diese bestehen aus Kontrollfeldernund Nutzdaten.

PNNI Private Network Network Interface

Ein Protokoll, das zwischen ATM-Switches eingesetzt wird. Es hat zwei Aufgaben: Einerseitsdas hierachische ’Routing’, andererseits das Weiterleiten von UNI-Signalisierungsnachrichtenüber ein ATM-Netz.

PVC Permanent Virtual Connection

Die VCI/VPI-Paare einer PVC zwischen Endgeräten werden in allen beteiligten ’Switches’ vomSystemadministrator manuell konfiguriert. Die Endgeräte können dann zu jeder Zeit, ohne vor-herige Signalisierung, Dateneinheiten übertragen.

QQoS ’Quality of Service’

Die Qualität eines Dienstes ist definiert als die durch ein System erbrachte Leistung, die den Zu-friedenheitsgrad eines Benutzers bestimmt. Beim Aufbau einer Verbindung in einem ATM-Netzkönnen Anforderungen an die Dienstgüte dieser Verbindung gestellt werden. Diese Umfassenz.B. den maximal zulässigen Zellverlust und die zulässige Zellverzögerung. ATM unterstütztsomit QoS-Anforderungen von Benutzern durch das Reservieren von Betriebsmittel.

149

Glossar

RRFC Request For Comment

Spezifikationen und Standards der IETF werden von ihr in Form von RFCs verabschiedet undzur Diskussion gestellt.

SSCSP Server Cache Synchronization Protocol

Protokoll zum Informationsabgleich zwischen Servern, um z.B. Server redundant betreiben zukönnen. Das Protokoll ist unabhängig von der Art der Server und somit allgemein einsetzbar.

SDH Synchronous Digital Hierarchy

Optisches Übertragungssystem, das in der ITU-T Empfehlung G.707 spezifiziert wurde und aufSONET (Synchronous Optical Network) basiert. Die definierte Multiplexhierarchie reicht bis zuBitraten von 10 Gbit/s und ist einfach erweiterbar. Die zu einer Verbindung gehörenden Datenmüssen bei SDH periodisch zu festgelegten Zeitpunkten gesendet werden (TDM).

Signalisierung

Die Signalisierung wird verwendet, um in einem ATM-Netz eine ’Switched Virtual Connection’aufzubauen (durchzuschalten). Die Wegfindung durch das Netz (über die Netzknoten) findet un-ter Beachtung der von der signalisierenden Station geforderten ’Quality of Service’ (QoS) statt.Beim Aufbau einer virtuellen Verbindung wird schrittweise, jeweils für die Teilstrecke zwischenzwei in der Verbindung ’benachbarten’ ’Switches’, ein VCI/VPI-Tupel in die Vermittlungsta-bellen der beiden ’Switches’ eingetragen. Dieses VCI/VPI-Tupel repräsentiert die Verbindungauf der jeweiligen Teilstrecke. Innerhalb eines ’Switch’ werden die beiden VCI/VPI-Tupel, diedie Verbindung auf den angrenzenden Teilstrecken repräsentieren, und die von der Verbindungbenutzten ’Ports’ des ’Switch’ in der Vermittlungstabelle in Beziehung gesetzt. Geht auf einemPort eine Zelle ein, liest der Switch das VCI/VPI-Tupel aus und stellt mit Hilfe der Vermitt-lungstabelle fest, welches VPI/VCI-Tupel in die Zelle kopiert und durch welchen Port die somodifizierte Zelle dann weitergeleitet werden muß.

SNMP Simple Network Management Protocol

SNMP ist ein von der IETF im Rahmen der TCP/IP-Familie definiertes Protokoll zur Ausfüh-rung grundlegender Managementfunktionen für Netzwerke wie z.B. Einstellen von Konfigurati-

150

Glossar

onsparametern oder Fehlerüberwachung. Wegen der beschränkten Grundfunktionalität und deneinfach strukturierten Aufbau der MIB sind SNMP-basierte Systeme einfach zu implementieren.

SPX Sequential Packet Exchange

siehe IPX

STM ’Synchronous Transfer Mode’

Im Gegensatz zum Asynchronous Transfer Mode muß beim STM jede Verbindung die Datenin festen Zeitabständen versenden. Hat eine Verbindung keine Daten zu übertragen, verfällt dienicht genutzte Übertagungskapazität, da sie nicht von anderen Verbindungen genutzt werdenkann. Während bei ATM jede Zelle einen Header mit Multiplex-Informationen mit sich tragenmuß, ist dies bei STM nicht notwendig. SONET und SDH spezifizieren die verschiedenen For-mate für die STM-Übertragung in öffentlichen Telefonnetzen.

SVC Switched Virtual Connection

Beim Aufbau einer ’Switched Virtual Connection’ werden die Vermittlungstabellen (VCI/VPI-Paare) in den ’Switches’ dynamisch eingerichtet, s. auch PVC oder Signalisierung.

TTCP Transmission Control Protocol

Das ’Transmission Control Protocol’ ist ein Schicht-4-Protokoll und bietet verbindungsorientier-te und zuverlässige Ende-zu-Ende Kommunikation über IP-Netzwerke. ’Zuverlässig’ bedeutethierbei, daß korrekt übertragene Pakete bestätigt werden, so daß Übertragungsfehler und Paket-verluste erkannt und davon betroffene Pakete erneut übertragen werden können . TCP übergibtdie empfangenen Daten in genau der Reienfolge an die Anwendung, wie sie vom Sender ver-schickt wurden.

UUBR ’Unspecified Bit Rate’

151

Glossar

Eine der vier von ATM angebotenen Serviceklassen. Beim Aufbau einer Verbindung wird ledig-lich eine maximale Senderate angegeben. Im Gegensatz zur Serviceklasse ABR gibt es bei UBRkeine Flußkontrolle.

UNI User-Network Interface

Als ’User-Network Interface’ wird zum Einen die Schnittstelle zwischen Endgerät und lokalemSwitch bezeichnet. Zum Anderen bezeichnet UNI 3.1 bzw. UNI 4.0 das Protokoll des ATM-Forums für die Signalisierung zwischen Endgerät und lokalem ’Switch’.

VVC Virtual (Channel) Connection

Die Verbindung zwischen zwei ATM-Endgerätenwird ’virtuelle Verbindung’ genannt. Es ist eine’virtuelle’ Verbindung, da es sich weiterhin um Paketvermittlung (’Zellswitching’) handelt, diejedoch Verbindungscharakter hat: analog zu dem ’Durchwählen’ im Telefonnetzmüssen vor demSenden der Daten Vermittlungstabellen in den Switches und Endgeräten eingerichtet werden (s.VCI/VPI).

VCI Virtual Channel Identifier

s. VCI/VPI

VCI/VPI Virtual Channel Identifier/Virtual Path Identifier

Der ’Virtual Path Identifier’ und der ’Virtual Channel Identifer’ bilden zusammen die Multi-plexinformationen in einer ATM-Zelle. Die Werte für (VPI, VCI) der Zellen einer Verbindungkönnen sich in jedem Switch ändern und haben somit nur lokale Bedeutung.

VLAN Virtuelles LAN

Die Zugehörigkeit eines ’Hosts’ zu einem LAN definiert sich über eine physische Verbindungdes ’Hosts’ an dieses LAN, i.A. über ein ’shared Medium’. Sind die Hosts nicht an ein ’sharedMedium’, sondern an ’Switches’ angeschlossen, ist es möglich die Zugehörigkeit von Hosts zu

152

Glossar

einem LAN unabhängig von der physichen Verbindung des Hosts an das Netz auf den ’Swit-ches’ zu konfigurieren. Dies hat zur Folge, daß nur noch bestimmte Rechner direkt miteinanderkommunizieren können und sich somit ein oder mehrere virtuelle LANs ein physikalisches Netzteilen.

VPI Virtual Path Identifier

s. VCI/VPI

WWAN ’Wide Area Network’

Ein WAN ist ein Netz, daß sich über ein großes Gebiet, in der Größenordnung von Ländernoder Kontinenten, erstreckt. Für Verbindungen zwischen Netzknoten in einemWAN werden i.A.Punkt-zu-Punkt Leitungen gewählt.

ZZelle

Dateneinheit der ATM-Technik. Eine ATM-Zelle hat eine festgelegte Größe und Struktur undkann daher sehr effizient, auch auf Hardwareebene, verarbeitet werden. Sie besteht auf 5 ByteHeader und 48 Byte ’Payload’.

153

Glossar

154

Literaturverzeichnis

[AFo98] ATMForum, Technical Committee,ATM Security Framework 1.0: AF-SEC-0096.000, Febru-ary, 1998.

[AFo99b] ATM Forum, Technical Committee, ATM Security Specification 1.0: AF-SEC-0100.000,February, 1999.

[AFo96a] ATM Forum, Technical Committee, Integrated Local Management Interface (ILMI), Spec-ification Version 4.0: AF-ILMI-0065.000, September, 1996.

[AFo97] ATM Forum, Technical Committee, LAN Emulation Over ATM, Version 2 - LUNI Specifica-tion: AF-LANE-0084.000, July 1997.

[AFo99a] ATM Forum, Technical Committee, PNNI Version 1.0 Security Signalling Addendum: AF-CS-0116.000, Mai, 1999.

[AFo96] ATM Forum, Technical Committee, Private Network-Network Interface, Specification Ver-sion 1.0 (PNNI 1.0): AF-PNNI-0055.000, March, 1996.

[AFo99] ATMForum, Technical Committee,UNI Signalling 4.0 Security Addendum:AF-CS-0117.000,Mai, 1999.

[Bel89] S.M. Bellovin, Security Problems in the TCP/IP Protocol Suite, Computer CommunicationReview, Vol. 19, No.2, April 1989.

[BeE98] C. Benecke und U. Ellermann, Securing ‘Classical IP over ATM’, 7th USENIX SecuritySymposium, San Antonio, Texas, USA, January 1998.

[CFS90] J. Case, M. Fedor, M. Schoffstall, und J. Davin, A Simple Network Management Protocol(SNMP): Request for Comments: 1157, Network Working Group, May 1990.

[ChZ95] D.B. Chapman und E.D. Zwicky, Building Internet Firewalls, O’Reilly & Associates, Inc.,November 1995.

[ChB94] W.R. Cheswick und S.M. Bellovin, Firewalls and Internet Security: repelling the wilyhacker, Addison-Wesley, 1994.

[DFN00] DFN-CERT, Leitfaden zur Absicherung von Rechnersystemen in Netzen, Version 1.0, DFN-CERT, Zentrum für sichere Netzdienste GmbH, Juli 2000.

[Ell94] U. Ellermann, Firewalls: Isolations- und Audittechniken zum Schutz von lokalen Computer-Netzen, DFN-Bericht Nr. 76, DFN-Verein, September 1994.

[DaS96] S. Garfinkel und G. Spafford,Practical UNIX& Internet Security, 2nd, O’Reilly, April 1996.

155

[Gin99] D. Ginsburg, ATM: solutions for enterprise internetworking, 2nd, Addison-Wesley, 1999.

[Hei97] M. Hein und N. von der Lancken, ATM: Konzepte - Trends - Migration, International Thom-son Publishing, 1997.

[ITU92] International TelecommunicationUnion,CLOSEDUSERGROUP: Recommendation I.225.1,ITU, 1992.

[Lau94]M. Laubach,Classical IP and ARP over ATM: Request for Comments: 1577, NetworkWork-ing Group, January 1994.

[LaH98] M. Laubach und J. Halpern, Classical IP and ARP over ATM: Request for Comments: 2225,Network Working Group, April 1998.

[LAH98] J. Luciani, G. Armitage, J. Halpern, und N. Doraswamy, Server Cache SynchronizationProtocol (SCSP): Request for Comments: 2334, Network Working Group, April 1998.

[Mah98] M. Maher, ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update: Requestfor Comments: 2331, Network Working Group, April 1998.

[PLM95] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, und A. Malis, ATM SignallingSupport for IP over ATM: Request for Comments: 1755, Network Working Group, February1995.

[Pis91] D. Piscitello, The Transmission of IP Datagrams over the SMDS Service: Request for Com-ments: 1209, Network Working Group, March 1991.

[Plu82] D.C. Plummer, An Ethernet Address Resolution Protocol: Request for Comments: 826, Net-work Working Group, November 1982.

[Sch96] B. Schneier, Applied Cryptography: protocols, algorithms, and source code in C, JohnWiley& Sons, Inc..

156

Documents

Online Ratgeber des DFN-FWL - uni-hamburg.de · 2016. 4. 18. · Die hier vorgestellten Vorschläge zur Implementierung und Konﬁguration von Firewalls und anderen Sicherheitsmechanismen