Skocz do zawartości

Ubinoob

Użytkownicy
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    58

  • Rejestracja

  • Ostatnio

  • Wygrane dni

    4

Posty napisane przez Ubinoob

  9. Napisano · Raportuj odpowiedź

    Taką sytuację obserwuję od ponad roku. Kilkukrotnie to zgłaszałem, bo zwyczajnie myślałem że to jakiś błąd, ale że nie doskwierało mi to tak bardzo to nie dążyłem do uzyskania sensownej odpowiedzi. Na dedykach oczywiście wszystko działa.

     

    Jeśli chodzi o stałą filtrację to uruchamia ona jedynie firewall-network i tilerę, więc filtrację dla niewielkiej ilości ataków. Natomiast nie w tym rzecz, bo gdy atak zostanie wykryty, załącza się arbor/armor (niezależnie od stałej filtracji) i można się pożegnać z UDP.

  10. Napisano · Raportuj odpowiedź

    Dziś miałem tą przyjemność (albo i nie) dowiedzieć się czegoś ciekawego o konfiguracji VAC, co jest dosyć ważne dla potencjalnych kupujących a nie ma nigdzie o tym wzmianki. Wszystkie usługi współdzielone (w tym oczywiście vps, pci, inne usługi cloud itd.) posiadają taką konfiguracje VAC'a że UDP jest w zasadzie całkowicie odcinane BEZ FILTROWANIA! Wyjątkiem są serwery dedykowane.

     

    Odpowiedzi od OVH na zgłoszenie problemu ciągłego odcinania UDP w przypadku każdego rodzaju ataku:

     

     

    Na serwerach VPS wycinany jest za każdym razem ruch UDP, w przypadku każdego możliwego ataku. Zalecamy w tym przypadku przejście na serwery z gamy serweów Dedykowanych, filtry AntyDDoS nie zostana zmodyfikowane dla VPS.

     

     

     

    Tyczy się to wszystkich usług opartych o zasoby współdzielone, czyli VPS, instancje PCI i inne usługi Cloud.

    Przy serwerach dedykowanych ruch jest filtrowany a przy serwerach GAME, jest ochrona dodatkowa UDP.

     

    Po moich zastrzeżeniach dotyczących dostępności tej informacji przed zakupem, dostałem odpowiedź że moja sugestia została przekazana do działu marketingu. Prawdę mówiąc we wszystkich usługach, czy to public cloud, czy dedykach widnieje ładne "Anty-DDoS Pro", gdzie możemy wyczytać o filtracji UDP a jednak nie do końca tak jest. Nie trzymam na tym serwerze żadnych gier czy innych głupot, ale np. OpenVPN na UDP działa znacznie wydajniej, a w momencie ataku można zapomnieć o UDP. Jeśli więc komuś zależy na postawieniu czegokolwiek co wymaga UDP to wszelkiego rodzaju instancje chmurowe, vpsy itp. w OVH to słaby pomysł (chyba że liczymy się z niedostępnością w momencie załączenia VAC).

  12. Napisano · Raportuj odpowiedź

    Sieć Multimediów nie jest zbyt wydajna, wystarczy spojrzeć na to jaką maksymalną przepustowość oferują, nie jest ona zbyt duża w porównaniu do konkurencji na podobnej technologii :)

     

    A może zwyczajnie nie ścigają się na te mocno overbookowane cyferki, które przeciętnemu Kowalskiemu nie są potrzebne? Jeżeli komuś to nie przeszkadza to od siebie powiem tyle, że w zasadzie nie ma na co u nich narzekać. Oczywiście wiele zależy od lokalizacji. Jeśli chodzi o brzeg to obecnie globala wypychają za pomocą COGENT'a i TATA, jest PLIX, TPIX, EPIX, DECIX, jest tranzyt do TPNET. Oprócz drobnych potknięć w postaci ostatnio przytykającego się TPIX'a jest ok. W szkielecie też bardzo niskie czasy.

     

    Koniec OT.

  13. Napisano · Edytowano przez Ubinoob (zobacz historię edycji) · Raportuj odpowiedź

    @Czoobek: OVH ma PNI z UPC i szczerze mówiąc pierwszy raz słyszę o takim problemie z tak niską przepustowością. Sprawdź tutaj: http://rbx.proof.ovh.net/ jeśli wynik jest ok to proponuje dokonanie kilku pomiarów iperfem. Może coś nie tak na routerze/switchu do którego jesteś podpięty lub na samej maszynie.

    • Upvote 1

  15. Napisano · Raportuj odpowiedź

    To, że cache "po drodze" może się różnie zachowywać. Weź też pod uwagę, że systemu DNS nie obsługuje jeden serwer i nie na każdym ta konfiguracja jest już odświeżona. Podany przez Ciebie objaw jest jak najbardziej normalny. Gratulacje natomiast należą się Tobie, za ignorancję tego co powiedzieli bardziej doświadczeni. Zadajesz pytanie, a potem odrzucasz z automatu odpowiedzi...

  16. Napisano · Raportuj odpowiedź

    Pełno opów ma obecnie na sztywno poustawiane różne localprefy na sesjach z OVH i wielu wciąż leci przez zagranicę. Często nawet ciężko jest OVH to zmienić (no chyba że zgasić sesję). Faktycznie warto zgłaszać na peering@ovh.net, ale trzeba się liczyć z tym, że to może potrwać (tak jak sprawa z preferencją vectry).

  18. Napisano · Raportuj odpowiedź

    Przetestowałem to u siebie i szczerze mówiąc ciekawy jest tylko problem z potokami, bo faktycznie przykład z whoami nic nie loguje (jak użyjemy np. touch to plik się tworzy). Natomiast odpaliłem sobie regułkę:

    /etc IN_MODIFY,IN_CREATE,IN_DELETE /bin/sh /root/testincron

    (tylko i wyłącznie ta jedyna reguła) i skrypt z Twoją zawartością się bez problemu uruchomił.

    #!/bin/sh

date +"%m/%d/%Y %H:%M:%S $HOSTNAME" >> /root/log.txt

    Jeśli nie "date" to spróbuj użyć zwykłe "touch /root/test" czy przynajmniej skrypt startuje.

  21. Napisano · Raportuj odpowiedź

    Sprawdź czy on uruchamia to faktycznie na roocie (w przeciwnym wypadku nie uda mu się dostać do katalogu):

    /etc IN_MODIFY,IN_CREATE,IN_DELETE /usr/bin/whoami >> /tmp/test.log

    Jeśli faktycznie na roocie, to spróbuj w swoim skrypcie zmienić:

    /bin/date +"%m/%d/%Y %H:%M:%S $HOSTNAME" >> /root/log.txt

    Ewentualnie można spróbować zobaczyć o jest w $PATH i próbować je ustawić.

  24. Napisano · Raportuj odpowiedź

    VAC w Polsce jest aktywny, ale atakowane IP nie są jeszcze do niego routowane (pewnie konfigurują). Podejrzewam, że będą blokami je dodawać i obserwować co się dzieje. Dodawanie reguł "Firewall Network" nie ma nic wspólnego z nową technologią (arbor > armor), bo akurat one są obsługiwane przez CISCO ASR9001, które tutaj też istnieje.

×