simsong/tcpflowTCP/IPパケットデマルチプレクサ。ダウンロード元:
ダウンロードディレクトリ: http://digitalcorpora.org/downloads/tcpflow/
ほとんどの一般的なGNU/Linuxディストリビューションは、リポジトリにtcpflowを同梱しています。そのため、Debian/Ubuntuなどでは以下のように入力します。
sudo apt-get install tcpflow
Fedora/RedHat/CentOSなどでは以下のように入力します。
sudo dnf install tcpflow
これで完了です。何らかの理由でこれで十分でない場合は、ソースからビルドできます。
Linux向けにコンパイルするには
必要な前提条件が揃っていることを確認してください。ルートディレクトリには、ホストオペレーティングシステムに応じてこれを実行するファイルがあります。
CONFIGURE_ARCH_17_8.sh CONFIGURE_FEDORA_18.sh CONFIGURE_FEDORA_26.sh CONFIGURE_UBUNTU_16_04.sh
OSに応じて、以下のように実行します。
# sudo bash CONFIGURE_<YOUROS>.sh
OSを設定したら、以下の手順でコンパイルとインストールを行います。
./configure
make
sudo make install
Gitで開発ツリーをダウンロードする場合は、--recursive を付けて 完全な チェックアウトを行い、その後 bootstrap.sh、configure、make を実行してください。
git clone --recursive https://github.com/simsong/tcpflow.git
cd tcpflow
bash bootstrap.sh
./configure
make
sudo make install
Amazon AMI向けにダウンロードしてコンパイルするには:
ssh ec2-user@<your ec2 instance>
sudo bash yum -y install git make gcc-c++ automake autoconf boost-devel cairo-devel libpcap-devel openssl-devel zlib-devel
git clone --recursive https://github.com/simsong/tcpflow.git
sh bootstrap.sh
Fedora Core上でmingwを使ってWindows向けにコンパイルするには:
yum -y install mingw64-gcc mingw64-gcc-c++ mingw64-boost mingw64-cairo mingw64-zlib
mingw64-configure
make
CMakeを使用する場合は、詳細な手順を参照してください: cmake/README.md
通常ユーザー（rootではない）としてクリーンなリポジトリから:
./bootstrap.sh # ./configure ファイルを生成
./configure # tcpflow.spec ファイルを生成
rpmbuild -bb tcpflow.spec --build-in-place
specファイルと結果のRPMを確認:
rpmlint tcpflow.spec
rpmlint ~/rpmbuild/RPMS/x86_64/tcpflow-....rpm
インストール:
sudo dnf install ~/rpmbuild/RPMS/x86_64/tcpflow-....rpm
tcpflow は、TCPコネクション（フロー）の一部として送信されるデータをキャプチャし、プロトコル分析やデバッグに便利な方法でデータを保存するプログラムです。各TCPフローは独自のファイルに保存されます。したがって、典型的なTCPフローは、各方向ごとに1つずつ、合計2つのファイルに保存されます。tcpflow は、保存された 'tcpdump' パケットフローも処理できます。
tcpflow は、キャプチャしたすべてのデータを次の形式の名前を持つファイルに保存します。
[timestampT]sourceip.sourceport-destip.destport[--VLAN][cNNNN]
ここで: timestamp は、最初のパケットが確認された時刻のオプションのタイムスタンプです T はタイムスタンプが指定されたことを示す区切り文字です sourceip は送信元IPアドレスです sourceport は送信元ポートです destip は宛先IPアドレスです destport は宛先ポートです VLAN はVLANポートです c は複数のコネクションが存在することを示す区切り文字です NNNN は、同じ [time]/sourceip/sourceport/destip/destport の組み合わせを持つ複数のコネクションがある場合のコネクションカウンターです。 タイムスタンプのプレフィックス付けが行われている場合、コネクションのカウントはほとんど発生しないことに注意してください。
以下にいくつかの例を示します。
128.129.130.131.02345-010.011.012.013.45103
上記のファイルの内容は、ホスト 128.129.131.131 のポート2345 からホスト 10.11.12.13 のポート45103 に送信されたデータになります。
128.129.130.131.02345-010.011.012.013.45103c0005
128.129.131.131 のポート2345 からホスト 10.11.12.13 のポート45103 への6番目のコネクションです。
1325542703T128.129.130.131.02345-010.011.012.013.45103
128.129.131.131 のポート2345 からホスト 10.11.12.13 のポート45103 へのコネクションで、2012年1月2日午後5時19分（-0500）に開始されたものです。
128.129.130.131.02345-010.011.012.013.45103--3
128.129.131.131 のポート2345 からホスト 10.11.12.13 のポート45103 へのコネクションで、VLANポート3で確認されたものです。
ファイル名の作成に使用するテンプレートは、-F オプションと -T オプションで変更できます。テンプレートにディレクトリが含まれている場合、そのディレクトリは自動的に作成されます。
-a オプションを使用すると、tcpflow はHTTPレスポンスを自動的に解釈します。
出力ファイルが
208.111.153.175.00080-192.168.001.064.37314
である場合、
後処理により次のファイルが作成されます:
208.111.153.175.00080-192.168.001.064.37314-HTTP
208.111.153.175.00080-192.168.001.064.37314-HTTPBODY
HTTPBODY が GZIP で圧縮されていた場合、3番目のファイルも生成される可能性があります:
208.111.153.175.00080-192.168.001.064.37314-HTTPBODY-GZIP
これらのストリームに関する追加情報（MD5ハッシュ値など）もDFXMLファイルに書き込まれます。
tcpflow は 'tcpdump' に似ています。どちらもワイヤーまたは保存されたファイルからパケットを処理します。しかし、実際のデータストリームを再構築し、各フローを後で分析するために別々のファイルに保存する点が異なります。
tcpflow はシーケンス番号を理解し、再送信や順序外れの配信にかかわらず、データストリームを正しく再構築します。ただし、現在の tcpflow はIPフラグメントを認識しません。IPフラグメントを含むフローは正しく記録されません。
tcpflow は DFXML 形式でサマリレポートファイルを出力できます。このファイルには、tcpflow プログラムがコンパイルされたシステム、実行された場所、およびすべてのTCPフローに関する情報（送信元・宛先IPアドレスとポート、バイト数、パケット数、オプションで各バイトストリームのMD5ハッシュ）が含まれます。
tcpflow は LBL Packet Capture Library (ftp://ftp.ee.lbl.gov/libpcap.tar.Z で入手可能) を使用しているため、'tcpdump' などのプログラムがサポートするのと同じ豊富なフィルタ式をサポートしています。ほとんどの一般的なUNIXバージョンでコンパイルできるはずです。詳細は INSTALL ファイルを参照してください。
tcpflow はネットワークパケットフローを理解し、ネットワークフォレンジックを実行するための便利なツールです。多くのパケットや単一のTCPコネクションを表示する WireShark などのプログラムとは異なり、tcpflow は何百、何千、あるいは何十万ものTCPコネクションをコンテキスト内で表示できます。
tcpflow の一般的な用途は、HTTPセッションの内容を明らかにすることです。tcpflow を使用すると、HTTP経由でダウンロードされたWebページを再構築できます。「ドライブバイダウンロード」として配信されるマルウェアを抽出することも可能です。
Jeremy Elson はもともとこのプログラムを、未文書のネットワークプロトコルを使用するさまざまなプログラムが送信するデータをキャプチャし、それらのプロトコルをリバースエンジニアリングする目的で作成しました。RealPlayer（およびほとんどのストリーミングメディアプレーヤー）、ICQ、AOL IM はこの種のアプリケーションの良い例です。後にHTTPプロトコル分析に使用されるようになりました。
Simson Garfinkel は1998年に Sandstorm Enterprises を設立しました。Sandstorm は tcpflow に類似した TCPDEMUX というプログラムと、NetIntercept という別バージョンのプログラムを作成しました。これらのプログラムは商用です。Simson が Sandstorm を退社した後、TCPフロー再構築プログラムが必要になりました。彼は tcpflow を見つけ、そのメンテナンスを引き継ぎました。
バグは github issue tracker に報告してください。
tcpflow は現在 IPフラグメントを認識しません。IPフラグメントを含むフローは正しく記録されません。IPフラグメンテーションはますます稀な事象であるため、これは大きな問題ではないと思われます。
tcpflow に関する記事を執筆される場合は、以下のテクニカルレポートを引用してください。
Simson L. Garfinkel [email protected]
私は引き続き bulk_extractor、tcpflow、be13_api、dfxml を最新の C++ に移植しています。標準を調査した結果、C++14 ではなく C++17 を採用することにしました。現在、17 のサポートが広く普及しているためです。（おそらく 20 は必要ありません）。autotools を使い続けていますが、CMake に移行する強い理由もあるようです。be13_api と dfxml は、スタンドアロンのリンクするライブラリではなく、Python スタイルでインクルードされるモジュールとして維持しています。ただし、それが正しい判断かどうかは100%確信が持てません。
プロジェクトは予想よりも時間がかかっています。一般的なコードリファクタリングも行っているためです。時間がかかっている主な理由は、パーサーオプションと設定に関するすべての C++ オブジェクトの絡まりをほどく方法を考えていることです。
tcpflow と bulk_extractor が両方とも be13_api を使用しているため、よりシンプルなプログラムである tcpflow を使って be13_api を動作可能にする方向に注意が移っています。現在約4分の3まで進んでいます。2020年末までには何か完成する見込みです。
--- Simson Garfinkel, 2020年10月18日
感謝します: