11 maja 2018 · 6 min czytania

Sensor gubi pakiety przy 20 Gbps, a część ataków przechodzi niezauważona. Jak PF_RING ZC omija stos sieciowy jądra i uwalnia ponad 70% CPU.

Krótka odpowiedź: przy ruchu rzędu 19–20 Gbps standardowe przechwytywanie pakietów przez stos sieciowy Linuksa wysyca CPU i zaczyna gubić pakiety. Zgubiony pakiet to pakiet, którego sensor nie policzył — a jeśli zgubi ich dość, atak nie przekroczy progu i przejdzie niezauważony. PF_RING ZC (zero copy) omija jądro i podaje pakiety bezpośrednio do aplikacji, co w opisanym wdrożeniu dało ponad 70% oszczędności CPU względem standardowego PF_RING i pozwoliło pracować z pełną prędkością łącza na obu portach.

Problem: sensor, który nie widzi całego ruchu

Klient zgłosił się do ITORO z konkretnym objawem: przy ruchu około 19–20 Gbps procesor serwera sensora był wysycony, a w procesie przechwytywania pakietów pojawiały się drop-y. Skutek nie był kosmetyczny — WanGuard nie widział całości ruchu, więc część ataków przechodziła dalej i docierała do usług hostingowych.

Ten mechanizm bywa mylnie interpretowany jako źle ustawione progi. Detekcja anomalii opiera się na porównaniu zmierzonego wolumenu (pakiety/s, bity/s, liczba flowów per dekoder) z progiem. Jeśli karta sieciowa albo jądro odrzuca co trzeci pakiet, sensor mierzy zaniżoną wartość — atak o realnych 900 kpps w statystykach wygląda na 600 kpps i przy progu 700 kpps alarm nigdy nie powstanie. To najgorszy możliwy tryb pracy systemu wykrywania: cichy fałszywy negatyw.

Dlatego pierwszą rzeczą do sprawdzenia po wdrożeniu nie są progi, tylko liczniki drop-ów na interfejsie przechwytującym.

Co zrobiliśmy najpierw: strojenie sterownika, przerwań i kolejek RX

Przejście na PF_RING ZC to poważniejsza operacja, więc jako szybkie rozwiązanie ITORO przestroiło sterowniki przechwytywania, przerwania i kolejki RX — i drop-y zniknęły. To rozwiązanie doraźne, ale w wielu sieciach wystarcza na tyle długo, żeby spokojnie zaplanować okno serwisowe.

Typowe rzeczy, które w tym kroku się sprawdza: liczba kolejek RX i ich rozłożenie na osobne rdzenie (a nie zbicie na CPU0), przypisanie przerwań (irqbalance potrafi psuć starannie ustawione powinowactwo), rozmiar bufora ring na karcie oraz to, czy sensor nie dzieli rdzeni z procesami okresowo zjadającymi CPU.

Punktem odniesienia są liczniki karty:

ethtool -S ethX

Jeżeli rosną rx_missed_errors albo rx_no_buffer_count, problem jest po stronie przechwytywania, a nie po stronie progów detekcji.

Dlaczego PF_RING ZC daje skok wydajności

Standardowa ścieżka pakietu w Linuksie zakłada kopiowanie danych ze sterownika do struktur jądra, a potem do przestrzeni użytkownika. Przy kilkunastu milionach pakietów na sekundę sam ten narzut kosztuje więcej niż analiza.

PF_RING ZC działa w trybie kernel bypass: interfejs przechwytujący jest wyjęty ze stosu sieciowego jądra, a pakiety trafiają do aplikacji bez kopiowania. System oszczędza czas CPU i cykle pamięciowe.

Ma to jedną istotną konsekwencję, o której trzeba wiedzieć przed wdrożeniem: karta w trybie ZC może być obsługiwana z pełną prędkością tylko przez jedną aplikację. To nie jest interfejs, na którym postawisz przy okazji drugi kolektor czy tcpdump do diagnostyki.

Pułapka wdrożeniowa: jeden sterownik do wszystkiego

W opisywanym wdrożeniu klient używał kart Intel 10 GE do przechwytywania, filtrowania i do zarządzania serwerem. Wszystko opierało się więc na jednym sterowniku — ixgbe.

To dokładnie ten scenariusz, który zamienia dziesięciominutową zmianę w wyjazd do serwerowni. Każda modyfikacja sterownika oznaczała, że wszystkie interfejsy stawały się niedostępne, łącznie z tym, przez który administrator był zalogowany. Pełną instalację trzeba było przeprowadzić z konsoli offline.

Zalecenie praktyczne: nie stawiaj całego systemu na jednym sterowniku. Adresy zarządzania warto wynieść na osobną kartę — na przykład 1 GE albo kartę innego producenta. Wtedy przeładowanie ixgbe przy pracach na kartach 10 GE nie zrywa dostępu do serwera. Drugi element tej samej higieny to działający dostęp out-of-band (IPMI/iLO/iDRAC), sprawdzony zanim będzie potrzebny.

Konfiguracja: interfejsy Sniffing i Management

Po wygenerowaniu licencji PF_RING ZC i ustawieniu wymaganych parametrów sterownika kolejnym krokiem jest rozdzielenie interfejsów na Sniffing i Management. PF_RING musi wiedzieć, które interfejsy mają nadal korzystać ze standardowego sterownika ixgbe do normalnej komunikacji, a które przejść pod silnik ZC.

Interfejsy przechwytujące pracują wtedy w trybie kernel bypass. Ich adresacja IP przestaje mieć znaczenie — nie ma tam już stosu sieciowego, jest tylko strumień pakietów podawany do sensora.

Praktyczna wskazówka: zaplanuj okno serwisowe. Zmiana wymaga ingerencji w konfigurację serwera i restartu, a przy jednym sterowniku na wszystkim — także fizycznego lub out-of-band dostępu do maszyny. Szczegóły instalacji samego systemu opisaliśmy osobno w instalacji WanGuard.

Efekt

Silnik PF_RING ZC pozwolił interfejsom pracować z pełną prędkością łącza — przechwytywanie osiągnęło pełne 10 Gbps na obu portach. Po stronie procesora odnotowaliśmy ponad 70% oszczędności w porównaniu ze standardowym PF_RING. Ten zapas nie poszedł na marne: trafił do silnika filtrowania WanGuard, który dostał realnie więcej mocy obliczeniowej.

Podziękowania dla zespołu NTOP.org — Alfreda Cardigliano i Luki Deri — za wsparcie przy dostrojeniu sterownika.

Jeśli planujesz sensor pracujący z ruchem powyżej 10 Gbps, dobór kart i sterownika to decyzja na etapie specyfikacji serwera, a nie po pierwszym przegapionym ataku. Architekturę opisaliśmy na stronie o WanGuard, a z doborem sprzętu pomagamy w ramach wsparcia technicznego.

Najczęstsze pytania

Skąd wiem, że mój sensor gubi pakiety?

Sprawdź liczniki karty (ethtool -S) pod kątem rx_missed_errors i rx_no_buffer_count oraz statystyki drop-ów w samym sensorze. Drugi sygnał to porównanie wolumenu ruchu widzianego przez sensor z licznikami SNMP na routerze — jeśli sensor konsekwentnie pokazuje mniej, różnica jest właśnie tam.

Czy PF_RING ZC jest zawsze potrzebny?

Nie. Przy niższych prędkościach i mniejszej liczbie pakietów na sekundę zwykle wystarcza poprawne rozłożenie kolejek RX i przerwań oraz standardowy PF_RING. ZC staje się konieczny wtedy, gdy sam narzut kopiowania pakietów przez jądro zjada procesor — czyli przy kilkunastu i więcej Gbps ruchu o dużej liczbie małych pakietów.

Czy mogę uruchomić tcpdump na interfejsie w trybie ZC?

Nie w sposób, do jakiego przywykłeś. Karta w trybie ZC jest wyjęta ze stosu jądra i obsługiwana z pełną prędkością przez jedną aplikację. Diagnostykę planuj przez narzędzia PF_RING albo przez osobny port podglądowy.

Czy PF_RING ZC wymaga osobnej licencji?

Tak — ZC jest licencjonowany per interfejs przez ntop, niezależnie od licencji WanGuard. Licencje trzeba wygenerować przed konfiguracją sterownika. Zakres i wycenę całości wdrożenia znajdziesz w cenniku.

Czy da się to wdrożyć bez przerwy w działaniu?

Nie w pełni. Zmiana sterownika przechwytywania wymaga jego przeładowania, a to zrywa łączność na wszystkich interfejsach obsługiwanych przez ten sam sterownik. Jeśli zarządzanie jest wyniesione na osobną kartę, przerwa dotyczy tylko przechwytywania i trwa krótko — jeśli nie, potrzebujesz konsoli offline.