Ochrona przez atakami DDoS w chmurze AWS

Okazuje się jednak, że w przypadku serwisów osadzonych w chmurze, przy prawidłowej ich architekturze i wykorzystaniu dostępnych funkcji oferowanych przez usługi w chmurze, ataki DDoS mogą stanowić dużo mniejsze zagrożenie, niż w przypadku tradycyjnych instalacji poza nią. Niniejszy post ma na celu przedstawienie kilku praktycznych przykładów funkcji chmury AWS, dzięki którym w bardziej efektywny sposób można ochronić się przed tego typu atakami.

Wśród wielu zagrożeń, na które narażane są serwisy webowe (np. strony internetowe), są ataki typu DDoS (ang. Distributed Denial of Service). Istnieje wiele sposobów przeprowadzania tego typu ataków a większość z nich (o ile nie wszystkie) mają na celu zmniejszenie wydajności serwerów hostujących daną aplikację – a ostatecznie zupełne ich przeciążenie, co zazwyczaj skutkuje zablokowaniem ich działania. Ataki DDoS charakteryzują się tym, że do ich przeprowadzenia wykorzystywane jest jednocześnie wiele serwerów, tzn. botów, które pośredniczą w wysyłaniu żądań do serwisu klienta, który w wyniku nagłego wzrostu ilości żądań i ich formy, może zostać przeciążony.

CloudFront jest typem usługi CDN (ang. Content Delivery Network), która charakteryzuje się kilkoma ważnymi cechami. Najważniejszą z nich, jest fakt, że dzięki wykorzystaniu infrastruktury globalnej, użytkownicy, którzy wysyłają żądania do naszej aplikacji (zazwyczaj żądania HTTP do strony WWW) nie trafiają od razu na serwery, gdzie strona jest osadzona a do tzw. Edge Location – dodatkowych serwerów zlokalizowanych na całym świecie (w chwili obecnej ponad 60 lokalizacji).

Celem tych lokalizacji w większości przypadków jest zwiększenie szybkości ładowania się zawartości stron WWW poprzez mechanizm cache’owania. Administrator decyduje jakie zawartości strony mogą być cache’owane i na jak długo. I tak np. może on zdecydować, że obrazki mogą być cache’owane przez okres 1h a pliki HTML przez okres 10 minut. Dzięki takiej konfiguracji, gdy użytkownicy końcowi będą próbowali otworzyć daną stronę WWW, to za pierwszym razem cache w najbliższej im lokalizacji (Edge) zostanie uzupełniony a żądania kolejnych użytkowników będą serwowane z tej lokalizacji, a nie z serwerów źródłowych. Wszystko to bez modyfikacji samej strony (jej kodu) oraz wiedzy użytkownika końcowego.

A gdzie jest w tym wszystkim obrona przed DDoS-em? Ano w tym, że w przypadku ataku DDoS żądania od atakującego nie trafią na serwery strony WWW a zostaną rozrzucone przez DNS na infrastrukturę CDN na całym świecie, która będzie miała za zadanie ‘wchłonąć’ atak – i tym samym nadmiar ruchu nie trafi w ogóle (lub w ograniczonym zakresie) do serwerów gdzie jest osadzona strona WWW.

Obrazek poniżej prezentuje przykład ataku DDoS, który jednocześnie dokonywany jest z wielu miejsc na terenie Europy. Wszystkie żądania http trafiają do serwerów, na których jest zlokalizowana strona WWW użytkownika i tym samym mogą doprowadzić do jej przeciążenia.

Diagram poniżej prezentuje ten sam przypadek ataku DDoS, jednak w tym przypadku użytkownik uruchomił usługę CloudFront dla strony. Dzięki tej technice, atak DDoS został w sposób automatycznie rozprowadzony na infrastrukturze globalnej (Edge Location) i nie trafił do serwerów, na których jest hostowana strona, tym samym nie doprowadzając do zaprzestania jej działania lub zwiększenia kosztów z uwagi na potrzebę skalowania.

AWS udostępnia usługę load balancing-u za pomocą usługi Elastic Load Balancer (ELB). Głównym zadaniem ELB jest odbieranie żądań (requestów) od użytkowników końcowych i rozprowadzanie ich na serwery podpięte do niego. ELB wykorzystuje się głównie, gdy mamy do czynienia z systemami, które możemy skalować horyzontalnie (tzn. dodawać kolejne serwery aplikacji). Jedną z cech ELB jest to, że przepuszcza on jedynie ruch TCP, a nie UDP. A to właśnie UDP jest jednym z częstszych wykorzystywanych protokołów przy atakach typu DDoS. Za każdym razem kiedy ELB otrzyma komunikacje UDP, zostanie ona zablokowana i nie będzie przepuszczona do serwerów.

P.E.C („Przed erą chmury”) przy wdrażaniu nowego systemu czy aplikacji, należało go dostosować do ‘maksymalnego’ szacowanego obciążenia. Raz zdefiniowana infrastruktura – zazwyczaj ilość serwerów nie ulegała później zmianie – obojętnie czy potrzeby się zwiększały (większa ilość użytkowników) – czy też malały (popularność aplikacji spadała). Pojawienie się chmury udostępniło nowy mechanizm, który wcześniej nie był dostępny dla projektantów IT – funkcję automatycznej skalowalności, dzięki któremu użytkownik może skalować horyzontalnie swoją aplikację lub system w zależności od potrzeb. Przykładowo użytkownik może skonfigurować system tak, aby zostawały dodawane nowe serwery z aplikacją, gdy średnie obciążenie CPU na istniejących serwerach jest większe, niż pewien zadany poziom. Oczywiście użytkownik skonfiguruje również wówczas maksymalną ilość serwerów, jaka jest dopuszczalna. W takim przypadku, pod wpływem ataku DDoS, infrastruktura chmurowa automatycznie wykryje zwiększony ruch i doda kolejne serwery, których zadaniem będzie obsługa dodatkowych żądań.  Gdy natomiast potencjalny atak zostanie zakończony, ilość serwerów wróci do pierwotnej wartości. Oczywiście mechanizm automatycznego skalowania nie jest remedium na każdy typ ataku DDoS. Raczej nie jest naszym celem rozszerzenie infrastruktury do gigantycznej ilości serwerów tylko po to, aby ‘obsłużyły ruch DDoS’ – jednak przy mniejszych atakach może pozwolić on na ich przetrwanie lub też da czas potrzebny na skonfigurowania innych typów obrony.

WAF jest funkcją, która często jest wybierana, aby dodatkowo zwiększyć ochronę systemów wystawionych na świat zewnętrzny. AWS udostępnia możliwość wykorzystania wielu z istniejących i znanych produktów typu WAF, które użytkownik może zainstalować na serwerach EC2. Dodatkowo jednak istnieje możliwość wykorzystania WAF-a jako usługi AWS. Zaletą takiego wyboru jest to, że nie ma wówczas potrzeby konfiguracji dodatkowych serwerów i aplikacji, ponieważ utrzymaniem WAF-a zajmuje się w tym przypadku AWS. Dzięki WAF-owi użytkownik może zdefiniować reguły, które będą określały jakie typu żądania mają być akceptowane i przepuszczane do aplikacji a jakie mają być odrzucane. Przykładowo użytkownik może określić adresacje IP – whitelist/blacklist lub też wartości jakie muszą (lub nie mogą) znaleźć się w nagłówkach requestów, aby dane żądanie przepuścić do systemu. WAF-a jako usługę wbudowaną, wykorzystuje się poprzez integracje z CloudFront-em, który wcześniej został opisany.

VPC jest jedną z podstawowych usług chmury AWS i umożliwia definiowanie infrastruktury sieciowej, czyli zdefiniowanie takich elementów, jak adresacja IP, podsieci, tablice routingu itp. Dobrą praktyka pracy z chmurą jest rozpoczęcie tworzenia każdego nowego systemu poprzez zdefiniowanie jego infrastruktury sieciowej, której prawidłowe wykonanie pozwala ograniczyć możliwość ataku DDoS. Tego typu dobrymi praktykami będzie np. umieszczenie w podsieci publicznej (czyli takiej, która widoczna jest z Internetu) jedynie tych komponentów, które powinny być bezpośrednio dostępne z tego miejsca. Natomiast te elementy, które nie mają takich potrzeb (np. bazy danych), powinny być umieszczone w podsieciach prywatnych – co spowoduje, że nie zostaną im przydzielone publiczne adresy IP i nie będą natywnie wystawione na świat.

Diagram poniżej prezentuje przykładową architekturę aplikacji webowej o trójwarstwowej architekturze. Jak widać każda z warstw została umieszczona w dedykowanej podsieci. I tylko warstwa webowa jest umieszczona w podsieci publicznej, widocznej z Internetu.

AWS dodatkowo zapewnia dwa typy wbudowanych firewall-ów – tzw. Security Group oraz Network Access Control List (NACL). Dzięki tym mechanizmom użytkownik ma możliwość zdefiniowania, jaki ruch jest dozwolony pomiędzy jakimi serwerami i sieciami. Przykładowo dla powyższego diagramu, użytkownik mógłby skonfigurować VPC w ten sposób, że dostęp do serwerów bazodanowych jest dostępny tylko na porcie 3306 i tylko z serwerów aplikacyjnych.

Poniższy schemat prezentuje poszczególne warstwy modelu OSI – trzy z nich, stanowią cel większości ataków typu DDoS. Jest to warstwa aplikacyjna, transportowa i sieciowa. O ile jak bronić się przed DDoSem w warstwie aplikacyjnej już powiedzieliśmy (np. WAF), to pozostało jeszcze odpowiedzenie na pytanie jak radzić sobie przed tymi atakami w warstwach niższych, które stanowią główny odsetek ataków.

W ramach chmury AWS, każdy z użytkowników otrzymuje dostęp i ochronę w ramach tzw. Usługi Shield. Usługa ta działa w dwóch trybach: Standard oraz Advanced. Trybu Standard jest zawsze uruchomiony i, co ważne, nie wiąże się to z dodatkowymi kosztami. Dzięki Shield typu Standard systemy i aplikacje uruchomione  w chmurze są chronione przed większością ataków DDoS. Poziom Advanced dodatkowo daje np. jeszcze możliwość zbierania metryk odnośnie ataków oraz dostępu do specjalnego zespołu (działającego w trybie 24/7), który ma na celu wspomaganie użytkownika przy określeniu źródła ataku oraz konfiguracji sposób obrony przed nim.

Powyższe przykłady stanowią jedynie część z funkcji usług chmury, które mogą być wykorzystywane do ochrony przez atakami typu DDoS. Na takie ataki narażony jest każdy, kogo systemy (w tym strony WWW) są dostępne z Internetu. Przy tworzeniu tego typu systemów warto wykorzystywać już istniejące, natywne funkcje, dzięki którym możemy szybko zwiększyć bezpieczeństwo tychże systemów – zazwyczaj bez żadnych dodatkowych kosztów.

Szerszy opis mechanizmów obrony przez atakami typu DDoS można znaleźć w AWS-owym ‘whitepaper’ na temat obrony przez tego typu atakami, dostępnym pod adresem https://aws.amazon.com/whitepapers/.

Ciekawa prezentacja (1h) odnośnie ochrony DDoS:

Niezmiernie ciekawa prezentacja (zaczyna się od 30 minuty) odnośnie realnego przypadku ataku DDoS na jednego z użytkowników chmury AWS: