
OSINT流出防御のためのCloudflare Zero Trustの導入
概要
Cloudflare Proxyを使用していたが、CensysやShodanなどのOSINT(Open Source Intelligence)検索エンジンにOrigin IPとポート情報が露出する問題があった。
原因を確認し、Originへの直接アクセスの遮断、管理ポートの非公開化、Cloudflare Tunnel基盤のZTNAまでを構築した。
問題状況の分析
Cloudflareを通じてサービスを運営中であったが、OSINT検索エンジンでProxy IPではなくOrigin IPが確認された。
原因分析
サーバーのIPが露出した原因は以下の通りである。
- TLS証明書の露出
- CensysなどのスキャナーはインターネットのPublic IPを継続的にスキャンする。
- Origin IPの443ポートに直接接続した際、Nginxが実際のサービス証明書を返却していた。
- 証明書のSANなどを通じて、該当IPとドメインを関連付けることができた。
- Inboundファイアウォールポリシーの不備(80、443ポートのファイアウォール設定を行っていなかったため、プロキシを経由しない接続が可能だった)
Nginxのセキュリティ強化
IPベースの直接接続時に不要に実際の証明書を返却しないよう設定する。
SSL Handshake拒否の設定
ssl_reject_handshakeはNginx 1.19.4以上でサポートされている。
まずバージョンを確認する。
File: /etc/nginx/sites-available/default
この設定はDefault Serverに入ってくるTLS Handshakeを拒否するための用途である。
攻撃者が実際のドメインをSNIとして指定した場合、正常なServer Blockが選択される可能性があるため、これだけでOriginへのアクセスを防ぐことはできない。
ファイアウォールポリシーの変更
Inbound Access ListをCloudflare IP帯域の変更に備えて自動的に更新する。
File: cloudflare_ip_update.sh
スクリプトのエラーやその他のやむを得ない理由によりサーバーにアクセスできなくなる問題が発生する可能性があるため、22番SSHポートはインスタンス管理ダッシュボードから直接管理することを推奨する。
最近はキャラクターの洗濯ではなくコンピューターの洗濯もします

@Binci
Public IPの入れ替え
既存のPublic IPを返却し、新しいEphemeral IPを割り当てる。
SSH Host Keyの再生成
実際のキー流出がない場合、必ず行わなければならない作業ではないが、Fingerprintingを防ぐために変更した。
Zero Trust Network Access
これからはPublic Internetに直接露出させず、Cloudflare Tunnel経由でアクセスする。
cloudflaredのインストール

Cloudflare One DashboardからTunnelを作成し、Tokenを発行してもらう。
インストール後、確認する。
Split TunnelおよびPrivate Networkの構成

まずサーバーのIPを確認する。
例:
Private IPv4帯域は以下の通りである。
Private IP帯域
10.0.0.0/8172.16.0.0/12192.168.0.0/16
Team & Resources/Devices > Devices > Device profiles > Profile > Split Tunnels

アクセスしようとするPrivate Network帯域がExcludeに含まれている場合、該当範囲を調整する。

Networks/Routes > Routes > CIDR Routes
Private Networkを追加する。

アクセス
Cloudflare One Agent (WARP Client)をインストール後、構成時に使用したTeam Domainにログインする。
