Skocz do zawartości

Rolej

WHT Pro
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    636

  • Rejestracja

  • Ostatnio

  • Wygrane dni

    6

Posty napisane przez Rolej

  1. Napisano · Raportuj odpowiedź

    Cześć.

     

    Próbuje przepchnąć przez Debiana 8.3 kernela 4.4.2 z grem. Wszystko byłoby świetnie gdyby nie to:

     

     

    modprobe: module ehci-orion not found in modules.dep

     

    Sprawdziłem .config - nigdzie tego nie ma. Ktoś się z tym już spotkał i poradzi coś?

  7. Napisano · Raportuj odpowiedź

    Powracam do tematu.

     

    KVM (Proxmox 4). Sieć w trybie bridge (vmbr0). Dziennie jeden użytkownik potrafi polecieć po kilka razy. Z OVH cały czas to wyjaśniam, jednak Ja i moi użytkownicy mamy już końcówkę cierpliwości. Głównie problem ma TP, Plus, lokalny provider z Wrocławia. Gdzie może być ten problem? Czy problemem może być karta sieciowa w serwerze?

     

  11. Napisano · Raportuj odpowiedź

    (..)

     

    Czy nie zasadnym byłoby połączyć siły i napisać petycję do szwabów ażeby naprawili swoje nędzne błędy?

     

    (..)

     

    P.S. Nie wnikam skąd r4p3 mają źródełka, ale jak to jest że oni potrafią szybciej napisać patch niż właściciel apki... Btw. kto nie ma VIP'a u nich to exploit dostępny na popularnym forum *.onion.

     

    No to tak... - dość spora część licencji to są licencje NPL. Czyli darmowe. Czyli tak naprawdę można zlać człowieka, bo nie płaci. Czyli dziury w aplikacji to nic nowego. Czyli petycje nic nie dadzą. Osobiście nie zdziwiłaby mnie postawa TSa, gdyby powstały dwie wersje TS Server - darmowa, dla wszystkich No license, NPL, gdzie byłyby łatane jedynie większe luki, dodawane usprawnienia lub byłaby swoistym poligonem doświadczalnym a wszystkie inne płatne, wersje łatane co krótszą chwilę, łatająca każde dziurki.

     

    Skąd r4p3 ma wtyki - ja mam teorię. Albo wtyka w samym TSie, albo backdoor, którego nikt nie widzi. Robimy zakłady? ;)

     

    Nie, cokolwiek byś nie zrobił, jakiekolwiek byś filtrowanie nie zrobił i regułki nie poustawiał to i tak aplikacja/usługa powinna być zabezpieczona na wszelki niepożądany i niewłaściwy ruch do niej docierający. De facto administrator jako taki nie powinien w ogóle robić jakichkolwiek regułek aplikacyjnych - wyłącznie limitowanie ilości pakietów, ale to jest obrona przed atakiem na łącze a nie aplikację.

     

    (..)

     

    ​Na naszym przykładzie widać, że można z TSa robić magisterki z zabezpieczeń, bo co chwilę można znaleźć nowe dziury w filtrach, zabezpieczeniach itp. Swoją drogą - jakiekolwiek filtrowanie z poziomu iptables, stawianie IPS, gr+pax etc. cokolwiek by zadziałało w przypadku dziur w TSie?

     

    Najprościej przenieść się na lepsze środowisko jakim jest chociażby Mumble ;)

     

    Wytłumaczysz to graczom/użytkownikom? Bo chyba dalej mamy erę TSa, a Mumble jest stosowane w konkretnych społecznościach.

     

     

     

    1. Zmienić port 30033 na jakiś niestandardowy przy pomocy ts3server.ini.

    2. Zlimitować nowy port

    3. Atakującemu nie będzie się chciało czekać lub skanować portów ;P

     

    ​Myślisz, że ktoś nie będzie sobie zadawał trudu by ten port znaleźć? Uwierz, znajdą się tacy, którzy to zrobią.Albo będą walić na oślep.

     

    P.S. Blokada nicku "TeamSleep" + blokowanie adresacji tego webowego gówna działa tylko na wersję webową...

     

    W​Nawet to nic nie da. Moim zdaniem lekka modyfikacja exploita, zniweluje to mini zabezpieczenie.

     

    Póki co nasze serwery jako tako nie zgłaszają problemu z tym TeamSleep, aczkolwiek jak dostarczycie mi jakieś precyzyjniejsze informacje co konkretnie się dzieje z serwerem, co pojawia się w error logu, to być może będę w stanie coś pokombinować.

     

    Gdybym miał takie logi to chętnie bym podjął współpracę z BlazingFast, mimo, że jestem w OVH. Zawsze by można było się wymieniać doświadczeniami ;) Jednak póki co nikt mnie nie atakuje tym czymś.

     

     

    __

     

    A gdybyśmy My, jak tu stoimy, jesteśmy, ruszamy się, stworzyli społeczność, która dla swoich społeczności tworzyła zabezpieczenia dot. tego typu usług? Zawsze to dość ciekawa forma wymiany doświadczeń itp.

     

  20. Napisano · Raportuj odpowiedź

    Telefon do nich może w końcu coś zadziałać? Po tej odpowiedzi mam dosyć kobiet w IT:

     

    Witam, Liczy sie to co jest tak naprawde na osatnim elemencie infrastruktury, a więc na Pana serwerze - tam strat w pakietach ani opóźnień nie ma, wyżej, sa jedynie 10% opóźnienia i to bez strat, które nadrabia reszta infrastruktury. Co do pingu do bramy - urządzenia CISCO nie mają obowiązku odpowidzi na zapytania ICMP, równie dobrze mogłyby wykazywać straty a jednocześnie działać idealnie.

  21. Napisano · Raportuj odpowiedź

    Cześć.

     

    Od prawie dwóch tygodni usiłuje od OVH się wywiedzieć, dlaczego do mojego serwera mam packet loss na poziomie 13%. Problem narodził się po DDoSie (znaczy - został wykryty) i od tego momentu jest przekładanie z Francji na Polskę, jeżeli chodzi o suport. Ja już nie mam pomysłu jak uderzyć, żeby zareagowali. mtr zrobiony, nie jest cudowny, pingi do bramy powinny być o wiele lepsze. Co może być nie tak?

     

    ping xxx.xxx.xxx.254

     

    PING xxx.xxx.xxx.254 (xxx.xxx.xxx.254) 56(84) bytes of data.
64 bytes from xxx.xxx.xxx.254: icmp_seq=1 ttl=255 time=3.84 ms
64 bytes from xxx.xxx.xxx.254: icmp_seq=2 ttl=255 time=5.57 ms
64 bytes from xxx.xxx.xxx.254: icmp_seq=3 ttl=255 time=3.26 ms
64 bytes from xxx.xxx.xxx.254: icmp_seq=4 ttl=255 time=5.55 ms
64 bytes from xxx.xxx.xxx.254: icmp_seq=5 ttl=255 time=2.83 ms

    mtr:

     

    mtr -rwc 100 proof.ovh.net 
Start: Fri Jan 29 11:26:48 2016 
HOST: ns3029530 Loss% Snt Last Avg Best Wrst StDev 
1.|-- rbx-1-6k.fr.eu 10.0% 100 1.2 3.6 0.9 8.3 1.2 
2.|-- rbx-s3-6k.fr.eu 0.0% 100 1.9 5.9 0.4 193.9 24.9 
3.|-- proof.ovh.net 0.0% 100 0.4 0.4 0.3 0.7 0.0
    Najbardziej jest to zauważalne przy dropach na TSie. Dropy głównie dotyczą TP, Orange, Vectra oraz dostawców lokalnych w moim rejonie.

  22. Napisano · Raportuj odpowiedź

    OVH, RBX1

     

    traceroute to 185.25.151.42 (185.25.151.42), 30 hops max, 60 byte packets
 1  rbx1-3b-a9.fr.eu (91.121.73.253)  1.487 ms  3.758 ms  3.724 ms
 2  rbx-g2-a9.fr.eu (37.187.231.97)  0.770 ms  0.752 ms rbx-g1-a9.fr.eu (37.187.231.95)  2.264 ms
 3  ams-5-a9.nl.eu (94.23.122.79)  5.778 ms  5.733 ms  5.714 ms
 4  * * var-5-6k.pl.eu (91.121.215.193)  69.372 ms
 5  atm.plix.pl (195.182.218.8)  32.767 ms  44.293 ms  30.698 ms
 6  xe-2-0-0-48.r5.isp-rs.thinx.atman.pl (212.91.0.13)  35.173 ms  35.025 ms  34.988 ms
 7  rev-212.91.24.146.atman.pl (212.91.24.146)  37.819 ms  49.620 ms  36.500 ms
 8  * * *
 9  * * *
10  185a25b151c42.greendata.pl (185.25.151.42)  35.637 ms  35.544 ms  35.482 ms
×