Monitoraggio immediato delle richieste HTTP su un'interfaccia di rete?


79

Per scopi di debug voglio monitorare le richieste http su un'interfaccia di rete.

Usando una tcpdumpriga di comando ingenua ottengo troppe informazioni di basso livello e le informazioni di cui ho bisogno non sono rappresentate in modo molto chiaro.

Scaricare il traffico tramite tcpdumpun file e quindi utilizzarlo wiresharkha lo svantaggio di non essere al volo.

Immagino un utilizzo di questo strumento:

$ monitorhttp -ieth0 --only-get --just-urls
2011-01-23 20:00:01 GET http://foo.example.org/blah.js
2011-01-23 20:03:01 GET http://foo.example.org/bar.html
...

Sto usando Linux.


Risposte:


100

Prova tcpflow:

tcpflow -p -c -i eth0 port 80 | grep -oE '(GET|POST|HEAD) .* HTTP/1.[01]|Host: .*'

L'output è così:

GET /search?q=stack+exchange&btnI=I%27m+Feeling+Lucky HTTP/1.1
Host: www.google.com

È ovviamente possibile aggiungere ulteriori metodi HTTP all'istruzione grep e utilizzare sedper combinare le due righe in un URL completo.


Un vantaggio tcpflowè che è già disponibile nei repository predefiniti in Ubuntu 10.04 (justsniffer, httpry non lo sono). Le informazioni sul pacchetto indicano che i frammenti IP non sono registrati correttamente - non so se questo è importante per questo caso d'uso - forse justsniffer può gestirli meglio.
maxschlepzig,

Dato che stai solo prendendo l'URL, non sembra che abbia importanza. Tcpflow visualizzerà i pacchetti nell'ordine in cui sono stati ricevuti sull'interfaccia. Pertanto, se si stava tentando di acquisire il contenuto del file, è possibile ottenere pacchetti che arrivano fuori servizio e producono un file corrotto. Ma il tuo caso d'uso elencato nella domanda penso che questo funzionerà per te. Puoi anche allargare il grep (o rimuovere il -o) per vedere più dati dei pacchetti per l'ordinamento o quant'altro in seguito.
Bahamat,

@bahamat "tcpflow" può funzionare con l'URL https?
Maulik patel,

Sempre più la risposta è no. In passato SSL era abbastanza debole che se avessi accesso alla chiave utilizzata per il flusso potresti decrittografare tutto il traffico utilizzato con quella chiave. Oggi, la maggior parte dei siti utilizzerà il segreto perfetto e negozerà chiavi effimere. L'opzione migliore oggi è un cosiddetto proxy trasparente "bump in the wire".
bahamat,

1
ottenuto nulla durante la navigazione tramite wifi: sudo tcpflow -p -c -i porta wlo2 80 | grep -oE '(GET | POST | HEAD). * HTTP / 1. [01] | Host:. *'
ses

23

Puoi usare httpry o Justniffer per farlo.

httpry è disponibile ad es. tramite il repository di pacchetti Fedora.

Esempio di chiamata:

# httpry -i em1

(dove em1indica un nome di interfaccia di rete)

Esempio di output:

2013-09-30 21:35:20    192.168.0.1     198.252.206.16    >    POST    unix.stackexchange.com    /posts/6281/editor-heartbeat/edit    HTTP/1.1
2013-09-30 21:35:20    198.252.206.16  192.168.0.1       < HTTP/1.1   200    OK
2013-09-30 21:35:49    192.168.0.1     198.252.206.16    >    POST    unix.stackexchange.com    /posts/validate-body                 HTTP/1.1
2013-09-30 21:35:49    198.252.206.16  192.168.0.1       < HTTP/1.1   200    OK
2013-09-30 21:33:33    192.168.0.1      92.197.129.26    >    GET     cdn4.spiegel.de    /images/image-551203-breitwandaufmacher-fgoe.jpg    HTTP/1.1

(l'output è leggermente abbreviato)


Come posso mostrare l'intestazione o il corpo della richiesta o della risposta?
Mohammed Noureldin,

non ha ottenuto nulla sudo httpry -i wlo2 (dove wlo2 è di gran nome del dispositivo WiFi)
SES

7

Stavo cercando qualcosa di simile, con l'ulteriore requisito che dovrebbe funzionare anche per HTTPS .

strumenti basati su pcap come tcpflow httpry urlsnarfe altri tcpdump kung fu funzionano bene per http, ma per richieste sicure sei sfortunato.

Ho inventato urldump , che è un piccolo involucro attorno a mitmproxy .
iptablesviene utilizzato per reindirizzare il traffico verso il proxy, quindi funziona in modo trasparente.

$ sudo urldump   
http://docs.mitmproxy.org/en/stable/certinstall.html
http://docs.mitmproxy.org/en/stable/_static/js/modernizr.min.js
https://media.readthedocs.org/css/sphinx_rtd_theme.css
https://media.readthedocs.org/css/readthedocs-doc-embed.css
https://media.readthedocs.org/javascript/readthedocs-doc-embed.js
...

Vedi README per maggiori informazioni.


1

Penso che Wireshark sia in grado di fare quello che vuoi

Tra i lati positivi, è molto potente, è possibile installarlo tramite apt-get e viene fornito con una GUI.

Tuttavia, il sistema di filtri è complicato, ma ci sono buoni tutorial integrati e ti darà una panoramica in diretta o di avvio / arresto del traffico.

Digitare la parola "http" nel filtro ti darà probabilmente quello che stai cercando (cioè il traffico principale generato dagli utenti).


Vorrei sapere perché questo è stato sottoposto a downgrade. Wireshark può leggere l'interfaccia al volo e filtrare solo per il traffico http.
Kevin M,

@ Kevin M, beh, non ho votato in negativo la tua risposta. Ma per essere onesti la tua risposta è un po 'incompleta e fuori tema. 1) Manca i dettagli su come usare esattamente WireShark, ovvero che dovrebbe essere usato un filtro, l'esatta espressione del filtro, ecc. 2) Non consente l'utilizzo della riga di comando come indicato nella domanda, anche se sto bene con l'approccio GUI, la vista predefinita mostra le richieste GET, in cui il nome di dominio non viene visualizzato fianco a fianco - con non è così conveniente per il caso d'uso disegnato.
Maxschlepzig,

Intendo: s / la tua risposta / la risposta di Phobia /
maxschlepzig il

1

Un'altra buona opzione potrebbe essere nethogs

Su fedora è disponibile tra i pacchetti core e su centos puoi farlo attraverso il repository epel.


1

C'è anche il programma da riga di comando urlsnarfche fa parte del pacchetto dsniff (che è anche impacchettato con, ad esempio, Fedora 19).

Esempio:

# urlsnarf -i em1
urlsnarf: listening on em1 [tcp port 80 or port 8080 or port 3128]
jhost - - [29/May/2014:10:25:09 +0200] "GET http://unix.stackexchange.com/questions HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/ HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/css/style-V5-2-2.css HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/jscfg/http/global-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/js/http/javascript-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/js/http/interface-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/layout/js/http/netmind-V5-2-2.js HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "GET http://www.spiegel.de/favicon.ico HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "POST http://ocsp.thawte.com/ HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
jhost - - [29/May/2014:10:25:36 +0200] "POST http://ocsp.thawte.com/ HTTP/1.1" - - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0
[..]

(quando si naviga prima su SE e poi su spiegel.de)

Limitazioni: dsnarf non supporta IPv6 . Posso riprodurre questo bug report con 0.17 su Fedora 19. Sembra anche essere rotto sotto Ubuntu Trust Atm (funziona benissimo con Lucido).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.