攻撃者は「宝探し」のプロだ：OSINTで広がる攻撃対象領域（Attack Surface）の真実
「うちはメインのWebサイトにはWAFを入れているし、主要なポートは閉じているから大丈夫だ」
もし君がそう思っているなら、残念だがその認識の甘さが最も危険なバックドアになる。攻撃者は正面から突破しようとはしない。彼らが最初に行うのは、いわゆる「偵察」フェーズ――OSINT（オープンソース・インテリジェンス）による情報収集だ。
攻撃者は、DNSのゾーン情報、GitHubに誤ってコミットされた設定ファイル、あるいは数年前に開発者が放置した「検証用サブドメイン」を執拗に探している。今回は、君たちのシステムがどのように「丸裸」にされているのか、そしてそれをどう防ぐべきか、現場の視点から解説する。
—
1. なぜ「サブドメイン」が突破口になるのか
開発者は、検証環境や社内ツールに dev.example.com や test-api.example.com といったサブドメインを割り当てがちだ。これらは往々にして本番環境よりもセキュリティが甘い。
攻撃者は subfinder や amass といったツールを使い、ドメインに関連するすべてのFQDNを数分で洗い出す。さらに、GitHubの検索機能を使って example.com を含むコードを掘り返す。そこに AWS_ACCESS_KEY や DB_PASSWORD がハードコードされていたら？ ゲームオーバーだ。
攻撃者が見ている「盲点」
- 検証用環境の放置: 脆弱性パッチが当たっていない古いWordPressやLaravelが動いている。
- Gitのメタデータ:
.gitディレクトリが公開されており、ソースコードが丸ごとダウンロード可能。 - 隠された管理画面:
admin.example.comや/configといったパスが推測され、ブルートフォースの対象になる。
—
2. 現場で使える「防御の鉄則」
OSINTによる攻撃を無効化するには、「情報を出さない」ことと「境界を厳格にする」ことが全てだ。
実践1：GitHubへの漏洩を防ぐ（pre-commit フック）
コードをプッシュする前に、機密情報が含まれていないか自動チェックする仕組みを導入せよ。gitleaks を使うのが業界標準だ。
# .pre-commit-config.yaml の設定例
# ローカルでコミットする前に機密情報を検知する
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks実践2：Nginxによる .git 隠蔽
誤って公開ディレクトリに .git を置いてしまっても、Nginx側で拒否設定を入れておけば被害を最小限に抑えられる。
# /etc/nginx/conf.d/security.conf
# .git ディレクトリへのアクセスを全拒否する
location ~ /\.git {
deny all;
access_log off;
log_not_found off;
}
# 隠しファイル（.envなど）へのアクセスも防ぐ
location ~ /\.(?!well-known).* {
deny all;
}実践3：環境変数の適切な分離（PHP/Node.jsでの鉄則）
絶対にコード内に認証情報を書くな。getenv() や process.env を活用し、本番環境のサーバー内にはファイルとして置かず、クラウドのシークレット管理サービス（AWS Secrets ManagerやHashiCorp Vault）から注入する運用に切り替えること。
// config.php - 悪い例
$db_pass = "super_secret_password"; // 絶対にダメ！
// config.php - 良い例
$db_pass = getenv('DB_PASSWORD'); // 環境変数から読み取る
if (!$db_pass) {
throw new Exception("環境変数が設定されていません");
}—
3. 継続的な「監視」というマインドセット
ペネトレーションテストは「一度やって終わり」ではない。OSINTは毎日更新される。攻撃者は君たちのドメインが新しいIPアドレスを指した瞬間、あるいは新しいクラウドストレージ（S3バケット等）を公開した瞬間にそれを検知している。
明日からやるべきこと:
1. 定期的なサブドメインスキャン: 自分の管理下にあるドメインに対して、定期的に subfinder を実行し、意図しないドメインが生えていないか確認せよ。
2. GitHubの監視: GitHubの通知設定を活用し、自社のドメイン名が含まれるコードが公開されたら即座にアラートが飛ぶようにせよ。
3. 不要な資産の廃棄: 使わなくなった検証環境は、サブドメインのレコードごと即座に削除せよ。
最後に：セキュリティは「泥臭い作業」の積み重ねだ
洗練されたハッキング手法は映画の中だけではない。現実のインシデントは、常に「設定ミス」「放置された検証環境」「漏洩した認証情報」といった些細なミスから始まる。
君たちが書く一行のコード、設定する一つのNginxファイルが、会社の資産を守る最後の砦になる。セキュリティを「コスト」ではなく「プロダクトの信頼を支える基盤」として捉え、妥協なき実装を続けてほしい。
何か疑問があればいつでも聞け。現場の泥臭い戦い方は、まだまだいくらでも教えてやる。
コメント