Jestem w trakcie projektowania aplikacji internetowej Java, którą prawdopodobnie skończę w Google App Engine (GAE). Zaletą GAE jest to, że naprawdę nie muszę się martwić o wzmocnienie mojej aplikacji przed przerażającym atakiem DDoS - po prostu określam „pułap rozliczeniowy”, a jeśli mój ruch osiąga szczyt do tego pułapu (DDoS lub inny), GAE po prostu wyłączy moją aplikację. Innymi słowy, GAE będzie zasadniczo skalowane do dowolnej kwoty, dopóki po prostu nie będzie Cię stać na dalsze działanie aplikacji.
Staram się więc zaplanować nieprzewidziany przypadek, w którym jeśli osiągnę ten pułap naliczania opłat i GAE wyłączy moją aplikację, ustawienia DNS domeny mojej aplikacji internetowej „przestawią się” na inny adres IP inny niż GAE. Niektóre wstępne badania wykazały, że niektóre sieci CDN, takie jak CloudFlare, oferują usługi w tej właśnie sytuacji. Zasadniczo po prostu zachowuję ustawienia DNS przy nich, a one udostępniają interfejs API, który mogę nacisnąć, aby zautomatyzować procedurę przełączania awaryjnego. Dlatego jeśli wykryję, że mam 99% pułapu naliczania opłat za moją aplikację GAE, mogę uruchomić ten interfejs API CloudFlare, a CloudFlare dynamicznie zmieni moje ustawienia DNS, aby wskazywały na serwery GAE na inny adres IP.
Moim początkowym przypadkiem byłoby przejście w tryb failover do wersji „tylko do odczytu” (tylko zawartość statyczna) mojej aplikacji internetowej hostowanej gdzie indziej, być może przez GoDaddy lub Rackspace.
Ale nagle mnie to przyszło do głowy: jeśli ataki DDoS są wymierzone w nazwę domeny, co za różnica, jeśli przejdę z mojego adresu IP GAE na mój (powiedzmy) adres IP GoDaddy? Zasadniczo przełączenie awaryjne nie zrobiłoby nic innego, niż pozwolić atakującym DDoS na usunięcie mojej strony z kopiami zapasowymi / GoDaddy!
Innymi słowy, osoby atakujące DDoS koordynują atak na moją aplikację internetową, obsługiwaną przez GAE, pod adresem www.blah-whatever.com, który w rzeczywistości jest adresem IP 100.2.3.4 . Powodują wzrost ruchu do 98% mojego pułapu naliczania opłat, a mój monitor niestandardowy uruchamia przełączenie awaryjne CloudFlare ze 100.2.3.4 na 105.2.3.4 . Atakujących DDoS nie obchodzi! Nadal przeprowadzają atak www.blah-whatever.com! Atak DDoS trwa!
Pytam więc: jaką ochronę zapewniają CDN, takie jak CloudFlare, aby - gdy trzeba przejść do innego DNS-u - nie byłeś narażony na ten sam ciągły atak DDoS? Jeśli taka ochrona istnieje, czy istnieją jakieś ograniczenia techniczne (np. Tylko do odczytu itp.), Które są nakładane na stronę trybu failover? Jeśli nie, jakie są dobre ?! Z góry dziękuję!
źródło
Odpowiedzi:
W tej konfiguracji nie chronią przed atakami DDoS. CDN nie „chroni” przed atakiem DDoS - po prostu łagodzi jego skutki, mając duży sprzęt i przepustowość, aby rzucić na problem. Gdy CDN zmienia ustawienia DNS tak, aby wskazywały bezpośrednio na serwer, CDN nie obsługuje już żądań dla Twojej witryny - klienci nigdy nie widzą adresu IP CDN, więc CDN nie może dłużej oferować ochrony.
Jeśli chodzi o „jakie są one dobre” - ataki DDoS nie są celem korzystania z CDN. Celem korzystania z sieci CDN jest zmniejszenie opóźnień między momentem, w którym ktoś żąda dużej ilości danych z jednego z serwerów internetowych, a tą osobą, która je otrzymuje, poprzez zmniejszenie odległości geograficznej między serwerem a klientem. To optymalizacja, którą możesz wykonać; ale tak naprawdę nie jest przeznaczony do zapewnienia bezpieczeństwa z DDoS.
źródło
Pracuję dla Incapsula , firmy Cloud Security, która świadczy również usługi akceleracyjne oparte na CDN (takie jak CF).
Chcę powiedzieć, że chociaż (jak słusznie stwierdził @Billy ONeal) CDN sam w sobie nie zapewnia ochrony przed DDoS, oparta na chmurze sieć proxy jest BARDZO skutecznym narzędziem ograniczającym DDoS.
I tak, w przypadku DDoS w chmurze CDN, to nie „CDN”, ale „Chmura” chroni cię, przejmując cały dodatkowy ruch generowany przez DDoS, jednocześnie umożliwiając dostęp do Twojej witryny z różnych POP na całym świecie.
Ponadto, ponieważ jest to rozwiązanie proxy front-gate, technologia ta może być wykorzystana do ograniczenia ataków sieciowych DDoS poziomu 3-4 (tj. SYN Floods), które wykorzystują sfałszowane adresy IP do wysyłania licznych żądań SYN do serwerów.
W takim przypadku serwer proxy nie nawiąże połączenia, dopóki nie zostanie odebrana odpowiedź ACK, co zapobiegnie wystąpieniu powodzi SYN.
Istnieją również inne sposoby korzystania z chmury dla bezpieczeństwa witryny (np. Blokowanie Bad Bot, oparte na chmurze WAF), a niektóre z nich można również wykorzystać do łagodzenia lub zapobiegania DDoS (zatrzymanie botów skanera jest dobrym przykładem na później), ale najważniejsze jest, aby zrozumieć, że wszystko to opiera się nie na CDN, ale na technologii Cloud.
źródło