#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ł .

Zacznijmy od tego co jest wąskim gardłem czy aby czasem nie webserver? W takim wypadku jakiekolwiek wtyczki do WP nic nie zdziałają bo co z tego że one coś sobie tam blokują skoro sam apache2 nie jest już w stanie obsłużyć większej ilości połączeń. Dlatego jeśli posiadasz serwer VPS/Dedyk po pierwsze zobacz /var/log/apache2/access.log co dokładnie z czego i gdzie leci, po 2 zastanów się nad ustawieniem proxy korzystając z NGINX przed tym apache.

Według mnie atak DDoS również może być takowym testem ponieważ pozwala poznać możliwości danej infrastruktury a także błędy w niej np: przepuszczanie przez firewall konkretnego typu pakietów bez żadnych limitów. I pozatym on oferuje również zabezpieczenie a tego bez odpowiednich accesów nie zrobi . I to akurat o to mi chodziło z bezpieczeństwem danych.

Tutaj nawet nie chodzi o faktury ale powiedz mi jaka normalna firma da ci dostęp do swoich serwerów bez podpisania stosownych umów na takie testy penetracyjne a także takie testy są zwykle zlecane większym podmiotom (firmom) które mają znacznie większe zaplecze i gwarantują poufność danych które mogą zdobyć podczas prowadzenia takowych "akcji".

Ok, więc co konkretnie chcesz zabezpieczać (Co zaproponował byś potencjalnemu klientowi)?

Oczywiście ovh nie posiada żadnej ochrony przeciwko atakom na webserver ale tutaj już jest pole do popisu dla osoby która daną stroną zarządza i dla ciebie jeśli ktoś się zdecyduje skorzystać choć wątpię . "Tak jak napisałem w temacie, mam własne metody tcp/udp." z pastebina/githuba ?

hmm ok fajnie tylko nie rozumiem 1 rzeczy dlaczego chcesz testować "strony" atakami amplifikacyjnymi a także TCP/UDP na warstwie 4? Według mnie takowe testy nie mają zbytnio sensu ponieważ sam nie będziesz w stanie nikogo obronić przed takowym atakiem "amp" (jeśli klient posiada rurkę w ch*****m DC które jak zobaczy już 1/4 tego ruchu to się wyłoży) a poza tym istnieją takie firmy jak OVH/CloudFlare/Voxility które chronią swoich klientów na tej warstwie oczywiście wtedy możesz wkroczyć z Ovh/Vox bypass ale to w dalszym ciągu będzie testowanie samego serwera a nie webservera co chyba chciałeś robić. wgl jeśli już chcesz testować strony to może zainteresuj się atakami skierowanymi bezpośrednio w webserver. Jeszcze co do tych twoich skryptów to posiadasz chociaż coś własnego?

Ok rozumiem, aczkolwiek jak już pisałem to nawet już nie jest kwestia zmiany hosta a postawieniu proxy na tym vps Co do CF to jak najbardziej jak zresztą napisałem zależy pod co i akurat w twoim przypadku się sprawdzi. Co do ukrywania real adresu IPv4 usługi przez CF to nie jest takie proste ponieważ żeby to miało sens trzeba odpowiednio skonfigurować web server (zezwolenie jedynie na adresy IPv4 proxy CF) ponieważ skanery takie jak censys nam to chwycą.

1. Dlaczego wszyscy używacie tego Cfa skoro i tak każdy wie iż można takową stronę wyłączyć są już znacznie lepsze rozwiązania może i nie takie molochy jakim jest CF ale znacznie lepsze pod kątem filtrowania req. (od razu zaznaczam że to również zależy do czego chcecie takiego CF wykorzystywać jeśli stricte tylko dla CDN to jak najbardziej) 2. Nie nie posiadam / nie pracuję w żadnej firmie która oferuje serwery vps poza tym nigdzie nie proponuję konkretnej marki (chyba że ktoś konkretnie zapyta). 3. Dlaczego vps? Z bardzo prostej przyczyny na hostingu www poza tym co zapewni ci twój usługodawca podczas trwania takiego ataku nie możesz nic poza ewentualna konfiguracją cfa i htaccess reszta to już kwestia providera który zapewne w większości przypadków zaproponuje wyższy pakiet i tym samym nie pomoże w problemie (oczywiście tutaj mocno zgeneralizowałem i zapewne znajdą się firmy które pomogą i w takich sytuacjach) . A na vps ewentualnie nawet hosting www + proxy (vps/dedyk) + CF / (inne rozwiazanie) spisze się w moim odczuciu znacznie lepiej i o tym cały czas mówię żeby mieć zawsze w takich sytuacjach serwer przed docelowym www na którym możemy uporać się z problemem. Apropo tego innego rozwiązania to opcji jest kilka: ddos-guard.net , nooder.net i zapewne znajdzie się więcej. (I tutaj również zbyt mocno zgeneralizowałem ) Zobacz up. I to też zależy od tego iloma vps dysponujemy, jakie maja parametry i końcowo co na nich stoi. https://github.com/duy13/vDDoS-Protection Nawet takie mini rozwiązanie z githuba ustawione przed webservem może dać spory efekt już nie mówiąc o tym co jeszcze za magie można zrobić samemu.

Powiedz mi co to jest za koszt wywalenia strony za cf i to na hekko przez tydzień? No najogólniej mówiąc to żaden więc na twoim miejscu zainwestowałbym w coś bardziej sensownego i na pewno nie w hosting www a vps.

https://contabo.com/?show=vps