Jak bronić się przed atakami DDoS skutkującymi downtimem serwera?

Witam,

Mam Javascript, ktory jest uzyty na kilku innych (nie moich) stronach. Sam JS wyswietla dane z mojego publicznego API. Tylko pytanie, jak zastrzec te publiczne API do specificznej domeny? Samo API ma public jwt token, ale API jest wywolywane z poziomu JS, przegladarki uzytkownika. Wiec, jak mam sie zabezpieczyc, ze te API nie bedzie uzyte przez inne domeny czy uzytkownikow?

Jeśli do Twojego API strzela klient prosto z przeglądarki, to nie da się specjalnie tego zastrzec, bo skoro ktoś strzela z przeglądarki to równie dobrze mógłby strzelić z desktopa.

Myslalem o CORS

poniatowski napisał(a):

Myslalem o CORS

No to ktoś sobie wyłączy CORS w przeglądarce i strzeli pod Twoje API.

Czyli nie idzie w ogole tego obejsc?

Jak niby mozna to wylaczyc w przegladarce?

poniatowski napisał(a):

Czyli nie idzie w ogole tego obejsc?

No skoro Twoje API jest wystawione publicznie na świat, i potrzeba tylko JWT żeby się do niego dobić, a dodatkowo klienty mogą strzelać do niego prosto z przeglądarki, to równie dobrze ktoś może z curl'a strzelić pod to API, więc jak niby chciałbyś to zabezpieczyć?

poniatowski napisał(a):

Jak niby mozna to wylaczyc w przegladarce?

No normalnie, CORS to jest zabezpieczenie wbudowane w klienty HTTP, jako ochrona przed XSS i strzałem wyciąganiem danych z innych domen. Możesz korzystać z klientów które nie mają tego zabezpieczenia, albo mają ale wyłaczone.

To jak takie SDK zabezpieczyc? Mam kilka API endpointow i klient musi korzystac z nich z JS.

poniatowski napisał(a):

To jak takie SDK zabezpieczyc? Mam kilka API endpointow i klient musi korzystac z nich z JS.

Z JS czy z przeglądarki? Bo jeśli z JS, to znaczy że mógłby też z node'a?

Poza tym, po co masz blokować dostęp do jakichś konkretnych domen, co chcesz tym osiągnąć?

Jeśli wyniki z API nie są publiczne to musisz wprowadzić logowanie każdego użytkownika. I wtedy token dostanie tylko Pan Kazio, a Pan Mietek bez znajomości hasła i loginu nie tokena nie dostanie.
Piszesz, że używasz JWT to kto i jak się loguje i dostaje ten token.
Albo inaczej. Opisz przed czym dokładnie chcesz się ochronić.

jurek1980 napisał(a):

Jeśli wyniki z API nie są publiczne to musisz wprowadzić logowanie każdego użytkownika. I wtedy token dostanie tylko Pan Kazio, a Pan Mietek bez znajomości hasła i loginu nie tokena nie dostanie.
Piszesz, że używasz JWT to kto i jak się loguje i dostaje ten token.
Albo inaczej. Opisz przed czym dokładnie chcesz się ochronić.

Tylko Pan Kazio może tego samego tokenu używać na innej stronie ;) Mam wrazenie, ze OP chce się bronić przed alternatywnym klientem API, a takie ludzie robią, gdy oficjalne apki ssą albo są zawalone reklamami.

Generalnie, nie chce, zeby ktos inny korzystal z mojego API oraz umieszczal moj content na swoich stronach. MIalem juz kilka atakow na te endpointy. Wysylane wiele requestow, tak ze prawie server byl zablokowany. Zaliczalem downtime juz kilka razy

Jak uzyskać token?

Uzytownik zarejestorwnany do strony moze wejsc w ustawienia oraz wygenerowac token do public API.

Nie możesz po tokenie zidentyfikować który to gagatek przeprowadza ataki? I mu odciąć dostęp

Nie wiem w czym masz to napisane, ale dopisz/ustaw jakiś parametr typu 20 requestów do zrobienia w minutę, czy co tam masz, ktoś przekroczy to pokazujesz komunikat "too many request" 429 Poczeka 10 minut na następną serię.
Jak będzie ktoś generował wiele tokenów to można jeszcze zrobić podobny mechanizm per IP, tylko wiadomo, że może zdarzyć się, że masz wielu prawdziwych użytkowników na jednym IP publicznym, więc to wprowadzał bym po dłuższym przemyśleniu.
Nic więcej logicznie się nie da.

A tak BTW.
Te dane masz naprawdę unikalne, a nie że sami je gdzieś ciągnięcie z netu?

poniatowski napisał(a):

Generalnie, nie chce, zeby ktos inny korzystal z mojego API oraz umieszczal moj content na swoich stronach. MIalem juz kilka atakow na te endpointy. Wysylane wiele requestow, tak ze prawie server byl zablokowany. Zaliczalem downtime juz kilka razy

No to próbujesz rozwiązać zły problem.

Prześledźmy scenariusz:

• Udostępniasz API, gdzie każdy użytkownik dostaje token po zarejestrowaniu
• Używając tego tokena może się dobić do Twojego API
• miałeś sytuacje, gdzie ktoś wysyłał za dużo żądań, tak że prawie przeciążył server
• pomyślałeś że dobrym rozwiązaniem na to, będzie ograniczenie requestów do jakiejś jednej domeny
  • Ale po pierwsze, to nie koniecznie rozwiązałoby Twój problem, bo z jednej domeny nadal ktoś może wysłać wiele requestów
  • A po drugie, Twój faktyczny problem to jest zbyt wiele requestów na minutę
  • No i po trzecie, to co chcesz osiągnąć - czyli ograniczenie dostępu do pewnych domen, wydaje się praktycznie niewykonalne.
  • Odpowiednim wyjściem na to, byłoby ograniczenie ilości akceptowalnych żądań dla jednego użytkownika na raz

Klasyczny X/Y

Rozwiązanie:

• Nadaj limit żądań dla minutę dla każdego użytkownika posługującego się danym tokenem.

Ochrona przed DDoS to głównie ochrona na poziomie infrastruktury sieciowej, oczywiście poziom aplikacji też.

Jeżeli robisz API publicznie dla wszystkich to wszelkiego rodzaju tokeny i inne narzuty są niepotrzebne, to się wtedy robi inaczej.

Ja mam na wszystkich swoich serwisach odpalony autorski system automatycznego banowania jeżeli ktoś (adres IP) przekroczy określone limity (X) wywołań w ciągu określonego czasu (Y) co skutkuje banem też na określony czas (Z).

X = ilość wywołań
Y = okres czasu limitu - np. ostatnia godzina, dzień kalendarzowy, etc.
Z = czas zbanowania

Przy czym przed banem twardym jest jeszcze limit A (mniejszy niż Y), naruszenie go skutkuje wywołaniem testu captcha, rozwiązanie testu captcha daje danemu adresowi IP określoną pulę wejść bez limitu, lub przez określony czas nie musi go ponownie rozwiązywać.

Do tego biała lista np. dla robotów google, bing etc, oraz czarna lista dla największych skur... przepraszam spamerów - głównie Chiny, i tutaj mogę sobie dawać do czarnej / białej listy pojedyncze IP, całe klasy lub na podstawie nazwy hosta - dokładne dopasowanie lub regexp.

Taki system stosuje dla zwykłych wywołań HTTP, ale gdybym wystawiał tak publiczne API to tam też bym do tego zastosował, lub zrobił coś podobnego.

Od kilku lat stosuję i jestem oraz moi klienci - bardzo zadowolony, system przy okazji pokazuje skalę tego jak roboty zabijają strony. Na dość popularnej stronie mojego klienta (i mojej prywatnej też) dobijają się boty chatGTP, boty amazona AWS to gdybym pozwolił to robiłyby po 200 tys wywołań HTTP dziennie, nie wspominając o Chinczykach i innych syfiarzach którzy np. postanowili odpalić program do robienia odbicia lustrzanego Twojej strony do przeglądania offline.

Warto coś takiego mieć żeby uzmysłowić sobie skalę tego, w czasach GA tego się nie widzi, bo mało kto np. używa analizatora logów serwera lub cokolwiek innego co pokazuje to zjawisko.

@TomRZ taka odpowiedz ma juz wiecej sensu. Google Captach to tez jakies rozwiazanie, pewnie. Nie wiem jak to by bylo z uzycie API.

Samo sprawdzanie limitu oraz blokowanie adresow IP, gdzie to jest zrobione? Masz to napisane w kodzie w back-end, czy to jest poustawiane w na serwerach? Uzywasz jakis Cloud, AWS?

Czy w ogole mozna uzyc jakiegos serwius np od AWS zeby automatycznie blokowac takie requesty? Wiadomo, ze DDoS to nie jest 1 adres IP tylko cala grupa adresow.

Nie mam czasu wszystkiego opisywać, stworzenie tego systemu to było parę dni pracy, jak nie dłużej, nie pamiętam.

Technicznie to tak działa, że jest RAM DYSK, na nim baza SQLIte która zlicza wejścia poszczególnych IP - to najbardziej obciążająca operacja - zliczanie IP i zapisywanie tego gdzieś, jednocześnie nie są to bardzo ważne dane.

Dlatego ramdysk jest idealny - zapis nie powoduje obciążenia I/O a w przypadku restartu i utraty danych, nic wielkiego się nie dzieje.

Zasady białej/czarnej listy i inne dane wymagające stałego zapisu to już osobna baza danych PostgreSQL na twardym dysku.

Tak to mniej więcej wygląda, i tak zdradziłem, i powiedziałem dużo :P

Moja apka dziala na AWS. I widze, ze moze AWS ma jakies serwisy sluzace do automatycznej blokowania. https://aws.amazon.com/blogs/security/automatically-block-suspicious-traffic-with-aws-network-firewall-and-amazon-guardduty/

Wiadomo, ze z tym raczej nie uzyjemy captcha, ale jak wystawiamy public API to te API jest uzyte na nie naszej stronie, wiec i captch'a sami nie dodamy.

Ale to chodzi bardziej o zabezpieczenie przed samym DDos czy jednak jakieś ograniczenie od strony dostępu. Teraz temat zmieniony, a wcześniej problem wyglądał inaczej.
BTW np w Laravel masz Throtle na midlleware
https://laravel.com/docs/8.x/rate-limiting
W SF też
https://symfony.com/doc/current/rate_limiter.html
Nie trzeba do tego pisać dodatkowych skryptów i od razu masz też obsługę zapisu odczytu w Redis czy tam memcache.

jurek1980 napisał(a):

Ale to chodzi bardziej o zabezpieczenie przed samym DDos czy jednak jakieś ograniczenie od strony dostępu.

Tzn. są różne ataki DDoS, są takie gdzie obrona jest na poziomie sieciowym - to są zabawy z protokołem TCP/IP, wysyłanie jakichś toksycznych ramek, tego typu rzeczy - wiesz o czym piszę - i tutaj bronimy się na poziomie routera / etc.

Są też ataki DDoS gdzie wszystko jest sieciowo OK, i "hostingodawca" ruch przepuszcza, ale jest to tak duży ruch i tak zrobiony, uderzający w takie strony, że system staje się niewydolny - i wtedy przydaje się takie rozwiązanie jak moje / podobne - działające na poziomie aplikacji.

poniatowski napisał(a):

Moja apka dziala na AWS. I widze, ze moze AWS ma jakies serwisy sluzace do automatycznej blokowania. https://aws.amazon.com/blogs/security/automatically-block-suspicious-traffic-with-aws-network-firewall-and-amazon-guardduty/

NIe czytałem tego szczegółowo, ale chyba masz tam właśnie podobny mechanizm - możesz sobie ustalać różne zasady bezpieczeństwa i limity, pobaw się tym.

@TomRZ: ja wiem. Ale przeszliśmy od używania API poza stronami OPa do DDoS na poziomie sieciowym. Tytuł wątku byl zmieniony w czasie. Wcześniej o żadnym DDoS nie było mowy. I uważam, że jeśli chcemy myśleć o DDoS ogólnie to trzeba zrobić jak się da i na poziomie sieci i na poziomie apki.

Chodzi bardziej o ataki. Poco komu inne limity?

YII2

https://www.yiiframework.com/doc/guide/2.0/en/rest-rate-limiting
No i porównaj teraz dokumentację z tym co opisałem.
Masz jakiś, gotowy mechanizm "z pudełka".

Generalnie co bys nie zrobil, to jesli atakujacy beda wystarczajaco zdeterminowani, to spowoduja DoS ostatecznie. Mozesz stosowac pewne metody antyflood itd na serwerze, ale musialbys schodzic nizej i nizej az do poziomu serwera DNS. Zeby calkowicie sie przed tego typu atakami zabezpieczyc, musialbys uzyc CDN oraz cos w rodzaju "api protector". Chociaz to tez zalezy od rozmiaru botnet, no ale generalnie wiekszosc dostawcow produktow CDN ma dosc duza zdolnosc pochlaniania atakow, czesto sa to poziomy TBps. Oczywiscie rozmawiamy w tym momencie o rozwiazaniu typowo enterprise, ale sa tez prostsze/tansze CDN i w wiekszosci przypadkow zalatwi to sprawe.

Myslalem, ze CDN jest glownie do zdjec etc. Mieszkasz w USA ? Fajna flaga stanow w awatarze :) Nice one!

Dla mnie nie jest wciąż jasne przed czym tak naprawdę chcesz się bronić.

1. Złośliwe ataki DDoS na twój backend
2. "Kradzież" danych. Np. masz stronę, na której prezentujesz jakieś dane i finansujesz ją z reklam, a ktoś tworzy sobie kopię, podpina się do twojego backendu i wstawia swoje banery.

I teraz:
Przed 1'ką nie da się obronić w 100%. Pytanie jakie koszty obrony ty chcesz ponieść (zabezpieczenia + nadmiarowa infrastruktura) i jakie koszty chce ponieść atakujący.
Przed 2ką też się nie zabezpieczysz, jeżeli jest to publiczna strona, na którą jest w stanie wejść dowolny użytkownik bez uwierzytelnienia. Komunikacja pomiędzy OPA i backendem jest dla użytkownika jawna, kod OPA i wszystkie potencjalne zabezpieczenia też są jawne. Skoro użytkownik jest w stanie sprawdzić jak OPA sobie radzi z nawiązywaniem komunikacji, to jest w stanie odtworzyć ten proces po swojej stronie. Oczywiście da się robić jakieś sprytne haki, żeby było trudniej, ale ogólnie, to nie ma się co spodziewać długoterminowych sukcesów.

Glownie chodzi o obrone przed atakami DDoS. Ale tez o to, zeby ludzie nie korzystali z tego public API i umieszczali moja tresc na swoich stronach. Tak, chodzi o te dwa czynniki.

Co to OPA?

No to obrona przed DDoS to:
Odpalenie WAF'a i włączenie ochrony. Problem w tym, że to potrafi sporo kosztować (np. w Azure 2k USD miesięcznie z tego co pamiętam)
Zadbanie, żeby publiczne endpointy (nie wymagające uwierzytelnienia) były napisane optymalnie i nie pozwalały np. na generowanie nadmiernego obciążenia infrastruktury.
Wymaganie uwierzytelnionych użytkowników tam gdzie to możliwe i sprawne obsługiwanie prób uwierzytelnienia oraz szybkie uwalanie żądań gdzie uwierzytelnienie nie jest możliwe (np. brak JWT, albo błędny JWT)
W przypadku mikroserwisów dochodzą takie rzeczy jak circuit breaker. Warto też przemyśleć skalowanie infrastruktury - zakładając, że aplikacja na to pozwala, to czy chcesz przeczekać DDoS, czy zapłacić za infrastrukturę, która te dodatkowe żądania ogarnie.

A, najprostszym sposobem na uniknięcie wykorzystywania danych z "boku" jest wymuszenie logowania użytkownika.

--Edit
@poniatowski: wspomniał jeszcze o CORS i pomysł został słusznie skrytykowany przez @Riddle, ale...
O ile nie stanowi to żadnego zabezpieczenia przed odpytaniem serwera z jakiegoś postmana, czy "nie przeglądarki", to stanowi pewną ochronę, jeżeli zakładamy, że atakujący chce wystawić prostą stronkę, która będzie pobierać i wyświetlać dane wewnątrz swoich reklam, czyli w takim scenariuszu:

Tylko atakujący może zrobić coś takiego:

Natomiast:

• Nie wykona w ten sposób ataku DDoS, bo wszystkie żądania przechodzą przez jego infrastrukturę
• Wszystkie żądania będą pochodzić z jednego IP (lub jakiegoś tam zakresu), więc wystarczy je zidentyfikować i wrzucić na black list pojedynczy adres IP.