Wie schützen CDNs Failover-Sites vor DDoS-Angriffen?


9

Ich bin im Entwurfsprozess für eine Java-Webanwendung, die ich wahrscheinlich in Google App Engine (GAE) bereitstellen werde. Das Schöne an GAE ist, dass ich mir wirklich keine Sorgen machen muss, meine App vor dem gefürchteten DDoS-Angriff zu schützen. Ich gebe nur eine "Abrechnungsobergrenze" an, und wenn mein Datenverkehr diese Obergrenze erreicht (DDoS oder anderweitig), GAE schalte einfach meine App aus. Mit anderen Worten, GAE wird im Wesentlichen auf einen beliebigen Betrag skaliert, bis Sie es sich einfach nicht mehr leisten können, die App länger laufen zu lassen.

Ich versuche also, eine Eventualität zu planen, bei der die DNS-Einstellungen meiner Web-App-Domain auf eine andere Nicht-GAE-IP-Adresse "umgeschaltet" werden, wenn ich diese Abrechnungsgrenze erreiche und GAE meine App herunterfährt. Einige erste Untersuchungen haben gezeigt, dass bestimmte CDNs wie CloudFlare Dienste für genau diese Situation anbieten. Grundsätzlich behalte ich nur meine DNS-Einstellungen bei und sie bieten eine API, mit der ich ein Failover-Verfahren automatisieren kann. Wenn ich feststelle, dass meine Rechnungsobergrenze für meine GAE-App bei 99% liegt, kann ich auf diese CloudFlare-API zugreifen, und CloudFlare ändert meine DNS-Einstellungen dynamisch, um von den GAE-Servern auf eine andere IP-Adresse zu verweisen.

Meine anfängliche Möglichkeit wäre ein Failover auf eine schreibgeschützte Version (nur statischer Inhalt) meiner Web-App, die an einem anderen Ort gehostet wird, möglicherweise von GoDaddy oder Rackspace.

Aber dann wurde mir plötzlich klar: Wenn DDoS-Angriffe auf den Domainnamen abzielen, welchen Unterschied macht es dann, wenn ich von meiner GAE-IP-Adresse auf meine (sagen wir) GoDaddy-IP-Adresse wechsle? Im Wesentlichen würde das Failover nichts anderes tun, als es den DDoS-Angreifern zu ermöglichen, meine Backup- / GoDaddy-Site herunterzufahren!

Mit anderen Worten, DDoS-Angreifer koordinieren einen Angriff auf meine von GAE gehostete Web-App unter, bei www.blah-whatever.comder es sich tatsächlich um eine IP-Adresse von 100.2.3.4 handelt . Dadurch steigt mein Datenverkehr auf 98% meiner Abrechnungsobergrenze, und mein benutzerdefinierter Monitor löst ein CloudFlare-Failover von 100.2.3.4 auf 105.2.3.4 aus . Den DDoS-Angreifern ist das egal! Sie starten immer noch einen Angriff gegen www.blah-whatever.com! Der DDoS-Angriff geht weiter!

Ich frage also: Welchen Schutz bieten CDNs wie CloudFlare, damit Sie - wenn Sie auf ein anderes DNS umsteigen müssen - nicht dem gleichen, fortgesetzten DDoS-Angriff ausgesetzt sind? Wenn ein solcher Schutz besteht, gibt es technische Einschränkungen (z. B. schreibgeschützt usw.), die auf der Failover-Site gelten? Wenn nicht, was nützen sie?! Danke im Voraus!


Tolles Q! Daraus kann man viel lernen :-)
Martijn Verburg

Antworten:


6

In dieser Konfiguration schützen sie nicht vor DDoS-Angriffen. Ein CDN "schützt" nicht vor einem DDoS-Angriff - es mildert nur seine Auswirkungen, indem es über viel Hardware und Bandbreite verfügt, um das Problem zu lösen. Wenn das CDN die DNS-Einstellungen so ändert, dass sie direkt auf Ihren Server verweisen, verarbeitet das CDN keine Anfragen mehr für Ihre Website. Die Clients sehen nie die IP des CDN, sodass das CDN Ihnen keinen Schutz mehr bieten kann.

Was "was nützen sie" angeht - DDoS-Angriffe sind nicht der Sinn der Verwendung eines CDN. Der Zweck der Verwendung eines CDN besteht darin, die Latenz zwischen dem Anfordern eines großen Datenblocks von einem Ihrer Webserver und dem Abrufen der Daten durch diese Person zu verringern, indem die geografische Entfernung zwischen dem Server und dem Client verkürzt wird. Es ist eine Perf-Optimierung, die Sie vornehmen können. Aber es ist wirklich nicht dafür ausgelegt, Sicherheit vor DDoS zu bieten.


Vielen Dank an @Billy ONeal (+1) - um es zusammenzufassen: Ich möchte, dass mein "DDoS-Failover" Anforderungen tatsächlich an die CDN-Server umleitet, damit diese genügend Hardware / Bandbreite auf das Problem werfen können, um die Site am Laufen zu halten. obwohl dies nicht die Hauptfunktion eines CDN ist. Ist das mehr oder weniger richtig? Wenn ja, eine kurze Frage: Wenn ich diesen Weg gegangen wäre und mein Failover zum CDN umgeleitet hätte, könnte meine Web-App weiterhin normal funktionieren oder würden CDNs nur statische Inhalte zurückgeben (dh meine Web-App würde " schreibgeschützt "usw.)? Danke noch einmal!
Herpylderp

@herpylderp: Nun, das hängt von der Art der Seite ab. CDNs verarbeiten nur vollständig statische Inhalte. Wenn Ihr Server "interessante Dinge" tut, hilft Ihnen das CDN nicht weiter. Normalerweise können Sie keinen Code auf den Servern des CDN ausführen. Beispielsweise werden auf den Stack-Exchange-Sites die Bilder für jede der Sites auf sstatic.com, einem CDN, gehostet, aber die Hauptwebsite wird in den eigenen Rechenzentren von StackExchange gehostet.
Billy ONeal

1
CDNs werden in der Regel volumenabhängig berechnet, sodass Sie nur die Abrechnungskosten von einem Anbieter auf einen anderen verschieben. AFAIK, DDoS-Minderung beinhaltet normalerweise die automatische vorübergehende Blockierung von IP-Bereichen.
Joeri Sebrechts

Danke @Joeri Sebrechts (+1) - gibt es einen Unterschied zwischen einem "IP-Bereich" und einem "IP-Subnetz" oder sind sie gleich? Ich frage, weil GAE es Ihnen ermöglicht, IP-Subnetze zu blockieren, und ich hoffe, dass Sie darüber sprechen.
Herpylderp

7

Ich arbeite für Incapsula , ein Cloud-Sicherheitsunternehmen, das auch CDN-basierte Beschleunigungsdienste (wie CF) anbietet.

Ich möchte sagen, dass CDN (wie von @Billy ONeal korrekt angegeben) für sich genommen keinen DDoS-Schutz bietet, ein Cloud-basiertes Proxy-Netzwerk jedoch ein SEHR effektives DDoS-Minderungstool ist.

Im Falle von DDoS auf Cloud-CDN schützt Sie also nicht das "CDN", sondern "Cloud", indem es den gesamten von DDoS generierten zusätzlichen Datenverkehr aufnimmt und gleichzeitig den Zugriff auf Ihre Site von verschiedenen POPs auf der ganzen Welt ermöglicht.

Da es sich um eine Front-Gate-Proxy-Lösung handelt, kann diese Technologie auch verwendet werden, um Netzwerk-DDoS-Angriffe der Stufe 3-4 (dh SYN-Floods) zu verringern, bei denen gefälschte IP-Adressen verwendet werden, um zahlreiche SYN-Anforderungen an Ihre Server zu senden.

In diesem Fall stellt ein Proxy erst dann eine Verbindung her, wenn eine ACK-Antwort empfangen wurde, wodurch verhindert wird, dass die SYN-Flut auftritt.

Es gibt auch andere Möglichkeiten, wie Sie Cloud für die Website-Sicherheit verwenden können (z. B. Bad Bot Blocking, Cloud-basiertes WAF), und einige davon können auch zur DDoS-Minderung oder -Vorbeugung verwendet werden (das Stoppen von Scanner-Bots ist ein gutes Beispiel für die spätere Version) Das Wichtigste dabei ist, dass dies alles nicht auf CDN, sondern auf Cloud-Technologie basiert.


1
Wow - danke @Igal Zeifman (+1) - tolle Antwort! Einige Anschlussfragen an Sie: (1) Wenn Sie " Proxy-Netzwerk " oder " Front-Gate-Proxy " sagen , meinen Sie damit, dass die Cloud Server bereitstellt, die als Zwischenhändler zwischen Clients und meinen App-Servern fungieren, ja? Wenn nicht, können Sie das bitte erklären? Und (2) bieten CloudFlare und / oder Incapsula Funktionen für diese anderen Dienste (Stoppen / Blockieren von Bots, WAF usw.)? Danke noch einmal!
Herpylderp

Mit " POP " meine ich auch "Präsenzpunkte", ja?
Herpylderp

Hallo danke. Sehr geschätzt. Um Ihre Fragen zu beantworten: Front Gate Proxy: Der Begriff "Proxy" impliziert eine zwischengeschaltete Beziehung zwischen dem genannten Netzwerk und Ihrer Site. Dies bedeutet, dass das Netzwerk als erste Verteidigungslinie vor Ihrer Site "sitzt" (daher "Front Gate"), im Grunde genommen den gesamten Verkehr zuerst empfängt und alle "schlechten Sachen" herausfiltert, in unserem Fall mithilfe von Bad Bot Blockierungsregeln und Vektoren, WAF und so weiter. Im Falle von DDoS hilft dieses Netzwerk auch dabei, den zusätzlichen Datenverkehr auszugleichen, wodurch Probleme im Zusammenhang mit DDoS vermieden werden. (dh Abstürze) POP = Points of Presence. Sie sind 100% korrekt.
Igal Zeifman
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.