DDoS hilft: wie wir Stress und Stresstests durchführen

Variti entwickelt Schutz vor Bots und DDoS-Angriffen und führt auch Stress- und Lasttests durch. Auf der HighLoad ++ 2018-Konferenz haben wir darüber gesprochen, wie Ressourcen vor verschiedenen Arten von Angriffen geschützt werden können. Kurz gesagt: Isolieren Sie Teile des Systems, verwenden Sie Cloud-Dienste und CDN und aktualisieren Sie diese regelmäßig. Aber ohne spezialisierte Unternehmen kann man Schutz immer noch nicht tun :)

Bevor Sie den Text lesen, können Sie sich auf der Konferenzwebsite mit kurzen Abstracts vertraut machen.
Und wenn Sie nicht gerne lesen oder nur ein Video ansehen möchten, finden Sie die Aufzeichnung unseres Berichts unten unter dem Spoiler.


Viele Unternehmen wissen bereits, wie man Stresstests durchführt, aber nicht alle führen Stresstests durch. Einige unserer Kunden halten ihre Website für unverwundbar, da sie über ein Hochlastsystem verfügen, das vor Angriffen schützt. Wir zeigen, dass dies nicht ganz stimmt.

Natürlich erhalten wir vor der Durchführung der Tests die Erlaubnis des Kunden, unterschrieben und abgestempelt, und mit unserer Hilfe können wir niemanden mit einem DDoS-Angriff angreifen. Die Tests werden zu dem vom Kunden gewählten Zeitpunkt durchgeführt, wenn die Anwesenheit seiner Ressource minimal ist und Zugriffsprobleme den Kunden nicht betreffen. Da während des Testprozesses immer etwas schief gehen kann, haben wir außerdem ständigen Kontakt zum Kunden. Dies ermöglicht nicht nur, über die erzielten Ergebnisse zu berichten, sondern auch während des Tests etwas zu ändern. Am Ende der Tests erstellen wir immer einen Bericht, in dem wir auf die festgestellten Mängel hinweisen und Empfehlungen zur Behebung der Schwachstellen der Website geben.

Wie arbeiten wir?

Während des Testens emulieren wir ein Botnetz. Da wir mit Clients arbeiten, die sich nicht in unseren Netzwerken befinden, laden wir die Last nicht von einer IP-Adresse, sondern von unserem eigenen Subnetz, um zu verhindern, dass der Test aufgrund des Auslösens von Grenzwerten oder des Schutzes in der ersten Minute endet. Um eine erhebliche Last zu erzeugen, verfügen wir über einen eigenen, ziemlich leistungsstarken Testserver.

Postulate

Viel ist nicht gut

Je weniger Last wir die Ressource zum Ausfall bringen können, desto besser. Wenn Sie es schaffen, dass die Website aufgrund einer Anforderung pro Sekunde oder sogar aufgrund einer Anforderung pro Minute nicht mehr funktioniert, ist dies in Ordnung. Denn nach dem Gesetz der Gemeinheit fallen Benutzer oder Angreifer versehentlich in diese Sicherheitslücke.

Teilversagen ist besser als vollständiges Versagen

Wir empfehlen immer, Systeme heterogen zu machen. Darüber hinaus lohnt es sich, sie auf physischer Ebene zu trennen und nicht nur zu containerisieren. Im Falle einer physischen Trennung ist es wahrscheinlich, dass die Funktion nicht vollständig aufhört, selbst wenn auf der Site ein Fehler auftritt, und die Benutzer weiterhin Zugriff auf mindestens einen Teil der Funktionen haben.

Die richtige Architektur ist die Grundlage für Nachhaltigkeit

Die Fehlertoleranz einer Ressource und ihre Fähigkeit, Angriffen und Belastungen standzuhalten, sollten in der Entwurfsphase festgelegt werden, und zwar in der Phase des Zeichnens der ersten Blockdiagramme in einem Notizbuch. Denn wenn sich schwerwiegende Fehler einschleichen, können Sie diese in Zukunft korrigieren, dies ist jedoch sehr schwierig.

Nicht nur Code sollte gut sein, sondern auch eine Konfiguration

Viele Leute denken, dass ein gutes Entwicklungsteam eine Garantie für Service-Ausfallsicherheit ist. Ein gutes Entwicklungsteam ist wirklich notwendig, aber es muss auch einen guten Betrieb geben, gute DevOps. Das heißt, wir brauchen Spezialisten, die Linux und das Netzwerk richtig konfigurieren, Konfigurationen in Nginx richtig schreiben, Limits konfigurieren und vieles mehr. Andernfalls funktioniert die Ressource nur beim Test gut, und in der Produktion wird irgendwann alles kaputt gehen.

Unterschiede zwischen Stress und Stresstests

Mit Lasttests können Sie die Grenzen des Systems identifizieren. Stresstests zielen darauf ab, die Schwächen des Systems zu ermitteln. Sie dienen dazu, dieses System zu beschädigen und festzustellen, wie es sich beim Ausfall bestimmter Teile verhält. Gleichzeitig bleibt dem Kunden die Art der Belastung bis zum Beginn der Stresstests in der Regel unbekannt.

Besonderheiten von L7-Angriffen

Normalerweise teilen wir die Lasttypen in Lasten auf der Ebene von L7 und L3 & 4 auf. L7 ist eine Last auf Anwendungsebene, meistens wird es nur als HTTP verstanden, aber wir meinen jede Last auf TCP-Protokollebene.

L7-Angriffe weisen bestimmte Unterscheidungsmerkmale auf. Erstens kommen sie direkt zur Anwendung, das heißt, es ist unwahrscheinlich, dass sie durch Netzwerkmittel reflektiert werden können. Solche Angriffe verwenden Logik und verbrauchen daher CPU, Speicher, Festplatte, Datenbank und andere Ressourcen sehr effizient und mit wenig Verkehr.

HTTP-Flut

Im Falle eines Angriffs ist die Last einfacher zu erstellen als zu handhaben, und im Fall von L7 gilt dies auch. Angriffsverkehr ist nicht immer leicht von legitim zu unterscheiden und kann meistens nach Häufigkeit durchgeführt werden. Wenn jedoch alles richtig geplant ist, ist es unmöglich zu verstehen, wo sich der Angriff befindet und wo legitime Anforderungen aus den Protokollen stammen.

Betrachten Sie als erstes Beispiel einen HTTP-Flood-Angriff. Die Grafik zeigt, dass solche Angriffe normalerweise sehr mächtig sind. Im folgenden Beispiel hat die maximale Anzahl von Anforderungen 600.000 pro Minute überschritten.



HTTP Flood ist der einfachste Weg, eine Last zu erstellen. Normalerweise wird dafür eine Art Lasttest-Tool verwendet, z. B. ApacheBench, und die Anforderung und der Zweck werden festgelegt. Mit einem so einfachen Ansatz kann es wahrscheinlich zu Server-Caching kommen, aber es ist einfach, sich fortzubewegen. Fügen Sie der Abfrage beispielsweise zufällige Zeilen hinzu, wodurch der Server gezwungen wird, ständig eine neue Seite zu erstellen.
Vergessen Sie auch nicht, den Benutzeragenten beim Erstellen einer Last zu berücksichtigen. Viele Benutzeragenten gängiger Testtools werden von Systemadministratoren gefiltert. In diesem Fall erreicht die Last möglicherweise einfach nicht das Backend. Sie können das Ergebnis erheblich verbessern, indem Sie einen mehr oder weniger gültigen Header aus dem Browser in die Anforderung einfügen.
Bei aller Einfachheit haben HTTP-Flood-Angriffe ihre Nachteile. Erstens sind große Kapazitäten erforderlich, um eine Last zu erzeugen. Zweitens sind solche Angriffe sehr leicht zu erkennen, insbesondere wenn sie von derselben Adresse stammen. Infolgedessen werden Anforderungen sofort entweder von Systemadministratoren oder sogar auf Anbieterebene gefiltert.

Worauf zu achten ist

Um die Anzahl der Anfragen pro Sekunde zu reduzieren und dennoch nicht an Effizienz zu verlieren, müssen Sie ein wenig Fantasie zeigen und die Site erkunden. Sie können also nicht nur den Kanal oder Server laden, sondern auch einzelne Teile der Anwendung, z. B. Datenbanken oder Dateisysteme. Sie können auch nach Orten auf der Website suchen, die hervorragende Berechnungen durchführen: Taschenrechner, Produktauswahlseiten und mehr. Schließlich kommt es häufig vor, dass es auf der Site ein PHP-Skript gibt, das eine Seite mit mehreren hunderttausend Zeilen generiert. Ein solches Skript lädt auch den Server stark und kann zum Angriffsziel werden.

Wo soll man suchen?

Wenn wir eine Ressource vor dem Testen scannen, schauen wir uns natürlich zunächst die Site selbst an. Wir suchen nach allen Arten von Eingabefeldern, schweren Dateien - im Allgemeinen nach allem, was Probleme für eine Ressource verursachen und deren Betrieb verlangsamen kann. Hier zeigen gängige Entwicklungstools in Google Chrome und Firefox die Antwortzeit der Seite an.

Wir scannen auch Subdomains. Zum Beispiel gibt es einen bestimmten Online-Shop, abc.com, und er hat eine Subdomain admin.abc.com. Dies ist höchstwahrscheinlich das Admin-Panel mit Berechtigung. Wenn Sie jedoch eine Last in das Panel einfügen, kann dies zu Problemen für die Hauptressource führen.

Die Site hat möglicherweise eine Subdomain api.abc.com. Dies ist höchstwahrscheinlich eine Ressource für mobile Anwendungen. Die Anwendung kann im App Store oder bei Google Play gefunden werden, einen speziellen Zugangspunkt einrichten, die API zerlegen und Testkonten registrieren. Das Problem ist, 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 nicht. Das Erstellen von 10 bis 20 Testkonten ist einfach. Durch das Erstellen dieser Konten erhalten wir Zugriff auf komplexe und unverhüllte Funktionen.

Natürlich schauen wir uns den Verlauf an, bei robots.txt und WebArchive, ViewDNS, suchen wir nach alten Versionen der Ressource. Manchmal kommt es vor, dass die Entwickler beispielsweise mail2.yandex.net eingeführt haben, aber die alte Version mail.yandex.net blieb erhalten. Dieses mail.yandex.net wird nicht mehr unterstützt, Entwicklungsressourcen werden ihm nicht zugewiesen, es verbraucht jedoch weiterhin die Datenbank. Dementsprechend können Sie mit der alten Version die Ressourcen des Backends und alles, was sich hinter dem Layout befindet, effektiv nutzen. Das passiert natürlich nicht immer, aber so etwas begegnen wir immer noch.

Natürlich analysieren wir alle Anforderungsparameter und die Cookie-Struktur. Sie können beispielsweise einen Wert in das JSON-Array innerhalb des Cookies verschieben, mehr Verschachtelung erstellen und die Ressource unangemessen lange arbeiten lassen.

Suchlast

Das erste, was bei der Recherche einer Website in den Sinn kommt, ist das Laden der Datenbank, da fast jeder eine Suche hat und leider fast jeder schlecht geschützt ist. Aus irgendeinem Grund schenken die Entwickler der Suche nicht genügend Aufmerksamkeit. Es gibt jedoch eine Empfehlung: Stellen Sie nicht die gleiche Art von Anforderungen, da möglicherweise Caching auftritt, wie dies bei der HTTP-Flut der Fall ist.

Zufällige Abfragen in der Datenbank sind ebenfalls nicht immer effizient. Es ist viel besser, eine Liste von Schlüsselwörtern zu erstellen, die für die Suche relevant sind. Wenn Sie zum Beispiel eines Online-Shops zurückkehren: Nehmen wir an, die Website verkauft Autoreifen und ermöglicht es Ihnen, den Radius der Reifen, den Autotyp und andere Parameter festzulegen. Dementsprechend führen Kombinationen relevanter Wörter dazu, dass die Datenbank unter viel komplexeren Bedingungen funktioniert.

Darüber hinaus lohnt es sich, die Paginierung zu verwenden: Bei einer Suche ist es viel schwieriger, die vorletzte Seite eines Problems zurückzugeben als bei der ersten. Das heißt, mit Hilfe der Paginierung können Sie die Last ein wenig diversifizieren.

Im folgenden Beispiel zeigen wir die Last in der Suche. Es ist ersichtlich, dass ab der ersten Sekunde des Tests mit einer Geschwindigkeit von zehn Anfragen pro Sekunde die Site ausfiel und nicht reagierte.

Wenn es keine Suche gibt?

Wenn keine Suche durchgeführt wird, bedeutet dies nicht, dass die Site keine anderen anfälligen Eingabefelder enthält. Dieses Feld kann eine Autorisierung sein. Jetzt erstellen Entwickler gerne komplexe Hashes, um die Anmeldedatenbank vor Angriffen auf Regenbogentabellen zu schützen. Das ist gut, aber solche Hashes verbrauchen große CPU-Ressourcen. Ein großer Strom falscher Berechtigungen führt zu einem Prozessorausfall. Infolgedessen arbeitet die Site nicht mehr an der Ausgabe.

Das Vorhandensein von Formularen aller Art für Kommentare und Rückmeldungen auf der Website ist eine Gelegenheit, sehr große Texte dorthin zu senden oder einfach eine massive Flut zu erzeugen. Manchmal akzeptieren Websites Dateianhänge, auch im gzip-Format. In diesem Fall nehmen wir eine 1-TB-Datei, komprimieren sie mit gzip auf einige Bytes oder Kilobyte und senden sie an die Site. Dann wird es entpackt und ein sehr interessanter Effekt erzielt.

Rest API

Ich möchte ein wenig auf so beliebte Dienste wie die Rest-API achten. Der Schutz der Rest-API ist viel schwieriger als eine normale Site. Für die Rest-API funktionieren selbst triviale Methoden zum Schutz vor Passwort-Cracking und anderen illegitimen Aktivitäten nicht.

Die Rest-API ist sehr leicht zu brechen, da sie direkt auf die Datenbank zugreift. Gleichzeitig hat der Ausfall eines solchen Dienstes schwerwiegende Folgen für das Unternehmen. Tatsache ist, dass die Rest-API normalerweise nicht nur die Hauptwebsite, sondern auch die mobile Anwendung und einige interne Geschäftsressourcen umfasst. Und wenn all dies abfällt, ist der Effekt viel stärker als im Fall des Ausfalls einer einfachen Site.

Starke Inhaltslast

Wenn uns angeboten wird, eine gewöhnliche einseitige Anwendung, Zielseite oder Visitenkarten-Website zu testen, die keine komplexen Funktionen aufweisen, suchen wir nach umfangreichen Inhalten. Zum Beispiel große Bilder, die der Server liefert, Binärdateien, PDF-Dokumentation - wir versuchen, alles herauszupumpen. Solche Tests laden das Dateisystem gut und verstopfen die 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 einfach den Kanal des Zielservers und es kommt 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 generierte.



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



Hier ging die Last zur Wurzel und betrug nur 10 RPS. Wir haben 5 Minuten gewartet und der Server ist abgestürzt. Bis zum Ende ist jedoch nicht bekannt, warum er gefallen ist, aber es besteht die Annahme, dass er einfach voller Erinnerungen war und daher nicht mehr reagierte.

Wellenbasiert

In den letzten ein oder zwei Jahren sind Wellenangriffe sehr beliebt geworden. Dies liegt an der Tatsache, dass viele Unternehmen bestimmte Hardwarekomponenten zum Schutz vor DDoS kaufen, für die eine bestimmte Anzahl von Statistiken erforderlich ist, um Angriffe zu filtern. Das heißt, sie filtern den Angriff nicht in den ersten 30 bis 40 Sekunden, da sie Daten sammeln und lernen. Dementsprechend können Sie in diesen 30 bis 40 Sekunden so viel starten, dass die Ressource lange Zeit liegen bleibt, bis alle Anforderungen geharkt sind.

Im Falle des Angriffs gab es ein Intervall von 10 Minuten darunter, wonach ein neuer, modifizierter Teil des Angriffs eintraf.



Das heißt, die Verteidigung trainierte, begann zu filtern, aber ein neuer, völlig anderer Teil des Angriffs traf ein und die Verteidigung begann erneut zu trainieren. Tatsächlich funktioniert die Filterung nicht mehr, der Schutz wird unwirksam und die Site ist nicht mehr zugänglich.

Wellenangriffe zeichnen sich durch sehr hohe Spitzenwerte aus, sie können im Fall von L7 hunderttausend oder eine Million Anfragen pro Sekunde erreichen. Wenn wir über L3 & 4 sprechen, kann es Hunderte von Gigabit Verkehr geben, oder dementsprechend Hunderte von MPPs, wenn Sie in Paketen zählen.

Das Problem bei solchen Angriffen ist die Synchronisation. Angriffe kommen von einem Botnetz, und um einen sehr großen einmaligen Peak zu erzeugen, ist ein hoher Grad an Synchronisation erforderlich. Und diese Koordination funktioniert nicht immer: Manchmal ist die Ausgabe eine Art parabolischer Peak, der ziemlich erbärmlich aussieht.

Nicht HTTP Unified

Neben HTTP auf L7-Ebene nutzen wir gerne andere Protokolle. In der Regel sind auf einer regulären Website, insbesondere auf einem regulären Hosting, Mail-Protokolle und MySQL hervorzuheben. Mail-Protokolle sind weniger betroffen als Datenbanken, können aber auch sehr effizient geladen werden und am Ausgang eine überlastete CPU auf dem Server erhalten.

Mit Hilfe der SSH-Schwachstelle 2016 waren wir recht erfolgreich. Jetzt wurde diese Sicherheitsanfälligkeit für fast alle behoben, dies bedeutet jedoch nicht, dass SSH nicht geladen werden kann. Du kannst. Es wird nur eine große Menge an Berechtigungen bereitgestellt, SSH verbraucht fast die gesamte CPU auf dem Server, und die Website besteht bereits aus ein oder zwei Anforderungen pro Sekunde.

Dementsprechend können diese ein oder zwei Protokollabfragen nicht von einer legitimen Last unterschieden werden.
Die vielen Verbindungen, die wir auf den Servern öffnen, bleiben relevant. Früher hat Apache gesündigt, jetzt hat Nginx tatsächlich gesündigt, da es oft standardmäßig konfiguriert ist. Die Anzahl der Verbindungen, die nginx offen halten kann, ist begrenzt. Daher öffnen wir diese Anzahl von Verbindungen, die neue nginx-Verbindung wird nicht mehr akzeptiert und die Site funktioniert bei der Ausgabe nicht.

Unser Testcluster verfügt über genügend CPU, um den SSL-Handshake anzugreifen. Wie die Praxis zeigt, tun Botnets dies im Prinzip manchmal auch gerne. Einerseits ist klar, dass Sie nicht auf SSL verzichten können, da Google die Ausgabe, das Ranking und die Sicherheit von Google berücksichtigt. SSL hingegen hat leider ein CPU-Problem.

L3 & 4

Wenn wir über einen Angriff auf den Ebenen L3 und 4 sprechen, sprechen wir normalerweise über einen Angriff auf Kanalebene. Eine solche Last ist fast immer von legitim zu unterscheiden, wenn es sich nicht um einen SYN-Flutangriff handelt. Das Problem von SYN-Flood-Angriffen auf Sicherheitsfunktionen ist groß. Der Maximalwert von L3 & 4 betrug 1,5-2 Tb / s. Dieser Datenverkehr ist selbst für große Unternehmen wie Oracle und Google sehr schwierig zu handhaben.

SYN und SYN-ACK sind die Pakete, mit denen die Verbindung hergestellt wird. Daher ist es schwierig, SYN-Flood von einer legitimen Last zu unterscheiden: Es ist nicht klar, dass dies SYN ist, das die Verbindung hergestellt hat, oder ein Teil der Flood.

UDP-Flut

In der Regel verfügen Angreifer nicht über die erforderlichen Funktionen, sodass die Verstärkung zum Organisieren von Angriffen verwendet werden kann. Das heißt, ein Angreifer durchsucht das Internet und findet entweder anfällige oder nicht ordnungsgemäß konfigurierte Server, die beispielsweise als Antwort auf ein SYN-Paket mit drei SYN-ACKs antworten. Durch Fälschen der Quelladresse von der Adresse des Zielservers können Sie ein Paket verwenden, um die Kapazität beispielsweise dreimal zu erhöhen und den Datenverkehr an das Opfer umzuleiten.



Das Problem bei Verstärkungen ist ihre komplexe Erkennung. Aus den neuesten Beispielen können wir den sensationellen Fall mit dem verwundbaren Memcached zitieren. Außerdem gibt es jetzt viele IoT-Geräte, IP-Kameras, die meistens auch standardmäßig konfiguriert sind und standardmäßig falsch konfiguriert sind. Daher führen Angreifer über solche Geräte am häufigsten Angriffe durch.

Schwierige SYN-Flut

SYN-Flood ist aus Sicht des Entwicklers wahrscheinlich die interessanteste Ansicht aller Angriffe. Das Problem ist, dass Systemadministratoren häufig IP-Blockierung zum Schutz verwenden. Darüber hinaus betrifft die IP-Blockierung nicht nur Systemadministratoren, die gemäß Skripten arbeiten, sondern leider auch einige Sicherheitssysteme, die für viel Geld gekauft werden.

Diese Methode kann zu einer Katastrophe werden, denn wenn die Angreifer ihre IP-Adressen ändern, blockiert das Unternehmen sein eigenes Subnetz. Wenn die Firewall ihren eigenen Cluster blockiert, stürzen externe Interaktionen am Ausgang ab und die Ressource wird unterbrochen.

Und das Blockieren Ihres eigenen Netzwerks ist einfach. Wenn das Büro des Kunden über ein Wi-Fi-Netzwerk verfügt oder der Zustand der Ressourcen mithilfe verschiedener Überwachungen gemessen wird, verwenden wir die IP-Adresse dieses Überwachungssystems oder Office-Wi-Fi-Clients und verwenden sie als Quelle. Am Ausgang scheint die Ressource verfügbar zu sein, aber die Ziel-IP-Adressen sind blockiert. So kann das Wi-Fi-Netzwerk der HighLoad-Konferenz, in dem ein neues Produkt des Unternehmens vorgestellt wird, blockiert werden, was bestimmte geschäftliche und wirtschaftliche Kosten mit sich bringt.

Während des Testens können wir keine Verstärkung durch Memcaching durch einige externe Ressourcen verwenden, da Vereinbarungen bestehen, Datenverkehr nur an zulässige IP-Adressen zu liefern. Dementsprechend verwenden wir die Verstärkung durch SYN und SYN-ACK, wenn das System mit dem Senden von zwei oder drei SYN-ACKs zum Senden eines SYN antwortet und die Ausgabe mit dem Zwei- bis Dreifachen multipliziert wird.

Die Werkzeuge

Eines der Hauptwerkzeuge, die wir für die Ladung auf L7-Ebene verwenden, ist der Yandex-Tank. Insbesondere wird ein Phantom als Pistole verwendet, und es gibt mehrere Skripte zum Generieren von Patronen und zum Analysieren der Ergebnisse.

Tcpdump wird zur Analyse des Netzwerkverkehrs und Nmap zur Analyse des Serververkehrs verwendet. Um eine Last auf L3- und 4-Ebene zu erstellen, wird OpenSSL verwendet und mit der DPDK-Bibliothek ein wenig von seiner eigenen Magie. DPDK ist eine Bibliothek von Intel, mit der Sie mit einer Netzwerkschnittstelle arbeiten, den Linux-Stack umgehen und dadurch die Effizienz steigern können. Natürlich verwenden wir DPDK nicht nur auf L3- und 4-Ebene, sondern auch auf L7-Ebene, da Sie so einen sehr hohen Lastfluss innerhalb weniger Millionen Anfragen pro Sekunde von einer Maschine aus erstellen können.
Wir verwenden auch bestimmte Verkehrsgeneratoren und spezielle Tools, die wir für bestimmte Tests schreiben. Wenn wir uns an die Sicherheitsanfälligkeit unter SSH erinnern, kann sie mit dem oben genannten Satz nicht behoben werden. Wenn wir das Mail-Protokoll angreifen, nehmen wir Mail-Dienstprogramme oder schreiben einfach Skripte darauf.

Schlussfolgerungen

Infolgedessen möchte ich sagen:

• Neben der klassischen Belastungsprüfung müssen auch Belastungsprüfungen durchgeführt werden. Wir haben ein Beispiel aus der Praxis, bei dem ein Subunternehmer eines Partners nur Lasttests durchgeführt hat. Es zeigte sich, dass die Ressource der Standardlast standhält. Aber dann trat eine abnormale Belastung auf, die Besucher der Website begannen, die Ressource etwas anders zu nutzen, und am Ausgang legte der Subunternehmer fest. Es lohnt sich daher, nach Sicherheitslücken zu suchen, auch wenn Sie bereits vor DDoS-Angriffen geschützt sind.
• Es ist notwendig, einige Teile des Systems von anderen zu isolieren. , , . , - . - , , , , OAuth2.
• .
• CDN , .
• . L3&4 , , , . L7 , . , - , .
• . , SSH daemon, . , , .