Nera/Ochrona anty-DDoS
Ochrona wchodzi w skład tranzytu IP. Nie naliczamy opłat za mitygację, za czas jej trwania ani za liczbę ataków.
Routery brzegowe wysyłają próbki sFlow do systemu wykrywania.
System wykrywania zgłasza alarm, gdy ruch przekroczy próg klasy albo profil ruchu.
Gdy natężenie wyraźnie przekroczy próg albo profil, system wykrywania uznaje ruch za atak i w ciągu 1 sekundy od tej chwili uruchamia mitygację. Ruch do atakowanej przestrzeni kieruje do systemu oczyszczającego trasami /25 i dłuższymi, ogłaszanymi w naszej sieci.
Mitygacja kończy się razem z alarmem, a ruch znów idzie wprost do Twojego portu.
Przykład
Ogłaszasz nam prefiks 203.0.113.0/24. Na liście chronionej przestrzeni zapisujemy go jako dwa prefiksy: 203.0.113.0/25 i 203.0.113.128/25. Trasy przekierowania są więc bardziej szczegółowe niż Twoja trasa, na naszym routerze brzegowym mają pierwszeństwo przed nią i ruch do przekierowanej przestrzeni idzie przez system oczyszczający.
| Mechanizm | Co mierzy | Kiedy zgłasza alarm | Co możesz zmienić |
|---|---|---|---|
| Progi klas ruchu | Ruch do każdego adresu osobno, w 24 klasach: Total Traffic, cztery klasy TCP, UDP, ICMP, trzy klasy IP, DNS i 13 klas Amplification. | Gdy ruch do adresu przekroczy próg klasy w bitach albo w pakietach na sekundę. Mitygację system wykrywania uruchamia, gdy natężenie wyraźnie przekroczy próg. | Progi zmieniasz w panelu albo przez API. Panel pokazuje, czy nowa wartość już działa. |
| Profil ruchu | Typowy ruch całej chronionej przestrzeni, przychodzący i wychodzący. | Gdy ruch wyraźnie przekroczy profil, także wtedy, gdy mieści się w progach klas. Ruchu poniżej stałego progu dolnego profil nie zgłasza. | Nie zmieniasz ich. Parametry profilu są wspólne dla wszystkich klientów. |
Szybkie wykrywanie gwałtownych zalewów jest włączone u każdego klienta. Wartości domyślnych progów nie publikujemy, bo atakujący mógłby wtedy utrzymywać natężenie tuż poniżej progu.
Atak wolumetryczny ma wysycić łącze albo port, niezależnie od protokołu.
Total Traffic · UDP · IP Fragmentation
Mechanizmy atakówUsługi UDP odsyłają do celu odpowiedzi większe od zapytań, które atakujący wysłał z adresem źródłowym podrobionym na adres celu. Każda z 13 klas ma własny próg.
Amplification: DNS · NTP · SSDP · SNMP · Chargen · Memcached · CLDAP · mDNS · NetBIOS · RPCbind · RIPv1 · L2TP · MSSQL
Porty usług wykorzystywanych do amplifikacjiW zalewie TCP do celu trafiają pakiety z flagą SYN, z flagami SYN i ACK, z flagą RST albo bez flag.
TCP SYN · TCP SYN-ACK · TCP RST · TCP NULL
Flagi TCP w zalewachKlasa DNS ma własny próg, liczony wyłącznie w pakietach na sekundę i niezależny od progu DNS Amplification.
DNS
DNS i DNS Amplification w tabeli klasKlasa ICMP i dwie klasy pakietów IP mają własne progi, liczone wyłącznie w pakietach na sekundę.
ICMP · IP Null · IP Private
Wszystkie klasy ruchuAtak rozkłada ruch na wiele adresów podsieci tak, że żaden z nich nie przekracza progu. Wykrywa go profil ruchu całej chronionej przestrzeni.
Atak rozłożony na podsiećAtak pojawia się w panelu dopiero wtedy, gdy system wykrywania uruchomi dla niego mitygację, a jego szczyt osiągnie 5 Gb/s. Alarmu bez mitygacji ani mniejszego ataku panel nie pokazuje.
Karta trwających ataków pokazuje przy każdym prefiksie etap „Wykryto” i stan przekierowania: „Ruch przekierowany do oczyszczania”, „Przekierowanie niepotwierdzone” albo „Stan przekierowania nieznany”.
Podaje też klasy ruchu oraz natężenie bieżące i szczytowe w bitach i pakietach na sekundę.
Strona ataku podaje przebieg minuta po minucie, przekroczone progi z godziną i zmierzoną wartością oraz ocenę NOC.
Po zakończeniu ataku pokazuje też charakterystykę ruchu: kraje i AS źródeł, protokoły, porty, flagi TCP, rozkład wielkości pakietów i przepływy o największym natężeniu.
Kraje źródłowe i adresy o największym natężeniu zmierzył system wykrywania. Wykaz adresów źródłowych, także w CSV, obejmuje wszystkich nadawców ruchu do atakowanego adresu, również ruchu prawidłowego.
Każdy atak w panelu dostaje numerowany raport PDF z przebiegiem, charakterystyką ruchu i adresami źródłowymi o największym natężeniu.
| Kanał | Zasada |
|---|---|
| Wiadomość o ataku wysyłamy, gdy jego szczyt osiągnie 5 Gb/s, także wtedy, gdy atak przekroczy tę wartość dopiero po wykryciu. Raport z ataku zastępuje osobną wiadomość o końcu ataku. Dla każdego adresu e-mail możesz ustawić wyższy próg szczytu. | |
| Webhook | Zdarzenia attack.detected i attack.ended wysyłamy przy każdym ataku widocznym w panelu, czyli od 5 Gb/s szczytu. |
Jak czytać raportStrona ataku w dokumentacjiAdresy e-mail, tematy i webhooki
| Cecha | Ochrona w tranzycie Nera | RTBH u dostawcy tranzytu | Ochrona na żądanie | Tunel GRE do centrum oczyszczania |
|---|---|---|---|---|
| Kiedy działa | Stale, bez zgłoszenia i bez potwierdzenia z Twojej strony | Po oznaczeniu prefiksu community blackhole albo po decyzji dostawcy | Po zgłoszeniu ataku i włączeniu ochrony przez dostawcę | Po skierowaniu ruchu do centrum oczyszczania |
| Ruch do atakowanego adresu | Po oczyszczeniu trafia do Twojego portu | Odrzucany w całości, także ruch prawidłowy | Bez filtrowania do chwili włączenia ochrony | Po oczyszczeniu wraca tunelem |
| Po Twojej stronie | Sesja BGP z nami i obiekty route w bazie RIR | Obsługa community blackhole | Kontakt z dostawcą w trakcie ataku | Tunel GRE, mniejsze MTU, prefiks ogłaszany przez dostawcę ochrony |
| W ofercie Nera | Tak | Stosujemy sami w przypadkach określonych w umowie | Nie oferujemy | Nie oferujemy |
Ruch odrzucony w oczyszczaniu nie dociera do Twojego portu i nie wchodzi do pomiaru 95. percentyla. Ruch, który do portu dotarł, liczy się w całości.
Jak liczymy 95. percentylPrzekierowanie wydłuża trasę ruchu do atakowanej przestrzeni adresowej. Filtrowanie może odrzucić część ruchu prawidłowego, zwiększyć opóźnienia albo czasowo ograniczyć dostępność niektórych usług. Te skutki ograniczamy na podstawie formularza wdrożeniowego, w którym wskazujesz ruch, którego nie wolno odrzucać.
Ochronę świadczymy w modelu best effort i nie gwarantujemy wykrycia ani odparcia każdego ataku. SLA dotyczy dostępności sieci, portu i ścieżki ochronnej, a nie skuteczności ochrony. Przyjmujemy zgłoszenia ataków, podejmujemy racjonalne działania ograniczające ich skutki, informujemy o istotnym przebiegu incydentu i współdziałamy przy przywracaniu usługi.
Wartości łączne dla wszystkich klientów
Tyle ruchu ataku nasza infrastruktura jest w stanie przyjąć i przetworzyć. Do tej wartości, wskazanej w Zamówieniu, świadczymy ochronę. Nie jest to wolumen zarezerwowany dla jednego klienta. Nie zobowiązujemy się do rozbudowy infrastruktury na potrzeby konkretnego ataku.
RTBH polega na zgłoszeniu prefiksu naszym dostawcom tranzytu tak, że na swoim brzegu odrzucają cały ruch do niego. Możemy go zastosować wobec atakowanego adresu albo prefiksu, gdy atak przekracza Wielkość Infrastruktury, zagraża stabilności naszej sieci, innym klientom albo łączności z dostawcami tranzytu, albo gdy dostawca tranzytu z powodu ataku sam ogranicza albo odcina ruch. Adres albo prefiks objęty RTBH jest niedostępny w Internecie także dla ruchu prawidłowego.
Formularz wdrożeniowy wypełniasz po polsku albo po angielsku, w wersji dla swojego rodzaju sieci.
Nie. Ochrona obejmuje prefiksy IPv4 o długości do /24 włącznie. Sesję BGP dla IPv6 zestawiamy na tym samym porcie i w ramach tej samej opłaty co sesję IPv4.
Nie. Wykrywanie i oczyszczanie obejmują ruch, który przechodzi przez naszą sieć. Ruch od innych dostawców tranzytu dociera do Ciebie z pominięciem systemu oczyszczającego.
Nie. Prefiks, który przestajesz ogłaszać, schodzi z listy chronionych prefiksów po 60 minutach i tylko wtedy, gdy wszystkie Twoje sesje BGP z nami działają.
Nie. Progi są wspólne dla całego konta i dotyczą każdego adresu osobno. Nowy prefiks od razu ma te same progi co pozostałe.
Zgłoś go do NOC kanałem podanym w umowie. NOC przyjmuje zgłoszenia całą dobę, 7 dni w tygodniu. Zgłoś też sytuację, w której usługi są niedostępne mimo trwającej mitygacji albo stan przekierowania pozostaje nieznany dłużej niż kilka minut.
Do zapytania dołącz numer AS, prefiksy i opis usług, które pod nimi działają.