Cloudflare to nie wszystko.

lukado
Ponad 15 lat w branży IT. Konsultant i architekt projektów Amazon Web Services. Entuzjasta rozwiązań serverless. Współtwórca AWS User Group (3500+ osób). AWS Community HERO. Masz pytanie, napisz do mnie.

W zeszłym tygodniu miałem “przyjemność” doświadczyć drobnego ataku DDoS na jeden z moich serwisów hostowanyych w AWS. Postanowiłem więc w ramach takiego tips&tricks krótko napisać o co chodziło.

Oczywiście wszystko wynikało z faktu lenistwa i odłożeniu czegoś na potem. Atak był typem syn-flood, ogromna ilość inicjowanych sesji tcp wysycała zasoby i jako pierwszy wywalał się serwis mysqld. Z racji, że moje środowisko jest dość małe i proste (bo tyle narazie mi wystarcza), nie używam tu żadnej wielonodowości baz, autoscalowania itp. Prosty serwer z webserwisem i bazą.

Cloudflare nie rozwiąże wszystkich problemów

Dla tych co nie wiedzą, Cloudflare (CF) jest serwisem oferującym szeroką paletę usług wspomagających strony internetowe. Zaczynając od DNS, poprzez usługi CDN, cache, optymalizacja oraz ochrona przed DDoS.

Ja wykorzystuję Cloudflare dla swoich webserwisów głównie jako DNS, obsługa SSL oraz ochrona przed DDoS. Jednak mimo tego oberwałem DDoSem. Ale dlaczego? To poniżej.

Cloudflare działa w ten sposób, że zapytanie dla nazwy domenowej rozwiązywane jest na jakichś tam adres IP z ich puli. Dzięki temu ruch trafia do ośrodków CF i tam jest “obrabiany”, a nastepnie przekazywany już prosto na adres IP naszego webserwisu.

Monitorując ruch podczas ataku na webserwerze (tcpdump) zauważyłem mnóstwo sesji inicjowanych z kilku adresów IP. W CloudWatch widać było wzrost ruchu sieciowego, ale Monitoring w Cloudflare nic nie notował.
Po dalszej analizie okazało się, że celem ataku nie był mój adres DNS, a bezpośrednio adres IP webserwisu (Elastic IP). Widocznie ktoś nie lubi AWS i postanowił walnąć w jakąś ich pule adresów z której przydzielają Elastic IP.

Z tego właśnie powodu, że ruch szedł prosto z pominięciem CloudFlare używanie tego rozwiązania nic nie dało.

Jak się bronić

Oczywiście podczas ataku na szybko po prostu zablokowałem na Access-List całą pulę adresów IP z których szły zapytania.

Patrząc jednak na docelowe rozwiązanie, w moim wypadku wystarczyło poprostu zakleić trochę Security Groupę i wpuszczać ruch tylko z puli należących do CloudFlare. Info z adresacją szybko udało się znaleść w necie: CloudFlare IP Ranges Można dodatkowo zmienić domyślne porty w backendzie na inne niż 80 czy 443.

Jeśli masz jakąś inną metodą pisz śmiało w komentarzach 🙂



Zbuduje swoje bezpieczne środowisko AWS.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

🔔Trwają zapisy na szkolenie otwarte AWS "4" IT Professionals 09-10 Kwietnia
This is default text for notification bar