Dieser Artikel ist der dritte in der Reihe "Wie Sie die Netzwerk-Infrastruktur unter Kontrolle bekommen". Den Inhalt aller Artikel der Reihe und die Links 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. Man muss auch verstehen, dass unsere Lösungen immer teurer werden, je mehr wir versuchen, das Netzwerk sicherer zu machen. Es ist notwendig, einen vernünftigen Kompromiss zwischen Preis, Komplexität und Sicherheit für Ihr Netzwerk zu finden.

Natürlich ist das Sicherheitsdesign organisch in die Gesamtarchitektur integriert, und die verwendeten Sicherheitslösungen wirken sich auf die Skalierbarkeit, Zuverlässigkeit, Verwaltbarkeit ... der Netzwerk-Infrastruktur aus, was ebenfalls berücksichtigt werden sollte.

Aber ich erinnere daran, dass wir jetzt nicht über den Aufbau eines Netzwerks sprechen. Entsprechend unseren ausgangsbedingungen haben wir bereits ein Design gewählt, die Hardware ausgewählt und die Infrastruktur erstellt, und sollten in dieser Phase, soweit möglich, "leben" und Lösungen im Kontext des zuvor gewählten Ansatzes finden.

Unsere Aufgabe besteht jetzt darin, Risiken im Zusammenhang mit der Netzwerk-Sicherheit zu identifizieren und sie auf ein vernünftiges Maß zu reduzieren.

Netzwerksicherheitsaudit

Wenn in Ihrer Organisation ISO 27k-Prozesse implementiert sind, sollten die Sicherheits- und Netzwerkänderungsprüfungen nahtlos in die allgemeinen Abläufe dieses Ansatzes integriert werden. Diese Standards beziehen sich jedoch nicht auf spezifische Lösungen, Konfigurationen oder Designs… Es gibt keine eindeutigen Ratschläge, keine Standards, die genau vorschreiben, wie Ihr Netzwerk aussehen sollte; das ist die Komplexität und Faszination dieser Aufgabe.

Ich würde mehrere mögliche Sicherheitsprüfungen des Netzwerks hervorheben:

Audit der Hardwarekonfiguration (Hardening)
Audit des Sicherheitsdesigns
Zugangsprüfung
Prozessprüfung

Audit der Hardwarekonfiguration (Hardening)

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

Der springende Punkt ist, dass wir normalerweise Empfehlungen von Anbietern zu den „besten Praktiken“ für die Sicherheitskonfiguration von Hardware erhalten. Dies wird als „Hardening“ bezeichnet.

Es ist auch häufig möglich, einen Fragebogen (oder selbst zu erstellen) basierend auf diesen Empfehlungen zu finden, der Ihnen hilft festzustellen, wie gut die Konfiguration Ihrer Hardware den „Best Practices“ entspricht und basierend auf den Ergebnissen Änderungen in Ihrem Netzwerk vorzunehmen. Dies ermöglicht es Ihnen, die Sicherheitsrisiken erheblich zu senken, relativ einfach und ohne Kosten.

Einige Beispiele für verschiedene Cisco-Betriebssysteme.
Härtung der Cisco IOS-Konfiguration
Härtung der Cisco IOS-XR-Konfiguration
Härtung der Cisco NX-OS-Konfiguration
Cisco Baseline Sicherheits-Checkliste
Basierend auf diesen Dokumenten kann eine Liste von Konfigurationsanforderungen für jede Art von Hardware erstellt werden. Beispielsweise könnten die Anforderungen für Cisco N7K VDC wie folgt aussehen: so.

Auf diese Weise können Konfigurationsdateien für verschiedene aktive Geräte Ihrer Netzwerk-Infrastruktur erstellt werden. Anschließend können Sie diese Konfigurationsdateien manuell oder mithilfe von Automatisierung „hochladen“. Wie dieser Prozess automatisiert werden kann, wird in einer anderen Artikelreihe zu Orchestrierung und Automatisierung ausführlich behandelt.

Audit des Sicherheitsdesigns

In einem Unternehmensnetzwerk sind typischerweise folgende Segmente vorhanden:

DC (DMZ für öffentliche Dienste und Intranet-Rechenzentrum)
Internetzugang
Remote Access VPN
WAN Edge
Zweigstelle
Campus (Büro)
Kern

Die Begriffe stammen aus Cisco SAFE Modell, doch es ist nicht zwingend notwendig, sich genau an diese Begriffe und dieses Modell zu halten. Es ist wichtiger, über das Wesentliche zu sprechen und sich nicht in Formalitäten zu verlieren.

Für jedes dieser Segmente variieren die Sicherheitsanforderungen, Risiken und somit auch die Lösungen.

Lassen Sie uns jedes einzelne Segment hinsichtlich der Herausforderungen betrachten, die Sie aus Sicht des Sicherheitsdesigns möglicherweise begegnen. Ich möchte betonen, dass dieser Artikel keineswegs den Anspruch auf Vollständigkeit erhebt; es ist nicht einfach (wenn überhaupt möglich), alle Aspekte dieses wirklich tiefgreifenden und vielschichtigen Themas zu erfassen, sondern reflektiert meine persönlichen Erfahrungen.

Es gibt keine perfekte Lösung (zumindest derzeit nicht). Es ist immer ein Kompromiss. Entscheidend ist, dass die Wahl eines bestimmten Ansatzes bewusst getroffen wird, mit einem Verständnis sowohl seiner Vor- als auch seiner Nachteile.

Rechenzentrum

Das aus Sicht der Sicherheit kritischste Segment.
Wie üblich gibt es auch hier keine universelle Lösung. Alles hängt stark von den Anforderungen an das Netzwerk ab.

Brauchen Sie eine Firewall oder nicht?

Auf den ersten Blick scheint die Antwort offensichtlich zu sein, aber es ist nicht so einfach, wie es scheint. Bei Ihrer Entscheidung könnten nicht nur Preis.

Beispiel 1. Latenzen.
Wenn zwischen bestimmten Segmenten des Netzwerks eine niedrige Latenz eine wesentliche Anforderung ist, wie zum Beispiel im Falle einer Börse, können wir zwischen diesen Segmenten keine Firewalls verwenden. Es ist schwierig, Studien zu Latenzen in Firewalls zu finden, aber nur wenige Switch-Modelle bieten Latenzen von weniger als oder etwa 1 µs, daher denke ich, dass, wenn Mikrosekunden für Sie entscheidend sind, Firewalls nichts für Sie sind.

Beispiel 2. Leistung.
Die Bandbreite der besten L3-Switches liegt in der Regel um ein Vielfaches höher als die Bandbreite der leistungsstärksten Firewalls. Daher werden Sie bei hochintensivem Traffic wahrscheinlich ebenfalls diesen Traffic an den Firewalls vorbeileiten müssen.

Beispiel 3. Zuverlässigkeit.
Firewalls, insbesondere moderne NGFW (Next-Generation Firewalls), sind komplexe Geräte. Sie sind deutlich anspruchsvoller als L3/L2-Switches. Aufgrund der Vielzahl an Diensten und Konfigurationsmöglichkeiten ist es nicht überraschend, dass ihre Zuverlässigkeit deutlich niedriger ist. Wenn die Kontinuität des Services für Ihr Netzwerk entscheidend ist, müssen Sie möglicherweise abwägen, was zu einer besseren Verfügbarkeit führt – der Schutz durch einen Firewall oder die Einfachheit eines Netzwerks, das auf Switches (oder ähnlichen Fabriken) mit herkömmlichen ACLs basiert.

In den oben genannten Beispielen werden Sie wahrscheinlich (wie gewohnt) einen Kompromiss finden müssen. Betrachten Sie die folgenden Lösungen:

Wenn Sie sich entschieden haben, keine Firewalls im Rechenzentrum zu verwenden, müssen Sie überlegen, wie Sie den Zugang an der Peripherie maximal einschränken. Beispielsweise können Sie nur die erforderlichen Ports aus dem Internet (für den Kundenverkehr) und Verwaltungszugänge zum Rechenzentrum nur von Jump-Hosts öffnen. Auf den Jump-Hosts sollten alle notwendigen Prüfungen (Authentifizierung/Autorisierung, Antivirus, Protokollierung, …) durchgeführt werden.
Sie können eine logische Unterteilung des Rechenzentrums in Segmente nutzen, ähnlich wie im PSEFABRIC-Schema beschrieben. Beispiel p002. Dabei sollte das Routing so konfiguriert sein, dass latenzempfindlicher oder intensiver Traffic "innerhalb" eines Segments (im Falle von p002, VRF) verläuft und nicht über die Firewall geht. Traffic zwischen verschiedenen Segmenten wird weiterhin über die Firewall geleitet. Sie können auch Route Leaking zwischen den VRFs verwenden, um eine Umleitung des Traffics über die Firewall zu vermeiden.
Ebenso kann die Firewall im transparenten Modus nur für VLANs eingesetzt werden, bei denen diese Faktoren (Latenz/Performance) keine wesentliche Rolle spielen. Allerdings sollten die Einschränkungen dieser Betriebsart für jeden Anbieter gründlich untersucht werden.
Sie können auch erwägen, eine Service-Chain-Architektur einzuführen. Dies würde es ermöglichen, nur den erforderlichen Traffic über die Firewall zu leiten. Theoretisch sieht es ansprechend aus, jedoch habe ich diese Lösung nie in der Praxis gesehen. Vor etwa drei Jahren haben wir Service-Chain für Cisco ACI/Juniper SRX/F5 LTM getestet, aber zu diesem Zeitpunkt erschien uns diese Lösung "unreif".

Schutzgrad

Nun müssen Sie sich die Frage stellen, welche Tools Sie für die Traffic-Filterung einsetzen möchten. Hier sind einige der Möglichkeiten, die typischerweise in einer NGFW vorhanden sind (zum Beispiel, hier):

stateful Firewalling (standardmäßig)
Anwendungsfirewalling
Bedrohungsprävention (Antivirus, Anti-Spyware und Schwachstellenmanagement)
URL-Filterung
Datenfilterung (Inhaltsfilterung)
Datei-Blockierung (Blockierung von Dateitypen)
DDoS-Schutz

Es ist auch nicht alles eindeutig. Auf den ersten Blick scheint es, je höher das Schutzniveau, desto besser. Aber Sie müssen auch bedenken, 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 Latenz erhöhen, siehe zum Beispiel hier
wie bei jeder komplexen Lösung kann der Einsatz komplexer Schutzmethoden die Zuverlässigkeit Ihrer Lösung beeinträchtigen, zum Beispiel habe ich bei der Verwendung von Application Firewalling erlebt, dass einige ganz normal funktionierende Anwendungen (DNS, SMB) blockiert wurden

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

Es gibt keine eindeutige Antwort auf die Frage, welche Schutzfunktionen erforderlich sein könnten. Erstens hängt dies natürlich von den Daten ab, die Sie übertragen oder speichern und zu schützen versuchen. Zweitens besteht die Herausforderung häufig darin, dass die Auswahl der Schutzmaßnahmen eine Frage des Vertrauens in den Anbieter ist. Sie kennen die Algorithmen nicht, wissen nicht, wie effektiv sie sind, und können sie nicht umfassend testen.

Für kritische Bereiche kann es daher sinnvoll sein, Lösungen von verschiedenen Anbietern zu nutzen. Beispielsweise können Sie einen Antivirus auf der Firewall aktivieren und gleichzeitig eine Antiviruslösung (von einem anderen Anbieter) lokal auf den Hosts einsetzen.

Segmentierung

Hier geht es um die logische Segmentierung des Rechenzentrumsnetzwerks. Die Aufteilung in VLANs und Subnetze ist ebenfalls eine logische Segmentierung, die wir jedoch aufgrund ihrer Offensichtlichkeit nicht im Detail betrachten werden. Interessant ist die Segmentierung unter Berücksichtigung von Entitäten wie FW-Sicherheitszonen, VRF (und ihren Äquivalenten bei verschiedenen Anbietern), logischen Geräten (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Ein Beispiel für eine solche logische Segmentierung und das derzeit gefragte Design eines Rechenzentrums findet sich in p002 des Projekts PSEFABRIC.

Nachdem Sie die logischen Teile Ihres Netzwerks definiert haben, können Sie beschreiben, wie der Datenverkehr zwischen den verschiedenen Segmenten fließt, auf welchen Geräten die Filterung erfolgt und welche Mittel dabei eingesetzt werden.

Falls in Ihrem Netzwerk keine klare logische Aufteilung existiert und die Sicherheitsrichtlinien für verschiedene Datenströme (Flow) nicht formalisiert sind, bedeutet dies, dass Sie bei der Gewährung von Zugriffen jedes Mal neu entscheiden müssen, und es ist sehr wahrscheinlich, dass Sie dies jedes Mal anders tun werden.

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

Welche Sicherheitszonen benötigen Sie?
Welches Sicherheitsniveau möchten Sie für jede dieser Zonen anwenden?
Wird der intra-Zonen-Datenverkehr standardmäßig erlaubt?
Wenn nicht, welche Filterrichtlinien werden innerhalb jeder Zone angewendet?
Welche Filterrichtlinien werden für jedes Paar von Zonen (Quelle/Ziel) angewendet?

TCAM

Ein häufig auftretendes Problem ist der Mangel an TCAM (Ternary Content Addressable Memory), sowohl für das Routing als auch für Zugriffe. Meiner Meinung nach ist dies eine der wichtigsten Überlegungen bei der Auswahl der Hardware, weshalb diesem Thema die gebührende Beachtung geschenkt werden sollte.

Beispiel 1. Forwarding-Tabelle TCAM.
Schauen wir uns das genauer an Palo Alto 7k Firewall.
Wir sehen, dass die Größe der IPv4-Forwarding-Tabelle* = 32K
Dieses Routing ist dabei insgesamt für alle VSYSs.
Angenommen, laut Ihrem Design haben Sie beschlossen, 4 VSYS zu verwenden.
Jeder dieser VSYSs ist über BGP mit zwei PE des MPLS-Netzwerks verbunden, das Sie als BB nutzen. So tauschen 4 VSYSs ihre spezifischen Routen untereinander aus und haben Forwarding-Tabellen mit annähernd identischen Routen-Sets (aber unterschiedlichen NH). Da jeder VSYS 2 BGP-Sitzungen (mit identischen Einstellungen) hat, hat jede Route, die über MPLS erhalten wird, 2 NH und somit 2 FIB-Einträge in der Forwarding-Tabelle. Angenommen, dies ist die einzige Firewall im Rechenzentrum und sie muss über alle Routen informiert sein, dann bedeutet dies, dass die Gesamtzahl der Routen in unserem Rechenzentrum nicht mehr als 32K/(4 * 2) = 4K betragen kann.
Angenommen, wir haben 2 Rechenzentren (mit identischem Design) und möchten VLANs verwenden, die zwischen diesen Rechenzentren „erweitert“ sind (zum Beispiel für vMotion). Um das Routing-Problem zu lösen, müssen wir Host-Routen verwenden. Das bedeutet jedoch, dass wir in den 2 Rechenzentren nicht mehr als 4096 mögliche Hosts haben können, was möglicherweise nicht ausreicht.

Beispiel 2. ACL TCAM.
Wenn Sie Traffic auf L3-Switches (oder anderen Lösungen, die L3-Switches verwenden, wie z.B. Cisco ACI) filtern möchten, sollten Sie beim Kauf der Hardware auf ACL TCAM achten.
Angenommen, Sie möchten den Zugriff auf SVI-Schnittstellen von Cisco Catalyst 4500 kontrollieren. Dann, wie aus dieses Artikelszu erkennen ist, können Sie zur Kontrolle des ausgehenden (sowie eingehenden) Traffics an den Schnittstellen nur 4096 TCAM-Zeilen verwenden. Bei Verwendung von TCAM3 erhalten Sie damit etwa 4000 ACE (ACL-Zeilen).

Wenn Sie auf ein Problem mit unzureichendem TCAM stoßen, sollten Sie zunächst eine Optimierung in Betracht ziehen. Bei Problemen mit der Größe der Forwarding Table könnte zum Beispiel die Aggregation von Routen sinnvoll sein. Bei Problemen mit der TCAM-Größe für Zugriffe sollten Sie eine Überprüfung der Zugriffsrechte in Erwägung ziehen, veraltete und überschneidende Einträge entfernen und möglicherweise das Verfahren zur Erteilung von Zugriffsrechten überdenken (dies wird ausführlich im Kapitel über die Überprüfung der Zugriffsrechte behandelt).

Hochverfügbarkeit

Die Frage ist, ob man HA für Firewalls verwenden oder zwei unabhängige Geräte parallel installieren und den Verkehr im Falle eines Ausfalls der einen über die andere leiten sollte?

Die Antwort scheint offensichtlich – HA zu verwenden. Der Grund, warum diese Frage dennoch aufkommt, ist, dass, bedauerlicherweise, die theoretischen und reklamemäßigen Verfügbarkeitswerte von 99 und mehreren Neunen nach dem Komma in der Praxis oft nicht so erfreulich sind. HA ist logischerweise ein recht komplexes Thema, und bei verschiedenen Geräten und Anbietern (keine Ausnahme) haben wir Probleme, Bugs und Serviceausfälle erlebt.

Wenn Sie HA verwenden, haben Sie die Möglichkeit, einzelne Knoten auszuschalten und ohne Unterbrechung des Dienstes zwischen ihnen zu wechseln. Dies ist besonders wichtig bei Upgrades. Allerdings besteht auch eine nicht unerhebliche Wahrscheinlichkeit, dass beide Knoten gleichzeitig ausfallen und dass das nächste Upgrade nicht so reibungslos verläuft, wie es der Anbieter verspricht. Dieses Problem kann vermieden werden, wenn Sie die Möglichkeit haben, das Upgrade auf Testhardware zu testen.

Wenn Sie kein HA verwenden, sind Ihre Risiken in Bezug auf doppelte Ausfälle deutlich geringer, da Sie zwei unabhängige Firewalls haben. Da jedoch die Sitzungen nicht synchronisiert sind, verlieren Sie jedes Mal, wenn zwischen diesen Firewalls gewechselt wird, Verkehr. Natürlich kann man stateless Firewalls nutzen, aber dann wird der Nutzen einer Firewall in vielerlei Hinsicht stark reduziert.

Wenn Sie also bei der Überprüfung feststellen, dass Sie isolierte Firewalls haben und darüber nachdenken, die Zuverlässigkeit Ihres Netzwerks zu erhöhen, dann ist Hochverfügbarkeit (HA) sicherlich eine der empfohlenen Lösungen. Allerdings sollten Sie auch die Nachteile, die mit diesem Ansatz verbunden sind, in Betracht ziehen. Möglicherweise ist eine andere Lösung besser geeignet für Ihr Netzwerk.

Verwaltbarkeit

Im Grunde genommen geht es bei HA auch um die Verwalbarkeit. Anstatt zwei Geräte separat zu konfigurieren und das Problem der Synchronisierung der Konfigurationen zu lösen, verwalten Sie sie größtenteils, als hätten Sie ein einziges Gerät.

Aber möglicherweise haben Sie viele Rechenzentren und zahlreiche Firewalls. In diesem Fall wird die Frage auf einem neuen Niveau gestellt. Es geht nicht nur um die Konfiguration, sondern auch um