{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS zur Hilfe: Wie wir Stress- und Lasttests durchf\u00fchren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nDas Unternehmen Variti entwickelt Schutz gegen Bots und DDoS-Angriffe und f\u00fchrt auch Stress- und Lasttests durch. Auf der Konferenz HighLoad++ 2018 haben wir erz\u00e4hlt, wie man Ressourcen vor verschiedenen Arten von Angriffen sch\u00fctzt. Kurz gesagt: Isolieren Sie Teile des Systems, nutzen Sie Cloud-Dienste und CDN und aktualisieren Sie regelm\u00e4\u00dfig. Doch ohne spezialisierte Unternehmen mit Schutz werden Sie es trotzdem nicht schaffen \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nVor dem Lesen des Textes k\u00f6nnen Sie sich mit kurzen Thesen vertrautmachen auf der Konferenzwebsite<\/a><\/noindex>.
\nUnd wenn Sie nicht gerne lesen oder einfach nur das Video ansehen m\u00f6chten, ist die Aufzeichnung unseres Vortrags unten unter dem Spoiler.<\/p>\n

Videoaufzeichnung des Vortrags<\/b>

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Viele Unternehmen k\u00f6nnen bereits Lasttests durchf\u00fchren, aber nicht alle f\u00fchren Stresstests durch. Einige unserer Kunden glauben, dass ihre Website unverwundbar ist, weil sie \u00fcber ein Highload-System verf\u00fcgen, das sie gut vor Angriffen sch\u00fctzt. Wir zeigen jedoch, dass das nicht ganz stimmt.
\nNat\u00fcrlich holen wir vor der Durchf\u00fchrung von Tests die Genehmigung des Kunden mit Unterschrift und Siegel ein, und mit unserer Hilfe kann niemand einen DDoS-Angriff ausf\u00fchren. Die Tests werden zu einem vom Kunden gew\u00e4hlten Zeitpunkt durchgef\u00fchrt, wenn die Besucherzahl auf seiner Ressource minimal ist und sich Probleme mit dem Zugang nicht auf die Kunden auswirken. Dar\u00fcber hinaus haben wir w\u00e4hrend der Testphase stets einen st\u00e4ndigen Kontakt zum Kunden. Dies erm\u00f6glicht es nicht nur, \u00fcber die erzielten Ergebnisse zu berichten, sondern auch w\u00e4hrend des Tests Anpassungen vorzunehmen. Nach Abschluss der Tests erstellen wir immer einen Bericht, in dem wir auf festgestellte M\u00e4ngel hinweisen und Empfehlungen zur Beseitigung von Schwachstellen der Website geben. <\/p>\n

Wie wir arbeiten<\/h3>\n

\nBei der Durchf\u00fchrung 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\u00f6sung von Limits oder Schutzma\u00dfnahmen endet. Zudem haben wir einen ausreichend leistungsstarken Testserver, um eine signifikante Last zu erzeugen.<\/p>\n

Postulate<\/h3>\n

<\/p>\n

Viel bedeutet nicht unbedingt gut<\/b>
\nJe geringer die Last ist, die wir ben\u00f6tigen, 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\u00e4re das gro\u00dfartig. Denn nach Murphy's Gesetz werden die Nutzer oder Angreifer genau diese Schwachstelle zuf\u00e4llig ansteuern. <\/p><\/blockquote>\n

Ein teilweiser Ausfall ist besser als ein vollst\u00e4ndiger<\/b>
\nWir 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\u00e4llt, ist die Wahrscheinlichkeit gro\u00df, dass sie nicht vollst\u00e4ndig funktionsunf\u00e4hig wird, und die Nutzer Zugang zu zumindest einem Teil der Funktionalit\u00e4t behalten.<\/p><\/blockquote>\n

Die richtige Architektur ist die Grundlage der Robustheit<\/b>
\nDie Ausfallsicherheit einer Ressource und ihre F\u00e4higkeit, Angriffe und Lasten standzuhalten, m\u00fcssen bereits in der Planungsphase eingeplant werden, tats\u00e4chlich bereits in der Phase, in der die ersten Blockdiagramme im Notizbuch gezeichnet werden. Denn wenn fatale Fehler eingeschlichen werden, k\u00f6nnen sie sp\u00e4ter zwar behoben werden, was jedoch sehr schwierig ist.<\/p><\/blockquote>\n

Nicht nur der Code, sondern auch die Konfiguration muss gut sein<\/b>
\nViele glauben, dass ein gutes Entwicklungsteam eine Garantie f\u00fcr die Ausfallsicherheit des Dienstes ist. Ein gutes Entwicklungsteam ist tats\u00e4chlich n\u00f6tig, aber es muss auch eine gute Betriebsf\u00fchrung und ein gutes DevOps geben. Das bedeutet, dass Fachleute ben\u00f6tigt 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.<\/p><\/blockquote>\n

Unterschiede zwischen Last- und Stresstests<\/b>
\nLasttests erm\u00f6glichen es, die Grenzen der Funktionalit\u00e4t 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\u00e4lt. Dabei bleibt die Art der Last normalerweise bis zum Beginn des Stresstests unbekannt f\u00fcr den Auftraggeber.<\/p><\/blockquote>\n

<\/p>\n

Charakteristische Merkmale von L7-Angriffen<\/h3>\n

\nArten von Lasten unterteilen wir h\u00e4ufig 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.
\nL7-Angriffe haben bestimmte charakteristische Merkmale. Erstens gelangen sie direkt in die Anwendung, so dass es kaum m\u00f6glich 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.<\/p>\n

HTTP Flood<\/h3>\n

\nIm Fall eines Angriffs ist es einfacher, eine Last zu erzeugen, als sie zu verarbeiten, und das gilt auch f\u00fcr L7. Der Angriffsverkehr l\u00e4sst sich nicht immer einfach von legitimen Anfragen unterscheiden, und h\u00e4ufig gelingt dies nur anhand der Frequenz. Wenn alles jedoch gut geplant ist, ist es aus den Logs unm\u00f6glich zu erkennen, wo der Angriff und wo die legitimen Anfragen sind.
\nAls erstes Beispiel betrachten wir einen HTTP Flood-Angriff. Aus dem Diagramm ist ersichtlich, dass solche Angriffe normalerweise sehr m\u00e4chtig sind; im folgenden Beispiel \u00fcberschritt die maximale Anzahl der Anfragen 600.000 pro Minute.<\/p>\n

\"DDoS
\n
\nHTTP Flood ist der einfachste Weg, um Belastung zu erzeugen. In der Regel wird daf\u00fcr 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\u00dfen, aber dies l\u00e4sst sich leicht umgehen. Zum Beispiel, indem man zuf\u00e4llige Zeichenfolgen in die Anfrage einf\u00fcgt, was den Server zwingt, st\u00e4ndig eine frische Seite auszugeben.
\nAu\u00dferdem sollte man den User-Agent beim Erzeugen der Belastung nicht vergessen. Viele User-Agents beliebter Testwerkzeuge werden von Systemadministratoren gefiltert, und in solchen F\u00e4llen kommt die Last m\u00f6glicherweise gar nicht bis zum Backend. Das Ergebnis kann erheblich verbessert werden, wenn man in die Anfrage einen mehr oder weniger g\u00fcltigen Header eines Browsers einf\u00fcgt.
\nTrotz der Einfachheit haben HTTP Flood-Angriffe auch ihre Nachteile. Erstens erfordert die Erstellung von Last gro\u00dfe 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. <\/p>\n

Was zu suchen ist<\/h3>\n

\nUm 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\u00dfe Berechnungen durchf\u00fchren: Rechner, Seiten zur Produktauswahl usw. Schlie\u00dflich kommt es h\u00e4ufig 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.<\/p>\n

Wo suchen<\/h3>\n

\nWenn wir eine Ressource vor dem Testen scannen, schauen wir uns vor allem die Website selbst an. Wir suchen nach jeglichen Eingabefeldern, gro\u00dfen Dateien - kurz gesagt, allem, was Probleme f\u00fcr die Ressource verursachen und ihre Leistung verlangsamen k\u00f6nnte. Dabei helfen die einfachen Entwicklungstools in Google Chrome und Firefox, die die Antwortzeiten der Seite anzeigen.
\nWir 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\u00f6nnte es Probleme f\u00fcr die Hauptressource verursachen.
\nDie Website k\u00f6nnte eine Subdomain api.abc.com haben. Wahrscheinlich ist das eine Ressource f\u00fcr 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\u00fctzt ist, gegen Angriffe auf die Verf\u00fcgbarkeit 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\u00fctzten Funktionen.
\nNat\u00fcrlich 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\u00e4hrend die alte Version mail.yandex.net bleibt. Dieses mail.yandex.net wird nicht mehr unterst\u00fctzt, 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\u00fcrlich geschieht das nicht immer, aber wir sto\u00dfen trotzdem h\u00e4ufig auf solche Situationen.
\nNat\u00fcrlich zerlegen wir alle Anfrageparameter und die Struktur der Cookies. Man k\u00f6nnte beispielsweise einen JSON-Array innerhalb der Cookies mit einem Wert f\u00fcllen, eine gro\u00dfe Verschachtelung erzeugen und die Ressource dazu bringen, nicht sinnvoll lange zu arbeiten.<\/p>\n

Suchlast<\/h3>\n

\nDas 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\u00fctzt sind. Aus irgendeinem Grund schenken die Entwickler der Suche nicht genug Aufmerksamkeit. Es gibt jedoch eine Empfehlung \u2014 man sollte keine gleichartigen Anfragen durchf\u00fchren, da man sonst auf Caching sto\u00dfen kann, \u00e4hnlich wie bei einem HTTP Flood.
\nZuf\u00e4llige Anfragen an die Datenbank sind ebenfalls nicht immer effektiv. Es ist viel besser, eine Liste von Schl\u00fcsselw\u00f6rtern zu erstellen, die sich auf die Suche beziehen. Wenn wir zum Beispiel von einem Online-Shop sprechen: Angenommen, die Website verkauft Autoreifen und erm\u00f6glicht es, den Reifenumfang, den Fahrzeugtyp und andere Parameter anzugeben. Entsprechend werden Kombinationen relevanter W\u00f6rter die Datenbank dazu bringen, unter wesentlich komplexeren Bedingungen zu arbeiten.
\nAu\u00dferdem sollte man Paginierung verwenden: Es ist f\u00fcr die Suche viel schwieriger, die vorletzte Seite der Ergebnisse zur\u00fcckzugeben, als die erste. Das hei\u00dft, durch Paginierung kann man die Last ein wenig variieren.
\nIm 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.<\/p>\n

\"DDoS
\n<\/p>\n

Gibt es keine Suche?<\/h3>\n

\nWenn es keine Suche gibt, bedeutet das nicht, dass die Website keine anderen anf\u00e4lligen Eingabefelder enth\u00e4lt. Ein solches Feld k\u00f6nnte die Authentifizierung sein. Heutzutage neigen Entwickler dazu, komplexe Hashes zu verwenden, um die Login-Datenbank gegen Angriffe mit Rainbow-Table zu sch\u00fctzen. Das ist gut, aber solche Hashes verbrauchen eine gro\u00dfe Menge an CPU-Ressourcen. Ein hoher Ansturm falscher Authentifizierungen f\u00fchrt zu einer \u00dcberlastung des Prozessors, wodurch die Website schlie\u00dflich nicht mehr funktioniert.
\nDas Vorhandensein verschiedener Formulare f\u00fcr Kommentare und Feedback auf der Website ist ein Grund, sehr gro\u00dfe 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\u00f6\u00dfe 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. <\/p>\n

Rest API<\/h3>\n

\nEs w\u00e4re sch\u00f6n, ein wenig Aufmerksamkeit auf so popul\u00e4re Dienste wie die Rest-API zu richten. Die Sicherung einer Rest-API ist viel komplexer als bei einer normalen Website. F\u00fcr die Rest-API funktionieren nicht einmal die banalen M\u00f6glichkeiten, sich gegen Password-Knacken und andere illegitime Aktivit\u00e4ten zu sch\u00fctzen.
\nEine Rest-API ist sehr leicht zu hacken, da sie direkt auf die Datenbank zugreift. Wenn dieser Dienst ausf\u00e4llt, hat das schwerwiegende Folgen f\u00fcr das Gesch\u00e4ft. Denn oft sind nicht nur die Hauptwebsite, sondern auch mobile Anwendungen und interne Gesch\u00e4ftsressourcen von der Rest-API abh\u00e4ngig. Wenn diese Systeme ausfallen, ist der Effekt viel dramatischer, als wenn einfach nur eine normale Website offline geht. <\/p>\n

Last auf schwerem Inhalt<\/h3>\n

\nWenn wir dazu aufgefordert werden, eine normale Einseitenanwendung, eine Landingpage oder eine Visitenkarte zu testen, die keine komplexe Funktionalit\u00e4t aufweist, suchen wir nach schwerem Inhalt. Zum Beispiel gro\u00dfe Bilder, die der Server bereitstellt, Bin\u00e4rdateien, PDF-Dokumentationen \u2013 wir versuchen all dies herunterzuladen. Solche Tests belasten das Dateisystem gut und blockieren die Kan\u00e4le, weshalb sie effektiv sind. Das hei\u00dft, selbst wenn Sie den Server nicht zum Absturz bringen, indem Sie eine gro\u00dfe Datei mit niedrigen Geschwindigkeiten herunterladen, werden Sie einfach den Kanal des Zielservers \u00fcberlasten, und es tritt dann ein Dienstversagen auf.
\nIm Beispiel dieses Tests ist zu sehen, dass die Website bei einer Geschwindigkeit von 30 RPS aufgeh\u00f6rt hat zu antworten oder 500-Fehler an den Server herausgegeben hat.<\/p>\n

\"DDoS
\n
\nVergessen Sie nicht die Serverkonfiguration. Es ist h\u00e4ufig 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. <\/p>\n

\"DDoS
\n
\nHier 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\u00fcrzt ist, aber es besteht die Vermutung, dass er einfach \u00fcberlastet war und deshalb aufgeh\u00f6rt hat zu antworten.<\/p>\n

Wellenbasiert<\/h3>\n

\nIn den letzten ein bis zwei Jahren sind Wellenangriffe recht popul\u00e4r geworden. Das liegt daran, dass viele Organisationen bestimmte Hardware zum Schutz gegen DDoS erwerben, die eine gewisse Zeit ben\u00f6tigt, 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\u00e4llt, bis alle Anforderungen bearbeitet sind.
\nIm Fall des unten beschriebenen Angriffs betrug das Intervall 10 Minuten, nach denen eine neue, ver\u00e4nderte Angriffswelle eintraf.<\/p>\n

\"DDoS
\n
\nDas hei\u00dft, der Schutz hat sich trainiert, die Filterung begonnen, aber es kam eine neue, v\u00f6llig andere Angriffswelle, und der Schutz begann erneut mit dem Training. Tats\u00e4chlich h\u00f6rt die Filterung auf zu funktionieren, der Schutz wird ineffektiv, und die Website ist nicht mehr erreichbar.
\nWellenangriffe zeichnen sich durch sehr hohe Werte an den Spitzen aus; sie k\u00f6nnen 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\u00e4hlt.
\nDas Problem solcher Angriffe liegt in der Synchronisation. Die Angriffe kommen aus einem Botnetz, und um einen sehr gro\u00dfen, einmaligen Peak zu erzeugen, ist ein hohes Ma\u00df an Synchronisation erforderlich. Diese Koordination gelingt jedoch nicht immer: Manchmal entsteht ein parabolischer Peak, der recht armselig aussieht.<\/p>\n

Nicht nur HTTP<\/h3>\n

\nNeben HTTP auf Ebene L7 nutzen wir auch andere Protokolle. In der Regel sind bei einer gew\u00f6hnlichen Website, insbesondere bei einem typischen Hosting, die Mail-Protokolle und MySQL nach au\u00dfen sichtbar. Mail-Protokolle sind weniger anf\u00e4llig f\u00fcr Belastungen als Datenbanken, aber sie k\u00f6nnen ebenfalls recht effektiv belastet werden, was zu einer \u00dcberlastung der CPU auf dem Server f\u00fchrt.
\nWir haben mit der SSH-Schwachstelle aus dem Jahr 2016 tats\u00e4chlich Erfolge erzielt. Diese Schwachstelle ist mittlerweile fast \u00fcberall 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\u00e4llt 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.
\nEs bleiben viele Verbindungen relevant, die wir auf den Servern \u00f6ffnen. Fr\u00fcher war das ein Problem bei Apache, heutzutage hat es faktisch auch nginx, da es h\u00e4ufig standardm\u00e4\u00dfig konfiguriert wird. Die Anzahl der Verbindungen, die nginx offen halten kann, ist begrenzt; entsprechend \u00f6ffnen wir diese Anzahl von Verbindungen, und eine neue Verbindung wird von nginx nicht mehr akzeptiert, was dazu f\u00fchrt, dass die Website nicht funktioniert.
\nUnser Test-Cluster verf\u00fcgt \u00fcber 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. <\/p>\n

L3&4<\/h3>\n

\nWenn 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\u00fcr Schutzma\u00dfnahmen liegt im gro\u00dfen Volumen. Die maximale Gr\u00f6\u00dfe f\u00fcr L3&4 betrug 1,5-2 Tbit\/s. Solch ein Verkehr ist selbst f\u00fcr gro\u00dfe Unternehmen, einschlie\u00dflich Oracle und Google, sehr schwer zu verarbeiten.
\nSYN 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.<\/p>\n

UDP-Flood<\/h3>\n

\nNormalerweise haben Angreifer nicht die Kapazit\u00e4ten, die wir haben, daher kann zur Durchf\u00fchrung von Angriffen eine Amplifikation verwendet werden. Das hei\u00dft, der Angreifer scannt das Internet und findet entweder anf\u00e4llige 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\u00e4t zum Beispiel verdreifachen und den Verkehr auf das Ziel umleiten.<\/p>\n

\"DDoS
\n
\nDas Problem der Amplifizierungen liegt in deren schwieriger Erkennung. Ein aktuelles Beispiel ist der aufsehenerregende Fall mit dem anf\u00e4lligen Memcached. Au\u00dferdem sind jetzt viele IoT-Ger\u00e4te, IP-Kameras verf\u00fcgbar, die ebenfalls meist standardm\u00e4\u00dfig falsch konfiguriert sind, weshalb Angreifer \u00fcber solche Ger\u00e4te die h\u00e4ufigsten Angriffe durchf\u00fchren. <\/p>\n

\"DDoS
\n<\/p>\n

Komplexer SYN-Flood<\/h3>\n

\nSYN-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.
\nEine solche Methode kann katastrophal enden, denn wenn die Angreifer IP-Adressen<\/a>, wird das Unternehmen sein eigenes Subnetz sperren. Wenn die Firewall das eigene Cluster blockiert, werden die externen Interaktionen unterbrochen und der Dienst bricht zusammen.
\nEs ist zudem nicht schwer, das eigene Netzwerk zu blockieren. Wenn es im B\u00fcro des Kunden ein Wi-Fi-Netzwerk gibt oder wenn die Verf\u00fcgbarkeit von Ressourcen mit verschiedenen Monitoring-Tools gemessen wird, nehmen wir die IP-Adresse dieses Monitoring-Systems oder des B\u00fcro-Wi-Fi-Clients und verwenden diese als Quelle. Auf der Ausgabe ist die Ressource scheinbar zug\u00e4nglich, aber die Ziel-IP-Adressen sind blockiert. So kann das Wi-Fi-Netzwerk der HighLoad-Konferenz, auf der ein neues Produkt des Unternehmens pr\u00e4sentiert wird, blockiert werden \u2014 und dies hat bestimmte gesch\u00e4ftliche und wirtschaftliche Kosten zur Folge.
\nW\u00e4hrend des Tests k\u00f6nnen wir keine Amplifikation \u00fcber Memcached mit externen Ressourcen nutzen, da es Vereinbarungen zur \u00dcbertragung von Verkehr nur an genehmigte IP-Adressen gibt. Daher verwenden wir die Amplifikation \u00fcber 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. <\/p>\n

Werkzeuge<\/h3>\n

\nEin wichtiges Werkzeug, das wir f\u00fcr 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.
\nZur Analyse des Netzwerkverkehrs wird Tcpdump verwendet, zur Analyse des Servers \u2013 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\u00f6glicht, mit dem Netzwerkinterface zu arbeiten, ohne den Linux-Stack zu durchlaufen, und damit die Effizienz steigert. Nat\u00fcrlich nutzen wir DPDK nicht nur auf L3&4, sondern auch auf L7-Ebene, da sie es erm\u00f6glicht, einen sehr hohen Lastfluss von mehreren Millionen Anfragen pro Sekunde von einem einzigen Rechner zu erzeugen.
\nWir verwenden auch bestimmte Traffic-Generatoren und spezielle Werkzeuge, die wir f\u00fcr 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\u00fcr sie.<\/p>\n

\n

Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h3>\n

\nZusammenfassend m\u00f6chte ich sagen:<\/p>\n