https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:15:14 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10725 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Paweł Goleń) Jeśli mail, który podałeś w komentarzu działa, to posłałem na niego mój PoC. Nie sądzę byś miał z niego wielki pożytek tak od razu, ale skoro jesteś zainteresowany - proszę :) Wed, 21 Nov 2012 17:54:36 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10725 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10723 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Tomek) Właśnie szukam jakiegoś nieinwazyjnego rozwiązania anty-botowego, bo jak się okazuje (via http://www.jogger.pl) reCAPTCHA już nie zawsze działa, pomijając to że jest coraz bardziej skomplikowana do rozszyfrowania w mojej opinii. Natknałem się na kilka implementacji, które wstawiały różnego rodzaju znaczniki/wymuszały obliczenia via JavaScript (+obsfucusowały kod za to odpowiedzialny) i z tego co piszą były dość skuteczne. Nie wiem jak z takim botem który "korzysta" z przeglądarki, ale równie dobrze można reCAPTCHA'ę podłożyć człowiekowi do rozwiązania. Myślę, że dopóki są "łatwe" cele ataku, to bot odpuści, chyba, że wartością jest tak jak w przypadku Joggera PageRank 5 strony. Hmm, masz gdzieś ten kod wystawiony? Wed, 14 Nov 2012 16:42:39 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10723 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10721 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Paweł Goleń) Przykładową implementację? Cóż, skrobnąłem sobie PoC w Pythonie, ale to raczej nie o to chodzi :) Jeśli chodzi o wykorzystanie takiego podejścia jako ochronę przed spamem, to mam wątpliwości. Na pewno spowodowałoby to znaczne zwiększenie "kosztu" wysłania jednej wiadomości przez co zmniejszyłoby opłacalność tego procederu. Poza tym ktoś musiałby te boty zaprogramować do obsługi tych "puzzli". Nie jest to nie do zrobienia, ale komuś musiałoby się chcieć to zrobić. Może rzeczywiście na jakiś czas miałoby to szansę działać. Ale co z botami, które "korzystają" z przeglądarki? Wracamy do punktu wyjścia - jedynym kosztem w tym wypadku jest czas potrzebny na rozwiązanie puzzla. Wed, 14 Nov 2012 16:33:13 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10721 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10719 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Tomek) Hmm, to mi wygląda na całkiem dobre rozwiązanie anty-spamowe (zakładając JavaScript po stronie klienta) przed botami, a jednocześnie przezroczyste (nie trzeba stosować żadnych typów captchy). Mam rację? Znasz może jakąś przykładową implementację? Pozdrawiam Tomek Wed, 14 Nov 2012 13:57:35 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10719 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10332 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Paweł Goleń) To nie jest do końca tak. Mnie w tym wypadku chodzi przede wszystkim o application-level DoS. Mam na myśli takie sytuacje, w których prawidłowe i "legalne" żądanie klienta wymaga stosunkowo dużych zasobów serwera do jego obsłużenia. Czyli zasoby, które musi posiadać klient nie są w tym wypadku istotne. Przykładowo może być tak, że operacja uwierzytelnienia wymaga odwołania do kilku systemów (np. realizowanych przez SOA), pobrania sporej ilości danych (np. historii operacji), albo wielu operacji na bazie danych (np. aktualizacja różnych rekordów). Czasami okazuje się, że te operacje powiązane są z wąskim gardłem w systemie i nawet JEDEN atakujący jest w stanie doprowadzić do jego zablokowania. Albo inaczej - wąskim gardłem jest np. szyna SOA, a te proste operacje w łatwy sposób mogą doprowadzić do jej przeciążenia i zablokowania lub poważnej degradacji wydajności WSZYSTKICH systemów z niej korzystających, również tych kompletnie bez związku z atakowaną aplikacją i niewystawionych do sieci. W takiej sytuacji load balancer nic nie da, bo sam serwer wyrabia, nie wyrabia natomiast środowisko, z którego aplikacja korzysta i niespecjalnie jest co w tym przypadku balansować. Również WAF pomoże tutaj w ograniczonym stopniu. Może próbować limitować ilość żądań od jednego klienta, ale w tym wypadku (hipotetyczna kosztowna operacja uwierzytelnienia) klient nie jest uwierzytelniony, więc może to co najwyżej robić po IP, a zmiana tego IP przez atakującego nie jest żadnym problemem. Limitowanie "globalne" (czyli maksymalna ilość dopuszczalnych żądań od WSZYSTKICH użytkowników) również nie jest dobrym rozwiązaniem. Co prawda prawdopodobnie rozwiąże to problem wąskiego gardła, ale stwarza kolejny potencjalny sposób ataku DoS - wygenerowanie dużej liczby żądań przez co "prawidłowe" żądania od "uczciwych" klientów nie są przetwarzane przez serwer. Broniąc się przed zatkaniem wąskiego gardła zostało stworzone kolejne wąskie gardło, które po prostu zapycha się wcześniej. Jeśli natomiast w jakiś sposób zwiększymy koszt wywołania takiej metody, atak będzie trudniejszy do przeprowadzenia. Po prostu atakujący do jego przeprowadzenia będzie potrzebował większych zasobów. Będzie oczywiście w stanie je zdobyć, ale stopień skomplikowania ataku wtedy rośnie. Tue, 13 Nov 2012 07:26:10 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10332 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10325 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (slaw) Imo atak 1 klienta nie jest tak bardzo grozny ze wzgledu ze dysponuje on (zazwyczaj) o kilka rzedow wielkosci mniejszymi zasobami. Sprawa moze sie troche skomplikowac gdy mamy delikwenta w LANie. Wewnatrz infrastruktury przywiazuje sie zdecydowanie mniejsza wage do zabezpieczania przed DoSem i czesto sie okazuje ze do dyspozycji mamy cale spektrum podatnosci z OSPFowa Dijkstrą i ipv6 wlacznie. W Twoim przypadku pokusilbym sie o tuning load balancerow/wafów zeby tego typu atakom sie opieraly. W przypadku DDoS to chyba tylko mozna probowac dogadac sie z operatorem. Mon, 12 Nov 2012 20:44:41 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10325 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10274 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Paweł Goleń) Nie, bo: - sleep kosztuje serwer zasoby, - sleep nie kosztuje klienta nic (poza drobnym opóźnieniem między złożeniem zapytania a otrzymaniem odpowiedzi), Mon, 12 Nov 2012 10:19:10 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10274 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#c10273 https://archive.mroczna-zaloga.org/archives/1154-limitowanie-klienta.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1154 nospam@example.com (Abc) A moze walnij 'slipa' poprostu... Mon, 12 Nov 2012 09:00:31 +0100 https://archive.mroczna-zaloga.org/archives/1154-guid.html#c10273