Atak DDoS przez mechanizmy Facebooka

•

Strona użytkownika Mikrus VPS została zaatakowana atakiem DDoS w nietypowy sposób - agresorem był... Facebook. 69+ tysięcy requestów w kilka godzin. Strona padła - przynajmniej na chwilę. Jak to w ogóle możliwe? 🧵 ↓

Sprawa zaczęła się niewinnie. Klient hostował stronę, która bardzo nie spodobała się pewnym osobom (wrażliwy temat). Postanowili ją wyłączyć. Mogli użyć botnetu, ale to łatwo wyciąć, bo źródłowe adresy IP to przeważnie Indie, Pakistan itp. Potrzebowali czegoś lepszego.

Facebook ma swojego crawlera, który wchodzi na strony, pobiera dane i cache'uje metadane. To dzięki niemu widzisz np. podglądy linków na Messengerze. Crawler ma zabezpieczenia - nie wejdzie tysiące razy na ten sam URL.

A co, jeśli dodasz do URL parametr, który nic nie robi? Załóżmy: ?fake=123, ?fake=321 itd. Facebook rozpoznaje taką sztuczkę. Gdy parametry nie zmieniają strony, uznaje je za zbyteczne i przestaje odświeżać cache.

Użytkownik miał na stronie wyszukiwarkę. Działała metodą GET. Fraza w URL. Coś na wzór: ?query=zabawne-kotki Problem? Wyszukiwarka ZAWSZE zwracała wyniki. Nawet przy śmieciach w query generowała "najbardziej pasujące artykuły". Każdy URL wyglądał na unikalny dla FB.

W logach widzimy, że strona leży. Sprawdzam logi. 69 tysięcy requestów. Wszystkie z pul IP Facebooka. Mój pierwszy pomysł: zbanować je wszystkie! Szybko!

Sprawdzam, ile to w ogóle jest adresów. whois -h whois.radb.net -- '-i origin AS32934' Facebook ma 1987 prefiksów IPv4 i 1848 prefixów IPv6. Ok, da się to zbanować. Ale...

Jeśli zbanujemy Facebooka, strona użytkownika praktycznie zniknie z FB. Nie będzie podglądów przy udostępnianiu. Nie będzie linków. Nie zadziałają niektóre mechanizmy. To byłaby strata dla usera.

Jako admini nie mogliśmy też przerabiać kodu strony klienta. Musieliśmy rozwiązać to na poziomie współdzielonego serwera Nginx. Pierwszy pomysł: rate limiting. Problem? Klasyczny limiter per IP nie ma sensu, gdy mamy do czynienia z potencjalnie milionami źródeł 'ataku'.

Potrzebowaliśmy połączyć wszystkie pule adresowe Facebooka w jedną całość. Użyliśmy map w Nginx. Każdy request z puli Facebooka podbija jeden wspólny licznik limitera, czyli miliony źródeł liczą się jako jedno źródło: META. Ale to nie koniec.

Nie mogliśmy zwrócić kodu 403 (brak dostępu). Crawler zapamiętałby "nie wolno tu wchodzić" i funkcje FB przestałyby działać. Musieliśmy użyć kodu 429 (too many requests) + nagłówek "retry-after". Crawler wie: "okej, wrócę później".

Wdrożyliśmy rozwiązanie. Atak ustał. Strona wstała. Strona klienta działa. Podglądy na Facebooku działają. Atakujący się poddali. Wprowadziliśmy jeszcze kilka innych zabezpieczeń, ale to już temat na osobny wątek.

Dla mnie najciekawsze ataki to te, które wykorzystują legalne narzędzia w nieoczywisty sposób. Niestety, obrona przed nimi to często balansowanie między bezpieczeństwem a funkcjonalnością. Opisywać resztę zabezpieczeń? 🤔