W porządku, wystarczy przeciągać; oto co wymyśliłem do tej pory
(przepraszam, długi post. Bądź odważny, przyjacielu, podróż będzie tego warta)
Łączenie metod 3 i 4 z oryginalnego postu w rodzaj „rozmytej” lub dynamicznej białej listy, a następnie - i oto sztuczka - nie blokowanie adresów IP spoza białej listy, tylko dławienie ich do piekła i z powrotem .
Należy pamiętać, że ten środek ma na celu jedynie udaremnienie tego bardzo specyficznego rodzaju ataku. W praktyce oczywiście działałby w połączeniu z innymi najlepszymi sposobami podejścia do uwierzytelniania: ograniczanie stałej nazwy użytkownika, ograniczanie dla poszczególnych adresów IP, polityka silnych haseł wymuszana kodem, logowanie do niezakłóconych plików cookie, haszowanie wszystkich odpowiedników haseł przed ich zapisaniem, nigdy używanie pytań zabezpieczających itp.
Założenia dotyczące scenariusza ataku
Jeśli atakujący kieruje się na zmienne nazwy użytkowników, funkcja ograniczania przepustowości nazw użytkowników nie zostanie uruchomiona. Jeśli atakujący używa botnetu lub ma dostęp do dużego zakresu adresów IP, nasze dławienie adresów IP jest bezsilne. Jeśli osoba atakująca wstępnie zeskrobała naszą listę użytkowników (zwykle jest to możliwe w usługach internetowych z otwartą rejestracją), nie możemy wykryć trwającego ataku na podstawie liczby błędów „nie znaleziono użytkownika”. A jeśli wymusimy restrykcyjne dławienie w całym systemie (wszystkie nazwy użytkowników, wszystkie adresy IP), każdy taki atak spowoduje DoS całą naszą witrynę na czas trwania ataku plus okres ograniczania przepustowości.
Więc musimy zrobić coś innego.
Pierwsza część środka zaradczego: Biała lista
Możemy być całkiem pewni, że atakujący nie jest w stanie wykryć i dynamicznie sfałszować adresów IP kilku tysięcy naszych użytkowników (+). Co sprawia, że biała lista jest możliwa. Innymi słowy: dla każdego użytkownika przechowujemy listę (zahaszowanych) adresów IP, z których użytkownik wcześniej (ostatnio) się logował.
W ten sposób nasz schemat białej listy będzie funkcjonował jako zamknięte „drzwi wejściowe”, w przypadku których użytkownik musi być połączony z jednym ze swoich uznanych „dobrych” adresów IP, aby w ogóle się zalogować. Atak siłowy na te „drzwi frontowe” byłby praktycznie niemożliwy (+).
(+) chyba, że atakujący „jest właścicielem” serwera, wszystkich skrzynek naszych użytkowników lub samego połączenia - iw takich przypadkach nie mamy już problemu z „uwierzytelnianiem”, mamy prawdziwą wersję typu pull-the -plug sytuacja FUBAR
Druga część środka zaradczego: ograniczanie nierozpoznanych adresów IP w całym systemie
Aby biała lista działała dla usługi internetowej z otwartą rejestracją, w której użytkownicy często zmieniają komputery i / lub łączą się z dynamicznych adresów IP, musimy pozostawić „kocie drzwiczki” otwarte dla użytkowników łączących się z nierozpoznanych adresów IP. Sztuczka polega na takim zaprojektowaniu tych drzwi, aby botnety utknęły w miejscu, a legalnym użytkownikom jak najmniej przeszkadzano .
W moim schemacie osiąga się to poprzez ustawienie bardzo restrykcyjnej maksymalnej liczby nieudanych prób logowania przez niezatwierdzone adresy IP w okresie, powiedzmy 3 godzin (rozsądniej jest użyć krótszego lub dłuższego okresu w zależności od rodzaju usługi) oraz uczynienie tego ograniczenia globalnym , tj. dla wszystkich kont użytkowników.
Nawet powolna (1-2 minuty między próbami) brutalna siła byłaby wykryta i udaremniona szybko i skutecznie przy użyciu tej metody. Oczywiście naprawdę powolna brutalna siła może pozostać niezauważona, ale zbyt wolne prędkości pokonują cel ataku brutalnej siły.
Mam nadzieję, że dzięki temu mechanizmowi dławienia mam nadzieję, że po osiągnięciu maksymalnego limitu nasze `` drzwiczki dla kota '' zatrzaskują się na chwilę, ale nasze drzwi wejściowe pozostają otwarte dla legalnych użytkowników łączących się w zwykły sposób:
- Albo przez połączenie z jednego z ich rozpoznanych adresów IP
- Lub za pomocą trwałego pliku cookie logowania (z dowolnego miejsca)
Jedyni uprawnieni użytkownicy, którzy zostaliby dotknięci podczas ataku - tj. gdy dławienie zostało aktywowane - byliby to użytkownicy bez trwałych plików cookie logowania, którzy logowali się z nieznanej lokalizacji lub z dynamicznym adresem IP. Tacy użytkownicy nie mogliby się zalogować, dopóki dławienie nie ustąpi (co może zająć trochę czasu, jeśli atakujący utrzymałby swój botnet pomimo ograniczenia).
Aby pozwolić tej niewielkiej grupie użytkowników przecisnąć się przez inaczej zaplombowane drzwi dla kota, nawet gdy boty wciąż w nie walą, zastosowałbym „zapasowy” formularz logowania z CAPTCHA. Tak więc, kiedy wyświetli się komunikat „Przepraszamy, ale w tej chwili nie możesz zalogować się z tego adresu IP”, umieść link o treści „ bezpieczne logowanie kopii zapasowej - TYLKO LUDZIE ( boty: bez kłamstwa ) ”. Żartuj na bok, kiedy klikną ten link, przekaż im formularz logowania uwierzytelniony przez reCAPTCHA, który omija ograniczanie przepustowości w całej witrynie. W ten sposób, JEŻELI są ludźmi ORAZ znają poprawny login i hasło (i potrafią odczytać CAPTCHA), nigdy nie otrzymają odmowy usługi, nawet jeśli łączą się z nieznanego hosta i nie używają pliku cookie autologowania.
Aha, i tylko dla wyjaśnienia: ponieważ uważam, że CAPTCHA są ogólnie złe, opcja logowania „zapasowa” pojawiała się tylko wtedy, gdy dławienie było aktywne .
Nie można zaprzeczyć, że taki długotrwały atak nadal stanowiłby formę ataku DoS, ale z opisanym systemem wpłynąłby tylko na to, co podejrzewam, że jest niewielką podgrupą użytkowników, a mianowicie na osoby, które nie używają plik cookie „zapamiętaj mnie” ORAZ loguje się podczas ataku ORAZ nie loguje się z żadnego ze swoich zwykłych adresów IP ORAZ nie może odczytać CAPTCHA. Tylko ci, którzy mogą odmówić WSZYSTKIM z tych kryteriów - w szczególności botom i naprawdę pechowym osobom niepełnosprawnym - zostaną odrzuceni podczas ataku botów.
EDYCJA: Właściwie wymyśliłem sposób, aby pozwolić nawet użytkownikom z wyzwaniami CAPTCHA przejść przez `` blokadę '': zamiast lub jako dodatek do zapasowego loginu CAPTCHA, zapewnić użytkownikowi opcję jednorazowego użytku , specyficzny dla użytkownika kod blokujący wysłany na jego e-mail, którego może użyć do ominięcia ograniczania przepustowości. To zdecydowanie przekracza mój próg `` irytacji '', ale ponieważ jest używany tylko w ostateczności dla niewielkiej części użytkowników, a ponieważ nadal jest lepszy od zablokowania konta, byłoby to do przyjęcia.
(Zwróć również uwagę, że nic z tego się nie dzieje, jeśli atak jest mniej wyrafinowany niż paskudna wersja rozproszona, którą tutaj opisałem. Jeśli atak pochodzi z zaledwie kilku adresów IP lub dotyczy tylko kilku nazw użytkowników, zostanie udaremniony znacznie wcześniej i bez konsekwencji dla całej witryny)
Jest to więc środek zaradczy, który zaimplementuję w mojej bibliotece auth, kiedy będę przekonany, że to dźwięk i że nie ma prostszego rozwiązania, którego nie przegapiłem. Faktem jest, że istnieje tak wiele subtelnych sposobów robienia rzeczy źle w zakresie bezpieczeństwa, a ja nie jestem wolny od fałszywych założeń lub beznadziejnie błędnej logiki. Więc proszę, wszelkie opinie, krytyka i ulepszenia, subtelności itp. Są bardzo mile widziane.