Firewall für Hochgeschwindigkeitsnetze

Firewall für Hochgeschwindigkeitsnetze

Firewalls f
ur Hochgeschwindigkeitsnetze
Uwe Ellermann
Carsten Benecke
DFN-FWL
Firewall-Labor fur Hochgeschwindigkeitsnetze
Fachbereich Informatik, Universitat Hamburg
fEllermann,[email protected]
Zusammenfassung
Der Firewall ist ein wichtiger Schutzmechanismus in IP-Netzen geworden. Der Trend zu ATM-Netzen fuhrt zu zwei wesentlichen Herausforderungen fur den Einsatz von Firewalls. Auf der einen Seite birgt die
ATM-Technik durch neue Konzepte und neue Dienste zusatzliche Sicherheitsrisiken. Auf der anderen Seite lassen sich die ubertragenen Daten bei
den uber ATM erreichbaren Durchsatzen nicht mehr so leicht wie bisher
von einem Firewall kontrollieren.
In diesem Artikel sollen Migrationswege fur den Einsatz von klassischen Firewall-Konzepten in ATM-Netzen aufgezeigt werden. Der
Schwerpunkt liegt bei der Analyse der Performanz der beiden wichtigsten Firewall-Komponenten (Proxy-Server und Packet Screen), um dadurch die kritischen Engpasse beim Einsatz von Firewalls in ATM-Netzen
zu identizieren. Abschlieend wird ein kurzer Ausblick auf skalierbare
Firewall-Konzepte gegeben, die uber eine Migration hinausgehen und fur
zukunftige Hochgeschwindigkeitsnetze benotigt werden.
1 Einleitung
Firewalls sind heute ein integraler Bestandteil von Schutzkonzepten bei der
Anbindung an das Internet, aber auch bei der Absicherung einzelner Subnetze
innerhalb von Unternehmen.
Mit der immer wichtigeren Rolle der Datenkommunikation werden hohere
Durchsatze erforderlich, die durch Hochgeschwindigkeitsnetze (HSN), wie FDDI, ATM, Fast- und Gigabit-Ethernet ermoglicht werden. Da sich die wesentliche Funktionsweise bei Fast- und Gigabit-Ethernet gegenuber dem herkommlichen Ethernet nicht geandert hat, unterscheiden sich diese Netze in erste
Das Projekt \Firewall-Labor fur Hochgeschwindigkeitsnetze" (DFN-FWL) wird durch
den \Verein zur Forderung eines Deutschen Forschungsnetzes e. V." (DFN-Verein) aus Mitteln der Deutschen Telekom nanziert.
1
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Linie durch einen hoheren maximalen Durchsatz (100 Mbit/s bzw. 1 Gbit/s).
ATM (\Asynchronous Transfer Mode") als verbindungsorientiertes Netz mit
einer festen Paketlange (\Zelllange") unterscheidet sich im Zugrisverfahren
entscheidend von klassischen Netzen. Dadurch ermoglicht ATM eine freie Skalierung des Durchsatzes auf mehrere Gbit/s und noch hohere Datenraten. Die
Leistungsfahigkeit von Firewalls ist demgegenuber in den letzten Jahren nur
durch den Einsatz leistungsfahigerer Hardware gesteigert worden. Mit der Skalierbarkeit von ATM kann die Leistungssteigerung bei universeller WorkstationHardware nicht mithalten.
Im folgenden Abschnitt wird untersucht, welche Moglichkeiten zur Integration von Firewalls in ATM-Netze bestehen.1 Der dritte Abschnitt untersucht
die Performanz von Firewalls in einem 155 Mbit/s ATM-Netz. Die Ergebnisse
dieser Untersuchungen konnen auch auf andere HSN ubertragen werden. Im
vierten Abschnitt werden Ansatze fur skalierbare Firewalls skizziert.
2 Integration von Firewalls in ATM-Netze
In ATM-Netzen werden heute \Classical IP" (CLIP) Laubach 94], \LAN Emulation" (LANE) oder \Multiprotocol over ATM" (MPOA) Dorling et al.96]
eingesetzt, um etablierte Dienste zur Verfugung stellen zu konnen. CLIP, LANE und MPOA ist gemeinsam, da sie die Eigenschaften und die Struktur
des zugrundeliegenden ATM-Netzes verdecken und das ATM-Netz auf die Eigenschaft reduziert, Dateneinheiten schnell transportieren zu konnen. Die Unterstutzung von z.B. IP durch CLIP ermoglicht so eine einfache Integration
etablierter IP-basierter Konzepte wie Firewalls in ATM-Netze.
Die Migrationsmoglichkeiten fur Firewalls in ATM-Netzen werden im Folgenden am Beispiel der Integration einer Packet Screen in ein CLIP-Netz diskutiert. Eine Packet Screen ist ein Filter, der anhand der in dem ProtokollHeader der Dateneinheit verfugbaren Informationen entscheidet, ob die Dateneinheit weitergeleitet werden soll. Fur die Filterung werden Quell- und ZielIP-Adressen sowie Quell- und Ziel-Ports verwendet. Eine Packet Screen kann
bei der Filterung einzelner Dateneinheiten jedoch wichtige Informationen nicht
erkennen, die erst im Kontext mehrerer Dateneinheiten sichtbar werden. Die
bei der Integration einer Packet Screen in ein ATM-Netz gewonnenen Erkenntnisse konnen auf die ubrigen Firewall-Konzepte | Gateway-Firewalls sowie
Kombinationen von Packet Screen und Bastion | direkt ubertragen werden.2
1 In diesem Artikel werden keine allgemeinen Fragen des Aufbaus von Firewalls, wie etwa die Auswahl der Sicherheitsrichtlinien, die Absicherung von Firewalls und sichere Realisierung von Proxy-Servern fur ausgewahlte Protokolle diskutiert. Diese Firewall-Aspekte
sind ausfuhrlich in einschlagiger Literatur diskutiert Chapman et al. 95, Cheswick et al. 94,
Ellermann 94] und sollen daher an dieser Stelle nicht wiederholt werden.
2 F
ur einen ausfuhrlichen Vergleich der unterschiedlichen Firewall-Konzepte mit ihren
Starken und Schwachen sei auf den DFN-Bericht Nr. 76 Ellermann 94] verwiesen.
2
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
2.1 Packet Screen Integration in ein ATM-Netz
Im Gegensatz zu "Legacy\-LANs wie BNC-Ethernet wo lediglich ein Kabel
fur den Aufbau eines Netzes erforderlich ist, benotigen ATM-Netze eine aktive Komponente, den Switch, der Dateneinheiten zum Ziel weiterleitet. Wird
fur das externe Netz (z. B. Internet) und das interne, zu schutzende Netz
(z. B. LAN) jeweils ein Switch eingesetzt, so ergibt sich der in Abbildung 1
dargestellte Aufbau. Die Packet Screen kann durch einen Router oder mit
geeigneter Software auch auf eine Workstation realisiert werden.
Internet
LAN
Packet Screen
ATM Switch
ATM Switch
Abbildung 1: Packet Screen Realisierung unter ATM mit einer Workstation als
Packet Screen
Durch dieses Setup wird eine klare Trennung der beiden Netze erreicht und
die sichere Abgrenzung hangt, wie auch bei den klassischen Netzwerken, nur
von der Sicherheit des Firewalls ab.
2.2 Flexible Losungen uber virtuelle Netze
ATM ermoglicht den Aufbau sogenannter virtueller Netze, die getrennt voneinander auf demselben physikalischen ATM-Netz realisiert werden konnen.
Durch den Einsatz virtueller Netze wird eine ATM-Realisierung des Packet
Screen Konzeptes mit nur einem Switch moglich (siehe Abb. 2).
Die Zusammenlegung der beiden ATM-Switche des internen und des externen Netzes in einem gemeinsamen Switch hat neben der Einsparung eines noch
relativ teuren ATM-Switches zusatzlich den Vorteil, da "native\-ATM Verbindungen3 zu ausgewahlten ATM-Endgeraten wie Telefonanlagen oder VideoKonferenzsystemen direkt unter Umgehung des Firewalls durchgeschaltet werden konnen.
Der Hauptvorteil von virtuellen Netzen ist jedoch die Flexibilitat, mit der
ein Endsystem abhangig von seinen Kommunikations- und Sicherheitsanforderungen dem internen oder dem externen Netz zugeordnet werden kann. Bei
klassischen Netzwerken wird die Zuordnung eines Endsystems zu einem Netz
3 Mit \nativen"-ATM Verbindungen wird die Kommunikation direkt u
ber ATM ohne
zusatzliche CLIP oder LANE Schichten bezeichnet.
3
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Internet
Packet Screen
LAN
ATM Switch
Abbildung 2: Packet Screen Realisierung mit einem Switch
bereits durch die raumlichen Gegebenheiten bestimmt. Um ein Gerat am externen Netz anzuschlieen, mu bei klassischen Netzen ublicherweise der Standort
des Gerates verlagert werden, da eine A nderung der Verkabelung aufgrund von
Entfernungsbeschrankungen und hohem Aufwand in der Regel nicht moglich
ist. U ber die entsprechende Konguration von virtuellen Netzen kann bei ATMNetzen das gleiche Ergebnis auch ohne Topologieveranderungen erreicht werden.
Durch die weitere Separierung eines Netzes in einzelne virtuelle Netze wird
es moglich Sicherheits-Sektionen zu schaen, die miteinander uber Firewalls
verbunden sind. Sicherheitsrisiken z. B. durch \Insider" bleiben so auf einen
kleinen Teil des Netzes beschrankt und kompromittieren nicht wie bei klassischen Firewall-Konzepten ublich das gesamte interne Netz.
Risiken virtueller Netze
Die Sicherheit von virtuellen Netzen hangt von der strikten Trennung der Netze
im Switch ab. Sollte es gelingen, direkt, ohne U berquerung des Firewalls, IPDateneinheiten von einem Netz in ein anderes zu senden, ware die Sicherheit
dieses Aufbaus nicht mehr gewahrleistet. Daher mu verhindert werden, da
ein Angreifer unter Umgehung des Firewalls den Switch anweist, eine Verbindung in das andere Netz aufzubauen. Zudem besteht bei virtuellen Netzen die
Gefahr, da der Switch selbst angegrien wird.
Mit der in Abbildung 2 vorgestellten Losung sind folgende Schwierigkeiten
verbunden:
Der Switch mu gegen Angrie "gehartet\ werden.
Um zu verhindern, da ein Angri direkt auf den Switch erfolgt, mu der
Switch gegen Angrie abgesichert werden. In erster Linie sind hierfur
die Moglichkeiten der Einschrankung des administrativen Zuganges auszuschopfen. Zusatzlich mu die Moglichkeit der Rekongurierung uber
4
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Netzwerkmanagement-Protokolle (SNMP oder ILMI)4 soweit wie moglich
eingeschrankt werden.
U berwachung von "native\-ATM Verbindungen.
Wenn "native\-ATM Verbindungen zugelassen werden, dann konnen kooperierende Insider IP-Tunnel einrichten und so einen (IP-)Firewall umgehen.
Die U berwachung von "nativen\-ATM Verbindungen ist ein bisher ungelostes Problem. Dieses Problem ist nicht auf ATM beschrankt, es bestand auch schon bei klassischen Firewalls, wo nach erfolgreicher Authentisierung (TCP-)Verbindungen durchgeschaltet wurden, uber die ein
Angreifer anschlieend IP-Tunnel aufbauen kann. Dieses Problem wird
durch die kryptographische Absicherung von Protokollen noch verscharft,
da eine U berwachung von verschlusselten Daten nicht mehr moglich ist.
Bei "native\-ATM Anwendungen erschweren die groen Datenmengen die
U berwachung zusatzlich.
Da "native\-ATM Anwendungen heute noch die Ausnahme sind, ist dies
noch kein dringendes Problem. Eine Kontrolle der Endsysteme ist derzeit
der einzige Weg, der auch vorerst wegen der geringen Anzahl der heute
betroenen System noch akzeptabel erscheint.
Trennung der virtuellen Netze im Switch.
Das Hauptproblem virtueller Netze ist die gegenseitige Abgrenzung der
Netze. Da mindestens zwei virtuelle Netze auf demselben ATM-Netz
konguriert werden, besteht die Gefahr einer direkten Kommunikation
zwischen den virtuellen Netzen, unter Umgehung des Firewalls. Zur
Durchsetzung der Trennung virtueller Netze bestehen die folgenden beiden Moglichkeiten:
Konguration von PVCs Um Systeme im jeweils anderen Netz an-
zugreifen, mu der Angreifer zunachst eine ATM-Verbindung aufbauen. ATM unterscheidet zwischen \Permanent Virtual Circuits"
(PVCs), die im Switch konguriert werden mussen, und \Switched
Virtual Circuits" (SVCs), die als Wahlverbindung vom Sender geschaltet werden. Durch die feste Konguration von PVCs kann genau bestimmt werden, welcher Knoten mit welchen anderen Knoten
kommunizieren darf. Damit kein Angreifer SVCs aufbaut, die gegen
die Sicherheitsrichtlinien verstoen, mu die fur SVCs notwendige
Signalisierung auf dem Switch unterbunden werden.
Da fur jede Kommunikationsbeziehung im Switch jeweils ein PVC
konguriert werden mu, steigert sich der Verwaltungsaufwand exponentiell mit dem Hinzufugen weiterer Rechner oder Switche.
4 Neben dem bekanntermaen sicherheitsproblematischen `Simple Network Management
Protocol' gibt es in ATM-Netzen das `Integrated Local Management Interface' als ein weiteres
Managementprotokoll mit neuen Sicherheitsrisiken Benecke et al. 98].
5
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Signalisierung einschranken A hnlich den Filterregeln bei Packet
Screens besteht beim ATM-Switch die Moglichkeit, uber Regeln
zu bestimmen, zwischen welchen Rechnern SVCs geonet werden
durfen. Der Switch vergleicht beim Aufbau eines SVCs die Senderund Empfanger-ATM-Adressen mit einer vom Administrator vorgegebenen Regelliste. Dadurch wird es moglich, die Systeme eines virtuellen Netzes gegen andere Netze hin abzuschotten. (s.
Benecke et al. 98])
3 Performanz von Firewalls in Hochgeschwindigkeitsnetzen
Arbeiten zur Messung der Performanz von Firewalls beschrankten sich bisher
auf einfache Skripte zur Last-Erzeugung Molitor] und auf die Denition von
Setups fur Durchsatzmessungen bei Packet Screens Bradner et al. 96]. Eine
systematische Untersuchung der Performanz von Firewalls wurde bisher noch
nicht vorgenommen. Im folgenden wird sich zeigen, da der meist als erstes
genannte Datendurchsatz (Mbit/s) nicht das wichtigste Performanzkriterium
bei Firewalls ist.
3.1 Performanz von Packet Screens
Bei der Messung der Performanz von Packet Screens wurde zunachst mit einer Datendurchsatzmessung begonnen. Das ATM-Testnetz5 wird dazu in zwei
virtuelle Netze aufgeteilt. Eine mit zwei ATM-Schnittstellen ausgestattete
Workstation wird an beide virtuellen Netze angeschlossen und dient als Packet
Screen. Die Software \IP-Filter" (Version 3.2)6 ermoglicht die Spezikation von
einfachen bis zu hochst komplexen Filterregeln. Mit dem Mewerkzeug \Netperf"7 werden jeweils uber einen Zeitraum von 10 Sekunden Schreibzugrie mit
der angegebenen Lange auf einer bereits geoneten TCP-Verbindung durchgefuhrt. Aus der ubertragenen Nutzdatenmenge kann der Durchsatz berechnet
werden. Wichtig ist bei der Messung der Performanz von Packet Screens, da
jeder Schreibzugri zur Erzeugung genau einer Dateneinheit fuhrt und nicht
mehrere Schreibzugrie zu einer groeren Dateneinheit vereinigt werden, da
dies zu einer Verfalschung der Meergebnisse fuhren kann. Durch die Anpassung der MTU-Groe8 an die jeweilige Schreibzugrislange wird sichergestellt,
da nur Dateneinheiten der gewunschten Lange erzeugt werden.
Die Performanz von Packet Screens hangt primar von der Anzahl der kongurierten Filterregeln ab. Je mehr Filterregeln von der Packet Screen aus5 Das Testnetz besteht zur Zeit aus sechs Sun Ultra Sparc 1/140 (Solaris 2.6), die u
ber
Sun ATM-Schnittstellen (SunATM 2.1) an einen Cisco Lightstream 1010 ATM Switch angeschlossen sind.
6 Verf
ugbar u ber ftp://coombs.anu.edu.au/pub/net/ip-filter/
7 Verf
ugbar u ber ftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/
8 Die \Maximum Transfer Unit" (MTU) gibt die maximale L
ange eines IP-Datagramms
an, da auf einem Netzwerk ubertragen werden kann. Groere IP-Datagramme mussen vor
der U bertragung in kleinere Einheiten aufgebrochen werden.
6
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
gewertet werden mussen, umso mehr Zeit wird fur die U berprufung jeder einzelnen Dateneinheit benotigt. Mehrere Satze von Filterregeln wurden fur die
Performanzmessungen der Packet Screen entwickelt. Die Filterregeln sind so
aufgebaut, da die letzte Filterregel das Weiterleiten der Dateneinheiten der
Messung erlaubt. Dadurch wird sichergestellt, da fur jede ubertragene Dateneinheit alle Filterregeln ausgewertet werden mussen. Diese Vorgehensweise
orientiert sich an dem in Bradner et al. 96] vorgeschlagen Vorgehen.
Abbildung 3 zeigt die erreichten Durchsatze bei drei Filterkongurationen
mit 0, 100 und 250 Regeln im Vergleich zum Durchsatz auf einer direkten
TCP-Verbindung und im Vergleich zum berechneten theoretischen maximalen
Durchsatz.9 Zu erkennen ist, da mit der Packet Screen bereits ohne kongurierte Filterregeln unterhalb einer Schreibzugrislange von 2048 Byte nicht
mehr der volle Durchsatz erreicht wird. Erst im Bereich von 2048 Byte bis zur
MTU-Groe uberdecken sich die Kurven, und es wird auch durch die Packet
Screen ein maximaler Durchsatz von uber 134 Mbit/s erreicht. Die Aussage,
da eine Packet Screen \Wire-Speed" ermoglicht, sagt daher wenig uber die
Leistungsfahigkeit einer Packet Screen aus, wenn nicht gleichzeitig die Datagrammlange mit der dieser Durchsatz erreicht wurde, angegeben wird.
Vergleich von theoretischem und gemessem TCP−Durchsatz
140
theoretisch erreichbar
gemessen Host zu Host
Packet Screen: 0 Regeln
Packet Screen: 100 Regeln
Packet Screen: 250 Regeln
120
TCP−Durchsatz [Mbit/s]
100
80
60
40
20
0
4
8
16
32
64
128
256
512
Schreibzugriffslänge [Byte]
1024
2048
4096
8192
Abbildung 3: Datendurchsatz uber Packet Screen
Bei den verschiedenen Packet Screen Kongurationen und bei der direkten
Host zu Host Messung wird fur groe Nachrichtenlangen ein maximaler Durch9 Der f
ur OC-3c ATM-Netze angegebene maximale Durchsatz von 155 Mbit/s steht nicht
voll fur die U bertragung von Nutzdaten zur Verfugung, da Protokoll-Informationen, wie IPund TCP-Header, ubertragen werden mussen. Da die Protokoll-Informationen im allgemeinen unabhangig von der Nachrichtenlange eine feste Lange haben, ist der Overhead bei kurzen
Datagrammen hoher. Die \Sagezahn" Funktion wird durch das Anpassen der Datenlange
(Padding) an die feste Lange der ATM-Zellen verursacht.
7
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
satz von 134 Mbit/s erreicht, der jedoch zu den kurzeren Nachrichtenlangen hin
in Abhangigkeit von der Anzahl der Filterregeln unterschiedlich fruh abfallt.
Die Ursache fur diesen starken Abfall wird oensichtlich aus der Berechnung der
Anzahl der Datagramme, die benotigt wird, um die an den einzelnen Mepunkten gemessenen Datendurchsatze zu erzielen. Die Ergebnisse in Abbildung 4
zeigen, da der starke Durchsatzruckgang bei den kurzeren Nachrichtenlangen
auf das Erreichen des maximalen Datagrammdurchsatzes zuruckzufuhren ist.
Wahrend auf einer direkten Host zu Host Verbindung knapp 16.000 Datagramme pro Sekunde von einer Workstation generiert werden konnen, verarbeitet
eine Packet Screen nur maximal 8.000 Datagramme pro Sekunde. Durch Hinzufugen von Filterregeln wird dieser Wert weiter reduziert. Zum Erreichen des
theoretisch moglichen Durchsatzes sind bei kurzen Nachrichtenlangen ( 40
Byte) in einem OC-3c ATM-Netz (155 Mbit/s) fast 180.000 Datagramme pro
Sekunde notwendig.
Durchsatz in Datagrammen/s, theoretisch, Host <−> Host und über Packet Screen
18000
theoretisch
Host zu Host
0 Regeln
100 Regeln
250 Regeln
16000
Durchsatz [Datagramme/s]
14000
12000
10000
8000
6000
4000
2000
0
1024
2048
4096
8192
Schreibzugriffslänge [Byte]
Abbildung 4: Datagramme/sec uber Packet Screen
In der Praxis werden die zum Erreichen des maximalen Datendurchsatzes
notwendigen Datagrammlangen oberhalb von 2048 Byte kaum erreicht. Dies
hangt damit zusammen, da die meisten Protokolle nur kurze Nachrichten
ubertragen. Im Extremfall wird ein Tastendruck (Nachrichtenlange 1 Byte)
einer Telnet-Verbindung in einem Datagramm versendet. Wird das ATM-Netz
als \Backbone" zur Verknupfung einer groen Zahl von Ethernet und FastEthernet Segmenten eingesetzt, so wird die Lange der meisten Dateneinheiten
durch die MTU von Ethernet auf 1500 Byte begrenzt.10 Dadurch konnen auch
bei Protokollen wie FTP, die zur U bertragung von groen Datenmengen die10 Bei CLIP Laubach 94] sind demgegen
uber als MTU 9180 Byte vorgegeben und sogar
noch groere Werte bis 64 KByte aushandelbar.
8
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
nen, keine Datagrammlangen oberhalb von 1500 Byte verwendet werden. Bei
einer Stichprobe wurden in einem typischen Ethernet durchschnittliche Nachrichtenlangen von 500 Byte gemessen. U ber eine Packet Screen werden bei dieser Nachrichtenlange Durchsatze von 30 bis 40 Mbit/s gemessen. Theoretisch
moglich waren hier jedoch um die 120 Mbit/s.11 Um diesen Wert zu erreichen,
ware eine Vervierfachung des Datagrammdurchsatzes der Packet Screen auf
etwa 30.000 Datagramme pro Sekunde notwendig.
3.2 Performanz von Proxy-Servern
Proxy-Server sind Anwendungen, die auf einer Bastion oder einem GatewayFirewall laufen. Sie kontrollieren nicht nur die Protokoll-Header, wie Packet
Screens, sondern erhalten Zugri auf den Inhalt der ubertragenen Daten und
ermoglichen so eine sehr viel grundlichere Kontrolle.12 Der Proxy-Server nimmt
die Verbindung des Klienten an und onet nach erfolgreicher Authentisierung
eine Verbindung zum gewunschten Empfanger. Anschlieend werden die Daten
zwischen diesen beiden Verbindungen kopiert und dabei gegebenenfalls der Inhalt uberpruft. Die Groe der Datenblocke, die vom Proxy-Server zwischen den
Verbindungen kopiert werden, wird als Kopierlange bezeichnet. Sie bestimmt
entscheidend den Datendurchsatz durch den Proxy-Server. Abbildung 5 zeigt
die im Testnetz gemessenen Datendurchsatze fur ausgewahlte Kopierlangen.
70 Byte Kopierlange (Durchsatz knapp 7 Mbit/s) emuliert ein zeilenweises Kopieren. Manche Proxy-Server implementieren sogar ein byteweises Kopieren,
wodurch ein maximaler Durchsatz von 0,1 Mbit/s nicht uberschritten werden kann. Erst bei der maximalen Kopierlange von 64 KByte wird fur groe
Schreibzugrislangen ein Durchsatz von 134 Mbit/s erreicht. Den gemessenen
Werten liegt lediglich das Kopieren der Daten zwischen den beiden Verbindungen zugrunde, aufwendige U berprufungen der ubertragenen Daten (z. B. VirenScanner) lassen deutliche Durchsatzruckgange erwarten.
Wichtiger als der Datendurchsatz ist die Verbindungsaufbauzeit durch einen
Proxy-Server. Da Proxy-Server die zweite Verbindung erst onen, nachdem
sich der Benutzer beim Proxy-Server authentisiert hat, steigt die insgesamt
benotigte Zeit, um einen entfernten Server uber eine Proxy-Server zu erreichen. Abhangig von der auf einer Verbindung zu ubertragenden Datenmenge
fallt die Verbindungsaufbauzeit unterschiedlich stark ins Gewicht. Abbildung 6
zeigt die Summe aus Verbindungsaufbauzeit und Datenubertragungszeit (Gesamtdauer) fur unterschiedliche Datenmengen. Die ubertragenen Daten konnen
zum Beispiel Web-Seiten oder Bilder sein. Oensichtlich ist, da die Verbindungsaufbauzeit gegenuber der Datenubertragungszeit den dominierenden Faktor darstellt. Die Transaktionslange betragt beim Standard Proxy-Server fur
11 Es spielt dabei keine Rolle, da auf einer direkten Host zu Host Verbindung nur etwa
60 Mbit/s gemessen wurden, da an der Packet Screen die Datenstrome von Verbindungen
zwischen vielen verschiedenen Rechnerpaaren ankommen, deren akkumulierte Last durchaus
120 Mbit/s ausmachen kann.
12 Mit Proxy-Server k
onnen zugegriene Web-Seiten und ubertragene E-Mails auf JavaApplets oder Computer-Viren uberpruft werden. Auch die Authentisierung von Zugrien
uber Einmal-Paworte kann in Proxy-Servern realisiert werden.
9
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Durchsatz TCP−Daten über experimentellen Proxy−Server
140
TCP−Durchsatz [Mbit/s]
120
100
80
60
40
20
0
512
1024
2048
4096
8192
Schreibzugriffslänge [Byte]
Kopierlänge
des Proxies:
70 Byte
1 KByte
8 KByte
64 KByte
Host zu Host
Abbildung 5: Durchsatz uber experimentellen Proxy-Server
16 KByte lange Nachrichten 0,03 Sekunden. Fur doppelt so lange Nachrichten
(32 KByte) werden immer noch 0,03 Sekunden benotigt. Bei herkommlichen
Ethernets (10 Mbit/s) mit geringem Datendurchsatz steigen die Kurven sehr
viel steiler an, so da die feste Verbindungsaufbauzeit bei groeren Nachrichten
kaum noch eine Rolle spielt.
Gesamtverbindungslänge für unterschiedliche Nachrichtenlängen
0.1
Standard Proxy
Multithreaded Proxy
Host zu Host
0.09
0.08
Gesamtdauer [s]
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
16
32
64
128
256
512
1024
Nachrichtenlänge [KByte]
Abbildung 6: Anteil des Verbindungsaufbaus an der U bertragung
10
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Die gemessenen Durchsatze und die Verlangerung der Verbindungsaufbauzeiten orientieren sich an der Benutzersicht auf einen Proxy-Server und zeigt,
welche Performanzeigenschaften der Benutzer von einem Proxy-Server in einem
Hochgeschwindigkeitsnetz erwarten kann. Fur den Betreiber des Firewalls ist
es jedoch mindestens ebenso wichtig, wieviele parallele Verbindungen gleichzeitig uber den Firewall gefuhrt werden konnen. Hierzu stehen noch detaillierte
Messungen aus. Erste Ergebnisse zeigen bereits jetzt, da abhangig vom Typ
des Proxy-Servers deutlich weniger als 100 aktive Verbindungen13 zur selben
Zeit von einem Proxy-Server verarbeitet werden konnen. Die in ATM-Netzen
zu erwartende Last und die steigende Komplexitat von anwendungsspezischen
Analysen auf Proxy-Servern (Viren-Scanner, Verschlusselung usw.) machen eine Verteilung auf mehrere Bastionen notwendig.
4 Parallelisierungskonzepte fur Firewalls
Derzeit werden im \DFN Firewall-Labor fur Hochgeschwindigkeitsnetze" (DFNFWL) verschiedene Ansatze fur Hochgeschwindigkeitsrewalls untersucht. Dabei sollen sowohl Losungen fur skalierbare Packet Screens als auch hochperformante Proxy-Server entwickelt werden.
Bei Packet Screens mu als wichtigstes Ziel der Datagrammdurchsatz erhoht
werden. Hierzu ist eine moglichst gleichmaige Aufteilung der Datagramme auf
parallele Packet Screens ein vielversprechender Ansatz. Um auszuschlieen,
da der Verteilmechanismus selbst zum Engpa und zur zentralen Fehlerquelle wird, entscheidet jede einzelne Packet Screen selbst (dezentral) fur welche
Datagramme sie zustandig ist. Dafur mu jede der parallelen Packet Screens
zunachst jedes Datagramm empfangen, kann aber sofort anhand von Protokollinformationen entscheiden, ob dieses Datagramm von einer anderen Packet
Screen verarbeitet werden mu. In dem Fall kann die Dateneinheit schnell
verworfen werden und belastet das System nicht.
Fur Proxy-Server in Hochgeschwindigkeitsnetzen gibt es zwei wichtige Ziele: die Verringerung der Verbindungsaufbauzeiten und die Steigerung des Gesamtdurchsatzes bei einer groen Anzahl von parallelen Verbindungen. Die
Verringerung der Verbindungsaufbauzeit erfordert eine Veranderung der verwendeten Protokolle, um unnotig hauges Auf- und Abbauen von Verbindungen zu verhindern oder um notwendige Verbindungen fruhzeitig vorauszusehen
und bereits vorab zu eronen. Fur die Steigerung des Gesamtdurchsatzes werden zur Zeit mehrere Verfahren zur Lastverteilung auf parallele Proxy-Server
untersucht. Ellermann et al. 98]
5 Abschlieende Bewertung
Die ATM-Technologie birgt fur Firewalls sowohl Chancen als auch Probleme.
Mit Hilfe von virtuellen Netzen wird es zukunftig besser moglich sein, die logische Netzstruktur an den Sicherheitsstrukturen auszurichten. U ber virtuelle
13 Eine inaktive Verbindung, etwa beim Warten auf Benutzereingaben, bindet zwar auch
Betriebsmittel, z. B. Speicher, belastet den Firewall jedoch viel geringer.
11
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.
Netze konnen selbst raumlich getrennte Hosts in einem Netz verbunden und
gleichzeitig abgeschottet werden, falls dies aus Sicherheitsgrunden erforderlich
ist. Der U bergang zwischen virtuellen Netzen mu dabei uber Firewalls abgesichert werden. Dies erfordert die konsequente Trennung der virtuellen Netze
durch den Switch.
Die hohen Datenraten in ATM-Netzen stellen ein groes Performanzproblem fur herkommliche Firewalls dar. Messungen haben zwar gezeigt, da das
Umkopieren von Daten mit 134 Mbit/s bei Packet Screens und auch bei ProxyServern selbst mit herkommlichen Workstations moglich ist. Dieser Durchsatz
wird aber nur mit sehr groen Dateneinheiten erreicht, die in realen Netzen
kaum vorkommen. Fur Packet Screens mu der Datagrammdurchsatz entscheidend erhoht werden, um auch in ATM-Backbones den notwendigen Durchsatz
zu erreichen.
Bei Proxy-Servern fuhren die hohe Verbindungsaufbauzeiten und die begrenzte Anzahl der parallelen Verbindungen zu Performanzproblemen in ATMNetzen.
Zukunftige Firewall-Konzepte fur Hochgeschwindigkeitsnetze durfen sich
nicht allein an den Anforderungen von aktuell verbreiteten 100 Mbit/s FastEthernet oder 155 Mbit/s ATM-Netzen orientieren, sondern mussen skalierbar
sein fur Netze mit sehr viel hoheren Datenraten. Hierfur sind parallele Packet
Screens und parallele Proxy-Server der richtige Ansatz.
Literatur
Benecke et al. 98] Carsten Benecke, Uwe Ellermann. "Securing 'Classical IP over
ATM Networks' \. 7th USENIX Security Symposium, 26.-29. Januar 1998,
San Antonio, Texas, 1998.
Bradner et al. 96] Scott Bradner, Jim McQuaid. "Benchmarking Methodology for
Network Interconnect Devices\. RFC 1944, Mai 1996.
(ftp://nic.nordu.net/rfc/rfc1944.txt)
Chapman et al. 95] D. Brent Chapman, Elizabeth D. Zwicky. "Building Internet
Firewalls\. O'Reilly & Associates, September 1995.
Cheswick et al. 94] William R. Cheswick, Steven M. Bellovin. "Firewalls and Internet Security: Repelling the wily Hacker\. Addison-Wesley, 1994.
Dorling et al.96] \Internetworking over ATM. An Introduction". Prentice Hall, 1996
Ellermann 94] Uwe Ellermann. "Firewalls: Isolations und Audittechniken zum
Schutz von lokalen Computer-Netzen\. DFN-Bericht Nr. 76, September
1994.
Ellermann et al. 98] Uwe Ellermann, Carsten Benecke. "Parallele Firewalls: skalierbare Losungen fur Hochgeschwindigkeitsnetze\. DFN-CERT Workshop
1998, 4.-5. Marz 1998, Hamburg, 1998.
Laubach 94] Mark Laubach. "Classical IP and ARP over ATM\. RFC 1577, Januar
1994. (ftp://nic.nordu.net/rfc/rfc1577.txt)
Molitor] Andrew Molitor. "Measuring Firewall Performance\.
(http://www.clark.net/pub/mjr/pubs/fwperf/molitor.htm)
12
Veröffentlicht in "Deutscher Internet Kongress 1998", 5. und 6. Mai 1998, CongressCenter Messe Frankfurt.