Żądania uwierzytelniane bez ograniczeń *

Załóżmy, że mamy moduł równoważenia obciążenia, który także ogranicza szybkość. Ograniczanie prędkości wydaje się dość proste dla zalogowanych użytkowników - wystarczy spojrzeć na JWT i być może użyć magazynu danych w pamięci, aby zobaczyć, ile żądań w ciągu ostatnich 10 sekund dla tego użytkownika.

A co z niezalogowanymi (nieuwierzytelnionymi) użytkownikami? Nie wiemy na pewno, od kogo lub skąd pochodzi żądanie, więc nie można łatwo ograniczyć tych żądań lub ...?

Czy istnieją wbudowane rozwiązania tego problemu na AWS i innych platformach hostingowych, czy jest to coś, o co musimy się martwić? Wydaje się, że musimy ręcznie obsługiwać logikę ograniczającą szybkość zalogowanych użytkowników, ale co z niezalogowanymi użytkownikami?

Domyślam się / mam nadzieję, że może istnieć jakiś wbudowany mechanizm ograniczania nieuwierzytelnionych żądań na platformach hostingowych, prosimy o poinformowanie nas wszystkich.

A co z niezalogowanymi (nieuwierzytelnionymi) użytkownikami? Nie wiemy na pewno, od kogo lub skąd pochodzi żądanie, więc nie można łatwo ograniczyć tych żądań lub ...?

Istnieje kilka metod, które możesz zastosować. Jednym z nich jest to, że potrzebujesz rozsądnie wiarygodnego identyfikatora pochodzenia, na przykład adresu IP. Możesz oceniać limit według adresu IP, dzięki czemu ataki na jedną zainfekowaną maszynę będą ograniczone. Jest to dość proste podejście, ale ma tę wadę, że istnieją duzi dostawcy sieci, którzy mogą używać tylko pojedynczych wychodzących adresów IP, aby ukryć bardzo dużą liczbę użytkowników za NAT.

Innym podejściem do ograniczenia stawek, które można zastosować, jest wymaganie dowodu pracy w przypadku nieuwierzytelnionych żądań. Serwer wysyła kod wyzwania, że ​​każdy klient wysyłający nieuwierzytelnione żądanie (np. Żądanie logowania) musi obliczyć odpowiedź wymagającą dużej ilości zasobów, zanim żądanie zostanie przetworzone. Częsta implementacja tego pomysłu wymaga od klientów obliczenia częściowego cofnięcia skrótu.

Aby wiedzieć, czy żądanie pochodzi od uwierzytelnionego użytkownika, czy anonimowego użytkownika, musisz koniecznie przetworzyć żądanie (choć szybko). Nadal oznacza to, że twoja aplikacja jest podatna na atak typu „odmowa usługi”.

Powinieneś sprawdzać ogólne żądania na sekundę, a jeśli pewna liczba zostanie przekroczona, po prostu zignoruj ​​resztę. Liczba ta powinna być wystarczająco wysoka, aby nie powodować problemów podczas normalnego funkcjonowania, ale powinna chronić przed takimi atakami.

Zasadniczo nie należy też zakładać, że atak nie zostanie przeprowadzony przez uwierzytelnionego użytkownika, przynajmniej jeśli chodzi o ataki DOS. Słabe hasło pozwoliłoby łatwo założyć tożsamość starego użytkownika. Zakładając, że możesz wykonać taką kontrolę, Twoi (ludzcy) użytkownicy nigdy nie powinni być zmuszeni do wykonywania żądań z takimi stawkami, nie przejmując się po prostu dlatego, że masz wielu indywidualnych użytkowników.

Jedną z głównych ofert Cloudflare jest ochrona przed atakami Denial of Service poprzez zapewnienie inteligentnego serwera proxy dla twojego API / serwera WWW. Podstawowa usługa jest bezpłatna; zarabiają na innych powiązanych usługach, takich jak usługi CDN i równoważenie obciążenia. Zapewniają również bardziej wyrafinowane i kontrolowane usługi ograniczania stawek, obecnie w wysokości 0,05 USD za 10 tys. Dobrych wniosków (bez opłat za odrzucone wnioski), ale musisz przejść na płatne plany, aby uzyskać więcej niż jedną globalną regułę.

Możesz korzystać z usługi Cloudflare z AWS lub dowolną inną platformą, o ile masz kontrolę nad serwerami nazw swojej domeny (tak jak w tym przypadku, możesz zmienić serwery nazw zarejestrowane dla Twojej domeny).

Możesz podać osobne limity stawek dla anonimowych i zalogowanych użytkowników, kierując zalogowanych użytkowników na różne adresy URL. Na przykład możesz po prostu poprzedzić wszystkie dostępne anonimowo ścieżki URL znakiem „/ u”, aby utworzyć punkt końcowy, który zawsze wymaga uwierzytelnienia i ma inny limit szybkości.

Pamiętaj, że ograniczenie stawek Cloudflare (podobnie jak wszystkie ograniczenia stawek komercyjnych dla anonimowych użytkowników, których znam) określa klienta na podstawie jego adresu IP. Może to powodować problemy dla osób korzystających z komercyjnych sieci VPN lub Tora, ponieważ mają tendencję do ukrywania dużej liczby klientów za 1 adresem IP w celu zwiększenia prywatności.

W AWS istnieją powiązane usługi AWS Shield i AWS WAF . Są one przede wszystkim przeznaczone do zapobiegania atakom DDoS, ale także oferują obsługę ograniczania prędkości na podstawie adresów IP.

W WAF koncepcja nazywa się Regułami Opartymi na Stawkach . Zapobieganie próbom logowania opartym na brutalnej sile jest wspomniane jako przypadek użycia w pierwotnym ogłoszeniu :

Ten nowy typ reguł chroni witryny internetowe klientów i interfejsy API przed zagrożeniami, takimi jak ataki DDoS w warstwie internetowej, próby logowania z użyciem brutalnej siły i złe boty. Reguły oparte na stawkach są uruchamiane automatycznie, gdy żądania sieciowe od klienta przekroczą określony konfigurowalny próg.

Inni dostawcy usług w chmurze powinni mieć podobne oferty. Oto porównanie tabelaryczne: Google Cloud Armor vs. AWS WAF vs. Cloudflare WAF .

Ponieważ już korzystasz z Nginx, użycie wbudowanego ograniczenia prędkości opartego na IP może być również prostą opcją. Moduł nazywa się ngx_http_limit_req_module . Ten post na blogu opisuje, jak można z niego korzystać.

Pamiętaj, że ograniczenie prędkości oparte na IP jest stosunkowo prostą koncepcją, ale nie jest idealne:

• Adresy IP mogą być współużytkowane (osoby pracujące w tym samym biurze), co prowadzi do fałszywych trafień
• Osoba atakująca może mieć łatwy dostęp do wielu adresów IP i wykorzystywać je do ominięcia limitów (rozproszony atak logowania typu brute-force)

Zasadniczo adresy IP to dobry początek. Ale jeśli potrzebujesz silniejszej ochrony, twoje najlepsze wybory będą zależeć od twojego modelu wątku (jakiego rodzaju ataków chcesz zapobiec).