SAFE: Ein Sicherheitsframework für Unternehmensnetzwerke

Transkript

1 SAFE: Ein Sicherheitsframework für Unternehmensnetzwerke Seite 1

2 Inhaltsverzeichnis GRUNDSÄTZLICHES... 3 NUTZER... 3 VORAUSSETZUNGEN... 4 ÜBERSICHT ÜBER DIE ARCHITEKTUR... 5 DIE GRUNDSÄTZE VON SAFE... 7 UNTERNEHMENSMODUL UNTERNEHMENSCAMPUS MANAGEMENTMODUL KERNMODUL GEBÄUDEVERTEILUNGSMODUL GEBÄUDEMODUL SERVERMODUL EDGEVERTEILUNGSMODUL UNTERNEHMENSEDGE UNTERNEHMENSINTERNETMODUL VPN UND REMOTE ACCESS MODUL WAN-MODUL E-COMMERCE-MODUL UNTERNEHMENSOPTIONEN ANHANG A: PRÜFLABOR ANHANG B: FIBEL ZUR NETZWERKSICHERHEIT ANHANG C: ARCHITEKTURELEMENTE Seite 2

3 Grundsätzliches Mit dem Sicherheitsframework für Unternehmensnetzwerke (SAFE) verfolgt Cisco in erster Linie das Ziel, Interessenten mit Informationen zur optimalen Vorgehensweise bei der Konzeption und Implementierung sicherer Netzwerke zu versorgen. SAFE stellt ein Handbuch für Netzwerkdesigner dar, in dem die Sicherheitsanforderungen eines Cisco-Netzwerks berücksichtigt werden. Der hierbei zur Gewährleistung der Netzwerksicherheit gewählte Ansatz zeichnet sich durch sehr tief greifende Abwehrmechanismen aus. Bei dieser Art der Konzeption richtet sich das Augenmerk primär auf die erwarteten Bedrohungen und Methoden zu deren Abwendung. Es ist nicht damit getan, einfach hier eine Firewall und dort ein Intrusion Detection System (IDS) einzusetzen. Daraus ergibt sich ein mehrschichtiger Sicherheitsansatz, bei dem auch der Ausfall eines Sicherheitssystems aller Wahrscheinlichkeit nach keine Sicherheitsverletzungen an Netzwerkressourcen nach sich zieht. SAFE basiert auf den Produkten von Cisco und dessen Partnern. Am Anfang dieses Dokuments steht eine Übersicht über die Architektur gefolgt von detaillierten Beschreibungen der einzelnen Module, aus denen sich das Netzwerkdesign zusammensetzt. In den ersten drei Abschnitten zu den verschiedenen Modulen werden anhand einfacher Abbildungen jeweils der Datenverkehrsfluss, die Hauptgeräte und erwartete Bedrohungen beschrieben. Es folgt eine detaillierte technische Analyse des Designs einschließlich ausführlicher Beschreibungen weiterer Methoden zur Abwehr von Bedrohungen und Migrationsstrategien. Anhang A enthält detaillierte Angaben zum Prüflabor für SAFE, darunter auch Konfigurationssnapshots. Anhang B enthält eine Fibel zur Netzwerksicherheit. Falls Sie mit den grundlegenden Begriffen der Netzwerksicherheit nicht vertraut sind, empfiehlt es sich, diesen Anhang vor dem Rest des Dokuments zu lesen. In Anhang C finden Sie eine systematische Auflistung der in diesem Dokument verwendeten Begriffe. Zentraler Betrachtungspunkt im Rahmen dieses Dokuments sind die Bedrohungen, denen Enterprise-Umgebungen ausgesetzt sind. Netzwerkdesigner, für die diese Bedrohungen keine unbekannte Größe sind, können gezielt entscheiden, wo und auf welche Weise Abwehrmechanismen zum Einsatz kommen. Fehlt hingegen das umfassende Wissen über die Bedrohungen, die in Bezug auf die Netzwerksicherheit zu berücksichtigen sind, besteht die Gefahr, dass die eingesetzten Abwehrmechanismen falsch konfiguriert oder zu stark auf die Sicherheitsgeräte konzentriert sind oder dass sie nicht flexibel genug auf Bedrohungen reagieren können. Mit diesem Dokument möchten wir also unter Beachtung des Ansatzes der Verhinderung von Bedrohungen Netzwerkdesignern alle Informationen an die Hand geben, die erforderlich sind, um fundierte Entscheidungen bezüglich der Netzwerksicherheit zu treffen. Nutzer Dieses Dokument ist zwar technischer Natur, dennoch werden dem Leser neue Begriffe bei ihrem ersten Auftreten nach Möglichkeit erläutert. Lesen Sie dieses Dokument als Netzwerkmanager, können Sie sich beispielsweise auf die einführenden Abschnitte zu den einzelnen Bereichen beschränken, um sich einen umfassenden Überblick über die Möglichkeiten eines sicheren Netzwerks und die diesbezüglich anzustellenden Überlegungen zu verschaffen. Als Netzwerkingenieur oder -designer hingegen können Sie das gesamte Dokument lesen und sich auf diese Weise über Designmöglichkeiten und Gefahrenanalyse informieren. Illustriert werden diese Informationen durch Snapshots einer tatsächlichen Konfiguration der betreffenden Geräte. Seite 3

4 Voraussetzungen Diesem Dokument muss immer eine bestehende Sicherheitspolicy zugrunde gelegt werden. Von dem Einsatz von Sicherheitstechnologien ohne entsprechende Policy wird dringend abgeraten. Dieses Dokument ist unmittelbar auf die Anforderungen von Großunternehmen abgestimmt. Dennoch treffen die meisten der hier angesprochenen Prinzipien auch direkt auf kleine und mittlere Unternehmen, ja sogar auf Heimbüros zu, wenn auch in anderem Umfang. Eine detaillierte Analyse der unterschiedlichen Arten von Unternehmen würde den Rahmen dieses Dokuments sprengen. Trotzdem soll dieser Punkt in begrenztem Umfang angesprochen werden. So enthalten die Abschnitte zu Alternativen und Optionen Angaben über Geräte, die nicht unbedingt eingesetzt werden müssen, so dass hier eine Kostenersparnis im Rahmen der Architektur möglich ist. Allerdings kann auch bei Einhaltung der in diesem Dokument dargelegten Richtlinien eine sichere Umgebung nicht garantiert werden, und so sind erfolgreiche Angriffe nicht auszuschließen. Eine wirkliche, absolute Sicherheit ließe sich nur erzielen, wenn man das betreffende System vom Netzwerk trennen, es in Beton gießen und im Keller von Fort Knox einlagern würde. Dann wären die Daten absolut sicher, aber eben nicht mehr erreichbar. Man kann jedoch auch in vertretbaren Maßen für Sicherheit sorgen. Dazu ist eine gute Sicherheitspolicy erforderlich, die in diesem Dokument dargelegten Richtlinien müssen eingehalten und die neuesten Entwicklungen im Kampf zwischen Hackern und Sicherheitstechnologie mitverfolgt werden. Und nicht zuletzt müssen alle Systeme unter Anwendung solider Methoden der Systemadministration gewartet und überprüft werden. Dazu zählen auch Kenntnisse in Bezug auf Probleme der Applikationssicherheit, die jedoch in diesem Dokument nicht umfassend besprochen werden. Virtuelle private Netzwerke (VPNs) sind in dieser Architektur zwar berücksichtigt, werden jedoch nicht ausführlich besprochen. So finden bestimmte Themen in Bezug auf VPNs, beispielsweise die Problematik der Skalierbarkeit oder Redundanzkonzepte, keine Berück-sichtigung. Ebenso wie VPNs werden auch Identifizierungsstrategien (u. a. Zertifizierungs-stellen (CAs)) in diesem White Paper nicht annähernd erschöpfend besprochen. Für eine umfassende Abhandlung über CAs müssten wir dermaßen in die Tiefe gehen, dass dies ebenfalls den Rahmen dieses Dokuments sprengen würde und eine eingehende Besprechung aller anderen relevanten Aspekte der Netzwerksicherheit nicht mehr möglich wäre. Außerdem ist hierbei zu beachten, dass die meisten Unternehmensnetzwerke noch nicht mit voll funktionsfähigen CA-Umgebungen arbeiten und daher den Erläuterungen zur Sicherung von Netzwerken ohne diese CA- Umgebungen eine umso höhere Bedeutung zukommt. Schließlich wurden auch bestimmte hoch entwickelte Netzwerkapplikationen und -technologien (wie beispielsweise Contentnetzwerke, Caching und Serverlastverteilung) in diesem Dokument nicht berücksichtigt. Es ist zwar zu erwarten, dass auch diese in SAFE integriert werden, in dieser ersten Ausgabe jedoch werden die besonderen Sicherheits-anforderungen dieser Applikationen nicht behandelt. Obwohl SAFE unter Verwendung von Produkten von Cisco und dessen Partnern konzipiert wurde, werden die betreffenden Produkte in diesem Dokument nicht explizit genannt. Das heißt, die einzelnen Komponenten werden nicht anhand ihrer Modellnummer, sondern anhand ihrer Funktion identifiziert. Während der Validierungsphase von SAFE wurden in exakt der in diesem Dokument beschriebenen Netzwerkimplementierung echte Produkte konfiguriert. Informationen zum Prüflabor und den Ergebnissen mitsamt spezifischer Konfigurationssnapshots aus dem Labor finden Sie im Abschnitt zur Validierung gegen Ende des Dokuments. Im gesamten Dokument wird der Begriff Hacker für Personen verwendet, die böswillig versuchen, sich unberechtigten Zugriff auf Netzwerkressourcen zu verschaffen. Dieser Begriff wurde zwecks besserer Lesbarkeit gewählt, obwohl grundsätzlich Cracker eine treffendere Bezeichnung für solche Personen ist. Seite 4

5 Übersicht über die Architektur Designgrundlagen SAFE wurde während der Entwicklungsphase so weit wie möglich auf die funktionellen Anforderungen heutiger Unternehmensnetzwerke abgestimmt. Natürlich variierten die einzelnen Entscheidungen bezüglich der Implementierung je nach angestrebter Netzwerk-funktionalität, aber jeder Entscheidungsfindung lag eine Reihe gemeinsamer Designziele zugrunde. Diese werden nachfolgend nach Priorität geordnet aufgelistet: Policybasierte Sicherheit und Angriffsabwehr Sicherheitsimplementierung unter Verwendung der Infrastruktur (nicht mit speziellen Sicherheitsgeräten) Sicheres Management und Reporting Authentifizierung und Autorisierung von Benutzern und Administratoren für kritische Netzwerkressourcen Angriffserkennung für kritische Ressourcen und Subnetze Unterstützung für neue Netzwerkapplikationen In allererster Linie handelt es sich bei SAFE um eine Sicherheitsarchitektur. Als solche muss SAFE so weit als möglich verhindern, dass Angriffe auf wertvolle Netzwerkressourcen Erfolg haben. Neben der erforderlichen Sicherheit muss das Netzwerk aber auch weiterhin die wichtigen Dienste bieten, die die Benutzer erwarten. Und eine solide Netzwerksicherheit in Kombination mit guter Netzwerkfunktionalität ist möglich. Diese Architektur eröffnet keine revolutionären neuen Wege im Netzwerkdesign, sondern zeigt lediglich auf, wie Netzwerke gesichert werden können. Alle Angriffe, die die erste Verteidigungslinie überwinden (oder sogar aus dem Innern des Netzwerks kommen), müssen zuverlässig erkannt und rasch unter Kontrolle gebracht werden, um die negativen Auswirkungen auf das übrige Netzwerk so gering wie möglich zu halten. Zudem ist SAFE vom Ansatz her zuverlässig und skalierbar. Netzwerkzuverlässigkeit wird durch physische Redundanz gewährleistet, die Schutz bei einem Geräteausfall bietet, und zwar unabhängig davon, ob dieser nun durch Konfigurations-fehler, eine Störung oder einen Angriff auf das Netzwerk ausgelöst wurde. Es sind zwar einfachere Designs möglich, besonders, wenn keine hohen Leistungs-anforderungen an das Netzwerk gestellt werden, hier wurde jedoch ein komplexes Design gewählt, da in komplexen Umgebungen die Entwicklung eines Sicherheitskonzepts komplizierter ist als in einfacheren Umgebungen. Innerhalb des Dokuments werden aber immer wieder Vorschläge gemacht, anhand derer sich das Design vereinfachen lässt. Im Netzwerkdesign stellt sich immer wieder die Frage, ob besser integrierte Funktionalität in einem Netzwerkgerät oder ein Dienstgerät mit einer speziellen Funktion eingesetzt werden soll. In vielen Fällen scheint die integrierte Funktionalität sicherlich die bessere Wahl zu sein, da sie in vorhandenen Geräten implementiert werden kann oder die Funktionen mit dem Gerät im Übrigen interagieren können, wodurch dann eine Lösung mit besserer Funktionalität erzielt werden kann. Spezielle Dienstgeräte hingegen werden häufig verwendet, wenn sehr weit reichende Funktionen erforderlich sind und/oder aufgrund der Leistungsanforderungen der Einsatz spezieller Hardware unumgänglich ist. So muss von Fall zu Fall unter Berücksichtigung der Kapazität und Funktionalität des Dienstgeräts gegenüber dem Integrationsvorteil des Netzwerkgeräts eine Entscheidung getroffen werden. So kann beispielsweise in bestimmten Seite 5

6 Fällen anstelle eines kleineren IOS-Routers mit separater Firewall ein integrierter IOS-Router mit höherer Kapazität und IOS-Firewallsoftware gewählt werden. Innerhalb dieser Architektur kommen beide Arten von Systemen zum Einsatz. Die meisten kritischen Sicherheitsfunktionen wurden aufgrund der Leistungsanforderungen in großen Unternehmensnetzwerken auf dedizierte Dienstgeräte verlagert. Modulares Konzept Obwohl die meisten Unternehmensnetzwerke im Zuge der steigenden IT-Anforderungen der Unternehmen einfach nur weiterentwickelt werden, wurde für die SAFE-Architektur ein von Grund auf neuer modularer Aufbau gewählt. Dieser bietet zwei wichtige Vorteile: Zum einen kann im Rahmen der Architektur auf diese Weise die sicherheitstechnische Beziehung zwischen den einzelnen Funktionsblöcken des Netzwerks berücksichtigt werden, und zum anderen bietet dieser Aufbau Designern die Möglichkeit, Sicherheitsmechanismen Modul für Modul zu bewerten und zu implementieren, ohne die gesamte Architektur in nur einem Schritt bewältigen zu müssen. Die nachfolgende Abbildung zeigt die erste Modulschicht in SAFE. Hierbei stellt jeder Block einen Funktionsbereich dar. Das ISP-Modul wird nicht durch das Unternehmen selbst implementiert, wird aber dennoch berücksichtigt, da bestimmte Sicherheitsfunktionen von jedem ISP gefordert werden müssen, um bestimmte Angriffe abzuwehren. Abbildung 1: Unternehmensmodell Die in Abbildung 2 dargestellte zweite Modulschicht entspricht einer Unterteilung der Module innerhalb der einzelnen Funktionsbereiche. Diese Module erfüllen innerhalb des Netzwerks jeweils eine bestimmte Aufgabe, und es gelten jeweils spezielle Sicherheitsanforderungen. Die Größe, in der die einzelnen Module dargestellt sind, ist jedoch nicht als Hinweis auf den tatsächlichen Anteil dieser Module am eigentlichen Netzwerk zu werten. So kann beispielsweise das Gebäudemodul, in dem die Endbenutzergeräte zusammengefasst sind, 80 % der Netzwerkgeräte umfassen. Das sicherheitstechnische Design der einzelnen Module wird in einem separaten Abschnitt beschrieben, es wird jedoch als Bestandteil des gesamten Unternehmensdesigns validiert. Seite 6

7 Abbildung 2: SAFE-Blockdiagramm für Unternehmen Es ist zwar in dem meisten Fällen nicht problemlos möglich, bestehende Unternehmensnetzwerke in klar definierte Module zu unterteilen, aber trotzdem stellt dieser Ansatz eine Orientierungshilfe bei der Implementierung verschiedener Sicherheitsfunktionen innerhalb des Netzwerks dar. Die Verfasser gehen nicht davon aus, dass jeder Netzwerkingenieur das von ihm betreute Netzwerk exakt nach den Vorgaben der SAFE-Implementierung konzipiert. Vielmehr wird in der Praxis eine Kombination der hier beschriebenen Module in bestehende Netzwerke integriert werden. Der restliche Teil dieses Dokuments enthält detaillierte Beschreibungen zum Unternehmensmodul und den zugehörigen Modulen. Die Grundsätze von SAFE Router sind Angriffsziele Router steuern den Zugriff von einem Netzwerk auf ein anderes. Sie werben für Netzwerke und filtern zulässige Benutzer und sind bei Hackern besonders beliebt. Daher stellen sie ein kritisches Element in jeder Sicherungsstrategie dar. Router haben grundsätzlich die Aufgabe, Zugriffe zu ermöglichen, und eben deshalb müssen sie gegen direkte Kompromittierung gesichert werden. Zu diesem Aspekt der Sicherheit wurden bereits diverse Dokumente verfasst, die streng befolgt werden sollten, da sie nähere Erläuterungen zu den folgenden Themen enthalten: Sperren oder Einschrämken des Telnet-Zugriffs auf einen Router Sperren oder Einschrämken des SNMP-Zugriffs auf einen Router Steuern des Zugriffs auf einen Router unter Verwendung von TACACS+ Deaktivieren nicht benötigter Dienste Protokollieren auf entsprechenden Ebenen Authentifizierung von Routing-Updates Eine detaillierte Behandlung dieses Themas finden Sie unter Seite 7

8 Switches sind Angriffsziele Ebenso wie Router sind auch Switches (sowohl L2 als auch L3) besonderen Sicherheits-risiken ausgesetzt. In diesem Fall sind jedoch weniger Informationen zu Sicherheitsrisiken und möglichen Abwehrmaßnahmen öffentlich zugänglich als bei Routern. Die meisten im vorangegangenen Abschnitt über Router genannten Sicherheitstechniken sind auch auf Switches anwendbar. Zusätzlich sind auch die folgenden Maßnahmen zu empfehlen: Für Ports, für die keine Trunk-Funktionalität erforderlich ist, sollten alle Trunk-Einstellungen deaktiviert werden (also nicht auf Auto gesetzt sein). Auf diese Weise lässt sich verhindern, dass ein Host zu einem Trunk-Port wird und allen Datenverkehr empfängt, der normalerweise zu einem Trunk-Port gelangt. Trunk-Ports sollte eine innerhalb des Switches eindeutige VLAN-Nummer zugewiesen werden. Auf diese Weise lässt sich vermeiden, dass Pakete, die mit demselben VLAN markiert sind wie der Trunk-Port, ein anderes VLAN erreichen, ohne ein L3-Gerät passieren zu müssen. Weitere Informationen hierzu finden Sie unter Alle ungenutzten Port eines Switches sollen auf ein VLAN ohne L3-Konnektivität eingestellt werden. Noch besser ist es, jeden nicht verwendeten bzw. benötigten Port zu deaktivieren. Auf diese Weise kann vermieden werden, dass ein Hacker eine Verbindung zu einem ungenutzten Port herstellen und so mit dem Rest des Netzwerks kommunizieren kann. Es ist allerdings nicht zu empfehlen, sich zur Sicherung des Zugriffs zwischen zwei Subnetzen allein auf VLANs zu verlassen. Angesichts der Tatsache, dass hier ein großes Fehlerpotenzial im Hinblick auf menschliches Versagen besteht und außerdem bei der Konzeption von VLANs und VLAN-Taggingprotokollen Sicherheitsfragen nicht in Betracht gezogen wurden, ist die Verwendung von VLANs in sensiblen Umgebungen nicht zu empfehlen. Ist allerdings der Einsatz von VLANs in Sicherheitsstrategien nicht zu umgehen, sollten Sie die weiter oben angeführten Konfigurationshinweise und Richtlinien auf das Strengste befolgen. Innerhalb eines bestehenden VLANs bieten private VLANs in bestimmten Maße zusätzliche Sicherheit für bestimmte Netzwerkapplikationen. Ihre Funktionsweise besteht darin, dass sie nur eine Kommunikation zwischen bestimmten Ports innerhalb eines VLANs und anderen Ports innerhalb desselben VLANs zulassen. Isolierte Ports innerhalb eines VLANs können nur mit Ports im Promiscuous-Mode kommunizieren. Community-Ports können nur mit anderen Mitgliedern derselben Community sowie mit Ports im Promiscuous-Mode kommunizieren. Ports im Promiscuous-Mode können mit jedem beliebigen Port kommunizieren. Auf diese Weise kann ein einzelner kompromittierter Host keinen zu großen Schaden anrichten. Stellen Sie sich ein durchschnittliches Segment für öffentliche Services mit einem Webserver, einem FTP-Server und einem DNS-Server vor. Ist nun die Sicherheit des DNS-Servers nicht mehr gewährleistet, kann ein Hacker die beiden anderen Hosts angreifen, ohne die Firewall erneut passieren zu müssen. Bei Verwendung privater VLANs könnte ein kompromittiertes System nicht mehr mit den anderen Systemen kommunizieren. In diesem Fall könnte der Hacker nur die Hosts auf der anderen Seite der Firewall angreifen. Seite 8

9 Hosts sind Angriffsziele Hosts stellen das beliebteste Angriffsziel dar und sind gleichzeitig am schwierigsten zu schützen. Es gibt zahlreiche Hardwareplattformen, Betriebssysteme und Applikationen, für die jeweils zu unterschiedlichen Zeiten Updates, Patches und Fehlerkorrekturen erhältlich sind. Da Hosts anderen Hosts die von diesen angeforderten Applikationsdienste zur Verfügung stellen, sind sie innerhalb des Netzwerks sehr exponiert. So wurden zum Beispiel unter der Adresse (dies ist ein Host) zahlreiche Besucher verzeichnet, wohingegen nur wenige versucht haben, auf s2-0.whitehouse.bbnplanet.net (einen Router) zuzugreifen. Aufgrund eben dieser Sichtbarkeit werden Hosts bei unbefugten Zugriffsversuchen weitaus häufiger angegriffen als andere Netzwerkgeräte. Und außerdem verlaufen Angriffe hier am häufigsten erfolgreich, was sicherlich teilweise auf die erwähnten Schwierigkeiten in Bezug auf die Gewährleistung der Sicherheit zurückzuführen ist. So kann es zum Beispiel vorkommen, dass auf einem bestimmten Webserver im Internet eine Hardwareplattform eines Herstellers, eine Netzwerkkarte eines anderen Herstellers, ein Betriebssystem wieder eines anderen Herstellers und eine Webserversoftware, die entweder ein Open Source-Produkt oder das Produkt wieder eines anderen Herstellers ist, verwendet wird. Und damit noch nicht genug. Nun könnten auf demselben Webserver auch noch Applikationen ausgeführt werden, die frei über das Internet verteilt werden, und der Webserver könnte zusätzlich mit einem Datenbankserver kommunizieren, der aus nicht weniger unterschiedlichen Komponenten zusammengesetzt ist. Damit soll keineswegs behauptet werden, dass die Schwachpunkte in Fragen der Sicherheit besonders von der Verwendung von Produkten unterschiedlichster Hersteller herrühren. Es ist jedoch nicht von der Hand zu weisen, dass mit zunehmender Komplexität eines Systems auch die Wahrscheinlichkeit eines Ausfalls oder Fehlers zunimmt. Zur Sicherung von Hosts müssen alle einzelnen Komponenten der Systeme mit besonderer Sorgfalt ausgewählt werden. Für all die oben genannten Systeme müssen stets die neuesten Patches, Fehlerkorrekturen usw. installiert werden. Dabei darf aber auch die spezielle Wirkung dieser Patches auf die Funktion der anderen Komponenten im System nicht außer Acht gelassen werden. Aus diesem Grund empfiehlt es sich, alle Updates vor der Implementierung in einer Produktionsumgebung auf Testsystemen zu prüfen und auszuwerten. Wird diese Prüfung nicht durchgeführt, kann der Patch selbst einen Denial-of-Service verursachen. Netzwerke sind Angriffsziele Die schlimmsten Angriffe sind die, die unaufhaltsam ihren Lauf nehmen. Und genau solch ein Angriff ist ein geplant ausgeführter DDoS (Distributed Denial of Service). Wie in der Fibel nachzulesen, werden durch einen DDoS Dutzende oder gar Hunderte von Computern veranlasst, gleichzeitig falsche Daten an eine IP-Adresse zu senden. In der Regel zielen die Urheber eines solchen Angriffs nicht darauf ab, einen bestimmten Host zum Absturz zu bringen, sondern das gesamte Netzwerk lahm zu legen. Stellen Sie sich zum Beispiel ein Unternehmen vor, das über eine DS3-Verbindung (45 MBit/s) zum Internet verfügt und Benutzern auf seiner Webseite E-Commerce-Dienste anbietet. Eine solche Site ist sehr sicherheitsbewusst angelegt und mit Angriffserkennung, Firewalls, Protokollierfunktion und aktivem Monitoring ausgestattet. Nur leider nutzen diese ganzen Sicherheitsvorkehrungen bei einem erfolgreichen DDoS-Angriff rein gar nichts. Stellen Sie sich nun 100 Geräte in aller Welt mit einer DS1-Verbindung (1,5 MBit/s) zum Internet vor. Wenn diese Systeme von einem Remotestandort die Anweisung erhalten, die serielle Schnittstelle des Internetrouters des Unternehmens mit Daten zu überschütten, kann dabei problemlos die DS3-Verbindung mit falschen Daten überflutet werden. Seite 9

10 Selbst wenn jeder Host nur Datenverkehr mit 1 MBit/s erzeugen kann (und Labortests haben bewiesen, dass eine handelsübliche Unix-Arbeitsstation mit einem beliebten DDoS-Tool ohne Weiteres 50 MBit/s erzielen kann), ist diese Datenmenge immer noch mehr als doppelt so groß wie die Bandbreite der Internetanbindung des erwähnten Unternehmens. Das führt dazu, dass legitime Webanforderungen verloren gehen und die Site für die meisten Benutzer ausgefallen zu sein scheint. Zwar würde die lokale Firewall alle falschen Daten zurückweisen, aber zu diesem Zeitpunkt wäre der Schaden schon eingetreten. Die Daten hätten die WAN-Verbindung bereits passiert und die Verbindung blockiert. Unser fiktives E-Commerce-Unternehmen hat nur in Zusammenarbeit mit seinem ISP eine Chance, derartige Angriffe zu vereiteln. Der ISP kann für die Ausgangsschnittstelle der Unternehmenssite eine Ratenbegrenzung konfigurieren. Mit Hilfe dieser Ratenbegrenzung kann der größte Teil des unerwünschten Datenverkehrs zurückgewiesen werden, sobald dieser mehr als einen festgelegten Teil der verfügbaren Bandbreite einnimmt. Das Wichtigste hierbei ist, Daten korrekt als unerwünscht zu kennzeichnen. Häufig verwendete Formen von DDoS-Tools arbeiten mit ICMP-, TCP SYN- oder UDP-Flooding. In einer E-Commerce-Umgebung ist diese Art von Datenverkehr recht einfach zu kategorisieren. Die einzige Gefahr besteht darin, dass der Administrator durch die Begrenzung von TCP SYN- Angriffen auf Port 80 (http) während eines Angriffs Zugriffe durch legitime Benutzer unterdrückt. Und selbst dann ist es besser, neue legitime Benutzer vorübergehend zu sperren und dafür die Routing- und Managementverbindungen zu erhalten, als einen Angriff auf den Router zuzulassen und dadurch jegliche Konnektivität einzubüßen. Bei ausgeklügelteren Angriffen wird Datenverkehr an Port 80 mit gesetztem ACK-Bit verwendet, so dass dieser wie legitimer Webverkehr aussieht. Dass ein Administrator einen solchen Angriff richtig kategorisieren könnte, ist sehr unwahrscheinlich, denn schließlich lässt jeder gerade TCP-Kommunikationen mit Bestätigung gerne in sein Netzwerk. Es gibt dennoch Möglichkeiten, solche Angriffe abzuwehren. Dazu bietet sich zum Beispiel die Befolgung der Filterrichtlinien für Netzwerke an, die in RFC 1918 und RFC 2827 niedergelegt sind. Dabei werden in RFC 1918 die Netzwerke benannt, die der privaten Verwendung vorbehalten sind und im öffentlichen Internet niemals sichtbar werden sollten. Die Filterung gemäß RFC 2827 wird unter dem Eintrag zu IP-Spoofing in der Fibel zur Netzwerksicherheit in diesem Dokument erläutert. Die Filterung nach RFC 1918 und 2827 sollte beispielsweise in Form von Eingangsfiltern an mit dem Internet verbundenen Routern eingesetzt werden, um zu verhindern, dass unerlaubter Datenverkehr das Unternehmens-netzwerk erreicht. Bei Implementierung auf Seite des ISP lässt sich mit Hilfe der Filterung verhindern, dass DDoS-Angriffspakete, die diese Adressen als Absender verwenden, die WAN-Verbindung passieren, wodurch gegebenenfalls während des Angriffs Bandbreite eingespart werden kann. Würden alle ISPs dieser Welt die in RFC 2827 niedergelegten Richtlinien umsetzen, ließe sich IP-Spoofing erheblich reduzieren. Damit wäre es zwar noch immer nicht möglich, DDoS-Angriffe von vornherein zu unterbinden, jedoch könnte die Absenderadresse eines solchen Angriffs nicht mehr getarnt werden, und eine Rückverfolgung zu den angreifenden Netzwerken würde erheblich einfacher. Seite 10

11 Applikationen sind Angriffsziele Applikationscodes werden zum überwiegenden Teil von Menschen geschrieben und sind daher recht fehleranfällig. Solche Fehler können gutartig sein, z. B. wenn sie dazu führen, dass ein Dokument im Druck merkwürdig aussieht, sie können aber auch schwer wiegender Natur sein, so zum Beispiel, wenn durch einen Fehler die Kreditkartennummern auf einem Datenbankserver von jedem abgerufen werden können. Diese schwer wiegenden Probleme sowie eine ganze Reihe anderer, allgemeinerer Sicherheitsprobleme können mit Hilfe von Angriffserkennungssystemen (Intrusion Detection Systeme, ID-Systeme, Abk. IDS) auf-gedeckt werden. Diese Angriffserkennung funktioniert nicht anders als eine Warnanlage in der realen Welt. Sobald das IDS etwas erkennt, das es als Angriff wertet, kann es entweder selbstständig entsprechende Maßnahmen ergreifen oder eine Mitteilung an ein Managementsystem senden, damit der Administrator reagieren kann. Manche Systeme sind mehr oder weniger in der Lage, auf solche Angriffe automatisch zu reagieren und diese zu vereiteln. Die hostbasierte Angriffserkennung kann Betriebssystem- und Applikationsaufrufe auf einzelnen Hosts abfangen. Alternativ kann ein solches ID-System auch nachträglich lokale Protokolldateien analysieren. Im ersten Fall können Angriffe effektiver vereitelt werden, während im zweiten Fall die Reaktion auf einen Angriff eher passiv ausfällt. Aufgrund ihrer besonderen Rolle sind hostbasierte ID-Systeme (HIDS) im Vergleich zu Netzwerk-IDS (NIDS) häufig besser geeignet, bestimmte Angriffe zu vereiteln als einfach nur bei Erkennen eines Angriffs eine Warnung auszugeben. Durch diese Eigenheit geht jedoch die Perspektive für das Netzwerk als Ganzes verloren. In diesem Bereich glänzt wiederum das NIDS. Daher empfiehlt sich als umfassendes Angriffserkennungssystem eine Kombination der beiden Systeme, d.h. HIDS auf kritischen Hosts und NIDS für das gesamte Netzwerk. Nach der anfänglichen Einrichtung muss jede IDS-Implementierung fein abgestimmt werden, um ihre Effektivität zu steigern und Fehlalarme zu vermeiden. Bei Fehlalarmen handelt es sich um Alarme, die fälschlicherweise durch legitimen Datenverkehr bzw. legitime Aktivitäten ausgelöst werden. Als Fehlzulassung hingegen werden Angriffe bezeichnet, die das ID-System nicht erkennt. Nach einer Feinabstimmung des IDS kann dieses gezielter für seine Aufgabe zur Abwehr von Bedrohungen konfiguriert werden. Wie bereits erwähnt, sollte das HIDS so konfiguriert werden, dass die meisten wirklichen Bedrohungen auf Hostebene abgefangen werden können, denn dieses System bietet die besten Voraussetzungen, um eine bestimmte Aktivität als tatsächliche Bedrohung zu erkennen. Beim NIDS gibt es im Wesentlichen zwei mögliche Gegenmaßnahmen zu beachten. Die erste Möglichkeit, die bei falscher Verwendung potenziell den größten Schaden anrichten kann, besteht darin, Datenverkehr auszugrenzen, indem Router mit Zugriffs-kontrollfiltern ausgestattet werden. Wenn ein NIDS einen Angriff von einem bestimmten Host über ein bestimmtes Protokoll erkennt, kann es den betreffenden Host für einen zuvor festgelegten Zeitraum daran hindern, auf das Netzwerk zuzugreifen. Auf den ersten Blick mag diese Methode als wertvolles Instrument für den Sicherheitsadministrator erscheinen, tatsächlich jedoch muss dieser bei der Implementierung größte Vorsicht walten lassen. Das erste Problem, das hierbei beachtet werden sollte, ist das Adressenspoofing. Erkennt das NIDS einen Angriff auf den eine Gegemaßnahme durchgeführt werden soll, so wird eine Access-Liste auf die Quell-IP-Adresse erzeugt, die jeden Verkehr von dieser IP-Adresse unterbindet. Wenn nun aber bei diesem Angriff eine gespoofte Quell-Adresse verwendet wurde, hat das NIDS eine Adresse gesperrt, von der niemals ein Angriff ausgegangen ist. Und handelt es sich bei der von dem Hacker verwendeten IP-Adresse zufällig um die IP-Adresse des für den abgehenden Datenverkehr zuständigen HTTP-Proxyservers eines großen ISP, kann es sogar passieren, dass unzählige Benutzer gesperrt werden. Das allein könnte für kreative Hacker schon als Anreiz für einen DoS- Angriff ausreichen. Seite 11

12 Um die Risiken des Ausgrenzungsverfahrens möglichst gering zu halten, sollte diese Methode grundsätzlich nur bei TCP-Datenverkehr angewandt werden, denn dabei ist erfolgreiches Spoofing sehr viel schwieriger als bei UDP. Zudem ist der Einsatz dieser Methode nur in Fällen einer realen Bedrohung zu empfehlen, wenn also die Gefahr, dass es sich bei einem erkannten Angriff eigentlich um einen Fehlalarm handelt, sehr gering ist. Innerhalb eines Netzwerks gibt es jedoch noch zahlreiche weitere Möglichkeiten. So lässt sich beispielsweise durch den effektiven Einsatz der Filterung nach RFC 2827 das Spoofing weitgehend unterbinden. Zudem können auch Angriffe aus dem internen Netzwerk strenger unterbunden werden, da sich Kunden in der Regel nicht im internen Netzwerk befinden. Dabei fällt auch ins Gewicht, dass interne Netzwerke häufig nicht über so statusbetonte Filtermechanismen verfügen wie Edgeverbindungen. Aus diesem Grund kommt hier dem IDS eine wesentlich wichtigere Rolle zu als in der externen Umgebung. Die zweite Möglichkeit zur Abwehr von Bedrohungen mittels NIDS stellt die Verwendung von TCP-Resets dar. Diese TCP-Resets funktionieren, wie der Name schon sagt, nur bei TCP- Datenverkehr. Dabei werden aktive Angriffe beendet, indem TCP-Resetmeldungen sowohl an den angreifenden als auch an den angegriffenen Host gesendet werden. Da sich bei TCP- Datenverkehr das Spoofing schwieriger gestaltet, ist die Verwendung von TCP-Resets in vielen Fällen eher zu empfehlen als das Ausgrenzungsverfahren. Unter dem Gesichtspunkt der Leistung muss berücksichtigt werden, dass ein NIDS Pakete bei der Übertragung überwacht. Werden nämlich Pakete schneller gesendet, als das NIDS sie verarbeiten kann, hat das keinen negativen Einfluss auf die Netzwerkleistung, denn das NIDS befindet sich nicht unmittelbar im Datenfluss. Allerdings kann das NIDS dann nicht mehr so effektiv arbeiten, und es können Pakete übersehen werden, wodurch es sowohl zu Fehlalarmen wie auch zu nicht erkannten Angriffen kommen kann. Besonders ist darauf zu achten, dass die Kapazität des IDS ausreichend hoch ist, damit alle Vorteile voll ausgenutzt werden können. Unter dem Gesichtspunkt des Routing ist zu beachten, dass ID-Systeme ebenso wie viele statusorientierte Engines in Umgebungen mit asymmetrischem Routing nicht einwandfrei arbeiten. Wenn Pakete über eine Gruppe von Routern und Switches nach außen gesendet werden, jedoch über eine andere Gruppe von Routern und Switches zurückkommen, hat dies zur Folge, dass die ID-Systeme nur die Hälfte des Datenverkehrs sehen und daher Fehlalarme ausgeben oder echte Angriffe nicht erkennen. Seite 12

13 Sicheres Management und Reporting Was man protokolliert, sollte man auch lesen Leicht gesagt Und sicherlich hat auch jeder, der sich mit der Netzwerksicherheit befasst, diesen Satz schon einmal im Munde geführt. In der Praxis kann es sich aber als ziemliche Herausforderung entpuppen, Daten von über 100 Geräten zu protokollieren und auch noch zu lesen. Welche Protokolle sind die wichtigsten? Wie kann man wichtige Meldungen von einfachen Benachrichtigungen unterscheiden? Wie kann man sicherstellen, dass die Protokolle zwischenzeitlich nicht manipuliert werden? Wie kann man gewährleisten, dass alle Zeitstempel übereinstimmen, wenn mehrere Geräte denselben Alarm melden? Welche Informationen sind von Bedeutung, falls die Daten des Event-Protokolls für polizeiliche Ermittlungen benötigt werden? Wie kann man die Unmengen von Meldungen handhaben, die in einem großen Netzwerk erzeugt werden können? All diese Fragen müssen bedacht werden, wenn ein effektives Management von Protokolldateien angestrebt wird. Im Hinblick auf das Management stellen sich ganz andere Fragen: Wie lässt sich ein Gerät sicher managen? Wie können Inhalte im Push-Verfahren an öffentliche Server gesendet und dabei sichergestellt werden, dass die Daten während der Übertragung nicht manipuliert werden? Wie lassen sich zum Zweck der Fehlersuche nach Angriffen oder Netzwerkausfällen Änderungen an Geräten zurückverfolgen? Unter dem Gesichtspunkt der Architektur betrachtet, sollte optimalerweise als erster Schritt einer jeden Management- und Reportingstrategie Out-of-band-Management für Netzwerksysteme implementiert werden. Der Begriff Out-of-band (OOB), zu Deutsch Außenband-, bezieht sich auf ein Netzwerk, in dem kein Produktionsdatenverkehr stattfindet. Sofern dies möglich ist, sollten Geräte über eine direkte lokale Verbindung zu einem solchen Netzwerk verfügen. Ist eine OOB-Implementierung (aufgrund von geografischen Gegebenheiten oder Problemen im System) nicht möglich, sollte die Verbindung über einen privaten, verschlüsselten Tunnel innerhalb des Produktionsnetzwerks hergestellt werden. Ein solcher Tunnel sollte zuvor so konfiguriert werden, dass eine Kommunikation ausschließlich über die Ports möglich ist, die für die Management- und Reportingfunktionen erforderlich sind. Darüber hinaus ist es ratsam, den Tunnel zu filtern, so dass nur Hosts mit entsprechender Berechtigung Tunnels initiieren und beenden können. Besonders ist darauf zu achten, dass das Out-of-band-Netzwerk nicht selbst eine Schwachstelle im Hinblick auf die Sicherheit darstellt. Nähere Informationen hierzu finden Sie im Abschnitt Managementmodul. Nach der Implementierung eines OOB-Managementnetzwerks gestaltet sich die Handhabung der Protokollierung und des Reporting etwas unkomplizierter. Die meisten Netzwerkgeräte sind in der Lage, Syslog-Daten zu senden, die wiederum bei der Fehlersuche aufgrund von Netzwerkproblemen oder Sicherheitsrisiken mitunter von unschätzbarem Wert sind. Solche Daten sollten an einen oder mehrere für die Syslog-Analyse zuständige Hosts im Managementnetzwerk gesendet werden. Je nach Art des betreffenden Geräts stehen verschiedene Protokollierungsebenen zur Auswahl, wodurch gewährleistet werden kann, dass weder zu viele noch zu wenige Daten an die Protokollierungsgeräte gesendet werden. Des Weiteren sollten die Protokolldaten der Geräte innerhalb der Analysesoftware mit Flags gekennzeichnet werden, um so eine Differenzierung bei Anzeige und Reporting zu ermöglichen. So sind unter Umständen während eines Angriffs die von Layer-2-Switches gesendeten Protokolldaten von geringerem Interesse als die Daten, die das ID-System bereitstellt. Spezialisierte Applikationen wie zum Beispiel IDS verwenden häufig eigene Protokollierungsprotokolle zur Übertragung von Alarminformationen. Diese Daten sollten grundsätzlich an separate Managementhosts übermittelt werden, die für die Verarbeitung von Angriffsalarmen besser ausgestattet sind. Eine Kombination der Alarmdaten aus vielen unterschiedlichen Quellen ermöglicht unter Umständen einen Einblick in den Gesamtzustand des Netzwerks. Seite 13

14 Um zu gewährleisten, dass Protokollmeldungen einander zeitlich entsprechen, müssen die Systemuhren der Hosts wie der Netzwerkgeräte aufeinander abgestimmt werden. Für Geräte, die NTP (Network Time Protocol) unterstützen, bietet dies eine effektive Möglichkeit zur Einstellung und Synchronisierung der genauen Uhrzeit auf allen Geräten. Im Falle eines Angriffs zählt jede Sekunde, denn es ist von großer Bedeutung, die genaue Reihenfolge der Schritte zu ermitteln, in denen der betreffende Angriff stattfand. Im Hinblick auf das Management, zu dem im Rahmen dieses Dokuments jegliche auf einem Gerät oder durch einen Administrator ausgeführten Funktionen zählen, bei denen es sich nicht um Protokollierung und Reporting handelt, stellen sich weitere Probleme und bieten sich weitere Lösungen an. Wie bei der Protokollierung und dem Reporting ermöglicht das OOB-Netzwerk auch in diesem Fall die Übertragung von Informationen in eine kontrollierte Umgebung, in der Manipulationen ausgeschlossen sind. Dennoch sollte einer sicheren Konfiguration wie beispielsweise unter Verwendung von Secure Socket Layer (SSL) oder Secure Shell (SSH) der Vorzug gegeben werden, sofern dies möglich ist. SNMP ist mit größter Vorsicht zu genießen, da das zugrundeliegende Protokoll eine Reihe eigener Schwachstellen in Bezug auf die Sicherheit aufweist. Ziehen Sie in Erwägung, ob es nicht sinnvoll ist, über SNMP nur Lesezugriff auf die Geräte zuzulassen und den SNMP- Community-String mit derselben Sorgfalt zu schützen, die Sie auch bei einem root-kennwort auf einem kritischen Unix-Host walten lassen würden. Im Rahmen des sicheren Managements stellt das Management von Konfigurationsänderungen ein weiteres Problem dar. Wird ein Netzwerk angegriffen, sind Informationen über den Zustand kritischer Netzwerkgeräte sowie den Zeitpunkt der letzten bekannten Änderungen von größter Bedeutung. Daher sollte im Rahmen jeder umfassenden Sicherheitspolicy ein entsprechender Plan erarbeitet werden, zumindest jedoch sollten alle Änderungen unter Verwendung von Authentifizierungssystemen auf den Geräten sowie über FTP/TFTP archivierten Konfigurationen aufgezeichnet werden. Unternehmensmodul Ein Unternehmensnetzwerk setzt sich aus zwei Funktionsbereichen zusammen, nämlich dem Campus- und dem Edgebereich. Diese sind wiederum in Module unterteilt, die den unterschiedlichen Funktionen des jeweiligen Bereichs im Einzelnen entsprechen. Die einzelnen Module werden in diesem Dokument zunächst detailliert erläutert. Darauf folgt jeweils ein Abschnitt, in dem unterschiedliche Designoptionen beschrieben werden. Erwartete Bedrohungen Im Hinblick auf Bedrohungen unterscheiden sich Unternehmensnetzwerke nicht von den meisten anderen Netzwerken, die mit dem Internet verbunden sind. Es gibt interne Benutzer, die Zugriff auf Ressourcen außerhalb des Netzwerks benötigen, und externe Benutzer, die auf die Ressourcen des internen Netzwerks zugreifen müssen. Zudem gibt es eine Reihe allgemeiner Bedrohungen, die zu der Art von anfänglicher Kompromittierung führen, die ein Hacker sich zunutze machen kann, um tiefer in das Netzwerk einzudringen und dort Schaden anzurichten. An erster Stelle stehen dabei Bedrohungen, die von internen Benutzern ausgehen. Es ist eine unbestreitbare Tatsache, dass die meisten Angriffe ihren Ursprung im internen Netzwerk haben. Lediglich über den prozentualen Anteil dieser Angriffe sind sich die verschiedenen Statistiken uneinig. Solche Angriffe aus dem internen Netzwerk können von den unterschiedlichsten Personen ausgehen, z. B. verärgerten Angestellten, Wirtschafts-spionen, Besuchern oder unachtsamen und ungeschickten Benutzern. Diese sehr reale interne Bedrohung sollte bei der Entwicklung eines Sicherheitskonzepts keinesfalls außer Acht gelassen werden. Seite 14

15 Die zweite Bedrohung betrifft die mit dem Internet verbundenen öffentlich zugänglichen Hosts. Angriffe auf diese Systeme erfolgen aller Wahrscheinlichkeit nach unter Ausnutzung von Schwachstellen der Anwendungsschicht oder in Form von DoS-Angriffen. Schließlich könnte ein Hacker auch versuchen, mit Hilfe eines so genannten War-dialer Ihre telefonischen Zugangsnummern zu ermitteln und sich so über die Systeme Zugriff auf das Netzwerk zu verschaffen. Bei diesen War-dialers handelt es sich um Soft- und/oder Hardware, die darauf ausgelegt ist, zahlreiche Telefonnummern anzuwählen und die Art des Systems an der Gegenstelle zu ermitteln. Weitaus am stärksten bedroht sind Personal Computer, auf denen der Benutzer Fernbedienungssoftware installiert hat. Solche Systeme weisen grundsätzlich keinen hohen Sicherheitsstandard auf. Da sich diese Systeme hinter einer Firewall befinden, kann ein Hacker, der sich über einen Host einwählt und sich somit Zugriff verschafft, im Netzwerk als der betreffende Benutzer ausgeben. Umfassende Informationen zu den verschiedenen Bedrohungen finden Sie in der Fibel zur Netzwerksicherheit gegen Ende des Dokuments. Unternehmenscampus Es folgt eine detaillierte Analyse sämtlicher im Unternehmenscampus enthaltenen Module. Abbildung 3: Der Unternehmenscampus im Einzelnen Seite 15

16 Managementmodul Das Managementmodul dient in erster Linie zur Erleichterung des sicheren Managements aller Geräte und Hosts innerhalb der SAFE-Architektur des Unternehmens. Protokoll- und Reportinginformationen werden von den Geräten an die Managementhosts gesendet, während Inhalte, Konfigurationen sowie neue Software umgekehrt von den Managementhosts an die Geräte gesendet werden. Abbildung 4: Der Fluss der Managementdaten Hauptgeräte SNMP-Managementhost bietet SNMP-Management für Geräte NIDS-Host sammelt Alarme für alle NIDS-Geräte im Netzwerk Syslog-Host(s) sammelt bzw. sammeln Protokollinformationen für PIX- und NIDS-Hosts Zugangskontrollserver stellt einmalige Zwei-Faktoren-Authentifizierungsdienste für die Netzwerkgeräte zur Verfügung OTP-Server - autorisiert die vom Zugangskontrollserver übertragenen Einmalkennwörter (One-Time Password; OTP) Systemadministrationshost ist zuständig für Konfigurations-, Software- und Inhaltsänderungen an Geräten Cisco IOS Firewall ermöglicht die differenzierte Kontrolle des Verkehrsflusses zwischen den Managementhosts und den verwalteten Geräten Cisco Catalyst-Switches gewährleisten, dass die Daten von den verwalteten Geräten nur direkt an die IOS Firewall übermittelt werden können Seite 16

17 Abbildung 5: Das Managementmodul im Einzelnen Abgewendete Bedrohungen Unberechtigter Zugriff durch die Filterung an der IOS Firewall wird unberechtigter Datenverkehr in beide Richtungen in den meisten Fällen abgefangen Mann-in-der-Mitte -Angriffe (man-in-the-middle) Managementdaten passieren ein privates Netzwerk, wodurch Mann-in-der-Mitte -Angriffe erschwert werden Kennwortangriffe der Zugangskontrollserver ermöglicht eine strenge Zwei-Faktoren- Authentifizierung an jedem Gerät IP-Spoofing gespoofter Datenverkehr in beide Richtungen wird abgefangen Packet Sniffer der Einsatz von Sniffern ist in einer geswitchten Infrastruktur nur begrenzt effektiv Vertrauensbruch - private VLANs verhindern, dass ein kompromittiertes Gerät sich als Managementhost ausgibt Abbildung 6: Die verschiedenen Rollen der Angriffsabwehr im Managementmodul Seite 17

18 Entwicklungsrichtlinien Wie der vorstehenden Abbildung zu entnehmen, werden im SAFE-Netzwerk für das Unternehmensmanagement zwei Netzwerksegmente verwendet, die durch einen als Firewall dienenden IOS-Router und ein VPN-Terminierungsgerät voneinander getrennt sind. Das außerhalb der Firewall liegende Segment ist mit allen Geräten verbunden, die verwaltet werden müssen. Das innerhalb der Firewall liegende Segment umfasst die eigentlichen Managementhosts sowie die IOS-Router, die als Terminalserver dienen. Über die verbleibende Schnittstelle erfolgt die Verbindung mit dem Produktionsnetzwerk. Hier ist jedoch ausschließlich IPSec-geschützter Managementdatenverkehr von zuvor festgelegten Hosts zulässig. Auf diese Weise kann auch ein Cisco-Gerät, das physisch nicht über eine ausreichende Anzahl an Schnittstellen zur Unterstützung der normalen Managementverbindung verfügt, verwaltet werden. Die IOS Firewall ist so konfiguriert, dass syslog-informationen in das Managementsegment durchgelassen werden. Ebenso dürfen Telnet-, SSH- und SNMP-Daten passieren, sofern diese im internen Netzwerk initiiert wurden. Beide dem Management vorbehaltenen Subnetze arbeiten in einem Adressraum, der vom übrigen Teil des Produktionsnetzwerks vollständig getrennt ist. Auf diese Weise wird sichergestellt, dass kein Routing-Protokoll für das Managementnetzwerk werben kann. Zudem wird es so den Geräten im Produktionsnetzwerk möglich, jeden Datenverkehr von den Managementsubnetzen, der in den Verbindungen des Produktionsnetzwerks erscheint, abzufangen. Das Managementmodul bietet Möglichkeiten zum Konfigurationsmanagement für nahezu alle Geräte im Netzwerk. Dabei kommen im Wesentlichen zwei Technologien zum Tragen, nämlich Cisco IOS-Router, die als Terminalserver agieren, und ein dediziertes Netzwerksegment für das Management. Die Router bieten eine Reverse Telnet-Funktion für die Konsolenports aller Cisco- Geräte im gesamten Unternehmen. Im dedizierten Netzwerksegment für das Management stehen weitere umfassende Managementfunktionen zur Verfügung (Softwareänderungen, Inhaltsupdates, Protokoll- und Alarmsammlung sowie SNMP-Management). Die wenigen Geräte und Hosts, die von diesen Managementfunktionen ausgenommen sind, werden über IPSec- Tunnel verwaltet, die von dem Managementrouter ausgehen. Da das Managementnetzwerk administrativen Zugriff auf beinahe jeden Bereich des Netzwerks hat, kann es zu einem sehr attraktiven Ziel für Hacker werden. Um diese Gefahr zu vermeiden, wurden bei der Entwicklung des Managementmoduls eine Reihe unterschiedlicher Technologien eingesetzt. Die primäre und größte Bedrohung geht von Hackern aus, die versuchen, direkt auf das Managementnetzwerk zuzugreifen. Dies lässt sich nur durch den effektiven Einsatz von Sicherheitsmechanismen auch in den übrigen Modulen innerhalb des Unternehmens verhindern. Die nachfolgend genannten Bedrohungen können nur eintreten, wenn die erste Verteidigungslinie bereits durchbrochen wurde. Um der Gefahr der Kompromittierung von Geräten zu begegnen, wird an der Firewall ebenso wie auf jedem möglichen anderen Gerät eine Zugangskontrolle implementiert, mit der sich ein Missbrauch des Managementkanals unterbinden lässt. Ist ein Gerät erst kompromittiert, kann es nicht einmal mehr mit anderen Host in demselben Subnetz kommunizieren, da private VLANs im Managementsegment sämtlichen Datenverkehr von den gemanagten Geräten zwangsweise direkt an die IOS Firewall vermitteln, wo die Filterung stattfindet. Dank der OTP-Umgebung ergeben sich beim Kennwortsniffing nur nutzlose Informationen. Im Hinblick auf das SNMP-Management sind wiederum ganz andere Punkte zur Gewährleistung der Sicherheit zu bedenken. Dadurch, dass der SNMP-Datenverkehr im Managementsegment verbleibt, braucht er nur ein isoliertes Segment zu passieren, wenn Managementinformationen von Geräten abgerufen werden. Im Rahmen von SAFE wurde die Entscheidung getroffen, dass für das SNMP-Management Informationen ausschließlich im Pull-Verfahren von Geräten abgerufen werden sollen, das Senden von Änderungen im Push-Verfahren hingegen nicht Seite 18

19 zulässig sein soll. Um dies zu gewährleisten, sind alle Geräte lediglich mit einem Nur-Lese - String konfiguriert. Korrektes Netzwerkmanagement ist nur möglich, wenn die Syslog-Informationen korrekt gesammelt und analysiert werden. Syslog stellt wichtige Informationen in Bezug auf die Sicherheit zur Verfügung. Unter anderem gibt das Protokoll Aufschluss über Sicherheitsverletzungen und Konfigurationsänderungen. Je nach Gerät sind unter Umständen Syslog- Informationen auf unterschiedlichen Ebenen erforderlich. Wird zum Beispiel die vollständige Protokollierung gewählt, bei der sämtliche Meldungen gesendet werden, kann das Protokoll einen solchen Umfang annehmen, dass ein einzelner Mensch oder auch der Syslog- Analysealgorithmus damit völlig überfordert ist. Die Protokollierung als Selbstzweck ist der Sicherheit in keiner Weise dienlich. Im SAFE-Prüflabor wurden alle Konfigurationen mit Hilfe von Stand-alone-Managementapplikationen sowie der Command Line Interface (CLI) vorgenommen. Das bedeutet jedoch keineswegs, dass die Verwendung von Policymanagementsystemen zur Konfiguration in SAFE nicht möglich sei. Mit Einrichtung dieses Managementmoduls wird der Einsatz einer solchen Technologie absolut machbar. Im Rahmen von SAFE wurden jedoch die CLI und Stand-alone- Managementapplikationen gewählt, da diese Konfigurationsmethoden heutzutage in den meisten Netzwerken angewandt werden. Alternativen Ein vollständiges Out-of-band-Management ist nicht immer möglich, da dies von manchen Geräten möglicherweise nicht unterstützt wird oder aufgrund geografischer Unterschiede ein Inband-Management unumgänglich ist. Ist Letzteres erforderlich, muss das Augenmerk ganz besonders auf die Sicherung des Transports der Managementprotokolle gerichtet werden. Zu diesem Zweck eignet sich der Einsatz von IPSec, SSH, SSL oder eines anderen verschlüsselten und authentifizierten Transportsystems, das Managementinformationen passieren können. Sollte es einmal vorkommen, dass an derselben Schnittstelle eines Geräts sowohl Benutzerdaten als auch Managementdaten auftreten, dann müssen Kennwörter, Community- Strings, kryptografische Schlüssel und Access-Listen, die die Kommunikation zu den Managementdiensten steuern, mit besonderer Sorgfalt eingesetzt werden. In naher Zukunft angestrebte Architekturziele Die aktuelle Implementierung für Reporting- und Alarmfunktionen ist auf mehrere Hosts aufgeteilt. Manche Hosts sind ideal für die Analyse von Firewall- und IDS-Daten geeignet, während andere Hosts Daten von Routern und Switches besser handhaben können. In Zukunft werden alle Daten auf derselben Gruppe redundanter Hosts gesammelt, so dass eine Korrelation von Events zwischen allen Geräten möglich ist. Seite 19

20 Kernmodul Das Kernmodul der SAFE-Architektur unterscheidet sich nicht wesentlich von den Kernmodulen anderer Netzwerkarchitekturen. Dieses Modul ist lediglich dafür zuständig, Daten so schnell wie möglich zwischen zwei Netzwerken zu routen und zu switchen. Hauptgeräte Layer-3-Switches routen und switchen Daten aus dem Produktionsnetzwerk zwischen zwei Modulen Abbildung 7: Das Kernmodul im Einzelnen Abgewendete Bedrohungen Keine das Kernmodul ist abhängig von effektiven Sicherheitsstrategien in den angrenzenden Modulen Entwicklungsrichtlinien Es wurden die Standardrichtlinien zur Implementierung befolgt, wie sie auch in sorgfältig konzipierten Cisco-basierten Netzwerken mit Kern-, Verteilungs- und Access-Schicht üblicherweise zugrundegelegt werden. Zwar werden innerhalb der SAFE-Architektur keine besonderen Anforderungen im Hinblick auf den Kern der Unternehmensnetzwerke formuliert, jedoch entsprechen die Kernswitches den weiter oben angeführten Sicherheitsgrundsätzen, so dass sie umfassend vor direkten Angriffen geschützt sind. Seite 20