Download: SysadminTop

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 2<+>32<+> 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ć
2<+>32<+> numerów sekwencyjnych oraz
2<+>16<+> 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 2<+>32<+> do
2<+>32<+>/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.