[Poszukuję] Przekierowanie ruchu TCP z ruchu pochodzącego z kontenerów docker (bridge) na inny adres ip

[daffx]

Cześć,

Z uwagi na ataki ddos które wykorzystują podatność firewalla ovh (tcp ack+psh) muszę przekierować ruch TCP z kontenerów docker (serwery gier - Valve) na nowy adres ip który będzie ukryty i będzie pozwalał na połączenia TCP, na ip serwerów gier chcę docelowo zablokować cały ruch TCP i niech będzie on kierowany przez ten dodatkowy adres ip.

Jeżeli da się coś takiego wykonać lub ktoś już to robił i wie, że będzie to działało to potrzebuję osoby która jest w stanie to wykonać

 

Serwery gier działają na kilku adresach ip jako osobne kontenery docker w bridge network.

Najlepiej jeżeli ktoś miał już styczność z panelem Pterodactyl i Wings.

 

[psz]

Rozumiem, że chodzi o połączenia przychodzące TCP?

 

Jeśli kontrolujesz oba końce połączenia polecam Cloudflare Tunnel. Po stronie serwera uruchamiasz "cloudflared tunnel" lub klienta WARP z routingiem prywatnego zakresu IP, po stronie klienta odpalasz proxy "cloudflared access tcp", albo klienta WARP.

 

Jeśli potrzebujesz dostępu z "otwartego Internetu", opcją będzie Cloudflare Spectrum, lecz jest to rozwiązanie droższe. Odpiera ataki DDoS.

 

Jeśli protokołem hulającym w tym połączeniu jest HTTP, to nawet lepiej. Masz do dyspozycji cały wachlarz funkcji Cloudflare Access, DDoS,  WAF, etc.

 

Odezwij się do mnie na priv z dokładnym opisem Twojej infrastruktury, a chętnie pomogę ustalić skuteczne rozwiązanie.

[l3szcz]

Serwery gier zabezpieczacie? Po TCP/UDP? 

[daffx]

2 godziny temu, l3szcz napisał(a):

Serwery gier zabezpieczacie? Po TCP/UDP? 

Gry Valve zazwyczaj są po UDP ale TCP jest wykorzystywane do komunikacji z master serverem i pluginy korzystają np z http itd.

[TheGuy]

Zapraszam na pw, 12 lat spędziłem z silnikiem source, nie ma tu tajemnic od strony sieci. Autor prawdopdobnie nie rozumie czego chce.

 

[psz]

18 godzin temu, l3szcz napisał(a):

Serwery gier zabezpieczacie? Po TCP/UDP? 

 

Tak, ale nowoczesne gry to szeroki temat. Połączenie do serwera gier UCP/TCP, ochrona API (logowanie, czaty, leaderboard, etc), dostarczanie assetów (np. pobieranie instalatora/aktualizacji, albo jakieś DLC/skiny/newsfeed). Trzeba sprecyzować.

 

Lektura:

https://www.cloudflare.com/pl-pl/gaming/

https://www.cloudflare.com/pl-pl/application-services/products/cloudflare-spectrum/minecraft/

https://cf-assets.www.cloudflare.com/slt3lc6tev37/49LTJaxXMdtHgH3Jg3Zx8o/878b0f87a9d3759fed672186a8b3cfae/Cloudflare_for_Gaming__Brief_.pdf

 

[l3szcz]

Chodzi konkretnie o HLDS / Source

[TheGuy]

Nie ma wielu skutecznych metod ochrony tego, srcds dostanie spofowanym ruchem i składa się od razu, problematyczne do ochrony jak dns.

 

Jedyna 100% skuteczna metoda to:

Postawić aplikacyjne "przezroczyste" proxy przed serwerem gry, które przeprowadza wstępną autoryzację klienta (na protokole gry, działanie nieco analogiczne do synproxy).

Dopiero po ustanowieniu połączenia (jakakolwiek wymiana pakietów, choćby query challenge upewnia nas, że ruch nie jest spofowany) wpuszcza go (nawiązuje połączenie z faktycznym serwerem gry, w pewnym sensie "udając" klienta przez pierwsze kilka pakietów, które wcześniej proxy wymieniło z klientem).

Kolejno proxy pilnuje tej sesji , sprawdza czy ruch pasuje do heurystyki. 

Tu rozwiązania ochrony muszą być szyte pod specyfikację aplikacji i protokół konkretnej gry. W przypadku srcds są w większości podobne.

 

Cloudflare ma... podobnie jak ovh, coś co "patrzy" na ruch i wycina wg swojej logiki bad actorów, czasem wytnie normalnych graczy (nawet na etapie łączenia się do serwera) notorycznie się zdarza.  Nie dalej jak 2 lata temu valve zaktualizowało query protocol, facepunch zaimplementował to w garrysmodzie, ovh żarło się z nim przez 3 miesiące podobnie jak cloudflare - dopóki ktoś ręcznie nie poprawił rozwiązań. To wszystko rozwiązania szyte pod protokół ale ich skuteczność jest taka sobie.

 

Firmy z takim budżetem mogłyby zrobić to lepiej... jednak ta kiepska skuteczność nie dziwi mnie, wystarczy że serwer będzie miał inny tickrate, niektóre sieciowe convary np. cl_updaterate inny niż ten, na podstawie którego tworzyli heurystykę... i już problemy.

Edytowane 19 Marca przez TheGuy
minor fix

[daffx]

4 minuty temu, TheGuy napisał(a):

Nie ma wielu skutecznych metod ochrony tego, srcds dostanie spofowanym ruchem i składa się od razu, problematyczne do ochrony jak dns.

 

Jedyna 100% skuteczna metoda to:

Postawić aplikacyjne "przezroczyste" proxy przed serwerem gry, które przeprowadza wstępną autoryzację klienta (na protokole gry, działanie nieco analogiczne do synproxy).

Dopiero po ustanowieniu połączenia (jakakolwiek wymiana pakietów, choćby query challenge upewnia nas, że ruch nie jest spofowany) wpuszcza go (nawiązuje połączenie z faktycznym serwerem gry, w pewnym sensie "udając" klienta przez pierwsze kilka pakietów, które wcześniej proxy wymieniło z klientem).

Kolejno proxy pilnuje tej sesji , sprawdza czy ruch pasuje do heurystyki. 

Tu rozwiązania ochrony muszą być szyte pod specyfikację aplikacji i protokół konkretnej gry. W przypadku srcds są w większości podobne.

 

Cloudflare ma... podobnie jak ovh, coś co "patrzy" na ruch i wycina wg swojej logiki bad actorów, czasem wytnie normalnych graczy, notorycznie się zdarza. 

Nie dalej jak 2 lata temu valve zaktualizowało query protocol, facepunch zaimplementował to w garrysmodzie, ovh żarło się z nim przez 3 miesiące podobnie jak cloudflare - dopóki ktoś ręcznie nie poprawił rozwiązań. To wszystko rozwiązania szyte pod protokół ale ich skuteczność jest taka sobie.

 

Firmy z takim budżetem mogłyby zrobić to lepiej.

Nie chodzi o atak aplikacyjny czyli ruch udp, chodzi o przekierowanie ruchu wychodzącego TCP przez znany tylko mi adres IP żeby atakujący nie znali tego IP i nie mogli przeprowadzać ataku tcp a+p (kto wie ten wie, nie będę pisał całości bo dzieci będą się bawić)

 

Docelowo chce ograniczyć cały ruch dla TCP dla IP serwerów gier i pozwolić na komunikację serwerów przez ten dodatkowy adres, gracze nie muszą mieć dostępu do TCP tylko serwer 

Edytowane 19 Marca przez daffx

[TheGuy]

Do hlds/srcds nie lata ani jeden pakiet tcp, obejrzyj tcpdump.

Ustaw policy drop na inpucie i allow tylko dla udp.

Problem rozwiązany, to najprostsze i najszybsze do wyjaśnienia rozwiązanie. 

 

Edytowane 19 Marca przez TheGuy

[daffx]

1 minutę temu, TheGuy napisał(a):

Do hlds/srcds nie lata ani jeden pakiet tcp, obejrzyj tcpdump.

Ustaw policy drop na inpucie i allow tylko dla udp.

Problem rozwiązany.

 

Mylisz się, komunikacja z Valve leci też przez TCP.

Jeżeli zablokuje TCP to Valve nie będzie mogło odpowiedzieć

Edytowane 19 Marca przez daffx

[TheGuy]

Conntrack śledzi połączenia jakie wykonujesz na zewnątrz i wpuści odpowiedź.

Podstawy linuksa szanowny Panie.

Edytowane 19 Marca przez TheGuy

[daffx]

Teraz, TheGuy napisał(a):

Conntrack śledzi połączenia jakie wykonujesz na zewnątrz i wpuści odpowiedź.

Podstawy linuksa szanowny Panie.

Jeżeli zablokuje ruch TCP w firewallu ovh? Szanowny Panie podstawy znajomości firewalli ...

Jeżeli nie znasz się po 12 latach jakich wspomniałeś wyżej to proszę Cię nie wypowiadaj się w moim temacie, dzięki!

[TheGuy]

Nie trzeba być uszczypliwym, a w jakim celu chcesz blokować to na firewalu w ovh?

Ilość ruchu cię przytłacza?

 

Myślę, że moje doświadczenie w tej materii jest niekwestionowalne

Edytowane 19 Marca przez TheGuy

[daffx]

6 minut temu, TheGuy napisał(a):

Nie trzeba być uszczypliwym, a w jakim celu chcesz blokować to na firewalu w ovh?

Ilość ruchu cię przytłacza?

W takim celu że atakujący próbuje wysycić łacze całego serwera poprzez atak TCP a+p a żeby ovh pozwolił na ruch TCP muszę dać TCP established all, czyli wystarczy, że atakujący wyśle połączenie na losowy port TCP który wymusi przyjęcie go. Valve odpowiada na losowym porcie więc nie można tego zrobić inaczej. ASN Valve jest są duże żeby zmieścić to w firewallu ovh (20 reguł). Pozostaje tylko przekierowanie wychodzącego TCP i zablokowanie go na publicznym IP 

 

+ Różne pluginy na serwerach gier  mogą wykonywać połączenia TCP np http

Edytowane 19 Marca przez daffx

[TheGuy]

Syn reflection attack? No to wracamy się o kilka komentarzy do góry, wystarczy nie przyjmować połączeń tcp i wolumen ruchu spada o połowę bo nie ma już wychodzącego.

Ile przychodzącego ruchu masz w mbps?

 

Edytowane 19 Marca przez TheGuy

[daffx]

9 minut temu, TheGuy napisał(a):

Syn reflection attack? No to wracamy się o kilka komentarzy do góry, wystarczy nie przyjmować połączeń tcp i wolumen ruchu spada o połowę bo nie ma już wychodzącego.

Ile przychodzącego ruchu masz w mbps?

 

Dobra napiszę Ci to bo dalej nie rozumiesz

Poczytaj o TCP ack+psh i jakim jest problemem w ovh albo o metodzie przykładowo kill-all.

https://gitlab.com/cryptio/ddos-research/-/blob/master/attacks/kill-all.md

To jest przykład o którym piszesz, i zalecane jest przekierowanie ruchu TCP przez inne IP.

Nie mogę zablokować ruchu TCP bo serwery gier się nie włącza ani pluginy na nich nie będą mogły wykonać żadnego połączenia TCP

Ack+psh ustawia połączenie jako established co wykorzystuje właśnie luke którą trzeba mieć na ovh żeby Valve mogło się połączyć z serwerem gry (TCP established all - ovh nie sprawdza czy połączenie zostało faktycznie wcześniej nawiązane prawidłowo)

Chce tą regułę usunąć a pozwolić serwerowi gry i Valve na komunikację przez inny adres IP którego atakujący nie będzie znał.

Edytowane 19 Marca przez daffx

[TheGuy]

Ale jak wytniesz przychodzące połączenia (na swojej zaporze) to problem się rozwiązuje, dalej możesz stukać gdzie tylko chcesz na zewnątrz.

Dlatego pytałem cię ile masz ruchu przychodzącego, bo prawdopodobnie nie ma powodu by wycinać na ich firewalu całe tcp w obie strony

Edytowane 19 Marca przez TheGuy

[daffx]

2 minuty temu, TheGuy napisał(a):

Ale jak wytniesz przychodzące połączenia (na swojej zaporze) to problem się rozwiązuje, dalej możesz stukać gdzie tylko chcesz na zewnątrz.

Dlatego pytałem cię ile masz ruchu przychodzącego, bo prawdopodobnie nie ma powodu by wycinać na ich firewalu całe tcp w obie strony

Muszę to zrobić po stronie ovh, ataki są często większe niż łącze serwera.

[TheGuy]

Jeśli odpowiadasz na ten ruch syn-ack generujesz drugie 50%, spróbowałbym na twoim miejscu proponowanego rozwiązania.

Ovh zobaczy, że dostajesz spam synów na który nie odpowiadasz i prawdopodobnie  (mam 95% pewności) wytnie to w cholerę automatycznie.

[daffx]

4 minuty temu, TheGuy napisał(a):

Jeśli odpowiadasz na ten ruch syn-ack generujesz drugie 50%, spróbowałbym na twoim miejscu proponowanego rozwiązania.

Ovh zobaczy, że dostajesz spam synów na który nie odpowiadasz i prawdopodobnie  (mam 95% pewności) wytnie to w cholerę automatycznie.

Pakiety które dostają nie mają flagi syn + co mi da zablokowanie odpowiedzi jeżeli wysycany jest ruch przychodzący i to często ponad 20x

Edytowane 19 Marca przez daffx

[TheGuy]

Would you mind sharing some pcaps?

Wiem sporo o rozwiązaniach antyddos w ovh, ciężko opisać jak bardzo dziwią mnie przedstawione tu informacje.

 

Jak ruch cię dowala to normalnie ssh zrywa? Laguje coś?

Chyba nie do końca rozumiem jak rozwiązanie z początkowego posta ma pomóc, skoro pasma brakuje.

[daffx]

Teraz, TheGuy napisał(a):

Would you mind sharing some pcaps?

Wiem sporo o rozwiązaniach antyddos w ovh, ciężko opisać jak bardzo dziwią mnie przedstawione tu informacje.

 

Jak ruch cię dowala to normalnie ssh zrywa? Laguje coś?

Chyba nie do końca rozumiem jak rozwiązanie z początkowego posta ma pomóc, skoro pasma brakuje.

Laguje wszystko i SSH zrywa połączenie do momentu aż atak ustanie albo atakujący zmniejszy jego moc.

Wszystkie pakiety jakie dostaje mają flagi ack+psh czyli znany bypass dla ovh.

Mam gdzieś dumpy z serwera gdzie miałem jeszcze 1Gbit łącze i on eksplodował za każdym razem, aktualnie mam większe ale nie 1 cyfrowe, nie będę pisał dokładnie bo każdy mnie zna z tego środowiska po nicku i atakujący ma tyle mocy żeby wywalić cały serwer albo mocno obciążyć łącze żeby były lossy.

 

[TheGuy]

W tej sytuacji, jeśli wysyca łącze, może przecież przysłać dowolny inny rodzaj pakietów (choćby udpowy ruch) i efekt będzie taki sam.

Tu żadne rozwiązanie się nie sprawdzi. Jeśli ovh tego nie ogarnia to wojna budżetów, twój vs jego.

 

Wygra tylko ten z większą rurą

Edytowane 19 Marca przez TheGuy

[daffx]

Teraz, TheGuy napisał(a):

W tej sytuacji, jeśli wysyca łącze, może przecież przysłać dowolny inny rodzaj pakietów i efekt będzie taki sam.

Tu żadne rozwiązanie się nie sprawdzi. Jeśli ovh tego nie ogarnia to wojna budżetów, twój vs jego.

 

Wygra tylko ten z większą rurą

Blokuje pozostały ruch + ovh filtruje udp. Problemem jest tylko publicznie dostępny adres dla TCP