Dieser Artikel ist der dritte in der Artikelreihe „Wie man die Netzwerkinfrastruktur unter Kontrolle bringt“. Den Inhalt aller Artikel der Reihe und die Links dazu finden Sie hier.

Es hat keinen Sinn, über die vollständige Beseitigung von Sicherheitsrisiken zu sprechen. Grundsätzlich können wir sie nicht auf null reduzieren. Außerdem muss man verstehen, dass unsere Lösungen immer teurer werden, je sicherer wir unser Netzwerk machen wollen. Es ist wichtig, einen sinnvollen Kompromiss zwischen Preis, Komplexität und Sicherheit für Ihr Netzwerk zu finden.

Natürlich ist das Sicherheitsdesign organisch in die allgemeine Architektur integriert, und die verwendeten Sicherheitslösungen haben Einfluss auf die Skalierbarkeit, Zuverlässigkeit und Verwaltbarkeit der Netzwerkinfrastruktur, was ebenfalls berücksichtigt werden muss.

Aber ich möchte daran erinnern, dass wir jetzt nicht über den Aufbau eines Netzwerks sprechen. Entsprechend unseren Ausgangsbedingungen haben wir bereits ein Design, die Ausrüstung wurde ausgewählt und die Infrastruktur wurde geschaffen, und in dieser Phase sollten wir, wenn möglich, "leben" und Lösungen im Kontext des zuvor gewählten Ansatzes finden.

Unsere Aufgabe ist es jetzt, die Risiken, die mit der Netzwerksicherheit verbunden sind, zu identifizieren und sie auf ein angemessenes Niveau zu reduzieren.

Audit der Netzwerksicherheit

Wenn in Ihrer Organisation Prozesse nach ISO 27k implementiert sind, sollte das Sicherheitse audit und Änderungen im Netzwerk organisch in die allgemeinen Prozesse im Rahmen dieses Ansatzes integriert werden. Aber diese Standards sind nicht über spezifische Lösungen, nicht über Konfiguration, nicht über Design… Es gibt keine eindeutigen Empfehlungen, es gibt keine Standards, die detailliert vorschreiben, wie Ihr Netzwerk aussehen sollte. Das ist die Komplexität und Schönheit dieser Aufgabe.

Ich würde einige mögliche Netzwerksicherheitsaudits hervorheben:

Audit der Gerätekonfiguration (Hardening)
Audit des Sicherheitsdesigns
Audit der Zugriffe
Audit der Prozesse

Audit der Gerätekonfiguration (Hardening)

Es scheint, dass dies in den meisten Fällen der beste Ausgangspunkt für das Audit und die Verbesserung der Sicherheit Ihres Netzwerks ist. IMHO ist dies eine gute Demonstration des Pareto-Prinzips (20 % des Aufwands bringen 80 % des Ergebnisses, während die restlichen 80 % des Aufwands nur 20 % des Ergebnisses bringen).

Die Essenz ist, dass wir normalerweise Empfehlungen von Anbietern zu den „best practices“ für die Sicherheit bei der Konfiguration von Geräten haben. Dies wird als „Hardening“ bezeichnet.

Es wird auch häufig eine Umfrage (oder selbst erstellt) auf der Grundlage dieser Empfehlungen gefunden, die Ihnen hilft zu bestimmen, wie gut die Konfiguration Ihrer Geräte diesen „Best Practices“ entspricht, und basierend auf dem Ergebnis Änderungen in Ihrem Netzwerk vorzunehmen. Dies ermöglicht es Ihnen, die Sicherheitsrisiken relativ einfach und tatsächlich ohne Kosten erheblich zu senken.

Einige Beispiele für verschiedene Cisco-Betriebssysteme.
Cisco IOS Konfigurationshärtung
Cisco IOS-XR Konfigurationshärtung
Cisco NX-OS Konfigurationshärtung
Cisco Baseline Sicherheits-Checkliste
Basierend auf diesen Dokumenten kann eine Liste von Anforderungen für die Konfiguration jedes Gerätetyps erstellt werden. Zum Beispiel könnten diese Anforderungen für Cisco N7K VDC so aussehen: so.

Auf diese Weise können Konfigurationsdateien für verschiedene Arten von aktiven Geräten Ihrer Netzwerk-Infrastruktur erstellt werden. Anschließend können Sie diese Konfigurationsdateien manuell oder unter Verwendung von Automatisierung „hochladen“. Wie dieser Prozess automatisiert werden kann, wird in einer anderen Artikelreihe, die sich mit Orchestrierung und Automatisierung beschäftigt, ausführlich behandelt.

Sicherheitsaudit des Designs

In der Regel sind in einem Unternehmensnetzwerk (enterprise network) in irgendeiner Form die folgenden Segmente vorhanden:

DC (Öffentliche Dienste DMZ und Intranet-Rechenzentrum)
Internetzugang
Remote Access VPN
WAN Edge
Branch
Campus (Büro)
Kern

Die Namen stammen aus Cisco SAFE Modellen, aber es ist natürlich nicht zwingend erforderlich, sich an diese Namen und dieses Modell zu halten. Schließlich möchte man über den Inhalt sprechen und sich nicht in Formalitäten verlieren.

Für jedes dieser Segmente werden die Anforderungen an das Sicherheitsniveau, Risiken und folglich die Lösungen unterschiedlich sein.

Betrachten wir jedes dieser Segmente einzeln hinsichtlich der Probleme, mit denen Sie aus Sicht des Sicherheitsdesigns konfrontiert werden könnten. Ich möchte hier nochmals betonen, dass dieser Artikel keineswegs den Anspruch auf Vollständigkeit erhebt, da es in diesem wirklich tiefgründigen und vielschichtigen Thema nicht einfach ist (wenn überhaupt möglich), dies zu erreichen, sondern meine persönliche Erfahrung widerspiegelt.

Es gibt keine perfekte Lösung (zumindest jetzt nicht). Es ist immer ein Kompromiss. Aber es ist wichtig, dass die Entscheidung, einen bestimmten Ansatz zu wählen, bewusst getroffen wird, mit Verständnis für die Vor- und Nachteile.

Rechenzentrum

Das sicherheitskritischste Segment.
Und wie gewohnt gibt es auch hier keine universelle Lösung. Alles hängt stark von den Anforderungen an das Netzwerk ab.

Ist eine Firewall notwendig oder nicht?

Es scheint, dass die Antwort offensichtlich ist, aber es ist nicht ganz so eindeutig, wie es scheint. Und Ihre Auswahl kann nicht nur von der Preis.

Beispiel 1. Latenzen.
Wenn zwischen bestimmten Segmenten des Netzwerks eine geringe Latenz ein wesentliches Kriterium ist, was beispielsweise im Fall von Börsen zutrifft, dann können wir zwischen diesen Segmenten keine Firewalls verwenden. Es ist schwierig, Studien zu Latenzen bei Firewalls zu finden, aber nur wenige Switch-Modelle können Latenzen von weniger als oder etwa 1 µs bereitstellen, deshalb denke ich, dass Firewalls nicht das Richtige für Sie sind, wenn Mikroseunden entscheidend sind.

Beispiel 2. Leistung.
Die Bandbreite der Top L3-Switches liegt in der Regel um Größenordnungen höher als die Bandbreite der leistungsfähigsten Firewalls. Daher wird es Ihnen wahrscheinlich auch nicht möglich sein, diesen Datenverkehr durch Firewalls zu leiten, wenn der Verkehr hochintensiv ist.

Beispiel 3. Zuverlässigkeit.
Firewalls, insbesondere moderne NGFW (Next-Generation Firewalls) – sind komplizierte Geräte. Sie sind wesentlich komplexer als L3/L2-Switches. Sie bieten viele Dienste und Konfigurationsmöglichkeiten, daher ist es nicht verwunderlich, dass ihre Zuverlässigkeit deutlich geringer ist. Wenn die Kontinuität des Dienstes für das Netzwerk entscheidend ist, müssen Sie möglicherweise abwägen, was zu einer besseren Verfügbarkeit führt – Sicherheit durch Firewalls oder die Einfachheit eines Netzes, das auf Switches (oder verschiedenen Arten von Fabriken) mit normalen ACLs basiert.

In den vorangegangenen Beispielen werden Sie höchstwahrscheinlich (wie gewohnt) einen Kompromiss finden müssen. Schauen Sie sich die folgenden Lösungen an:

Wenn Sie beschlossen haben, innerhalb des Rechenzentrums keine Firewalls zu verwenden, müssen Sie sorgfältig überlegen, wie Sie den Zugang am Rand maximal einschränken können. Sie könnten beispielsweise nur die erforderlichen Ports aus dem Internet (für den Client-Datenverkehr) und administrative Zugänge zum Rechenzentrum nur von Jump-Hosts aus öffnen. Führen Sie alle erforderlichen Überprüfungen (Authentifizierung/Autorisierung, Antivirus, Protokollierung, …) auf den Jump-Hosts durch.
Sie können die logische Unterteilung des Netzwerks im Rechenzentrum in Segmente nutzen, ähnlich dem in PSEFABRIC beschriebenen Schema. Beispiel p002. Die Routing-Konfiguration muss so gestaltet sein, dass latenzsensitiver oder hochintensiver Verkehr „innerhalb“ eines Segments (im Falle von p002, dem VRF) läuft und nicht durch die Firewall geht. Der Verkehr zwischen verschiedenen Segmenten wird weiterhin über die Firewall laufen. Auch kann Route-Leaking zwischen VRFs verwendet werden, um die Umleitung des Verkehrs durch die Firewall zu vermeiden.
Es kann auch die Firewall im transparenten Modus verwendet werden, und zwar nur für die VLANs, bei denen diese Faktoren (Latenz/Performance) nicht entscheidend sind. Aber man muss die Einschränkungen, die mit der Verwendung dieses Modus für jeden Anbieter verbunden sind, genau prüfen.
Sie könnten über den Einsatz einer Service-Chain-Architektur nachdenken. Dies würde es ermöglichen, nur den notwendigen Verkehr durch die Firewall zu leiten. Theoretisch sieht das gut aus, aber ich habe diese Lösung noch nie in der Produktion gesehen. Wir haben vor etwa drei Jahren eine Service-Chain für Cisco ACI/Juniper SRX/F5 LTM getestet, aber zu diesem Zeitpunkt schien uns die Lösung „unreif“ zu sein.

Schutzstufe

Nun müssen Sie die Frage beantworten, welche Werkzeuge Sie zur Filterung des Verkehrs verwenden möchten. Hier sind einige der Funktionen, die normalerweise in einer NGFW (z.B.) vorhanden sind: hier):

stateful firewalling (Standard)
application firewalling
threat prevention (Antivirus, Anti-Spyware und Schwachstellen)
URL-Filterung
Datenfilterung (Inhaltsfilterung)
Dateiblocking (Blockierung von Dateitypen)
DOS-Schutz

Und nicht alles ist eindeutig. Es könnte scheinen, dass je höher die Schutzstufe, desto besser. Aber Sie müssen auch berücksichtigen, dass

je mehr der oben genannten Funktionen der Firewall Sie verwenden, desto teurer wird es natürlich (Lizenzen, zusätzliche Module).
Der Einsatz bestimmter Algorithmen kann die Durchsatzrate der Firewall erheblich verringern und auch die Latenzen erhöhen, siehe zum Beispiel hier
Wie bei jeder komplexen Lösung kann die Verwendung komplexer Schutzmethoden die Zuverlässigkeit Ihrer Lösung verringern, z.B. habe ich beim Einsatz von Application Firewalling festgestellt, dass einige ganz standardmäßig funktionierende Anwendungen (DNS, SMB) blockiert wurden.

Wie gewohnt müssen Sie die optimale Lösung für Ihr Netzwerk finden.

Es ist nicht möglich, eindeutig zu beantworten, welche Schutzfunktionen erforderlich sein könnten. Erstens, weil es natürlich von den Daten abhängt, die Sie übertragen oder speichern und zu schützen versuchen. Zweitens ist die Wahl der Schutzmittel in der Tat oft eine Frage des Vertrauens in den Anbieter. Sie kennen die Algorithmen nicht, wissen nicht, wie effektiv sie sind, und können sie nicht umfassend testen.

Daher kann in kritischen Segmenten die Nutzung von Angeboten verschiedener Unternehmen eine gute Lösung sein. Zum Beispiel können Sie einen Antivirus auf der Firewall aktivieren, aber auch eine lokale Antiviruslösung (von einem anderen Anbieter) auf den Hosts verwenden.

Segmentierung

Es geht um die logische Segmentierung des Rechenzentrumsnetzwerks. Beispielsweise stellt die Aufteilung in VLANs und Subnetze ebenfalls eine logische Segmentierung dar, aber wir werden dies aufgrund der Offensichtlichkeit nicht betrachten. Interessant ist die Segmentierung unter Berücksichtigung solcher Entitäten wie FW-Sicherheitszonen, VRF (und deren Analogien bei verschiedenen Anbietern), logischen Geräten (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Ein Beispiel für eine solche logische Segmentierung und ein derzeit gefragter Rechenzentrumsdesign wird in p002 des Projekts PSEFABRIC.

Nachdem Sie die logischen Teile Ihres Netzwerks definiert haben, können Sie nun beschreiben, wie der Datenverkehr zwischen verschiedenen Segmenten fließt, auf welchen Geräten die Filterung erfolgt und mit welchen Mitteln.

Wenn in Ihrem Netzwerk keine klare logische Gliederung vorhanden ist und die Regeln für die Anwendung von Sicherheitspolitiken für verschiedene Datenströme (Flow) nicht formalisiert sind, bedeutet dies, dass Sie bei der Gewährung eines bestimmten Zugriffs gezwungen sind, diese Aufgabe zu lösen, und mit großer Wahrscheinlichkeit werden Sie jedes Mal unterschiedlich entscheiden.

Oft basiert die Segmentierung nur auf FW-Sicherheitszonen. Dann müssen Sie die folgenden Fragen beantworten:

Welche Sicherheitszonen benötigen Sie?
Welches Schutzniveau möchten Sie für jede dieser Zonen anwenden?
Wird der interne Verkehr zwischen den Zonen standardmäßig erlaubt?
Falls nein, welche Filterrichtlinien für den Datenverkehr werden innerhalb jeder Zone angewendet?
Welche Filterrichtlinien für den Datenverkehr werden für jedes Paar von Zonen (Quelle/Ziel) angewendet?

TCAM

Häufig tritt das Problem eines unzureichenden TCAM (Ternary Content Addressable Memory) auf, sowohl bei der Routenfindung als auch beim Zugriff. IMHO ist dies eines der wichtigsten Kriterien bei der Auswahl von Hardware, weshalb diesem Thema die gebührende Aufmerksamkeit geschenkt werden sollte.

Beispiel 1. Weiterleitungstabelle TCAM.
Betrachten wir Palo Alto 7k Firewall.
Wir sehen, dass die Größe der IPv4-Weiterleitungstabelle* = 32K
Dieser Wert ist die Gesamtheit der Routen für alle VSYS.
Angenommen, dass Sie in Ihrer Architektur beschlossen haben, 4 VSYS zu verwenden.
Jedes dieser VSYS ist über BGP mit zwei PE des MPLS-Netzes verbunden, das Sie als BB verwenden. Somit tauschen 4 VSYS alle spezifischen Routen untereinander aus und haben eine Weiterleitungstabelle mit ungefähr denselben Routen-Sets (aber unterschiedlichen NH). Da jedes VSYS 2 BGP-Sitzungen (mit identischen Einstellungen) hat, hat jede Route, die über MPLS empfangen wird, 2 NH und somit 2 FIB-Einträge in der Weiterleitungstabelle. Wenn wir annehmen, dass dies die einzige Firewall im Rechenzentrum ist und sie über alle Routen informiert sein muss, bedeutet dies, dass die Gesamtzahl der Routen in unserem Rechenzentrum nicht mehr als 32K/(4 * 2) = 4K betragen kann.
Jetzt, wenn wir annehmen, dass wir 2 Rechenzentren (mit identischer Architektur) haben und VLANs verwenden möchten, die zwischen den Rechenzentren "ausgedehnt" sind (zum Beispiel für vMotion), dann müssen wir zur Lösung des Routingproblems Host-Routen verwenden. Das bedeutet jedoch, dass wir für die 2 Rechenzentren nicht mehr als 4096 mögliche Hosts haben können, was natürlich möglicherweise nicht ausreicht.

Beispiel 2. ACL TCAM.
Wenn Sie den Datenverkehr auf L3-Switches (oder anderen Lösungen, die L3-Switches verwenden, wie z.B. Cisco ACI) filtern möchten, sollten Sie bei der Auswahl der Hardware auf die ACL TCAM achten.
Angenommen, Sie möchten die Zugriffe an den SVI-Schnittstellen des Cisco Catalyst 4500 kontrollieren. Dann können Sie, wie zu sehen ist, dieses Artikels, zur Kontrolle des ausgehenden (sowie eingehenden) Datenverkehrs an den Schnittstellen nur 4096 Zeilen TCAM verwenden. Das gibt Ihnen bei Verwendung von TCAM3 etwa 4000 ACE (Zeilen ACL).

Falls Sie auf ein Problem mit unzureichendem TCAM stoßen, sollten Sie zunächst die Möglichkeit der Optimierung in Betracht ziehen. Bei einem Problem mit der Größe der Weiterleitungstabelle sollten Sie die Aggregation von Routen in Betracht ziehen. Wenn es ein Problem mit der TCAM-Größe für Zugriffe gibt, sollten Sie eine Zugriffsauditierung durchführen, veraltete und überlappende Einträge löschen und möglicherweise das Verfahren zur Eröffnung von Zugriffen überdenken (dies wird ausführlich im Kapitel zur Zugriffsauditierung behandelt).

Hohe Verfügbarkeit

Die Frage ist, ob man HA für Firewalls nutzen oder zwei unabhängige Geräte „parallel“ installieren und den Verkehr im Falle eines Ausfalls eines Geräts über das andere leiten sollte?

Offensichtlich wäre die Antwort – HA zu nutzen. Der Grund, warum diese Frage dennoch aufkommt, liegt darin, dass die theoretischen und beworbenen 99 und einige Dezimalstellen Prozent Verfügbarkeit in der Praxis leider oft nicht so rosig aussehen. HA ist ein logischerweise recht komplexes Thema, und auf unterschiedlichen Geräten und bei verschiedenen Anbietern (Ausnahmen gab es nicht) haben wir Probleme, Bugs und Ausfälle von Diensten festgestellt.

Wenn Sie HA verwenden, haben Sie die Möglichkeit, einzelne Knoten abzuschalten und ohne Unterbrechung des Dienstes zwischen ihnen zu wechseln, was wichtig ist, zum Beispiel bei Upgrades. Gleichzeitig besteht jedoch eine nicht unerhebliche Wahrscheinlichkeit, dass beide Knoten gleichzeitig ausfallen, ebenso wie die Möglichkeit, dass ein weiteres Upgrade nicht so reibungslos verläuft, wie vom Anbieter versprochen (dieses Problem kann vermieden werden, wenn Sie die Möglichkeit haben, das Upgrade auf Laborhardware zu testen).

Wenn Sie HA nicht verwenden, sind Ihre Risiken im Hinblick auf doppelte Ausfälle erheblich geringer (da Sie zwei unabhängige Firewalls haben), aber da die Sitzungen nicht synchronisiert sind, verlieren Sie jedes Mal, wenn ein Wechsel zwischen diesen Firewalls erfolgt, Traffic. Man könnte natürlich auch stateless Firewalling verwenden, aber dann wird der Sinn der Verwendung einer Firewall größtenteils verloren.

Wenn Sie während einer Auditierung isolierte Firewalls entdeckt haben und darüber nachdenken, die Zuverlässigkeit Ihres Netzwerks zu erhöhen, dann ist HA sicherlich eine der empfohlenen Lösungen. Sie müssen jedoch auch die Nachteile dieser Vorgehensweise berücksichtigen, und möglicherweise ist eine andere Lösung für Ihr Netzwerk besser geeignet.

Benutzerfreundlichkeit (Managability)

Im Grunde genommen geht es bei HA auch um die Verwaltbarkeit. Anstatt zwei Geräte separat zu konfigurieren und das Synchronisationsproblem der Konfigurationen zu lösen, verwalten Sie sie weitgehend so, als ob Sie ein einziges Gerät hätten.

Aber vielleicht haben Sie viele Rechenzentren und viele Firewalls, dann wird diese Frage auf eine neue Ebene gehoben. Es geht nicht nur um die Konfiguration, sondern auch um