So übernehmen Sie die Kontrolle über Ihre Netzwerkinfrastruktur. Kapitel drei. Netzwerksicherheit. Teil eins

Dieser Artikel ist der dritte in der Artikelreihe „So übernehmen Sie die Kontrolle über Ihre Netzwerkinfrastruktur“. Den Inhalt aller Artikel der Reihe und Links finden Sie hier hier.

So übernehmen Sie die Kontrolle über Ihre Netzwerkinfrastruktur. Kapitel drei. Netzwerksicherheit. Teil eins

Es hat keinen Sinn, über die vollständige Eliminierung von Sicherheitsrisiken zu sprechen. Im Prinzip können wir sie nicht auf Null reduzieren. Wir müssen uns auch darüber im Klaren sein, dass unsere Lösungen immer teurer werden, je mehr wir danach streben, das Netzwerk immer sicherer zu machen. Sie müssen einen Kompromiss zwischen Kosten, Komplexität und Sicherheit finden, der für Ihr Netzwerk sinnvoll ist.

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

Aber ich möchte Sie daran erinnern, dass wir jetzt nicht über die Schaffung eines Netzwerks sprechen. Nach unserem Anfangsbedingungen Wir haben bereits das Design ausgewählt, die Ausrüstung ausgewählt und die Infrastruktur geschaffen, und in dieser Phase sollten wir, wenn möglich, im Kontext des zuvor gewählten Ansatzes „leben“ und Lösungen finden.

Unsere Aufgabe besteht nun darin, die mit der Sicherheit auf Netzwerkebene verbundenen Risiken zu identifizieren und auf ein vertretbares Maß zu reduzieren.

Netzwerksicherheitsaudit

Wenn Ihr Unternehmen ISO 27k-Prozesse implementiert hat, sollten sich Sicherheitsaudits und Netzwerkänderungen nahtlos in die Gesamtprozesse dieses Ansatzes einfügen. Aber bei diesen Standards geht es immer noch nicht um spezifische Lösungen, nicht um Konfiguration, nicht um Design ... Es gibt keine klaren Ratschläge, keine Standards, die im Detail vorschreiben, wie Ihr Netzwerk aussehen soll, das ist die Komplexität und Schönheit dieser Aufgabe.

Ich möchte mehrere mögliche Netzwerksicherheitsaudits hervorheben:

  • Gerätekonfigurationsaudit (Härtung)
  • Sicherheitsdesign-Audit
  • Zugriffsprüfung
  • Prozess-Audit

Prüfung der Gerätekonfiguration (Härtung)

Es scheint, dass dies in den meisten Fällen der beste Ausgangspunkt für die Prüfung und Verbesserung der Sicherheit Ihres Netzwerks ist. Meiner Meinung nach ist dies eine gute Demonstration des Pareto-Gesetzes (20 % des Aufwands erzeugen 80 % des Ergebnisses, und die restlichen 80 % des Aufwands erzeugen nur 20 % des Ergebnisses).

Unterm Strich haben wir in der Regel Empfehlungen von Anbietern zu „Best Practices“ für die Sicherheit bei der Konfiguration von Geräten. Dies wird als „Verfestigung“ bezeichnet.

Auf der Grundlage dieser Empfehlungen können Sie häufig auch einen Fragebogen finden (oder selbst einen erstellen), der Ihnen dabei hilft, festzustellen, wie gut die Konfiguration Ihrer Geräte diesen „Best Practices“ entspricht, und anhand des Ergebnisses Änderungen in Ihrem Netzwerk vorzunehmen . Dadurch können Sie Sicherheitsrisiken ganz einfach und nahezu kostenlos deutlich reduzieren.

Mehrere Beispiele für einige Cisco-Betriebssysteme.

Härtung der Cisco IOS-Konfiguration
Härtung der Cisco IOS-XR-Konfiguration
Härtung der Cisco NX-OS-Konfiguration
Cisco Baseline Security Checkliste

Basierend auf diesen Dokumenten kann eine Liste der Konfigurationsanforderungen für jeden Gerätetyp erstellt werden. Für ein Cisco N7K VDC könnten diese Anforderungen beispielsweise so aussehen so.

Auf diese Weise können Konfigurationsdateien für verschiedene Arten aktiver Geräte in Ihrer Netzwerkinfrastruktur erstellt werden. Anschließend können Sie diese Konfigurationsdateien manuell oder mithilfe der Automatisierung „hochladen“. Wie dieser Prozess automatisiert werden kann, wird in einer weiteren Artikelreihe zum Thema Orchestrierung und Automatisierung ausführlich besprochen.

Prüfung des Sicherheitsdesigns

Typischerweise enthält ein Unternehmensnetzwerk die folgenden Segmente in der einen oder anderen Form:

  • DC (DMZ für öffentliche Dienste und Intranet-Rechenzentrum)
  • Internetzugang
  • RAS-VPN
  • WAN-Kante
  • Filiale
  • Campus (Büro)
  • Kernbereich

Titel entnommen aus Cisco SAFE Modell, aber es ist natürlich nicht notwendig, sich genau an diese Namen und an dieses Modell zu binden. Dennoch möchte ich über das Wesentliche sprechen und mich nicht in Formalitäten verzetteln.

Für jedes dieser Segmente werden die Sicherheitsanforderungen, Risiken und dementsprechend die Lösungen unterschiedlich sein.

Schauen wir uns jedes davon einzeln an, um die Probleme zu erkennen, auf die Sie aus Sicht des Sicherheitsdesigns stoßen können. Natürlich wiederhole ich noch einmal, dass dieser Artikel in keiner Weise Anspruch auf Vollständigkeit erhebt, was bei diesem wirklich tiefgreifenden und vielschichtigen Thema nicht einfach (wenn nicht unmöglich) zu erreichen ist, aber er spiegelt meine persönlichen Erfahrungen wider.

Es gibt keine perfekte Lösung (zumindest noch nicht). Es ist immer ein Kompromiss. Es ist jedoch wichtig, dass die Entscheidung für den einen oder anderen Ansatz bewusst getroffen wird und sowohl die Vor- als auch die Nachteile bekannt sind.

Data Center

Aus Sicherheitsgründen das kritischste Segment.
Und wie immer gibt es auch hier keine universelle Lösung. Es hängt alles stark von den Netzwerkanforderungen ab.

Ist eine Firewall notwendig oder nicht?

Es scheint, dass die Antwort offensichtlich ist, aber nicht alles ist so klar, wie es scheint. Und Ihre Wahl kann nicht nur beeinflusst werden Preis.

Beispiel 1. Verzögerungen.

Wenn eine geringe Latenz zwischen einigen Netzwerksegmenten eine wesentliche Anforderung ist, was beispielsweise bei einem Austausch der Fall ist, können wir zwischen diesen Segmenten keine Firewalls verwenden. Es ist schwer, Studien zur Latenz in Firewalls zu finden, aber nur wenige Switch-Modelle können eine Latenz von weniger als oder in der Größenordnung von 1 mksec bieten. Ich denke also, wenn Ihnen Mikrosekunden wichtig sind, dann sind Firewalls nichts für Sie.

Beispiel 2. Leistung.

Der Durchsatz der besten L3-Switches ist normalerweise um eine Größenordnung höher als der Durchsatz der leistungsstärksten Firewalls. Daher müssen Sie bei hochintensivem Datenverkehr höchstwahrscheinlich auch zulassen, dass dieser Datenverkehr Firewalls umgeht.

Beispiel 3. Zuverlässigkeit.

Firewalls, insbesondere moderne NGFW (Next-Generation FW), sind komplexe Geräte. Sie sind viel komplexer als L3/L2-Switches. Sie bieten eine große Anzahl an Diensten und Konfigurationsmöglichkeiten, daher ist es nicht verwunderlich, dass ihre Zuverlässigkeit deutlich geringer ist. Wenn die Dienstkontinuität für das Netzwerk von entscheidender Bedeutung ist, müssen Sie möglicherweise entscheiden, was zu einer besseren Verfügbarkeit führt – Sicherheit mit einer Firewall oder die Einfachheit eines Netzwerks, das auf Switches (oder verschiedenen Arten von Fabrics) mit regulären ACLs basiert.

Bei den oben genannten Beispielen müssen Sie höchstwahrscheinlich (wie üblich) einen Kompromiss finden. Suchen Sie nach folgenden Lösungen:

  • Wenn Sie sich dafür entscheiden, keine Firewalls innerhalb des Rechenzentrums zu verwenden, müssen Sie darüber nachdenken, wie Sie den Zugriff rund um den Perimeter so weit wie möglich einschränken können. Sie können beispielsweise nur die erforderlichen Ports aus dem Internet öffnen (für Client-Datenverkehr) und den administrativen Zugriff auf das Rechenzentrum nur über Jump-Hosts ermöglichen. Führen Sie auf Jump-Hosts alle erforderlichen Prüfungen durch (Authentifizierung/Autorisierung, Antivirus, Protokollierung usw.)
  • Sie können eine logische Aufteilung des Rechenzentrumsnetzwerks in Segmente verwenden, ähnlich dem in PSEFABRIC beschriebenen Schema Beispiel p002. In diesem Fall muss das Routing so konfiguriert werden, dass verzögerungsempfindlicher oder hochintensiver Verkehr „innerhalb“ eines Segments (im Fall von p002, VRF) verläuft und nicht durch die Firewall geht. Der Datenverkehr zwischen verschiedenen Segmenten wird weiterhin durch die Firewall geleitet. Sie können auch Routenlecks zwischen VRFs verwenden, um die Umleitung des Datenverkehrs durch die Firewall zu vermeiden
  • Sie können eine Firewall auch im transparenten Modus verwenden und nur für diejenigen VLANs, bei denen diese Faktoren (Latenz/Leistung) keine Rolle spielen. Sie müssen jedoch die Einschränkungen, die mit der Verwendung dieses Mods für jeden Anbieter verbunden sind, sorgfältig studieren
  • Möglicherweise möchten Sie die Verwendung einer Service-Chain-Architektur in Betracht ziehen. Dadurch wird nur der erforderliche Datenverkehr durch die Firewall geleitet. Sieht in der Theorie gut aus, aber ich habe diese Lösung noch nie in der Produktion gesehen. Wir haben die Servicekette für Cisco ACI/Juniper SRX/F5 LTM vor etwa 3 Jahren getestet, aber damals kam uns diese Lösung „roh“ vor.

Schutzstufe

Jetzt müssen Sie die Frage beantworten, welche Tools Sie zum Filtern des Datenverkehrs verwenden möchten. Hier sind einige der Funktionen, die normalerweise in NGFW vorhanden sind (z. B. hier):

  • Stateful Firewalling (Standard)
  • Anwendungs-Firewalling
  • Bedrohungsprävention (Antivirus, Anti-Spyware und Schwachstellen)
  • URL-Filterung
  • Datenfilterung (Inhaltsfilterung)
  • Dateiblockierung (Blockierung von Dateitypen)
  • DOS-Schutz

Und es ist auch nicht alles klar. Es scheint, dass je höher das Schutzniveau, desto besser. Aber auch das muss man bedenken

  • Je mehr der oben genannten Firewall-Funktionen Sie nutzen, desto teurer wird es natürlich (Lizenzen, Zusatzmodule)
  • Der Einsatz einiger Algorithmen kann den Firewall-Durchsatz erheblich reduzieren und auch Verzögerungen erhöhen, siehe z. B hier
  • Wie bei jeder komplexen Lösung kann der Einsatz komplexer Schutzmethoden die Zuverlässigkeit Ihrer Lösung beeinträchtigen. Bei der Verwendung von Anwendungs-Firewalls bin ich beispielsweise auf die Blockierung einiger ganz normal funktionierender Anwendungen (DNS, SMB) gestoßen.

Wie immer müssen Sie die beste Lösung für Ihr Netzwerk finden.

Die Frage, welche Schutzfunktionen gegebenenfalls erforderlich sind, lässt sich nicht abschließend beantworten. Erstens, weil es natürlich von den Daten abhängt, die Sie übertragen oder speichern und schützen möchten. Zweitens ist die Wahl der Sicherheitstools in der Realität oft eine Frage des Vertrauens in den Anbieter. Sie kennen die Algorithmen nicht, Sie wissen nicht, wie effektiv sie sind, und Sie können sie nicht vollständig testen.

Daher kann es in kritischen Segmenten eine gute Lösung sein, Angebote verschiedener Unternehmen zu nutzen. Sie können beispielsweise Antivirus auf der Firewall aktivieren, aber auch einen Antivirenschutz (von einem anderen Hersteller) lokal auf den Hosts verwenden.

Segmentierung

Wir sprechen über die logische Segmentierung des Rechenzentrumsnetzwerks. Beispielsweise ist die Aufteilung in VLANs und Subnetze ebenfalls eine logische Segmentierung, wir werden sie jedoch aufgrund ihrer Offensichtlichkeit nicht berücksichtigen. Interessante Segmentierung unter Berücksichtigung von Einheiten wie FW-Sicherheitszonen, VRFs (und ihren Analoga in Bezug auf verschiedene Anbieter), logischen Geräten (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Ein Beispiel für eine solche logische Segmentierung und das derzeit gefragte Rechenzentrumsdesign finden Sie in p002 des PSEFABRIC-Projekts.

Nachdem Sie die logischen Teile Ihres Netzwerks definiert haben, können Sie beschreiben, wie sich der Datenverkehr zwischen verschiedenen Segmenten bewegt, auf welchen Geräten die Filterung durchgeführt wird und mit welchen Mitteln.

Если в вашей сети отсутствует ясное логическое разбиение и не формализованы правила применения security политик для разных потоков данных (flow), то это значит, что при открытии того или иного доступа вы вынуждены решать эту задачу, и с большой вероятностью каждый раз вы будете решать ее unterschiedlich.

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

  • Welche Sicherheitszonen benötigen Sie?
  • Welches Schutzniveau möchten Sie für jede dieser Zonen anwenden?
  • Wird zoneninterner Verkehr standardmäßig zugelassen?
  • Wenn nicht, welche Verkehrsfilterungsrichtlinien werden in den einzelnen Zonen angewendet?
  • Welche Verkehrsfilterungsrichtlinien werden für jedes Zonenpaar (Quelle/Ziel) angewendet?

TCAM

Ein häufiges Problem ist unzureichender TCAM (Ternary Content Addressable Memory), sowohl für das Routing als auch für Zugriffe. Meiner Meinung nach ist dies eines der wichtigsten Probleme bei der Auswahl der Ausrüstung, daher müssen Sie dieses Problem mit der entsprechenden Sorgfalt behandeln.

Beispiel 1. Weiterleitungstabelle TCAM.

Betrachten wir Palo Alto 7k Firewall
Wir sehen, dass die Größe der IPv4-Weiterleitungstabelle* = 32 KB ist
Darüber hinaus ist diese Anzahl von Routen für alle VSYSs gleich.

Nehmen wir an, dass Sie sich gemäß Ihrem Design für die Verwendung von 4 VSYS entscheiden.
Jedes dieser VSYSs ist über BGP mit zwei MPLS PEs der Cloud verbunden, die Sie als BB nutzen. Somit tauschen 4 VSYS alle spezifischen Routen untereinander aus und verfügen über eine Weiterleitungstabelle mit annähernd gleichen Routensätzen (aber unterschiedlichen NHs). Weil Jedes VSYS hat 2 BGP-Sitzungen (mit den gleichen Einstellungen), dann hat jede über MPLS empfangene Route 2 NH- und dementsprechend 2 FIB-Einträge in der Weiterleitungstabelle. Wenn wir davon ausgehen, dass dies die einzige Firewall im Rechenzentrum ist und alle Routen kennen muss, bedeutet dies, dass die Gesamtzahl der Routen in unserem Rechenzentrum nicht mehr als 32 KB/(4 * 2) = 4 KB betragen darf.

Wenn wir nun davon ausgehen, dass wir zwei Rechenzentren haben (mit demselben Design) und VLANs verwenden möchten, die zwischen Rechenzentren „ausgedehnt“ sind (z. B. für vMotion), müssen wir zur Lösung des Routing-Problems Host-Routen verwenden . Dies bedeutet jedoch, dass wir für zwei Rechenzentren nicht mehr als 2 mögliche Hosts haben, 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, z. B. Cisco ACI) filtern möchten, sollten Sie bei der Auswahl der Geräte auf die TCAM-ACL achten.

Angenommen, Sie möchten den Zugriff auf die SVI-Schnittstellen des Cisco Catalyst 4500 steuern. Dann, wie aus ersichtlich ist dieser ArtikelUm den ausgehenden (sowie eingehenden) Datenverkehr auf Schnittstellen zu steuern, können Sie nur 4096 TCAM-Leitungen verwenden. Wenn Sie TCAM3 verwenden, erhalten Sie etwa 4000 ACEs (ACL-Linien).

Wenn Sie mit dem Problem einer unzureichenden TCAM konfrontiert sind, müssen Sie natürlich zunächst die Möglichkeit einer Optimierung in Betracht ziehen. Wenn also ein Problem mit der Größe der Weiterleitungstabelle auftritt, müssen Sie die Möglichkeit in Betracht ziehen, Routen zu aggregieren. Im Falle eines Problems mit der TCAM-Größe für Zugriffe prüfen Sie Zugriffe, entfernen Sie veraltete und überlappende Datensätze und überarbeiten Sie möglicherweise das Verfahren zum Öffnen von Zugriffen (wird im Kapitel über die Überwachung von Zugriffen ausführlich besprochen).

Hochverfügbarkeit

Die Frage ist: Soll ich HA für Firewalls verwenden oder zwei unabhängige Boxen „parallel“ installieren und, wenn eine davon ausfällt, den Datenverkehr über die zweite leiten?

Es scheint, dass die Antwort offensichtlich ist: Verwenden Sie HA. Der Grund, warum diese Frage immer noch aufkommt, ist, dass die theoretischen und werblichen 99 und mehrere Dezimalprozente der Zugänglichkeit in der Praxis leider alles andere als so rosig ausfallen. HA ist logischerweise eine ziemlich komplexe Sache, und auf verschiedenen Geräten und bei verschiedenen Anbietern (es gab keine Ausnahmen) sind uns Probleme, Fehler und Servicestopps aufgefallen.

Wenn Sie HA verwenden, haben Sie die Möglichkeit, einzelne Knoten auszuschalten und zwischen ihnen zu wechseln, ohne den Dienst zu stoppen, was beispielsweise bei Upgrades wichtig ist wird gleichzeitig kaputt gehen, und auch, dass das nächste Upgrade nicht so reibungslos verläuft, wie der Hersteller verspricht (dieses Problem kann vermieden werden, wenn Sie die Möglichkeit haben, das Upgrade auf Laborgeräten zu testen).

Wenn Sie HA nicht verwenden, sind Ihre Risiken im Hinblick auf einen Doppelausfall viel geringer (da Sie über zwei unabhängige Firewalls verfügen), aber da... Wenn Sitzungen nicht synchronisiert sind, geht jedes Mal, wenn Sie zwischen diesen Firewalls wechseln, Datenverkehr verloren. Sie können natürlich eine zustandslose Firewall verwenden, aber dann geht der Sinn der Verwendung einer Firewall weitgehend verloren.

Wenn Sie also als Ergebnis der Prüfung einsame Firewalls entdeckt haben und darüber nachdenken, die Zuverlässigkeit Ihres Netzwerks zu erhöhen, dann ist HA natürlich eine der empfohlenen Lösungen, aber Sie sollten auch die damit verbundenen Nachteile berücksichtigen Bei diesem Ansatz und möglicherweise speziell für Ihr Netzwerk wäre eine andere Lösung besser geeignet.

Verwaltbarkeit

Im Prinzip geht es bei HA auch um Kontrollierbarkeit. Anstatt zwei Boxen separat zu konfigurieren und sich mit dem Problem zu befassen, die Konfigurationen synchron zu halten, verwalten Sie sie so, als ob Sie ein einziges Gerät hätten.

Aber vielleicht haben Sie viele Rechenzentren und viele Firewalls, dann stellt sich diese Frage auf einer neuen Ebene. Und bei der Frage geht es nicht nur um die Konfiguration, sondern auch um

  • Backup-Konfigurationen
  • Aktualisierung
  • Upgrades
  • Überwachung
  • Protokollierung

Und all dies kann durch zentralisierte Managementsysteme gelöst werden.

Wenn Sie beispielsweise Palo Alto-Firewalls verwenden, dann Panorama ist so eine Lösung.

To be continued.

Source: habr.com

Kommentar hinzufügen