W jaki sposób sieci CDN chronią witryny przełączania awaryjnego przed atakami DDoS?


9

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ę!


Świetnie Q! Wiele można się z tego nauczyć :-)
Martijn Verburg

Odpowiedzi:


6

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.


Dzięki @Billy ONeal (+1) - tak podsumowując: chciałbym, aby moje „DDoS Failover” faktycznie przekierowywało żądania do serwerów CDN, aby mogli rzucić wystarczającą ilość sprzętu / przepustowości na problem, aby utrzymać działanie strony; chociaż nie jest to podstawowa funkcja CDN. Czy to mniej więcej słuszne? Jeśli tak, to krótkie pytanie: jeśli wybiorę tę trasę i przekieruję do trybu CDN moje przełączenie awaryjne, czy moja aplikacja internetowa będzie mogła dalej funkcjonować normalnie, czy też CDN będzie obsługiwać tylko zawartość statyczną (tj. Moja aplikacja internetowa zmieni się w „ tylko do odczytu ”itp.)? Dzięki jeszcze raz!
herpylderp

@herpylderp: Cóż, to zależy od charakteru strony. Sieci CDN obsługują wyłącznie treści całkowicie statyczne. Jeśli twój serwer robi „ciekawe rzeczy”, CDN nie pomoże ci. Zazwyczaj nie można uruchomić kodu na serwerach CDN. Na przykład w witrynach wymiany stosów obrazy dla każdej z witryn są hostowane na sstatic.com, CDN, ale strona główna jest hostowana we własnych centrach danych StackExchange.
Billy ONeal

1
CDN zazwyczaj naliczają opłaty w zależności od wolumenu, więc po prostu przenosisz koszty fakturowania od jednego dostawcy do drugiego. AFAIK, łagodzenie DDoS zwykle obejmuje automatyczne tymczasowe blokowanie zakresów adresów IP.
Joeri Sebrechts

Dzięki @Joeri Sebrechts (+1) - czy jest jakaś różnica między „zakresem IP” a „podsiecią IP”, czy są one takie same? Pytam, ponieważ GAE pozwala blokować podsieci IP i mam nadzieję, że właśnie o tym mówisz.
herpylderp

7

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.


1
Wow - dzięki @Igal Zeifman (+1) - świetna odpowiedź! Kilka dalszych pytań dla Ciebie: (1) Kiedy mówisz „ sieć proxy ” lub „ front gate proxy ”, zakładam, że masz na myśli, że chmura zapewnia serwery, które działają jako pośrednicy między klientami a moimi serwerami aplikacji, tak? Jeśli nie, proszę wyjaśnić? I (2) czy CloudFlare i / lub Incapsula zapewnia funkcjonalność dla tych innych usług (zatrzymywanie / blokowanie botów, WAF itp.)? Dzięki jeszcze raz!
herpylderp

Ponadto przez „ POP ” zakładam, że masz na myśli „Punkty obecności”, tak?
herpylderp

Cześć, dzięki. Bardzo mile widziane. Aby odpowiedzieć na pytania: Front Gate Proxy: termin „proxy” oznacza związek pośredni między tą siecią a witryną. Oznacza to, że sieć będzie „siedzieć” przed twoją witryną (stąd „frontowa brama”) jako pierwsza linia obrony, w zasadzie przyjmując cały ruch 1-szy i odfiltrowując wszystkie „złe rzeczy”, w naszym przypadku za pomocą Bad Bot blokowanie reguł i wektorów, WAF i tak dalej. W przypadku DDoS sieć ta pomoże również zrównoważyć dodatkowy ruch, zapobiegając w ten sposób problemom związanym z DDoS. (tzn. ulega awarii) POP = Punkty obecności. Masz 100% racji.
Igal Zeifman
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.