Monitorowanie ruchu HTTP za pomocą tcpdump

42

Obecnie używam do monitorowania ruchu HTTP między serwerem a serwerem WWW tcpdump. Działa to dobrze, ale chciałbym pozbyć się zbędnych danych wyjściowych (wiem o tcpflowi wireshark, ale nie są one łatwo dostępne w moim środowisku).

Ze strony podręcznika tcpdump:

Aby wydrukować wszystkie pakiety HTTP IPv4 do iz portu 80, tzn. Wydrukować tylko pakiety zawierające dane, nie na przykład pakiety SYN i FIN oraz pakiety tylko ACK.

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

To polecenie

sudo tcpdump -A 'src example.com i tcp port 80 i (((ip [2: 2] - ((ip [0] i 0xf) << 2)) - ((tcp [12] i 0xf0) >> 2) )! = 0) ”

zapewnia następujące dane wyjściowe:

19: 44: 03.529413 IP 192.0.32.10. Http: 10.0.1.6.52369: Flagi [P.], seq 918827135: 918827862, ack 351213824, win 4316, opcje [nop, nop, TS val 4093273405 ecr 869959372], długość 727

E ..... @ ....... .... P..6.0 ......... D ...... __ .. e = 3 ...__ HTTP / 1.1 200 OK Serwer: Apache / 2.2.3 (Red Hat) Content-Type: text / html; charset = UTF-8 Data: sob., 14 listopada 2009 18:35:22 GMT Wiek: 7149
Długość treści: 438

<HTML> <HEAD> <TITLE> Przykładowa strona internetowa </TITLE> </HEAD> <body>
<p> Dotarłeś do tej strony ... </p> </BODY> </HTML>

Jest to prawie idealne, z wyjątkiem podświetlonej części. Co to jest, koniec - co ważniejsze - jak się go pozbyć? Może to tylko drobna modyfikacja wyrażenia na końcu polecenia?

tcpdump tshark

— otto.poellath
źródło

39

tcpdump drukuje kompletne pakiety. „Śmieci”, które widzisz, są tak naprawdę nagłówkami pakietów TCP.

z pewnością możesz masować dane wyjściowe za pomocą np. skryptu perl, ale dlaczego nie użyć tshark, tekstowej wersji wireshark?

tshark 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

pobiera te same argumenty co tcpdump (ta sama biblioteka), ale ponieważ jest analizatorem, może przeprowadzać głęboką kontrolę pakietów, dzięki czemu można jeszcze bardziej udoskonalić filtry, tj.

tshark 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' -R'http.request.method == "GET" || http.request.method == "HEAD"'

— Aleksandar Ivanisevic
źródło

1

Dzięki - po wypróbowaniu wszystkich sugestii, tshark wydaje się najlepszym narzędziem do pracy. Obecnie używam „tshark -d tcp.port == 8070, http -R„ http.request lub http.response ””. Teraz gdybym tylko mógł zmusić tshark do „podążania za strumieniem tcp”, tak jak może to zrobić wireshark (często się o to pyta, ale wciąż nie znalazłem odpowiedzi). „-V” wyświetla informacje o pakietach TCP i IP itd., Które mnie nie interesują. Wydaje mi się, że mogę to usunąć za pomocą skryptu.

— otto.poellath

4

Można też szukać „get” w filtrze przechwytywania dopasowując wartości ASCII dla każdej postaci: tcp port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420. Jakiś czas temu dodałem stronę do witryny Wireshark, która pomaga tworzyć filtry przechwytywania pasujących ciągów: wireshark.org/tools/string-cf.html

— Gerald Combs,

18

spójrz na ngrep - może ci się przydać.

jako odniesienie dla innych httpry [serwer wydaje się być wyłączony, ale mam nadzieję, że jest tymczasowy] i tshark są również przydatne do pasywnej analizy protokołu - pierwsza tylko dla http, druga - dla znacznie więcej.

— pQd
źródło

2

+1 za ngrep. Bardzo przydatne narzędzie.

— tylerl

ngrep i httpry wyglądają zdecydowanie przydatne, ale ngrep nie zna HTTP i AFAIK, httpry działa tylko z nagłówkami HTTP i nie może wyświetlać danych ładunku.

— otto.poellath

@sapporo - pewnie - ngrep jest niezależny od protokołu, ale możesz dodać filtr pcap „port 80” i uzyskać… w [większości przypadków] tylko ruch http.

— pQd,

Imo, ngrep jest 100000x lepszy niż tcpdump

— Daniel W.,

5

Spróbuj httpry lub justniffer

Justniffer działa dobrze w przypadku pakietów tcp zmieniających kolejność retrasmycji i fragmentacji adresów IP

— Mole24
źródło

1

Dzięki! justniffer był tym, czego szukałem (myślę, że to jedyne wspomniane narzędzie, które jest bardzo proste i mierzy czas trwania żądania).

— gkop

1

Sugerowałbym użycie głupiego wiersza poleceń tcpdump, który przechowuje wszystko w pliku pcap do post-processingu. W zależności od tego, na co dokładnie patrzysz podczas diagnozowania, tcpflow działa doskonale, tworząc spójną analizę z powrotem.

Niektóre inne dobre informacje, w tym niektóre zastosowania httpry można znaleźć pod adresem : http://taosecurity.blogspot.com/2008/06/logging-web-traffic-with-httpry.html

— ScottZ
źródło

0

Czy używany serwer sieciowy nie tworzy dzienników? Z pewnością byłby to znacznie lepszy sposób monitorowania ruchu HTTP, istnieje mnóstwo narzędzi do analizy danych, a każdy kompetentny serwer sieciowy powinien generować wiarygodne dzienniki.

— JamesHannah
źródło

4

Wyraźnie. Wyobrażam sobie, że już o tym pomyślał. Czasami przydatne jest monitorowanie rzeczywistych danych przesyłanych między punktem A a punktem B.

— tylerl

0

Na rynku dostępnych jest kilka narzędzi zaprojektowanych specjalnie do monitorowania ruchu HTTP. Przykłady takich narzędzi to Fiddler2 ( http://www.fiddler2.org ) i HTTP Debugger Pro .

4

Dziękuję za twoje sugestie. Niestety oba narzędzia działają tylko w systemie Windows. Nie wspomniałem o tym, ale szukam czegoś, co działa na Linuksie.

— otto.poellath