trinadh465/external_tcpdump_cve-2018-14880コマンドラインのパケット解析ツールで、ネットワークトラフィックのキャプチャと検査を行います。ライブおよびオフライン解析に対応し、BPFフィルタリング、プロトコルデコード、スクリプト可能な出力により、セキュリティ監視とトラブルシューティングをサポートします。
セキュリティ問題を報告する場合は、[email protected] に電子メールを送信してください。
バグやその他の問題の報告、パッチの投稿、機能のリクエスト、一般的なフィードバックの提供などについては、tcpdump ソースツリーのルートにある CONTRIBUTING ファイルを参照してください。
TCPDUMP 4.x.y 現在は "The Tcpdump Group" によってメンテナンスされています 参照: www.tcpdump.org
匿名 Git は以下から利用可能です:
git clone git://bpf.tcpdump.org/tcpdump
以前は Lawrence Berkeley National Laboratory
Network Research Group [email protected]
ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z (3.4)
このディレクトリには、ネットワーク監視とデータ取得のためのツールである tcpdump のソースコードが含まれています。このソフトウェアは、もともとローレンス・バークレー国立研究所のネットワーク研究グループによって開発されました。元の配布物は anonymous ftp で ftp.ee.lbl.gov の tcpdump.tar.Z から入手可能です。最近の開発は tcpdump.org (http://www.tcpdump.org/) で行われています。
Tcpdump は libpcap を使用します。これはユーザーレベルのパケットキャプチャのためのシステムに依存しないインターフェースです。tcpdump をビルドする前に、まず libpcap を取得してビルドする必要があります。libpcap も元々 LBL から提供され、現在は tcpdump.org によってメンテナンスされています。http://www.tcpdump.org/ を参照してください。
libpcap がビルドされたら（インストールするか、../libpcap に配置されていることを確認してください）、INSTALL.txt ファイルの手順に従って tcpdump をビルドできます。
このプログラムは SMI の "etherfind" に大まかに基づいていますが、etherfind のコードは残っていません。元々は Van Jacobson によって、TCP とインターネットゲートウェイのパフォーマンスを調査・改善するための進行中の研究プロジェクトの一環として作成されました。プログラムのうち Sun の etherfind から取られた部分は、後に LBL の Steven McCanne によって書き直されました。tcpdump にプロプライエタリなコードの痕跡が残らないようにするため、Steve はマニュアルエントリの仕様に基づいて、tcpdump や etherfind のソースにアクセスせずにこれらの部分を書きました。
ここ数年、tcpdump はインターネットコミュニティからの素晴らしい貢献によって着実に改善されてきました（CHANGES ファイルをご覧ください）。すべてのご意見に感謝します。
Richard Stevens は彼の著書 "TCP/IP Illustrated, Volume 1" でインターネットプロトコルを優れた形で解説しています。tcpdump とその出力の解釈方法についてもっと学びたい場合は、この本を手に取ってみてください。
tcpdump トレースファイルを表示・分析するためのいくつかのツールが Internet Traffic Archive から入手可能です:
tcpdump ユーザーにとって有用なもう一つのツールは tcpslice です:
これは tcpdump のバイナリトレースファイルの一部を抽出するために使用できるプログラムです。詳細とドキュメントについては上記の配布物を参照してください。
現在のバージョンは www.tcpdump.org で見つけることができます。
原文: Steve McCanne, Craig Leres, Van Jacobson
このディレクトリには、特定のネットワーク問題を追跡する際に tcpdump データを削減する方法の例として、いくつかの短い awk プログラムも含まれています:
send-ack.awk
ftp（または他の単方向 TCP 転送）の tcpdump トレースを簡略化します。
一方のホストが送信のみを行い、もう一方が ACK のみを行うと想定しているため、
すべてのアドレス情報は省略され、パケットが "send" か "ack" かのみが記録されます。
元のトレースの各行に対して1行の出力があります。
フィールド1はパケットの時刻（秒単位、会話開始からの相対時間）。
フィールド2は前のパケットからのデルタ時間。
フィールド3はパケットタイプ/方向。
"Send" は送信側から受信側へのデータ、"ack" は受信側から送信側への ACK を意味します。
先頭の "*" はデータが再送信であることを示します。
先頭の "-" はシーケンス空間に穴がある（つまりパケット欠落）ことを示し、"#" は通常とは異なるサイズ（最大セグメントサイズではない）のパケットを示します。
フィールド4はパケットフラグ（生トレースと同じ形式）。
フィールド5はシーケンス番号（送信側の場合は開始シーケンス番号、ACK の場合は次の期待シーケンス番号）。
ACK の後の括弧内の数値は、そのパケットの最初の送信から ACK までのデルタ時間です。
send の後の括弧内の数値は、そのパケットの最初の送信から現在の送信までのデルタ時間（重複パケットのみ）です。
重複した send または ack には、これまでの重複回数を示す角括弧内の数値が表示されます。
以下は ftp 開始付近の短いサンプルです:
3.00 0.20 send . 512
3.20 0.20 ack . 1024 (0.20)
3.20 0.00 send P 1024
3.40 0.20 ack . 1536 (0.20)
3.80 0.40 * send . 0 (3.80) [2]
3.82 0.02 * ack . 1536 (0.62) [2]
会話開始から3秒後に、バイト512〜1023が送信されました。
200ms後、それらは ACK されました。その直後にバイト1024〜1535が送信され、再び200ms後に ACK されました。
その後、特に理由もなく、0〜511が再送信されました。最初の送信から3.8秒後です（この ftp の往復時間は1秒±500msでした）。
受信側は1536を期待しているため、0が到着したときに1536が再 ACK されます。
packetdat.awk
ftp（または類似の単方向 TCP 転送）のチャンクサマリーデータを計算します。
[「チャンク」とはシーケンス空間のチャンク、つまりパケットシーケンス番号を最大セグメントサイズで割ったものを指します。]
チャンク数、そのチャンク数を送信するのに要したパケット数（損失や重複がなければパケット数はチャンク数と等しいはずです）、および ACK の数を示すサマリー行が出力されます。
サマリー行の後、チャンクごとに1行の情報が表示されます。
行には8つのフィールドが含まれます:
1 - チャンク番号
2 - このチャンクの開始シーケンス番号
3 - 最初の送信時刻
4 - 最後の送信時刻
5 - 最初の ACK 時刻
6 - 最後の ACK 時刻
7 - チャンクが送信された回数
8 - チャンクが ACK された回数
（すべての時刻は秒単位で、会話開始からの相対時間です。）
例として、ftp トレースの最初の部分の出力を示します:
# 134 chunks. 536 packets sent. 508 acks.
1 1 0.00 5.80 0.20 0.20 4 1
2 513 0.28 6.20 0.40 0.40 4 1
3 1025 1.16 6.32 1.20 1.20 4 1
4 1561 1.86 15.00 2.00 2.00 6 1
5 2049 2.16 15.44 2.20 2.20 5 1
6 2585 2.64 16.44 2.80 2.80 5 1
7 3073 3.00 16.66 3.20 3.20 4 1
8 3609 3.20 17.24 3.40 5.82 4 11
9 4097 6.02 6.58 6.20 6.80 2 5
これは134チャンク（平均パケットサイズが512バイトなので約70KB）が転送されたことを示しています。
データの転送には536パケットが必要でした（つまり、平均して各チャンクは4回送信されました）。
例えば、チャンク4を見ると、シーケンス空間の1561〜2048の512バイトを表しています。
会話開始から1.86秒後に最初に送信されました。最後の送信は15秒後で、合計6回送信されました（つまり平均2秒ごとに再送信されました）。
最初の到着から140ms後に1回 ACK されました。
stime.awk
atime.awk
送信または ACK ごとに1行を出力します。形式は:
<time> <seq. number>
ここで <time> は転送開始からの秒数、<seq. number> は送信または ACK されたシーケンス番号です。
通常、このデータをプロットして不審なパターンを探します。
私が取り組んでいた問題は、典型的な DARPA インターネット条件下での、中程度の遅延ネットワークパス（往復時間1〜6秒）におけるバルクデータ転送スループットでした。
大きなファイルの ftp 転送のトレースを生データソースとして使用しました。
方法は以下の通りです:
- ローカルホスト（ただし tcpdump を実行している Sun ではない）でリモート ftp に接続します。
- 監視用 Sun でトレースを開始します。例:
tcpdump host local-host and remote-host and port ftp-data >tracefile
- ローカルで、大きなファイル（約500KB）の get または put を行います（ディスク書き込み待ちによる受信ウィンドウの閉鎖などの影響を最小限にするため、できれば null デバイスに対して）。
- 転送が完了したら、tcpdump を停止します。awk を使用して2つのサマリーデータファイルを作成します（maxsize は最大パケットサイズ、tracedata は tcpdump トレースデータのファイル）:
awk -f send-ack.awk packetsize=avgsize tracedata >sa
awk -f packetdat.awk packetsize=avgsize tracedata >pd
- サマリーデータファイルが出力中に、転送の振る舞いを確認します:
awk -f stime.awk tracedata | xgraph
（学ぶことの90%はこのステップで起こるようです）。
- 上記のすべてのステップを、両方向で、時刻を変え、相手側のプロトコル実装を変えて、数回繰り返します。
- Unix のデータ分析パッケージ（私の場合は S と Gary Perlman の Unix|Stat）を使用して、データを数ヶ月間じっくり観察します。
- ローカルのプロトコル実装に変更を加え、上記のステップをやり直します。
- 週に一度、資金提供者に素晴らしい発見をしていると伝え、研究報告書を「もうすぐ」書くと言います。