Skanowanie portów TCP

Skanowanie portów TCP Autor: Vatazhka 20.09.2007. Zmieniony 20.09.2007. Skanowanie portów (ang. port scanning) jest jednym z kroków poprzedzających włamanie do systemu informatycznego. Dostarcza ono informacji o liczbie i pośrednio o rodzaju usług uruchomionych na skanowanej stacji. Celem niniejszego opracowania jest zademonstrowanie działania wszystkich obecnie znanych metod skanowania portów TCP. Ze względu na dotychczas niewielkie rozpowszechnienie nowych protokołów z rodziny IPv6 problem zostanie ograniczony do dziedziny IPv4. Rodzina protokołów powiązanych z IPv4 jest obecnie dominującym rozwiązaniem na rynku - pracuje w niej nie tylko Internet, ale i spora część intra- i ekstranetów. Większość protokołów wyższego rzędu, wykorzystywanych przez aplikacje, używaw charakterze protokołu transportowego protokołu TCP. Protokół IP Protokół IP jest w użyciu od wczesnych lat 80. Jest on protokołem warstwy sieciowej w rozumieniu siedmiowarstwowego modelu ISO/OSI - zapewnia przekazywanie datagramów od stacji źródłowej do stacji docelowej poprzez sieć rozległą (największą siecią rozległą, w której wykorzystywany jest protokół IP, jest Internet). Ze względu na ograniczenia wynikające ze stosowania różnych technologii w warstwie kanałowej, datagram IP może zostać podzielony na mniejsze - jest to tzw. fragmentacja. Ustawienie bitu zakazu fragmentacji (DF, Don't Fragment) powoduje odrzucanie przez bramę datagramów o za dużym rozmiarze (MTU, Maximum Transmission Unit) w stosunku do określonego dla danej sieci. Protokół TCP Połączeniowy protokół TCP działa "nad" protokołem IP. Wykorzystuje on w pełni dwukierunkowe połączenia, zapewnia niezawodność (stosowane są obustronne potwierdzenia), sterowanie przepływem danych (określana jest ilość danych, która może jeszcze zmieścić się w buforach) oraz zachowanie kolejności danych (co wymaga numeracji segmentów - jednostek danych przekazywanych przez warstwę TCP do warstwy IP). Oprogramowanie TCP ustanawia połączenie stosując uzgadnianie trójfazowe (ang. three-way handshake), kończy je zaś wymiana czterech komunikatów. Połączenie TCP może znajdować się w danej chwili w jednym z 11 zdefiniowanych w [8] (wraz z warunkami przejść) stanów. W każdej chwili wiele procesów w jednej stacji może korzystać z protokołu TCP. W celu rozróżnienia tych procesów używa się szesnastobitowych numerów portów. Istnieje klasa tzw. portów ogólnie znanych (ang. well-known ports) - przeznaczonych do wykonywania ogólnie znanych usług, która jest zdefiniowana w [10], a najnowszą wersję przypisań można znaleźć w [5]. Pewne serwery usług zawierają błędy, które mogą posłużyć do ataku, którego skutkiem będzie odmowa wykonania usługi (ang. denial of service) lub nawet przejęcie kontroli nad serwerem. Skanowanie portów służy do określenia potencjalnych usług, na które może być przeprowadzony atak (dane zebrane w ten sposób wymagają dodatkowej weryfikacji). Ustanawianie połączenia TCP - uzgadnianie trójfazowe Ustanawianie połączenia TCP przebiega według poniższego scenariusza: - serwer wykonuje tzw. otwarcie bierne (ang. passive open) połączenia, wywołując funkcje interfejsu gniazdowego socket(), bind(), listen(), - klient wykonuje tzw. otwarcie aktywne (ang. active open), wywołując funkcję interfejsu gniazdowego connect() - powoduje to wysłanie segmentu SYN (synchronizacji, ang. synchronize), zawierającego początkowy numer kolejnych danych, które klient zamierza wysyłać przez to połączenie (w pewnych sytuacjach także dane) oraz ewentualne opcje TCP, - serwer potwierdza przyjęcie segmentu SYN klienta i wysyła własny segment SYN, zawierający początkowy numer danych, które serwer będzie wysyłał przez to połączenie, wraz z segmentem ACK (potwierdzenia, ang. acknowledgement), zawierającym początkowy numer kolejnych danych klienta zwiększony o 1 - taki segment autor będzie określał jako SYN ACK, - klient sygnalizuje przyjęcie odpowiedzi serwera segmentem ACK, zawierającym początkowy numer kolejnych danych serwera zwiększony o 1. Wymiana danych w połączeniu TCP

Jest to zasadnicza część transmisji, mogąca przebiegać według wielu scenariuszy; najczęściej obejmuje ona następującą wymianę segmentów: - klient wysyła żądanie do serwera, - serwer wysyła potwierdzenie przyjęcia żądania w postaci segmentu ACK, który może być wysłany razem z odpowiedzią, - klient potwierdza otrzymanie odpowiedzi segmentem ACK. Kończenie połączenia TCP Schemat zamykania połączenia TCP obejmuje zwykle wymianę czterech segmentów i wygląda następująco: - jeden z programów - klient lub serwer - wykonuje tzw. zamknięcie aktywne (ang. active close), wywołując funkcję close(), co powoduje wysłanie segmentu FIN (zakończenia, ang. finish); w pewnych sytuacjach segment ten może być wysłany razem z danymi, - drugi z programów potwierdza przyjęcie segmentu FIN własnym segmentem ACK, zwiększając numer segmentu FIN o 1 (segmenty FIN są numerowane podobnie jak segmenty SYN), wykonując tzw. zamknięcie bierne (ang. passive close), - w tym momencie tym połączeniem mogą jeszcze przepływać dane od stacji wykonującej zamknięcie bierne do stacji wykonującej zamknięcie aktywne, jest to tzw. półzamknięcie (ang. half-close), - stacja wykonująca zamknięcie bierne wykonując funkcję close() wysyła numerowany segment FIN do stacji wykonującej zamknięcie aktywne, - stacja wykonująca zamknięcie aktywne potwierdza przyjęcie segmentu FIN wysyłając stacji wykonującej zamknięcie bierne segment ACK z numerem segmentu FIN zwiększonym o 1. 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: - klient wysyła na skanowany port serwera segment SYN, - serwer odpowiada segmentem SYN ACK, - klient potwierdza odpowiedź serwera wysyłając segment ACK. 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: - klient wysyła na skanowany port serwera segment SYN, - serwer odpowiada segmentem RST, - klient potwierdza odpowiedź serwera wysyłając segment RST. 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: - klient wysyła na skanowany port serwera segment SYN,

- serwer odpowiada segmentem SYN ACK jeżeli żądany port przeciwnym wypadku. jest w stanie nasłuchu lub RST w 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: - zgodnie z [8] skanowana stacja powinna odpowiedzieć segmentem RST jeżeli docelowy port nie jest w stanie nasłuchu lub zignorować go w przeciwnym wypadku, - używane we wszystkich metodach segmenty nie pojawiają się bez uprzedniego nawiązania połączenia, a więc pojawienie się takiego segmentu jest sytuacją wyjątkową i może być wykryte przez stanową zaporę sieciową, analizującą przebieg połączenia i odrzucającą niepoprawne segmenty, - powyższe cechy oznaczają, że skanowanie tymi metodami jest wolne (segment należy uznać za zignorowany po przekroczeniu pewnego, zwykle dość długiego czasu oczekiwania) oraz często zawodne (urządzenia aktywne na trasie przejścia segmentu mogą go odrzucić bez poinformowania o tym nadawcy), - twórcy części systemów (m. in. IRIX, HP/UX, IOS, Windows) nie zastosowali się do specyfikacji zawartych w [8] i nadejście tak spreparowanego segmentu zawsze powoduje odpowiedź RST, niezależnie od stanu portu docelowego. 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ę: - skanujący loguje się na serwer FTP obsługujący przekierowanie odpowiedzi, - podczas sesji FTP skanujący wykonuje komendę PORT A,B,C,D,X,Y, gdzie X _ 256 + Y określa numer skanowanego portu, - jeżeli serwer FTP umożliwia przekierowanie, odpowie komunikatem o kodzie 200, jeżeli nie - komunikatem o kodzie 500, - skanujący wydaje dowolną komendę (np. LIST) inicjującą transmisję danych pod wskazany komendą PORT A,B,C,D,X,Y adres, - jeżeli skanowany port nie był w stanie nasłuchu, serwer zwróci komunikat o kodzie 426, w przeciwnym wypadku - komunikaty o kodach 150 i 226. 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: - stacja skanująca pobiera wartość IP ID stacji pośredniczącej wysyłając bezpośrednio do niej dowolny pakiet IP, najczęściej wykorzystując żądania echa ICMP (ang. ICMP Echo Request), na które stacja pośrednicząca powinna odpowiadać odpowiedziami echa ICMP (ang. ICMP Echo Reply) - w ten sposób, kilkakrotnie powtarzając procedurę, skanujący może obliczyć przyrost wartości IP ID stacji pośredniczącej, - stacja skanująca wysyła do stacji skanowanej segment TCP z ustawioną flagą SYN o sfałszowanym adresie źródłowym, wskazującym na stację pośredniczącą, - stacja skanowana odpowiada segmentem SYN ACK jeżeli port docelowy był w stanie nasłuchu lub RST w przeciwnym wypadku (odpowiedź jest oczywiście "odsyłana" stacji pośredniczącej), - jeżeli do stacji pośredniczącej dotarł segment SYN ACK, odpowiada ona stacji skanowanej segmentem RST, co powoduje zwiększenie licznika IP ID; w przeciwnym wypadku (tj. jeżeli stacja pośrednicząca otrzymała segment RST) ignoruje go, co nie powoduje zwiększenia licznika IP ID, - stacja skanująca ponownie pobiera aktualną wartość licznika IP ID stacji pośredniczącej i tej postawie oblicza, czy skanowany port był w stanie nasłuchu czy nie. 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ć: - wielokrotne próby nawiązania połączenia na różnych portach TCP w krótkim okresie czasu, - duża ilość wychodzących z sieci segmentów RST, pochodzących z jednej stacji, - pojawiające się przychodzące segmenty TCP o adresach docelowych obejmujących stacje z tej sieci o ustawionych flagach innych niż SYN, których numer sekwencyjny nie wskazuje na przynależność tego segmentu do żadnego z nawiązanych połączeń). 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żą: - przekazanie pakietu odbiorcy w niezmienionej postaci ("akceptuj", ang. accept), - zwrócenie pakietu nadawcy w niezmienionej postaci ("odbij", ang. mirror), odrzuceniu pakietu z odesłaniem informacji o tym nadawcy ("odrzuć", ang. reject), - skasowanie bez śladu ("usuń", ang. drop), zapisanie informacji o pakiecie do logu systemowego "loguj", ang. log oraz przekazanie pakietu do innej stacji ("przekaż", ang. jump). 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/innotes/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