ハニーポットを個人で運用する、というと「一部のマニアの趣味」に聞こえるかもしれません。実際そうです。

ただ、やってみると学べることがかなり多くて、個人的にはコスパの良い学習環境だと思っています。この記事では、T-Pot をVPSで運用するにあたっての構成・維持費・つまずいたポイントを、実際に運用している立場からまとめます。

「これからハニーポットを立ててみたい」という人の、つまずき回避の参考になればうれしいです。

そもそもT-Potとは

T-Pot は、Deutsche Telekom Security が公開しているハニーポットのオールインワン環境です。

ハニーポットというのは、ざっくり言うとわざと攻撃させるためのおとりサーバのこと。攻撃者がやってくるのを待ち構えて、何をしてくるかを観察・記録します。

T-Pot のいいところは、数十種類のハニーポットを Docker でまとめて立ち上げてくれること。めちゃめちゃ種類あるので、是非とも公式github見て欲しいです。

https://github.com/telekom-security/tpotce/blob/master/README.md

これらを1台にまとめて動かせるので、「実攻撃トラフィックを観測したい」という入り口にはぴったりです。

全体構成 ― あえてELKを分離する

ここがこの記事の本題です。

T-Pot はデフォルトで構築すると、ログの可視化基盤である ELK Stack（Elasticsearch / Logstash / Kibana）が丸ごと付いてきます。便利。

システム要件はこんな感じです。

T-Pot TypeRAMStorage
Hive16GB256GB SSD
Sensor8GB128GB SSD

企業運営だと、難なくデプロイできるでしょう。でも、私は収益も今のとこはない個人。

ELK、重い。

そこで、ELKをVPSから切り離して、自宅のPCで動かす構成にしています。図にするとこうです。

        インターネット（攻撃者）
              │
              ▼  ポート 1〜N 番を受ける
    ┌────────────────────────────┐
    │  VPS（WebARENA Indigo）                │
    │                                        │
    │   T-Pot CUSTOM EDITION                 │
    │   ├ Cowrie（SSH/Telnet）               │
    │   ├ Dionaea（マルウェア捕獲）           │
    │   ├ Suricata（IDS）                    │
    │   └ …他多数                            │
    │                                        │
    │   ※ ELKは載せない（軽量化）            │
    │     ログはファイルに溜めておくだけ      │
    └────────────────────────────┘
              │
              │  SCPで手動取得（週1ペースでもOK）
              ▼
    ┌────────────────────────────┐
    │  自宅PC（普段使いのマシン）             │
    │                                        │
    │   ELK Stack（Docker）                  │
    │   ├ Elasticsearch（保存・検索）        │
    │   ├ Logstash（取り込み・加工）         │
    │   └ Kibana（可視化）                   │
    └────────────────────────────┘

VPS側は「攻撃を受けてログを溜めるだけ」に専念させて、重い分析・可視化は手元のPCに任せる、という分担です。

でもホントはELKもホスト環境から分離するべきですよ。私はめんどいからやってないだけですorz

なぜ分けたのか

理由はシンプルで、お金とリソースです。

ELK込みのデフォルト構成をまともに動かそうとすると、それなりのスペックのVPSが必要になります。VPSは性能を上げるほど月額が上がるので、ELKを外して必要スペックを下げれば、その分月額を抑えられるわけです。

一方で、自宅のPCにはそれなりにリソースの余裕があります。だったら「重い処理は手元、晒すのはVPS」と役割分担したほうが、財布にもやさしい。

元々はゲームしたくて買ったPCなので、、、PS5買うよりPC買って部分リプレースしたほうがいいかなぁって思っちゃった。。。

デメリットも正直に

いいことばかりではありません。この構成だとリアルタイム性はありません。

ログはSCPで手動取得しているので、取り込むまではKibanaに反映されません。我が家の場合、自宅PCは平気で1週間くらい電源を入れないこともあるので、「リアルタイムで監視」はそもそも諦めています。

マジの実生活では

起きる –> 子供のお世話 –> 保育園 –> 出社 or 始業 –> 終業 –> 炊事(家族の夜ご飯) –> 娘の世話、嫁との会話、自分の諸々 –> 寝落ち

毎日は無理です。。

ただ、個人の学習用途なら、これで十分だと思っています。リアルタイム監視が必要な運用ではないですし、まとめて取り込んでも分析の質は変わりません。

この辺は結構考えました。

維持費のリアル

「個人でVPS運用」と聞くと身構えるかもしれませんが、構成を絞ればそこまでかかりません。我が家の内訳はこんな感じです。

項目月額（目安）備考
VPS（WebARENA Indigo）約 1,600円ELKを外してスペックを抑えた構成
ドメインほぼ無料手持ちのものを流用
分析基盤（自宅PC＋Docker）0円既存のPCを使うので追加費用なし
所々の解約できてない費用N円本来無い。減少傾向。。

固定でかかるのは実質VPS代だけです。ELKを分離したことでVPSのスペックを落とせたのが、ここに効いています。

ハニーポットを「お金のかかる本格運用」ではなく「手の届く学習環境」に落とし込めたのは、良い構成だと思っています。

つまずきポイント

ここからが実体験です。これから立てる人が同じ穴にハマらないように、つまずいた点を残しておきます。

1. デフォルト構成は本当に重い

最初に何も考えずデフォルト構成で「イケるやろ！！！」と立ち上げたとき、メモリ使用率が100%に張り付きました。SSHでログインするだけでも数分待つ始末。

原因は前述のとおりELKです。ここで「VPSのスペックを上げる」のではなく「ELKを外す」方向に舵を切ったのが、結果的に正解でした。VPSは攻撃を受けるおとりに専念させるのが、コスト的にも安定性的にも良いと思います。

2. 管理ポートをファイアウォールで守る

T-Pot は攻撃を受けるためのものなので、わざと広いポート範囲を開けます。ただし、T-Pot自身の管理用ポート（管理画面やSSH）まで攻撃者に晒すのは、攻撃の入り口（アタックサーフェス）を無駄に広げるだけなので、美しくない。(あと色々メンテがだるい)

公式のドキュメントでも、ここははっきり注意されています。

To avoid probing for T-Pot’s management ports you should put T-Pot behind a firewall and forward all TCP / UDP traffic in the port range of 1-64000 to T-Pot while allowing access to ports > 64000 only from trusted IPs

（要約：管理ポートを探られないよう、1〜64000番ポートはT-Potへ転送しつつ、64000番より上は信頼できるIPからのみアクセスを許可すること）

っということでVPS事業者（WebARENA）が提供するファイアウォール機能を使って、この切り分けをしています。「おとりに使うポート」と「自分が管理に使うポート」を分けて守り、管理用の経路は自分側の設定（VPSのSSH制限）とVPS事業者側のFWの二段構えにする、というのが肝です。

3. アウトバウンド通信は絞る（踏み台化を防ぐ）

ここはミスって後から気づいたところです。

最初はアウトバウンド（外向き）通信を全開放にしていました。が、これは危ない。ハニーポットは「侵入されること」が前提のサーバなので、乗っ取られた後に、そこを踏み台にして別のサーバを攻撃されるリスクがあるからです。

ハニーポット運用者には、一般的なサーバ管理者よりも高い注意義務が求められる、という考え方があります。これは法的に確立したルールというより、運用者として持っておくべきリスク認識に近いですが、攻撃者が自由に外部へ攻撃できる状態を放置していると、踏み台にされた場合に運用者の責任が問われかねません。

なので今はアウトバウンドをかなり絞っています。(VPSから再構築しました。)

ただ、ここは難しいところで、Cowrie のように「攻撃者が落としてくるマルウェアをダウンロードして観察する」ために、ある程度のアウトバウンド通信が必要なハニーポットもあります。

For some honeypots to reach full functionality (i.e. Cowrie or Log4Pot) outgoing connections are necessary as well, in order for them to download the attacker’s malware.

（要約：CowrieやLog4Potなど、攻撃者のマルウェアをダウンロードするために外向き通信が必要なハニーポットもある）

このあたりは「何を観測したいか」と「踏み台化のリスク」のバランスで、運用しながら調整していくところだと思っています。

4. ログの取り込み設計はちゃんとやる

最後はELK側の話です。

ログの取り込み（Logstashのパイプライン）を、最初ろくに設計せずに作り始めたら、案の定あとからミスに気づいて作り直しになりました。フィールドの抽出ルールや、重複データの扱いを最初に決めておかないと、後で「データがダブってる」「うまく集計できない」といった問題にぶつかります。

ここは急がば回れで、取り込む前にどんなフィールドが欲しいかを決めてから設計するのがおすすめです。

これから始める人へ

ここまでをまとめると、個人でT-Potを運用するときのコツはこんな感じです。

  • ELKは分離する：VPSは軽く保ち、重い分析は手元のPCへ
  • 管理ポートはFWで守る：おとり用ポートと管理用ポートを分ける
  • アウトバウンドは絞る：踏み台化のリスクを意識する
  • リアルタイム性は割り切る：個人の学習用途なら手動取得で十分

当たり前のことばかりかもしれませんが、最初の1台はだいたいどこかでつまずくものです。この記事がその回避に少しでも役立てば。

おわりに

T-Pot を個人で立てると、「攻撃って本当に毎日来るんだ」というのを肌で実感できます。そして実際に何が捕れるのかは、ログを見てのお楽しみです。

一つあるとすれば、「敵を知り」の精神で運用しています。擦り切れるまでいろんな方がおっしゃってる言葉です。知らない方は2分使って「孫子兵法」でググってみてください。

「敵を知り、己を知れば」ということで、多少なりとも自分のせいで不幸になる人は防げると思います。攻撃する人はコントロールできないけど。

少なくとも、私のhoneypotはドメインついてない(Aレコード無い)ので、普通の人間がたどり着くことはない。

つまり、裏を返せば「名前解決できない誰も知るはずがないサーバでも、日/数千件のリクエストは届く」ということです。

このブログでは、ここで構築した環境で実際に観測した記録を 観測記録シリーズ としてまとめています。たとえば、

このあたりを読むと、「立てたあとに何が見えるのか」のイメージがつかめると思います。環境の詳細は このサイトについて にも書いているので、あわせてどうぞ。

T-Pot: Deutsche Telekom Security GmbH / tpotce on GitHub / GPL v3.0