Modernes Netzwerkdesign

Segmentierung für Security

09. März 2005, 00:16 Uhr   |  Enno Rey/wj Enno Rey (CISSP, CISA) ist Gründer und technischer Geschäftsführer des in Heidelberg ansässigen Security-Dienstleisters ERNW.

Das klassische Firewall-Modell wird nicht jeder Bedrohung für Netzwerke gerecht. Mit gezielten organisatorischen Maßnahmen läst sich die Sicherheit deutlich verbessern.

Das "klassische Firewall-Modell" für die Netzwerksicherheit ist den Anwendern der
Informationstechnologie nund schon seit Jahren bestens vertraut. Hier ist am Übergang vom internen
Netz ("LAN") zum Internet eine Firewall installiert, die den an dieser Stelle verarbeiteten
Netzwerkverkehr prüft und regelt. Diese Firewall kann dabei durchaus aus mehreren Komponenten
bestehen; es handelt sich also eher um ein Gesamtsystem als zwingend um einen einzigen Rechner. So
können etwa neben der eigentlichen Firewall-Komponente (dem in der traditionellen Firewall-Theorie
so genannten "Bastion Host") auch Antiviren-Gateways oder Content Filter enthalten sein.

Noch immer entspricht dies dem in vielen Organisationen anzutreffendem Design. Zentrale
Grundbegriffe dieses Ansatzes sind das Konzept der "Perimeter Defense" oder "Border Defense" (mit
der Annahme, dass Gefahren an Netzwerkgrenzen abgewehrt müssen) und das Konzept eines "Choke Points"
, über den der gesamte Netzwerkverkehr fliessen muss, um geprüft und gefiltert zu werden. Dieses
Design geht implizit von den folgenden fünf Grundannahmen aus:

Alle internen Systeme sind vertrauenswürdig (trusted). Diese Annahme liegt
etwa auch der Konfiguration eines Cisco-Pix-Systems zugrunde, wo nach der initialen Definition des
Security Levels aller Schnittstellen (der den Grad an Vertrauenswürdigkeit des jeweils
angeschlossenen Netzes widerspiegelt) per Default ein Netz mit höherer Vertrauenswürdigkeit (etwa
mit Level 100) mit Netzen niedrigerer Vertrauenswürdigkeit (beispielsweise Level 10) ungehindert
kommunizieren kann, der umgekehrte Fall (Kommunikation von "10 nach 100") aber zunächst nicht
möglich ist. Die Netzwerkwelt wird bei dieser Denkweise in "gut" (intern) und "schlecht" (extern,
Internet) unterteilt.

Alle internen Systeme haben denselben Schutzbedarf (der durch die am zentralen
Netzübergang wirkende Firewall realisiert wird).

Es gibt eine klare Grenze zwischen "innen" und "außen" (und genau an dieser
Stelle wirkt die Firewall).

Gefahren kommen in erster Linie von "außen".

Die Firewall kann die Gefahren erkennen und abwehren.

Betrachtet man diese Grundannahmen genauer, stellt man fest, dass die Realität heutiger Netze
durchaus anders aussieht. Sie sollen daher einzeln diskutiert werden.

Annahme 1

Alle internen Systeme sind vertrauenswürdig (trusted).

In den internen Netzen sind zunehmend Geräte im Einsatz, die dort nur temporär eingesetzt werden
und sich oft auch "außerhalb" befinden (etwa Laptops, PDAs oder sogar private PCs). Sie weisen
damit sicher nicht den Grad an Vertrauenswürdigkeit auf, der für andere Systeme gilt, die das
interne Netz nie verlassen.

Alle Systeme werden darüber hinaus von Menschen bedient, was für den erfahrenen
Sicherheitspraktiker die Vertrauenswürdigkeit weiter einschränken wird (schließlich machen Menschen
Fehler oder verstoßen sogar fahrlässig und mutwillig gegen Richtlinien).

Die Sicherheitsgrad der Systeme hängt weiterhin von ihrer konkreten Konfiguration ab
(Patch-Level, Aktualität der Virensignaturen, Systemparameter etc.). Oft kann das für die
Firewall-Konfiguration verantwortliche Personal die Vertrauenswürdigkeit der internen Systeme zudem
nicht einschätzen, weil unterschiedliche Abteilungen für Firewall(s), Server und Desktops zuständig
sind.

Schliesslich bleibt angesichts der immer komplexer werdenden Netze mit Partneranbindungen,
Extranets und Kundenübergängen die Frage, wie genau denn nun das "interne" Netz von "externen"
Einheiten abgegrenzt werden kann.

Annahme 2

Es gibt eine klare Grenze zwischen innen und außen.

Diese Grenze wird, wie oben schon beschrieben, zunehmend durch Systeme aufgeweicht, deren
Betrieb nur temporär im internen Netz erfolgt.

Netzwerkumgebungen werden darüber hinaus in steigender Zahl logisch durch VPNs erweitert (mit
unkontrollierbaren Endpunkten, etwa in den kleinen privaten Netzen von VPN-Usern) oder physisch
mithilfe von Wireless-Technologien (WLANs, Bluetooth etc.) ausgedehnt. Immer mehr
Partneranbindungen oder Wartungszugänge (die zwar durchaus durch Firewalls "kontrollierbar" sind,
die entsprechenden Regelsätze aber meist unübersichtlicher und damit fehleranfälliger machen) tun
ihr Übriges, um dazu beizutragen, dass eine klare Grenze zwischen schützenswerten System und
potenziell bedrohlichen Systeme ständig verschwommener wird.

Annahme 3

Gefahren kommen in erster Linie von außen.

Eine der Hauptgefahrenquellen, nämlich die die Systeme bedienenden User, befindet sich innerhalb
von Netzen. Annahme 3 ist daher schlicht falsch. Bedenkt man weiterhin, wieviele Netze von Blaster
oder SQL-Slammer befallen waren (obwohl die jeweiligen Firewalls bestimmt die notwendigen Ports 135
oder 1434 nicht passieren ließen), zeigt sich, dass offensichtlich andere, "interne" Mechanismen
(meist VPN-Zugänge oder Laptops) für die Verbreitung verantwortlich waren.

Annahme 4

Die Firewall kann die Gefahren erkennen und abwehren.

Die Fähigkeiten der meisten Firewalls hinken der technischen Entwicklung von
Übertragungs-Mechanismen oder -Protokollen deutlich hinterher. Dies zeigt sich etwa an Technologien
wie Instant Messaging, Voice over IP oder SOAP, mit denen viele Firewalls nur rudimentär umgehen
können. Immer mehr (sicherheitsrelevanter) Verkehr wird zudem über HTTP abgewickelt (gegebenenfalls
sogar durch User darüber explizit getunnelt) oder wird Ende-zu-Ende verschlüsselt, was die
Möglichkeiten einer Firewall zur angemessenen Prüfung und Filterung beschränkt. Diese Probleme
werden mit IPv6 dank der nativen IPsec-Implementierungen und Mobile IP noch wachsen.

Eine solche Border Defense/Choke Point Firewall bildet außerdem oft einen Flaschenhals (was dazu
verlockt, sie zu umgehen) und erzeugt ein falsches Sicherheitsbewusstsein ("Wir haben ja eine
Firewall").

Segmentierung als Lösungsansatz

Viele dieser Probleme lassen sich durch eine geeignete Segmentierung des Netzes mit Regeln für
die Übergänge zwischen Teilbereichen und sinnvollen Maßnahmen innerhalb der Segmente lösen. Dies
soll nachfolgend am Beispiel einer deutschen Provider-Umgebung dargestellt werden.

Das Netzwerk wurde hier in Segmente ("Zonen") mit unterschiedlichen Sicherheitsanforderungen
unterteilt (Bild 1). Die Zonen sind physisch voneinander getrennt und können in sich nochmals (etwa
auf Basis von Anwendungen) unterteilt werden (zum Beispiel mit VLANs). Alle Netzwerkentitäten im
weiteren Sinn (Applikationen, Systeme, User) werden durch ihre jeweiligen Owner/Verantwortlichen je
einer Zone zugeordnet. Pro Zone gelten bestimmte Richtlinien zu Installation/Konfiguration/Betrieb
der Systeme (beispielsweise hinsichtlich Dokumentation, User-Verwaltung, Zugriffsregelung,
Systemhärtung, Logging, Business Continuity etc.). Die Kommunikationsbeziehungen zwischen den Zonen
sind genau geregelt; im Beispiel sind etwa nur Kommunikationsbeziehungen zwischen benachbarten
Zonen gestattet, und bestimmte Kommunikationsvorgänge müssen zwingend verschlüsselt werden (Bild
2).

Den Grundprinzipien einer solchen Segmentierung zu folgen, kann in vielen Unternehmensnetzen die
oben genannten Probleme lösen. Sicherheitsprobleme wie etwa Würmer werden bei geeigneter
Kommunikation auf einzelne Segmente beschränkt. Es gibt definierte Kommunikationsbeziehungen
innerhalb des Netzes, und verbindliche Richtlinien pro Zone gewährleisten (idealerweise) die
einheitliche Konfiguration von Systemen, wodurch zudem Kosteneinsparungen realisiert werden
können.

Es wird allerdings in solchen Konzepten oft ein organisatorischer Soll-Zustand (hinsichtlich der
Systemkonfiguration) beschrieben, der gegebenenfalls von einem technischen Ist-Zustand abweichen
kann. Eine vorgenommene Zonen-Einstufung bestimmt im Beispiel anschließend ein administratives
(menschliches) Handeln, das zu einer bestimmten Systemkonfiguration führen soll.

Zu fragen wäre, ob nicht vielleicht der umgekehrte Weg (konkrete Konfiguration eines Systems
führt ihrerseits zur Platzierung in einem bestimmten Segment) angesichts der Komplexität moderner
Netze und des schnellen Wandels der Technologien und damit verbundener Risiken vielversprechender
ist.

Der Quarantäneansatz

Solche Fragestellungen haben zu einem weiteren Designansatz geführt, in dem der Begriff
Quarantäne eine große Rolle spielt. Eine theoretische Erörterung dieses neuen Ansatzes findet sich
im (nicht mehr gültigen) IETF-Draft "Quarantine Model Overview for IPv6 Network Security"
(Quarantine Model Overview for IPv6 Network Security:
community.roxen.com/developers/idocs/drafts/draft-kondo-quarantine-overview-01.html).

Die praktische Umsetzung dieses Modells wird jedoch aktuell von vielen Herstellern
vorangetrieben, etwa bei Cisco im Rahmen der "Network Admission Control", bei Alcatel auf
Omni-Switches mit "Automated Quarantine Engine" und bei Check Point mit dem "Integrity"
-Produkt.

Die grundlegende Methodik sieht vor, dass für jeden Netzwerkteilnehmer ein Security Level
ermittelt wird, das gesamte Netz wiederum anhand der ermittelten Security Level segmentiert wird
und auf jedes Segment eine bestimmte Policy angewendet wird.

Zugrundeliegende Parameter für die Bestimmung des Security Levels können etwa Betriebssystem-
oder Softwareversionen, installierte Patches, vorhandene Security-Komponenten (Antivirussoftware,
lokale Firewalls) samt eventueller Signatur-Updates oder auch Konfigurationsparameter des Systems
sein. Die Segmentierung des Netzes wird dann durch Netzwerk-Devices mithilfe von Techniken wie
802.1x, VMPS, DHCP Option 82 und so weiter vorgenommen und in Form von unterschiedlichen
IP-Subnetzen, VLANs oder MPLS-Strukturen realisiert. Bestandteile einer dann pro Segment
anzuwendenden Policy können Authentifzierungserfordernisse (Teilnehmer eines vertrauenswürdigen
Segments müssen sich zum Beispiel per Zertifikat authentifizieren), Paketfilter (die den aus dem/in
das Segment fließenden Verkehr regeln), Routing-Pfade (Verkehr hoch vertrauenswürdiger Segmente
nimmt einen anderen Weg als Verkehr weniger vertrauenswürdiger Segmente) oder auch
Bandbreitenbegrenzungen (um etwa Wurm-Traffic zu begrenzen) sein. Im genannten IETF-Draft sind
verschiedene beteiligte Komponenten vorgesehen. Hier gibt es etwa einen "Prevention Information
Server" (der Informationen über Sicherheitslücken bereitstellt, kurz PS), einen "Quarantine
Inspection Agent" (der Informationen über einen Host liefert, QA), einen Quarantine-Server (der die
gelieferten Daten auf Basis von Informationen des PS bewertet, QS) und "Policy Enforcer" (also
Netzwerk-Devices, die die konkrete Policy jedes Segments dann realisieren).

Dieses Modell ist gegebenenfalls besser als statische, administrative Netzwerksegmentierung zur
Abwehr aktueller Bedrohungen geeignet. Damit aber ein solches Modell (herstellerübergreifend)
funktioniert, müssen folgende Mechanismen vorhanden sein:

Server, die Informationen über Sicherheitslücken oder Viren/Würmer
bereitstellen,

ein standardisiertes Format/Protokoll zur Übertragung solcher
Informationen,

ein standardisiertes Format/Protokoll zur Bestimmung des Security Levels
(zwischen QA und QS),

eine standardisierte "Security Policy Definition Language", OS-Support für den
QA, auch für mobile Endgeräte,

ein Kommunikationsmechanismus zwischen QS und PE.

All dies ist noch nicht in standardisierter Form vorhanden. Es existieren zur Zeit nur
herstellerproprietäre Implementierungen des Quarantänemodells mit den bekannten Folgen.

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

Default