5 września 2023
·
9 min czytania
Co przygotować przed wdrożeniem ochrony anty-DDoS: routing bez pętli, sposób zbierania ruchu, serwery i progi. Lista kontrolna dla ISP i data center.
Krótka odpowiedź: przed uruchomieniem filtrowania ruchu DDoS trzeba mieć przygotowane trzy rzeczy: routing, który nie zapętli przekierowanego ruchu, sposób zbierania danych o ruchu (port-mirror, sFlow albo NetFlow/IPFIX) i serwery pod konsolę oraz sensory z filtrami. Jeżeli router obsługuje BGP FlowSpec, pierwszy i trzeci punkt upraszczają się drastycznie — znikają VRF-y, tunele GRE i osobny serwer filtrujący. Z naszego doświadczenia to właśnie przygotowanie po stronie klienta, a nie sama instalacja, zajmuje około 90% czasu całego wdrożenia.
Ten tekst jest listą kontrolną. Przejdź ją przed pierwszym spotkaniem — skróci wdrożenie o tygodnie.
Od czego zacząć: czym ochrona różni się od RTBH?
Zanim cokolwiek zaczniesz przygotowywać, warto ustalić, co właściwie wdrażasz. Większość zespołów mówiąc „ochrona przed DDoS" ma na myśli RTBH (Remotely Triggered Black Hole), bo to jedyny mechanizm, który mieli pod ręką.
RTBH nie jest ochroną. To odcięcie ruchu do atakowanego adresu — z perspektywy klienta końcowego efekt jest taki sam jak udany atak: usługa nie działa. Napastnik osiąga swój cel, tyle że Twoimi rękami. RTBH ma sens jako ratowanie reszty sieci kosztem jednego lub kilku adresów, kiedy nie da się już zrobić nic lepszego. Kiedy dokładnie warto po to sięgnąć, opisaliśmy w tekście o RTBH.
To, czego naprawdę potrzebują Twoi klienci, to filtrowanie ruchu — usunięcie pakietów ataku przy zachowaniu ciągłości komunikacji, bez przerwy i bez zauważalnych opóźnień.
Druga typowa sytuacja: klient ma już jakieś darmowe narzędzie, ale uruchamiane skryptem albo ręcznie przez administratora. To działa dokładnie tak długo, jak długo ktoś patrzy na wykresy — czyli nie o trzeciej w nocy i nie w weekend. Przejście na automatyczne wykrywanie i filtrowanie jest zwykle momentem, w którym zespoły sieciowe trafiają do nas i do systemu WanGuard.
Lista kontrolna: co przygotować przed wdrożeniem
Trzy obszary, w tej kolejności:
| Obszar | Co konkretnie | Kto to robi |
|---|---|---|
| Routing | możliwość rozdzielenia tablic routingu tak, żeby przekierowany ruch nie wracał do pętli — albo router z BGP FlowSpec, który tego nie wymaga | Twój zespół sieciowy |
| Zbieranie ruchu | port-mirror, sFlow albo NetFlow/IPFIX doprowadzony do sensora; przy port-mirrorze także karta i port o odpowiedniej przepustowości | Twój zespół sieciowy |
| Serwery | maszyna pod konsolę oraz maszyny pod sensory z filtrami; dostęp zdalny dla zespołu wdrożeniowego | Twój zespół + ITORO |
Poniżej rozwinięcie tych punktów, które w praktyce sprawiają najwięcej kłopotu.
Dlaczego przekierowanie ruchu grozi pętlą routingu?
To najtrudniejsza część wdrożenia w sieci bez BGP FlowSpec — i najczęstszy powód, dla którego projekt się przeciąga.
Mechanizm jest prosty. Kiedy system wykryje atak, wysyła do routera aktualizację BGP, która przekierowuje ruch do atakowanego prefiksu na serwer filtrujący. Serwer odfiltrowuje atak i wstrzykuje czysty ruch z powrotem do sieci. Problem: ten ruch trafia do tej samej tablicy routingu, w której nadal obowiązuje przekierowanie na serwer filtrujący. Pakiet wraca do filtra. I jeszcze raz. I jeszcze raz.
Rozwiązaniem jest rozdzielenie tablic routingu przy pomocy VRF (Virtual Routing and Forwarding). W typowym projekcie potrzebne są trzy:
- Tablica brzegowa BGP — tu trafiają wszystkie prefiksy od operatorów tranzytowych.
- Tablica wejściowa filtra — VRF z trasą domyślną skierowaną na serwer filtrujący.
- Reszta sieci — podsieci klienckie i usługi, bez widocznych prefiksów światowych z punktu 1.
Alternatywą bywa przekierowanie tunelami GRE, ale to nie znosi problemu — tylko przenosi go w inne miejsce.
Rzecz w tym, że taka przebudowa routingu jest operacją na żywym organizmie. Robisz ją na działającej sieci, z ruchem produkcyjnym i usługami, których nie wolno przerwać. To zadanie na osobne okno serwisowe, plan wycofania i kilka nieprzespanych nocy. Jeśli czytasz ten akapit i myślisz „u nas to się nie uda w rozsądnym czasie" — masz rację, i dlatego istnieje następna sekcja.
Co upraszcza BGP FlowSpec?
Jeśli masz router z obsługą BGP FlowSpec albo planujesz zakup, cały poprzedni rozdział możesz pominąć. FlowSpec rozwiązuje dwa główne problemy naraz:
- Znika problem pętli. Nie przekierowujesz ruchu nigdzie — reguła filtrująca jest instalowana bezpośrednio na interfejsie routera. Nie ma czego zapętlać, więc nie ma potrzeby budowania VRF-ów.
- Znika serwer filtrujący. Filtrowanie odbywa się sprzętowo, z prędkością interfejsu. Czy to 10, 40 czy 100 GE, nie ma znaczenia — obciążenie CPU routera pozostaje pomijalne.
To przekłada się bezpośrednio na budżet: nie kupujesz serwerów filtrujących ani specjalizowanych kart sieciowych, nie przebudowujesz routingu, nie płacisz za tygodnie pracy przy projekcie sieciowym. Zestawienie tego, jak reguła FlowSpec wygląda w praktyce i co da się w niej dopasować, znajdziesz w tekście o filtrowaniu ataków DDoS przez BGP FlowSpec.
Jedno zastrzeżenie z terenu: sam fakt, że producent deklaruje wsparcie FlowSpec, nie wystarczy. Różne platformy różnie radzą sobie z programowaniem reguł w sprzęcie — sprawdź to na konkretnym modelu i konkretnej wersji oprogramowania, zanim podpiszesz zamówienie. Producenci, u których FlowSpec działa w praktyce w sieciach naszych klientów, to Arista, Cisco, Huawei, Juniper i Nokia.
Jak zbierać dane o ruchu?
Sensor potrzebuje widzieć ruch. Masz dwie drogi:
- Port-mirror — kopia całego ruchu trafia na kartę sensora. Najkrótszy czas reakcji, bo sensor widzi pakiety w tej samej chwili co router. Wymaga wolnego portu o odpowiedniej przepustowości i karty sieciowej po stronie serwera.
- NetFlow / IPFIX / sFlow — router eksportuje próbki albo podsumowania przepływów. Tańsze i prostsze, ale eksport wprowadza opóźnienie liczone w dziesiątkach sekund, a próbkowanie zaniża wolumeny małych pakietów.
Przy atakach wolumetrycznych ta różnica jest kluczowa: sieć potrafi paść w kilkadziesiąt sekund, czyli w czasie, w którym NetFlow dopiero eksportuje pierwsze flowy. Jeśli masz wybór — wybierz port-mirror, a NetFlow zostaw jako uzupełnienie do raportowania i planowania łączy.
Instalacja i strojenie: co robimy razem
Kiedy serwery są gotowe i ruch dociera do sensora, sama instalacja jest szybka. Zakres prac wygląda tak:
- Instalacja komponentów — konsola (GUI), sensory i filtry. Zestawienie sesji BGP między serwerem konsoli a routerami (np. przez ExaBGP). Szczegóły opisaliśmy w instrukcji instalacji WanGuard.
- Definicja podsieci i szablonów progów — osobno dla każdego typu środowiska: klienci końcowi, serwery hostingowe, usługi wewnętrzne. Ruch abonenta wygląda inaczej niż ruch serwera pocztowego i progi muszą to odzwierciedlać.
- Wyłączenia — czasem trzeba wyłączyć z ochrony konkretne adresy lub sieci, żeby nie ryzykować naruszenia SLA. Typowy przykład: serwery cache Google albo inne systemy proxy wymieniające dane z wysokimi prędkościami po zamkniętym lub peeringowym łączu, wystarczająco bezpiecznym, by taki wyjątek uzasadnić.
Progi początkowe zawsze się zmieniają. To nie jest wada — to normalny cykl życia wdrożenia. Pierwsze ustawienia są punktem startowym; przez kolejne tygodnie dostrajasz je do rzeczywistych wzorców ruchu, aż system odróżnia poziom normalny od nienormalnego dla każdego segmentu sieci. Celem tego strojenia jest ograniczenie fałszywych alarmów, które niepotrzebnie wyzwalałyby RTBH albo filtrowanie na czystym ruchu.
W sytuacjach kryzysowych — klient pod serią ataków, praktycznie niewidoczny w internecie — potrafiliśmy przy pomocy BGP FlowSpec uruchomić działające filtrowanie w mniej niż 48 godzin. Warunek był zawsze ten sam: serwer gotowy, port-mirror lub inna metoda zbierania ruchu podpięta i działająca.
Podsumowanie: jedno pytanie przed pierwszą rozmową
Zanim zaczniesz porównywać rozwiązania anty-DDoS, odpowiedz sobie na pytanie: czy mój router brzegowy obsługuje BGP FlowSpec? Odpowiedź decyduje o tym, czy wdrożenie będzie projektem sieciowym na kilka tygodni, czy instalacją na kilka dni.
Jeśli planujesz wymianę sprzętu brzegowego w najbliższym czasie, wsparcie dla BGP FlowSpec powinno być pozycją obowiązkową w specyfikacji — niezależnie od tego, czy ochronę wdrażasz teraz, czy za dwa lata. To jeden parametr, który później oszczędza serwery, przebudowę routingu i czas.
Od tego punktu zaczynamy każdą pierwszą rozmowę. Aktualny cennik i kalkulator — bez „zapytaj o wycenę" — znajdziesz na stronie Cennik.
Najczęstsze pytania
Ile trwa wdrożenie ochrony anty-DDoS?
Zależy prawie wyłącznie od stanu przygotowania po stronie sieci. Przy routerze z BGP FlowSpec, gotowym serwerze i podpiętym zbieraniu ruchu działające filtrowanie potrafi ruszyć w ciągu kilku dni, a w trybie kryzysowym w mniej niż 48 godzin. Bez FlowSpec dochodzi przebudowa routingu z VRF-ami, która sama w sobie jest osobnym projektem sieciowym.
Czy potrzebuję serwera filtrującego, jeśli mam BGP FlowSpec?
Nie. Przy filtrowaniu opartym na FlowSpec reguły instalują się bezpośrednio na interfejsach routera i wykonują sprzętowo, więc osobny serwer filtrujący i specjalizowane karty sieciowe są zbędne. Nadal potrzebujesz serwera pod konsolę i sensor — ale to znacznie mniejszy wydatek.
Co jest lepsze do wykrywania: port-mirror czy NetFlow?
Port-mirror, jeśli zależy Ci na czasie reakcji — sensor widzi pakiety natychmiast, bez czekania na eksport przepływów. NetFlow, IPFIX i sFlow są tańsze i prostsze do uruchomienia, ale opóźnienie eksportu i próbkowanie sprawiają, że przy szybkich atakach wolumetrycznych reakcja przychodzi już po fakcie. Wiele sieci używa obu metod równolegle.
Czy muszę wyłączać jakieś adresy z ochrony?
Czasem tak. Systemy generujące bardzo wysokie, ale legalne wolumeny — serwery cache dużych dostawców treści, systemy proxy wymieniające dane po peeringu — potrafią wyglądać dla systemu wykrywania jak anomalia. Jeśli łącze do nich jest zamknięte lub peeringowe i wystarczająco bezpieczne, wyłączenie ich z ochrony jest tańsze niż tłumaczenie fałszywych alarmów.
Kiedy najlepiej rozmawiać o ochronie przed DDoS?
Najlepiej przed wymianą routera brzegowego, a nie po. Decyzja o zakupie sprzętu z obsługą BGP FlowSpec albo bez niej przesądza o architekturze ochrony na kilka następnych lat i o tym, ile będzie kosztować jej uruchomienie. Drugi dobry moment to planowanie budżetu — właśnie wtedy najłatwiej dopisać jedną pozycję do specyfikacji.
