Surveillance à la volée des requêtes HTTP sur une interface réseau?

79

À des fins de débogage, je souhaite surveiller les demandes http sur une interface réseau.

En utilisant une tcpdumpligne de commande naïve , je reçois trop d'informations de bas niveau et les informations dont j'ai besoin ne sont pas très clairement représentées.

Dumping du trafic via tcpdumpun fichier et ensuite utiliser wiresharka le désavantage de ne pas être à la volée.

J'imagine un outil comme celui-ci:

$ 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
...

J'utilise Linux.

networking monitoring http-logging maxschlepzig
la source
La même question a été répondue sur superuser.com/questions/67428/possible-to-catch-urls-in-linux
AlexD le

Réponses:

100

Essayez tcpflow:

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

La sortie est comme ça:

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

Vous pouvez évidemment ajouter des méthodes HTTP supplémentaires à l'instruction grep et les utiliser sedpour combiner les deux lignes en une URL complète.

bahamat
la source
Un avantage tcpflowest qu'il est déjà disponible dans les référentiels par défaut d'Ubuntu 10.04 (justsniffer, httpry ne le sont pas). L'information sur le paquet indique que les fragments IP ne sont pas enregistrés correctement. Je ne sais pas si cela est important pour ce cas d'utilisation. Peut-être que justsniffer pourrait mieux les gérer.
maxschlepzig
Puisque vous ne faites que saisir l'URL, il ne semble pas que ce soit important. Tcpflow affichera les paquets dans l'ordre dans lequel ils ont été reçus sur l'interface. Ainsi, si vous essayez de capturer le contenu d'un fichier, vous pouvez obtenir des paquets qui arrivent dans le désordre et qui produiront un fichier corrompu. Mais votre cas d'utilisation énuméré dans la question, je pense que cela fonctionnera pour vous. Vous pouvez également élargir votre grep (ou supprimer le -o) pour voir plus de données de paquet pour le tri ou quoi plus tard.
bahamat
@bahamat "tcpflow" peut-il fonctionner avec une URL https?
Maulik patel
De plus en plus, la réponse est non. Dans le passé, SSL était suffisamment faible pour que, si vous aviez accès à la clé utilisée pour le flux, vous puissiez décrypter tout le trafic utilisé avec cette clé. Aujourd'hui, la plupart des sites utilisent le secret parfaitement avancé et négocient des clés éphémères. La meilleure option aujourd'hui est un proxy transparent dit "bump in the wire".
bahamat
1
n'a rien obtenu en navigant, en utilisant le wifi: sudo tcpflow -p -c -i wlo2 port 80 | grep -oE '(GET | POST | HEAD). * HTTP / 1. [01] | Hôte:. *'
son
23

Vous pouvez utiliser httpry ou Justniffer pour le faire.

httpry est disponible par exemple via le référentiel de paquets Fedora.

Exemple d'appel:

# httpry -i em1

(où em1dénote un nom d'interface réseau)

Exemple de sortie:

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

(la sortie est un peu raccourcie)

X4lldux
la source
Comment puis-je afficher l'en-tête ou le corps de la demande ou de la réponse?
Mohammed Noureldin
rien obtenu sudo httpry -i wlo2 (où wlo2 est par le nom du périphérique wifi)
ses
7

Je recherchais quelque chose de similaire, avec l'exigence supplémentaire que cela fonctionne aussi pour https .

Les outils basés sur pcap, comme par exemple les tcpflow httpry urlsnarfautres kung-fu de tcpdump, fonctionnent bien pour http, mais pour les requêtes sécurisées, vous n’avez pas de chance.

Je suis venu avec urldump , qui est une petite enveloppe autour de mitmproxy .
iptablesest utilisé pour rediriger le trafic vers le proxy, afin que cela fonctionne de manière transparente. 

$ 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
...

Voir le fichier README pour plus d'informations.

citron
la source
1

Je pense que Wireshark est capable de faire ce que vous voulez

Sur le plan positif, il est très puissant, vous pouvez l’installer via apt-get, et il est livré avec une interface graphique.

Cependant, le système de filtrage est compliqué - mais il existe de bons tutoriels intégrés qui vous donneront un aperçu en direct ou début / arrêt du trafic.

En tapant le mot "http" dans le filtre, vous obtiendrez probablement ce que vous recherchez (le trafic principal généré par les utilisateurs).

Mahmoud Hossam
la source
Voudrais savoir pourquoi cela a été voté. Wireshark peut lire l'interface à la volée et filtrer uniquement le trafic http.
Kevin M
@ Kevin M, eh bien, je n'ai pas voté contre votre réponse. Mais pour être juste, votre réponse est un peu incomplète et hors sujet. 1) Il manque des détails sur la manière exacte d'utiliser WireShark, c'est-à-dire qu'un filtre doit être utilisé, l'expression exacte du filtre, etc. l’approche graphique, la vue par défaut affiche les demandes GET, où le nom de domaine n’est pas affiché côte à côte - avec n’est pas très pratique pour le cas d’utilisation esquissé.
maxschlepzig
Je veux dire: s / votre réponse / la réponse de Phobia /
maxschlepzig
1

Une autre bonne option pourrait être nethogs

Fedora est disponible dans les packages principaux, et sur centos, vous pouvez l’obtenir via le dépôt epel.

Adriano72
la source
1

Il y a aussi le programme en ligne de commande urlsnarfqui fait partie du paquet dsniff (qui est également fourni avec, par exemple, Fedora 19).

Exemple:

# 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
[..]

(en naviguant d'abord sur SE puis sur spiegel.de)

Limitations: dsnarf ne prend pas en charge IPv6 . Je peux reproduire ce rapport de bogue avec 0,17 sur Fedora 19. Il semble également être en panne sous l’atmosphère de confiance Ubuntu (fonctionne très bien sous lucid).

maxschlepzig
la source