ネットワークインターフェースでHTTP要求をオンザフライで監視しますか？

79

デバッグの目的で、ネットワークインターフェース上のhttpリクエストを監視します。

単純なtcpdumpコマンドラインを使用すると、低レベルの情報が多すぎて、必要な情報があまり明確に表示されません。

トラフィックをtcpdumpファイルにダンプしてから使用すると、wiresharkオンザフライではないという欠点があります。

次のようなツールの使用法を想像します。

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

Linuxを使用しています。

networking monitoring http-logging

— マックスシュレープツィヒ
ソース

superuser.com/questions/67428/possible-to-catch-urls-in-linuxで

— AlexD

100

試してくださいtcpflow：

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

出力は次のようになります。

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

もちろん、追加のHTTPメソッドをgrepステートメントに追加しsed、2行を完全なURLに結合するために使用できます。

— バハマ
ソース

利点はtcpflow、Ubuntu 10.04のデフォルトのリポジトリですでに利用できることです（justsniffer、httpryはそうではありません）。パッケージ情報には、IPフラグメントが適切に記録されていないと記載されています-このユースケースでこれが問題になるかどうかわからない-おそらくjustsnifferはそれらをより良く処理できるでしょう。

— maxschlepzig

URLを取得しているだけなので、問題になるとは思えません。Tcpflowは、パケットをインターフェイスで受信した順序で表示します。したがって、ファイルの内容をキャプチャしようとしていた場合は、パケットが順番どおりに到着せず、破損したファイルが生成される可能性があります。しかし、質問にリストされているユースケースは、これがあなたのために働くと思います。また、grepの幅を広げて（または-oを削除して）、後でソートするためのパケットデータを表示することもできます。

— バハマ

@bahamat "tcpflow"はhttps URLで動作しますか？

— Maulikパテル

ますます、答えはノーです。過去には、SSLは十分に脆弱であったため、フローに使用されるキーにアクセスできる場合、そのキーで使用されるトラフィックを解読できました。今日、ほとんどのサイトは完全転送秘密を使用し、一時キーをネゴシエートします。今日の最良のオプションは、いわゆる「バンプインザワイヤ」透過プロキシです。

— バハマ

1

閲覧中にwifiを使用しても何も得られませんでした：sudo tcpflow -p -c -i wlo2 port 80 | grep -oE '（GET | POST | HEAD）。* HTTP / 1。[01] | Host：。*'

— ses

23

これを行うには、httpryまたはJustnifferを使用できます。

httpry Fedoraパッケージリポジトリなどから入手できます。

呼び出しの例：

# httpry -i em1

（ここでem1、ネットワークインターフェイス名を示します）

出力例：

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

（出力は少し短くなっています）

— X4lldux
ソース

要求または応答のヘッダーまたは本文を表示するにはどうすればよいですか？

— モハメッドヌールディン

何も得られなかったsudo httpry -i wlo2（wlo2はwifiデバイス名による）

— ses

7

私は似たようなものを探していましたが、httpsでも動作するという追加の要件がありました。

tcpflow httpry urlsnarfやその他のtcpdump kung fuなどのpcapベースのツールはhttpでうまく機能しますが、安全なリクエストのためには運がありません。

私が思い付いたurldump周りの小さなラッパーで、mitmproxy。
iptablesトラフィックをプロキシにリダイレクトするために使用されるため、透過的に機能します。

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

詳細については、READMEを参照してください。

— レモンスクイーズ
ソース

1

Wiresharkはあなたがやりたいことをできると思います

プラス面としては、非常に強力であり、apt-getを介してインストールでき、GUIが付属しています。

ただし、フィルタシステムは複雑です-しかし、組み込みの優れたチュートリアルがあり、トラフィックのライブまたは開始/停止の概要を提供します。

「http」という単語をフィルターに入力すると、おそらく探しているもの（つまり、ユーザーが生成した主なトラフィック）が得られます。

— マフムード・ホッサム
ソース

これがなぜ投票されたのか知りたいです。Wiresharkは、その場でインターフェイスを読み取り、httpトラフィックのみにフィルタリングできます。

— ケビンM

@ケビンM、まあ、私はあなたの答えをダウン票しませんでした。しかし、公平を期すために、あなたの答えは少し不完全でトピックから外れています。1）Wiresharkの正確な使用方法、つまり、フィルタの使用方法、正確なフィルタ表現などの詳細が欠落しています。2）問題でスケッチしたようなコマンドラインの使用は許可されていません-でも大丈夫ですGUIアプローチでは、デフォルトビューにGETリクエストが表示されますが、ドメイン名は横並びでは表示されません-とは、スケッチしたユースケースにはあまり便利ではありません。

— maxschlepzig

私の意味：s /あなたの答え/恐怖症の答え/

— maxschlepzig

1

別の良いオプションはnethogsかもしれません

fedoraはコアパッケージの中から入手でき、centosではepelリポジトリから入手できます。

— adriano72
ソース

1

dsniffパッケージのurlsnarf一部であるコマンドラインプログラムもあります（Fedora 19などにもパッケージ化されています）。

例：

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

（最初にSEを参照し、次にspiegel.deを参照する場合）

制限：dsnarfはIPv6をサポートしません。Fedora 19で0.17でこのバグレポートを再現できます。また、Ubuntu trusty atm（lucidで正常に動作します）では壊れているようです。

— マックスシュレープツィヒ
ソース