はじめに：T-Pot分析ツール開発で直面した謎の接続エラー
ハニーポットプラットフォーム「T-Pot」は、サイバー攻撃を収集・分析するための強力なツールです。しかし、その収集したデータを外部のスクリプトから活用しようとした時、私は奇妙で根深い問題に直面しました。基本的な接続テストは成功するにもかかわらず、Elasticsearchに複雑な分析クエリを投げると、決まってタイムアウトや接続拒否エラーが発生するのです。
この記事では、その原因がT-Potサーバーの「リソース過負荷」であったことを突き止め、その根本原因である「Suricata」を無効化するまでの、長い試行錯誤の全記録を詳細に記します。T-Potのカスタマイズやパフォーマンス問題に悩む、すべてのユーザーの助けとなれば幸いです。
第1章：パフォーマンス問題の特定
最初に疑ったのは、スクリプトやネットワーク設定でした。しかし、requestsライブラリを使ったシンプルな接続テスト用スクリプトは、何度試しても正常に応答を返します。一方で、elasticsearchライブラリを使った本格的な分析スクリプトは必ず失敗します。このことから、問題は「単純な疎通確認」ではなく、「ある程度の負荷がかかるクエリの処理」にあると推測しました。
そこで、T-PotサーバーにSSHでログインし、定番のtopコマンドでリソースの使用状況を監視しました。すると、案の定、いくつかのプロセスがCPUとメモリを激しく消費していることが判明しました。
# topコマンドの出力例
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6339 tpot 20 0 52.3g 2.9g 355180 S 39.2 24.4 1:47.71 java
5724 tpot 20 0 6066328 1.4g 45420 S 27.6 12.4 1:13.20 python3
特にCPUとメモリを消費していたのは、以下の2つです。
- java: これはT-PotのデータストアであるElasticsearchです。
- Suricata: ネットワーク全体を監視する侵入検知システム(IDS)です。
この状況から、「サーバーの負荷が高い状態では、Elasticsearchが新しい接続要求に応答する余裕がなくなり、タイムアウトや接続拒否を引き起こしている」という仮説に至りました。
第2章：Suricata無効化への長い道のり
解決策として、まずはリソース消費の大きいSuricataを無効化し、Elasticsearchが使えるリソースを確保する方針を立てました。しかし、ここからがT-Potの強固な自己防衛機能との長い戦いの始まりでした。
試行1：設定ファイルのリネーム → 失敗
T-Potは各コンポーネントが個別のdocker-compose.ymlで管理されているアーキテクチャです。そこで、まずSuricata専用の設定ファイルを無効化しようと試みました。
sudo mv /opt/tpot/docker/suricata/docker-compose.yml /opt/tpot/docker/suricata/docker-compose.yml.disabled
しかし、T-Potを再起動すると、何事もなかったかのようにSuricataは起動してきました。どうやら、メインの設定ファイルがこれを上書き、あるいは別の場所から設定を読み込んでいるようでした。
試行2：メイン設定ファイルのコメントアウト → 失敗
次に、T-Pot全体を統括するメインの設定ファイルを編集する方針に切り替えました。docker inspectコマンドで現在起動しているコンテナが参照している設定ファイルを特定すると、それは/opt/tpot/etc/tpot.ymlであることが判明しました。
しかし、このファイルを編集しようとすると「リンクされたファイルです」というメッセージが表示されます。ls -lで確認すると、このファイルは/opt/tpot/etc/compose/standard.ymlへのシンボリックリンクでした。
そこで、リンク先の実体であるstandard.ymlを直接編集し、suricataのブロック全体をコメントアウトしました。今度こそ大丈夫だろうとT-Potを再起動しましたが、それでもSuricataはゾンビのように起動してきたのです。
第3章：原因の核心と最終的な解決手順
なぜ設定を正しく編集したのに反映されないのか？最後のヒントは、docker psの出力にありました。
# 他コンテナは数分前起動なのに、Suricataだけ数時間前起動のまま
suricata "/bin/sh -c 'SURICAT..." 2 hours ago Up 2 minutes
elasticsearch "/bin/sh -c 'python3..." 8 minutes ago Up 2 minutes
他のコンテナは再起動のたびに作り直されているのに、Suricataのコンテナだけが古いまま生き残っていたのです。これこそが問題の核心でした。
原因のまとめ：
- T-Potの起動プロセスには、ほとんどのコンテナを一度削除し、最新設定で再作成するクリーンアップ処理が含まれている。
- しかし、
network_mode: "host"という特殊な設定のためか、Suricataコンテナだけがこのクリーンアップ処理を免れ、古いコンテナが残り続けていた。 - そのため、私たちがいくら設定ファイルを編集しても、その設定が適用される新しいコンテナが作られず、古いコンテナがずっと起動し続けていた。
最終的な解決手順
原因が分かれば、対策は明確です。「クリーンアップを免れている古いSuricataコンテナを、手動で完全に削除する」ことです。
1. Dockerサービスを完全に停止させる
まず、ファイルロックなどを避けるため、Docker自体を完全に停止させ、安全な作業環境を確保します。
sudo systemctl stop docker
2. 古いSuricataコンテナを手動で強制削除する
T-Potのクリーンアップ処理ができなかった後始末を、私たち自身の手で行います。
# -f (--force) オプションで、もしコンテナが停止していなくても強制的に削除します
sudo docker rm -f suricata
3. 設定ファイル（実体）が編集済みであることを確認する
この手順の前に、/opt/tpot/etc/compose/standard.yml内のsuricataのブロックがコメントアウトされていることが必須です。これが私たちの望む「新しい設計図」となります。
4. Dockerサービスを起動する
準備は全て整いました。Dockerサービスを起動すれば、T-Potも自動的に起動します。
sudo systemctl start docker
この手順により、T-Potはクリーンな状態から起動し、私たちの編集した（Suricataが存在しない）`standard.yml`を読み込みます。そして、削除すべき古いSuricataコンテナはもはや存在しないため、新しく作成されることもありません。
結論：戦いの終わりと得られた教訓
docker ps | grep suricata を実行し、何も表示されなくなったのを確認した時、私たちの長い戦いは終わりました。サーバーリソースは安定し、topコマンドの出力も非常に穏やかなものになりました。そして、ついに当初の目的であったmalware_analyzer.pyは、Elasticsearchへの接続に成功したのです。
[2025-08-29 23:49:58.779450] マルウェア分析スクリプトを開始します。
前回の実行時刻: 2025-08-29T14:46:54.726943+00:00
- Elasticsearchにクエリを送信しています: https://www.automotive555.net:64297/es/tpot-*/_search
✅ クエリ成功。
新しいマルウェアは見つかりませんでした。
[2025-08-29 23:49:58.922980] スクリプトを終了します。
今回のトラブルシューティングから得られた最大の教訓は、**「T-Potをカスタマイズする際は、設定ファイルの変更と合わせて、古いコンテナが残っていないか確認することが重要である」**ということです。T-Potの強固な自己防衛機能と複雑なアーキテクチャを理解し、正しく付き合っていくことが、安定した運用の鍵となります。
コメント