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

Das Unternehmen Variti entwickelt Schutz gegen Bots und DDoS-Angriffe und führt auch Stress- und Lasttests durch. Auf der Konferenz HighLoad++ 2018 haben wir erzählt, wie man Ressourcen vor verschiedenen Arten von Angriffen schützt. Kurz gesagt: Isolieren Sie Teile des Systems, nutzen Sie Cloud-Dienste und CDN und aktualisieren Sie regelmäßig. Doch ohne spezialisierte Unternehmen mit Schutz werden Sie es trotzdem nicht schaffen 🙂

Vor dem Lesen des Textes können Sie sich mit kurzen Thesen vertrautmachen auf der Konferenzwebsite.
Und wenn Sie nicht gerne lesen oder einfach nur das Video ansehen möchten, ist die Aufzeichnung unseres Vortrags unten unter dem Spoiler.

Videoaufzeichnung des Vortrags

Viele Unternehmen können bereits Lasttests durchführen, aber nicht alle führen Stresstests durch. Einige unserer Kunden glauben, dass ihre Website unverwundbar ist, weil sie über ein Highload-System verfügen, das sie gut vor Angriffen schützt. Wir zeigen jedoch, dass das nicht ganz stimmt.
Natürlich holen wir vor der Durchführung von Tests die Genehmigung des Kunden mit Unterschrift und Siegel ein, und mit unserer Hilfe kann niemand einen DDoS-Angriff ausführen. Die Tests werden zu einem vom Kunden gewählten Zeitpunkt durchgeführt, wenn die Besucherzahl auf seiner Ressource minimal ist und sich Probleme mit dem Zugang nicht auf die Kunden auswirken. Darüber hinaus haben wir während der Testphase stets einen ständigen Kontakt zum Kunden. Dies ermöglicht es nicht nur, über die erzielten Ergebnisse zu berichten, sondern auch während des Tests Anpassungen vorzunehmen. Nach Abschluss der Tests erstellen wir immer einen Bericht, in dem wir auf festgestellte Mängel hinweisen und Empfehlungen zur Beseitigung von Schwachstellen der Website geben.

Wie wir arbeiten

Bei der Durchführung von Tests emulieren wir ein Botnetz. Da wir mit Kunden arbeiten, die sich nicht in unseren Netzwerken befinden, geben wir die Last nicht von einer IP-Adresse, sondern aus unserem eigenen Subnetz ab, damit der Test nicht schon in der ersten Minute wegen der Auslösung von Limits oder Schutzmaßnahmen endet. Zudem haben wir einen ausreichend leistungsstarken Testserver, um eine signifikante Last zu erzeugen.

Postulate

Viel bedeutet nicht unbedingt gut
Je geringer die Last ist, die wir benötigen, um eine Ressource zum Ausfall zu bringen, desto besser. Wenn es gelingt, die Website bei einem einzigen Anfrage pro Sekunde oder sogar pro Minute zum Stillstand zu bringen, wäre das großartig. Denn nach Murphy's Gesetz werden die Nutzer oder Angreifer genau diese Schwachstelle zufällig ansteuern.

Ein teilweiser Ausfall ist besser als ein vollständiger
Wir raten immer dazu, Systeme heterogen zu gestalten. Es ist wichtig, sie auf physischer Ebene zu trennen und nicht nur durch Containerisierung. Bei physischer Trennung, selbst wenn auf der Website etwas ausfällt, ist die Wahrscheinlichkeit groß, dass sie nicht vollständig funktionsunfähig wird, und die Nutzer Zugang zu zumindest einem Teil der Funktionalität behalten.

Die richtige Architektur ist die Grundlage der Robustheit
Die Ausfallsicherheit einer Ressource und ihre Fähigkeit, Angriffe und Lasten standzuhalten, müssen bereits in der Planungsphase eingeplant werden, tatsächlich bereits in der Phase, in der die ersten Blockdiagramme im Notizbuch gezeichnet werden. Denn wenn fatale Fehler eingeschlichen werden, können sie später zwar behoben werden, was jedoch sehr schwierig ist.

Nicht nur der Code, sondern auch die Konfiguration muss gut sein
Viele glauben, dass ein gutes Entwicklungsteam eine Garantie für die Ausfallsicherheit des Dienstes ist. Ein gutes Entwicklungsteam ist tatsächlich nötig, aber es muss auch eine gute Betriebsführung und ein gutes DevOps geben. Das bedeutet, dass Fachleute benötigt werden, die Linux und Netzwerke richtig konfigurieren, die Konfigurationen in nginx richtig schreiben, Limits einstellen und mehr. Andernfalls wird die Ressource nur im Test gut funktionieren, und in der Produktion wird irgendwann alles brechen.

Unterschiede zwischen Last- und Stresstests
Lasttests ermöglichen es, die Grenzen der Funktionalität eines Systems zu ermitteln. Stresstests sind darauf ausgerichtet, Schwachstellen im System zu finden und werden dazu verwendet, dieses System zum Absturz zu bringen und zu beobachten, wie es sich im Falle des Ausfalls bestimmter Teile verhält. Dabei bleibt die Art der Last normalerweise bis zum Beginn des Stresstests unbekannt für den Auftraggeber.

Charakteristische Merkmale von L7-Angriffen

Arten von Lasten unterteilen wir häufig in Lasten auf L7- und L3&4-Ebene. L7 ist die Last auf Anwendungsebene, meistens versteht man darunter nur HTTP, wir hingegen meinen jede Last auf Protokollebene TCP.
L7-Angriffe haben bestimmte charakteristische Merkmale. Erstens gelangen sie direkt in die Anwendung, so dass es kaum möglich ist, sie mit netzwerkbasierten Mitteln zu reflektieren. Solche Angriffe nutzen Logik aus und verbrauchen daher sehr effizient und mit geringem Datenverkehr CPU, Arbeitsspeicher, Festplatte, Datenbank und andere Ressourcen.

HTTP Flood

Im Fall eines Angriffs ist es einfacher, eine Last zu erzeugen, als sie zu verarbeiten, und das gilt auch für L7. Der Angriffsverkehr lässt sich nicht immer einfach von legitimen Anfragen unterscheiden, und häufig gelingt dies nur anhand der Frequenz. Wenn alles jedoch gut geplant ist, ist es aus den Logs unmöglich zu erkennen, wo der Angriff und wo die legitimen Anfragen sind.
Als erstes Beispiel betrachten wir einen HTTP Flood-Angriff. Aus dem Diagramm ist ersichtlich, dass solche Angriffe normalerweise sehr mächtig sind; im folgenden Beispiel überschritt die maximale Anzahl der Anfragen 600.000 pro Minute.

HTTP Flood ist der einfachste Weg, um Belastung zu erzeugen. In der Regel wird dafür ein Belastungstestwerkzeug wie ApacheBench verwendet, und eine Anfrage sowie ein Ziel werden festgelegt. Bei diesem einfachen Ansatz besteht eine hohe Wahrscheinlichkeit, auf die Server-Caching zu stoßen, aber dies lässt sich leicht umgehen. Zum Beispiel, indem man zufällige Zeichenfolgen in die Anfrage einfügt, was den Server zwingt, ständig eine frische Seite auszugeben.
Außerdem sollte man den User-Agent beim Erzeugen der Belastung nicht vergessen. Viele User-Agents beliebter Testwerkzeuge werden von Systemadministratoren gefiltert, und in solchen Fällen kommt die Last möglicherweise gar nicht bis zum Backend. Das Ergebnis kann erheblich verbessert werden, wenn man in die Anfrage einen mehr oder weniger gültigen Header eines Browsers einfügt.
Trotz der Einfachheit haben HTTP Flood-Angriffe auch ihre Nachteile. Erstens erfordert die Erstellung von Last große Ressourcen. Zweitens werden solche Angriffe sehr schnell erkannt, insbesondere wenn sie von einer Adresse ausgehen. In der Folge werden die Anfragen entweder sofort von Systemadministratoren oder sogar auf Ebene des Providers gefiltert.

Was zu suchen ist

Um die Anzahl der Anfragen pro Sekunde zu reduzieren und dabei die Effizienz nicht zu verlieren, muss man ein wenig Fantasie walten lassen und die Website erkunden. So kann man nicht nur den Kanal oder den Server belasten, sondern auch einzelne Teile der Anwendung, zum Beispiel Datenbanken oder Dateisysteme. Man kann auch nach Bereichen auf der Seite suchen, die große Berechnungen durchführen: Rechner, Seiten zur Produktauswahl usw. Schließlich kommt es häufig vor, dass auf der Website ein PHP-Skript vorhanden ist, das eine Seite aus mehreren Hunderttausend Zeilen generiert. Ein solches Skript belastet den Server ebenfalls erheblich und kann zum Ziel eines Angriffs werden.

Wo suchen

Wenn wir eine Ressource vor dem Testen scannen, schauen wir uns vor allem die Website selbst an. Wir suchen nach jeglichen Eingabefeldern, großen Dateien - kurz gesagt, allem, was Probleme für die Ressource verursachen und ihre Leistung verlangsamen könnte. Dabei helfen die einfachen Entwicklungstools in Google Chrome und Firefox, die die Antwortzeiten der Seite anzeigen.
Wir scannen auch Subdomains. Zum Beispiel gibt es einen Online-Shop, abc.com, der eine Subdomain admin.abc.com hat. Wahrscheinlich handelt es sich um das Admin-Panel mit Authentifizierung, aber wenn man dort Last erzeugt, könnte es Probleme für die Hauptressource verursachen.
Die Website könnte eine Subdomain api.abc.com haben. Wahrscheinlich ist das eine Ressource für mobile Anwendungen. Man kann die Anwendung im App Store oder bei Google Play finden, einen speziellen Zugangspunkt einrichten, die API untersuchen und Testkonten registrieren. Das Problem ist, dass viele Menschen oft denken, dass alles, was durch eine Authentifizierung geschützt ist, gegen Angriffe auf die Verfügbarkeit immun ist. Angeblich ist Authentifizierung die beste CAPTCHA, 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 ungeschützten Funktionen.
Natürlich betrachten wir die Historie, die robots.txt und WebArchive, ViewDNS und suchen nach alten Versionen der Ressource. Manchmal stellen die Entwickler etwas wie mail2.yandex.net bereit, während die alte Version mail.yandex.net bleibt. Dieses mail.yandex.net wird nicht mehr unterstützt, die Entwicklungsressourcen werden nicht mehr darauf verwendet, aber es verbraucht weiterhin die Datenbank. Entsprechend kann man mit der alten Version effektiv die Backend-Ressourcen und alles, was hinter der Gestaltung steht, nutzen. Natürlich geschieht das nicht immer, aber wir stoßen trotzdem häufig auf solche Situationen.
Natürlich zerlegen wir alle Anfrageparameter und die Struktur der Cookies. Man könnte beispielsweise einen JSON-Array innerhalb der Cookies mit einem Wert füllen, eine große Verschachtelung erzeugen und die Ressource dazu bringen, nicht sinnvoll lange zu arbeiten.

Suchlast

Das Erste, was einem bei der Untersuchung einer Website in den Sinn kommt, ist, die Datenbank zu belasten, da fast jeder eine Suchfunktion hat und die meisten leider schlecht geschützt sind. Aus irgendeinem Grund schenken die Entwickler der Suche nicht genug Aufmerksamkeit. Es gibt jedoch eine Empfehlung — man sollte keine gleichartigen Anfragen durchführen, da man sonst auf Caching stoßen kann, ähnlich wie bei einem HTTP Flood.
Zufällige Anfragen an die Datenbank sind ebenfalls nicht immer effektiv. Es ist viel besser, eine Liste von Schlüsselwörtern zu erstellen, die sich auf die Suche beziehen. Wenn wir zum Beispiel von einem Online-Shop sprechen: Angenommen, die Website verkauft Autoreifen und ermöglicht es, den Reifenumfang, den Fahrzeugtyp und andere Parameter anzugeben. Entsprechend werden Kombinationen relevanter Wörter die Datenbank dazu bringen, unter wesentlich komplexeren Bedingungen zu arbeiten.
Außerdem sollte man Paginierung verwenden: Es ist für die Suche viel schwieriger, die vorletzte Seite der Ergebnisse zurückzugeben, als die erste. Das heißt, durch Paginierung kann man die Last ein wenig variieren.
Im folgenden Beispiel zeigen wir die Suchlast. Man sieht, dass die Website vom ersten Moment des Tests bei zehn Anfragen pro Sekunde ausgefallen ist und nicht reagiert hat.

Gibt es keine Suche?

Wenn es keine Suche gibt, bedeutet das nicht, dass die Website keine anderen anfälligen Eingabefelder enthält. Ein solches Feld könnte die Authentifizierung sein. Heutzutage neigen Entwickler dazu, komplexe Hashes zu verwenden, um die Login-Datenbank gegen Angriffe mit Rainbow-Table zu schützen. Das ist gut, aber solche Hashes verbrauchen eine große Menge an CPU-Ressourcen. Ein hoher Ansturm falscher Authentifizierungen führt zu einer Überlastung des Prozessors, wodurch die Website schließlich nicht mehr funktioniert.
Das Vorhandensein verschiedener Formulare für Kommentare und Feedback auf der Website ist ein Grund, sehr große Texte zu senden oder einfach massiven Spam zu erzeugen. Manchmal akzeptieren Websites auch hochgeladene Dateien, unter anderem im gzip-Format. In diesem Fall nehmen wir eine Datei mit einer Größe von 1TB, komprimieren sie mit gzip auf einige Byte oder Kilobyte und senden sie an die Website. Sie wird dann entpackt, was einen sehr interessanten Effekt erzeugt.

Rest API

Es wäre schön, ein wenig Aufmerksamkeit auf so populäre Dienste wie die Rest-API zu richten. Die Sicherung einer Rest-API ist viel komplexer als bei einer normalen Website. Für die Rest-API funktionieren nicht einmal die banalen Möglichkeiten, sich gegen Password-Knacken und andere illegitime Aktivitäten zu schützen.
Eine Rest-API ist sehr leicht zu hacken, da sie direkt auf die Datenbank zugreift. Wenn dieser Dienst ausfällt, hat das schwerwiegende Folgen für das Geschäft. Denn oft sind nicht nur die Hauptwebsite, sondern auch mobile Anwendungen und interne Geschäftsressourcen von der Rest-API abhängig. Wenn diese Systeme ausfallen, ist der Effekt viel dramatischer, als wenn einfach nur eine normale Website offline geht.

Last auf schwerem Inhalt

Wenn wir dazu aufgefordert werden, eine normale Einseitenanwendung, eine Landingpage oder eine Visitenkarte zu testen, die keine komplexe Funktionalität aufweist, suchen wir nach schwerem Inhalt. Zum Beispiel große Bilder, die der Server bereitstellt, Binärdateien, PDF-Dokumentationen – wir versuchen all dies herunterzuladen. Solche Tests belasten das Dateisystem gut und blockieren die Kanäle, weshalb sie effektiv sind. Das heißt, selbst wenn Sie den Server nicht zum Absturz bringen, indem Sie eine große Datei mit niedrigen Geschwindigkeiten herunterladen, werden Sie einfach den Kanal des Zielservers überlasten, und es tritt dann ein Dienstversagen auf.
Im Beispiel dieses Tests ist zu sehen, dass die Website bei einer Geschwindigkeit von 30 RPS aufgehört hat zu antworten oder 500-Fehler an den Server herausgegeben hat.

Vergessen Sie nicht die Serverkonfiguration. Es ist häufig zu sehen, dass jemand eine virtuelle Maschine gekauft hat, Apache darauf installiert, alles auf die Standardeinstellungen konfiguriert und eine PHP-Anwendung platziert hat. Unten ist das Ergebnis zu sehen.

Hier betrug die Last nur 10 RPS auf den Root-Server. Wir warteten 5 Minuten, und der Server fiel aus. Es ist allerdings nicht genau bekannt, warum er abgestürzt ist, aber es besteht die Vermutung, dass er einfach überlastet war und deshalb aufgehört hat zu antworten.

Wellenbasiert

In den letzten ein bis zwei Jahren sind Wellenangriffe recht populär geworden. Das liegt daran, dass viele Organisationen bestimmte Hardware zum Schutz gegen DDoS erwerben, die eine gewisse Zeit benötigt, um Statistiken zu sammeln, bevor die Attacke gefiltert wird. Das bedeutet, dass sie die Attacke in den ersten 30-40 Sekunden nicht filtern, weil sie Daten sammeln und trainieren. In diesen 30-40 Sekunden kann man so viele Anfragen an die Website senden, dass der Dienst lange ausfällt, bis alle Anforderungen bearbeitet sind.
Im Fall des unten beschriebenen Angriffs betrug das Intervall 10 Minuten, nach denen eine neue, veränderte Angriffswelle eintraf.

Das heißt, der Schutz hat sich trainiert, die Filterung begonnen, aber es kam eine neue, völlig andere Angriffswelle, und der Schutz begann erneut mit dem Training. Tatsächlich hört die Filterung auf zu funktionieren, der Schutz wird ineffektiv, und die Website ist nicht mehr erreichbar.
Wellenangriffe zeichnen sich durch sehr hohe Werte an den Spitzen aus; sie können bei L7 bis zu hunderttausend oder eine Million Anfragen pro Sekunde erreichen. Wenn man von L3&4 spricht, kann der Traffic auch Hunderte von Gigabit betragen oder entsprechend Hunderte von mpps, wenn man in Paketen zählt.
Das Problem solcher Angriffe liegt in der Synchronisation. Die Angriffe kommen aus einem Botnetz, und um einen sehr großen, einmaligen Peak zu erzeugen, ist ein hohes Maß an Synchronisation erforderlich. Diese Koordination gelingt jedoch nicht immer: Manchmal entsteht ein parabolischer Peak, der recht armselig aussieht.

Nicht nur HTTP

Neben HTTP auf Ebene L7 nutzen wir auch andere Protokolle. In der Regel sind bei einer gewöhnlichen Website, insbesondere bei einem typischen Hosting, die Mail-Protokolle und MySQL nach außen sichtbar. Mail-Protokolle sind weniger anfällig für Belastungen als Datenbanken, aber sie können ebenfalls recht effektiv belastet werden, was zu einer Überlastung der CPU auf dem Server führt.
Wir haben mit der SSH-Schwachstelle aus dem Jahr 2016 tatsächlich Erfolge erzielt. Diese Schwachstelle ist mittlerweile fast überall behoben, aber das bedeutet nicht, dass man in SSH keine Last erzeugen kann. Man kann es. Es wird einfach eine enorme Anzahl von Authentifizierungen gesendet, die SSH fast die gesamte CPU auf dem Server beansprucht, und die Website fällt bereits bei ein oder zwei Anfragen pro Sekunde aus. Diese ein oder zwei Anfragen lassen sich in den Logs jedoch nicht von legitimen Lasten unterscheiden.
Es bleiben viele Verbindungen relevant, die wir auf den Servern öffnen. Früher war das ein Problem bei Apache, heutzutage hat es faktisch auch nginx, da es häufig standardmäßig konfiguriert wird. Die Anzahl der Verbindungen, die nginx offen halten kann, ist begrenzt; entsprechend öffnen wir diese Anzahl von Verbindungen, und eine neue Verbindung wird von nginx nicht mehr akzeptiert, was dazu führt, dass die Website nicht funktioniert.
Unser Test-Cluster verfügt über ausreichend CPU, um den SSL-Handshake anzugreifen. Prinzipiell ist es so, dass Botnets das manchmal auch gerne machen. Auf der einen Seite ist klar, dass man ohne SSL nicht auskommt, da es um die Google-Ausgabe, die Rangfolge, die Sicherheit geht. Auf der anderen Seite gibt es leider ein Problem mit der CPU bei SSL.

L3&4

Wenn wir von Angriffen auf den L3&4-Ebenen sprechen, meinen wir in der Regel Angriffe auf der Kanalebene. Eine solche Last ist fast immer von legitimer zu unterscheiden, es sei denn, es handelt sich um einen SYN-Flood-Angriff. Das Problem der SYN-Flood-Angriffe für Schutzmaßnahmen liegt im großen Volumen. Die maximale Größe für L3&4 betrug 1,5-2 Tbit/s. Solch ein Verkehr ist selbst für große Unternehmen, einschließlich Oracle und Google, sehr schwer zu verarbeiten.
SYN und SYN-ACK sind die Pakete, die bei der Verbindungsherstellung verwendet werden. Daher ist es schwierig, einen SYN-Flood von legitimer Last zu unterscheiden: Es ist unklar, ob es sich um ein SYN handelt, das zur Verbindungsherstellung angekommen ist, oder um einen Teil des Floods.

UDP-Flood

Normalerweise haben Angreifer nicht die Kapazitäten, die wir haben, daher kann zur Durchführung von Angriffen eine Amplifikation verwendet werden. Das heißt, der Angreifer scannt das Internet und findet entweder anfällige oder falsch konfigurierte Server, die zum Beispiel auf ein SYN-Paket mit drei SYN-ACK antworten. Durch das Spoofing der Quelladresse von der Zielserveradresse kann man mit einem Paket die Kapazität zum Beispiel verdreifachen und den Verkehr auf das Ziel umleiten.

Das Problem der Amplifizierungen liegt in deren schwieriger Erkennung. Ein aktuelles Beispiel ist der aufsehenerregende Fall mit dem anfälligen Memcached. Außerdem sind jetzt viele IoT-Geräte, IP-Kameras verfügbar, die ebenfalls meist standardmäßig falsch konfiguriert sind, weshalb Angreifer über solche Geräte die häufigsten Angriffe durchführen.

Komplexer SYN-Flood

SYN-Flood ist vielleicht die interessanteste Art von Angriffen aus der Sicht eines Entwicklers. Das Problem besteht darin, dass Systemadministratoren oft IP-Blockaden zur Sicherheit nutzen. Dabei sind nicht nur die Administratoren betroffen, die nach Skripten handeln, sondern leider auch einige Schutzsysteme, die oft teuer gekauft werden.
Eine solche Methode kann katastrophal enden, denn wenn die Angreifer IP-Adressen, wird das Unternehmen sein eigenes Subnetz sperren. Wenn die Firewall das eigene Cluster blockiert, werden die externen Interaktionen unterbrochen und der Dienst bricht zusammen.
Es ist zudem nicht schwer, das eigene Netzwerk zu blockieren. Wenn es im Büro des Kunden ein Wi-Fi-Netzwerk gibt oder wenn die Verfügbarkeit von Ressourcen mit verschiedenen Monitoring-Tools gemessen wird, nehmen wir die IP-Adresse dieses Monitoring-Systems oder des Büro-Wi-Fi-Clients und verwenden diese als Quelle. Auf der Ausgabe ist die Ressource scheinbar zugänglich, aber die Ziel-IP-Adressen sind blockiert. So kann das Wi-Fi-Netzwerk der HighLoad-Konferenz, auf der ein neues Produkt des Unternehmens präsentiert wird, blockiert werden — und dies hat bestimmte geschäftliche und wirtschaftliche Kosten zur Folge.
Während des Tests können wir keine Amplifikation über Memcached mit externen Ressourcen nutzen, da es Vereinbarungen zur Übertragung von Verkehr nur an genehmigte IP-Adressen gibt. Daher verwenden wir die Amplifikation über SYN und SYN-ACK, wenn das System auf das Senden eines SYN mit zwei bis drei SYN-ACK antwortet, wodurch der Angriff um das Zwei- bis Dreifache multipliziert wird.

Werkzeuge

Ein wichtiges Werkzeug, das wir für die Last auf L7-Ebene nutzen, ist Yandex-tank. Dabei wird insbesondere eine Phantomwaffe eingesetzt, dazu kommen einige Skripte zur Generierung von Munition und zur Analyse der Ergebnisse.
Zur Analyse des Netzwerkverkehrs wird Tcpdump verwendet, zur Analyse des Servers – Nmap. Zur Erzeugung von Last auf L3&4-Ebene nutzen wir OpenSSL und ein wenig eigene Magie mit der DPDK-Bibliothek. DPDK ist eine Bibliothek von Intel, die es ermöglicht, mit dem Netzwerkinterface zu arbeiten, ohne den Linux-Stack zu durchlaufen, und damit die Effizienz steigert. Natürlich nutzen wir DPDK nicht nur auf L3&4, sondern auch auf L7-Ebene, da sie es ermöglicht, einen sehr hohen Lastfluss von mehreren Millionen Anfragen pro Sekunde von einem einzigen Rechner zu erzeugen.
Wir verwenden auch bestimmte Traffic-Generatoren und spezielle Werkzeuge, die wir für spezifische Tests entwickeln. Wenn man an die Schwachstelle unter SSH denkt, kann sie mit dem oben genannten Satz nicht ausgenutzt werden. Wenn wir das E-Mail-Protokoll angreifen, verwenden wir E-Mail-Utilities oder schreiben einfach Skripte für sie.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

Zusammenfassend möchte ich sagen:

• Neben klassischem Lasttests ist es unbedingt notwendig, auch Stresstests durchzuführen. Wir haben ein echtes Beispiel, bei dem ein Subunternehmer des Partners nur Lasttests durchgeführt hat. Diese zeigten, dass die Ressource die normale Belastung aushält. Doch dann trat eine außergewöhnliche Belastung auf, die Besucher der Website begannen, die Ressource anders zu nutzen – und am Ende fiel der Subunternehmer aus. Daher sollte man nach Schwachstellen suchen, selbst wenn man bereits gegen DDoS-Angriffe geschützt ist.
• Es ist notwendig, Teile des Systems voneinander zu isolieren. Wenn Sie eine Suche haben, sollte sie auf separate Maschinen ausgelagert werden, also nicht einmal in Docker. Denn wenn die Suche oder die Authentifizierung ausfällt, wird mindestens etwas weiterhin funktionieren. Im Falle eines Online-Shops werden die Nutzer weiterhin Produkte im Katalog finden, von Aggregatoren auf die Seite kommen und einkaufen, wenn sie bereits authentifiziert sind, oder sich über OAuth2 anmelden.
• Man sollte alle möglichen Cloud-Dienste nicht unterschätzen.
• Verwenden Sie ein CDN nicht nur zur Optimierung von Netzwerkverzögerungen, sondern auch als Mittel zum Schutz gegen Kanalerschöpfungsangriffe und einfaches Flooding in die Statik.
• Es ist notwendig, spezialisierte Schutzdienste zu nutzen. Gegen L3&4-Angriffe auf Kanalebene können Sie sich nicht selbst schützen, da Sie wahrscheinlich nicht über einen ausreichenden Kanal verfügen. Ebenso werden Sie sich gegen L7-Angriffe schwer tun, da diese sehr groß sein können. Außerdem ist das Finden kleinerer Angriffe letztlich das Metier spezialisierter Dienste und spezieller Algorithmen.
• Halten Sie sich regelmäßig auf dem neuesten Stand. Das betrifft nicht nur den Kernel, sondern auch den SSH-Daemon, besonders wenn diese nach außen geöffnet sind. Prinzipiell sollten Sie alles aktualisieren, da Sie kaum in der Lage sein werden, bestimmten Schwachstellen selbstständig nachzugehen.

Quelle: habr.com