![[Einwahl-Modems, WLANs, Wartungszugänge Home Offices und ins Intranet eingebundene Dienstleister sorgen leicht für unkontrollierte Einfallswege zum internen Netz]](54-1.jpg)
Viele Wege führen ins Internet – lange nicht alle über die Firewalls.
Sobald es um die Absicherung des Intranets gegen Angriffe von außen geht, scheint alles klar: Benötigt wird eine Firewall, ergänzt durch eine Demilitarized Zone (DMZ) für Web-Proxies und Mailserver. Ein Virenscanner für eingehende E-Mails und ein Network Intrusion Detection System (NIDS) runden das lehrbuchmäßige Design ab.
Diesem Vorgehen liegt ein Perimetermodell zugrunde: Innerhalb einer Sicherheitszone (Trust Domain) dürfen alle IP-Dienste uneingeschränkt genutzt werden. Auf der Firewall, die den zonenüberschreitenden Verkehr kontrolliert, lassen Security-Policies nur die Freischaltung von Diensten mit vertretbarem und bewusst akzeptiertem Restrisiko als Ausnahme einer Default-Deny-Policy zu. Klassische LAN-Protokolle mit fehlenden oder schwachen Sicherheitsmerkmalen wie tftp oder NetBIOS wird man üblicherweise nicht freischalten. Meist bildet das Intranet die einzige Sicherheitszone, die über eine Firewall mit dem Rest der Welt verbunden ist.
Die impliziten Annahmen beim Perimetermodell lauten:
Was auf den ersten Blick trivial erscheinen mag, erweist sich in modernen IT-Umgebungen als kaum meisterbare Herausforderung. Konflikte mit typischen betrieblichen Gegebenheiten führen zu einer trügerischen Sicherheit des Perimetermodells.
Viele Wege führen ins Internet – lange nicht alle
über die Firewalls.
Selbst einfachere Verträge mit externen Dienstleistern erfordern in der Regel Zugriff auf interne IT-Ressourcen. Manche Zugriffe können mit vertretbarem Restrisiko über die Firewall gefiltert werden, beispielsweise bei einfachen Datentransfers mittels ftp. Komplexe IT-Dienstleistungen basieren jedoch zunehmend auf Distributed-Computing-Konzepten, bei denen mehrere Systeme betriebssystemnah gekoppelt werden (System Cluster). Weit verbreitete Techniken hierzu sind etwa RPC, DCE oder Corba. Wegen der hohen Flexibilität und der einfachen Softwareentwicklung im Baukastensystem werden sie zunehmend auch als Schnittstelle zum Dienstleister verwendet. Auf der Firewall ist das an freigeschalteten Protokollen wie IIOP, portmap oder großen Bereichen für dynamisch vergebene Portnummern leicht zu erkennen.
Bei Distributed Computing über Firewallgrenzen hinweg entsteht ein unlösbarer Widerspruch: Firewalls sollen einerseits interne und externe Sicherheitszonen trennen, System Cluster versuchen andererseits jegliche Hürden zwischen Systemen zu beseitigen und implizieren aufgrund fehlender Sicherheitsmerkmale eine eigene (firewallübergreifende) Sicherheitszone. Denn Sicherheit gehörte bei diesen Protokollen nicht zu den Design-Kriterien – für den ursprünglich unterstellten Einsatz im eigenen, vertrauenswürdigen LAN erschien das überflüssig. Und wenn Sicherheitsmerkmale wie Authentifizierung und Verschlüsselung verfügbar sind, werden sie aus Performancegründen in der Regel nicht implementiert oder aktiviert.
Firewalls können den Inhalt von IIOP-Calls oder RPC leider nicht prüfen; dazu sind die Protokolle zu komplex und anwendungsabhängig. Auch die seit kurzem angebotenen Application Level Gateways für Corba haben ihre Tücken: Zu einer wirksamen Prüfung müssen sie tief in die Corba-Kommunikation hineinschauen. Dazu brauchen sie die Definition der Funktionsaufrufe aus dem Sourcecode der jeweiligen Anwendung – Corba-Firewalls sind also keine nachträglichen Add-ons. Solange die Hersteller von Corba-Anwendungen die Application Gateways nicht aktiv unterstützen und bei jedem Software-Upgrade anpassen, sind diese von geringem praktischen Nutzen.
Dienstleister spielen die Sicherheitsproblematik gerne herunter, wenn sie auf einen einzelnen TCP- oder UDP-Port verweisen, der auf der Firewall freizuschalten ist. Dahinter verbergen sich aber meist Tunnelprotokolle, die jede Firewallfunktion weitgehend aushebeln. Was im Firewall-Regelsatz mit einer einzigen Regel optisch harmlos aussieht, entspricht effektiv einer kompletten Netzöffnung zum Dienstleister.
Bedient der Dienstleister aus seinem Rechenzentrum noch andere Kunden, entsteht eine ungewollte Kette von Vertrauensbeziehungen. Bei branchenspezifischen Dienstleistern ist mit hoher Wahrscheinlichkeit sogar ein direkter Wettbewerber darunter. Nachdem der Kosten senkende Effekt beim Outsourcing genau in der weitgehenden gemeinsamen Nutzung teurer Ressourcen besteht, ist dieses Szenario eher die Regel als die Ausnahme.
Die wesentliche Funktion eines Firewallsystems liegt in der Zugangskontrolle auf der Transportschicht durch selektives Erlauben oder Sperren einzelner Quell- und Zieladressen sowie Dienste, verbunden mit einer Inhaltsüberprüfung auf korrekte Syntax durch Proxies und Prüfung auf bekannte schädliche Inhalte durch IDS und Virenscanner. Entwicklungen der letzten Jahre haben jedoch zu komplexen Kommunikationsprotokollen geführt, die durch diese Techniken nicht zu kontrollieren sind.
Mit Mobile Code wie Java, JavaScript oder ActiveX kann beim Surfen automatisch fremder und möglicherweise schädlicher Code von Webservern geladen und ausgeführt werden. Firewalls beschränken sich auf die Überprüfung der Syntax einiger einfacher Protokolle wie SMTP oder FTP; ausführbaren Code auf schädliche Aktionen zu prüfen übersteigt die Komplexität einer Syntaxprüfung bei weitem.
Zwar werden Content-Scanner als zentrale Filter für den Internetzugang angeboten, die vor schädlichen Java Applets schützen sollen. Sie prüfen aber meist nur auf bestimmte kritische Aktionen des Applets (z. B. Zugriff auf Festplatten oder Versand von IP-Paketen) und verfolgen damit eine bedenkliche Default-Allow-Policy: Alles, was sie nicht als schädlich erkennen, geht durch.
Gleiches gilt für Virenscanner: Ihre Funktion beruht überwiegend auf dem Vergleich mit einer Datenbank bekannter Virenfragmente. Gegen neue Viren ist bis zur nächsten Aktualisierung kein Schutz gegeben. Vom ersten (erkannten) Auftreten eines Virus bis zur Verfügbarkeit neuer Virus-Patterns können jedoch mehrere Stunden bis Tage ins Land gehen. Malware wie Melissa oder Code Red haben mit ihren aggressiven Verbreitungsstrategien gezeigt, wie kritisch dieses schutzlose Zeitfenster sein kann.
Weitere Sicherheitsprobleme entstehen durch Ende-zu-Ende-Verschlüsselung, etwa bei SSL-Verbindungen (HTTPS): Proxies und NIDS können dann die übertragenen Inhalte nicht mehr prüfen. Auch ein Virenscanner am zentralen Mail-Gateway wird durch verschlüsselte Attachments schachmatt gesetzt.
In der Praxis lässt sich leider kaum umsetzen, dass alle Netzverbindungen über die Grenzen einer Sicherheitszone über die Firewall laufen. Klassische Verstöße sind beispielsweise Modems oder ISDN-Karten an PCs im internen Netz. Ungleich höher als bei ausgehenden Wählverbindungen ist das Risiko ungesicherter Einwahl-Zugänge, wie sie üblicherweise zu Wartungszwecken eingerichtet werden (vgl. S. 6).
Bei der Angebotserstellung setzen viele Hersteller voraus, dass Fernwartung mittels direkter Einwahl auf ISDN-Karten ihrer Systeme im Kundennetz möglich ist – nach deren Sicherheitsvorgaben fragen Anbieter selten. Der vorsorgliche Hinweis darauf endet meist mit der lapidaren Antwort, dass ohne den vorgesehenen Wartungszugang leider der vereinbarte Support nicht geliefert werden könne.
Die Absicherung solcher Einwahlzugänge ist häufig katastrophal schlecht: Der Einfachheit halber verwenden viele Support-Anbieter für alle Kunden die gleichen (Trivial-)Passwörter, die zudem über Jahre und Generationen von ausgeschiedenen Support-Mitarbeitern hinweg nicht geändert werden. Durch hartnäckiges Nachfragen bei einem Netzausrüster war beispielsweise zu erfahren, dass die Einwahl auf dessen Seite nicht etwa aus einem isolierten Supportnetz heraus geschieht, sondern vielmehr zu einer Kopplung mit seinem weltweitem Office-Netz und anderen Kundennetzen führt. Leider lassen sich viele Hersteller nur sehr mühsam von derlei Gepflogenheiten abbringen – aber letztlich sollte der Kunde die Spielregeln bestimmen.
Wireless LANs bilden eine neue Quelle von Firewall-Umgehungen. Sie werden meist aus rein praktischen Erwägungen beispielsweise in Besprechungs- oder Schulungsräumen installiert – in der Regel ohne Aktivierung der Sicherheitsmerkmale. Das Einklinken von draußen ins interne Firmennetz ist dann trivial (War Driving). Aus Sicherheitssicht entspricht das der Installation von LAN-Dosen auf dem Gehsteig.
In aller Regel untersagen Security-Policies die angeführten Praktiken. Sich darauf zu verlassen, dass der anvisierte Idealzustand ohne weiteres erreicht wird, wäre jedoch naiv. Auch mit regelmäßigen IT-Audits lässt sich das Problem nicht grundlegend beheben: Mitarbeiter, die in ihren Projekten unter Termindruck stehen, werden Sicherheitsbelange – so sie diese überhaupt als sinnvoll erachten – den eigenen Projektprioritäten unterordnen. Eine realitätsnahe Sicherheitsstrategie muss daher den Faktor Mensch einbeziehen und gegenüber denjenigen Sicherheitsanforderungen fehlertolerant ausgelegt werden, die vom einzelnen Anwender eigenverantwortlich umzusetzen sind.
Wenn also eine Firewall nicht gegen alle Bedrohungen schützen kann, so lautet die naheliegende Strategie, im internen Netz gegen bekannte Angriffe nicht verwundbar zu sein. Berücksichtigt man dies von der Planungsphase an, so lässt sich die Verwundbarkeit mit geringem Aufwand erheblich reduzieren.
Vireninfektionen werden vielerorts als unabwendbare Ereignisse hingenommen. Dabei waren bei den großen Virenvorfällen der letzten Jahre Implementierungsfehler und Designschwächen in wenigen Produkten verantwortlich – prominente Vertreter sind Microsofts Outlook und Internet Information Server (IIS). Wer den Einsatz dieser Produkte wegen Sicherheitsbedenken von vornherein abgelehnt hat, blieb von Melissa, Code Red & Co weitgehend verschont. Die Häufigkeit von Sicherheitsbugs als Maß für künftig zu erwartende Verwundbarkeiten sollte daher ein wichtiges Kriterium für jede Produktauswahl sein.
Die Schwelle zur unautorisierten Nutzung von Modems und ISDN-Adaptern lässt sich deutlich erhöhen, wenn kein nutzbarer Telefonanschluss in greifbarer Nähe ist. Nachdem Nebenstellenanlagen meist Systemtelefone mit proprietären Protokollen einsetzen, wird es außer bei Fax-Geräten wenig Bedarf für analoge und ISDN-Nebenstellen geben. Entsprechend sollte auch die Nutzung direkter Amtsleitungen auf ihre Verwendung hin geprüft werden – hier verbergen sich oft Supportzugänge.
Die allgemeinen Empfehlungen zur Hostsicherheit, wie die Verwendung starker Passworte oder das Abschalten nicht benötigter Dienste, müssen auch innerhalb einer Sicherheitszone gelten – nicht nur wegen des begrenzten Schutzes der Firewall, sondern auch aufgrund der Bedrohung durch Innentäter. In der Praxis scheitert die Umsetzung der hehren Ziele nicht selten am Fehlen einer aktuellen Bestandsliste der am Netz angeschlossenen Systeme: Allzu oft verwandeln sich "schnell mal" installierte Testsysteme schleichend in Produktivsysteme. Die unkontrollierte Anschaltung neuer Systeme kann durch die Aktivierung von Port-Security (Bindung einer Ethernet-Adresse an einen Switch-Port) oder die Nutzung dynamischer IP-Adressen, die der DHCP-Server nur für bekannte Hosts vergibt, weitgehend unterbunden werden.
Bei jeder Outsourcing-Entscheidung stellt sich die Frage, inwieweit eigene Sicherheitsinteressen in Gefahr geraten (vgl. KES 2001/1, S. 91 und KES 2002/2, S. 50 und 52). Ist die Entscheidung zum Outsourcing von IT-Dienstleistungen und damit zur Einrichtung einer Netzschnittstelle zum Dienstleister gefallen, steht eine Entscheidung zur Umsetzung der Netzkopplung an: Wird das im Kundenauftrag betriebene (Teil-)Netz des Dienstleisters als intern im Sinne des Perimetermodells betrachtet, so kann die Netzkopplung im Prinzip direkt (ohne Firewall) erfolgen. In diesem Fall muss sich der Dienstleister aber auch an die Sicherheitsstandards des Kunden halten – vor allem muss dieser eine dedizierte IT-Infrastruktur ohne Kopplung zu weiteren Kundennetzen aufbauen. Diese Variante ist am einfachsten zu implementieren, räumt dem Dienstleister aber automatisch uneingeschränktes Vertrauen ein. Als Kunde sollte man sich ein umfangreiches Auditrecht vertraglich sichern.
Die Platzierung des Dienstleisters außerhalb des Perimeters bedingt eine Filterung des Verkehrs über eine Firewall, wobei auf firewallfähige, das heißt entsprechend kontrollierbare, Anwendungen zu achten ist. RPC, DCE und Corba kommen hier kaum in Frage, was zu harten Einschränkungen führt. Jeder Versuch, einem IT-Dienstleister mittels "gefährlicher" Protokolle umfangreiche Rechte zu gewähren und gleichzeitig eine Trennung durch Firewalls anzustreben, gliche der versuchten Quadratur des Kreises.
Eine der größten sicherheitstechnischen Herausforderungen liegt in der Größe und Komplexität vieler firmeninterner Netze: Oft entstand aus einem Rechenzentrumsnetz mit dem Client/Server-Boom der 90er-Jahre eine komplexe Intranet-Architektur mit Verbindung zum Internet. Kommt dann noch eine Unternehmensfusion dazu, werden die Intranets einfach gekoppelt – schließlich vertraut man sich ja. Das ursprünglich geschlossene und als sicher eingestufte RZ-Netz hat sich zu einem allgemein verfügbaren internen Transportnetz gewandelt, an dem jedes IP-fähige Gerät einfach angeschlossen wird. Leicht vergisst man dabei, dass die Systeme und Anwendungen höchst unterschiedliche Schutzanforderungen besitzen. Während etwa Vertriebsmitarbeiter darauf angewiesen sind, sich von unterwegs ins Firmennetz anmelden zu können, ist es bedenklich, wenn damit prinzipiell auch von überall her IP-Zugang auf kritische Systeme wie die Lohnbuchhaltung möglich wird.
Der Vergleich mit der Gebäudeabsicherung verdeutlicht diese Inkonsistenz: Während Rechenzentren wegen der hohen Schutzanforderungen mittels separater Zutrittskontrolle, Einbruchmeldern etc. besonders gesichert sind, erstreckt sich die logische Sicherheitszone nicht nur über das RZ hinaus auf den gesamten Firmenstandort, sondern bis ins Home Office, auf Flughäfen, Kundenlokationen oder wo sich angebundene Mitarbeiter auf Reisen sonst noch aufhalten mögen.
Einen erheblichen Sicherheitsgewinn kann man durch Schaffung interner Sicherheitszonen erreichen. Die Trennung verfolgt im Wesentlichen drei Ziele:
Eine Sicherheitszone könnte zum Beispiel kritische Anwendungen wie die Buchhaltung oder das Abrechnungssystem beherbergen, eine separate Zone die normale Office-Umgebung mit den Desktop-PCs. Die Grenzen interner Sicherheitszonen müssen sich am Schutzbedarf der Ressourcen sowie sekundär an den Verkehrsströmen orientieren. Die Trennung nach Unternehmensstandorten oder historisch gewachsenen Netzgrenzen ist dagegen nicht zielführend. Standortübergreifende Zonen lassen sich kostengünstig mit Virtual Private Networks (VPNs) realisieren.
Auch dem Wunsch nach Wireless LANs in (halb-)öffentlichen Bereichen wie Schulungsräumen oder der Cafeteria muss nicht kategorisch abgelehnt werden: In einer eigenen Sicherheitszone darf man ein WLAN sogar für externe Gäste öffnen, wenn gleichzeitig der Zugang zum Intranet auf Dienste wie E-Mail und unkritische Teile des internen Webauftritts beschränkt wird. Auf die minimalen Sicherheitsmerkmale des WLAN-Standards sollte man dennoch nicht verzichten.
Mögliche Grundsätze für eine Policy zur Absicherung von Zonen mit hohen Sicherheitsanforderungen (z. B. einer Produktions-Domain mit Billing-System oder Kundendatenbanken) sind:
Die zunehmende Komplexität der IT-Infrastruktur und ihre Vernetzung mit externen Dienstleistern lässt die ursprünglich praktizierte Schwarz-Weiß-Malerei "innen ist sicher – außen ist unsicher" fragwürdig erscheinen – und damit auch das Perimetermodell als einzigen Schutzwall. Ein erweitertes Sicherheitsmodell muss den unterschiedlichen Sicherheitsanforderungen mit einem differenzierten Zonenmodell Rechnung tragen. Wichtig ist die Kommunikation, dass eine Firewall keinen hundertprozentigen Schutz bieten kann, getreu dem Motto "unser Netz ist sicher, wir haben eine Firewall". Sicherheit ist und bleibt eine Herausforderung von Design bis Betrieb eines jeden Systems.
Wolfgang Bäuml arbeitet als Senior Network
Security Specialist in der Abteilung Unternehmenssicherheit bei
British Telecom (![[externer Link]](../../../../images/link.gif)
www.btignite.de.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 2002/6, Seite 54
