Dieser Artikel ist der vierte in einer Reihe von Artikeln zur Thematik „Wie Sie die Netzwerk-Infrastruktur unter Kontrolle bringen“. Die Inhalte aller Artikel der Reihe und Links finden Sie hier.

In dem ersten Teil dieses Kapitels haben wir einige Aspekte der Netzwerksicherheit im Bereich „Data Center“ betrachtet. Dieser Teil wird dem Segment „Internetzugang“ gewidmet sein.

Internetzugang

Das Thema Sicherheit ist zweifellos eines der komplexesten Themen im Bereich der Datenübertragungsnetzwerke. Wie in den vorherigen Fällen zeige ich hier zwar keine vollständige Tiefe, jedoch werde ich einige einfache, aber meiner Meinung nach wichtige Fragen behandeln, deren Antworten hoffentlich helfen werden, die Sicherheit Ihres Netzwerks zu erhöhen.

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

Design
BGP-Einstellungen
DOS/DDOS Schutz
Traffic-Filterung auf der Firewall

Design

Als Beispiel für das Design dieses Segments im Unternehmensnetzwerk würde ich empfehlen, die Richtlinien von Cisco im Rahmen der SAFE-Modelle.

Natürlich mag Ihnen die Lösung anderer Anbieter attraktiver erscheinen (siehe Gartner-Quadrant von 2018)), aber ohne Sie dazu aufzufordern, diesem Design im Detail zu folgen, halte ich es dennoch für sinnvoll, die Prinzipien und Ideen zu verstehen, die ihm zugrunde liegen.

Hinweis
Im SAFE-Segment ist der Bereich „Remote Access“ Teil des „Internet Access“. In diesem Artikelzyklus werden wir ihn jedoch separat betrachten.

Die Standardhardware in diesem Segment für das Unternehmensnetzwerk (enterprise network) sind

Grenzrouter (border routers)
Firewalls

Hinweis 1
In diesem Artikelzyklus, wenn ich von Firewalls spreche, meine ich NGFW.

Hinweis 2
Ich lasse die Betrachtung verschiedener L2/L1- oder Overlay-L2-über-L3-Lösungen, die zur Gewährleistung von L1/L2-Konnektivität erforderlich sind, außen vor und beschränke mich nur auf Themen der L3-Ebene und höher. Teilweise wurden die Themen L1/L2 im Kapitel „Reinigung und Dokumentation«.

Wenn Sie keine Firewall in diesem Segment gefunden haben, sollten Sie nicht zu schnell zu Schlüssen kommen.

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

Ich kann sagen, dass es anscheinend der sinnvollste Ort für den Einsatz von Firewalls und für die Anwendung komplexer Traffic-Filteralgorithmen ist. In Teil 1 Wir haben vier Faktoren erwähnt, die die Nutzung von Firewalls im Rechenzentrumsbereich beeinträchtigen können. Hier sind sie jedoch nicht mehr so relevant.

Beispiel 1. Latenz
Im Hinblick auf das Internet macht es keinen Sinn, von Latenzen selbst im Bereich von 1 Millisekunde zu sprechen. Daher kann die Latenz in diesem Segment kein Faktor sein, der die Nutzung von Firewalls einschränkt.

Beispiel 2. Leistung
In einigen Fällen kann dieser Faktor dennoch entscheidend sein. Daher müssen Sie möglicherweise einen Teil des Verkehrs (zum Beispiel den Verkehr von Lastenausgleichern) an Firewalls vorbeileiten.

Beispiel 3. Zuverlässigkeit
Dieser Faktor sollte weiterhin berücksichtigt werden, aber angesichts der Unzuverlässigkeit des Internets ist seine Bedeutung für dieses Segment nicht so groß wie für ein Rechenzentrum.
Angenommen, Ihr Dienst 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 zweite umleiten.
Oder Sie können Firewalls im transparenten Modus verwenden und im Falle eines Ausfalls während der Problemlösung den Verkehr an Firewalls vorbeileiten.

Deshalb ist es wahrscheinlich der Preis, der Sie dazu bringen könnte, auf Firewalls in diesem Bereich zu verzichten. Preis Der Preis könnte tatsächlich der Faktor sein, der Sie davon abbringt, in diesem Segment Firewalls zu verwenden.

Wichtig!
Es besteht die Versuchung, diese Firewall mit der Firewall des Rechenzentrums zu kombinieren (also eine Firewall für beide Segmente zu verwenden). Diese Lösung ist im Prinzip möglich, aber man muss verstehen, dass die Firewall für den Internetzugang, die an der Frontlinie Ihrer Verteidigung steht und, zumindest teilweise, schädlichen Verkehr abfängt, ein erhöhtes Risiko birgt, dass sie ausfällt. Das bedeutet, wenn Sie dieselben Geräte in beiden Segmenten verwenden, verringern Sie erheblich die Verfügbarkeit Ihres Rechenzentrumssegments.

Wie üblich muss man bedenken, dass das Design dieses Segments je nach den angebotenen Dienstleistungen des Unternehmens stark variieren kann. Sie können, wie gewohnt, je nach den Anforderungen unterschiedliche Ansätze wählen.

Beispiel
Wenn Sie ein Content-Anbieter mit einem CDN-Netzwerk sind (siehe zum Beispiel eine Reihe von Artikeln), dann möchten Sie möglicherweise nicht dutzende oder sogar Hunderte von Infrastruktur-Punkten mit separaten Geräten zur Routing- und Traffic-Filterung erstellen. Das wäre teuer und möglicherweise einfach überflüssig.
Für BGP benötigen Sie nicht unbedingt dedizierte Router; Sie können Open-Source-Tools verwenden, wie zum Beispiel Quagga. Daher könnte alles, was Sie benötigen, 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 fungieren, sondern auch als Router. Natürlich gibt es hier viele Details (z. B. wie man die Last verteilt), aber es ist umsetzbar, und diesen Ansatz haben wir erfolgreich für einen unserer Partner angewendet.
Sie können mehrere Rechenzentren mit umfassendem Schutz (Firewalls, DDoS-Schutzdienste, die von Ihren Internetanbietern bereitgestellt werden) und dutzende oder hunderte von "vereinfachten" Präsenzpunkten nur mit L2-Switches und Servern haben.
Und wie steht es in diesem Fall um den Schutz?
Lassen Sie uns beispielsweise einen der zuletzt populären Angriffe betrachten, DNS Amplification DDoS-Angriff.Die Gefahr liegt darin, dass eine große Menge an Traffic generiert wird, die einfach alle Ihre Upstream-Verbindungen zu 100 % überlastet.
Was haben wir in Bezug auf unser Design?

Wenn Sie AnyCast verwenden, wird der Traffic zwischen Ihren Standorten verteilt. Wenn Ihre gesamte Bandbreite in Terabit liegt, schützt Sie das tatsächlich (trotz einiger jüngster Angriffe mit bösartigem Traffic von etwa Terabit) vor einer Überlastung Ihrer Upstreams.

Wenn dennoch einige Upstreams überlastet sind, können Sie diese einfach vom Dienst nehmen (indem Sie aufhören, das Präfix anzukündigen).

Sie können auch den Traffic-Anteil erhöhen, der von Ihren „vollwertigen“ (und somit geschützten) Rechenzentren ausgegeben wird, wodurch ein wesentlicher Teil des bösartigen Traffics von ungeschützten Standorten entfernt wird.
Noch eine kleine Anmerkung zu diesem Beispiel: Wenn Sie eine ausreichende Menge an Traffic über IX verteilen, verringert das ebenfalls Ihre Anfälligkeit für derartige Angriffe.

BGP-Konfiguration

Hier gibt es zwei Themen.

Konnektivität
BGP-Konfiguration

Über die Konnektivität haben wir bereits ein wenig gesprochen. Teil 1. Es geht darum, den Datenverkehr zu Ihren Kunden auf optimalem Weg zu leiten. Obwohl Optimierung nicht immer nur mit Latenz zusammenhängt, ist in der Regel eine niedrige Latenz der Hauptindikator für Optimierung. Für manche Unternehmen ist das wichtiger, für andere weniger. Es hängt alles von dem Service ab, den Sie anbieten.

Beispiel 1
Wenn Sie eine Börse sind und für Ihre Kunden Zeitintervalle von weniger als einer Millisekunde wichtig sind, dann ist klar, dass ein Internet überhaupt keine Rolle spielt.

Beispiel 2
Wenn Sie ein Spieleunternehmen sind und für Sie Zehntelmillisekunden wichtig sind, dann ist die Konnektivität natürlich von großer Bedeutung für Sie.

Beispiel 3
Es ist auch wichtig zu verstehen, dass aufgrund der Eigenschaften des TCP-Protokolls die Datenübertragungsgeschwindigkeit innerhalb einer TCP-Sitzung ebenfalls von der RTT (Round Trip Time) abhängt. CDN-Netzwerke werden unter anderem eingerichtet, um dieses Problem zu lösen, indem sie Content-Server näher an die Verbraucher dieses Inhalts bringen.

Die Untersuchung der Konnektivität ist ein eigenes, interessantes Thema, das einer gesonderten Artikelreihe würdig ist und ein gutes Verständnis dafür erfordert, wie das Internet „aufgebaut“ ist.

Nützliche Ressourcen:

ripe.net
bgp.he.net

Beispiel
Ich möchte nur ein kleines Beispiel anführen.
Angenommen, Ihr Rechenzentrum befindet sich in Moskau und Sie haben eine einzige Anbindung – Rostelecom (AS12389). In diesem Fall benötigen Sie kein (single homed) BGP, und als öffentliche IP-Adressen verwenden Sie wahrscheinlich einen Adresspool von Rostelecom.
Angenommen, Sie bieten einen Dienst an und haben ausreichend Kunden aus der Ukraine, die sich über hohe Latenzen beschweren. Bei der Untersuchung haben Sie festgestellt, dass einige ihrer IP-Adressen im Bereich 37.52.0.0/21 liegen.
Nachdem Sie traceroute ausgeführt haben, stellten Sie fest, dass der Datenverkehr über AS1299 (Telia) läuft, und beim Ausführen eines pings erhielten Sie eine mittlere RTT von 70 – 80 Millisekunden. Sie können dies ebenfalls auf dem Looking Glass von Rostelecom sehen..
Mit dem Tool whois (auf ripe.net oder einem lokalen Tool) können Sie leicht herausfinden, dass der Block 37.52.0.0/21 zu AS6849 (Ukrtelecom) gehört.
Gehen Sie nun auf bgp.he.net , und Sie sehen, dass AS6849 keine Beziehungen zu AS12389 hat (sie sind weder Kunden noch Upstreams füreinander, und auch kein Peering besteht). Aber wenn Sie sich die Peering-Liste von AS6849 anschauen, sehen Sie beispielsweise AS29226 (Mastertel) und AS31133 (Megafon).
Wenn Sie das Looking Glass dieser Anbieter finden, können Sie den Pfad und die RTT vergleichen. Zum Beispiel beträgt die RTT für Mastertel etwa 30 Millisekunden.
Wenn der Unterschied zwischen 80 und 30 Millisekunden für Ihren Service erheblich ist, sollten Sie vielleicht über Konnektivität nachdenken. Beantragen Sie Ihre AS-Nummer im RIPE, sichern Sie sich Ihren Adresspool und erwägen Sie zusätzliche Uplinks oder das Einrichten von Präsenzpunkten an IXs.

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

Dieses Dokument enthält Empfehlungen zur BGP-Konfiguration. Obwohl diese Empfehlungen auf den „Best Practices“ von Anbietern basieren, sind sie, sofern Ihre BGP-Einstellungen nicht ganz trivial sind, zweifellos nützlich und sollten Teil des Hardenings sein, das wir in dem ersten Teil.

DOS/DDOS Schutz

Heutzutage sind DOS-/DDoS-Angriffe für viele Unternehmen eine alltägliche Realität. Tatsächlich werden Sie in irgendeiner Form relativ häufig angegriffen. Dass Sie dies bisher nicht bemerkt haben, bedeutet lediglich, dass noch kein gezielter Angriff auf Sie organisiert wurde und dass die Schutzmaßnahmen, die Sie verwenden – möglicherweise ohne es zu wissen (verschiedene integrierte Schutzfunktionen von Betriebssystemen) – ausreichend sind, um die Degradation der angebotenen Dienste für Sie und Ihre Kunden zu minimieren.

Es gibt Internetressourcen, die anhand von Protokolldaten der Geräte in Echtzeit ansprechende Angriffs-Karten erstellen.

Hier finden Sie Links zu ihnen.

Meine Lieblings- Karte von CheckPoint.

Der Schutz vor DDoS/DOS ist normalerweise mehrschichtig. Um zu verstehen, warum, müssen wir die verschiedenen Arten von DOS-/DDoS-Angriffen kennen (siehe beispielsweise, hier oder hier)

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

volumetrische Angriffe
Protokollangriffe
Anwendungsangriffe

Während Sie sich möglicherweise selbst gegen die letzten beiden Angriffsarten mit Firewalls schützen können, sind Sie gegen Angriffe, die auf ein „Überlaufen“ Ihrer Uplinks abzielen, hilflos — es sei denn, Ihre gesamte Internetbandbreite beträgt mehrere Terabits, besser noch Dutzende Terabits.

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

Beispiel
Angenommen, Sie verfügen über mehrere Uplinks, aber nur ein Anbieter kann Ihnen diesen Schutz bieten. Doch wenn der gesamte Datenverkehr über einen Anbieter läuft, wie sieht es dann mit der Konnektivität aus, die wir zuvor kurz angesprochen haben?
Während eines Angriffs müssen Sie in diesem Fall teilweise auf die Konnektivität verzichten. Aber

das ist nur während des Angriffs. Sie können im Falle eines Angriffs manuell oder automatisch das BGP umkonfigurieren, sodass der Datenverkehr nur über den Anbieter läuft, der Ihnen den ‚Schutzschirm‘ bietet. Nach dem Angriff können Sie das Routing wieder in den ursprünglichen Zustand versetzen.

Es ist nicht erforderlich, den gesamten Datenverkehr zu übertragen. Wenn Sie beispielsweise sehen, dass über bestimmte Upstreams oder Peering keine Angriffe stattfinden (oder der Datenverkehr nicht signifikant ist), können Sie weiterhin Präfixe mit wettbewerbsfähigen Attributen gegenüber diesen BGP-Nachbarn bekanntgeben.

Den Schutz vor „Protocol-Angriffen“ und „Anwendungsangriffen“ können Sie ebenfalls an Partner delegieren.
Hier hier könnten Sie eine gute Studie lesen (Übersetzung). Zugegeben, der Artikel ist zwei Jahre alt, aber er gibt Ihnen einen Einblick in Ansätze, wie Sie sich vor DDoS-Angriffen schützen können.

Im Grunde können Sie sich darauf beschränken, Ihre gesamte Sicherheit auszulagern. Es gibt Vorteile in dieser Lösung, aber auch einen offensichtlichen Nachteil. Es könnte sich (abhängig von dem, was Ihr Unternehmen tut) um das Überleben des Geschäfts handeln. Und so etwas externen Organisationen anzuvertrauen...

Deshalb lassen Sie uns betrachten, wie wir eine zweite und dritte Verteidigungslinie einrichten können (als Ergänzung zum Schutz des Anbieters).

Die zweite Verteidigungslinie besteht aus Filtern und Traffic-Polizisten (policers) an der Eingangsseite Ihres Netzwerks.

Beispiel 1
Stellen Sie sich vor, Sie haben sich durch einen Anbieter gegen DDoS-Angriffe "unter einen Schirm zurückgezogen". Angenommen, dieser Anbieter verwendet Arbor zur Filterung des Traffics und Filter an der Grenze seines Netzwerks.
Die Bandbreite, die Arbor "verarbeiten" kann, ist begrenzt, und der Anbieter kann selbstverständlich nicht ständig den gesamten Traffic aller seiner Partner, die diesen Service bestellt haben, durch die Filtergeräte leiten. Daher wird unter normalen Bedingungen der Traffic nicht gefiltert.
Angenommen, es findet ein SYN-Flood-Angriff statt. Selbst wenn Sie einen Service bestellt haben, bei dem im Falle eines Angriffs der Traffic automatisch zur Filterung geleitet wird, geschieht dies nicht sofort. Für eine Minute oder länger sind Sie unter Angriff. Und das kann dazu führen, dass Ihre Hardware ausfällt oder der Service beeinträchtigt wird. In diesem Fall wird die Traffic-Beschränkung an der Grenz-Routing zwar dazu führen, dass einige TCP-Sitzungen in dieser Zeit nicht hergestellt werden, aber sie wird 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. Nehmen wir an, dass Sie einen Dienst bereitstellen, bei dem gleichzeitig etwa 100.000 TCP-Verbindungen (in einem Rechenzentrum) bestehen können.
Angenommen, aufgrund eines kurzfristigen Problems mit einem Ihrer Hauptanbieter wurden die Hälfte der Sitzungen getrennt. Wenn Ihre Anwendung so konzipiert ist, dass sie, ohne lange nachzudenken, sofort (oder nach einem einheitlichen Zeitintervall für alle Sitzungen) versucht, die Verbindung neu herzustellen, dann erhalten Sie ungefähr gleichzeitig mindestens 50.000 SYN-Pakete.
Wenn über diesen Sitzungen beispielsweise ein SSL/TLS-Handshake stattfinden soll, der den Austausch von Zertifikaten impliziert, wird dies aus Sicht der Ressourcenerschöpfung für Ihren Lastenausgleich ein viel gravierenderes "DDoS" darstellen als ein einfacher SYN-Flood. Es scheint, als sollten Lastenausgleicher solche Ereignisse bewältigen können, aber ... leider sind wir in vollem Umfang mit diesem Problem konfrontiert worden.
Und natürlich wird ein Policer am Grenzrouter Ihr Equipment in diesem Fall schützen.

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

Hier können sowohl Angriffe der zweiten als auch der dritten Art abgewehrt werden. Grundsätzlich können alle Gefahren, die die Firewall erreichen, hier gefiltert werden.

Tipp
Versuchen Sie, der Firewall so wenig Arbeit wie möglich zu geben, indem Sie möglichst viel in den ersten beiden Verteidigungslinien filtern. Und das ist der Grund dafür.
Hatten Sie jemals das Problem, dass Sie durch das Generieren von Traffic, um beispielsweise zu testen, wie robust das Betriebssystem Ihrer Server gegen DDoS-Angriffe ist, Ihre Firewall "überlastet" haben, indem Sie sie auf 100 Prozent ausgelastet haben, während Sie normalen Traffic erzeugt haben? Wenn nicht, dann vielleicht einfach, weil Sie es noch nicht ausprobiert haben?
Im Allgemeinen ist eine Firewall, wie ich bereits erwähnt habe, eine komplexe Angelegenheit. Sie funktioniert gut mit bekannten Schwachstellen und erprobten Lösungen, aber wenn Sie etwas Ungewöhnliches schicken – einfach irgendwelchen Müll oder Pakete mit falschen Headern – besteht eine nicht unerhebliche Wahrscheinlichkeit, dass selbst hochmodernes Equipment ins Stocken gerät. Daher sollten Sie im Schritt 2 mit gewöhnlichen ACL (auf L3/L4-Ebene) nur den Traffic in Ihr Netzwerk lassen, der dort hineingehört.