Dieser Artikel ist der vierte in einer Reihe von Artikeln mit dem Titel „Wie man die Netzwerkinfrastruktur unter Kontrolle bringt“. Den Inhalt aller Artikel und die Links finden Sie hier.

Im ersten Teils in diesem Kapitel haben wir einige Aspekte der Netzwerksicherheit im Segment „Rechenzentrum“ betrachtet. Dieser Teil wird dem Segment „Internetzugang“ gewidmet sein.

Internetzugang

Das Thema Sicherheit ist zweifellos eines der komplexesten Themen in der Welt der Datenübertragungsnetze. Wie in den vorherigen Fällen werde ich hier, ohne Anspruch auf Tiefe und Vollständigkeit, einige relativ einfache, aber meiner Ansicht nach wichtige Fragen betrachten, deren Antworten hoffentlich dazu beitragen, die Sicherheit Ihres Netzwerks zu erhöhen.

Bei der Prüfung dieses Segments sollten Sie auf folgende Aspekte achten:

Design
BGP-Konfigurationen
DOS/DDOS-Schutz
Traffic-Filtern auf der Firewall

Design

Als Beispiel für das Design dieses Segments für Unternehmensnetzwerke würde ich empfehlen Anleitung von Cisco im Rahmen der SAFE-Modelle.

Natürlich kann es sein, dass die Lösungen anderer Anbieter für Sie attraktiver erscheinen (siehe Gartner-Quadrant für 2018), aber ohne Sie dazu aufzurufen, diesem Design im Detail zu folgen, halte ich es dennoch für hilfreich, die Prinzipien und Ideen, die ihm zugrunde liegen, zu verstehen.

Hinweis
Im SAFE-Segment „Remote Access“ ist Teil des „Internet Access“. Aber in dieser Artikelreihe werden wir ihn getrennt betrachten.

Die Standardausstattung in diesem Segment für Unternehmensnetzwerke sind

Gateway-Router
Firewalls

Hinweis 1
In dieser Artikelreihe meine ich, wenn ich von Firewalls spreche, NGFW.

Hinweis 2
Ich lasse verschiedene Arten von L2/L1 oder Overlay L2 über L3-Lösungen, die für die Gewährleistung der L1/L2-Konnektivität erforderlich sind, und beschränke mich nur auf Fragen der Ebene L3 und höher. Teilweise wurden L1/L2-Themen im Kapitel „Bereinigung und Dokumentation«.

Wenn Sie in diesem Segment keine Firewall gefunden haben, sollten Sie nicht vorschnell zu Schlussfolgerungen kommen.

Lassen Sie uns, wie in vorherigen Teil, die Frage beginnen, ob die Verwendung einer Firewall in diesem Segment in Ihrem Fall notwendig ist.

Ich kann sagen, dass dies der sinnvollste Ort für den Einsatz von Firewalls und komplexen Traffic-Filtersystemen zu sein scheint. In Teil 1 haben wir 4 Faktoren erwähnt, die der Nutzung von Firewalls im Rechenzentrumssegment entgegenstehen können. Aber hier sind sie nicht mehr so entscheidend.

Beispiel 1. Latenz
Wenn es um das Internet geht, macht es keinen Sinn, über Latenzen von sogar nur 1 Millisekunde zu sprechen. Daher kann die Latenz in diesem Segment kein Faktor sein, der die Nutzung der Firewall einschränkt.

Beispiel 2. Leistung
In einigen Fällen kann dieser Faktor dennoch erheblich sein. Daher müssen Sie möglicherweise einen Teil des Datenverkehrs (zum Beispiel den Datenverkehr von Lastenausgleichern) an der Firewall vorbeileiten.

Beispiel 3. Zuverlässigkeit
Dieser Faktor muss weiterhin berücksichtigt werden, doch angesichts der Unzuverlässigkeit des Internets ist seine Bedeutung für dieses Segment nicht so entscheidend wie für das Rechenzentrum.
Angenommen, Ihr Service läuft über http/https (mit kurzen Sitzungen). In diesem Fall können Sie zwei unabhängige Boxen (ohne HA) verwenden und bei Problemen mit einer von ihnen den gesamten Verkehr auf die andere umleiten.
Oder Sie können Firewalls im transparenten Modus verwenden und bei Ausfall dieser während der Problemlösung den Verkehr an den Firewalls vorbeileiten.

Daher ist es möglicherweise genau nur der Preis der Faktor, der Sie dazu bringt, auf die Verwendung von Firewalls in diesem Segment zu verzichten.

Wichtig!
Es besteht die Versuchung, diese Firewall mit der Firewall des Rechenzentrums zu kombinieren (eine Firewall für diese Segmente zu verwenden). Eine solche Lösung ist grundsätzlich möglich, aber dabei müssen Sie verstehen, dass die "Internet Access"-Firewall tatsächlich an der Frontlinie Ihrer Verteidigung steht und zumindest einen Teil des schädlichen Datenverkehrs "aufnimmt". Daher müssen Sie das erhöhte Risiko berücksichtigen, dass diese Firewall außer Gefecht gesetzt wird. Das heißt, wenn Sie dieselben Geräte in diesen beiden Segmenten verwenden, senken Sie erheblich die Verfügbarkeit Ihres Rechenzentrumssegments.

Wie gewohnt ist es wichtig zu verstehen, dass das Design dieses Segments je nach Service, den das Unternehmen anbietet, stark variieren kann. Wie gewohnt können Sie je nach Anforderungen unterschiedliche Ansätze wählen.

Beispiel
Wenn Sie ein Content-Anbieter mit einem CDN-Netzwerk sind (siehe z. B. eine Reihe von Artikeln), möchten Sie möglicherweise nicht in Dutzenden oder sogar Hunderte von Präsenzpunkten der Infrastruktur separate Geräte für die Routing- und Filterung des Verkehrs erstellen. Das wäre teuer und könnte einfach überflüssig sein.
Für BGP benötigen Sie keine dedizierten Router; Sie können Open-Source-Tools wie verwenden, Quagga. Daher könnte alles, was Sie brauchen, ein Server oder mehrere Server, ein Switch und BGP sein.
In diesem Fall können Ihr Server oder mehrere Server nicht nur als CDN-Server, sondern auch als Router fungieren. Natürlich gibt es hier viele Details (zum Beispiel, wie man Lastverteilung sicherstellt), aber das ist umsetzbar, und diesen Ansatz haben wir erfolgreich für einen unserer Partner angewendet.
Sie können mehrere Rechenzentren mit vollem Schutz haben (Firewalls, DDoS-Schutzdienste, die von Ihren Internetanbietern bereitgestellt werden) und Dutzende oder Hunderte von „vereinfachten“ Präsenzpunkten nur mit L2-Switches und Servern.
Wie steht es in diesem Fall um den Schutz?
Lassen Sie uns zum Beispiel einen in letzter Zeit beliebten DNS-Amplification-DDoS-Angriffbetrachten. Seine Gefahr besteht darin, dass eine große Menge an Datenverkehr erzeugt wird, die einfach Ihre gesamten Uplinks zu 100 % „verstopft“.
Was haben wir in unserem Design?

Wenn Sie AnyCast verwenden, wird der Datenverkehr zwischen Ihren Präsenzpunkten verteilt. Wenn Ihre Gesamtdatenrate Terabits beträgt, schützt Sie das im Grunde genommen (es gab in letzter Zeit jedoch mehrere Angriffe mit bösartigem Datenverkehr im Bereich von einem Terabit) vor einem „Überlauf“ der Uplinks.

Wenn dennoch einige Uplinks „verstopft“ sind, ziehen Sie einfach diesen Standort aus dem Betrieb (stoppen Sie die Ankündigung des Präfixes).

Sie können auch den Anteil des Datenverkehrs erhöhen, der von Ihren „vollwertigen“ (und somit geschützten) Rechenzentren bereitgestellt wird, wodurch Sie einen erheblichen Teil des bösartigen Datenverkehrs von ungeschützten Präsenzpunkten entfernen.
Und noch eine kleine Anmerkung zu diesem Beispiel. Wenn Sie eine ausreichende Menge an Datenverkehr über IX ausgeben, verringert das ebenfalls Ihre Anfälligkeit für solche Angriffe.

BGP-Konfiguration

Hier gibt es zwei Themen.

Konnektivität
BGP-Konfiguration

Über die Konnektivität haben wir bereits ein wenig in gesprochen Teil 1. Es geht darum, dass der Verkehr zu Ihren Kunden auf optimalem Weg erfolgt. Obwohl Optimalität nicht immer nur über Latenz geht, ist in der Regel eine niedrige Latenz das Hauptkriterium für Optimalität. Für einige Unternehmen ist das wichtiger, für andere weniger. Das hängt vom Service ab, den Sie anbieten.

Beispiel 1
Wenn Sie ein Austausch sind und für Ihre Kunden Zeitintervalle von weniger als einer Millisekunde wichtig sind, dann gibt es keinen Platz für Internet.

Beispiel 2
Wenn Sie ein Gaming-Unternehmen sind und für Sie Dutzende von Millisekunden wichtig sind, ist die Konnektivität natürlich sehr wichtig für Sie.

Beispiel 3
Es ist auch wichtig zu verstehen, dass die Geschwindigkeit der Datenübertragung innerhalb einer TCP-Sitzung aufgrund der Eigenschaften des TCP-Protokolls auch von der RTT (Round Trip Time) abhängt. CDN-Netzwerke werden unter anderem auch zur Lösung dieses Problems aufgebaut, indem sie die Content-Delivery-Server näher zum Konsumenten des Inhalts bringen.

Die Untersuchung der Konnektivität ist ein separates, interessantes Thema, das eine eigene Artikelreihe verdient und ein gutes Verständnis dafür erfordert, wie das Internet „aufgebaut“ ist.

Nützliche Ressourcen:

ripe.net
bgp.he.net

Beispiel
Ich werde nur ein kleines Beispiel anführen.
Angenommen, Ihr Rechenzentrum befindet sich in Moskau und Sie haben einen einzigen Upstream – Rostelecom (AS12389). In diesem Fall (single homed) benötigen Sie kein BGP, und als öffentliche IP-Adressen verwenden Sie höchstwahrscheinlich den Adresspool von Rostelecom.
Angenommen, Sie bieten einen bestimmten Service an und haben eine ausreichende Anzahl von Kunden aus der Ukraine, die sich über hohe Latenzzeiten beschweren. Bei der Untersuchung haben Sie herausgefunden, dass die IP-Adressen einiger von ihnen im Netzwerk 37.52.0.0/21 liegen.
Nachdem Sie traceroute ausgeführt haben, haben Sie gesehen, dass der Verkehr über AS1299 (Telia) geht, und beim Ausführen von ping haben Sie eine durchschnittliche RTT von 70–80 Millisekunden erhalten. Sie können dies auch auf dem Looking Glass von Rostelecom.
Mit dem Whois-Tool (auf der Website ripe.net oder mit einem lokalen Tool) können Sie leicht feststellen, dass der Block 37.52.0.0/21 zu AS6849 (Ukrtelecom) gehört.
Darüber hinaus sehen Sie nach dem Besuch von bgp.he.net dass AS6849 keine Beziehungen zu AS12389 hat (sie sind weder Kunden noch Upstreams füreinander, und sie haben auch keine Peering-Beziehungen). Aber wenn Sie sich die Peering-Liste für AS6849 ansehen, sehen Sie zum Beispiel AS29226 (Mastertel) und AS31133 (Megafon).
Wenn Sie das Looking Glass dieser Anbieter finden, können Sie den Pfad und die RTT vergleichen. Zum Beispiel hätte Mastertel bereits eine RTT von etwa 30 Millisekunden.
Wenn der Unterschied zwischen 80 und 30 Millisekunden für Ihren Service erheblich ist, sollten Sie vielleicht über die Konnektivität nachdenken, sich bei RIPE Ihre AS-Nummer besorgen, Ihren Adresspool bereitstellen und zusätzliche Upstreams anschließen und/oder Präsenzpunkte bei IXs erstellen.

Mit BGP haben Sie nicht nur die Möglichkeit, die Konnektivität zu verbessern, sondern auch Ihre Internetverbindung zu sichern.

Dieses Dokument enthält Empfehlungen zur Konfiguration von BGP. Obwohl diese Empfehlungen auf den Best Practices von Anbietern basieren, sind sie dennoch - falls Ihre BGP-Einstellungen nicht ganz trivial sind - definitiv nützlich und sollten tatsächlich Teil der Härtung sein, über die wir in ersten Teils.

DOS/DDOS-Schutz

In der heutigen Zeit sind DOS/DDOS-Angriffe für viele Unternehmen eine alltägliche Realität. Tatsächlich werden Sie in der einen oder anderen Form ziemlich häufig angegriffen. Dass Sie dies bisher nicht bemerkt haben, bedeutet nur, dass noch kein gezielter Angriff auf Sie organisiert wurde und dass die Schutzmaßnahmen, die Sie nutzen, möglicherweise (wie verschiedene eingebaute Schutzmechanismen der Betriebssysteme) ausreichend sind, um die Degradierung des bereitgestellten Dienstes für Sie und Ihre Kunden zu minimieren.

Es gibt Webressourcen, die auf Basis von Logs von Geräten in Echtzeit schöne Angriffskarten zeichnen.

Hier Sie finden Links zu ihnen.

Meine Lieblings- Karte von CheckPoint.

DDoS/DOS-Schutz ist normalerweise schichtweise. Um zu verstehen, warum, müssen Sie verstehen, welche Arten von DOS/DDOS-Angriffen es gibt (siehe zum Beispiel hier oder hier)

Das heißt, wir haben drei Arten von Angriffen:

volumetrische Angriffe
Protokollangriffe
Anwendungsangriffe

Während Sie sich vor den letzten beiden Angriffsarten selbst mit Hilfe von Firewalls schützen können, können Sie sich gegen Angriffe, die auf das „Überfluten“ Ihrer Upstream-Verbindungen abzielen, nicht selbst schützen (natürlich, wenn Ihre gesamte Internet-Kapazität nicht in Terabits, besser noch in Dutzenden von Terabits gemessen wird).

Deshalb ist die erste Verteidigungslinie der Schutz vor „volumetrischen“ Angriffen, und dieser Schutz sollte von Ihrem Anbieter oder den Anbietern bereitgestellt werden. Wenn Sie dies noch nicht erkannt haben, haben Sie bisher einfach Glück gehabt.

Beispiel
Angenommen, Sie haben mehrere Upstream-Verbindungen, aber nur einer der Anbieter kann Ihnen diesen Schutz bieten. Doch wenn der gesamte Verkehr über einen Anbieter läuft, wie steht es dann um die Konnektivität, die wir kurz zuvor besprochen haben?
Im Falle eines Angriffs müssen Sie in diesem Fall teilweise auf Konnektivität verzichten.

Dies ist nur während eines Angriffs. Sie können im Falle eines Angriffs manuell oder automatisch BGP neu konfigurieren, damit der Verkehr nur über den Anbieter geleitet wird, der Ihnen den "Schutzschirm" zur Verfügung stellt. Nach dem Ende des Angriffs können Sie das Routing in den ursprünglichen Zustand zurückversetzen.

Es ist nicht notwendig, den gesamten Verkehr umzuleiten. Wenn Sie beispielsweise sehen, dass über bestimmte Uplinks oder Peering keine Angriffe stattfinden (oder der Verkehr nicht erheblich ist), können Sie weiterhin Präfixe mit wettbewerbsfähigen Attributen an diese BGP-Nachbarn ankündigen.

Den Schutz vor "Protokoll-Angriffen" und "Anwendungs-Angriffen" können Sie ebenfalls an Partner delegieren.
Hier hier Sie können eine gute Studie lesen (Übersetzung). Zwar ist der Artikel zwei Jahre alt, aber er wird Ihnen einen Einblick in Ansätze geben, wie Sie sich gegen DDoS-Angriffe schützen können.

Im Grunde können Sie sich darauf beschränken, Ihren Schutz vollständig auszulagern. Diese Lösung hat ihre Vorteile, aber auch offensichtliche Nachteile. Es könnte sich (je nach Tätigkeit Ihres Unternehmens) um das Überleben des Unternehmens handeln. Und solchen Dingen Dritten anzuvertrauen...

Lassen Sie uns daher betrachten, wie wir die zweite und dritte Verteidigungslinie organisieren (als Ergänzung zum Schutz des Anbieters).

Die zweite Verteidigungslinie besteht aus der Filterung und Verkehrsregelung (Policern) am Eingang zu Ihrem Netzwerk.

Beispiel 1
Angenommen, Sie haben sich mit einem "Schutzschirm" gegen DDoS mit Hilfe eines der Anbieter geschützt. Angenommen, dieser Anbieter verwendet Arbor zur Verkehrsfiltrotion und Filter an der Grenze seines Netzwerks.
Die Bandbreite, die Arbor "verarbeiten" kann, ist begrenzt, und der Anbieter kann natürlich nicht ständig den gesamten Verkehr seiner Partner, die diesen Dienst bestellt haben, durch die Filtergeräte leiten. Daher wird der Verkehr unter normalen Bedingungen nicht gefiltert.
Angenommen, es findet ein SYN-Flood-Angriff statt. Selbst wenn Sie einen Service gebucht haben, bei dem der Verkehr im Falle eines Angriffs automatisch zur Filterung umgeleitet wird, geschieht dies nicht sofort. Sie bleiben für eine Minute oder länger unter Beschuss. Und das kann zu einem Ausfall Ihrer Hardware oder einer Degradierung des Dienstes führen. In diesem Fall wird eine Traffic-Beschränkung an der Grenzroute, obwohl sie dazu führt, dass einige TCP-Sitzungen in dieser Zeit nicht hergestellt werden, Ihre Infrastruktur vor größeren Problemen bewahren.

Beispiel 2
Eine abnormal hohe Anzahl von SYN-Paketen kann nicht nur das Ergebnis eines SYN-Flood-Angriffs sein. Stellen wir uns vor, Sie bieten einen Service an, bei dem Sie gleichzeitig etwa 100.000 TCP-Verbindungen (zu einem Rechenzentrum) haben können.
Angenommen, aufgrund eines kurzfristigen Problems mit einem Ihrer Hauptanbieter wurden die Hälfte der Sitzungen „gekickt“. Wenn Ihre Anwendung so eingerichtet ist, dass sie, ganz ohne nachzudenken, sofort (oder nach einem für alle Sitzungen gleichen Zeitintervall) versucht, die Verbindung wiederherzustellen, erhalten Sie ungefähr gleichzeitig mindestens 50.000 SYN-Pakete.
Wenn auf diesen Sitzungen beispielsweise ein SSL/TLS-Handshake laufen muss, der einen Austausch von Zertifikaten impliziert, dann wird dies aus der Sicht der Ressourcenauslastung für Ihren Load Balancer ein viel stärkerer „DDoS“-Angriff sein als ein einfacher SYN-Flood. Auf den ersten Blick sollten Load Balancer solche Ereignisse verarbeiten können, aber ... leider sind wir mit diesem Problem konfrontiert.
Und natürlich wird ein Polizist (Policer) am Grenzrouter Ihre Hardware auch in diesem Fall schützen.

Die dritte Verteidigungsebene gegen DDoS/DOS sind die Einstellungen Ihrer Firewall.

Hier können Sie sowohl Angriffe des zweiten als auch des dritten Typs eindämmen. Im Allgemeinen können alles, was die Firewall erreicht, hier gefiltert werden.

Tipp
Versuchen Sie, der Firewall so wenig Arbeit wie möglich zu geben, indem Sie so viel wie möglich in den ersten beiden Verteidigungslinien filtern. Und das ist der Grund.
Hatten Sie schon einmal das Problem, dass Sie beim Testen, wie widerstandsfähig das Betriebssystem Ihrer Server gegen DDoS-Angriffe ist, zufällig Ihren Firewall überlastet haben, indem Sie ihn mit 100 Prozent Verkehr belasten, der normalerweise auftritt? Wenn nicht, liegt es möglicherweise einfach daran, dass Sie es noch nicht versucht haben.
Im Allgemeinen ist die Firewall, wie ich bereits erwähnt habe, eine komplexe Angelegenheit. Sie funktioniert gut mit bekannten Schwachstellen und getesteten Lösungen, aber wenn Sie etwas Ungewöhnliches, einfach irgendeinen Müll oder Pakete mit falschen Headern senden, können Sie mit einer nicht ganz geringen Wahrscheinlichkeit (je nach meiner Erfahrung) selbst hochwertige Geräte in Schwierigkeiten bringen. Daher sollten Sie in Schritt 2 nur den Verkehr in Ihr Netzwerk lassen, der dort hineingehören sollte, unter Verwendung normaler ACLs (auf L3/L4-Ebene).