Monitoramento rápido de solicitações HTTP em uma interface de rede?

79

Para fins de depuração, quero monitorar as solicitações HTTP em uma interface de rede.

Usando uma tcpdumplinha de comando ingênua, obtenho muitas informações de baixo nível e as informações de que eu preciso não estão muito claramente representadas.

Despejar o tráfego tcpdumpem um arquivo e usá-lo wiresharktem a desvantagem de que ele não está em movimento.

Eu imagino um uso de ferramenta 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
...

Eu estou usando Linux.

networking monitoring http-logging maxschlepzig
fonte
Existe a mesma pergunta respondida em superuser.com/questions/67428/possible-to-catch-urls-in-linux #
7897 AlexD

Respostas:

100

Tente tcpflow:

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

A saída é assim:

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

Obviamente, você pode adicionar métodos HTTP adicionais à instrução grep e usar sedpara combinar as duas linhas em uma URL completa.

bahamat
fonte
Uma vantagem tcpflowdisso é que ele já está disponível nos repositórios padrão do Ubuntu 10.04 (justsniffer, o initpry não está). As informações do pacote afirmam que os fragmentos de IP não são registrados corretamente - não sei, se isso importa para este caso de uso - talvez o justsniffer possa lidar melhor com eles.
maxschlepzig
Como você está apenas pegando o URL, não parece que isso importará. O Tcpflow exibirá pacotes na ordem em que foram recebidos na interface. Portanto, se você estava tentando capturar o conteúdo do arquivo, pode obter pacotes que chegam fora de ordem e produzem um arquivo corrompido. Mas seu caso de uso listado na pergunta acho que isso funcionará para você. Você também pode ampliar seu grep (ou remover o -o) para ver mais dados de pacotes para classificação ou outros enfeites mais tarde.
bahamat
@bahamat O "tcpflow" pode funcionar com URL https?
Maulik patel #
Cada vez mais, a resposta é não. No passado, o SSL era fraco o suficiente para que, se você tivesse acesso à chave usada para o fluxo, pudesse descriptografar qualquer tráfego usado com essa chave. Hoje, a maioria dos sites usa sigilo de encaminhamento perfeito e negocia chaves efêmeras. A melhor opção hoje é o chamado proxy transparente "bump in the wire".
bahamat
1
não conseguiu nada enquanto navega usando wifi: sudo tcpflow -p -c -i wlo2 port 80 | grep -oE '(GET | POST | HEAD). * HTTP / 1. [01] | Host:. *'
ses
23

Você pode usar o enablepry ou o Justniffer para fazer isso.

httpry está disponível, por exemplo, através do repositório de pacotes do Fedora.

Chamada de exemplo:

# httpry -i em1

(em que em1denota um nome de interface de rede)

Exemplo de saída:

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

(a saída é um pouco reduzida)

X4lldux
fonte
Como posso mostrar o cabeçalho ou o corpo da solicitação ou resposta?
Mohammed Noureldin
não tenho nada sudo httpry -i wlo2 (onde wlo2 é pelo nome do dispositivo wifi)
ses
7

Eu estava procurando por algo semelhante, com o requisito adicional de que também deveria funcionar para https .

ferramentas pcap baseados como tcpflow httpry urlsnarfe outros fu tcpdump kung trabalho bem para http, mas para solicitações seguras você está sem sorte.

Eu vim com urldump , que é um pequeno invólucro em torno de mitmproxy .
iptablesé usado para redirecionar o tráfego para o proxy, para que funcione de forma 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
...

Consulte README para obter mais informações.

limões
fonte
1

Eu acho que o Wireshark é capaz de fazer o que você quer

No lado positivo, é muito poderoso, você pode instalá-lo via apt-get e vem com uma GUI.

No entanto, o sistema de filtro é complicado - mas há bons tutoriais integrados e ele fornece uma visão geral ao vivo ou iniciar / parar o tráfego.

Digitar a palavra 'http' no filtro provavelmente fornecerá o que você está procurando (ou seja, o principal tráfego gerado pelos usuários).

Mahmoud Hossam
fonte
Gostaria de saber por que isso foi rebaixado. O Wireshark pode ler a interface rapidamente e filtrar apenas o tráfego http.
Kevin M
@ Kevin M, Bem, eu não diminuí a votação da sua resposta. Mas, para ser justo, sua resposta é um pouco incompleta e fora de tópico. 1) Falta detalhes de como exatamente o wireshark deve ser usado, ou seja, que um filtro deve ser usado, a expressão exata do filtro, etc. 2) não permite o uso da linha de comando, como esboçado na pergunta - mesmo se eu estiver bem com Na abordagem da GUI, a exibição padrão exibe solicitações GET, nas quais o nome do domínio não é exibido lado a lado - o que não é conveniente para o caso de uso esboçado.
maxschlepzig
Quero dizer: s / sua resposta / Resposta de Phobia /
maxschlepzig 22/01
1

Outra boa opção pode ser nethogs

No fedora está disponível entre os pacotes principais, e no centos você pode obtê-lo através do epel repo.

adriano72
fonte
1

Há também o programa de linha de comando urlsnarfque faz parte do pacote dsniff (que também é empacotado com, por exemplo, o Fedora 19).

Exemplo:

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

(ao navegar primeiro para o SE e depois para spiegel.de)

Limitações: O dsnarf não suporta IPv6 . Eu posso reproduzir este relatório de erro com 0.17 no Fedora 19. Também parece estar quebrado no Ubuntu trusty atm (funciona bem no lucid).

maxschlepzig
fonte