Ochrona DDoS dla operatora ISP
Jak operator ISP chroni abonentów przed DDoS: dlaczego blackhole to porażka, co psuje CGNAT i gdzie postawić filtrowanie ruchu.
Ostatnia aktualizacja:
Dla operatora ISP atak DDoS wygląda inaczej niż dla właściciela jednej usługi. Celem bywa pojedynczy abonent, ale skutek odczuwa cała baza klientów, bo ruch ataku i tak musi przejść przez współdzielony uplink. Ochrona sprowadza się więc do jednego pytania: gdzie w sieci odrzucić ten ruch, żeby nie zdążył zaszkodzić po drodze.
Dlaczego blackhole jest przegraną, a nie obroną
Najprostszą reakcją jest RTBH, czyli poproszenie operatora nadrzędnego o wrzucenie atakowanego adresu do blackhole'a. Ruch przestaje przychodzić i łącze się odtyka, ale atakowany abonent jest offline, czyli dostał dokładnie to, co miał mu zrobić atakujący. Z perspektywy klienta nie ma różnicy między skutecznym atakiem a skuteczną obroną w tym modelu. Blackhole ma sens jako ostateczność, kiedy alternatywą jest awaria całej sieci, ale nie jako produkt sprzedawany jako ochrona.
BGP FlowSpec daje więcej precyzji, bo pozwala rozesłać reguły dopasowane do adresu, portu, protokołu czy długości pakietu. Nadal jednak działa zgrubnie i wymaga, żeby ktoś napisał regułę pod konkretny wektor. Przy ataku, który zmienia charakterystykę w trakcie, pisanie reguł jest gonieniem celu.
Co psuje CGNAT
Jeśli prowadzisz CGNAT, za jednym publicznym adresem stoją setki abonentów. Atak wycelowany w ten adres jest awarią dla nich wszystkich naraz, a blackhole na tym adresie daje ten sam efekt. Do tego dochodzi wyczerpywanie tablic translacji: zalew nowych sesji zjada wpisy i pule portów, więc usługa psuje się także abonentom, których ruch nie ma nic wspólnego z atakiem. Przy CGNAT filtrowanie musi się odbywać przed urządzeniem NAT, nie za nim.
Warstwy, na których operator faktycznie walczy
| Wektor | Co obciąża | Gdzie odrzucać |
|---|---|---|
| Amplifikacja i reflection UDP | Pasmo uplinku | Brzeg sieci dostawcy, powyżej Twojego portu |
| SYN flood i floody pps | Tablice stanów, CPU urządzeń | Przed zaporą i NAT, z SYN proxy |
| Carpet bombing | Uplink, przy cichych alarmach per IP | Filtrowanie całego prefiksu, bez progów per adres |
| Ataki aplikacyjne (L7) | Aplikacja i baza danych | Filtracja L7, cache i limity po stronie usługi |
Gdzie postawić filtrowanie
Zasada jest jedna: filtr musi stać powyżej wąskiego gardła. Urządzenie we własnej serwerowni chroni to, co za nim, tylko dopóki łącze do niego ma zapas. Kiedy zalew wypełni uplink, sprzęt za nim nie ma już czego bronić, choćby był najlepszy. Dlatego mitygację prowadzi się na brzegu sieci operatora nadrzędnego, tam gdzie jest jeszcze pojemność, żeby wchłonąć ruch ataku.
Praktycznie oznacza to, że chroniony ruch idzie przez sieć dostawcy ochrony. Warto sprawdzić, dokąd dokładnie go prowadzi: czy filtracja odbywa się w kraju i w tej samej sieci, która przenosi ruch, czy ruch jest oddawany podmiotowi trzeciemu i wyprowadzany za granicę. Różnica widać w opóźnieniach, w tym, jak wygląda diagnostyka podczas incydentu, i w tym, kto ogląda dane Twoich abonentów.
Czego wymagać od dostawcy ochrony
- Filtrowanie stanowe, a nie tylko reguły dopasowane do znanych wektorów, bo tych drugich zawsze brakuje pod nowy atak.
- Reakcja bez etapu detekcji i przekierowania, albo jasna informacja, ile trwa uruchomienie ochrony w trybie on-demand.
- Polityki ustawiane per prefiks i per usługa, żeby resolwery DNS, serwery gier i VPN nie padały ofiarą własnej ochrony.
- Zachowanie osiągalności atakowanego adresu zamiast wrzucania go do blackhole'a.
- Obsługa carpet bombingu bez progów liczonych per adres IP.
- Możliwość wpięcia tam, gdzie już jesteś: cross-connect, VLAN w punkcie wymiany ruchu albo tunel GRE.
- Wsparcie NOC dostępne w trakcie incydentu, a nie tylko w godzinach pracy.
Najczęstsze pytania
Czy jako mały operator w ogóle potrzebuję ochrony DDoS?
Skala sieci nie chroni przed atakiem, a mniejszy uplink zapełnia się szybciej. Dla operatora z kilkoma gigabitami wyjścia atak, który u dużego gracza byłby ledwie zauważalny, oznacza zapchane łącze i telefon od każdego abonenta. Praktyczne pytanie brzmi nie czy, tylko w jakim modelu: stała ochrona całego prefiksu czy uruchamiana na żądanie dla wskazanych zakresów.
Czy ochrona DDoS wymaga zmiany dostawcy tranzytu?
Najprościej jest wziąć ochronę razem z tranzytem, bo wtedy filtrowany jest ruch, który i tak idzie przez tego dostawcę. Możliwe są też układy mieszane, gdzie tylko część ruchu albo tylko wskazane prefiksy są prowadzone przez sieć dostawcy ochrony. Przy takim scenariuszu warto z góry ustalić, jak wygląda trasa powrotna i co się dzieje przy awarii tunelu.