DDoS zur Rettung: So führen wir Stress- und Belastungstests durch

Variti entwickelt Schutzmaßnahmen gegen Bots und DDoS-Angriffe und führt zudem Stress- und Belastungstests durch. Auf der Konferenz HighLoad++ 2018 haben wir darüber gesprochen, wie man Ressourcen vor verschiedenen Arten von Angriffen schützt. Kurz gesagt: Teile des Systems isolieren, Cloud-Dienste und CDNs nutzen und regelmäßig aktualisieren. Aber ohne spezialisierte Unternehmen werden Sie den Schutz trotzdem nicht bewältigen können :)

Bevor Sie den Text lesen, können Sie die kurzen Zusammenfassungen lesen auf der Konferenzwebsite.
Und wer nicht gerne liest oder einfach nur das Video anschauen möchte, findet die Aufzeichnung unseres Berichts weiter unten unter dem Spoiler.

Videoaufzeichnung des Berichts

Viele Unternehmen wissen bereits, wie man Lasttests durchführt, aber nicht alle führen Stresstests durch. Einige unserer Kunden denken, dass ihre Website unverwundbar ist, weil sie über ein hoch ausgelastetes System verfügen und es gut vor Angriffen schützt. Wir zeigen, dass dies nicht ganz stimmt.
Selbstverständlich holen wir vor der Durchführung von Tests die unterschriebene und gestempelte Erlaubnis des Kunden ein und mit unserer Hilfe kann ein DDoS-Angriff auf niemanden durchgeführt werden. Die Tests werden zu einem vom Kunden gewählten Zeitpunkt durchgeführt, wenn der Verkehr zu seiner Ressource minimal ist und Zugriffsprobleme keine Auswirkungen auf die Kunden haben. Da bei der Prüfung immer etwas schief gehen kann, stehen wir darüber hinaus im ständigen Kontakt mit dem Kunden. Dadurch können Sie nicht nur die erzielten Ergebnisse melden, sondern auch während des Tests etwas ändern. Nach Abschluss der Tests erstellen wir stets einen Bericht, in dem wir auf die festgestellten Mängel hinweisen und Empfehlungen zur Beseitigung der Schwachstellen der Website geben.

Wie wir arbeiten

Beim Testen emulieren wir ein Botnetz. Da wir mit Clients arbeiten, die sich nicht in unseren Netzwerken befinden, liefern wir die Last nicht von einer IP, sondern aus unserem eigenen Subnetz, um sicherzustellen, dass der Test nicht in der ersten Minute aufgrund von Limits oder Schutzauslösungen endet. Um eine erhebliche Auslastung zu erzielen, verfügen wir außerdem über einen eigenen, ziemlich leistungsstarken Testserver.

Postulate

Zu viel bedeutet nicht gut
Je weniger Last wir eine Ressource zum Scheitern bringen können, desto besser. Wenn Sie dafür sorgen können, dass die Website bei einer Anfrage pro Sekunde oder sogar einer Anfrage pro Minute nicht mehr funktioniert, ist das großartig. Denn nach dem Gesetz der Gemeinheit geraten Benutzer oder Angreifer versehentlich in diese besondere Sicherheitslücke.

Ein teilweiser Ausfall ist besser als ein vollständiger Ausfall
Wir empfehlen immer, Systeme heterogen zu gestalten. Darüber hinaus lohnt es sich, sie auf physischer Ebene zu trennen und nicht nur durch Containerisierung. Im Falle einer physischen Trennung besteht eine hohe Wahrscheinlichkeit, dass die Website auch dann nicht vollständig funktioniert, wenn etwas auf der Website ausfällt und die Benutzer weiterhin Zugriff auf zumindest einen Teil der Funktionalität haben.

Gute Architektur ist die Basis für Nachhaltigkeit
Die Fehlertoleranz einer Ressource und ihre Fähigkeit, Angriffen und Belastungen standzuhalten, sollten bereits in der Entwurfsphase festgelegt werden, und zwar bereits in der Phase, in der die ersten Flussdiagramme in ein Notizbuch gezeichnet werden. Denn wenn sich fatale Fehler einschleichen, ist eine Korrektur in Zukunft zwar möglich, aber sehr schwierig.

Nicht nur der Code sollte gut sein, sondern auch die Konfiguration
Viele Leute denken, dass ein gutes Entwicklungsteam ein Garant für einen fehlertoleranten Service ist. Ein gutes Entwicklungsteam ist wirklich notwendig, aber es muss auch gute Abläufe und gute DevOps geben. Das heißt, wir brauchen Spezialisten, die Linux und das Netzwerk richtig konfigurieren, Konfigurationen richtig in Nginx schreiben, Grenzwerte festlegen usw. Andernfalls funktioniert die Ressource nur beim Testen gut und irgendwann wird in der Produktion alles kaputt gehen.

Unterschiede zwischen Belastungs- und Stresstests
Durch Lasttests können Sie die Grenzen der Systemfunktion ermitteln. Stresstests zielen darauf ab, Schwachstellen in einem System zu finden und werden verwendet, um dieses System zu zerstören und zu sehen, wie es sich im Prozess des Ausfalls bestimmter Teile verhält. In diesem Fall bleibt dem Kunden vor Beginn des Stresstests in der Regel die Art der Belastung unbekannt.

Besonderheiten von L7-Angriffen

Normalerweise unterteilen wir die Lastarten in Lasten auf den Ebenen L7 und L3&4. L7 ist eine Last auf Anwendungsebene, meistens bedeutet es nur HTTP, aber wir meinen jede Last auf der TCP-Protokollebene.
L7-Angriffe weisen bestimmte Besonderheiten auf. Erstens kommen sie direkt in die Anwendung, das heißt, es ist unwahrscheinlich, dass sie über Netzwerkmittel reflektiert werden. Solche Angriffe nutzen Logik und verbrauchen daher CPU, Speicher, Festplatte, Datenbank und andere Ressourcen sehr effizient und mit wenig Datenverkehr.

HTTP-Flood

Bei jedem Angriff ist es einfacher, die Last zu erzeugen als zu bewältigen, und das gilt auch für L7. Es ist nicht immer einfach, Angriffsverkehr von legitimem Verkehr zu unterscheiden, und meistens kann dies anhand der Häufigkeit erfolgen, aber wenn alles richtig geplant ist, ist es unmöglich, anhand der Protokolle zu erkennen, wo der Angriff stattfindet und wo sich die legitimen Anfragen befinden.
Betrachten Sie als erstes Beispiel einen HTTP-Flood-Angriff. Die Grafik zeigt, dass solche Angriffe in der Regel sehr leistungsstark sind; im Beispiel unten lag die Spitzenzahl der Anfragen bei über 600 pro Minute.

HTTP Flood ist der einfachste Weg, Last zu erzeugen. Normalerweise benötigt es ein Lasttest-Tool wie ApacheBench und legt eine Anforderung und ein Ziel fest. Bei einem so einfachen Ansatz besteht eine hohe Wahrscheinlichkeit, dass es zum Server-Caching kommt, es lässt sich aber leicht umgehen. Fügen Sie der Anfrage beispielsweise zufällige Zeichenfolgen hinzu, wodurch der Server gezwungen wird, ständig eine neue Seite bereitzustellen.
Vergessen Sie beim Erstellen einer Last auch nicht den Benutzeragenten. Viele Benutzeragenten beliebter Testtools werden von Systemadministratoren gefiltert, und in diesem Fall erreicht die Last möglicherweise einfach nicht das Backend. Sie können das Ergebnis deutlich verbessern, indem Sie einen mehr oder weniger gültigen Header aus dem Browser in die Anfrage einfügen.
So einfach HTTP-Flood-Angriffe auch sind, sie haben auch ihre Nachteile. Erstens sind große Energiemengen erforderlich, um die Last zu erzeugen. Zweitens sind solche Angriffe sehr leicht zu erkennen, insbesondere wenn sie von einer Adresse ausgehen. Dadurch werden Anfragen sofort entweder von Systemadministratoren oder sogar auf Anbieterebene gefiltert.

Worauf zu achten ist

Um die Anzahl der Anfragen pro Sekunde zu reduzieren, ohne an Effizienz zu verlieren, müssen Sie ein wenig Fantasie zeigen und die Website erkunden. Somit können Sie nicht nur den Kanal oder Server laden, sondern auch einzelne Teile der Anwendung, beispielsweise Datenbanken oder Dateisysteme. Sie können auf der Website auch nach Stellen suchen, an denen umfangreiche Berechnungen durchgeführt werden: Taschenrechner, Produktauswahlseiten usw. Schließlich kommt es häufig vor, dass die Site über eine Art PHP-Skript verfügt, das eine Seite mit mehreren hunderttausend Zeilen generiert. Ein solches Skript belastet zudem den Server erheblich und kann zum Ziel eines Angriffs werden.

Wo soll ich suchen?

Wenn wir eine Ressource vor dem Testen scannen, schauen wir uns natürlich zuerst die Site selbst an. Wir suchen nach Eingabefeldern aller Art, umfangreichen Dateien – im Allgemeinen nach allem, was der Ressource Probleme bereiten und ihren Betrieb verlangsamen kann. Hier helfen banale Entwicklungstools in Google Chrome und Firefox, die Seitenreaktionszeiten anzeigen.
Wir scannen auch Subdomains. Beispielsweise gibt es einen bestimmten Online-Shop, abc.com, und dieser hat eine Subdomain admin.abc.com. Höchstwahrscheinlich handelt es sich hierbei um ein Admin-Panel mit Autorisierung, aber wenn Sie es überlasten, kann es zu Problemen für die Hauptressource kommen.
Die Website verfügt möglicherweise über eine Subdomain api.abc.com. Höchstwahrscheinlich handelt es sich hierbei um eine Ressource für mobile Anwendungen. Sie können die Anwendung im App Store oder bei Google Play finden, einen speziellen Zugangspunkt installieren, die API analysieren und Testkonten registrieren. Das Problem besteht darin, dass die Leute oft denken, dass alles, was durch Autorisierung geschützt ist, immun gegen Denial-of-Service-Angriffe ist. Angeblich ist die Autorisierung das beste CAPTCHA, aber das ist nicht der Fall. Es ist einfach, 10 bis 20 Testkonten zu erstellen, aber durch deren Erstellung erhalten wir Zugriff auf komplexe und unverhüllte Funktionen.
Natürlich schauen wir uns den Verlauf, robots.txt und WebArchive, ViewDNS an und suchen nach alten Versionen der Ressource. Manchmal kommt es vor, dass Entwickler beispielsweise mail2.yandex.net eingeführt haben, die alte Version, mail.yandex.net, jedoch bestehen bleibt. Dieses mail.yandex.net wird nicht mehr unterstützt, ihm werden keine Entwicklungsressourcen zugewiesen, aber es verbraucht weiterhin die Datenbank. Dementsprechend können Sie mit der alten Version die Ressourcen des Backends und alles, was sich hinter dem Layout verbirgt, effektiv nutzen. Natürlich ist das nicht immer der Fall, aber dennoch kommt es bei uns recht häufig vor.
Selbstverständlich analysieren wir alle Anfrageparameter und die Cookie-Struktur. Sie können beispielsweise einen Wert in einem JSON-Array innerhalb eines Cookies ablegen, viele Verschachtelungen erzeugen und dafür sorgen, dass die Ressource unangemessen lange arbeitet.

Suchlast

Das erste, was einem bei der Recherche auf einer Website in den Sinn kommt, ist das Laden der Datenbank, da fast jeder über eine Suche verfügt und diese leider für fast jeden schlecht geschützt ist. Aus irgendeinem Grund schenken Entwickler der Suche nicht genügend Aufmerksamkeit. Hier gibt es jedoch eine Empfehlung: Sie sollten keine Anfragen desselben Typs stellen, da es zu Caching kommen kann, wie es bei HTTP-Flood der Fall ist.
Auch zufällige Abfragen der Datenbank sind nicht immer effektiv. Es ist viel besser, eine Liste mit Schlüsselwörtern zu erstellen, die für die Suche relevant sind. Kehren wir zum Beispiel eines Online-Shops zurück: Nehmen wir an, die Website verkauft Autoreifen und ermöglicht Ihnen die Einstellung des Reifenradius, des Fahrzeugtyps und anderer Parameter. Dementsprechend zwingen Kombinationen relevanter Wörter die Datenbank dazu, unter viel komplexeren Bedingungen zu arbeiten.
Darüber hinaus lohnt es sich, die Paginierung zu verwenden: Es ist viel schwieriger, bei einer Suche die vorletzte Seite der Suchergebnisse zurückzugeben als die erste. Das heißt, mit Hilfe der Paginierung können Sie die Last leicht diversifizieren.
Das folgende Beispiel zeigt die Suchlast. Es ist ersichtlich, dass die Website ab der ersten Sekunde des Tests mit einer Geschwindigkeit von zehn Anfragen pro Sekunde ausfiel und nicht reagierte.

Gibt es keine Suche?

Wenn keine Suche erfolgt, bedeutet dies nicht, dass die Site keine anderen anfälligen Eingabefelder enthält. Dieses Feld kann eine Autorisierung sein. Heutzutage erstellen Entwickler gerne komplexe Hashes, um die Anmeldedatenbank vor einem Rainbow-Table-Angriff zu schützen. Das ist gut, aber solche Hashes verbrauchen viele CPU-Ressourcen. Ein großer Strom falscher Autorisierungen führt zu einem Prozessorausfall und in der Folge dazu, dass die Website nicht mehr funktioniert.
Das Vorhandensein aller Arten von Formularen für Kommentare und Feedback auf der Website ist ein Grund, sehr große Texte dorthin zu senden oder einfach eine riesige Flut zu erzeugen. Manchmal akzeptieren Websites angehängte Dateien, auch im GZIP-Format. In diesem Fall nehmen wir eine 1-TB-Datei, komprimieren sie mit gzip auf mehrere Bytes oder Kilobytes und senden sie an die Site. Dann wird es entpackt und es entsteht ein sehr interessanter Effekt.

Rest API

Ich möchte so beliebten Diensten wie der Rest-API ein wenig Aufmerksamkeit schenken. Die Sicherung einer Rest-API ist viel schwieriger als die einer normalen Website. Selbst triviale Methoden zum Schutz vor Passwort-Brute-Force und anderen illegalen Aktivitäten funktionieren für die Rest-API nicht.
Die Rest-API ist sehr leicht zu knacken, da sie direkt auf die Datenbank zugreift. Gleichzeitig hat der Ausfall eines solchen Dienstes durchaus schwerwiegende Folgen für das Unternehmen. Tatsache ist, dass die Rest-API normalerweise nicht nur für die Hauptwebsite, sondern auch für die mobile Anwendung und einige interne Geschäftsressourcen verwendet wird. Und wenn das alles scheitert, dann ist der Effekt viel stärker als bei einem einfachen Website-Ausfall.

Es werden umfangreiche Inhalte geladen

Wenn uns angeboten wird, eine gewöhnliche Single-Page-Anwendung, Landingpage oder Visitenkarten-Website zu testen, die nicht über komplexe Funktionen verfügt, suchen wir nach umfangreichen Inhalten. Zum Beispiel große Bilder, die der Server sendet, Binärdateien, PDF-Dokumentation – wir versuchen, all das herunterzuladen. Solche Tests belasten das Dateisystem gut, verstopfen Kanäle und sind daher effektiv. Das heißt, selbst wenn Sie den Server nicht herunterfahren und eine große Datei mit niedriger Geschwindigkeit herunterladen, verstopfen Sie lediglich den Kanal des Zielservers und es kommt dann zu einem Denial-of-Service.
Ein Beispiel für einen solchen Test zeigt, dass die Site bei einer Geschwindigkeit von 30 RPS nicht mehr reagierte oder 500. Serverfehler verursachte.

Vergessen Sie nicht, Server einzurichten. Sie können oft feststellen, dass eine Person eine virtuelle Maschine gekauft, dort Apache installiert, alles standardmäßig konfiguriert, eine PHP-Anwendung installiert hat und unten das Ergebnis sehen kann.

Hier ging die Last bis zur Wurzel und betrug nur 10 RPS. Wir haben 5 Minuten gewartet und der Server ist abgestürzt. Zwar ist nicht vollständig geklärt, warum er gestürzt ist, es besteht jedoch die Vermutung, dass er einfach zu viel Gedächtnis hatte und deshalb nicht mehr reagierte.

Wellenbasiert

In den letzten ein bis zwei Jahren erfreuen sich Wellenangriffe großer Beliebtheit. Dies ist auf die Tatsache zurückzuführen, dass viele Unternehmen bestimmte Hardwareteile für den DDoS-Schutz kaufen, die eine gewisse Zeit benötigen, um Statistiken zu sammeln und mit der Filterung des Angriffs zu beginnen. Das heißt, sie filtern den Angriff nicht in den ersten 30–40 Sekunden, da sie Daten sammeln und lernen. Dementsprechend können Sie in diesen 30-40 Sekunden so viel auf der Site starten, dass die Ressource lange liegen bleibt, bis alle Anfragen geklärt sind.
Im Fall des unten aufgeführten Angriffs gab es eine Pause von 10 Minuten, nach der ein neuer, modifizierter Teil des Angriffs eintraf.

Das heißt, die Verteidigung lernte, fing an zu filtern, aber es kam ein neuer, völlig anderer Teil des Angriffs, und die Verteidigung begann erneut zu lernen. Tatsächlich funktioniert die Filterung nicht mehr, der Schutz wird unwirksam und die Website ist nicht verfügbar.
Wave-Angriffe zeichnen sich durch sehr hohe Spitzenwerte aus, sie können im Fall von L7 einhunderttausend oder eine Million Anfragen pro Sekunde erreichen. Wenn wir über L3 und 4 sprechen, kann es Hunderte von Gigabit an Datenverkehr geben, bzw. Hunderte von Mpps, wenn man die Pakete zählt.
Das Problem bei solchen Angriffen ist die Synchronisation. Die Angriffe kommen von einem Botnetz und erfordern ein hohes Maß an Synchronisierung, um eine sehr große einmalige Spitze zu erzeugen. Und diese Koordination funktioniert nicht immer: Manchmal ist das Ergebnis eine Art parabolischer Peak, der ziemlich erbärmlich aussieht.

Nicht nur HTTP

Neben HTTP nutzen wir bei L7 gerne auch andere Protokolle. In der Regel ragen bei einer regulären Website, insbesondere bei einem regulären Hosting, Mail-Protokolle und MySQL heraus. Mail-Protokolle unterliegen einer geringeren Belastung als Datenbanken, können aber auch recht effizient geladen werden und am Ende zu einer überlasteten CPU auf dem Server führen.
Wir haben die SSH-Sicherheitslücke von 2016 recht erfolgreich ausgenutzt. Mittlerweile wurde diese Schwachstelle für fast alle behoben, was jedoch nicht bedeutet, dass die Last nicht an SSH übermittelt werden kann. Dürfen. Es gibt einfach eine riesige Menge an Berechtigungen, SSH frisst fast die gesamte CPU auf dem Server und dann bricht die Website bei ein oder zwei Anfragen pro Sekunde zusammen. Dementsprechend können diese ein oder zwei Anfragen anhand der Protokolle nicht von einer legitimen Auslastung unterschieden werden.
Auch viele Verbindungen, die wir auf Servern öffnen, bleiben relevant. Früher war Apache daran schuld, jetzt ist Nginx tatsächlich daran schuld, da es oft standardmäßig konfiguriert ist. Die Anzahl der Verbindungen, die Nginx offen halten kann, ist begrenzt. Wenn wir also diese Anzahl von Verbindungen öffnen, akzeptiert Nginx keine neue Verbindung mehr und die Site funktioniert daher nicht.
Unser Testcluster verfügt über genügend CPU, um den SSL-Handshake anzugreifen. Grundsätzlich gilt, wie die Praxis zeigt, dass Botnetze dies manchmal auch gerne tun. Einerseits ist klar, dass man auf SSL nicht verzichten kann, denn Google-Ergebnisse, Ranking, Sicherheit. Andererseits hat SSL leider ein CPU-Problem.

L3&4

Wenn wir von einem Angriff auf den Ebenen L3 und 4 sprechen, sprechen wir normalerweise von einem Angriff auf der Verbindungsebene. Eine solche Belastung ist fast immer von einer legitimen zu unterscheiden, es sei denn, es handelt sich um einen SYN-Flood-Angriff. Das Problem bei SYN-Flood-Angriffen für Sicherheitstools ist ihr großes Volumen. Der maximale L3&4-Wert betrug 1,5-2 Tbit/s. Diese Art von Datenverkehr ist selbst für große Unternehmen, darunter Oracle und Google, nur sehr schwer zu verarbeiten.
SYN und SYN-ACK sind Pakete, die beim Verbindungsaufbau verwendet werden. Daher ist SYN-Flood schwer von einer legitimen Last zu unterscheiden: Es ist nicht klar, ob es sich um ein SYN handelt, das zum Aufbau einer Verbindung gekommen ist, oder um Teil einer Flood.

UDP-Flut

Normalerweise verfügen Angreifer nicht über die Fähigkeiten, die wir haben, sodass Verstärkung zur Organisation von Angriffen genutzt werden kann. Das heißt, der Angreifer durchsucht das Internet und findet entweder anfällige oder falsch konfigurierte Server, die beispielsweise als Reaktion auf ein SYN-Paket mit drei SYN-ACKs antworten. Durch Spoofing der Quelladresse aus der Adresse des Zielservers ist es möglich, die Leistung mit einem einzigen Paket beispielsweise um das Dreifache zu erhöhen und den Datenverkehr zum Opfer umzuleiten.

Das Problem bei Verstärkungen besteht darin, dass sie schwer zu erkennen sind. Zu den jüngsten Beispielen gehört der aufsehenerregende Fall des gefährdeten Memcached. Außerdem gibt es mittlerweile viele IoT-Geräte, IP-Kameras, die meist auch standardmäßig konfiguriert sind, und zwar standardmäßig falsch, weshalb Angreifer ihre Angriffe am häufigsten über solche Geräte durchführen.

Schwierige SYN-Flut

Aus Entwicklersicht ist SYN-Flood wahrscheinlich die interessanteste Angriffsart. Das Problem besteht darin, dass Systemadministratoren häufig IP-Blockierungen zum Schutz einsetzen. Darüber hinaus betrifft die IP-Blockierung nicht nur Systemadministratoren, die mithilfe von Skripten agieren, sondern leider auch einige Sicherheitssysteme, die für viel Geld gekauft werden.
Diese Methode kann zur Katastrophe werden, denn wenn Angreifer IP-Adressen austauschen, blockiert das Unternehmen sein eigenes Subnetz. Wenn die Firewall ihren eigenen Cluster blockiert, schlägt die Ausgabe bei externen Interaktionen fehl und die Ressource schlägt fehl.
Darüber hinaus ist es nicht schwer, das eigene Netzwerk zu blockieren. Wenn das Büro des Kunden über ein Wi-Fi-Netzwerk verfügt oder die Leistung von Ressourcen mithilfe verschiedener Überwachungssysteme gemessen wird, verwenden wir die IP-Adresse dieses Überwachungssystems oder das WLAN im Büro des Kunden und verwenden sie als Quelle. Am Ende scheint die Ressource verfügbar zu sein, aber die Ziel-IP-Adressen sind blockiert. Daher kann es sein, dass das WLAN-Netzwerk der HighLoad-Konferenz, auf der das neue Produkt des Unternehmens vorgestellt wird, blockiert wird, was mit gewissen geschäftlichen und wirtschaftlichen Kosten verbunden ist.
Während des Tests können wir die Verstärkung durch Memcached nicht mit externen Ressourcen verwenden, da es Vereinbarungen gibt, den Datenverkehr nur an zulässige IP-Adressen zu senden. Dementsprechend verwenden wir die Verstärkung durch SYN und SYN-ACK, wenn das System auf das Senden eines SYN mit zwei oder drei SYN-ACKs reagiert und der Angriff am Ausgang zwei- oder dreimal multipliziert wird.

Werkzeuge

Eines der Haupttools, die wir für L7-Workloads verwenden, ist Yandex-Tank. Als Waffe wird insbesondere ein Phantom verwendet, außerdem gibt es mehrere Skripte zum Generieren von Patronen und zur Analyse der Ergebnisse.
Tcpdump wird zur Analyse des Netzwerkverkehrs und Nmap zur Analyse des Servers verwendet. Um die Last auf L3&4-Ebene zu erzeugen, werden OpenSSL und ein wenig unserer eigenen Magie mit der DPDK-Bibliothek verwendet. DPDK ist eine Bibliothek von Intel, die es Ihnen ermöglicht, mit der Netzwerkschnittstelle unter Umgehung des Linux-Stacks zu arbeiten und so die Effizienz zu steigern. Selbstverständlich nutzen wir DPDK nicht nur auf L3&4-Ebene, sondern auch auf L7-Ebene, da wir damit einen sehr hohen Lastfluss im Bereich von mehreren Millionen Anfragen pro Sekunde von einer Maschine erzeugen können.
Wir verwenden auch bestimmte Traffic-Generatoren und spezielle Tools, die wir für bestimmte Tests schreiben. Wenn wir uns an die Sicherheitslücke unter SSH erinnern, kann der oben genannte Satz nicht ausgenutzt werden. Wenn wir das Mail-Protokoll angreifen, nehmen wir Mail-Dienstprogramme oder schreiben einfach Skripte darauf.

Befund

Als Fazit möchte ich sagen:

• Zusätzlich zum klassischen Lasttest ist die Durchführung von Stresstests erforderlich. Wir haben ein reales Beispiel, bei dem der Subunternehmer eines Partners nur Belastungstests durchgeführt hat. Es zeigte sich, dass die Ressource der normalen Belastung standhält. Doch dann kam es zu einer ungewöhnlichen Belastung, die Website-Besucher begannen, die Ressource etwas anders zu nutzen, und als Folge davon gab der Subunternehmer nach. Daher lohnt es sich, nach Schwachstellen zu suchen, auch wenn Sie bereits vor DDoS-Angriffen geschützt sind.
• Es ist notwendig, einige Teile des Systems von anderen zu isolieren. Wenn Sie eine Suche haben, müssen Sie diese auf separate Maschinen verschieben, also nicht einmal auf Docker. Denn wenn die Suche oder die Autorisierung fehlschlägt, funktioniert zumindest etwas weiterhin. Im Falle eines Online-Shops finden Benutzer weiterhin Produkte im Katalog, verlassen den Aggregator, kaufen, wenn sie bereits autorisiert sind, oder autorisieren sich über OAuth2.
• Vernachlässigen Sie nicht alle Arten von Cloud-Diensten.
• Nutzen Sie CDN nicht nur zur Optimierung von Netzwerkverzögerungen, sondern auch als Schutz vor Angriffen auf Kanalauslastung und einfachem Überfluten von statischem Datenverkehr.
• Es ist notwendig, spezialisierte Schutzdienste in Anspruch zu nehmen. Sie können sich auf Kanalebene nicht vor L3- und 4-Angriffen schützen, da Sie höchstwahrscheinlich einfach nicht über einen ausreichenden Kanal verfügen. Es ist auch unwahrscheinlich, dass Sie L7-Angriffe abwehren können, da diese sehr groß sein können. Außerdem ist die Suche nach kleinen Angriffen immer noch das Vorrecht spezieller Dienste, spezieller Algorithmen.
• Regelmäßig aktualisieren. Dies gilt nicht nur für den Kernel, sondern auch für den SSH-Daemon, insbesondere wenn Sie diese nach außen geöffnet haben. Grundsätzlich muss alles aktualisiert werden, da Sie bestimmte Schwachstellen wahrscheinlich nicht alleine aufspüren können.

Source: habr.com