{"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
\nDie Firma Variti entwickelt Bot-Schutz und DDoS-Abwehr und f\u00fchrt au\u00dferdem Stress- und Lasttests durch. Auf der Konferenz HighLoad++ 2018 haben wir dar\u00fcber gesprochen, wie man Ressourcen gegen verschiedene Arten von Angriffen absichert. Kurz gesagt: Isolieren Sie Teile des Systems, nutzen Sie Cloud-Dienste und CDN und halten Sie Ihre Software regelm\u00e4\u00dfig auf dem neuesten Stand. Allerdings kommen Sie ohne spezialisierte Anbieter f\u00fcr Sicherheitsl\u00f6sungen dennoch nicht weit \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nBevor Sie den Text lesen, k\u00f6nnen Sie sich mit den kurzen Thesen vertraut machen. auf der Website der Konferenz.<\/a><\/noindex>.
\nWenn Sie nicht gerne lesen oder einfach das Video anschauen m\u00f6chten, finden Sie die Aufzeichnung unseres Vortrags unten im Spoiler.<\/p>\n

Videoaufzeichnung des Vortrags<\/b>

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

Viele Unternehmen sind bereits in der Lage, Lasttests durchzuf\u00fchren, aber nicht alle f\u00fchren auch Stresstests durch. Einige unserer Kunden sind der Ansicht, dass ihre Website unverwundbar ist, weil sie \u00fcber ein Highload-System verf\u00fcgen und dieses gut gegen Angriffe sch\u00fctzt. Wir zeigen jedoch, dass dies nicht ganz der Wahrheit entspricht.
\nSelbstverst\u00e4ndlich holen wir vor den Tests die Zustimmung des Kunden ein, inklusive Unterschrift und Stempel. Mit unserer Hilfe ist es nicht m\u00f6glich, eine DDoS-Attacke gegen irgendjemanden durchzuf\u00fchren. Die Tests finden zu einem vom Kunden gew\u00e4hlten Zeitpunkt statt, an dem die Besucherzahlen seiner Ressource minimal sind, sodass Zugangsprobleme keine Auswirkungen auf die Kunden haben. Dar\u00fcber hinaus halten wir w\u00e4hrend des gesamten Testprozesses einen st\u00e4ndigen Kontakt mit dem Kunden. Dies erm\u00f6glicht es uns, nicht nur \u00fcber die erzielten Ergebnisse zu berichten, sondern auch Anpassungen w\u00e4hrend der Tests vorzunehmen. Nach Abschluss der Tests erstellen wir immer einen Bericht, in dem wir die festgestellten M\u00e4ngel benennen und Empfehlungen zur Behebung der Schwachstellen der Website geben. <\/p>\n

So arbeiten wir<\/h3>\n

\nBei den Tests simulieren wir ein Botnetz. Da wir mit Kunden arbeiten, die sich nicht in unseren Netzwerken befinden, geben wir den Stress nicht von einer IP aus, sondern aus unserem eigenen Subnetz aus, um zu verhindern, dass der Test gleich nach der ersten Minute aufgrund von Limits oder Schutzma\u00dfnahmen abgebrochen wird. Zudem verf\u00fcgen wir \u00fcber einen leistungsstarken Testserver, um eine erhebliche Last zu erzeugen.<\/p>\n

Postulate<\/h3>\n

<\/p>\n

Viel bedeutet nicht immer gut<\/b>
\nJe geringer die Last, die wir ben\u00f6tigen, um eine Ressource zum Ausfall zu bringen, desto besser. Wenn es gelingt, die Website durch nur einen Aufruf pro Sekunde oder sogar durch einen Aufruf pro Minute zum Stillstand zu bringen, ist das gro\u00dfartig. Denn das Gesetz der Wahrscheinlichkeit besagt, dass Benutzer oder Angreifer zuf\u00e4llig genau diese Schwachstelle ausnutzen werden. <\/p><\/blockquote>\n

Teilweiser Ausfall ist besser als vollst\u00e4ndiger<\/b>
\nWir empfehlen immer, Systeme heterogen zu gestalten. Dabei sollten sie auf physischer Ebene getrennt werden und nicht nur durch Containerisierung. Bei physischer Trennung ist die Wahrscheinlichkeit gro\u00df, dass die Website auch bei einem Ausfall noch teilweise funktionsf\u00e4hig bleibt und die Benutzer zumindest Zugang zu einem Teil der Funktionalit\u00e4t haben.<\/p><\/blockquote>\n

Die richtige Architektur ist die Grundlage der Stabilit\u00e4t<\/b>
\nDie Ausfallsicherheit einer Ressource und ihre F\u00e4higkeit, Angriffe und Lasten standzuhalten, m\u00fcssen bereits in der Entwurfsphase auf Grundlage der ersten Diagramme im Notizbuch eingeplant werden. Denn wenn fatale Fehler auftreten, k\u00f6nnen sie sp\u00e4ter zwar behoben werden, sind jedoch sehr schwer zu korrigieren.<\/p><\/blockquote>\n

Nicht nur der Code, sondern auch die Konfiguration sollte gut sein<\/b>
\nViele glauben, dass ein gutes Entwicklungsteam eine Garantie f\u00fcr die Ausfallsicherheit eines Services ist. Ein gutes Entwicklungsteam ist zwar notwendig, aber es ben\u00f6tigt auch einen effektiven Betrieb und kompetentes DevOps. Das hei\u00dft, es sind Fachleute erforderlich, die Linux und das Netzwerk richtig konfigurieren, die Nginx-Konfigurationen korrekt erstellen und Limits sowie andere Einstellungen richtig vornehmen. Andernfalls wird die Ressource nur im Test gut funktionieren, w\u00e4hrend sie in der Produktion irgendwann versagen wird.<\/p><\/blockquote>\n

Unterschiede zwischen Last- und Stresstests<\/b>
\nLasttests erm\u00f6glichen es, die Grenzen der Funktionsf\u00e4higkeit eines Systems zu identifizieren. Stresstests hingegen sind darauf ausgerichtet, Schwachstellen im System zu finden. Sie werden durchgef\u00fchrt, um das System zum Versagen zu bringen und zu beobachten, wie es sich bei einem Ausfall bestimmter Komponenten verh\u00e4lt. Dabei ist die Art der Last in der Regel bis zum Beginn des Stresstests unbekannt f\u00fcr den Auftraggeber.<\/p><\/blockquote>\n

<\/p>\n

Besonderheiten von L7-Angriffen<\/h3>\n

\nWir unterteilen die Lastarten \u00fcblicherweise in L7- und L3&4-Lasten. L7 bezieht sich auf Lasten auf Anwendungsebene, die meist nur HTTP umfassen. Wir verstehen darunter jedoch jede Last auf der TCP-Protokollebene.
\nL7-Angriffe weisen bestimmte charakteristische Merkmale auf. Erstens gelangen sie direkt an die Anwendung, weshalb es kaum m\u00f6glich ist, sie mit Netzwerkma\u00dfnahmen abzuwehren. Solche Angriffe nutzen Logik, wodurch sie sehr effizient und mit geringem Traffic CPU, RAM, Speicher, Datenbank und andere Ressourcen beanspruchen.<\/p>\n

HTTP Flood<\/h3>\n

\nBei jedem Angriff ist es einfacher, die Last zu erzeugen, als sie zu verarbeiten, und das gilt auch f\u00fcr L7. Angriffs-Traffic ist nicht immer leicht von legitimen Anfragen zu unterscheiden, und das gelingt meist anhand der H\u00e4ufigkeit. Wenn alles jedoch gut geplant ist, ist es anhand der Logs unm\u00f6glich zu erkennen, wo der Angriff und wo die legitimen Anfragen sind.
\nAls erstes Beispiel betrachten wir den HTTP Flood-Angriff. Aus dem Diagramm geht hervor, dass solche Angriffe in der Regel sehr m\u00e4chtig sind; im folgenden Beispiel \u00fcberstieg die Spitzenanzahl der Anfragen 600.000 pro Minute.<\/p>\n

\"DDoS
\n
\nHTTP Flood ist die einfachste Methode, um Last zu erzeugen. Oft wird daf\u00fcr ein Lasttest-Tool wie ApacheBench verwendet, um Anfragen und Ziele festzulegen. Bei diesem einfachen Ansatz besteht eine hohe Wahrscheinlichkeit, dass das Server-Caching aktiviert ist, jedoch l\u00e4sst sich dies leicht umgehen. Beispielsweise durch das Hinzuf\u00fcgen zuf\u00e4lliger Zeichenfolgen zur Anfrage, wodurch der Server gezwungen wird, st\u00e4ndig die aktuelle Seite auszugeben.
\nEbenso sollte man bei der Lastgenerierung nicht den User-Agent vergessen. Viele User-Agents von beliebten Testwerkzeugen werden von Systemadministratoren gefiltert, wodurch die Last m\u00f6glicherweise nicht bis zum Backend gelangt. Signifikant verbessern kann man das Ergebnis, indem man in die Anfrage einen mehr oder weniger g\u00fcltigen Header aus einem Browser einf\u00fcgt.
\nTrotz der Einfachheit haben HTTP Flood-Angriffe auch ihre Nachteile. Erstens erfordern sie gro\u00dfe Kapazit\u00e4ten zur Lastgenerierung. Zweitens werden solche Angriffe sehr leicht erkannt, besonders wenn sie von einer einzigen Adresse ausgehen. Infolgedessen werden die Anfragen sofort entweder von Systemadministratoren gefiltert oder sogar auf Anbieter-Ebene. <\/p>\n

Was zu beachten ist<\/h3>\n

\nUm die Anzahl der Anfragen pro Sekunde zu reduzieren, ohne an Effizienz zu verlieren, ist ein wenig Kreativit\u00e4t gefragt. Man kann nicht nur den Kanal oder den Server belasten, sondern auch einzelne Teile der Anwendung, wie Datenbanken oder Dateisysteme. Au\u00dferdem sollte man nach Bereichen auf der Website suchen, die gro\u00dfe Berechnungen durchf\u00fchren, wie Rechner, Produktvergleichsseiten und dergleichen. Oft gibt es auch einen PHP-Skript auf der Website, der eine Seite aus mehreren Hunderttausend Zeilen generiert. Ein solcher Skript kann ebenfalls erheblich die Serverlast erh\u00f6hen und ein Ziel f\u00fcr Angriffe werden.<\/p>\n

Wo suchen<\/h3>\n

\nWenn wir eine Ressource vor der Durchf\u00fchrung von Tests scannen, schauen wir zun\u00e4chst nat\u00fcrlich auf die Website selbst. Wir suchen nach Eingabefeldern, gro\u00dfen Dateien \u2014 kurz gesagt, allem, was Probleme f\u00fcr die Ressource verursachen und ihre Leistungsf\u00e4higkeit verringern k\u00f6nnte. Hierbei helfen die einfachen Entwicklertools in Google Chrome und Firefox, die die Antwortzeiten der Seite anzeigen.
\nWir scannen auch Subdomains. Zum Beispiel gibt es einen Online-Shop, abc.com, und eine Subdomain admin.abc.com. Wahrscheinlich handelt es sich hierbei um den administrativen Bereich mit Authentifizierung. Wenn wir jedoch Last darauf aus\u00fcben, kann dies Probleme f\u00fcr die Hauptressource verursachen.
\nDie Website k\u00f6nnte eine Subdomain api.abc.com haben. Wahrscheinlich ist dies eine Ressource f\u00fcr mobile Anwendungen. Man kann die App im App Store oder Google Play finden, einen speziellen Zugangspunkt einrichten, die API analysieren und Testkonten registrieren. Das Problem ist, dass viele Leute glauben, dass alles, was durch Authentifizierung gesch\u00fctzt ist, immun gegen Denial-of-Service-Angriffe ist. Man denkt oft, dass Authentifizierung die beste CAPTCHA ist, aber das ist nicht der Fall. Es ist einfach, 10-20 Testkonten zu erstellen, und sobald wir sie haben, erhalten wir Zugang zu komplexen und unverdeckten Funktionen.
\nNat\u00fcrlich analysieren wir die Historie, die robots.txt und WebArchive, ViewDNS und suchen nach \u00e4lteren Versionen der Website. Manchmal kommt es vor, dass die Entwickler beispielsweise mail2.yandex.net ver\u00f6ffentlichen, w\u00e4hrend die alte Version, mail.yandex.net, bestehen bleibt. Diese mail.yandex.net wird nicht mehr unterst\u00fctzt, es werden keine Entwicklungsressourcen daf\u00fcr bereitgestellt, aber sie verbraucht weiterhin die Datenbank. Daher k\u00f6nnen wir mit der alten Version effektiv die Backend-Ressourcen und alles, was hinter dem Layout steht, nutzen. Nat\u00fcrlich geschieht das nicht immer, aber wir sto\u00dfen trotzdem ziemlich oft auf solche Situationen.
\nNat\u00fcrlich zerlegen wir alle Anfrageparameter und die Struktur der Cookies. Man kann beispielsweise in ein JSON-Array innerhalb der Cookies einen Wert einf\u00fcgen, eine gro\u00dfe Verschachtelung schaffen und die Website dazu bringen, v\u00f6llig unn\u00f6tig lange zu arbeiten.<\/p>\n

Suchlast<\/h3>\n

\nDas erste, was einem beim Testen einer Website in den Sinn kommt, ist die Belastung der Datenbank, da fast jeder eine Suchfunktion hat und diese leider oft unzureichend gesch\u00fctzt ist. Aus irgendeinem Grund schenken Entwickler dem Thema Suche nicht gen\u00fcgend Aufmerksamkeit. Hier gibt es jedoch einen Hinweis \u2013 man sollte vermeiden, identische Anfragen durchzuf\u00fchren, da es sonst zu Caching-Problemen kommen kann, \u00e4hnlich wie bei HTTP-Fluten.
\nZuf\u00e4llige Anfragen an die Datenbank sind ebenfalls nicht immer effizient. Es ist viel besser, eine Liste von Schl\u00fcsselw\u00f6rtern zu erstellen, die sich auf die Suche beziehen. Wenn wir zum Beispiel einen Online-Shop betrachten: Angenommen, die Website verkauft Autoreifen und erm\u00f6glicht die Eingabe von Reifengr\u00f6\u00dfe, Fahrzeugtyp und anderen Parametern. Entsprechend werden Kombinationen relevanter W\u00f6rter die Datenbank unter viel komplexeren Bedingungen arbeiten lassen.
\nAu\u00dferdem sollte man Paginierung verwenden: Es ist f\u00fcr die Suche viel schwieriger, die vorletzte Seite der Ergebnisse anzuzeigen als die erste. Durch Paginierung kann die Last daher etwas variieren.
\nIm folgenden Beispiel zeigen wir die Belastung der Suchanfrage. Es ist zu sehen, dass die Website bereits ab der ersten Sekunde des Tests mit zehn Anfragen pro Sekunde nicht mehr reagierte.<\/p>\n

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

Kein Ergebnis gefunden?<\/h3>\n

\nWenn kein Ergebnis gefunden wird, bedeutet das nicht, dass die Seite keine anderen verwundbaren Eingabefelder enth\u00e4lt. Ein solches Feld k\u00f6nnte die Authentifizierung sein. Aktuelle Entwickler neigen dazu, komplexe Hashes zu verwenden, um die Datenbank der Anmeldungen vor Angriffen durch Regenbogentabellen zu sch\u00fctzen. Das ist zwar gut, jedoch verbrauchen solche Hashes gro\u00dfe CPU-Ressourcen. Ein hohes Aufkommen falscher Anmeldungen kann zu einer \u00dcberlastung der CPU f\u00fchren, was zur Folge hat, dass die Webseite nicht mehr funktioniert.
\nDas Vorhandensein verschiedenster Formulare f\u00fcr Kommentare und Feedback auf der Webseite ist ein Anlass, um sehr gro\u00dfe Texte zu senden oder einfach massiven Spam zu erzeugen. Oft akzeptieren Webseiten auch angeh\u00e4ngte Dateien, einschlie\u00dflich im gzip-Format. In diesem Fall nehmen wir eine Datei mit einem Volumen von 1 TB, komprimieren sie mit gzip auf einige Byte oder Kilobyte und senden sie an die Webseite. Anschlie\u00dfend wird sie dekomprimiert und es entsteht ein sehr interessantes Ergebnis. <\/p>\n

Rest API<\/h3>\n

\nIch m\u00f6chte etwas Aufmerksamkeit auf die derzeit beliebten Dienste wie Rest API lenken. Es ist viel schwieriger, eine Rest API zu sch\u00fctzen als eine herk\u00f6mmliche Webseite. F\u00fcr Rest APIs funktionieren sogar einfache Schutzma\u00dfnahmen gegen Passwortangriffe und andere illegitime Aktivit\u00e4ten nicht.
\nREST-APIs sind anf\u00e4llig f\u00fcr St\u00f6rungen, da sie direkt mit der Datenbank kommunizieren. Ein Ausfall solch eines Services kann erhebliche Konsequenzen f\u00fcr das Gesch\u00e4ft nach sich ziehen. Oft sind REST-APIs nicht nur f\u00fcr die Hauptwebsite, sondern auch f\u00fcr mobile Anwendungen und interne Gesch\u00e4ftsressourcen verantwortlich. Wenn diese Systeme ausfallen, ist der Effekt weitaus gravierender als bei einem einfachen Website-Ausfall. <\/p>\n

Last auf schweren Inhalten<\/h3>\n

\nWenn wir aufgefordert werden, ein einfaches Einseiter-Programm, eine Landingpage oder eine Visitenkarte zu testen, die keine komplexe Funktionalit\u00e4t aufweisen, suchen wir nach schweren Inhalten. Dazu geh\u00f6ren gro\u00dfe Bilder, die der Server liefert, Bin\u00e4rdateien, PDF-Dokumentationen \u2013 wir versuchen, alles herunterzuladen. Solche Tests belasten das Dateisystem stark und \u00fcberlasten die Kan\u00e4le, weshalb sie effektiv sind. Selbst wenn Sie den Server nicht herunterfahren, indem Sie eine gro\u00dfe Datei mit niedrigen Geschwindigkeiten herunterladen, blockieren Sie einfach den Kanal des Zielservers, was zu einem Dienstverweigerungsangriff f\u00fchren kann.
\nBei einem solchen Test ist deutlich zu sehen, dass die Website bei 30 RPS aufgeh\u00f6rt hat zu reagieren oder 500er Serverfehler ausgegeben hat.<\/p>\n

\"DDoS
\n
\nVergessen Sie nicht die Serverkonfiguration. H\u00e4ufig sieht man, dass jemand eine virtuelle Maschine gekauft hat, Apache installiert und alles auf die Standardeinstellungen gesetzt hat, sein PHP-Anwendung platziert hat und weiter unten das Ergebnis sehen kann. <\/p>\n

\"DDoS
\n
\nHier lag die Last bei nur 10 RPS. Wir haben 5 Minuten gewartet, und der Server ist abgest\u00fcrzt. Bis jetzt bleibt unklar, warum er abgest\u00fcrzt ist, aber es gibt die Vermutung, dass er einfach zu viel Speicher verbraucht hat und deshalb nicht mehr reagierte.<\/p>\n

Wellenbasiert<\/h3>\n

\nIn den letzten ein bis zwei Jahren sind wellenbasierte Angriffe ziemlich popul\u00e4r geworden. Dies liegt daran, dass viele Organisationen Hardware zum Schutz vor DDoS-Angriffen kaufen, die eine gewisse Zeit ben\u00f6tigt, um Statistiken zu sammeln, bevor sie mit der Filterung der Angriffe beginnen. Das hei\u00dft, sie filtern die Angriffe in den ersten 30-40 Sekunden nicht, weil sie Daten sammeln und lernen. In diesen 30-40 Sekunden kann man also so viele Anfragen an die Website senden, dass der Dienst l\u00e4ngere Zeit nicht verf\u00fcgbar ist, w\u00e4hrend alle Anfragen bearbeitet werden.
\nIm Falle des Angriffs gab es einen Intervall von 10 Minuten, nach dem eine neue, modifizierte Angriffswelle eintraf.<\/p>\n

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

Nicht nur HTTP<\/h3>\n

\nNeben HTTP auf L7-Ebene nutzen wir gerne auch andere Protokolle. In der Regel sind bei einer herk\u00f6mmlichen Website, besonders bei normalem Hosting, die E-Mail-Protokolle und MySQL nach au\u00dfen hin sichtbar. E-Mail-Protokolle sind weniger anf\u00e4llig f\u00fcr Lasten als Datenbanken, jedoch k\u00f6nnen sie ebenfalls relativ effektiv belastet werden, was zu einer hohen CPU-Auslastung auf dem Server f\u00fchrt.
\nWir haben durchaus Erfolge erzielt, indem wir die SSH-Schwachstelle von 2016 ausnutzten. Diese Schwachstelle ist mittlerweile bei den meisten behoben, aber das bedeutet nicht, dass SSH nicht belastet werden kann. Das ist m\u00f6glich. Es wird einfach eine enorme Last an Authentifizierungen erzeugt, wodurch SSH fast die gesamte CPU auf dem Server in Anspruch nimmt. Infolgedessen kann die Website bereits bei ein oder zwei Anfragen pro Sekunde zusammenbrechen. Diese ein oder zwei Anfragen lassen sich in den Logs nicht von legitimem Traffic unterscheiden.
\nEs bleiben viele Verbindungen aktiv, die wir auf den Servern \u00f6ffnen. Fr\u00fcher war dies ein Problem bei Apache, und jetzt betrifft es tats\u00e4chlich auch nginx, da es h\u00e4ufig standardm\u00e4\u00dfig konfiguriert wird. Die Anzahl der Verbindungen, die nginx offenhalten kann, ist begrenzt; entsprechend k\u00f6nnen wir diese Anzahl an Verbindungen \u00f6ffnen, und eine neue Verbindung wird von nginx nicht mehr angenommen, was dazu f\u00fchrt, dass die Website nicht funktioniert.
\nUnser Testcluster verf\u00fcgt \u00fcber gen\u00fcgend CPU, um den SSL-Handshake zu attackieren. Praktisch gesehen machen Botnets das gelegentlich auch. Auf der einen Seite ist klar, dass man nicht auf SSL verzichten kann, da es f\u00fcr das Google-Ranking und die Sicherheit entscheidend ist. Auf der anderen Seite hat SSL leider ein Problem mit der CPU. <\/p>\n

L3&4<\/h3>\n

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

UDP-Flood<\/h3>\n

\nIn der Regel haben Angreifer nicht die Ressourcen, die wir haben. Daher kann zur Durchf\u00fchrung von Angriffen eine Amplifikation verwendet werden. Das bedeutet, dass der Angreifer das Internet scannt und anf\u00e4llige oder falsch konfigurierte Server findet, die beispielsweise auf ein SYN-Paket mit drei SYN-ACK antworten. Durch das F\u00e4lschen der Quelladresse des Zielservers kann man mit einem einzigen Paket die Leistung, sagen wir, verdreifachen und den Datenverkehr auf das Opfer umleiten.<\/p>\n

\"DDoS
\n
\nDas Problem der Amplifikation liegt in ihrer schwierigen Erkennung. Ein aktuelles Beispiel ist der viel beachtete Fall mit dem anf\u00e4lligen Memcached. Zudem gibt es jetzt viele IoT-Ger\u00e4te, IP-Kameras, die ebenfalls meist standardm\u00e4\u00dfig falsch konfiguriert sind. Daher nutzen Angreifer h\u00e4ufig diese Ger\u00e4te f\u00fcr ihre Angriffe. <\/p>\n

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

Schwieriges SYN-Flood<\/h3>\n

\nSYN-Flood ist wahrscheinlich die interessanteste Art von Angriffen aus der Sicht eines Entwicklers. Das Problem ist, dass Systemadministratoren oft IP-Blocking zur Verteidigung verwenden. Dabei sind nicht nur die Administratoren betroffen, die gem\u00e4\u00df Skripten handeln, sondern bedauerlicherweise auch einige teure Sicherheitssysteme.
\nDiese Methode kann katastrophal enden, denn wenn Angreifer sich als andere ausgeben, IP-Adressen<\/a>, k\u00f6nnte das Unternehmen sein eigenes Subnetz blockieren. Wenn die Firewall das eigene Cluster blockiert, kommen externe Interaktionen zum Erliegen, und die Ressource bricht zusammen.
\nEs ist gar nicht so schwer, die eigene Netzwerkblockade zu erreichen. Wenn im B\u00fcro des Kunden ein WLAN-Netzwerk vorhanden ist oder die Funktionsf\u00e4higkeit der Ressourcen durch verschiedene Monitoring-Systeme \u00fcberwacht wird, nehmen wir die IP-Adresse dieses Monitoring-Systems oder des B\u00fcro-WLANs und verwenden sie als Quelle. Das Ergebnis scheint zwar zug\u00e4nglich zu sein, aber die Ziel-IP-Adressen sind blockiert. So k\u00f6nnte das WLAN-Netzwerk der HighLoad-Konferenz, auf der das neue Produkt des Unternehmens pr\u00e4sentiert wird, blockiert werden \u2013 und das hat bestimmte gesch\u00e4ftliche und wirtschaftliche Kosten zur Folge.
\nW\u00e4hrend der Tests k\u00f6nnen wir keine Amplifikation \u00fcber Memcached mit externen Ressourcen nutzen, da es Vereinbarungen gibt, den Traffic nur an genehmigte IP-Adressen weiterzuleiten. Folglich verwenden wir Amplifikation durch SYN und SYN-ACK, wobei das System auf das Senden eines SYN mit zwei bis drei SYN-ACK reagiert, wodurch sich die Attacke zwei- bis dreimal potenziert. <\/p>\n

Werkzeuge<\/h3>\n

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

\n

Fazit<\/h3>\n

\nZusammenfassend m\u00f6chten wir Folgendes sagen:<\/p>\n