自前でFortinet風VPNハニーポットを立ててみた：VPS・Cloudflare Tunnel・攻撃分析APIまで

セキュリティ検証
スポンサーリンク

はじめに

これまでT-Potを使ったハニーポット運用や、Elasticsearch / VirusTotal連携による分析自動化を試してきました。

T-Potは非常に強力で、CowrieやDionaeaなど複数のハニーポットをまとめて扱えるのが魅力です。一方で、今回は少し違う方向の検証として、自前でVPN装置風の低対話ハニーポットを立てることにしました。

自前でハニーポットを立てるのは、T-Potのような既存基盤を使うより手間がかかります。しかし、その分だけ次のような調整ができます。

  • どの製品に見せるかを細かく制御できる
  • HTTPレスポンス、Cookie、証明書、404の返し方まで寄せられる
  • 自分が見たいログ形式にできる
  • Cloudflare Tunnel経由で分析画面だけ安全に公開できる
  • 攻撃者の行動を、自分の観点で分類できる

今回作ったのは、Fortinet FortiGate SSL-VPN風に見える低対話型のVPNデコイです。

公開しているのは偽装ログイン画面だけで、実際のVPN機能やコマンド実行機能はありません。目的は侵入させることではなく、インターネット上のスキャナや攻撃者が、公開VPN機器に対してどのようなアクセスをしてくるのかを観測することです。

なぜVPN装置風にしたのか

2020年代後半の攻撃トレンドを見ると、境界防御機器、特にVPN、ファイアウォール、リモートアクセス装置は継続的に狙われています。

攻撃者にとって、VPN装置は魅力的です。侵害できれば、そこから内部ネットワークへ入る足がかりになるためです。

今回のデコイでは、以下のような製品を模倣できるようにしました。

  • Ivanti Connect Secure
  • Fortinet FortiGate SSL-VPN
  • Palo Alto GlobalProtect
  • Citrix NetScaler

ただし、1台のVPSで複数製品を同時に見せるのは不自然です。

同じIPアドレスの80/443番で、IvantiにもFortinetにもPalo Altoにも見えるという状態は、スキャナから見ればかなりハニーポット臭くなります。

そのため今回は、1台だけ運用する前提で Fortinet単一機器として振る舞う構成にしました。

DECOY_PRIMARY_VENDOR=fortinet
STRICT_SINGLE_VENDOR=1

STRICT_SINGLE_VENDOR=1 にすると、主ベンダ以外の探索パスは基本的に404へ倒します。収集網羅性は少し落ちますが、「単一のFortinet機器らしさ」を優先する判断です。

全体構成

構成は次のようにしました。

Internet
  |
  | 80 / 443
  v
Xserver VPS
  |
  +-- edge        OpenResty / TLS終端 / 80,443公開
  |
  +-- vpn-decoy   Flask / 偽装VPNログイン画面 / JSONLログ出力
  |
  +-- api         集計ダッシュボード / JSON API / 外部ポート非公開
  |
  +-- cloudflared Cloudflare Tunnel / stats用のみ外部公開

ハニーポット本体はVPSの80/443で公開します。

一方、分析画面はVPSの公開ポートには出さず、Cloudflare Tunnel + Cloudflare Accessで stats.example.com のような管理用URLだけ公開します。

ポイントは、ハニーポット本体にはCloudflare Proxyを被せないことです。

Cloudflareのオレンジ雲を使うと、送信元IP、TLS証明書、TLS指紋、HTTP挙動がCloudflare化します。攻撃収集用のデコイとしては、Fortinetらしさが落ちます。

そのため、役割を分けます。

ハニーポット本体:
  162.43.51.48:80/443
  または vpn.example.com Aレコード DNS only

分析画面:
  stats.example.com
  Cloudflare Tunnel + Access認証

VPSの準備

今回はXserver VPSを使いました。

スペックは次の構成です。

OS: Ubuntu 24.04 LTS
RAM: 2GB
CPU: 3Core
SSD: 50GB

1GBでも動く可能性はありますが、Docker buildやログ保存を考えると2GBの方が楽です。

OCI Always Freeも候補にしましたが、Ampere A1の無料枠は在庫不足で作れないことが多く、今回はXserver VPSに切り替えました。

SSHのハーデニング

まずSSHは鍵認証だけにします。

VPSの外側パケットフィルタでは、最初に22番を自分のIPだけ許可しました。

SSHで入れることを確認した後、サーバー側でパスワード認証を無効化します。

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PubkeyAuthentication .*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin .*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config

sshd -t
systemctl reload ssh

秘密鍵はローカルに置きますが、Gitには絶対に入れません。

*.pem
*.key
id_*

鍵ファイルの権限も絞ります。

chmod 600 ssh.pem

Dockerの導入

Ubuntu 24.04環境で docker-compose-plugin が標準aptから見つからなかったため、Docker公式リポジトリを追加しました。

apt update
apt install -y ca-certificates curl gnupg git jq logrotate cron

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu noble stable" \
  > /etc/apt/sources.list.d/docker.list

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
systemctl enable --now docker

確認します。

docker --version
docker compose version

アプリの配置

GitHubリポジトリがprivateの場合、VPS上にPersonal Access Tokenを残すのは避けたいところです。

今回は手元からSSH経由で転送しました。

ssh root@<VPS_IP> 'mkdir -p /opt/vpn-decoy'

tar --exclude=.git --exclude=.env --exclude=logs --exclude='*.jsonl' -czf - . \
  | ssh root@<VPS_IP> 'tar -xzf - -C /opt/vpn-decoy'

VPS上で設定ファイルを作ります。

cd /opt/vpn-decoy
cp .env.example .env

Fortinet単一機器として動かします。

sed -i 's/^DECOY_PRIMARY_VENDOR=.*/DECOY_PRIMARY_VENDOR=fortinet/' .env

ログディレクトリはコンテナ内の非rootユーザーが書き込めるようにします。

mkdir -p logs
chown -R 10001:10001 logs

起動します。

docker compose up -d --build vpn-decoy edge api

確認します。

docker compose ps
curl -I http://127.0.0.1/
curl -k -I https://127.0.0.1/

外部からも確認します。

curl -I http://<VPS_IP>/
curl -k -I https://<VPS_IP>/

Fortinetとして動いていれば、/ は /remote/login?lang=en へ302されます。

HTTP/2 302
location: /remote/login?lang=en
set-cookie: SVPNNETWORKCOOKIE=...

ログイン画面は次のURLで200になります。

https://<VPS_IP>/remote/login?lang=en

自己署名証明書について

ブラウザで見ると証明書エラーが出ます。

これは意図通りです。

Fortinet風に自己署名証明書を生成しています。

CN=FGT60FTK00000000
O=Fortinet
OU=FortiGate
emailAddress=support@fortinet.com

curl でも -k なしでは失敗します。

curl: (60) SSL certificate problem: self signed certificate

実機FortiGateでも自己署名証明書のまま運用されているケースはあるため、ハニーポットとしては許容範囲と判断しました。

外向き通信の遮断

ハニーポットで重要なのは、踏み台化リスクを抑えることです。

このデコイはコマンド実行をしない低対話型ですが、念のためデコイ用コンテナの新規アウトバウンドを遮断します。

注意点として、Dockerコンテナの通信はホストの OUTPUT ではなく、FORWARD / DOCKER-USER を通ります。

そのため、DOCKER-USER にルールを入れます。

ip route get 1.1.1.1

外向きインターフェイスが ens3 なら、次のようにします。

iptables -I DOCKER-USER -s 172.31.10.0/24 -o ens3 -m conntrack --ctstate NEW -j DROP

172.31.10.0/24 はデコイ用のcaptureネットワークです。

一方、Cloudflare Tunnel用の cloudflared は別のmgmtネットワークに置いているため、Cloudflareへの外向き通信は維持します。

systemdで永続化しました。

cat > /usr/local/sbin/vpn-decoy-egress-lockdown.sh <<'EOF'
#!/bin/sh
set -eu
EXT="$(ip route get 1.1.1.1 | awk '{for (i=1;i<=NF;i++) if ($i=="dev") {print $(i+1); exit}}')"
[ -n "$EXT" ]
iptables -C DOCKER-USER -s 172.31.10.0/24 -o "$EXT" -m conntrack --ctstate NEW -j DROP 2>/dev/null \
  || iptables -I DOCKER-USER -s 172.31.10.0/24 -o "$EXT" -m conntrack --ctstate NEW -j DROP
EOF

chmod +x /usr/local/sbin/vpn-decoy-egress-lockdown.sh

cat > /etc/systemd/system/vpn-decoy-egress-lockdown.service <<'EOF'
[Unit]
Description=Block new outbound traffic from vpn-decoy capture network
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/vpn-decoy-egress-lockdown.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now vpn-decoy-egress-lockdown.service

確認します。

iptables -S DOCKER-USER

ログの確認

ログはJSONL形式です。

/opt/vpn-decoy/logs/events.jsonl

確認例です。

tail -f /opt/vpn-decoy/logs/events.jsonl | jq .

送信元IPランキングを見るなら次のようにします。

jq -r '.src_ip' /opt/vpn-decoy/logs/events.jsonl | sort | uniq -c | sort -nr | head

アクセスパスランキングです。

jq -r '.path' /opt/vpn-decoy/logs/events.jsonl | sort | uniq -c | sort -nr | head

攻撃シグネチャに一致したものだけを見る場合です。

jq 'select(.is_exploit_attempt == true)' /opt/vpn-decoy/logs/events.jsonl

ログローテーションも設定しています。

hourly
maxsize 500M
rotate 168
gzip
copytruncate

ローテ済みログも集計対象にしています。

Cloudflare Tunnelで分析画面を公開する

分析画面はVPSのポートとしては公開しません。

Cloudflare Tunnelで stats.secsitex.com のようなURLを作り、Cloudflare Accessで自分だけ入れるようにします。

Cloudflare Zero TrustでTunnelを作成し、Docker connectorを選びます。

VPS上の .env にTunnel tokenを入れます。

cd /opt/vpn-decoy
nano .env

TUNNEL_TOKEN=...

起動します。

docker compose up -d cloudflared
docker compose logs --tail=80 cloudflared

Cloudflare側でTunnelがHealthyになったら、Published application routeを追加します。

Hostname: stats.secsitex.com
Service:  http://api:8090

ここで重要なのは、stats 用にAレコードを作らないことです。

Tunnel routeを追加すると、Cloudflareが自動で次のようなCNAMEを作ります。

stats.secsitex.com CNAME <tunnel-id>.cfargotunnel.com

一方、ハニーポット本体にドメインを付ける場合はAレコードを使います。

vpn.secsitex.com A <VPS_IP> DNS only

オレンジ雲のProxyは使いません。

Cloudflare Accessで認証する

分析画面はログや送信元IPを含むため、公開しっぱなしにしません。

Cloudflare Accessで自分のメールアドレスだけ許可します。

設定例です。

Application domain: stats.secsitex.com
Action: Allow
Include: Emails
Value: 自分のメールアドレス
Session duration: 24 hours

設定後、未認証でアクセスするとCloudflare Accessのログイン画面へ302されます。

https://stats.secsitex.com/

メールOTPが届かない場合は、Zero TrustのAuthentication設定でOne-time PINが有効か確認します。

Google認証を追加して、同じGmailアドレスを許可する構成でも問題ありません。

分析画面で見えるもの

分析画面では、単なる件数だけでなく、攻撃者の行動仮説まで出すようにしました。

表示項目は次の通りです。

  • 総イベント
  • 外部イベント
  • ユニーク外部IP
  • OASTドメイン
  • アクター仮説
  • 判定確度
  • アクセス意図分類
  • CVEランキング
  • 送信元IPランキング
  • パスランキング
  • HTTPメソッド
  • 応答種別
  • User-Agent
  • TLSバージョン
  • IP別プロファイル
  • 直近イベント

APIも用意しています。

GET /summary
GET /assessment
GET /ips
GET /ip?address=<IP>
GET /healthz

たとえば /assessment では、全体の仮説分類が返ります。

{
  "assessment": {
    "stages": [
      {"key": "手動確認またはブラウザ型確認", "count": 9},
      {"key": "VPN/エッジ機器の偵察", "count": 5},
      {"key": "エクスプロイト試行/配送", "count": 3}
    ]
  }
}

IP単位の詳細も見られます。

GET /ip?address=172.174.165.231

返ってくる内容には、以下が含まれます。

  • 件数
  • ユニークパス数
  • 最多パス
  • User-Agent
  • アクセス分類
  • 判定ステージ
  • 判定根拠
  • HTTPメソッド分布
  • 応答種別分布

攻撃者の行動をどう分類するか

今回の分析では、攻撃者の意図を断定するのではなく、観測ログから仮説を立てる形にしています。

分類は次のようにしました。

Fortinet表層スキャン
  / から /remote/login?lang=en への導線確認、favicon取得など。
  製品識別や広域スキャンの可能性。

VPN/エッジ機器の偵察
  /SDK/webLanguage, /remote/fgt_lang, /api/auth/validate-sso など。
  既知のVPN/エッジ機器パスを探している可能性。

広域スキャナ/認証情報探索
  /.env, /.git/config, wp-config.php, .aws/credentials など。
  一般的なWebサーバー向けの認証情報探索。

Fortinetログイン試行/手動確認
  /remote/login へのPOSTやブラウザUser-Agent。
  人間の確認、ブラウザ型ボット、認証試行の可能性。

エクスプロイト試行/配送
  CVE署名一致、非ログインPOST、パストラバーサル、OASTドメイン、ペイロード付きリクエスト。

判定確度は high / medium / low にしています。

ただし、これはあくまでヒューリスティックです。ログだけで「人間が手で狙ってきた」と断定することはできません。

たとえば、ブラウザUser-Agentで /remote/login にアクセスしてきた場合、人間の可能性もありますが、ブラウザ風User-Agentを使う自動化ツールの可能性もあります。

逆に、短時間に多数のパスを探索し、.env や .git/config を見に来るものは、広域スキャナや認証情報探索の可能性が高いと見ます。

実際に見えたアクセス

立ち上げ後、短時間でアクセスが来ました。

代表的には次のようなパスです。

/
/remote/login?lang=en
/SDK/webLanguage
/.env
/.git/config
/wp-config.php
/.aws/credentials
/manager/html

Fortinetのログイン画面を見に来るものもあれば、WordPressやGit、AWS credentialsのような一般的なWebスキャンも混ざります。

つまり、VPN風に見せても、インターネット上の広域スキャナはかなり雑にいろいろなパスを投げてきます。

これはT-Potでもよく見る傾向ですが、自前で作ると「どの応答に対して何が来たか」がかなり見やすくなります。

自前ハニーポットの良いところ

T-Potと比べると、自前ハニーポットは機能数では劣ります。

しかし、今回やってみて、自前には自前の良さがあると感じました。

  • 特定テーマに絞れる
  • 偽装の作法を細かく調整できる
  • ログ形式を自分で決められる
  • 低スペックVPSで動かせる
  • 分析APIを自分の仮説に合わせて作れる
  • Cloudflare Tunnelで管理画面だけ安全に出せる

特に、「攻撃者が何を見て、どこで次の行動に移ったのか」を見るには、自分でログ設計できるのが大きいです。

注意点

ハニーポットは、意図的に攻撃を集める仕組みです。

運用するなら、最低限以下は必要です。

  • 本番ネットワークから分離する
  • SSHは鍵認証にする
  • 管理ポートは自分のIPだけ許可する
  • デコイコンテナの外向き通信を遮断する
  • ログローテーションを入れる
  • 分析画面は認証で保護する
  • Cloudflare Proxyをハニーポット本体に被せない

また、ログには送信元IPやUser-Agentが含まれます。記事やレポートで共有する場合は、個人情報や法的な扱いに注意が必要です。

まとめ

今回は、自前でFortinet風VPNハニーポットを立てました。

最終的な構成は次の通りです。

Xserver VPS
Ubuntu 24.04 LTS
Docker Compose
Fortinet SSL-VPN風デコイ
Cloudflare Tunnel
Cloudflare Access
自前分析API

T-Potのような総合ハニーポット基盤も便利ですが、特定の攻撃面を深く見るなら、自前で小さく作るのもかなり有効です。

特に今回は、VPN装置風の表層、自己署名証明書、Cookie、ログイン導線、404応答、Cloudflare Tunnelによる分析画面保護まで、一通り自分で制御できました。

今後は、実際に集まったログをもとに、Fortinet系の探索パターンや、広域スキャナと手動確認っぽいアクセスの違いをもう少し深掘りしていきたいと思います。

スポンサーリンク

コメント

タイトルとURLをコピーしました