Przechwytywanie sesji TCP

SYSADMIN

Zrozumienie i zapobieganie atakom na protokół TCP

ZAPOBIEGANIE PRZECHWYTYWANIU SESJI Przechwycić sesję TCP za pomocą ataku RST jest dość prosto i to ryzyko wzrasta wraz ze zwiększaniem się liczby zastosowań wymagających długotrwałego utrzymywania sesji, jak VPN, transfery stref DNS czy BGP. W tym artykule opiszemy sposób przeprowadzania ataku tego typu oraz przedstawimy kilka technik zabezpieczania sieci. CHRISTOPH WEGENER I WILHELM DOLLE

O

d roku 1985 eksperci wiedzą doskonale, że TCP (Transmission Control Protocol) nie jest bezpiecznym protokołem. Napastnicy mogą przerwać połączenie, sfałszować dane, czy nawet przechwycić istniejące połączenie TCP, znając jedynie kilka podstawowych informacji na jego temat: źródłowy adres IP, adres docelowy i poprawny numer sekwencyjny. Jeśli napastnik ma możliwość podsłuchania połączenia jego bitwa jest wygrana zanim jeszcze się zacznie. Jeśli napastnik nie ma możliwości podsłuchania, ponieważ nie ma kontroli nad żadną maszyną na drodze pakietu od nadawcy do odbiorcy, trudność ata-

ku nieco wzrasta. Jednak ludzie mają ogólną skłonność do przeceniania poziomu komplikacji procesu przechwytywania połączeń, a sztuczki ze zmianą wielkości okna TCP jeszcze bardziej upraszczają to zadanie. Jedno z najtrudniejszych zadań dla napastnika polega na odgadnięciu właściwego numeru sekwencyjnego. To jedyny sposób, aby przekonać maszynę docelową, że przesłany datagram TCP jest wysłany przez właściwego nadawcę. Jeśli napastnik zdobędzie właściwe wartości, nic nie jest w stanie powstrzymać go przed wykorzystaniem istniejącego połączenia do wysyłki własnych da-

nych i zdobyciem w ten sposób nieautoryzowanego dostępu do informacji lub przerwania połączenia za pomocą pakietu z ustawionym znacznikiem reset (RST). Często bywa tak, że przerwanie połączenia to nie tragiczny problem, szczególnie wtedy, gdy użytkownik po prostu surfuje w sieci. W innych sytuacjach problem może być jednak większy: systematyczne przerywanie połączeń BGP (Border Gateway Protocol) pomiędzy dwoma ruterami brzegowymi w Internecie może mieć poważne konsekwencje. Ataki DoS mogą być też poważnym problemem nawet dla mniejszych sieci firmo-

Rysunek 1: Każdy segment TCP rozpoczyna się od takiego nagłówka, po którym następuje segment danych. W połączeniu z adresami IP numery portów identyfikują połączenie w sposób unikalny, natomiast numer sekwencyjny identyfikuje miejsce pakietu w strumieniu danych.

WWW.LINUX-MAGAZINE.PL

NUMER 20 PAŹDZIERNIK 2005

63

SYSADMIN

Przechwytywanie sesji TCP

Historia 1981: Powstaje specyfikacja Transmission Control Protocol (TCP) w postaci dokumentu (RFC) 793 [2]. 1985: Bob Morris ujawnia słabe strony protokołu TCP [15]. 1994: Pierwsza publikacja na temat podatności TCP na ataki pojawia się wraz z zastosowaniem przez Kevina Mittnicka tzw. ataku bożonarodzeniowego (Christmas Day Attack), który jest skierowany przeciwko ekspertowi od zabezpieczeń Tsutumo Shimomurze [19]. 1995: Paul Watson wysyła do sieci Usenet informację na temat podatności protokołu TCP na ataki. Informacja ta spotyka się z zasłużoną uwagą. Odbywa się kilka niezależnych dochodzeń, dotyczących przede wszystkim jakości generatorów numerów sekwencyjnych. 1995: Laurent Joncheray przedstawia swój dokument „Simple Active Attack Against TCP” (prosty aktywny atak na TCP) na konferencji Usenix [15]. 2001: CERT opisuje podatność różnych generatorów numerów sekwencyjnych TCP/ IP i zwraca uwagę na problem zmiany wielkości okna [16]. 2003: Paul Watson demonstruje prostotę przeprowadzenia ataku nawet za pomocą zwykłego połączenia DSL. 2004: Organizacja IETF (Internet Engineering Task Force) publikuje pierwotną wersję swojej propozycji usprawnienia protokołu TCP zatytułowaną „Improving TCP's Robustness to Blind In-Window Attacks” (poprawa odporności protokołu TCP na ślepe ataki wykorzystujące zmianę wielkości okna) [10].

wych. Weźmy pod uwagę złośliwych włamywaczy na długi czas blokujących dostęp do sklepu WWW. Koszty związane z taką przerwą mogą być dość znaczne [1].

Szczegóły techniczne Aby w pełni zrozumieć istotę podatności protokołu TCP, musimy poznać nieco szczegółów technicznych. Protokół został zdefiniowany w dokumencie RFC 793 [2] opublikowanym w roku 1981. Każdy segment TCP rozpoczyna się nagłówkiem, który zawiera numer portu źródłowego i docelowego (16bitowe wartości z przedziału od 0 do 65535) oraz inne ważne parametry połączenia, jak numer sekwencyjny i numer potwierdzenia, obydwa o rozmiarze 32 bitów. Do tego dochodzi spora liczba znaczników połączenia (SYN, ACK, PSH, URG, RST i FIN) oraz

64

NUMER 20 PAŹDZIERNIK 2005

rozmiar okna odbiorczego. Ten ostatni parametr jest kluczowy do przeprowadzenia ataku, który chcemy opisać (Rysunek 1). Ustanowione połączenie jest identyfikowane w sposób unikalny przez czwórkę parametrów: źródłowy adres IP, port źródłowy, docelowy adres IP, port docelowy. Numer sekwencyjny wskazuje co do bajta pozycję segmentu w strumieniu danych połączenia. Każdy, kto wejdzie w posiadanie czwórki identyfikującej połączenie oraz numeru sekwencyjnego posiada już wszystkie informacje niezbędne do zablokowania połączenia. Niezależnie od tego, w którym miejscu sieci znajduje się napastnik, może spreparować odpowiedni pakiet i wysłać go do odbiorcy.

Liczby losowe Numer sekwencyjny może mieć jedną z 232 możliwych wartości. Prawdopodobieństwo odgadnięcia właściwego numeru, wykorzystania go do spreparowania pakietu i wstawienia takiego pakietu do strumienia wydaje się być bardzo nikłe. Jednak prawdopodobieństwo może zmienić się na korzyść napastnika, jeśli nadawca i odbiorca pakietu nie stosują losowego numeru inicjującego połączenie (initial sequence numbers, ISN) w procedurze trzykrotnego potwierdzenia (3 way handshake). W trakcie połączenia z każdym przesyłanym bajtem numer sekwencyjny jest zwiększany o jeden. Numer portu docelowego jest najczęściej zdeterminowany przez aplikację i usługę na nim nasłuchującą, lecz port źródłowy może mieć praktycznie dowolną wartość pomiędzy 0 a 65535. Co prawda pierwsze 1024 porty są w systemach Unix zastrzeżone na potrzeby systemowe, lecz ten fakt nie ma większego znaczenia w tym wyliczeniu. Przez długi czas ludzie wierzyli, że napastnik musi wypróbować 232 numerów sekwencyjnych oraz 216 portów, aby zdalnie zaatakować połączenie TCP bez konieczności podsłuchiwania połączenia. Niestety, większość systemów operacyjnych nie dobiera portu w sposób przypadkowy, lecz wrócimy do tego później. Największy problem z TCP ma związek z mechanizmem okna. Pakiety mogą docierać do odbiorcy w innej kolejności niż były wysyłane. Okno odbiorcze pozwala poskładać indywidualne segmenty w jedną całość zgodnie z ich kolejnością, po czym do nadawcy pakietów jest wysyłane potwierdzenie poprawnego otrzymania grupy segmentów. Słowniczek dokumentu RFC 793 w następujący sposób wyjaśnia działanie mechanizmu okna: „Reprezentuje kolejność nume-

WWW.LINUX-MAGAZINE.PL

rów sekwencyjnych, w jakiej chce je otrzymywać lokalny (odbiorczy) mechanizm TCP. Lokalny stos TCP uznaje, że zakres od RCV.NXT do RCV.NXT + RCV.WND – 1 stanowi wystarczający obszar niezbędny do kontroli pakietów. Segmenty zawierające numery sekwencyjne poza tym zakresem są uznawane za duplikaty i odrzucane”.

Zamykanie okna Jeśli numer sekwencyjny pakietu mieści się w oknie odbiorczym, stos TCP zaakceptuje pakiet i przetworzy go jako poprawny. To w znacznym stopniu zmniejsza ilość prób zgadywania numeru sekwencyjnego, ponieważ liczba ta spada z 232 do 232/rozmiar okna. W zależności od systemu operacyjnego rozmiar okna może wynosić od 65535 bajtów (Windows XP Professional z SP2) do 5840 bajtów (jądro Linuksa 2.4 i 2.6). Tabela 1 zawiera więcej standardowych wartości dla innych systemów. Rozmiar okna jest różny również w zależności od zastosowania. Na przykład Cisco Telnet stosuje okno o rozmiarze 4192 bajtów, a rozmiar okna w Cisco BGP wynosi 16384 bajtów. Niezależnie jak na to spojrzeć, rozmiar okna zmniejsza liczbę numerów sekwencyjnych, jakie napastnik musi wziąć pod uwagę. Biorąc za przykład system Windows XP, liczba takich pakietów spada do około 65000. Innymi słowy, napastnik musi wysłać 65000 pakietów RST, aby zakończyć aktywne połączenie. To zatrważająco mała liczba. Dobry system detekcji włamań (intrusion detection system, IDS) wykryje bez trudu taką nienormalną liczbę jednocześnie przesyłanych pakietów RST, lecz w sieci o dużym natężeniu ruchu zalew taką liczba pakietów RST może przejść niezauważony.

Wysoka skalowalność Sprawa się pogarsza, gdy strony komunikacji obsługują mechanizm skalowania okna. To rozszerzenie protokołu TCP (RFC 1323, [3])

Tabela 1: Początkowy rozmiar okna System operacyjny

Rozmiar okna

Linux Kernel 2.4

5840 Bajtów

Linux Kernel 2.6

5840 Bajtów

OpenBSD 3.6

16384 Bajty

Windows 2000 SP1, SP2

17520 Bajtów

Windows 2000 SP3, SP4

65535 Bajtów

Windows 2000 MS05-019

17520 Bajtów

Windows XP Professional, SP2

65535 Bajtów

Przechwytywanie sesji TCP

SYSADMIN

pulatni napastnicy nie będą mieli żadnego problemu z uzyskaniem informacji o systemie operacyjnym ofiary (za pomocą techniki tzw. odcisku palca, ang. fingerprinting). Biorąc pod uwagę te fakty, odgadnięcie numeru portu źródłowego nie jest żadną przeszkodą.

Techniki ataku Rysunek 2a: Polecenie netstat -nt wypisujące połączenia TCP dla systemu lokalnego. Numeracja portów źródłowych opiera się na prostym schemacie. Jądro po prostu zwiększa numer portu o jeden dla każdego nowego połączenia.

Rysunek 2b: OpenBSD utrudnia nieco życie napastnikom. Jednym ze sposobów jest w pełni losowe przydzielanie portu źródłowego dla każdego połączenia, co powoduje, że napastnik musi odgadnąć numer portu, zamiast po prostu go wyliczyć.

zwiększa szanse znalezienia pasującego numeru sekwencyjnego w bardzo krótkim czasie. Skalowanie okna jest zaprojektowane na potrzeby połączeń wymagających większych niż standardowy rozmiarów okna z powodu dużej przepustowości lub opóźnień. Dzięki temu transmisje mogą odbywać się bez zakłóceń i bez oczekiwania na częste potwierdzenia. Technika ta pozwala zwiększyć rozmiar okna (przeskalować) o liczbę zapisywaną na 14 bitach (Microsoft Windows). Daje to mnożnik rzędu 16384. Okno odbiorcze jest ograniczone do 65535 bajtów tylko w przypadku, gdy żadna ze stron nie obsługuje mechanizmu skalowania okna. Napastnikowi pozostała do pokonania już tylko jedna przeszkoda: czwórka adresów i portów nadawcy i odbiorcy. Adresy IP nie są problemem – napastnik wie wszak, kogo wziął sobie na cel, podobnie port docelowy jest bardzo łatwy do odgadnięcia. Nieco trudniej jest odgadnąć port źródłowy, który może mieć teoretycznie wartość od 0 do 65535. W praktycznych zastosowaniach zakres jest mniejszy, ponieważ pierwsze 1024 numery portów są z reguły zarezerwowane na specjalne potrzeby systemowe. System Linux (z jądrami 2.4 i 2.6) i co najmniej 128 MB RAM wykorzystuje porty źródłowe o numerach od 32768 do 61000 (jeśli system ma poniżej 128 MB RAM zakres jest węższy). Porty o numerach powyżej 61000 są z reguły wykorzystywane przez jądro na potrzeby mechanizmu maskarady IP. Rzeczywiste wartości można sprawdzić w pseudopliku

/proc/sys/net/ipv4/ip_local_range, można je też zmienić za pomocą polecenia sysctl, na przykład sysctl -w net.ipv4.ip_local_range=„32768 61000”.

Nie trzeba zgadywać Ku zachwytowi napastników pozostałe 28232 nie są przydzielane w sposób losowy, jądro stosuje tu pewien schemat. To jedna z najważniejszych rewelacji dokumentu Paula Watsona [4]. Napastnicy nie powinni mieć większego problemu z odgadnięciem portów źródłowych. Istnieje tyko kilka wyjątków, jak OpenBSD, które rzeczywiście przydzielają porty źródłowe w sposób losowy. Na przykład Windows XP rozpoczyna od portu 1050 dla pierwszego połączenia i zwiększa ten numer o jeden dla każdego kolejnego. Linux (w tym przypadku Fedora Core 3 z jądrem 2.6.9) rozpoczyna od portu 32768 i również zwiększa numery o jeden. Rysunek 2a prezentuje wynik działania polecenia netstat w systemie Linux z jądrem 2.6 (porty od 32771 do 32777). Warto porównać ten rysunek z Rysunkiem 2b przedstawiającym wynik działania netstat w systemie OpenBSD 3.6 z losowo przydzielonymi numerami portów. Produkty Cisco zwiększają numer portu dla każdego kolejnego połączenia o 512, lecz to ani trochę nie zwiększa bezpieczeństwa tego mechanizmu. Napastnicy nie muszą odgadywać numeru portu źródłowego, jeśli znają numer bieżącego połączenia w systemie ofiary. Napastnik potrzebuje jedynie znać bieżący numer portu i wypróbować około 50 portów. Bardzo skru-

WWW.LINUX-MAGAZINE.PL

Wiele ataków na połączenia TCP opiera się na opisanych do tej pory słabych punktach implementacji i samego protokołu. Jedna z technik polega na wysłaniu pakietu z ustawionym znacznikiem RST. Zgodnie z RFC 793 ten znacznik informuje odbiorcę, że ma bezwarunkowo zakończyć połączenie. Odbiorca pakietu weryfikuje jedynie numer sekwencyjny oraz (teoretycznie) numer potwierdzenia i decyduje, czy pakiet jest wiarygodny i połączenie ma być zamknięte. Odbiorca pakietu RST nie powinien odsyłać żadnego pakietu odpowiedzi (w szczególności pakietu RST). Ważnym elementem specyfikacji jest wskazówka, iż odbiorca pakietu RST powinien zweryfikować numer sekwencyjny i na jego podstawie podjąć decyzję o wiarygodności pakietu. Odbiorca zamyka połączenie tylko wówczas, gdy numer sekwencyjny znajduje się w oknie odbiorczym. Choć odbiorca mógłby zweryfikować numer potwierdzający, nie musi tego robić. Ekspert do spraw bezpieczeństwa, Paul Watson (patrz Ramka „Historia”), przeanalizował zachowanie wielu implementacji stosu TCP i stwierdził, że większość z nich po prostu ignoruje numer potwierdzenia [4]. Pakiet RST odebrany w odpowiednim oknie, zawierający dane zgodne z połączeniem, zawsze spowoduje jego bezwarunkowe zakończenie. Szczególnie zagrożone atakami tego typu są połączenia długoterminowe, jak komunikacja BGP pomiędzy ruterami. Z jednej strony napastnik ma dość czasu, aby wprowadzić precyzyjnie spreparowany pakiet, z drugiej strony skutki takiego ataku blokady usług są bardzo poważne. Rutery w takiej sytuacji muszą odbudować swoje tablice sąsiadów, co w rzeczywistych warunkach może zająć kilka minut.

Synchroniczna śmierć Mniej oczywisty jest fakt, że pakiety SYN również mogą zakończyć połączenie. TFC 793 stwierdza, że gdy znacznik SYN jest ustawiony na początku połączenia, pole numeru sekwencyjnego powinno zawierać inicjującą wartość numeru sekwencyjnego do późniejszego wykorzystania. Jeśli pakiet SYN nadejdzie w czasie połączenia, RFC określa taki przypadek jako błąd. W konsekwencji odbiorca takiego błędnego pakietu jest zobowiązany

NUMER 20 PAŹDZIERNIK 2005

65

SYSADMIN

Przechwytywanie sesji TCP

do natychmiastowego przerwania połączenia przed odesłanie do nadawcy pakiety RST. To jest zdefiniowany bezpośrednio w standardzie TCP sposób uniknięcia dwukrotnego inicjowania połączenia, na przykład w przypadku, gdy jedna ze stron połączenia jest zrestartowana. Ustawienie znacznika RST lub SYN w datagramie IP zawierającym poprawny numer sekwencyjny da ten sam efekt: zamknięcie połączenia. W odróżnieniu od zrywania połączenia za pomocą pakietu RST, w przypadku błędu SYN host odbiorcy jest zobowiązany do reakcji na ten pakiet, czyli do odesłania pakietu RST. Jest nawet wymyślona nazwa dla zachowania tego typu: mówi się, że odbiorca odbija (ang. reflect) pakiet. Takie zachowanie otwiera nowe możliwości dla ataków blokady usług. Napastnik może zatamować całą przepustowość ofiary. Atak tego typu jest szczególnie skuteczny w przypadku łączy ADSL. Ofiara otrzymuje dane szybciej, niż jest w stanie odsyłać odpowiedzi. Ataki RST i SYN nie wykorzystują zawartości datagramów IP, istnieje trzecia technika, polegająca na wstrzykiwaniu danych do istniejących połączeń. Takie dane mogą być zupełnie dowolne i psuć połączenia, napastnik może też odpowiednio preparować pakie-

ty, aby sprowokować sytuację błędu. Ofiara może nawet nie zauważyć manipulacji.

Zastosowania praktyczne Paul Watson w celu praktycznego sprawdzenia swoich teorii [4] napisał kod reset_tcp.c, który opublikował w maju roku 2004 [12]. Paul zauważył, że zwykłe połączenia DSL wystarczą do odgadnięcia numeru sekwencyjnego i zamknięcia połączenia w przeciągu jedenastu minut, przyjmując rozmiar okna wynoszący 65535 i 50 portów źródłowych do sprawdzenia. Biorąc pod uwagę okno o rozmiarze 16384 bajtów, atak zajmie 45 minut. Wspomniany program wymaga do pracy biblioteki „Libnet Packet Construction Library” [13] autorstwa Mike'a D. Schiffmana. Jeśli atak ma się odbywać w sieci lokalnej, przed skompilowaniem programu należy skonfigurować w nim własny adres MAC oraz adres MAC interfejsu docelowego (ofiary). Program oczekuje kilku parametrów: reset_tcp interfejs IP_źródłowe port_źródłowy IP_docelowe port_docelowy rozmiar_okna. Parametr interfejs określa kartę sieciową, przez którą będą wysyłane pakiety RST. Pierwszy praktyczny test miał na celu sprawdzenie, czy program jest w stanie prze-

rwać połączenie SSH pomiędzy dwoma komputerami z systemem Linux (Rysunek 3). Obydwa komputery do połączenia z Internetem wykorzystywały modem Telekom T-DSL 1000 (prędkość wysyłki 128 Kb/s). Na potrzeby tego prostego testu założymy, że napastnik zna już port docelowy. Pakiet RST ma rozmiar 40 bajtów (ponieważ składa się tylko z nagłówków IP i TCP), czyli 320 bitów. Załóżmy, że rozmiar okna wynosi 5840 bajtów w obydwu kierunkach. W oparciu o teorię można wyliczyć, ile czasu zajmie zamknięcie połączenia: maksymalna wartość numeru sekwencyjnego podzielona przez rozmiar okna, pomnożona przez rozmiar pakietu, podzielona przez prędkość transmisji. Po podstawieniu wartości uzyskujemy 4294967296 / 5840 * 320 bitów / 128000 b/s, co daje w wyniku 1840 sekund, czyli 30 minut i 40 sekund. Gdyby przyjąć, że wszystkie próby będą miały te same szanse powodzenia, napastnik będzie potrzebował średnio tylko połowę tego czasu, czyli 15 minut i 20 sekund. Nasze testy potwierdzają to przypuszczenie: w serii 20 testów odnotowaliśmy średnią wartość równą 932 sekundy (czyli 15 minut i 32 sekundy). Załóżmy, że potrzebujemy sprawdzić 50 portów źródłowych (na przeciętnym komputerze

Ważne pojęcia Numer potwierdzenia: 32-bitowy element segmentu nagłówka TCP zawierający numer sekwencyjny, jaki będzie wysyłany w kolejnym datagramie TCP.

■ URG: Jeśli ustawiony jest znacznik URG, w polu wskaźnika pilnych danych znajduje się wskaźnik do danych, których dostarczenie powinno być przyspieszone.

BGP: Border Gateway Protocol służy do przesyłania pomiędzy ruterami komunikatów na temat dostępności poszczególnych tras komunikacyjnych. Siła protokołu BGP polega na tym, że dzięki niemu z wielu tras można zbudować jedną tablicę rutingu.

ICMP: Internet Control Message Protocol (zdefiniowany w RFC 792), wykorzystywany głównie w celach diagnostycznych i do wymiany informacji.

Bity kontrolne: znaczniki wchodzące w skład segmentu nagłówka TCP. Występuje sześć bitów kontrolnych:

■ SYN: żądanie synchronizacji na początku połączenia.

■ ACK: Pakiet potwierdzający otrzymanie przez odbiorcę pakietów o numerze sekwencyjnym mniejszym od numeru zapisanego w polu potwierdzenia pakietu ACK.

Looking Glass: usługa służąca do sprawdzenia, czy dany serwer jest dostępny i jaka jest jakość łącza [6]. Diagnoza odbywa się przez odpytanie za pomocą protokołu BGP ruterów biorących udział w transmisji. Usługa Looking Glass daje użytkownikom dobry przegląd jakości połączeń. Dodatkowymi narzędziami, które mogą być pomocne w diagnozowaniu systemów pośredniczących transmisji, są być ping i traceroute.

■ RST: Przerwanie połączenia.

Sygnatura MD5: Algorytm MD5 wylicza unikalny skrót (hash) z dowolnego zbioru danych. Jeśli do obliczenia skrótu jest wykorzystane hasło, MD5 wygeneruje sygnaturę (skrót zabezpieczony kluczem).

■ PSH: Znacznik informujący stos TCP o tym, że powinien natychmiast opróżnić bufory i wysłać wszystkie oczekujące dane, lub przesłać je do odpowiedniej aplikacji.

Numer sekwencyjny: 32-bitowy element segmentu nagłówka TCP zawierający numer pierwszego oktetu (bajtu) segmentu danych. Odbiorca pakietu numer sekwencyjny wyko-

■ FIN: Wszystkie dane zostały wysłane (poprawne zakończenie połączenia).

66

NUMER 20 PAŹDZIERNIK 2005

WWW.LINUX-MAGAZINE.PL

rzystuje do sprawdzenia kolejności i poprawności przychodzących pakietów. Ta technika zabezpiecza odbiorcę przed atakami powtórzenia (reply) lub wstrzyknięcia (injection). Ta cecha protokołu zabezpiecza jednak raczej przed przypadkowymi błędami, niż przed atakami opierającymi się na celowej manipulacji. TCP: Transmission Control Protocol (zdefiniowany w RFC 793) kontroluje transfer danych pomiędzy nadawcą i odbiorcą. W odróżnieniu od protokołu UDP (User Datagram Protocol, zdefiniowanego w RFC 768), TCP jest zorientowany połączeniowo, dzięki czemu dane docierają bez uszkodzeń i w odpowiedniej kolejności. Rozmiar okna: 16 bitowy element segmentu nagłówka TCP określający liczbę oktetów danych (bajtów), jakie nadawca tego pakietu przyjmie jako prawidłowe. Skalowanie okna: Sposób na optymalizację wydajności połączeń o dużej przepustowości lub o dużych czasach opóźnień. Skalowanie okna pozwala zwiększyć rozmiar okna odbiorczego w celu zmieszczenia w nim pakietów przychodzących z opóźnieniem i aby zwiększyć ilość danych, które odbiorca przyjmie bez konieczności wysyłania potwierdzenia.

Przechwytywanie sesji TCP

SYSADMIN

obsługującym jednocześnie tylko kilka połączeń). Czas potrzebny na przeprowadzenie ataku będzie wynosił około 13 godzin. To dość sporo, nawet na długotrwałe połączenie SSH.

Okno odbiorcze TCP nie ma stałego rozmiaru. Administratorzy większości systemów operacyjnych mogą zmienić jego domyślny i maksymalny rozmiar.

Zmienny rozmiar okna

Cisco IOS: W trybie „enable” rozmiar okna można zmienić, wywołując polecenie ip tcp window-size rozmiar_okna.

Większość systemów operacyjnych modyfikuje rozmiar okna aktywnego połączenia, aby dostosować go do rozmiarów przesyłanych danych. Na przykład Linux zwiększy okno odbiorcze połączenia SSH przesyłającego tylko wynik działania programu top do rozmiaru powyżej 16000 bajtów. Jeśli napastnik wie, że ofiara wykorzystuje połączenie do przesyłania dużej ilości danych, może on założyć większy rozmiar okna. Powtórzyliśmy nasze testy na tym samym łączu, lecz tym razem za cel wzięliśmy połączenie SSH, w którym był uruchomiony program top. Średnia trwania skutecznego ataku wyniosła tym razem 5 minut i 45 sekund przy oknie o rozmiarze 16000 i znanym porcie źródłowym.

Zmiana rozmiaru okna

Linux, jądro w wersji 2.4 i 2.6 z IPv4: Zmodyfikować wartości w plikach /proc/sys/net/ipv4/tcp_rmem oraz /proc/sys/net/ipv4/wmem lub wpisać wartości dla tcp_rmem i tcp_wmem w pliku /etc/sysctl.conf, po czym wywołać polecenie sysclt -p. Szczegółowy opis znajduje się w dokumencie HOWTO [18]. Sun Solaris: W systemach Solaris służy do tego polecenie ndd: ndd -set /dev/tcp tcp_xmit_hiwat rozmiar_okna oraz ndd -set /dev/tcp tcp_recv_hiwat rozmiar_okna. Windows 2000 i XP: Zmodyfikować wartości kluczy GlobalMaxTcpWindowSize (typ REG_DWORD) oraz TcpWindowSize (typ REG_DWORD) w gałęzi HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters rejestru. Szczegółowy opis znajduje się w dokumencie HOWTO [18].

W praktycznych testach otrzymaliśmy średni czas 5 minut i 39 sekund, co ponownie potwierdza teorię. Połączenia BGP z reguły trwają tygodniami, a nawet miesiącami. Ponowne nawiązanie połączenia trwa średnio ponad minutę, a rutery BGP nie otwierają jednocześnie dużej liczby połączeń sieciowych. Dzięki temu stają się łatwym celem, dając napastnikowi mnóstwo czasu na sprawdzenie zaledwie kilku portów źródłowych.

Aktywne zabezpieczenie

Rysunek 3: Program Ethereal monitorujący atak RST na połączenie SSH. Napastnik wysyła dużą liczbę pakietów TCP ze zwiększającymi się numerami sekwencyjnymi (górne okno, w pobliżu wiersza Seq=...). Widok szczegółowy (środek) wyraźnie pokazuje, że został wysłany pakiet ze znacznikiem RST.

Kolejny zestaw eksperymentów oparliśmy na przedstawionym przez Watsona przykładzie połączenia BGP. Komputer z systemem Linux (jądro 2.4, początkowy rozmiar okna 5840) wykorzystujący protokół BGP do komunikacji z ruterem Cisco (początkowy rozmiar okna 16384). Rozmiar okna zmienił się zgodnie z oczekiwaniami wraz ze zwiększeniem się natężenia ruchu. Na początku połączenia protokół BGP przesyła dość duże ilości danych. W naszym scenariuszu rozmiar okna w ciągu kilku minut wzrósł w obydwu kierunkach do 16616 i ustabilizował się na tym poziomie. Teoretyczny średni czas skutecznego ataku wynosi w takim przypadku 4294967296 / 16616 * 320 bitów / 128.000 b/s / 2 = 5 minut i 23 sekundy.

Z powodu dużego zagrożenia i małego ryzyka ze strony napastnika ważne jest, aby zastosować odpowiednie środki zaradcze. Istnieje kilka sposobów podejścia do minimalizacji negatywnych efektów omówionych problemów. Jako regułę należy przyjąć unikanie publikowania informacji na temat połączeń i konfiguracji sieci. Konfiguracja usług typu Looking Glass jest zbyt ryzykowna (protokół BGP, zob. Ramka „Ważne pojęcia” oraz [6]), podobnie jak niektóre wpisy w DNS. W wielu systemach operacyjnych administratorzy mogą modyfikować rozmiary okna (patrz Ramka „Zmiana rozmiaru okna”). Mniejsze wartości powodują, że trudniej jest zaatakować system. O ile to możliwe, najlepiej w ogóle unikać skalowania okna. Dzięki temu w oknie odbiorczym będzie mieścić się mniejsza liczba numerów sekwencyjnych, a napastnik będzie musiał wykazać więcej precyzji, co z kolei będzie kosztować go więcej czasu. Istnieją jednak granice takich konfiguracji. Jeśli wybrane wielkości okna będą za małe, obniży się wydajność sieciowa. TCP będzie działać wolniej, ponieważ oprogramowanie obsługujące protokół będzie czekać na potwierdzenia, zamiast kontynuować transmisję. A wraz ze wzrostem liczby pakietów

WWW.LINUX-MAGAZINE.PL

potwierdzających (ACK) zwiększa się narzut na wykorzystanie pasma. Przyjrzyjmy się skrajnemu przykładowi: jeśli rozmiar okna będzie wynosił 10, 40-bajtowy pakiet ACK będzie wysyłany dla potwierdzenia każdych 10 bajtów danych (20 bajtów na nagłówek IP, 20 bajtów na nagłówek TCP).

Porządne filtrowanie Dobre zabezpieczenie przed atakami RST na wysokim poziomie kontroli daje filtr sieciowy. Rutery powinny po prostu akceptować przychodzący i wychodzący ruch o adresach źródłowych odpowiadających interfejsowi rutera, przez który ten ruch przechodzi. Dzięki temu można zabezpieczyć się przed podsłuchiwaniem i taka konfiguracja powinna oczywiście dotyczyć każdego rutera. Filtry typu ingress i egress zabezpieczają sieć wewnętrzną przed atakami z zewnątrz sieci wykorzystującymi podszywanie się pod adresy wewnętrzne, zabezpieczają też sieć zewnętrzną przed napastnikami z naszej sieci. Ostrożni administratorzy uzupełnią konfigurację filtra o reguły ruchu BGP odbywającego się ze znanymi ruterami. Dzięki temu ataki na połączenia BGP będą znacznie utrudnione. Kolejny typ zabezpieczeń został wprowadzony w roku 1998: RFC 2385 opisuje sygnatury MD5 dla połączeń TCP [7]. Ta technika wykorzystuje skróty MD5 oparte na hasłach i wszystkich kluczowych polach nagłówków. Dzięki temu adresat pakietu może zidentyfikować sfałszowany pakiet. Oczywiście, hasła muszą być mocne, aby uniknąć ataków z wykorzystaniem programów łamiących, jak bgpcrack [8] stosujących metody słownikowe. Opis podatności na ataki protokołu BGP oraz kilka porad na temat zabezpieczeń można znaleźć w [9].

NUMER 20 PAŹDZIERNIK 2005

67

SYSADMIN

Przechwytywanie sesji TCP

Ostrożna odpowiedź

5 sekund przyśle maksymalnie 10 pakietów RST. Proponowana zmiana standardu zaleca ponadto, aby za pomocą pakietu ACK weryfikować również poprawność przychodzącego pakietu SYN. Wszystkie proponowane rozszerzenia standardu są zgodne z RFC 793. Rozszerzenia te do zapobiegania atakom wykorzystują standardowe mechanizmy TCP. Pomimo tych usprawnień nadal jednak istnieje zagrożenie atakami Rysunek 4: Zmodyfikowany stos oparty na [10], w którym wyblokady usług wykorzystująmaga się, aby pakiet RST miał poprawny numer sekwencyjny. cymi zalewanie ofiary odpowiednio spreparowanymi pakietami. kietem ACK, szybko zużyje swoją przepustoLinux ma jeszcze jedno narzędzie do walki wość, co jest szczególnie skuteczne w przypadz atakami tego typu: jest to pakiet łat na jądro ku niesymetrycznych łączy ADSL. Aby tego o nazwie GR Security [11], który powoduje, że uniknąć, sugeruje się tak skonfigurować mejądra 2.4 i 2.6 w sposób losowy dobierają porty chanizmy TCP, aby pakiet ACK był wysyłany źródłowe połączeń TCP. Ta funkcja, jak wiele wyłącznie w przypadku, gdy nadawca w czasie innych poprawek wprowadzanych przez GR Security, była oryginalnie zaimplementowaINFO na w systemie OpenBSD. Nasze testy dowio[1] Computer Security Institute: [11] GR Security: http://www.grsecurity.net dły, że łata działa zgodnie z założeniami: http://www.gocsi.com w pełni zapobiegła naszym próbom zamknię[12] TCP Connection Reset Remote Exploit: cia połączenia za pomocą zdalnego ataku. [2] RFC 793, „Transmission Control Protohttp://www.frsirt.com/exploits/04232004.tcp-

W kwietniu 2004 roku organizacja IETF opublikowała szkic standardu [10] sugerującego zmiany w mechanizmach odpowiedzi na pakiety w protokole TCP. Zamiast natychmiast reagować na przychodzący znacznik RST, protokół wymagałby dokładnego dopasowania numeru sekwencyjnego. Jeśli numer sekwencyjny znajduje się w oknie odbiorczym, lecz nie jest dopasowany dokładnie, odbiorca takiego pakietu miałby wysyłać pakiet ACK, na który nadawca musi odesłać drugi pakiet RST (Rysunek 4.). Chodzi o to, że napastnik podszywający się pod jedną ze stron komunikacji nie otrzyma pakietu ACK i szansa powodzenia ataku jest znacznie zmniejszona. Jeśli pakiet RST był jednak przesłany przez właściwego nadawcę, wtedy w odpowiedzi na pakiet ACK ponownie prześle pakiet RST, potwierdzając chęć zamknięcia połączenia. Proponowana modyfikacja wprowadza jednak nową dziurę - tak zwaną wojnę ACK, gdy napastnik zaleje ofiarę dużą liczbą pakietów RST. Jeśli ofiara na każdy pakiet odpowie pa-

col”: http://rfc.net/rfc793.html

-exploit.php

[3] RFC 1323, „TCP Extensions for High Performance”: http://rfc.net/rfc1323.html

[13] Libnet: http://www.packetfactory.net/projects/libnet/

[4] Open Source Vulnerability Database, Paul (Tony) Watson, „Slipping in the Window: TCP Reset Attacks”: http://www.osvdb.org/reference/SlippingInTheWindow_v1.0.ppt

[14] Robert T. Morris, „A Weakness in the 4.2 BSD Unix TCP/IP Software”: http://pdos.csail.mit.edu/~rtm/papers/117.pdf

[5] Open Source Vulnerability Database, Paul (Tony) Watson, „TCP Reset Spoofing”: http://www.osvdb.org/4030 [6] Strony usługi IPv4 Looking Glass: http://www.bgp4.net/lg [7] RFC 2385, „Protection of BGP Sessions via the TCP MD5 Signature Option”: http://rfc.net/rfc2385.html [8] BGP Crack: http://www.cisco.com/security_services/ciag/tools/bgpcrack-2.1.tar.gz [9] Sean Convery i Matthew Franz, „BGP Vulnerability Testing: Separating Fact from FUD v1.1”: http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-convery-franz-v3.pdf [10] Internet Draft, „Improving TCP's Robustness to Blind In-Window Attacks”: http://ietfreport.isoc.org/idref/draft-ietf-tcpm-tcpsecure/

68

NUMER 20 PAŹDZIERNIK 2005

[15] Laurent Joncheray, „Simple Active Attack Against TCP”: http://www.usenix.org/publications/library/proceedings/security95/full_papers/joncheray.ps [16] Cert Advisory CA-2001-09, „Statistical Weaknesses in TCP/IP Initial Sequence Numbers”: http://www.cert.org/advisories/CA-2001-09.html [17] Dave MacDonald i Warren Barkley, „Microsoft Windows 2000 TCP/IP Implementation Details”: http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx [18] Oskar Andreasson, „Ipsysctl tutorial – Chapter 3, IPv4 variable reference”: http://ipsysctl-tutorial.frozentux.net/chunkyhtml/tcpvariables.html [19] Cert Advisory CA-1995-01, „IP Spoofing Attacks and Hijacked Terminal Connections”: http://www.cert.org/advisories/CA-1995-01.html

WWW.LINUX-MAGAZINE.PL

Lepiej zapobiegać Atak TCP RST i jego krewniak TCP SYN stanowią duże zagrożenie i nie wolno ich lekceważyć. Istnieje duża liczba gotowych do zastosowania skryptów i programów, które mogą być wykorzystane przez napastnika nawet za pośrednictwem łącza DSL do zablokowania długotrwałego połączenia. W związku z tym zagrożeniem Theo de Raadt, lider projektu OpenBSD powiedział kiedyś: „wiele osób mówi, że to nie jest żaden problem, ale jestem pewny, że prędzej czy później pojawi się robak wykorzystujący tę dziurę”. ■

AUTORZY Wilhelm Dolle ma certyfikat CISSP i jest zatwierdzonym przez BSI (Bundesamt für Sicherheit in der Informationstechnik) audytorem bezpieczeństwa informatycznego. Pracuje w Interactive Systems GmbH (iAS), gdzie jest odpowiedzialny za bezpieczeństwo informatyczne. Christoph Wegener ma doktorat z fizyki i jest szefem działu Business Development w Gits AG. Przez wiele lat był niezależnym konsultantem do spraw bezpieczeństwa Linuksa i innych zastosowań informatycznych.