Większość z nas, pracujących w świecie e-security miała osobiście do czynienia z analizą wykazów zapory sieciowej (ang. Firewall), systemu IDS, czy też innego typu urządzenia zwiększającego bezpieczeństwo. Badanie pakietów może być trudnym zadaniem a przede wszystkim czasochłonnym. W związku z powyższym, wielu z nas preferuje automatyzację pracy sprawdzonymi narzędziami takimi jak na przykład Ethereal.
P R Z E D S T A W I E N I E
Jest jednak pewien zauważalny problem przy tego typu podejściu. Nawet jeśli praca z programem Ethereal dostarcza świetnych wyników analizy przy rozkładaniu pakietów oraz ich treści na fragmenty, to istnieje jedna rzecz której nigdy nie zrobi za Ciebie - Nie pomoże Ci zrozumieć pewnych kluczowych zależności zawartych w metryce pakietów, takich jak na przykład sekwencyjność TCP. Ethereal nie zakomunikuje czy w przechwytywanym przez niego strumieniu danych brakuje pewnych pakietów. Jedyną możliwością dojścia do tego czy brakuje jest ręczna analiza każdego pojedynczego pakietu odnosząc się do wspomnianej wcześniej metryki pakietów TCP. Jeżeli wydaje Ci się to na pierwszy rzut oka mało istotne, to jesteś w błędzie. Konsultanci do spraw bezpieczeństwa audytując sieć klienta posiadać muszą kompletne rozeznanie tego co się w niej dzieje. Muszą mieć możliwość zliczenia każdego jednego pakietu przesłanego podczas ataku. Czasami przy pewnych założeniach dochodzi do porzucenia niektórych pakietów przez tcpdump czy choćby windump, szczególnie jeśli badana sieć dysponuje szybkimi łączami. Kruczek polega na tym, iż nie wiedziałbyś o tym gdyby nie świadomość opcji przeprowadzenia szczegółowej analizy pakietów. Aby mieć taką możliwość wymagana jest dogłębna wiedza na temat szczegółów dotyczących komunikacji poszczególnych protokołów, w tym przypadku protokołu TCP.
Celem tego artykułu jest uzbrojenie Cię w wiedzę, która pomoże Ci przy przeprowadzaniu testów na strumieniach oraz prawidłowe determinowanie czy w przesyle brakuje jakichkolwiek pakietów. Jest to wysoce konieczne w przypadkach, kiedy w strumieniu danych brakuje pakietów mogących zawierać kluczowe wskazania, dowódy włamania lub wrażliwe dane. Jedyny aspekt, który nie zostanie poruszony w niniejszym artykule to analiza warstwy aplikacji. Skupmy się tylko na wiedzy potrzebnej do szczegółowej analizy pakietów.
W P R O W A D Z E N I E
Artykuł ten wyjaśnia w pełni zależności pomiędzy numerami sekwencyjnymi TCP a numerami potwierdzeń. Numery te pełnią główną rolę przy transmisji pakietów. Po udanej 3-stopniowej procedurze powitalnej (handshake) zostanie wysłany pakiet z numerem sekwencyjności TCP. Będzie on pierwszym oczekiwanym przez adres docelowy numerem sekwencyjności. Aby dokładniej to zrozumieć możemy przyjąć że adres IP będący źródłem wysyła numer potwierdzenia, który jest kolejnym oczekiwanym numerem sekwencyjności TCP adresu docelowego.
04/10/2005 10:11:46.263921 10.10.10.10.2748 > 192.168.1.1.25: S [tcp sum
ok] 1635370671:1635370671(0) win 8760 <mss 1460,nop,nop,sackOK> (DF) \
(ttl 112, id 8408, len 48)
0x0000 4500 0030 20d8 4000 7006 a954 0a0a 0a0a
\n
\n E..0..@.p..T.... Ten adres e-mail zabezpieczony jest przed spambotami. Musisz posiadać wąłczoną JavaScript aby zobaczyć. Ten adres e-mail jest chroniony przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
0x0010 c0a8 0101 0abc 0019 6179 c6af 0000 0000 ........ay......
0x0020 7002 2238 ed4d 0000 0204 05b4 0101 0402 p."8.M..........
Liczba podkreślona na powyższym listingu nazywana jest "Initial Sequence Number" - ISN. Zawarta jest zawsze w pakiecie SYN, przy pierwszym kroku handshake. Sekwencja ta rozpoczyna się wysłaniem SYN do (192.168.1.1). "mss 1460" odnosi się do maksymalnej wielkości segmentu. Wartość 1460 mierzona jest w bajtach czyli po prostu 1460 bajtów. "mss 1460" oznacza że (10.10.10.10) chce otrzymać nie więcej niż 1460 bajtów w każdym zadanym pakiecie z adresu (192.168.1.1).
Następny w kolejności "nop" jest prostą instrukcją (pad), która właściwie nic nie robi, używana jest czasami do opóźniania operacji. "sackOK" odwołuje się do wybranych potwierdzeń informując, iż może być użyty dla danej sesji. Obie wartości "sackOK" i "mss" powinny być widoczne tylko i wyłącznie podczas porcji SYN, SYN/ACK wymiany TCP/IP handshake, nie powinny się pojawić w porcji danych całej sesji. Ostatnią metryką jest "win 8760" związany z ilością miejsca pamięci bufora (w bajtach), którą dysponuje adres źródłowy (10.10.10.10). Wartość ta nazywana jest czasami buforem odbioru (ang. Receive buffer). Możemy stwierdzić, iż powyższy pakiet jest pakietem SYN, gdyż widzimy na wykazie "S," lecz bardziej definitywnie dopatrujemy się klasy pakietu po jego wartości hex wynoszącej 02. Hex jako 0x.... wskazuje że następujące po nim liczby przedstawione są w formacie szesnastkowym. Przyjrzyjmy się teraz dokładniej pakietowi SYN i offsetom w których się znalazł (nagłówek TCP).
O B J A Ś N I E N I E F L A G T C P
Czterema bazowymi protokołami omawianej tematyki są IP, TCP, UDP i ICMP. Jeśli chcemy zliczyć bajty w rdzeniu nagłówka pakietu musimy zacząć od 0 nie od 1, jak ma to czasami miejsce. Flagi FIN, SYS, RST, PSH, ACK, URG znajdują się w 13-stym bajcie offsetu licząc od 0 w nagłówku pakietu TCP. Każda z tej flagi posiada przydzieloną dla siebie wartość, niezależnie od systemu liczbowego w którym jest przez Ciebie przedstawiana zawsze wynosi tyle samo. To z kolei daje nam możliwość zapisania maski bitów do pliku binarnego (loga), lub bezpośredniego zrzutu z tcpdump.
CWR ECE URG ACK PSH RST SYN FIN
128 64 32 16 8 4 2 1
Diagram przedstawiony powyżej obrazuje decymalne wartości dla poszczególnych flag w 13-stym bajcie offsetu nagłówka TCP. Z takimi informacjami możemy bez problemu zaplanować filtr BPF zawierający maskę bitów i wyciągnąć wszystkie pakiety wraz z odpowiadającymi im flagami. Na przykład (korzystając z powyższego diagramu) jeśli chcielibyśmy zapisać wykaz z filtrem BPF i bitmaską tak, aby wyświetlała nam tylko pakiety PSH/ACK wykorzystalibyśmy poniższą metodę:
tcpdump -nXvSs 0 ip and host 10.10.10.10 and \
host 192.168.1.1 and tcp[13] = 24
Podnosząc wartości obu flag ACK i PSH doszliśmy do wartości decymalnej równej 24, . Dlaczego łącznie akurat 24? - Gdyż nakazaliśmy tcpdump, aby spojrzał w nagłówek TCP do 13-stego bajtu offsetu licząc od 0, sprawdził czy bajt ten posiada dziesiętną wartość równą 24 i w rezultacie wyświetlił ją nam. Pamiętajmy o tym że pracę filtru wykonuje się na pliku binarnym, który został uprzednio całkowicie zalogowany (obrazek poniżej). Filtru przedstawionego powyżej użylibyśmy celem nakazania tcpdump zapisywania tylko pakietów z powyższego IP włączając kombinację flag równą 24. Natomiast filtrem przedstawionym poniżej podziałamy na istniejący już plik binarny (log) który nazwaliśmy "bleh".
tcpdump -r bleh 0 ip and host 10.10.10.10 and \
host 192.168.1.1 and tcp[13] = 24 > bleh2
Zakładamy że plik "bleh" jest zalogowanym uprzednio zapisem sesji pomiędzy dwoma przyjętymi adresami IP. Posiadając taki plik binarny mamy możliwość dodania przeciwko niemu interaktywnie filtra bpf/bitmaski. Wykonując powyższą komendę, nakazujemy tcpdump, aby przyjrzał się przyjętym warunkom, zapisując ostatecznie całą zawartość w formacie ASCII do pliku "bleh2". Pamiętajmy że zawsze lepiej jest logować bezpośrednio do pliku binarnego, który daje nam potem możliwość zrzucenia zawartości do formatu ASCII. Pliku binarnego z formatu ASCII już nie odtworzymy, a więc wniosek jest oczywisty. Wiele narzędzi takich jak Snort czy Tcpdump będzie pracowało tylko z plikami binarnymi i definitywnie odrzucą parsowanie plików w formacie ASCII.
W R A C A J Ą C D O B A D A Ń P A K I E T Ó W
Przyjrzyjmy się drugiemu pakietowi:
04/10/2005 10:11:46.264343 192.168.1.1.25 > 10.10.10.10.2748: S [tcp sum
ok] 727167800:727167800(0) ack 1635370672 win 24820 <nop,nop,sackOK,mss
1460> (DF) (ttl 62, id 18217, len 48)
0x0000 4500 0030 4729 4000 3e06 b503 c0a8 0101 E..0G)@.>.......
0x0010 0a0a 0a0a 0019 0abc 2b57 b338 6179 c6b0 ........+W.8ay..
0x0020 7012 60f4 cff0 0000 0101 0402 0204 05b4 p.`.............
Drugim krokiem w procedurze handshake jest SYN/ACK. Zauważyć możemy ISN +1 (podkreślone na listingu). Posiadamy dodatkowo numer sekwencyjności TCP - 727167800:727167800.
Przejdźmy do kroku trzeciego:
04/10/2005 10:11:47.381612 10.10.10.10.2748 > 192.168.1.1.25: . [tcp sum
ok] ack 727167801 win 8760 (DF) (ttl 112, id 8426, len 40)
0x0000 4500 0028 20ea 4000 7006 a94a 0a0a 0a0a E..(
\n
\n ..@.p..J.... Ten adres e-mail zabezpieczony jest przed spambotami. Musisz posiadać wąłczoną JavaScript aby zobaczyć. Ten adres e-mail jest chroniony przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
0x0010 c0a8 0101 0abc 0019 6179 c6b0 2b57 b339 ........ay..+W.9
0x0020 5010 2238 3b71 0000 0000 0000 0000 P."8;q........
Pakiet ten jest ostatnim krokiem całości 3-stopniowej procedury. ACK oznaczony jest jako "." (zaraz za portem docelowym 25 adresu IP). ACK, następuje w formie numerów nie wskazując jako iż jest 13-stym bajtem offsetu nagłówka TCP licząc od zera, więc w rzeczywistości jest to numer potwierdzenia + 1, następują po nim kolejne numery. To jest ważny punkt do zapamiętania.
04/10/2005 10:11:47.670592 192.168.1.1.25 > 10.10.10.10.2748: P [tcp sum
ok] 727167801:727167830(29) ack 1635370672 win 24820 (DF) (ttl 62, id
18218, len 69)
0x0000 4500 0045 472a 4000 3e06 b4ed c0a8 0101 E..EG*@.>.......
0x0010 0a0a 0a0a 0019 0abc 2b57 b339 6179 c6b0 ........+W.9ay..
0x0020 5018 xxxx xxxx xxxx xxxx xxxx xxxx xxxx P.`.....xxxxxxxx
0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx
0x0040 xxxx xxxx xx xxxxxx
Mamy teraz nasz adres (192.168.1.1) wysyłający dane, na co wskazuje nam "P" z powyższego listingu a także wartość 13-stego bajtu dla flagi ACK. Zauważmy że 13-sty bajt w nagłówku TCP to tam gdzie znajdują się wszystkie flagi: SYN, ACK, RST, FIN, URG, PSH. Zdajemy sobie sprawę również z tego że nie mamy możliwości wizualizacji reprezentacji flagi ACK w nagłówku pakietu na powyższym obrazku, ale widać go przy wartości 5018. Dokładniej, "18" w hex, który reprezentuje 24 w dec. Liczba ta odwołująca się do PSH i ACK jest sumowana i wynosi 24.
04/10/2005 10:11:49.770114 10.10.10.10.2748 > 192.168.1.1.25: . [tcp sum
ok] ack 727167830 win 8731 (DF) (ttl 112, id 8473, len 40)
0x0000 4500 0028 2119 4000 7006 a91b 0a0a 0a0a E..(!
\n
\n .@.p....... Ten adres e-mail zabezpieczony jest przed spambotami. Musisz posiadać wąłczoną JavaScript aby zobaczyć. Ten adres e-mail jest chroniony przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
0x0010 c0a8 0101 0abc 0019 6179 c6b0 2b57 b356 ........ay..+W.V
0x0020 5010 221b 3b71 0000 0000 0000 0000 P.".;q........
W pakiecie tym widzimy adres (10.10.10.10) uzyskujący odpowiedź, potwierdzając jednocześnie przyjęcie porcji danych, czyli pakietu przedstawionego powyżej. Pole z numerami zapytania zostały podkreślone na obrazku. Spoglądając na numer potwierdzenia 727167830 wiemy jednocześnie że adres (192.168.1.1) otrzymał kompletną zawartość pakietu.
04/10/2005 10:11:51.682538 10.10.10.10.2748 > 192.168.1.1.25: P [tcp sum
ok] 1635370672:1635370706(34) ack 727167830 win 8731 (DF) (ttl 112, id
8501, len 74)
0x0000 4500 004a 2135 4000 7006 a8dd 0a0a 0a0a E..J!
\n
\n 5@.p....... Ten adres e-mail zabezpieczony jest przed spambotami. Musisz posiadać wąłczoną JavaScript aby zobaczyć. Ten adres e-mail jest chroniony przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
0x0010 c0a8 0101 0abc 0019 6179 c6b0 2b57 b356 ........ay..+W.V
0x0020 5018 221b b622 0000 4845 4c4f 2074 7332 P.".."..HELO.ts2
0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx
0x0040 6c2e 726f 6c2e 7275 0d0a l.rol.ru..
Kluczowym do zapamiętania tutaj jest fakt że numer "ACK" zadanego pakietu jest kolejną oczekiwaną sekwencją numerów TCP, które pasują numerom "ACK" pakietu przedstawionego dwa obrazki wyżej. Jest właśnie tak jak powinno być. Pakiet przedstawiony na powyższym obrazku to ten który odpowiada, przyjmując zapytanie pakietu a nie ten, który wysyła dane (gdyż brak numerów sekwencyjnych). Jeśli dochodzi do wysyłania danych automatycznie warunkuje to załączenie numerów sekwencyjnych. Jeśli pakiet wysyła dane posiada on oba numery, sekwencyjny i numer "ACK". Także możemy oczekiwać że adres (192.168.1.1) wykorzysta numery "ACK" jako przyjęte numery sekwencyjne TCP.
04/10/2005 10:11:51.682814 192.168.1.1.25 > 10.10.10.10.2748: . [tcp sum
ok] ack 1635370706 win 24820 (DF) (ttl 62, id 18219, len 40)
0x0000 4500 0028 472b 4000 3e06 b509 c0a8 0101 E..(G+@.>.......
0x0010 0a0a 0a0a 0019 0abc 2b57 b356 6179 c6d2 ........+W.Vay..
0x0020 5010 60f4 fc75 0000 0000 0000 0000 P.`..u........
W tym pakiecie adres (192.168.1.1) przyjmuje od pakietu z poprzedniego obrazka tylko potwierdzenie. Dlatego nie zawiera numeru sekwencyjnego TCP. Upewnijmy się, przyglądając się numerowi sekwencyjnemu z poprzedniego obrazka i żauważmy że numer ten znajduje się po prawej, czyli potwierdzenie numeru "ACK" naszego pakietu. Innymi słowy, pakiet mówi 'odebrałem Twoje dane i przetworzyłem je.'.
04/10/2005 10:11:51.682916 192.168.1.1.25 > 10.10.10.10.2748: P [tcp sum
ok] 727167830:727167853(23) ack 1635370706 win 24820 (DF) (ttl 62, id
18220, len 63)
0x0000 4500 003f 472c 4000 3e06 b4f1 c0a8 0101 E..?G,@.>.......
0x0010 0a0a 0a0a 0019 0abc 2b57 b356 6179 c6d2 ........+W.Vay..
0x0020 5018 60f4 xxxx xxxx xxxx xxxx xxxx xxxx P.`.....xxxxxxxx
0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx
Na listingu przedstawionym powyżej widać że posiadamy dwa numery, sekwencyjny i "ACK". Dlatego wiemy że używany jest do potwierdzenia danych jak również do wysyłania odpowiedzi. W tym przypadku nasz numer sekwencyjny TCP składa się z numeru "ACK" widzianego dwa obrazki wyżej. Sytuacja jest również taka jak powinna być. Zapamiętajmy że numer "ACK" pakietu jest kolejną oczekiwaną sekwencją numerów TCP przez pakiet innego adresu IP. Mamy więc ten sam numer "ACK" i jest to prawidłowe zachowanie.
04/10/2005 10:11:54.820932 10.10.10.10.2748 > 192.168.1.1.25: . [tcp sum
ok] ack 727167853 win 8708 (DF) (ttl 112, id 8541, len 40)
0x0000 4500 0028 215d 4000 7006 a8d7 0a0a 0a0a E..(!]@.p.......
0x0010 c0a8 0101 0abc 0019 6179 c6d2 2b57 b36d ........ay..+W.m
0x0020 5010 2204 3b4f 0000 0000 0000 0000 P.".;O........
Pakiet ten jest tylko potwierdzeniem na co wskazuje "ACK". Nie zawiera numerów sekwencyjnych TCP, gdyż nie było wysyłanych żadnych danych. Innymi słowy, (10.10.10.10) mówi 'dzięki 192.168.1.1, otrzymałem Twoje dane.".
04/10/2005 10:11:58.070622 10.10.10.10.2748 > 192.168.1.1.25: P [tcp sum
ok] 1635370706:1635370747(41) ack 727167853 win 8708 (DF) (ttl 112, id
8591, len 81)
0x0000 4500 0051 218f 4000 7006 a87c 0a0a 0a0a E..Q!
\n
\n .@.p.. Ten adres e-mail zabezpieczony jest przed spambotami. Musisz posiadać wąłczoną JavaScript aby zobaczyć. Ten adres e-mail jest chroniony przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć |....
0x0010 c0a8 0101 0abc 0019 6179 c6d2 2b57 b36d ........ay..+W.m
0x0020 5018 2204 42ec 0000 4d41 494c 2046 524f P.".B...MAIL.FRO
0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx
0x0040 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx
0x0050 0a
04/10/2005 10:11:58.070913 192.168.1.1.25 > 10.10.10.10.2748: . [tcp sum
ok] ack 1635370747 win 24820 (DF) (ttl 62, id 18221, len 40)
0x0000 4500 0028 472d 4000 3e06 b507 c0a8 0101 E..(G-@.>.......
0x0010 0a0a 0a0a 0019 0abc 2b57 b36d 6179 c6fb ........+W.may..
0x0020 5010 60f4 fc35 0000 0000 0000 0000 P.`..5........
K O N K L U Z J A
Jest to przewodnik, którego celem jest przybliżenie szczegółów komunikacji oraz zależności pomiędzy numerami sekwencyjności TCP a numerami potwierdzeń. Pełne zrozumienie tego artykułu pomoże Ci w przypadku, w którym wymagane będą od Ciebie szczegółowe badania poszczególnych pakietów. Nawet jeśli nie, to napewno wpływnie pozytywnie na Twoją ogólną wiedzę o TCP/IP.
- Autorzy: Don Parker i Mike Sues
- Przełożył: Paweł Jabłoński, admin [at] cyberterroryzm.pl (tłumaczenie oryginalnie znajduje się pod adresem: http://cyberterroryzm.pl/(...)analiza-pakietow-tcp.html)
Źródło: Don Parker i Mike Sues