サーバーが突如過負荷に：どこを確認すべきか？
深夜、Telegramのアラート通知が鳴り止まない。サーバーのCPU使用率は100%に達し、ネットワーク帯域は圧迫され、アプリケーションの応答が異常に遅くなっています。急いでサーバーにSSH接続してnetstatを実行すると、何千ものTCP接続が殺到しているのが目に入ります。
ローカルPCであれば、Wiresharkを起動してGUI上で簡単にパケットをフィルタリングできます。しかし、SSH経由でアクセスする本番サーバー上では、目の前にあるのは黒いターミナル画面だけです。tcpdumpを使うと生のログが滝のように流れ、アプリケーション層（L7）の詳細を読み解くのは困難を極めます。これこそが、Tsharkの真価が発揮される場面です。
以前、Webサーバークラスターに対する巧妙なSSHブルートフォース攻撃の原因特定に3時間近く費やしたことがありました。その苦い経験以来、管理するすべてのサーバーで最初にインストールするツールがTsharkになりました。
Tsharkとは？なぜtcpdumpの代わりに使うべきなのか
シンプルに言えば、TsharkはWiresharkのコマンドライン（CLI）バージョンです。両者は共通のプロトコルデコードライブラリ（dissector）を使用しています。そのため、Wiresharkで解析できるプロトコルであれば、Tsharkでも同様に完璧に解析できます。
tcpdumpは非常に普及しており、ほぼすべてのLinuxディストリビューションに標準搭載されていますが、Tsharkには以下の3つの決定的なアドバンテージがあります：
- アプリケーション層（Layer 7）のディープ解析： 複雑なパーススクリプトを書くことなく、HTTPヘッダー、DNSクエリ、TLSハンドシェイク証明書、SSHペイロードなどのフィールドを直接抽出して読み取れます。
- 強力なディスプレイフィルタ（Display Filters）：
http.request.method == "POST"やdns.flags.response == 0など、Wiresharkでおなじみの構文をそのまま再利用できます。 - 柔軟なデータ抽出： 送信元IP、HTTPステータスコード、User-Agentなどのフィールドを簡単にテーブル形式で抽出し、
grep、awk、sortと直接パイプラインで連携できます。
実践：Tsharkによるパケットキャプチャと調査
1. LinuxへのTsharkのインストール
UbuntuまたはDebianの場合、APT経由で素早くインストールできます：
sudo apt update
sudo apt install -y tsharkインストール中、非rootユーザーにパケットキャプチャを許可するかどうか尋ねられます。Yesを選択し、その後現在のユーザーをwiresharkグループに追加して、毎回sudoを入力しなくても済むようにします：
sudo usermod -aG wireshark $USER
# 新しい権限を反映させるためにSSHからログアウトして再ログイン2. ネットワークインターフェースの特定とリアルタイムキャプチャ
まず、利用可能なネットワークインターフェースの一覧を確認します：
tshark -Dシステムには 1. eth0、2. lo（ループバック）などのインターフェースが表示されます。インターネットに接続しているメインインターフェースが eth0 の場合、以下のようにトラフィックの監視を開始します：
tshark -i eth0画面上にインターフェースを通過するパケットがリアルタイムで次々と表示されます。停止したい場合は Ctrl + C を押します。
3. -T fields オプションによる特定フィールドの抽出
長大なログ全体を眺める代わりに、-T fields オプションを使用すると必要な情報だけをピンポイントで抽出できます：
tshark -i eth0 -T fields -e ip.src -e ip.dst -e _ws.col.Protocol -e _ws.col.Info上記のコマンドは、送信元IP、宛先IP、プロトコル、パケットの概要情報の4列をタブ区切りで分かりやすく出力します。
4. シナリオ1：ポートスキャン（SYN Port Scan）の検知
攻撃者がNmapなどを使ってサーバーのポートスキャン（SYNスキャン）を実行する場合、3ウェイハンドシェイクを完了させずに（ACKを返さずに）TCP SYNパケットを大量に送信します。これらのパケットは以下のようにフィルタリングできます：
tshark -i eth0 -Y "tcp.flags.syn == 1 and tcp.flags.ack == 0" -T fields -e ip.src -e tcp.dstport見知らぬ単一のIPアドレスがわずか1〜2秒の間に数十個もの異なるポート（21、22、80、443、3306、8080など）へパケットを連続送信している場合、サーバーが脆弱性探査のターゲットになっていると判断できます。
5. シナリオ2：SSHブルートフォース攻撃の追跡
攻撃者がSSHパスワード総当たりツール（Hydraなど）を実行すると、ポート22への接続数が急増します。以下のコマンドは、20秒間キャプチャを行い、ポート22への接続試行回数が多い送信元IPのランキングを集計します：
tshark -i eth0 -a duration:20 -Y "tcp.dstport == 22 and tcp.flags.syn == 1" -T fields -e ip.src | sort | uniq -c | sort -nr各パラメータの意味：
-a duration:20：20秒後に自動停止します。-Y "tcp.dstport == 22 and tcp.flags.syn == 1"：SSHポートへのTCPハンドシェイク開始パケットのみを抽出します。sort | uniq -c | sort -nr：IPごとにグループ化し、接続回数の多い順（降順）に並べ替えます。
わずか20秒間で50〜100回ものリクエストを送信しているIPが見つかった場合、そのIPを iptables -A INPUT -s <攻撃者IP> -j DROP または ufw deny from <攻撃者IP> で即座に遮断できます。
6. シナリオ3：DNSトンネリングによるデータ漏洩の検知
マルウェアやボットネットは、外部への不正なデータ持ち出しやC2（コマンド＆コントロール）サーバーとの通信にDNSクエリを悪用することがよくあります。UDP 53番ポートはファイアウォールでブロックされることが稀であるためです。サーバーが名前解決を要求しているすべてのドメインを監視するには、次のように実行します：
tshark -i eth0 -Y "dns.flags.response == 0" -T fields -e ip.src -e dns.qry.nameランダムな文字列や異常に長いBase64エンコードされたサブドメイン（例：dGVzdC1kYXRh.malicious-domain.com）が確認された場合、サーバーがマルウェアに感染し、裏でデータを持ち出されている可能性が極めて高いと言えます。
7. 詳細解析に向けた.pcapファイルへのパケット保存
インシデントが発生している最中は、詳細な解析を行う前にまず生のトラフィック全体を.pcapファイルにダンプ保存しておくのが最も確実な対処法です：
# 10,000パケットをキャプチャしてincident.pcapファイルに保存
sudo tshark -i eth0 -c 10000 -w /tmp/incident.pcap保存後は、サーバー上でいつでもこのファイルをオフライン解析できます：
# 4xxまたは5xxのエラーステータスコードを返したHTTPリクエストを抽出
tshark -r /tmp/incident.pcap -Y "http.response.code >= 400" -T fields -e ip.src -e http.response.code -e http.request.uriまとめ
Tsharkは、Linuxターミナル上で手軽に使える強力な虫眼鏡のような存在です。数行のログをフィルタリングするためだけに、数ギガバイトものダンプファイルをローカルPCにダウンロードしてWiresharkを開く必要はありません。Tsharkの基本的なフィルタリング操作をマスターすれば、障害やインシデントの原因を迅速に特定し、予期せぬ攻撃からサーバーをプロアクティブに保護できるようになります。
