DDoS zur Hilfe: wie wir Stress- und Lasttests durchführen

Die Firma Variti entwickelt Bot-Schutz und DDoS-Abwehr und führt außerdem Stress- und Lasttests durch. Auf der Konferenz HighLoad++ 2018 haben wir darüber gesprochen, wie man Ressourcen gegen verschiedene Arten von Angriffen absichert. Kurz gesagt: Isolieren Sie Teile des Systems, nutzen Sie Cloud-Dienste und CDN und halten Sie Ihre Software regelmäßig auf dem neuesten Stand. Allerdings kommen Sie ohne spezialisierte Anbieter für Sicherheitslösungen dennoch nicht weit 🙂

Bevor Sie den Text lesen, können Sie sich mit den kurzen Thesen vertraut machen. auf der Website der Konferenz..
Wenn Sie nicht gerne lesen oder einfach das Video anschauen möchten, finden Sie die Aufzeichnung unseres Vortrags unten im Spoiler.

Videoaufzeichnung des Vortrags

Viele Unternehmen sind bereits in der Lage, Lasttests durchzuführen, aber nicht alle führen auch Stresstests durch. Einige unserer Kunden sind der Ansicht, dass ihre Website unverwundbar ist, weil sie über ein Highload-System verfügen und dieses gut gegen Angriffe schützt. Wir zeigen jedoch, dass dies nicht ganz der Wahrheit entspricht.
Selbstverständlich holen wir vor den Tests die Zustimmung des Kunden ein, inklusive Unterschrift und Stempel. Mit unserer Hilfe ist es nicht möglich, eine DDoS-Attacke gegen irgendjemanden durchzuführen. Die Tests finden zu einem vom Kunden gewählten Zeitpunkt statt, an dem die Besucherzahlen seiner Ressource minimal sind, sodass Zugangsprobleme keine Auswirkungen auf die Kunden haben. Darüber hinaus halten wir während des gesamten Testprozesses einen ständigen Kontakt mit dem Kunden. Dies ermöglicht es uns, nicht nur über die erzielten Ergebnisse zu berichten, sondern auch Anpassungen während der Tests vorzunehmen. Nach Abschluss der Tests erstellen wir immer einen Bericht, in dem wir die festgestellten Mängel benennen und Empfehlungen zur Behebung der Schwachstellen der Website geben.

So arbeiten wir

Bei den Tests simulieren wir ein Botnetz. Da wir mit Kunden arbeiten, die sich nicht in unseren Netzwerken befinden, geben wir den Stress nicht von einer IP aus, sondern aus unserem eigenen Subnetz aus, um zu verhindern, dass der Test gleich nach der ersten Minute aufgrund von Limits oder Schutzmaßnahmen abgebrochen wird. Zudem verfügen wir über einen leistungsstarken Testserver, um eine erhebliche Last zu erzeugen.

Postulate

Viel bedeutet nicht immer gut
Je geringer die Last, die wir benötigen, um eine Ressource zum Ausfall zu bringen, desto besser. Wenn es gelingt, die Website durch nur einen Aufruf pro Sekunde oder sogar durch einen Aufruf pro Minute zum Stillstand zu bringen, ist das großartig. Denn das Gesetz der Wahrscheinlichkeit besagt, dass Benutzer oder Angreifer zufällig genau diese Schwachstelle ausnutzen werden.

Teilweiser Ausfall ist besser als vollständiger
Wir empfehlen immer, Systeme heterogen zu gestalten. Dabei sollten sie auf physischer Ebene getrennt werden und nicht nur durch Containerisierung. Bei physischer Trennung ist die Wahrscheinlichkeit groß, dass die Website auch bei einem Ausfall noch teilweise funktionsfähig bleibt und die Benutzer zumindest Zugang zu einem Teil der Funktionalität haben.

Die richtige Architektur ist die Grundlage der Stabilität
Die Ausfallsicherheit einer Ressource und ihre Fähigkeit, Angriffe und Lasten standzuhalten, müssen bereits in der Entwurfsphase auf Grundlage der ersten Diagramme im Notizbuch eingeplant werden. Denn wenn fatale Fehler auftreten, können sie später zwar behoben werden, sind jedoch sehr schwer zu korrigieren.

Nicht nur der Code, sondern auch die Konfiguration sollte gut sein
Viele glauben, dass ein gutes Entwicklungsteam eine Garantie für die Ausfallsicherheit eines Services ist. Ein gutes Entwicklungsteam ist zwar notwendig, aber es benötigt auch einen effektiven Betrieb und kompetentes DevOps. Das heißt, es sind Fachleute erforderlich, die Linux und das Netzwerk richtig konfigurieren, die Nginx-Konfigurationen korrekt erstellen und Limits sowie andere Einstellungen richtig vornehmen. Andernfalls wird die Ressource nur im Test gut funktionieren, während sie in der Produktion irgendwann versagen wird.

Unterschiede zwischen Last- und Stresstests
Lasttests ermöglichen es, die Grenzen der Funktionsfähigkeit eines Systems zu identifizieren. Stresstests hingegen sind darauf ausgerichtet, Schwachstellen im System zu finden. Sie werden durchgeführt, um das System zum Versagen zu bringen und zu beobachten, wie es sich bei einem Ausfall bestimmter Komponenten verhält. Dabei ist die Art der Last in der Regel bis zum Beginn des Stresstests unbekannt für den Auftraggeber.

Besonderheiten von L7-Angriffen

Wir unterteilen die Lastarten üblicherweise in L7- und L3&4-Lasten. L7 bezieht sich auf Lasten auf Anwendungsebene, die meist nur HTTP umfassen. Wir verstehen darunter jedoch jede Last auf der TCP-Protokollebene.
L7-Angriffe weisen bestimmte charakteristische Merkmale auf. Erstens gelangen sie direkt an die Anwendung, weshalb es kaum möglich ist, sie mit Netzwerkmaßnahmen abzuwehren. Solche Angriffe nutzen Logik, wodurch sie sehr effizient und mit geringem Traffic CPU, RAM, Speicher, Datenbank und andere Ressourcen beanspruchen.

HTTP Flood

Bei jedem Angriff ist es einfacher, die Last zu erzeugen, als sie zu verarbeiten, und das gilt auch für L7. Angriffs-Traffic ist nicht immer leicht von legitimen Anfragen zu unterscheiden, und das gelingt meist anhand der Häufigkeit. Wenn alles jedoch gut geplant ist, ist es anhand der Logs unmöglich zu erkennen, wo der Angriff und wo die legitimen Anfragen sind.
Als erstes Beispiel betrachten wir den HTTP Flood-Angriff. Aus dem Diagramm geht hervor, dass solche Angriffe in der Regel sehr mächtig sind; im folgenden Beispiel überstieg die Spitzenanzahl der Anfragen 600.000 pro Minute.

HTTP Flood ist die einfachste Methode, um Last zu erzeugen. Oft wird dafür ein Lasttest-Tool wie ApacheBench verwendet, um Anfragen und Ziele festzulegen. Bei diesem einfachen Ansatz besteht eine hohe Wahrscheinlichkeit, dass das Server-Caching aktiviert ist, jedoch lässt sich dies leicht umgehen. Beispielsweise durch das Hinzufügen zufälliger Zeichenfolgen zur Anfrage, wodurch der Server gezwungen wird, ständig die aktuelle Seite auszugeben.
Ebenso sollte man bei der Lastgenerierung nicht den User-Agent vergessen. Viele User-Agents von beliebten Testwerkzeugen werden von Systemadministratoren gefiltert, wodurch die Last möglicherweise nicht bis zum Backend gelangt. Signifikant verbessern kann man das Ergebnis, indem man in die Anfrage einen mehr oder weniger gültigen Header aus einem Browser einfügt.
Trotz der Einfachheit haben HTTP Flood-Angriffe auch ihre Nachteile. Erstens erfordern sie große Kapazitäten zur Lastgenerierung. Zweitens werden solche Angriffe sehr leicht erkannt, besonders wenn sie von einer einzigen Adresse ausgehen. Infolgedessen werden die Anfragen sofort entweder von Systemadministratoren gefiltert oder sogar auf Anbieter-Ebene.

Was zu beachten ist

Um die Anzahl der Anfragen pro Sekunde zu reduzieren, ohne an Effizienz zu verlieren, ist ein wenig Kreativität gefragt. Man kann nicht nur den Kanal oder den Server belasten, sondern auch einzelne Teile der Anwendung, wie Datenbanken oder Dateisysteme. Außerdem sollte man nach Bereichen auf der Website suchen, die große Berechnungen durchführen, wie Rechner, Produktvergleichsseiten und dergleichen. Oft gibt es auch einen PHP-Skript auf der Website, der eine Seite aus mehreren Hunderttausend Zeilen generiert. Ein solcher Skript kann ebenfalls erheblich die Serverlast erhöhen und ein Ziel für Angriffe werden.

Wo suchen

Wenn wir eine Ressource vor der Durchführung von Tests scannen, schauen wir zunächst natürlich auf die Website selbst. Wir suchen nach Eingabefeldern, großen Dateien — kurz gesagt, allem, was Probleme für die Ressource verursachen und ihre Leistungsfähigkeit verringern könnte. Hierbei helfen die einfachen Entwicklertools in Google Chrome und Firefox, die die Antwortzeiten der Seite anzeigen.
Wir scannen auch Subdomains. Zum Beispiel gibt es einen Online-Shop, abc.com, und eine Subdomain admin.abc.com. Wahrscheinlich handelt es sich hierbei um den administrativen Bereich mit Authentifizierung. Wenn wir jedoch Last darauf ausüben, kann dies Probleme für die Hauptressource verursachen.
Die Website könnte eine Subdomain api.abc.com haben. Wahrscheinlich ist dies eine Ressource für mobile Anwendungen. Man kann die App im App Store oder Google Play finden, einen speziellen Zugangspunkt einrichten, die API analysieren und Testkonten registrieren. Das Problem ist, dass viele Leute glauben, dass alles, was durch Authentifizierung geschützt ist, immun gegen Denial-of-Service-Angriffe ist. Man denkt oft, dass Authentifizierung die beste CAPTCHA ist, aber das ist nicht der Fall. Es ist einfach, 10-20 Testkonten zu erstellen, und sobald wir sie haben, erhalten wir Zugang zu komplexen und unverdeckten Funktionen.
Natürlich analysieren wir die Historie, die robots.txt und WebArchive, ViewDNS und suchen nach älteren Versionen der Website. Manchmal kommt es vor, dass die Entwickler beispielsweise mail2.yandex.net veröffentlichen, während die alte Version, mail.yandex.net, bestehen bleibt. Diese mail.yandex.net wird nicht mehr unterstützt, es werden keine Entwicklungsressourcen dafür bereitgestellt, aber sie verbraucht weiterhin die Datenbank. Daher können wir mit der alten Version effektiv die Backend-Ressourcen und alles, was hinter dem Layout steht, nutzen. Natürlich geschieht das nicht immer, aber wir stoßen trotzdem ziemlich oft auf solche Situationen.
Natürlich zerlegen wir alle Anfrageparameter und die Struktur der Cookies. Man kann beispielsweise in ein JSON-Array innerhalb der Cookies einen Wert einfügen, eine große Verschachtelung schaffen und die Website dazu bringen, völlig unnötig lange zu arbeiten.

Suchlast

Das erste, was einem beim Testen einer Website in den Sinn kommt, ist die Belastung der Datenbank, da fast jeder eine Suchfunktion hat und diese leider oft unzureichend geschützt ist. Aus irgendeinem Grund schenken Entwickler dem Thema Suche nicht genügend Aufmerksamkeit. Hier gibt es jedoch einen Hinweis – man sollte vermeiden, identische Anfragen durchzuführen, da es sonst zu Caching-Problemen kommen kann, ähnlich wie bei HTTP-Fluten.
Zufällige Anfragen an die Datenbank sind ebenfalls nicht immer effizient. Es ist viel besser, eine Liste von Schlüsselwörtern zu erstellen, die sich auf die Suche beziehen. Wenn wir zum Beispiel einen Online-Shop betrachten: Angenommen, die Website verkauft Autoreifen und ermöglicht die Eingabe von Reifengröße, Fahrzeugtyp und anderen Parametern. Entsprechend werden Kombinationen relevanter Wörter die Datenbank unter viel komplexeren Bedingungen arbeiten lassen.
Außerdem sollte man Paginierung verwenden: Es ist für die Suche viel schwieriger, die vorletzte Seite der Ergebnisse anzuzeigen als die erste. Durch Paginierung kann die Last daher etwas variieren.
Im folgenden Beispiel zeigen wir die Belastung der Suchanfrage. Es ist zu sehen, dass die Website bereits ab der ersten Sekunde des Tests mit zehn Anfragen pro Sekunde nicht mehr reagierte.

Kein Ergebnis gefunden?

Wenn kein Ergebnis gefunden wird, bedeutet das nicht, dass die Seite keine anderen verwundbaren Eingabefelder enthält. Ein solches Feld könnte die Authentifizierung sein. Aktuelle Entwickler neigen dazu, komplexe Hashes zu verwenden, um die Datenbank der Anmeldungen vor Angriffen durch Regenbogentabellen zu schützen. Das ist zwar gut, jedoch verbrauchen solche Hashes große CPU-Ressourcen. Ein hohes Aufkommen falscher Anmeldungen kann zu einer Überlastung der CPU führen, was zur Folge hat, dass die Webseite nicht mehr funktioniert.
Das Vorhandensein verschiedenster Formulare für Kommentare und Feedback auf der Webseite ist ein Anlass, um sehr große Texte zu senden oder einfach massiven Spam zu erzeugen. Oft akzeptieren Webseiten auch angehängte Dateien, einschließlich im gzip-Format. In diesem Fall nehmen wir eine Datei mit einem Volumen von 1 TB, komprimieren sie mit gzip auf einige Byte oder Kilobyte und senden sie an die Webseite. Anschließend wird sie dekomprimiert und es entsteht ein sehr interessantes Ergebnis.

Rest API

Ich möchte etwas Aufmerksamkeit auf die derzeit beliebten Dienste wie Rest API lenken. Es ist viel schwieriger, eine Rest API zu schützen als eine herkömmliche Webseite. Für Rest APIs funktionieren sogar einfache Schutzmaßnahmen gegen Passwortangriffe und andere illegitime Aktivitäten nicht.
REST-APIs sind anfällig für Störungen, da sie direkt mit der Datenbank kommunizieren. Ein Ausfall solch eines Services kann erhebliche Konsequenzen für das Geschäft nach sich ziehen. Oft sind REST-APIs nicht nur für die Hauptwebsite, sondern auch für mobile Anwendungen und interne Geschäftsressourcen verantwortlich. Wenn diese Systeme ausfallen, ist der Effekt weitaus gravierender als bei einem einfachen Website-Ausfall.

Last auf schweren Inhalten

Wenn wir aufgefordert werden, ein einfaches Einseiter-Programm, eine Landingpage oder eine Visitenkarte zu testen, die keine komplexe Funktionalität aufweisen, suchen wir nach schweren Inhalten. Dazu gehören große Bilder, die der Server liefert, Binärdateien, PDF-Dokumentationen – wir versuchen, alles herunterzuladen. Solche Tests belasten das Dateisystem stark und überlasten die Kanäle, weshalb sie effektiv sind. Selbst wenn Sie den Server nicht herunterfahren, indem Sie eine große Datei mit niedrigen Geschwindigkeiten herunterladen, blockieren Sie einfach den Kanal des Zielservers, was zu einem Dienstverweigerungsangriff führen kann.
Bei einem solchen Test ist deutlich zu sehen, dass die Website bei 30 RPS aufgehört hat zu reagieren oder 500er Serverfehler ausgegeben hat.

Vergessen Sie nicht die Serverkonfiguration. Häufig sieht man, dass jemand eine virtuelle Maschine gekauft hat, Apache installiert und alles auf die Standardeinstellungen gesetzt hat, sein PHP-Anwendung platziert hat und weiter unten das Ergebnis sehen kann.

Hier lag die Last bei nur 10 RPS. Wir haben 5 Minuten gewartet, und der Server ist abgestürzt. Bis jetzt bleibt unklar, warum er abgestürzt ist, aber es gibt die Vermutung, dass er einfach zu viel Speicher verbraucht hat und deshalb nicht mehr reagierte.

Wellenbasiert

In den letzten ein bis zwei Jahren sind wellenbasierte Angriffe ziemlich populär geworden. Dies liegt daran, dass viele Organisationen Hardware zum Schutz vor DDoS-Angriffen kaufen, die eine gewisse Zeit benötigt, um Statistiken zu sammeln, bevor sie mit der Filterung der Angriffe beginnen. Das heißt, sie filtern die Angriffe in den ersten 30-40 Sekunden nicht, weil sie Daten sammeln und lernen. In diesen 30-40 Sekunden kann man also so viele Anfragen an die Website senden, dass der Dienst längere Zeit nicht verfügbar ist, während alle Anfragen bearbeitet werden.
Im Falle des Angriffs gab es einen Intervall von 10 Minuten, nach dem eine neue, modifizierte Angriffswelle eintraf.

Das bedeutet, dass der Schutz trainiert wurde, die Filterung gestartet ist, aber eine neue, völlig andere Angriffswelle aufgetreten ist, und der Schutz wieder mit dem Training begonnen hat. Tatsächlich hört die Filterung auf zu funktionieren, der Schutz wird ineffektiv und die Website ist nicht erreichbar.
Wellenangriffe zeichnen sich durch sehr hohe Werte an den Spitzen aus, sie können bis zu hunderttausend oder eine Million Anfragen pro Sekunde erreichen, im Fall von L7. Bei L3&4 können mehrere Hundert Gigabit an Traffic oder entsprechend mehrere hundert Mpps gemessen werden, wenn man in Paketen rechnet.
Das Problem solcher Angriffe liegt in der Synchronisation. Die Angriffe erfolgen aus einem Botnetz, und um einen sehr großen einmaligen Peak zu erzeugen, ist eine hohe Grad der Synchronisation erforderlich. Diese Koordination gelingt nicht immer: Manchmal entsteht ein parabolischer Peak, der ziemlich mickrig aussieht.

Nicht nur HTTP

Neben HTTP auf L7-Ebene nutzen wir gerne auch andere Protokolle. In der Regel sind bei einer herkömmlichen Website, besonders bei normalem Hosting, die E-Mail-Protokolle und MySQL nach außen hin sichtbar. E-Mail-Protokolle sind weniger anfällig für Lasten als Datenbanken, jedoch können sie ebenfalls relativ effektiv belastet werden, was zu einer hohen CPU-Auslastung auf dem Server führt.
Wir haben durchaus Erfolge erzielt, indem wir die SSH-Schwachstelle von 2016 ausnutzten. Diese Schwachstelle ist mittlerweile bei den meisten behoben, aber das bedeutet nicht, dass SSH nicht belastet werden kann. Das ist möglich. Es wird einfach eine enorme Last an Authentifizierungen erzeugt, wodurch SSH fast die gesamte CPU auf dem Server in Anspruch nimmt. Infolgedessen kann die Website bereits bei ein oder zwei Anfragen pro Sekunde zusammenbrechen. Diese ein oder zwei Anfragen lassen sich in den Logs nicht von legitimem Traffic unterscheiden.
Es bleiben viele Verbindungen aktiv, die wir auf den Servern öffnen. Früher war dies ein Problem bei Apache, und jetzt betrifft es tatsächlich auch nginx, da es häufig standardmäßig konfiguriert wird. Die Anzahl der Verbindungen, die nginx offenhalten kann, ist begrenzt; entsprechend können wir diese Anzahl an Verbindungen öffnen, und eine neue Verbindung wird von nginx nicht mehr angenommen, was dazu führt, dass die Website nicht funktioniert.
Unser Testcluster verfügt über genügend CPU, um den SSL-Handshake zu attackieren. Praktisch gesehen machen Botnets das gelegentlich auch. Auf der einen Seite ist klar, dass man nicht auf SSL verzichten kann, da es für das Google-Ranking und die Sicherheit entscheidend ist. Auf der anderen Seite hat SSL leider ein Problem mit der CPU.

L3&4

Wenn wir von Angriffen auf den L3&4-Ebenen sprechen, reden wir in der Regel von Angriffen auf der Ebene des Kanals. Solche Lasten sind fast immer von legitimen Lasten unterscheidbar, es sei denn, es handelt sich um einen SYN-Flood-Angriff. Das Problem von SYN-Flood-Angriffen für Schutzmaßnahmen liegt im hohen Volumen. Die maximale Größe bei L3&4 lag bei 1,5-2 Tbit/s. Solcher Traffic ist selbst für große Unternehmen, einschließlich Oracle und Google, sehr schwierig zu verarbeiten.
SYN und SYN-ACK sind Pakete, die zur Herstellung einer Verbindung verwendet werden. Daher ist es schwierig, SYN-Flooding von legitimen Lasten zu unterscheiden: Es ist unklar, ob es sich um ein SYN handelt, das zur Verbindungsherstellung gesendet wurde, oder um einen Teil des Floodings.

UDP-Flood

In der Regel haben Angreifer nicht die Ressourcen, die wir haben. Daher kann zur Durchführung von Angriffen eine Amplifikation verwendet werden. Das bedeutet, dass der Angreifer das Internet scannt und anfällige oder falsch konfigurierte Server findet, die beispielsweise auf ein SYN-Paket mit drei SYN-ACK antworten. Durch das Fälschen der Quelladresse des Zielservers kann man mit einem einzigen Paket die Leistung, sagen wir, verdreifachen und den Datenverkehr auf das Opfer umleiten.

Das Problem der Amplifikation liegt in ihrer schwierigen Erkennung. Ein aktuelles Beispiel ist der viel beachtete Fall mit dem anfälligen Memcached. Zudem gibt es jetzt viele IoT-Geräte, IP-Kameras, die ebenfalls meist standardmäßig falsch konfiguriert sind. Daher nutzen Angreifer häufig diese Geräte für ihre Angriffe.

Schwieriges SYN-Flood

SYN-Flood ist wahrscheinlich die interessanteste Art von Angriffen aus der Sicht eines Entwicklers. Das Problem ist, dass Systemadministratoren oft IP-Blocking zur Verteidigung verwenden. Dabei sind nicht nur die Administratoren betroffen, die gemäß Skripten handeln, sondern bedauerlicherweise auch einige teure Sicherheitssysteme.
Diese Methode kann katastrophal enden, denn wenn Angreifer sich als andere ausgeben, IP-Adressen, könnte das Unternehmen sein eigenes Subnetz blockieren. Wenn die Firewall das eigene Cluster blockiert, kommen externe Interaktionen zum Erliegen, und die Ressource bricht zusammen.
Es ist gar nicht so schwer, die eigene Netzwerkblockade zu erreichen. Wenn im Büro des Kunden ein WLAN-Netzwerk vorhanden ist oder die Funktionsfähigkeit der Ressourcen durch verschiedene Monitoring-Systeme überwacht wird, nehmen wir die IP-Adresse dieses Monitoring-Systems oder des Büro-WLANs und verwenden sie als Quelle. Das Ergebnis scheint zwar zugänglich zu sein, aber die Ziel-IP-Adressen sind blockiert. So könnte das WLAN-Netzwerk der HighLoad-Konferenz, auf der das neue Produkt des Unternehmens präsentiert wird, blockiert werden – und das hat bestimmte geschäftliche und wirtschaftliche Kosten zur Folge.
Während der Tests können wir keine Amplifikation über Memcached mit externen Ressourcen nutzen, da es Vereinbarungen gibt, den Traffic nur an genehmigte IP-Adressen weiterzuleiten. Folglich verwenden wir Amplifikation durch SYN und SYN-ACK, wobei das System auf das Senden eines SYN mit zwei bis drei SYN-ACK reagiert, wodurch sich die Attacke zwei- bis dreimal potenziert.

Werkzeuge

Eines der Hauptwerkzeuge, das wir zur Lastgenerierung auf L7-Ebene verwenden, ist Yandex-tank. Insbesondere wird als Waffe ein Phantom eingesetzt, zusätzlich gibt es mehrere Skripte zur Generierung von Munition und zur Analyse der Ergebnisse.
Für die Analyse des Netzwerkverkehrs verwenden wir Tcpdump, für die Serveranalyse — Nmap. Zur Erzeugung von Last auf L3&4-Ebene nutzen wir OpenSSL und etwas eigene Magie mit der DPDK-Bibliothek. DPDK ist eine Bibliothek von Intel, die es ermöglicht, direkt mit dem Netzwerk-Interface zu arbeiten, ohne den Linux-Stack zu durchlaufen, was die Effizienz steigert. Natürlich verwenden wir DPDK nicht nur auf L3&4, sondern auch auf L7, da sie es ermöglicht, sehr hohe Lastströme von mehreren Millionen Anfragen pro Sekunde von einer Maschine aus zu erzeugen.
Wir verwenden auch spezielle Traffic-Generatoren und Tools, die wir für spezifische Tests entwickeln. Wenn wir an die SSH-Sicherheitsanfälligkeit denken, kann diese mit dem oben genannten Satz nicht ausgenutzt werden. Wenn wir das E-Mail-Protokoll angreifen, verwenden wir entweder E-Mail-Utilities oder schreiben einfach Skripte für diese.

Fazit

Zusammenfassend möchten wir Folgendes sagen:

• Neben klassischem Lasttesting sollte unbedingt auch Stresstesting durchgeführt werden. Wir haben ein konkretes Beispiel, bei dem ein Subunternehmer des Partners nur Lasttests durchgeführt hat. Diese zeigten, dass die Ressource die normale Last bewältigen kann. Doch dann trat eine atypische Last auf, und die Besucher der Website nutzten die Ressource etwas anders – und schließlich fiel der Subunternehmer aus. Daher ist es wichtig, nach Sicherheitsanfälligkeiten zu suchen, selbst wenn Sie bereits gegen DDoS-Angriffe geschützt sind.
• Es ist notwendig, bestimmte Teile des Systems voneinander zu isolieren. Wenn Sie eine Suche haben, sollte diese auf separate Maschinen verlagert werden, also nicht einmal in Docker. Denn wenn die Suche oder Authentifizierung ausfällt, funktioniert zumindest noch etwas. Bei einem Onlineshop können die Nutzer weiterhin Produkte über den Katalog finden, von Aggregatoren kommen, Käufe tätigen, wenn sie bereits authentifiziert sind, oder sich über OAuth2 anmelden.
• Vernachlässigen Sie nicht die Möglichkeiten von Cloud-Diensten.
• Verwenden Sie ein CDN nicht nur zur Optimierung von Netzwerklatenzen, sondern auch als Schutzmaßnahme gegen Abreissattacken und einfaches Spam in der Statik.
• Es ist wichtig, spezialisierte Schutzdienste zu nutzen. Gegen L3&4-Attacken auf der Kanalschicht können Sie sich selbst nicht schützen, da Sie wahrscheinlich einfach nicht über genügend Bandbreite verfügen. Auch gegen L7-Attacken werden Sie wahrscheinlich nicht bestehen können, da diese sehr groß sein können. Darüber hinaus ist die Erkennung kleiner Angriffe das Fachgebiet spezieller Dienste und Algorithmen.
• Halten Sie Ihre Systeme regelmäßig auf dem neuesten Stand. Dies betrifft nicht nur den Kernel, sondern auch den SSH-Daemon, insbesondere wenn dieser nach außen geöffnet ist. Im Grunde sollten Sie alles aktualisieren, denn es wird Ihnen schwerfallen, die neuesten Schwachstellen selbstständig zu verfolgen.

Quelle: habr.com