Skocz do zawartości
Fizyda

VPS SSD w OVH pingi dla TS3

Polecane posty

Teamspeak to taki jełop na rynku aplikacji VoIP, przyjmie wszystko co mu się wciśnie. Nie mam pojęcia jak inne firmy hostingowe, ale teamspeaki w naszej sieci stanowią 0.04-6%, a jednocześnie 75-85% wszystkich zgłoszeń związanych z problemami z atakami, więc te liczby chyba dokładnie uświadamiają skalę problemu. Aplikacja jest beznadziejna, developerzy kompletnie zapomnieli o weryfikacji czegokolwiek, aplikacja przyjmie każdy ruch, tworzone exploity w 99% przypominają legalny ruch (
Teamspeaka wszędzie oflagowałbym gwiazdką, która informuje, że jest to swoisty ewenement i brzydzimy się ochroną tego czegoś. Aczkolwiek BlazingFast próbuje.. :lol: Hosteam również, najwidoczniej lubimy się taplać w błocie. 90% ataków, które na siłę staramy się filtrować, moglibyśmy spokojnie odsyłać do developerów Teamspeaka, gdyż jest to kompletnie ich wina.

I jeszcze te magiczne komentarze klientów .. "Teamspeak mi padł, więc nie macie ochrony.".

Edytowano przez EvoBattle (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Spoofy

aplikacja przyjmie każdy ruch, tworzone exploity w 99% przypominają legalny ruch (<3 udp).

 

A jak chciałbyś to zrobić bez wykorzystania udp? Problem komunikacji tego badziewia to jedno, weryfikacja serwerów z licencją to drugie. Jedni płacą po 1000zł rocznie za licencję a inni stawiają sobie jakieś gówno (przy okazji dołączając do botnetów ), dopisują w hosts adres serwera do weryfikacji jako localhost i mają gdzieś niemców - i to jest nie fair. Developerzy się zwyczajnie opierdzielają nawet z łataniem klienta.

 

Ostatnio tak się kłóciłem z Archim właśnie i nadal uważam że niebawem wyjdzie wkońcu jakaś ludzka alternatywa która zawładnie tym rynkiem i nie będzie takich problemów, ale musimy jeszcze poczekać na rozwój webrtc ;)

Edytowano przez Spoofy (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bardzo prosto, przykładem jest mumble - wydajniejsze kodeki, zdecydowanie lepsza jakość komunikacji i działa na obu protokołach. Odetniesz udp, to aplikacja sama przerzuca się na tcp-only. Po takim czymś można odróżnić, czy pisał aplikację ktoś z głową, czy kernojajowiec. ^_^ (autorskie określenie, właśnie je wymysliłem).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Mumble przerabiałem dobre 6 lat temu, niestety masa dzieciarni jest przyzwyczajona do TSa (rangi, ikonki i inne duperele, czego nie ma na mumble) i tego nie zmienisz, trzeba płacić aby utrzymać publikę mimo iż w moim przekonaniu jest świetna darmowa alternatywa https://discordapp.com/

Edytowano przez protoplasta (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Mumble przerabiałem dobre 6 lat temu, niestety masa dzieciarni jest przyzwyczajona do TSa (rangi, ikonki i inne duperele, czego nie ma na mumble) i tego nie zmienisz

I właśnie sam podałeś argument za tym, by się przesiadać z TS.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Mumble przerabiałem dobre 6 lat temu, niestety masa dzieciarni jest przyzwyczajona do TSa (rangi, ikonki i inne duperele, czego nie ma na mumble)

Wydaje mi się, że Mumble będzie szło w dobrym kierunku.

 

mumble_redesign_metro_mumble_theme-lite.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Jak na razie Mumble straciło trochę rynku https://www.google.pl/trends/explore#q=teamspeak%2C%20mumble

 

Wniosek jest taki, że Mumble jest dla tych co cenią sobie niezawodność kosztem funkcjonalności, jaką np. daje TeamSpeak 3.

Zrodził się nam inny temat w tym wątku :)

Edytowano przez DreamPL (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Teamspeak to taki jełop na rynku aplikacji VoIP, przyjmie wszystko co mu się wciśnie. Nie mam pojęcia jak inne firmy hostingowe, ale teamspeaki w naszej sieci stanowią 0.04-6%, a jednocześnie 75-85% wszystkich zgłoszeń związanych z problemami z atakami, więc te liczby chyba dokładnie uświadamiają skalę problemu. Aplikacja jest beznadziejna, developerzy kompletnie zapomnieli o weryfikacji czegokolwiek, aplikacja przyjmie każdy ruch, tworzone exploity w 99% przypominają legalny ruch (<3 udp). Dodatkowo dochodzi już do takich finezji, że ataki 10p/s potrafią doprowadzić do destabilizacji całej aplikacji, a wystarczy tylko mieć otwarty query port przez klienta.

 

Teamspeaka wszędzie oflagowałbym gwiazdką, która informuje, że jest to swoisty ewenement i brzydzimy się ochroną tego czegoś. Aczkolwiek BlazingFast próbuje.. :lol: Hosteam również, najwidoczniej lubimy się taplać w błocie. 90% ataków, które na siłę staramy się filtrować, moglibyśmy spokojnie odsyłać do developerów Teamspeaka, gdyż jest to kompletnie ich wina.

 

I jeszcze te magiczne komentarze klientów .. "Teamspeak mi padł, więc nie macie ochrony.".

 

Te pakiety UDP są specyficzne, już kilka lat temu napisałem regułkę iptables, która działa mi do dziś - nie dopuszcza żadnego ataku po UDP do aplikacji - w oparciu o wiele rzeczy takich jak rozmiar pakietu, częstotliwość, a nawet sam content (który też jest do przewidzenia, w szczególności jak serwer używa szyfrowania). Nie, nie podzielę się.

 

ServerQuery to zło konieczne, 10011 u mnie jest zablokowane od początku istnienia, otwarte tylko dla określonej puli adresów IP, które trackują mój serwer, i żadne inne.

 

Wszystko się da, tylko trzeba mieć dostęp tam gdzie trzeba, dlatego właśnie lubię OVH i magiczny dostęp jaki dają przez API do regułek swojego firewalla.

 

 

I właśnie sam podałeś argument za tym, by się przesiadać z TS.

 

Mumble jest spoko, ale nie ma wielu bajerów do których przyzwyczaił mnie TS, do tego ma nieco większe wymagania odnośnie jego hostowania. Jakby TS3 stał się open-source to by był najlepszym programem głosowym opartym o architekturę klient/serwer, bo community naprawiłoby te wszystkie fuckupy, które się w nim znajdują. Ale firma jest nastawiona na zysk, a nie na pracę w formie wolontariatu dla dobra swoich użytkowników, jak co poniektórzy sądzą na WHT odnośnie niektórych firm.

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Mumble jest spoko, ale nie ma wielu bajerów do których przyzwyczaił mnie TS, do tego ma nieco większe wymagania odnośnie jego hostowania. Jakby TS3 stał się open-source to by był najlepszym programem głosowym opartym o architekturę klient/serwer, bo community naprawiłoby te wszystkie fuckupy, które się w nim znajdują. Ale firma jest nastawiona na zysk, a nie na pracę w formie wolontariatu dla dobra swoich użytkowników, jak co poniektórzy sądzą na WHT odnośnie niektórych firm.

 

Nie chcę w żadnym wypadku hejtować tego co napisałeś bo masz rację, ale czy nie logicznym byłoby że w interesie firmy jest naprawienie tych błędów?

Nie wiem czemu firma tak postępuje z TSem, może przez to że nie mają zagrożonej pozycji na rynku i nie muszą dbać o jakość. Wystarczy że działa średnio na jeża i dalej jest najlepszym wyborem pod względem wydajności pomimo błędów i problemów.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Według mnie to obecnie nie jest w interesie firmy bo nie ma znaczącej konkurencji. Im więcej dłubania w kodzie tym większe koszta czyli wynagrodzenia dla programistów i mniej zysku. A połatanie wszystkiego nie zajmie dzień czy dwa, trochę się z tym zejdzie. Więc póki użytkownicy to akceptują to im jest na rękę, większy zysk niższymi kosztami. Co innego gdyby nie akceptowali i szukali alternatyw na co na razie się nie zapowiada.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Kamikadze

Ja tam nie wiem po co te rangi. Starczą dwie - trzy. User, gość, admin i tyle.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ja tam nie wiem po co te rangi. Starczą dwie - trzy. User, gość, admin i tyle.

 

 

Dla dzieciarni rangi są priorytetem. Mogą szpanować przed sobą jacy to są ważni.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość

Nie polecam jeden atak DDoS na twój serwer i OVH wyłącza ci serwer teamspeaka

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Nie polecam jeden atak DDoS na twój serwer i OVH wyłącza ci serwer teamspeaka

 

Na starej ofercie VPSów (czyli VZ) kolega przez rok miał TSa a potem Ja. Ani razu mi nie wyłączyli z powodu DDoSa więc możesz nie siać herezji?

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Te pakiety UDP są specyficzne, już kilka lat temu napisałem regułkę iptables, która działa mi do dziś - nie dopuszcza żadnego ataku po UDP do aplikacji - w oparciu o wiele rzeczy takich jak rozmiar pakietu, częstotliwość, a nawet sam content (który też jest do przewidzenia, w szczególności jak serwer używa szyfrowania). Nie, nie podzielę się.

 

Najwidoczniej jeszcze nie miał Pan żadnej styczności z realnym zagrożeniem na teamspeaku. Całowałbym Pana po stopach, gdyby Pana rozwiązanie było realne i efektywne, gdyż dzięki temu byłbym w stanie otworzyć hosting, który bije na głowę rozwiązania mitigacyjne dla Teamspeaków - Incapsuly, Akamai Prolexica, Verisign, NXG, Voxility, Staminus..i tak dalej i tak dalej. Póki co, żaden ddos-team z w/w nie wymyślił tak cudownego rozwiązania jak Pańskie, zwłaszcza, że strukturalnie te pakiety zmieniają sie co kilka update clienta/serwera. :wub::D CTO Teamspeak Systems GmbH również nie widzi takiej szansy jak Pan przedstawił.

Edytowano przez EvoBattle (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Najwidoczniej jeszcze nie miał Pan żadnej styczności z realnym zagrożeniem na teamspeaku. Całowałbym Pana po stopach, gdyby Pana rozwiązanie było realne i efektywne, gdyż dzięki temu byłbym w stanie otworzyć hosting, który bije na głowę rozwiązania mitigacyjne dla Teamspeaków - Incapsuly, Akamai Prolexica, Verisign, NXG, Voxility, Staminus..i tak dalej i tak dalej. Póki co, żaden ddos-team z w/w nie wymyślił tak cudownego rozwiązania jak Pańskie, zwłaszcza, że strukturalnie te pakiety zmieniają sie co kilka update clienta/serwera. :wub::D CTO Teamspeak Systems GmbH również nie widzi takiej szansy jak Pan przedstawił.

 

Chyba się nie zrozumieliśmy - ataki wymierzone są najczęściej w łącze, a nie w aplikacje. Przed atakami w aplikację można się bardzo prosto zabezpieczyć posiadając wiedzę i umiejętności analizy ruchu, którym operuje TS - i właśnie na tej bazie działa moja regułka (i kilka innych implementacji, które u siebie zastosowałem). Łącze to zupełnie inna historia.

Edytowano przez Archi (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość Filip Nowacki

 

Chyba się nie zrozumieliśmy - ataki wymierzone są najczęściej w łącze, a nie w aplikacje. Przed atakami w aplikację można się bardzo prosto zabezpieczyć posiadając wiedzę i umiejętności analizy ruchu, którym operuje TS - i właśnie na tej bazie działa moja regułka (i kilka innych implementacji, które u siebie zastosowałem). Łącze to zupełnie inna historia.

Ataki w łącze? To zależy. Weź na przykład takiego ts3fucka, małym kosztem wywalał samego teamspeaka. Większość ataków, które mają być skuteczne lecą po warstwie aplikacji.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Filipsiu, Archi w pierwszej części odniósł się do ataków ogólnie, a nie konkretnie do ataków na TeamSpeak'a.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ataki w łącze? To zależy. Weź na przykład takiego ts3fucka, małym kosztem wywalał samego teamspeaka. Większość ataków, które mają być skuteczne lecą po warstwie aplikacji.

 

A popatrzyłeś na publicznie dostępne regułki iptables które proponują inni administratorzy? To popatrz dokładniej, bo nie ma w nich niczego czego ja bym nie miał zanim ktoś w ogóle wpadł na pomysł zrobienia ts3fucka - to serio nie jest nic trudnego odpalić jakiegokolwiek sniffera, popatrzeć sobie w pakiety, ich ilość, częstotliwość, i inne zmienne na bazie których możesz zrobić takie regułki, które przykładowo limitują ruch per IP i oczekują konkretnego pierwszego pakietu, żeby akceptować jakiekolwiek pozostałe, i na tym poziomie już 99.9% takich ataków się wycina, bo żaden z nich nie wpadnie na pomysł, żeby najpierw wysłać trochę poprawnego ruchu, aby zmylić moje regułki.

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Przed atakami w aplikację można się bardzo prosto zabezpieczyć posiadając wiedzę i umiejętności analizy ruchu, którym operuje TS - i właśnie na tej bazie działa moja regułka (i kilka innych implementacji, które u siebie zastosowałem). Łącze to zupełnie inna historia.

Wypiłbym z Panem litr wódki ale i tak nie zgodziłbym się z tą tezą. To właśnie ataki aplikacyjne stanowią największy problem. Potrzebują solidnego DPI i jest to syzyfowa praca bazująca na cięciach stringów etc. Zapewniam Pana, że Pana regułka co do "ruchu" na którym Pan operuje nie jest nic warta. Owszem, to o czym Pan mówi, jest całkiem logiczne, ale musiałby Pan sprecyzować cały ruch pod kątem określonych wpisów. Więc regułką iptables Pan tego nie załatwi. :huh:

 

Zwłaszcza w VoIP

 

To właśnie główny problem app-bs ataków, że strukturalnie w 99% przypominają ruch legalny. Zwłaszcza w teamspeaku.

Edytowano przez EvoBattle (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Wypiłbym z Panem litr wódki ale i tak nie zgodziłbym się z tą tezą. To właśnie ataki aplikacyjne stanowią największy problem. Potrzebują solidnego DPI i jest to syzyfowa praca bazująca na cięciach stringów etc. Zapewniam Pana, że Pana regułka co do "ruchu" na którym Pan operuje nie jest nic warta. Owszem, to o czym Pan mówi, jest całkiem logiczne, ale musiałby Pan sprecyzować cały ruch pod kątem określonych wpisów. Więc regułką iptables Pan tego nie załatwi. :huh:

 

"client sends COMMAND_GET_COOKIE=0 (command byte = 0)
packet content is 16 bytes."

"The client replies with COMMAND_SOLVE_PUZZLE=4

The content is the puzzle response + connection initialization data. Should be around 462 bytes, but can vary"

 

 

Cały ruch? Niee, mamy netfiltera i możliwość zapamiętywania stanu komunikacji nawet w przypadku bezstanowego protokołu jakim jest UDP - ogranicza zarówno mnie jak i Was wiedza, którą posiadacie żeby coś takiego zaimplementować. Ja twierdzę, że się da - Ty (a pewnie i cała firma także), że nie. Tak więc możesz albo założyć, że blefuję i mówię o czymś o czym nie mam pojęcia, albo że umiem zrobić coś, co uważasz (lub uważacie) za niemożliwe. A ja mam lepsze rzeczy do roboty niż udowadniać światu, że wiem lepiej, więc śmiało preferuję założenie pierwszego wariantu ;).

 

Nie twierdzę, że aplikacja TS3 jest bezpieczna czy dobrze napisana - bo nie jest, twierdzę natomiast że można porządnie zminimalizować lub nawet wyciąć do zera niepożądany ruch UDP do tejże aplikacji trafiający. A to czy ktoś potrafi to już inna kwestia.

Edytowano przez Gość (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Kochałbym świat, gdyby to o czym Pan mówi, było równie proste do wykonania, co do napisania. Ja owszem..twierdzę, że się da, aczkolwiek skoro póki nikt tego nie dokonał na świecie (udowodniony przypadek, a nie "mam, ale nie dam"), to śmiem twierdzić, że jeszcze dużo czasu minie zanim coś takiego ujrzymy.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×