Konieczność zebrania kopii ruchu transferowanego przez naszą sieć nie jest ani niczym nowym, ani wyjątkowym. Potrzebna jest do analizy problemów, jak i poprawnego działania systemów bezpieczeństwa.

Zastanawialiście się kiedyś, w jakim celu możemy potrzebować wykonać kopię pakietów, które są przetwarzane przez urządzenie lub do tego urządzenia skierowane? Ten cel może być zarówno dobry, jak i zły. W tym pierwszym przypadku kopia pakietów potrzebna będzie nam na przykład do analizy problemu występującego wewnątrz naszej infrastruktury. Wielu nieoczywistych problemów, których nie widać w samych logach urządzenia lub aplikacji, nie rozwiążemy bez dokładnej analizy pakietów czy ramek, które są przesyłane przez naszą sieć. To właśnie tym, co dzieje się na poziomie warstwy sieciowej lub warstwy łącza danych modelu ISO OSI i w charakterystycznych aspektach protokołów transmisyjnych, które wykorzystujemy w sieci, będziemy poszukiwać anomalii i źródeł naszych problemów.

Wiele systemów monitoringu, szczególnie tych przeznaczonych do analityki pod kątem bezpieczeństwa (na przykład systemy IDS), analizuje przesyłane do nich pakiety, często wstępnie wyselekcjonowane. Dzięki temu mogą one dokonać analizy bez negatywnego wpływu na czas transmisji. Firma, w której pracujemy, może być także prawnie zobligowana do monitorowania połączeń sieciowych, co wynika między innymi z zapisów ustawy o Krajowym Systemie Cyberbezpieczeństwa.

Wiele osób zbiera próbki ruchu także w celach edukacyjnych, aby rozwijać swoją wiedzę w zakresie technologii teleinformatycznych i protokołów, z którymi pracują na co dzień. W sytuacji gdy takie działanie jest realizowane za zgodą przełożonych i działu bezpieczeństwa oraz z zachowaniem zasad poufności danych, nie ma w tym nic złego. Jeżeli jednak są one łamane, przechodzimy na ciemną stronę mocy, po której znajdują się osoby, które mogą być zainteresowane pozyskaniem kopii przesyłanych w naszej sieci danych, aby wydobyć z nich cenne dla siebie informacje (niekoniecznie te dostępne publicznie). Takie działanie jest oczywiście bezprawne. Przyjrzyjmy się zatem, w jaki sposób na różnych urządzeniach konfigurujemy dostępne funkcje, aby uzyskać potrzebną nam do pracy czy nauki kopię przesyłanego przez sieć ruchu.

> Źródło i rodzaj zbieranego ruchu

Zanim skupimy się na mechanizmach, które dostępne są dla różnego typu urządzeń wybranych producentów, musimy dobrze rozumieć, jaki typ ruchu chcemy pozyskać. W inny sposób będziemy zbierać informacje o pakietach, które są przekazywane przez urządzenie, a w inny o tych, które są do niego kierowane. Przekazywaniem pakietów zajmuje się warstwa danych (ang. data plane) urządzenia. W tym drugim przypadku mamy na myśli pakiety przetwarzane przez warstwę kontrolną (ang. control plane) oraz zarządzającą (ang. management plane). Różnica polega na tym, że każda z tych trzech warstw przetwarzana jest przez inne komponenty urządzenia. Ma to szczególne znaczenie w przypadku zaawansowanych urządzeń o modularnej budowie, aczkolwiek małe jednostki także wyposażone są w układy przeznaczone do realizacji poszczególnych funkcji. Dlatego sposób zbierania danych będzie mocno uzależniony od samego urządzenia, jak i tego, z której warstwy będziemy zbierać ruch. Routery czy przełączniki nie mają magicznego układu pozwalającego utworzyć kopię ruchu sieciowego na interfejsie. Jest to możliwe dopiero na poziomie dedykowanego układu przetwarzającego pakiety.

> tcpdump

Tcpdump kojarzy nam się z serwerami i stacjami roboczymi. To powszechnie wykorzystywane narzędzie to tekstowa wersja Wiresharka, którą uruchamiamy z wiersza poleceń konsoli systemu operacyjnego z rodziny Unix i BSD (choć istnieje też wersja dla Windowsa). Służy ono do analizy pakietów sieciowych. Samym zbieraniem pakietów nie zajmuje się jednak wprost sam tcpdump czy Wireshark, ale biblioteka libpcap (w nowszych wersjach Wiresharka biblioteka npcap). Zapewnia ona niezależny od systemu operacyjnego interfejs do przechwytywania pakietów, który może być wywołany z poziomu użytkownika. Interfejs libpcap obsługuje mechanizm filtrowania oparty na architekturze filtru pakietów BSD. Dlatego w Wiresharku inną składnię mają filtry, których używamy, aby zawęzić kryteria zapisywania przechwyconych pakietów, a inną w przypadku posługiwania się filtrami przeszukiwania w samym programie.

Tcpdump znajdziemy na większości systemów z rodziny Unix czy BSD, a także na wybranych urządzeniach sieciowych, np. Junipera. Junos OS (zwany potocznie JunOS) zbudowano, opierając się na systemie operacyjnym FreeBSD. Administrator ma zapewniony dostęp do konsoli systemu, a co za tym idzie również do podstawowych narzędzi wchodzących w jego skład, w tym także do tcpdump. W przeciwieństwie jednak do tradycyjnych systemów operacyjnych, uruchamiając tcpdump z linii poleceń, nie będziemy w stanie zarejestrować wszystkich pakietów transferowanych przez wskazany fizyczny lub logiczny interfejs routera lub przełącznika. Ponieważ działa on w warstwie control plane, pozwoli nam na zarejestrowanie jedynie pakietów, których odbiorcą jest wskazane urządzenie, nie zaś ruch tranzytowy. Bardzo często musimy jednak zdiagnozować, czy komunikaty wskazanego protokołu są poprawnie odbierane przez nasz router, i w takim scenariuszu tcpdump idealnie się sprawdzi. Zebrane pakiety możemy wyświetlić bezpośrednio na konsoli urządzenia lub zapisać do pliku, który następnie pobierzemy, wykorzystując do tego scp. Zapisując dane w pliku bezpośrednio na urządzeniu, pamiętajmy, że starsze modele zazwyczaj są wyposażone w niewielką pamięć wewnętrzną. Kluczowe zatem jest odpowiednie stosowanie filtrów, aby rejestrować tylko interesujące nas pakiety.

Aby uruchomić rejestrowanie pakietów, musimy zalogować się na urządzeniu, a następnie poleceniem start shell user root przejść do konsoli systemu operacyjnego, do konta z uprawnieniami superużytkownika, czyli roota. Wywołamy wtedy tcpdump bezpośrednio z wiersza poleceń.

> SPAN

SPAN to najprostsza metoda kopiowania ruchu pomiędzy interfejsami. Założenie tej metody jest bardzo proste – wskazujemy port, z którego chcemy tworzyć kopię ruchu oraz port na tym samym urządzeniu, na który kopia ruchu ma być wysyłana. Jest to zatem metoda pozwalająca na tworzenie kopii ruchu jedynie w obrębie danego urządzenia. Jednocześnie to najprostsza z dostępnych metod, która często nazywana jest jako Local SPAN. Na przełącznikach Cisco konfiguracja jest bardzo prosta:

Switch1(config)#monitor session 1 source interface GigabitEthernet0/1
Switch1(config)#monitor session 1 destination interface GigabitEthernet0/15

Możemy utworzyć kilka sesji SPAN, nadając im identyfikatory numeryczne. Każdej sesji wskazujemy interfejs źródłowy, z którego mają być zbierane ramki, oraz interfejs docelowy do którego kopia ramek ma być wysyłana. Co ważne interfejsem źródłowym może być zarówno interfejs fizyczny, jak i logiczny, na przykład interfejs SVI. Domyślnie zbierany będzie zarówno ruch wychodzący z danego interfejsu, jak i do niego przychodzący. W konfiguracji możemy jednak ograniczyć się jedynie do ruchu przychodzącego lub wychodzącego, dodając odpowiednio parametr rx lub tx. Aktywnie działające na urządzeniu sesje SPAN wyświetlimy poleceniem show monitor, zaś ustawienia konkretnej sesji poleceniem show monitor session.

Analogiczna funkcja na urządzeniach z logo Junipera ma nazwę port mirroring. Sposób konfiguracji, jak i szczegółowe parametry, które możemy wprowadzić, zależą od wersji systemu operacyjnego JunOS, który został zainstalowany na urządzeniu, oraz od modelu samego urządzenia. Przykładowo na przełącznikach serii EX konfiguracja wygląda następująco:

set ethernet-switching-options analyzer moj-span input ingress interface ge-0/0/0.0
set ethernet-switching-options analyzer moj-span output interface ge-0/0/10.0

Porty, z których zbieramy dane, muszą być ustawione jako porty warstwy drugiej (family ethernet-switching) lub trzeciej (family inet lub family inet6), zaś port docelowy jako warstwy drugiej. JunOS pozwala nam jednak na bardziej szczegółowe określenie tego, jakie pakiety chcemy kopiować za pomocą filtrów.

[...]

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Jest twórcą modułów do Docker Swarm w Ansible i jednym z opiekunów modułów w community.docker. Pracuje jako niezależny konsultant IT. Posiada certyfikat CCIE.