Von: Kai-Oliver Detken, Bernd Reder
Dank des Standards IPsec ist der Anwender heute nicht mehr auf herstellerspezifische Extranet-Lösungen angewiesen. Trotzdem treten immer wieder Probleme mit der Interoperabilität auf. Das hat zwei Ursachen: Manche Anbieter interpretieren die Spezifikationen sehr großzügig, andere fügen proprietäre Funktionen hinzu. Um die Kompatibilität zwischen den Produkten zu erhöhen und die Sicherheit zu garantieren, stellt die ICSA (http://www.icsa.net) Zertifikate aus. Diese Organisation testet und bewertet Sicherheitslösungen für Netzwerke. Allerdings ist ein Zertifikat der ICSA noch keine Garantie, daß eine IPsec-Komponente mit anderen zusammenarbeitet. Das liegt unter anderem daran, daß IPsec eine "junge" Spezifikation ist. Experten arbeiten bereits an der Version 1.1, die Zertifizierungsstellen (Certificate Authorities) und Tunnels über variierende Subnetze berücksichtigt.
Bei Extranets auf Grundlage von IPsec sind folgende Punkte zu beachten:
-Performance,
-Migration,
-Zugriffssicherheit,
-Schlüsselverwaltung (Key-Management) und
-Zertifikate.
Die Sicherheitsmechanismen von IPsec wirken sich nicht nachteilig auf die Performance im internen IP-Netz (Intranet) aus, weil diese Verfahren nur im Extranet und am Netzrand in der Firewall oder dem Router ansetzen. Anders sieht es bei den Teilnehmern eines Extranets aus. Sie müssen mit Leistungseinbußen rechnen.
IPsec verwendet zwei Sicherheitsmechanismen: die "Encapsulated Security Payload" (ESP) und den "Authentication Header" (AH). Die ESP garantiert die Integrität und Vertraulichkeit von IP-Paketen. Außerdem spielt sie bei der Authentifizierung eine Rolle, vor allem in Verbindung mit dem Authentication Header.
Schutz von IP-Paketen durch Authentication Header
Die Daten werden verschlüsselt und auf folgende Weise übertragen:
-im Transportmodus: Hier wird lediglich die Nutzlast verschlüsselt;
-im Tunnelmodus: Das komplette IP-Paket (Header und Daten) wird chiffriert und erhält einen neuen IP-Header sowie eine neue Adresse. Die "wahre" Zieladresse bleibt verborgen und wird erst beim Empfänger entschlüsselt.
AH plaziert vor den TCP-Header einen verschlüsselten Authentifikator. Die Nutzdaten bleiben unchiffriert. Der Sender erzeugt den Authentication Header vor Beginn der Kommunikation mit Hilfe eines Schlüssels, den auch der Empfänger zur Überprüfung des Paketes einsetzt. Das Verfahren läßt sich separat oder in Verbindung mit ESP einsetzen.
Asymmetrische Verschlüsselungsverfahren sind sicherer als symmetrische Methoden, vor allem dann, wenn lange Schlüssel eingesetzt werden, dafür aber deutlich langsamer. Das bestätigten Messungen in einem Fast-Ethernet-LAN zwischen zwei PCs unter Linux mit Hilfe der Testsoftware ttcp. Im unverschlüsselten Modus betrug der Durchsatz 88 MBit/s. Mit AH (HMAC-MD5) sank er auf 20 MBit/s, beim Einsatz von ESP (Triple-DES-MD5) auf 2,56 MBit/s. Wurden beide Techniken zusammen verwendet, betrug die Datenübertragungsrate noch 2,48 MBit/s.
IPsec beeinflußt normalerweise keine anderen Protokolle oder Anwendungen, weil es unterhalb der Transportschicht des OSI-Referenzmodells arbeitet. Das erlaubt eine Ende-zu-Ende-Kommunikation über beliebige Netze, ohne daß auf vorhandene Hard- und Software Rücksicht genommen werden muß. IPsec läßt sich deshalb auf einfache Weise in IPv4-Umgebungen integrieren. Eine Ausnahme ist SNA über IP: IPsec verschlüsselt einige für SNA notwendige Informationen, so daß in diesem Fall die Migration schwieriger ist.
Zwei Verfahren für die Schlüsselverwaltung
In Extranets ist neben der Authentifizierung die Verschlüsselung wichtig. Deshalb spielen dort ESP und der Tunnelmodus eine wichtige Rolle. Gegen Replay-Angriffe, bei denen ein altes Paket wieder in den Datenstrom eingebracht wird und dann als gültig erscheint, bietet IPsec derzeit keinen Schutz. Das ist Aufgabe der Anwendungen. Abhilfe soll eine Erweiterung des IPsec-Protokolls schaffen, die derzeit diskutiert wird.
Für die Schlüsselverwaltung gibt es noch kein einheitliches Verfahren, weil die Internet Engineering Task Force (IETF) zunächst die IP-Sicherheitsfunktionen spezifizierte, erst danach ein Protokoll für das Key-Management. Das National Institute of Standards and Technology (NIST) und Cisco legten zwei Entwürfe vor. Der erste sieht vor, die Schlüsselinformationen in einem erweiterten Header zusammen mit dem IP-Paket zu übertragen. Ciscos Ansatz verwendet ein separates Protokoll auf der Anwendungsebene für die Schlüsselverwaltung. Suns "Simple Key-Management over IP" (Skip) ist ein Beispiel für den ersten Ansatz, während das "Internet Security Association and Key Management Protocol" (ISAKMP) für die zweite Lösung steht.
Das Key-Management sollte den Austausch von Schlüsseln zwischen den Teilnehmern im Extranet automatisch regeln. Vor allem in großen Netzen ist eine manuelle Konfiguration der Security Associations (SA) zwischen den Gateways (Firewalls) und Hosts (Client/Server) zu aufwendig. Zusätzlich müssen die Sicherheitsrichtlinien der Teilnehmer angeglichen werden. "Internet Key Exchange" (IKE), ein Verfahren, das auf ISAKMP basiert, unterscheidet zwei Phasen: die Authentifizierung und das Generieren des Schlüssels. Eine Security Association ist ein "Vertrag", der für eine Kommunikationsbeziehung eine Reihe von Sicherheitsparametern festlegt. Diese sind durch die Zieladresse und einen "Security Parameter Index" (SPI) definiert. Den SPI und den Inhalt der Security Association fixiert der Empfänger.
Die Authentifizierung des Kommunikationspartners in einem Extranet sollte mit Hilfe der asymmetrischen Verschlüsselung erfolgen. Jeder Teilnehmer erhält dabei ein asymmetrisches Schlüsselpaar - einen Public und einen Private Key. Öffentliche Schlüssel bekommt der Anwender in Form von Zertifikaten gemäß X.509. Ein Zertifikat ist ein "Ausweis", den ein Trust Center oder eine Regulierungsbehörde dem Teilnehmer über öffentlich zugängliche Verzeichnisse (X.500) zur Verfügung stellt. Die Private Keys enthalten die persönlichen Informationen des Eigentümers.
Produkte für Extranets
Im folgenden gehen wir auf drei Produkte ein, die eine sichere Kommunikation über ein Extranet ermöglichen. Das erste stammt von der Nürnberger Firma NCP. Es verbindet Außenstellen, Telearbeiter oder Mitarbeiter im Außendienst mit einer Zentrale. Zusätzlich erlaubt die Lösung den Clients, Tunnel zum firmeneigenen "Network Access Server" (NAS) aufzubauen, und dies unabhängig von der Infrastruktur des Internet-Serviceproviders. Auch ohne IPsec kann der Benutzer somit eine Ende-zu-Ende-Kommunikation herstellen und behält trotzdem die Kontrolle über das Sicherheitsmanagement.
Die Lösung ist für ISDN, das analoge Telefonnetz, X.25 und GSM ausgelegt. Neben IP unterstützt sie IPX, SNA und Netbios. Als Tunnelverfahren stehen das "Layer 2 Forwarding Protocol" (L2F) sowie das "Layer 2 Tunneling Protocol" (L2TP) zur Auswahl. Eine IPsec-Erweiterung ist geplant.
Zum NCP-Produktfolio für Extranets gehören:
-"Narac Enterprise VPN": ein VPN-Gateway für die Firmenzentrale,
-der "Multi Protocol Router for Global Access mit VPN" (MPR/GA VPN): eine Router-Software für dezentrale LANs und
-die "Remote Workstation for Global Access mit VPN" (RWS/GA VPN): eine Kommunikationssoftware für Workstations.
Das VPN-Gateway wird über VPN-Kommunikationsverbindungen verwaltet. Um die Zugriffssicherheit zu garantieren, verwendet NCP das L2F-Protokoll, eine Authentifizierung über Radius sowie digitale Signaturen. Die Daten werden mit Triple DES und Blowfish dynamisch verschlüsselt. Als deutscher Hersteller unterliegt NCP nicht den amerikanischen Ausfuhrbestimmungen für Verschlüsselungsprodukte, sprich der Begrenzung auf Schlüssel mit 56 Bit. Triple DES mit 168 Bit erlaubt einen wirksamen Schutz sensitiver Daten. Der Blowfish-Algorithmus geht mit einer maximalen Schlüssellänge von 448 Bit noch einen Schritt weiter und weist zudem eine bessere Performance auf.
Gebühren sparen durch Verbindungsmanagement
Bestandteil der Remote-Access-Lösung ist ein Verbindungsmanagement inklusive Short-Hold-Modus. Die Software trennt nach einer bestimmten Zeit ohne Datentransfer lediglich die physikalische Verbindung und erhält die logische aufrecht. Dadurch läßt sich die Verbindung innerhalb weniger Sekunden erneut aufbauen.
Die "Remote Workstation RWS/GA VPN" von NCP führt sofort nach Aufbau eines Tunnels eine durchgängige Verschlüsselung (Ende zu Ende) durch, nicht erst dann, wenn sich ein Anwender in das Extranet eingeloggt hat. Das Tunnelende bildet bei NCP nicht der IP-Router, sondern das VPN-Gateway. Es übernimmt automatisch alle Aufgaben eines NAS, auch die Zuteilung der IP-Adresse aus dem Firmennetz.
An welcher Stelle das VPN-Gateway plaziert wird, also vor oder hinter einer Firewall, hängt von den Anforderungen ab. Grundsätzlich ist das VPN-Gateway die zentrale Stelle für die Authentifizierung, so daß alle Anforderungen eines "Secure-Servers" erfüllt werden. Verwalten läßt sich das System mittels SNMP oder anderer Managementsysteme. Neben OS/2 werden Windows-95/98- und NT-Clients unterstützt.
Secure VPN mit Layer3-Tunneling-Switch
Mit "Secure VPN" stellte 3Com eine Extranet-Lösung mit interessanten Leistungsmerkmalen vor. Sie stellt im Transportmodus IPsec-Funktionen bereit. Für den Aufbau eines Tunnels durch das Internet ist das "Point-to-Point Tunneling Protocol" (PPTP), eine Entwicklung von 3Com und Microsoft, zuständig. Künftig soll auch das "Layer 2 Tunneling Protocol" (L2TP) unterstützt werden. Außerdem kann der Anwender PPTP gemeinsam mit IPsec im Transportmodus einsetzen.
Wie bei der NCP-Lösung bezieht "Secure VPN" mobile Teilnehmer sowie unterschiedliche Protokolle mit ein, etwa IPX, Appletalk und Netbios. Das Standard-Tunnelprotokoll ist IP, das der Anwender durch ATM oder Frame-Relay ersetzen kann. Für die Softwarelösung benötigt der Benutzer einen "Tunnel Initiator" (TI), ein geroutetes Netz und "Tunnel Terminators" (TT). Ein Mitarbeiter kann beispielsweise einen Tunnel von seinem Laptop mit der entsprechenden Software aufbauen.
Besonders interessant ist die "Secure VPN"-Variante, die mit Layer-3-Tunnel-Switches arbeitet. Das Gerät erzielt eine deutlich höhere Leistung als herkömmliche Firewalls mit VPN-Funktionen oder Softwarelösungen. Bei eingeschalteter Verschlüsselung und Kompression routet es bis zu 180000 Pakete pro Sekunde und unterstützt mehr als 2000 Tunnels. Die Vorteile dieses Ansatzes sind
-die Skalierbarkeit: Vorkonzentration von Tunneln und Lastverteilung zu verschiedenen TTs,
-die Sicherheit: Ein Tunnel bis zur Anwendung ersetzt den Netzzugang. Hinzu kommt, daß die innere Firewall effizienter arbeiten kann und
-die Protokollumsetzung: Umwandlung des Tunnelprotokolls sowie Wandlung verschlüsselter in unverschlüsselte Tunnel.
Zur Verschlüsselung wird Microsofts "Point-to-Point Encryption" (MPPE) in der 40-Bit-Version angeboten, die auf 128 Bit erweitert werden kann. MPPE verschlüsselt PPP-Pakete des Clients, bevor sie in den PPTP-Tunnel geschickt werden. Für die Benutzererkennung wird das "Challenge Handshake Protocol" (MS-CHAP) verwendet, allerdings nur dann, wenn IPsec nicht eingesetzt wird.
Firewall-1 für Solaris und NT
"Firewall-1" von Checkpoint wurde ursprünglich für Solaris entwickelt, ist mittlerweile jedoch auch für Windows NT verfügbar. Die Software kontrolliert Zugriffe auf das Netz, indem sie jedes Informationspaket untersucht. Prüf-, Filter- und Alarmfunktionen identifizieren und markieren verdächtige Daten. Zusätzlich authentifiziert Firewall-1 Benutzer und verwaltet deren Kenndaten. Optional steht eine Datenverschlüsselung zur Verfügung.
Eine Besonderheit ist die "Stateful Inspection"-Technik. Das System analysiert den Netzwerkverkehr und erzeugt daraus Zustandstabellen, die es dem Systemverwalter erlauben, Pakete nachzuverfolgen. Ab Version 4 steht eine Verschlüsselung in Verbindung mit IPsec zur Verfügung.
Optional lassen sich Virtuelle Private Netze zur sicheren Verbindung von Firmennetzen über mehrere Firewall-1-Systeme hinweg aufbauen. Grundlage dieser Lösung ist eine Software, welche für die Zugriffskontrolle, Au-thentifizierung, NAT, "Content Security" und unternehmensweites Policy-Management zuständig ist. Es gibt Versionen für unterschiedliche Betriebssysteme, wie Solaris und NT. Linux soll in Kürze folgen.
Hinzu kommt das VPN-Paket "VPN-1 Gateway", mit dem der Anwender Extranets aufbauen kann, die gängige Algorithmen und Protokolle (IPsec, IKE, Triple-DES) verwenden. Eine solche Komplettlösung besteht aus
-einem VPN-1-Gateway: Softwarelösung, die Firewall-1- und VPN-Technik miteinander verbindet,
-dem Remote Link: einer Hard- und Software für den sicheren Internet-Zugang für Außenstellen oder Zweigniederlassungen,
-Securemote: einer Client-basierten Verschlüsselungssoftware, die einzelnen Rechnern unter Windows 95/98 oder NT beziehungsweise Remote-Anwendern VPN-Funktionen zur Verfügung stellt,
-Certificate Manager: einem PKI-System für den Einsatz öffentlicher Schlüssel. Es arbeitet mit Zertifizierungsstellen und LDAP-Verzeichnisdiensten zusammen,
-der Accelerator Card: Diese PCI-Karte für Solaris oder NT beschleunigt die Datenverschlüsselung auf bis zu 45 MBit/s.
Firewall-1 ist ein ausgereiftes Produkt, das den Schwerpunkt auf die Firewall-Lösung legt. Erweiterungen für Extranet lassen sich einbauen, wobei jedoch bei der Performance Abstriche zu machen sind.
Standardlösungen im Kommen
Abschließend läßt sich feststellen, daß der IPsec-Standard immer noch im Fluß ist und Herstellern Raum für eigene Implementierungen bietet. Gegenwärtig schreibt IPsec für die Authentifizierung den MD5-Hash-Algorithmen mit 128 Bit vor, für die Datenverschlüsselung den "Data Encryption Standard" -Algorithmus mit 56 Bit im Cipher Block Chaining Mode (CBC). Extranet- und VPN-Anbieter bieten inzwischen bessere Methoden an, die allerdings nicht in heterogenen Umgebungen eingesetzt werden können.
Hinzu kommt, daß viele Hersteller das Key-Management vernachlässigen. Das heißt, die Kommunikationspartner müssen die Schlüssel manuell vereinbaren und austauschen. Besserung verspricht der Standard IKE der IETF. Auch die Schwierigkeiten im Zusammenhang mit der Übermittlung von SNA-Verkehr über Extranets dürften in künftigen Versionen von IPsec überwunden werden. Somit ist davon auszugehen, daß in absehbarer Zeit standardkonforme Lösungen verfügbar sind.
Literatur
[1] Detken, K.-O.: Geschlossene Gesellschaft - Serie Extranet, Teil 1: Grundlagen. gateway 4/99, S. 28 ff.
[2] Detken, K.-O.: Safer Net - Serie Extranet, Teil 2: Sicherheit. gateway 5/99, S. 82 ff.
[3] Detken, K.-O.: Die dicksten Dinger - Serie Extranet, Teil 3: Anwendungsbeispiele. gateway 6/99, S. 70 ff.
Web-Links
VPNs und Sicherheit: http://www.data.com/lab_tests/first.html