Skanowanie portów - technika i stosowane metody

Ze względu na pewną dowolność pozostawioną przez twórców [8], nie wszystkie stosy TCP/IP są podatne na zaprezentowane metody skanowania portów.

Skanowanie otwarte (ang. connect() scan, open scan)

Skanowanie otwarte jest rzadko wykorzystywane ze względu na łatwość wykrycia i zablokowania takiego "ataku". Metoda ta polega na wykonaniu próby uzgadniania trójfazowego dla każdego spośród skanowanych portów TCP. Mechanizm uzgadniania trójfazowego jest dostępny w systemach zgodnych z UNIX nawet dla nieuprzywilejowanych użytkowników w postaci funkcji connect(), stanowiącej część interfejsu gniazdowego.
Procedura nawiązywania połączenia z portem nasłuchującym (będącym w stanie nasłuchu - LISTENING) wygląda następująco:

Zakończone sukcesem uzgadnianie trójfazowe powoduje powrót funkcji connect() z wartością 0, oznaczającą sukces.
Przebieg nieudanej próby nawiązania połączenia z portem zamkniętym (nie będącym w stanie LISTENING) wygląda następująco:

W takiej sytuacji funkcja connect() powraca z wartością -1, która sygnalizuje błąd.
Stacja skanująca zwykle natychmiast zamyka dopiero co otwarte połączenie (wywołując funkcje close()), ponieważ ilość otwartych deskryptorów jest limitowana, a wynegocjowane połączenie nie jest używane do dalszej wymiany danych.

Skanowanie półotwarte (ang. SYN scan, half-open scan)

Ten rodzaj skanowania także korzysta ze zdefiniowanego w [8] uzgadniania trójfazowego i dlatego jest równie łatwy do wykrycia i zablokowania co skanowanie otwarte, mimo że nie zachodzi w tym przypadku pełne uzgadnianie trójfazowe (brakuje wysłania ostatecznego potwierdzenia przez klienta).
Wymiana segmentów następuje według poniższego schematu:

Skanowanie niewłaściwym polem flag

Na oktet flag składa się 6 bitów (flag), licząc od zerowego odpowiadają one następującym flagom: FIN, SYN, RST, PSH, ACK, URG oraz 2 niewykorzystane bity (zgodnie z [8] powinny być one wyzerowane, podobnie jak 4 niewykorzystane bity oktetu przesunięcia). Taka ilość flag pozwala na skonstruowanie dużej ilości różnych segmentów o niewłaściwych flagach, dlatego też opisane zostaną jedynie wybrane, najczęściej spotykane ich kombinacje.
Opisane niżej metody łączy wiele wspólnych cech:

Skanowanie FIN (ang. FIN scan, stealth scan)

Segment z ustawioną flagą FIN normalnie służy do zamknięcia połączenia. Jeżeli taki segment, nie należący do połączenia, trafi na nasłuchujący port, to powinien on zostać zignorowany. Jeśli natomiast skanowany port nie był w stanie nasłuchu, odesłany powinien zostać segment z ustawioną flagą RST.

Skanowanie puste (ang. NULL scan)

W tej metodzie do skanowania pojedynczego portu używa się segmentu z wyzerowanymi wszystkimi flagami.

Skanowanie X (ang. XMAS scan)

Odpowiednik skanowania pustego, lecz w nagłówku TCP segmentu wysyłanego przez skanującego ustawiona jest nieużywana flaga o wartości 40hex (pole opcji z włączonym wyłącznie szóstym bitem), tzw. flaga X - stąd nazwa metody.

Skanowanie Y (ang. YMAS scan)

Metoda analogiczna do poprzedniej z tym wyjątkiem, że ustawiona jest nieużywana flaga o wartości 80hex (tj. włączony jest jedynie siódmy bit pola opcji), zwana flagą Y.

Skanowanie Z (ang. ZMAS scan)

Ten typ skanowania jest często określany mianem skanowania X, co prowadzi do nieporozumień. Dlatego autor [4] zdecydował się nazywać metodę, w której stacja skanująca wysyła segment z normalnie niespotykaną kombinacją flag FIN|PSH|URG skanowaniem Z, analogicznie do dwóch poprzednio omawianych metod.

Skanowanie ACK (ang. ACK scan)

Ten rodzaj skanowania polega na wysłaniu segmentu z ustawioną flagą ACK i nie umożliwia wykrycia portów nasłuchujących, a jedynie ustalenie faktu filtrowania danych przychodzących do skanowanego portu przez stanową zaporę sieciową. Gdy skanowana stacja zwraca w odpowiedzi segment RST, oznacza to, że skanowany port nie jest filtrowany przez stanową zaporę sieciową.

Skanowanie rozmiarem okna (ang. window size scan)

Jest to rodzaj skanowania podobny do skanowania ACK, jednak dzięki temu, że większość systemów modyfikuje pole rozmiaru okna (nie jest to zachowanie wyspecyfikowane w [8]) możliwe jest ustalenie nie tylko faktu filtrowania skanowanego portu, ale także stwierdzenia, czy jest on w stanie nasłuchu.

Skanowanie przekierowaniem odpowiedzi serwera FTP (ang. FTP bounce scan)

W specyfikacji protokołu FTP (zawartej w [9]) zdefiniowano możliwość trybu pracy serwera FTP, w którym wyniki przekazuje on innej stacji niż ta, która zainicjowała sesję. Aby skanować stację o adresie A.B.C.D należy wykonać poniższą procedurę:

Najważniejszą zaletą tej metody jest zapewnienie anonimowości skanującemu, ponieważ z perspektywy stacji skanowanej wydaje się, że to serwer FTP prowadzi skanowanie otwarte. Nie jest to jednak anonimowość pełna - w logach serwera FTP pozostają informacje, które mogą doprowadzić do wykrycia inicjatora skanowania portów.

Skanowanie bezczynne (ang. IP ID idle scan, dumb scan)

Najnowsza metoda skanowania, po raz pierwszy przedstawiona w [3]. Jej największą zaletą jest zapewnianie praktycznie zupełnej anonimowości skanującemu.
Metoda ta opiera swe działanie na fakcie, iż większość stosów TCP/IP zwiększa pole ID w nagłówku IP o stałą wartość (najczęściej 1); do działania wymagane jest użycie stacji pośredniczącej, której oprogramowanie TCP/IP zachowuje się właśnie w taki sposób. Aby skanowanie tego rodzaju było w ogóle możliwe, stacja pośrednicząca musi być w czasie skanowania pojedynczego portu bezczynna, tzn. nie może w tym czasie wysłać żadnego pakietu poza opisanymi w poniższym schemacie:

Od czasu opublikowania tej metody sukcesywnie nanoszone są poprawki do stosów TCP/IP w systemach operacyjnych, np. w systemie OpenBSD pole IP ID jest zwiększane standardowo o pseudolosową wartość, a dla Linuksa istnieją "łaty" zawierające wspomniany kod z OpenBSD oraz taką korektę obsługi protokołu ICMP, aby odpowiedzi ICMP (ang. ICMP Reply) zawierały kopie pól z żądań ICMP (ang. ICMP Request).
Istnieją również implementacje powodujące zablokowanie lub czasowe ograniczenie wysyłania segmentów RST, zawarte np. w systemie FreeBSD, lecz nie powinny być one używane ze względu na to, że łamią one zalecenia zawarte w [8].

Obrona przed skanowaniem portów

Jak wynika z wyżej opisanych własności poszczególnych metod skanowania portów, administratorowi sieci nie jest łatwo stwierdzić, czy ma on do czynienia ze skanowaniem portów, czy z innego rodzaju aktywnością (np. powtarzanymi próbami nawiązania połączenia z usługami nieobsługiwanymi przez daną stację).
Podejrzenia powinny budzić:

Wymienione zdarzenia należy uwzględnić w konfiguracji zapór sieciowych i zdefiniować odpowiednie reakcje lub zastosować gotowe pakiety IDS (Intrusion Detection System). Reakcją nie polecaną jest automatyczne "odcinanie" ruchu przychodzącego ze stacji, którą zidentyfikowano jako skanującą ze względu na możliwość sfałszowania adresu źródłowego (ang. spoofing).
Nieocenionym narzędziem do wykrywania ataków (także skanowania portów) i zapobiegania im jest odpowiednio skonfigurowana zapora sieciowa (ang. firewall).
Zapora sieciowa jest mechanizmem służącym do filtrowania transmisji drogą analizy adresów protokołowych (w przypadku, gdy jest to bezstanowa zapora sieciowa, ang. non-stateful firewall, screening router) lub dodatkowo informacji protokołowych (zapora stanowa, ang. stateful firewall). Zapory sieciowe działają w oparciu o tzw. zestawy reguł (ang. rulesets), które uwzględniają takie kryteria, jak adresy oraz inne informacje protokołowe (w tym aktualny stan połączeń TCP). W zależności od stopnia zaawansowania oprogramowania zapory sieciowejmożliwe jest zastosowanie różnych akcji.
Do najczęściej spotykanych należą:

Sporym problemem może być wysyłanie sfragmentowanych datagramów IP przez stację skanującą. Nie każda zapora sieciowa działa w ten sposób, że przed zbadaniem datagramu próbuje go zdefragmentować (ograniczeniem jest w tym przypadku głównie pojemność pamięci oraz moc przetwarzania). W ten sposób można "przemycić" do sieci m. in. wykorzystywane w skanowaniu portów nietypowe segmenty TCP.
Warto także zabezpieczyć się przed pośredniczeniem w skanowaniu portów, odpowiednio konfigurując serwery FTP (uniemożliwiając FTP bounce scan) oraz nałożyć "łaty" wprowadzające losowe zmiany licznika IP ID.
Dobra polityka bezpieczeństwa powinna uwzględniać tego rodzaju próby naruszenia bezpieczeństwa (niektórzy skłaniają się ku zdaniu, że skanowanie portów jest już formą ataku). Jednocześnie nie zaleca się eskalacji działań odwetowych, a jedynie poprzestanie na zapisaniu informacji do logów systemowych i, w szczególnie uciążliwych przypadkach, odcięciu transmisji od intruza oraz powiadomieniu odpowiedniego operatora sieciowego.

Technika ukrywania źródła skanowania portów

Często stosowanie technik "anonimowych" (IP ID idle scan, FTP bounce scan) nie jest pożądane lub możliwe. Wówczas skanujący mają do wyboru wyłącznie metody ujawniające ich adres IP. Ponieważ podanie prawdziwego adresu źródłowego jest wymagane gdy oczekuje się odpowiedzi od stacji docelowej, w grę wchodzi jedynie wysłanie dużej ilości pakietów, które różnią się wyłącznie adresem źródłowym. Wśród nich jest jeden pakiet z adresem źródłowym stacji atakującego, a pozostałe stacje służą jako tzw. przynęty (ang. decoys). Właśnie z tego powodu - wszak "przynętą" może być dowolnie wybrany adres - nie poleca się przeprowadzania odwetu ani "odcinania" ruchu.
Niestety, jak już wspomniano, wykrycie skanowania portów jest możliwe jedynie poprzez zliczanie ilości nieprawidłowych lub niezakończonych połączeń przychodzących w jednostce czasu. Jeżeli skanowanie poszczególnych portów jest dokonywane w na tyle dużych odstępach czasowych, aby nie uaktywnić IDS (w celu skrócenia całkowitego czasu skanowanie portów można prowadzić z różnych stacji - w sposób rozproszony), jest ono praktycznie niemożliwe do wykrycia.

Literatura

[1] W. Richard Stevens: UNIX. Programowanie usług sieciowych. T.1, Wydawnictwa Naukowo-Techniczne, Warszawa 2000
[2] Computer Emergency Response Team: TCP SYN Flooding and IP Spoofing Attacks. Advisory CA-96.21, Computer Emergency Response Team, Pittsburgh 1996
[3] Salvatore "Antirez" Sanfilippo: dumbscan.txt, http://www.kyuzz.org/antirez/papers/dumbscan.html
[4] Marcin Dawcewicz: Techniki skanowania sieci komputerowych, Software 2.0 nr 9/2001
[5] Internet Assigned Numbers Authority: Assigned Port Numbers, ftp://ftp.ftp.isi.edu/in-notes/iana/assignments/port-numbers
[6] J. B. Postel (red): Internet Protocol. RFC 791, 1981
[7] J. B. Postel: Internet Control Message Protocol. RFC 792, 1981
[8] J. B. Postel (red): Transmission Control Protocol. RFC 793, 1981
[9] J. B. Postel, J. K. Reynolds: File Transfer Protocol. RFC 959, 1985
[10] J. K. Reynolds, J. B. Postel: Assigned Numbers. RFC 1700, 1994