Wpis z mikrobloga

Nie było żadnego ataku, a #hejto perfidnie kłamie. Hejto korzysta z Cloudflare'a co można łatwo sprawdzić w internecie. Oznacza to, że każda udana próba ataku Denial-of-Service została by zatrzymana na poziomie Cloudflare'a i użytkownik nie zobaczyłby błędu 500 z astronautą na stronie hejto. Jeżeli strona korzystająca z CF może załadować się na tyle, żeby wyświetlić błąd to znaczy, że wina jest po stronie ich web servera, a nie jest spowodowana żadnym atakiem. W przypadku gdyby był prowadzony atak, użytkownik zatrzymałby się na poziomie CF. Cloudflare jest bardzo dobrym i znanym rozwiązaniem, jednym z jego głównych zadań jest ochrona przed tego rodzaju atakami. A tutaj ewidentnie CF nie ma nic do roboty, a błąd pochodzi z serwera hejto.

Tak że sorry @evilonep ale mam złe wieści, zostałeś oszukany. Hejto wykorzystuje niewiedzę użytkowników, to co mówią na temat DDoS jest bzdurą.
Pobierz KaiserBrotchen - Nie było żadnego ataku, a #hejto perfidnie kłamie. Hejto korzysta z ...
źródło: hejto
  • 55
Cloudflare nie wie ile ruchu może przyjąć baza danych, poza tym mógłby to być „zwykły” ruch. Nie wiedza w cf ile hejto może przyjąć ruchu.


@BreathDeath: no, dokładnie. To teraz porównaj to z tym co napisało oficjalne konto hejto. Ich serwis działał #!$%@? nawet o 4 w nocy - o tej godzinie dużego ruchu nie było na pewno.
@fakePMcoach: może potwierdzać, ale nie musi. 524 jest błędem oznaczającym, że udało się połączyć z serwerem, ale ten nie odpowiedział na request w wyznaczonym czasie. Atak jest jednak wątpliwy nawet przy tym błędzie, bo raczej nie powinno w ogóle utworzyć połączenia. Hejto raz działa, raz nie. Statyczny kontent działa u nich praktycznie zawsze, a wysypuje się tam gdzie używana jest baza danych. Tak jak napisał @Klopsztanga gdyby to był atak, to
@KaiserBrotchen: bez obrazy ale #!$%@? głupoty, prowadzę serwisy internetowe schowane za CloudFlare i tak jak tu piszą w komentarzach wyżej można je zddosować, CloudFlare z automatu nie blokuje praktycznie nic oprócz znanych botów, strona z captchą jest bardzo łatwa do ominięcia jeśli do ataku używasz prawdziwych urządzeń. jedyna opcja jaka ci zostaje to śledzenie logów i próba całkowitego wycięcia danych IP, User Agent lub URL przez Firewall Rules co zajmuje czas
@KaiserBrotchen: przykład z ostatniego ataku na moją stronę:
w godzinę ponad 1.2 miliona wejść, wszystkie z ruskich IP, zmieniany User Agent i IP (realne urządzenia), wszystkie requesty na plik index, powodzenia z zablokowaniu czegoś takiego (masz opcję wycięcia całego kraju lub całkowitego zablokowania strony głównej i czekania aż im się znudzi)

kolejny przykład ataków, które przeprowadzał kompletny debil:
wszystkie wejścia miały ten sam User Agent lub miały dopięty parametr do głównego
strona z captchą jest bardzo łatwa do ominięcia jeśli do ataku używasz prawdziwych urządzeń


@satanasluciferi: nie ominiesz captchy bez fizycznego dostępu do urządzenia. Po to ona istnieje, żeby wykrywać boty. A z pojedynczych komputerów nie zrobisz ataku DDoS, który z definicji jest atakiem przeprowadzanym z dużej liczby urządzeń. Jakby ktoś próbował ze swojego łącza wysyłać taką ilość danych, by zablokować usługę, to w pierwszej kolejności dostęp wyłączyłby mu jego dostawca. Spróbujesz
ale jesli ktos poznal oryginalne adresy IP serwisu (a sam serwis nie zostal odpowiednio utwardzony, by nie przyjmowac ruchu uptream spoza CF)


@marcinforall: wspominałem o tym w pierwszym komentarzu. To jest właściwie jedyny sposób jaki przychodzi mi do głowy, żeby to się mogło udać. Ale po pierwsze jest to dość łatwe do naprawienia, a po drugie chyba nikt kto wystawia duży serwis internetowy by czegoś takiego zrobił. To trochę tak jakby