#Gremsonkowy#

.

.

Jak najbardziej filtrowanie pakietów samego komunikatora jest tutaj kluczem lecz nie bierzesz pod uwagę iż OVH dość często daje ciała również pod względem wolumetrycznym. Pozwolę sobie przytoczyć podatność sprzed kilku miesięcy opierającą się o protokół MDNS w niektórych lokalizacjach potrafiła przysporzyć problemów nawet wszystkim serwerom znajdującym się w jednej szafie a to wszystko przez kompletny brak reakcji systemu VAC na ten konkretny ruch a tym samym wygenerowanie sporego obciążenia na switch'u co skutkowało niedostępnością usługi na którą nie możesz mieć żadnego wpływu próbując cokolwiek filtrować z poziomu hosta.

Twój problem jest zupełnie inny. Skoro nie masz problemów tylko podczas trwania mitygacij po co piszesz "mam dokładnie to samo, jest coś z mitygacją." ? Dodatkowo znów pokazuje to twoje niezrozumienie działania OVH, jak możesz mieć problem z mitygacją skoro ona w danym momencie nie jest włączona? Kolejny raz używasz sformułowania którego kompletnie nie rozumiesz. BGP blackholing nie ma kompletnie nic wspólnego z działaniem Anty-DDoS PRO OVH w przypadku wykrycia Flooda nie ważne czy to tcp/udp, ruch na protokole UDP jest przycinany. Co do współpracy z @Mesharsky czemu cię to tak interesuje?

Powiedz mi w takim razie jak to sprawdziłeś? Jeśli użyłeś check-hosta a oni prawdopodobnie używają serwerów z OVH to widać że nie wiesz jak działa Anty-DDoS w OVH. Ponieważ firewall na tilerach obsługuje ruch jedynie WAN natomiast ten w obrębie infry OVH nie jest przez niego limitowany.

Nie z mitygacją a ze stanem twojej wiedzy. Niestety ale OVH w przypadku Ataku DoS/DDoS dla usług objętych filtracją Anty-DDoS Pro ucina wszystkie pakiety UDP na czas trwania filtracji. I dlatego kolega @Mesharsky ma takowy problem. Jednym z jego rozwiązań jest używanie kilku adresów ipv4 dla serwera DNS bądź zmiana gamy serwera na GAME która filtruje pakiety UDP a nie je całkowicie odrzuca.

W twoim poprzednim temacie umieściłem ofertę, spójrz na nią. Jeśli będziesz zainteresowany jak już pisałem szczegóły omówimy via priv. Mogę jeszcze dodać że oferujemy 30 dniowy okres testowy podczas którego możesz za darmo sprawdzić jak nasza usługa poradzi sobie z atakami na twoją stronę.

Wygląda na to że potrzebujesz proxy. Jestem w stanie zaoferować usługę która bez problemu poradzi sobie z atakami na warstwę 7 (wszelkiego rodzaju requesty nie generowane poprzez realnego użytkownika) a także da radę z atakami L4 nawet sięgającymi wartości 600 Gbps/54M pps. Oczywiście usługa ulokowana jest w Polskim DataCenter aby zapewnić możliwie najmniejsze opóźnienia. Jeśli jesteś zainteresowany zapraszam do kontaktu na pw gdzie mogę przedstawić więcej szczegółów odnośnie samego rozwiązania jak i jego poprawnego wdrożenia.

Fail2ban nigdy nie był i nie będzie WAFem i to spełnianie przez niego założeń definicji jest również bardzo naciągne choćby przytoczmy pierwszy zacytowany przez ciebie fragment definicji "It applies a set of rules to an HTTP conversation" więc czy fail2ban pozwala nam na stworzenie konkretnej reguły do blokady tylko 1 konkretnego urla/requesta a nie ogranicza się tylko do blokady na poziomie IP? Nie! Co jednoznacznie kłóci się z powyższą definicją jako iż zakłada ona stosowanie ACLek tylko w obrębie samej komunikacji HTTP. "An application firewall is a form of firewall that controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls that do not meet the configured policy of the firewall" Tutaj natomiast fail2ban nie wypełnia w 100% definicji jako iż pozwala on jedynie na kontrolę inputu która w normalnym użyciu nie ma sensu jako iż raz zadziała z opóźnieniem (użytkownik dostanie response) a dwa owe narzędzie poza logami nie ma żadnych innych sensownych możliwość analizowania i reagowania na potencjalne nieprawidłowe requesty.

Z tego co widać na gowork.pl to akurat po artykule w Puls Dnia nagle dziwnym trafem zleciała się tam cała śmietanka z samych postów można wywnioskować iż posty z nicków pokroju Kasia to ta słynna agencja marketingowa która próbowała robić szeptankę tutaj jak i na innych forach oczywiście w najgłupszy możliwy sposób a dłuższe wychwalające nazwę opinie są prawdopodobnie pisane przez pracowników nazwa.pl którzy usilnie próbują zagiąć rzeczywistość i podlizać się pracodawcy.

A więc od początku widzę że nie ogarniasz tematu serwerów TeamSpeak3 więc tak serwer VPS którego używasz zakupiłeś w hekko a owa firma hostingowa nie posiada żadnych filtrów "anty-ddos" dla aplikacji teamspeak3 dlatego pierwszy lepszy flood i twój serwer będzie mieć problemy zwłaszcza że zamierzasz stawiać serwer publiczny (a wiadomo jakie jest community TeamSpeak3) do którego będzie mieć dostęp każdy dlatego też zmiana hostingu to priorytet. Dodatkowo zalecam szybką aktualizację serwera jak i klienta ponieważ w chwili obecnej narażasz siebie i potencjalnych użytkowników twojego serwera na wykorzystanie podatności RCE.

Ale on podał budżet tylko że w wcześniejszym poście. Ok, więc w takim razie mogę ci to ogarnąć szczegóły priv.

Ja również mogę polecić https://www.multigaming.pl/ i ich usługę VVPS której managementem od strony technicznej nie musisz się przejmować (security, anty-ddos, aktualizacje), co do konfiguracji permisions na serwerze to mogę pomóc tylko podeślij ip na pw.

Zacznjimy od tego że nie powinieneś bazować na tej całej "ochronie" CloudFlare jak sam zauważyłeś nic nie daje nawet UAM + Captcha w tym momencie dla atakujących to nie problem tak samo rate-limit czy też country block a także powyższe opcje w przypadku cfa są dodatkowo płatne (rate-limit), według mnie CF ma jedyne zastosowanie jeśli chodzi o wygodny management stref dns a także ukrycie realnego adresu ip serwera. Od siebie mogę polecić kupno VPS'a ale tutaj też to nie będzie polegało no tym że instalujesz webserver i problem z głowy.

Jeśli postawi po prostu NGINX to jak najbardziej na wiele się to nie zda aczkolwiek takie rozwiązanie daje już możliwość cięcia req przed apache'm czy chociażby można zastosować gotowe rozwiązanie o nazwie vDDoS. Co do blokowania "wyżej" to na dobrą sprawę jedyne co możesz robić to limity per Source adres (możesz to również limitowac per konkretne żądanie) a cała resztę typu weryfikacja chociażby przez JS'a musisz już ogarniać z samego proxy. Reasumując według mnie w przypadku protokołu http nie ma sensu ciąć tego wcześniej niż proxy to nie jest atak L4 z którym przeciętny serwer z rurką 1gbps by sobie sam nie poradził .