Die Häufigkeit und Heftigkeit von DDoS(Distributed Denial of Service)-Angriffen nimmt zu. Durch Ausnutzung von Millionen von unsicheren IoT(Internet of Things)-Geräten ist es jetzt leichter und wirksamer als je zuvor, Botnets für hochgradig verteilte volumetrische Angriffe zu erstellen. Aber die Angriffe werden nicht nur immer umfangreicher, sie richten sich nun auch eher gegen die Anwendungsschicht (7. Schicht) anstatt gegen die Netzwerk- oder Übertragungsschicht. Angriffe gegen die Anwendungsschicht sind viel raffinierter. Meist benötigen sie weniger Ressourcen, um Websites oder Anwendungen lahmzulegen und sie können den Betrieb noch wirkungsvoller stören.
DDoS-Angriffe stören den normalen Geschäftsbetrieb, indem sie die Performance und die Verfügbarkeit von Websites und Anwendungen verschlechtern. Manchmal legen sie sie sogar vollständig lahm. Im Durchschnitt verursachen durch Infrastrukturausfälle entstandene Ausfallzeiten Kosten in Höhe von $100.000 pro Stunde.Solche Angriffe führen schnell zur Abwanderung von Kunden, einer Abwertung der Marke und entgangenen Umsätzen.
Websites und Anwendungen benötigen die Stabilität und Intelligenz eines skalierbaren Netzwerks, um die umfangreichsten und neuesten Angriffe abwehren zu können.Der Schutz vor Bedrohungen sollte die Performance nicht durch sicherheitsinduzierte Latenzen beeinträchtigen. Außerdem sollten Sicherheitsservices leicht zu konfigurieren sein, damit es nicht zu Fehlkonfigurationen kommt, die neue Schwachstellen hervorrufen.
Schutz vor den umfangreichsten Angriffen
Die Kapazität des Cloudflare-Netzwerks ist 15x größer als der größte bislang verzeichnete DDoS-Angriff.Mit seiner Kapazität von 30 Tbps kann es modernen verteilten Angriffen entgegenwirken, auch solchen, die auf die DNS-Infrastruktur abzielen.
Freigegebene Netzwerkdaten
Mit jeder neuen Eigenschaft wird das Cloudflare-Netzwerk intelligenter. Die IP-Reputationsdatenbank von Cloudflare erkennt und blockiert neue und weiterentwickelte Bedrohungen bei allen 7 Millionen Netzwerk-Properties.
Keine Kompromisse bei der Performance
Integrieren Sie die in der Cloudflare-Lösung enthaltenen Performance Services, darunter CDN, Smart Routing und die aktuellen Webstandards, und eliminieren Sie so sicherheitsinduzierte Latenzen.
DNS-Flood-Angriffe unterbrechen die DNS-Auflösung und sorgen so dafür, dass die Performance einer Website, API oder Anwendung nicht mehr ausreicht oder diese sogar gar nicht mehr verfügbar sind.
Angreifer nutzen die Funktionen offener DNS- oder NTP-Resolver, um einen Zielserver oder ein Zielnetzwerk mit verstärktem Anforderungsdatenverkehr zu überlasten, bei dem die Nutzlast größer ist als die ursprüngliche Anforderung.
HTTP-Flood-Angriffe erzeugen große Mengen von HTTP-, GET- oder POST-Anforderungen aus verschiedenen Quellen. Sie zielen auf die Anwendungsebene ab und sorgen für eine Serviceverschlechterung oder sogar dafür, dass der Dienst nicht mehr verfügbar ist.
Bei dem mehrstufigen Sicherheitsansatz von Cloudflare sind mehrere Sicherheitsfunktionen in einem Dienst zusammengefasst. Er verhindert durch illegitimen Datenverkehr verursachte Störungen, lässt aber legitimen Datenverkehr passieren. So bleiben Websites, Anwendungen und APIs hochgradig verfügbar und leistungsfähig.
Wichtigste Ergebnisse
226.500.000
Angriffe wurden zwischen August 2015 und November 2016 blockiert. Das sind 500.000 Angriffe pro Tag und nicht einer davon war erfolgreich.
95%
Bandbreite wurde pro Monat eingespart.
$250.000
Fallstudie lesen
Brad Parscale
President von Giles-Parscale
Digital Director im Trump-Wahlkampf
Alle Tarife von Cloudflare beinhalten die unbegrenzte und zeitlich unabhängige Abwehr von DDoS(Denial-of-Service)-Angriffen unabhängig von ihrem Umfang ohne zusätzliche Kosten. Kunden sollten nicht für Datenverkehrsspitzen bestraft werden, die durch DDoS-Angriffe entstehen. Der DDoS-Schutz von Cloudflare sorgt dafür, dass alle Internet-Properties online bleiben. Gleichzeitig bleiben die Infrastrukturkosten vorhersehbar.
Die Ingenieure von Cloudflare haben bereits einige der größten Angriffe der Geschichte miterlebt. Mehr darüber erfahren Sie in unserem Entwicklerblog.
Im Winter 2016 konnte Cloudflare den bisher größten verteilten Layer-3-Angriff abschwächen. Er wurde nicht nur gestoppt, sondern auch genau erfasst und analysiert. Weitere Informationen
Verteilte Angriffe nehmen alle Formen und Gestalten an. Bei diesem 400-Gbit/s-Amplification-Angriff nutzte der Angreifer 4.529 NTP-Server, um einen Angriff von einem Quellserver mit lediglich 87 Mbit/s zu verstärken.
Weitere Informationen
Cloudflare bekämpft bereits seit mehr als 7 Jahren verbreitete Angriffe. Der 120-Gbit/s-Angriff auf Spamhaus von 2013 gilt als sehr groß. Cloudflare konnte dafür sorgen, dass die Website dennoch online blieb. Weitere Informationen
Verhindern Sie, dass Angreifer Zugang zu sensiblen Kundendaten wie Anmeldeinformationen, Kreditkartendaten und anderen Informationen, anhand derer Personen identifiziert werden können, erlangen.
Verhindern Sie, dass missbräuchliche Bots durch Content Scraping, betrügerische Zugriffe und die Übernahme von Konten Internet-Properties beschädigen.
Die Sicherheits- und Performance-Services von Cloudflare greifen ineinander, um die Latenz von Websites, mobilen Anwendungen und APIs umfassend zu reduzieren. Gleichzeitig bieten sie Schutz vor DDoS-Angriffen, missbräuchlichen Bots und dem Missbrauch von Daten.
Die Cloudflare Performance Services steigern die Konversionen, vermindern die Kundenabwanderung und verbessern das Besuchererlebnis, indem sie die Performance im Web und auf mobilen Geräten verbessern und die Anwendungen verfügbar halten.
Cloudflare Security Services verringern das Risiko von Kundenverlust, abnehmenden Gewinnen und Beschädigung der Marke, indem sie vor DDoS-Angriffen, missbräuchlichen Bots und dem Missbrauch von Daten schützen.
Da Cloudflare als Proxy für Ihren gesamten Netzwerkverkehr dient, können wir Sie vor jeder Art von Distributed-Denial-of-Service-Angriffen schützen, einschließlich:
Die meisten Angriffe zielen auf die Übertragungs- und Netzwerkschichten eines Kommunikationssystems ab. Diese Schichten repräsentieren Layer 3 und 4 des OSI-Schichtenmodells. Die so genannte Transportschicht spezifiziert das Protokoll (zB TCP oder UDP) mit dem zwei Hosts in einem Netzwerk miteinander kommunizieren. Angriffe auf die Schichten 3 und 4 sollen die Netzwerkschnittstelle mit Angriffsverkehr überschwemmen, um seine Ressourcen zu überfordern und die Fähigkeit zu verweigern auf legitimen Datenverkehr zu reagieren. Insbesondere zielen Angriffe dieser Art es darauf ab, die Switch-Kapazität zu sättigen, oder eine Netzwerkkarte oder die CPU-Fähigkeit des Servers zur Abwehr des Angriffs zu überfordern.
Layer 3 und 4 Attacken können mit einer On-Premise-Lösung kaum abgeschwächt werden. Wenn ein Angreifer mehr Verkehr sendet als eine Netzwerkverbindung verarbeiten kann, werden auch keine zusätzlichen Hardware-Ressourcen dabei helfen, einen solchen Angriff zu mildern. Wenn Sie beispielsweise einen Router mit einem 10-Gbit/s-Port verwenden und ein Angreifer Ihnen ein Angriffspaket mit 11 Gbit/s sendet, können Sie noch so intelligente Software oder Hardware verwenden, Sie können den Angriff nicht aufhalten, wenn die Netzwerkverbindung vollständig ausgelastet ist.
Sehr große Layer 3/4 Angriffe stammen fast immer aus einer Reihe von Quellen. Diese vielen Quellen senden jeweils Angriffsverkehr an eine einzige Internet-Adresse und erzeugen somit eine Flutwelle, mit denen das Angriffsziel nicht umgehen kann. Der Angriff wird also verteilt. Die Angriffsverkehr-Quelle kann eine Gruppe von Leuten sein die miteinander arbeiten, ein Botnet von kompromittierten PCs, ein Botnet von kompromittierten Servern, falsch konfigurierte DNS-Resolver oder sogar Heim-Internet-Router mit schwachen Passwörtern.
Da es dem Angreifer einer 3/4 Layer Attacke egal ist, ob er eine Antwort auf seine Anfragen erhält, muss das Angriffspaket nicht genau oder richtig formatiert sein. Der Angreifer wird regelmäßig alle Informationen in den Angriffspaketen manipulieren, einschließlich der Quell-IP-Adresse, um es so aussehen zu lassen, als wie wenn der Angriff von einer praktisch unbegrenzten Anzahl von Quellen kommen würde. Da Paketdaten vollständig randomisiert werden können, werden selbst Techniken wie Ingress-Filter praktisch nutzlos.
Mit Cloudflare wird jeglicher Angriffsdatenverkehr, der sonst direkt auf Ihren Server treffen würde, automatisch an das globale Anycast-Netzwerk von Cloudflare geroutet. Sobald der Angriffsverkehr verlagert wurde, nutzen wir die globale Kapazität unseres Netzwerks und die Vielzahl unserer Server um die Flut des Angriffsverkehr am Networkedge zu absorbieren. Das bedeutet, dass Cloudflare jedes einzelne Angriffpaket einer Layer 3/4 Attacke davon abhalten kann, jemals eine Seite zu erreichen, die unter dem Schutz von Cloudflare steht.
DNS-Amplification-Angriffe sind eine Form von DRDoS, die auf dem Vormarsch sind und zur größten Quelle der Layer 3/4-Angriffe geworden sind. Cloudflare schwächt regelmäßig Angriffe ab, die 100 Gbit/s überschreiten, und hat vor Kurzem einen Kunden vor einem Angriff mit mehr als 300 Gbit/s geschützt. Die New York Times bezeichnete ihn als den „größten öffentlich bekannt gewordenen DDoS-Angriff in der Geschichte des Internets“.
Die Anfragen der Angreifer machen nur einen Bruchteil der Größe der Antworten aus, so dass der Angreifer den Angriff zu einem Vielfachen der Größe der Bandbreiten-Ressourcen die er selbst kontrolliert erweitern kann. Der DNS-Amplifikationsangriff ohne Cloudflare Ein Angreifer sammelt Ressourcen wie Botnets und imitiert die IP-Adresse des Ziels. Die Anforderungen der Angreifer selbst machen nur einen Bruchteil der Antworten aus. So kann der Angreifer seinen Angriff um ein Vielfaches der Bandbreitenressourcen unter seiner eigenen Kontrolle verstärken.
Zum Beispiel können Sie die folgende (winzige) Anfrage senden (wobei x.x.x.x die IP eines Open-DNS-Resolvers ist):Die Ressourcen senden daraufhin eine Flut von Antworten an das Ziel und legen es so lahm.
Zum Beispiel können Sie die folgende (winzige) Anfrage senden (wobei x.x.x.x die IP eines Open-DNS-Resolvers ist):Die Ressourcen senden daraufhin eine Flut von Antworten an das Ziel, werden aber regional von den Rechenzentren von Cloudflare blockiert. Legitimer Datenverkehr erreicht die Web-Property weiterhin.
Es gibt zwei Kriterien für Amplification-Angriffe:1.) Eine Abfrage kann von einer gefälschten Quelladresse gesendet werden (z. B. über ein protokollartiges ICMP oder UDP, das keinen Handshake erfordert) und 2.) die Antwort auf die Abfrage ist deutlich größer als die Abfrage selbst. Das DNS ist eine grundlegende, universelle Internetplattform, die diese Kriterien erfüllt. Daher ist es mittlerweile zur wichtigsten Quelle von Amplification-Angriffen geworden.
DNS-Abfragen werden in der Regel über UDP übertragen. Das bedeutet, dass es sich wie bei ICMP-Abfragen, die bei einem SMURF-Angriff (siehe unten) verwendet werden, um Fire-and-Forget-Abfragen handelt. Dementsprechend kann das Quellattribut einer DNS-Abfrage gefälscht sein. In diesem Fall hat der Empfänger keine Möglichkeit, es vor einer Antwort auf seine Richtigkeit zu überprüfen. Das DNS ist auch in der Lage, Antworten zu generieren, die weit größer sind als die Abfrage. Sie können beispielsweise folgende (winzige) Abfrage versenden (wobei x.x.x.x die IP-Adresse eines offenen DNS-Resolvers darstellt):
dig ANY isc.org @x.x.x.x +edns=0
Und die folgende gigantische Antwort erhalten:
; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 4084 IN A 149.20.64.42
isc.org. 4084 IN MX 10 mx.pao1.isc.org.
isc.org. 4084 IN MX 10 mx.ams1.isc.org.
isc.org. 4084 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 4084 IN TXT "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org. 4084 IN AAAA 2001:4f8:0:2::d
isc.org. 4084 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org. 4084 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 4084 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 484 IN RRSIG NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org. 484 IN RRSIG SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org. 484 IN RRSIG MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org. 484 IN RRSIG TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org. 484 IN RRSIG AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org. 484 IN RRSIG NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org. 484 IN RRSIG NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org. 484 IN RRSIG SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org. 484 IN RRSIG A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223
Hier handelt es sich um eine 64-Byte-Abfrage, die zu einer 3.223-Byte-Antwort geführt hat. Die Angreifer können also ihre Attacke nahezu 50-fach verstärken.
Cloudflares Anycast-Netzwerk wurde speziell dazu entworfen, enorme Layer 3/4 Attacken aufzuhalten. Durch die Verwendung von Anycast sind wir dazu in der Lage, für jedes unserer 194 Rechenzentren weltweit die gleiche IP-Adresse anzugeben. Das Netzwerk sendet Anfragen an die nächstgelegene Einrichtung. Unter normalen Umständen hilft uns das sicherzustellen, dass Ihre Website-Nutzer automatisch zum nächstgelegenen Rechenzentrum in unserem Netzwerk geleitet werden, um die beste Leistung zu gewährleisten. Im Falle eines Angriffs verteilt Anycast den Angriffsdatenverkehr effektiv in unserem gesamten Rechenzentrumsnetzwerk. Da jedes Rechezentrum die gleiche IP-Adresse für jeden Cloudflare Kunden anzeigt, kann der Verkehr nicht an nur einen Standort gesendet werden. Anstatt eines Viele-zu-Eins-Angriffs wird der Angriff zu einem Viele-zu-Viele-Angriff, bei dem kein einzelner Punkt innerhalb des Netzwerks eine einzelne Schwachstelle darstellt.
Eine neue Generation von Angriffen zielt auf die 7. Schicht des OSI-Schichtenmodells ab. Diese Angriffe fokussieren auf spezifische Aspekte der entsprechenden Applikation. So versenden zum Beispiel die sogenannten Slow-Read-Angriffe Pakete langsam über mehrere Verbindungen. Da Apache für jede Verbindung einen neuen Thread öffnet und die Verbindungen solange aufrechterhält, wie Datenverkehr gesendet wird, kann ein Angreifer einen Webserver überlasten, indem er alle verfügbaren Threads in relativ kurzer Zeit auslastet.
Tatsächlich reduzieren wir den HTTP Angriffsverkehr um etwa 90%. Dies reicht meistens aus, um unsere Kunden zu schützen. Die restlichen 10%, bei denen herkömmliche Schutzmaßnahmen nicht ausreichen, können Kunden mit limitierten Ressourcen oder im Falle eines großen Angriffs dennoch hart treffen. In diesem Fall bietet Cloudflare den Sicherheitsmodus “I’m Under Attack” (IUAM).
IUAM ist ein Sicherheitslevel, dass Sie für Ihre Website einstellen können, wenn Sie angegriffen werden. Wenn IUAM eingeschaltet ist, wird Cloudflare eine zusätzliche Schutzschicht hinzufügen, um bösartigen HTTP-Datenverkehr davor zu stoppen, an den Server weitergeleitet zu werden. Während eine Reihe von zusätzlichen Kontrollen im Hintergrund ausgeführt wird, wird dem Besucher Ihrer Website für 5 Sekunden eine interstitielle Seite präsentiert, bis die Kontrollen abgeschlossen werden. Betrachten Sie es als eine Aufgabe, bei der Tests automatisch durchgeführt werden und die Besucher kein CAPTCHA ausfüllen müssen.
Nachdem die Verifizierung durchgeführt wurde, können Besucher unbeschwert Ihre Seite durchsuchen. JavaScript und Cookies sind für die Tests erforderlich und werden benötigt, um aufzuzeichnen, dass die Tests ordnungsgemäß bestanden sind. Der IUAM-Modus blockiert Suchmaschinen-Crawler oder Ihre bestehende Cloudflare Whitelist nicht. Der „I’m Under Attack“-Modus blockiert keine Suchmaschinen-Crawler oder Ihre vorhandene Cloudflare-Positivliste.
Einer der ersten DNS-Amplifikationsangriffe war als der SMURF-Angriff bekannt. Bei einem SMURF-Angriff sendet ein Angreifer ICMP-Anforderungen (d. h. Ping-Anforderungen) an die Broadcast-Adresse eines Netzwerks (d. h. X.X.X.255), die von einem Router angegeben wird, der so konfiguriert ist, dass ICMP-Anforderungen an alle dem Router nachgeschalteten Geräte weitergeleitet werden. Der Angreifer täuscht dann vor, dass die Quelle der ICMP-Anfrage die IP-Adresse des beabsichtigten Opfers ist. Da für ICMP kein Handshake erfolgt, kann das Ziel nicht überprüfen, ob die IP-Quelladresse legitim ist. Der Router empfängt die Anfrage und leitet sie an alle Geräte im lokalen Netz weiter. Jedes dieser Geräte reagiert dann auf die Ping-Anforderungen. Der Angreifer kann dann den Angriff auf die Anzahl der Geräte im angegriffenen Netz erweitern (dh, wenn Sie 5 Geräte haben, dann kann der Angreifer die Attacke um das 5-fache verstärken, siehe Diagramm unten).
SMURF-Angriffe gehören weitgehend der Vergangenheit an. Der Großteil der Netzbetreiber hat ihre Router so konfiguriert, dass an die Broadcast-Adresse übermittelte ICMP-Anfragen nicht weitergeleitet werden.
