¿Supervisión sobre la marcha de solicitudes HTTP en una interfaz de red?

79

Para fines de depuración, deseo monitorear las solicitudes http en una interfaz de red.

Usando una ingenua tcpdumplínea de comando obtengo demasiada información de bajo nivel y la información que necesito no está muy claramente representada.

Volcar el tráfico tcpdumpa un archivo y luego usarlo wiresharktiene la desventaja de que no está sobre la marcha.

Me imagino un uso de herramienta como este:

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

Estoy usando Linux

networking monitoring http-logging

— maxschlepzig
fuente

Hay misma pregunta contestada en superuser.com/questions/67428/possible-to-catch-urls-in-linux

— AlexD

100

Prueba tcpflow:

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

La salida es así:

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

Obviamente, puede agregar métodos HTTP adicionales a la declaración grep y usarlos sedpara combinar las dos líneas en una URL completa.

— bahamat
fuente

Una ventaja de esto tcpflowes que ya está disponible en los repositorios predeterminados en Ubuntu 10.04 (justsniffer, httpry no lo están). La información del paquete indica que los fragmentos de IP no se registran correctamente, no sé si esto es importante para este caso de uso, tal vez justsniffer pueda manejarlos mejor.

— maxschlepzig

Como solo estás tomando la URL, no parece que importe. Tcpflow mostrará los paquetes en el orden en que fueron recibidos en la interfaz. Por lo tanto, si intentaba capturar el contenido del archivo, puede obtener paquetes que llegan fuera de servicio y producirán un archivo corrupto. Pero su caso de uso enumerado en la pregunta creo que esto funcionará para usted. También puede ampliar su grep (o eliminar el -o) para ver más datos del paquete para ordenarlos o no.

— bahamat

@bahamat ¿Puede "tcpflow" funcionar con la URL https?

— Maulik patel

Cada vez más, la respuesta es no. En el pasado, SSL era lo suficientemente débil como para que si tuviera acceso a la clave utilizada para el flujo, pudiera descifrar cualquier tráfico utilizado con esa clave. Hoy en día, la mayoría de los sitios utilizarán el secreto perfecto y negociarán claves efímeras. La mejor opción hoy en día es un llamado proxy transparente "protuberancia en el cable".

— bahamat

1

no obtuvo nada, mientras navegaba, usando wifi: sudo tcpflow -p -c -i wlo2 port 80 | grep -oE '(GET | POST | HEAD). * HTTP / 1. [01] | Host:. *'

— ses

23

Puede usar httpry o Justniffer para hacer eso.

httpry está disponible, por ejemplo, a través del repositorio de paquetes de Fedora.

Llamada de ejemplo:

# httpry -i em1

(donde em1denota un nombre de interfaz de red)

Salida de ejemplo:

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 salida se acorta un poco)

— X4lldux
fuente

¿Cómo puedo mostrar el encabezado o el cuerpo de la solicitud o respuesta?

— Mohammed Noureldin

no tiene nada sudo httpry -i wlo2 (donde wlo2 es por nombre de dispositivo wifi)

— ses

7

Estaba buscando algo similar, con el requisito adicional de que también debería funcionar para https .

Las herramientas basadas en pcap como tcpflow httpry urlsnarfy otros tcpdump kung fu funcionan bien para http, pero para solicitudes seguras no tiene suerte.

Se me ocurrió urldump , que es una pequeña envoltura alrededor de mitmproxy .
iptablesse utiliza para redirigir el tráfico al proxy, por lo que funciona de manera 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
...

Ver README para más información.

— exprimir
fuente

1

Creo que Wireshark es capaz de hacer lo que quieras

En el lado positivo, es muy potente, puede instalarlo a través de apt-get, y viene con una GUI.

Sin embargo, el sistema de filtro es complicado, pero hay buenos tutoriales incorporados y le dará una visión general en vivo o de inicio / detención del tráfico.

Escribir la palabra 'http' en el filtro probablemente le dará lo que está buscando (es decir, el tráfico principal generado por los usuarios).

— Mahmoud Hossam
fuente

Me gustaría saber por qué esto fue rechazado. Wireshark puede leer la interfaz sobre la marcha y filtrar solo el tráfico http.

— Kevin M

@ Kevin M, Bueno, no desestimé tu respuesta. Pero para ser justos, su respuesta es un poco incompleta y fuera de tema. 1) Se pierden detalles sobre cómo se debe usar exactamente wireshark, es decir, se debe usar un filtro, la expresión exacta del filtro, etc. En el enfoque GUI, la vista predeterminada muestra las solicitudes GET, donde el nombre de dominio no se muestra al lado del otro, lo que no es conveniente para el caso de uso esbozado.

— maxschlepzig

Quiero decir: s / tu respuesta / la respuesta de Phobia /

— maxschlepzig

1

Otra buena opción podría ser nethogs

En fedora está disponible entre los paquetes principales, y en centos puede obtenerlo a través del repositorio de epel.

— adriano72
fuente

1

También está el programa de línea de comandos urlsnarfque forma parte del paquete dsniff (que también está empaquetado con, por ejemplo, Fedora 19).

Ejemplo:

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

(cuando navega primero a SE y luego a spiegel.de)

Limitaciones: dsnarf no es compatible con IPv6 . Puedo reproducir este informe de error con 0.17 en Fedora 19. También parece estar roto en Ubuntu Trusty ATM (funciona bien bajo lucid).

— maxschlepzig
fuente