対策・対応の記録

第1章：多層防御の全体像

1つの仕組みだけに頼らず、複数の層で攻撃を止める設計にしています。1つの層が突破されても、次の層で止まるようにするのが狙いです。

• 境界（ファイアウォール）：インターネットとの境界で、明らかに不審な通信・帯域攻撃の類をそもそも中に入れない
• エッジ（リバースプロキシ／TLS終端）：Webサイトへの通信を一元的に受け、証明書管理と基本的なアクセス制御を行う
• アプリケーション層（Webサーバー／メールサーバー）：存在しないファイルへのアクセスや、プロトコルを無視した不正な通信をその場で拒否する
• ログ監視・自動遮断：各サービスのログをリアルタイムに監視し、同一IPからの繰り返し失敗を検知したら自動でアクセス遮断する
• OSレベルの強制アクセス制御：万一アプリケーションが乗っ取られても、OSの権限モデルでできることを最小限に制限する

各要素の詳しい構造は、運用・保守内のFirewalld／Fail2ban／SELinuxの各ページで個別に解説しています。

第2章：上位攻撃への具体的な対応手順

攻撃ランキングで紹介した攻撃のうち、上位のものについて、実際にどのコマンドで確認し、どう対応しているかを具体的に紹介します。皆さんが自分のサーバーで同じことをする際の参考にしてください。

2-1. 機密ファイル総当たり攻撃（.env / .git / wp-config等）への対応

何が起きているか： 攻撃者が、機密情報が入っていそうなファイルパスに次々とアクセスし、実際に読み取れるかを試します。

確認コマンド： アクセスログから該当パターンを抽出します。

sudo tail -n 500 /var/log/httpd/access_log | grep -E "\.env|\.git|wp-config|\.aws|backup\.sql|server\.key"

判定： ステータスコードが404であれば、そのファイルは存在せず実害はありません。もし200が返っているものがあれば、実際に読み取れてしまっている可能性があるため最優先で対応します（第4章の実例参照）。

fail2banの状況確認：

sudo fail2ban-client status apache-404

該当IPが自動的にBANされているかを確認します。緊急で今すぐ遮断したい場合は、自動検知を待たず手動でBANすることもできます。

sudo fail2ban-client set apache-404 banip <IPアドレス>

2-2. 複合型SMTPプロトコル破壊攻撃への対応

何が起きているか： メールサーバーに対し、正規のSMTP手順を無視した接続（挨拶前の送信、非SMTPコマンドの送信等）が行われます。

確認コマンド：

sudo journalctl -u postfix -n 200 | grep -E "PREGREET|NON-SMTP|BARE NEWLINE"

判定： postscreenが接続段階でDISCONNECTしていれば対応不要です。実際にメール本体の配送（smtpdへの接続成功）まで進んでいないかだけ確認します。

2-3. gitディレクトリ公開への対応（実際に使った修正）

確認方法： 自分のサイトに対して、定期的に外部から状態を確認します。

curl -s -o /dev/null -w "%{http_code}\n" https://自分のドメイン/.git/config

200が返れば公開されてしまっている状態、403か404であれば安全です。

実際に使った修正（Apache httpd）： 以下を設定ファイルに追加し、Webサーバーから.gitディレクトリへの一切のアクセスを拒否しました。

<DirectoryMatch "/\.git">
    Require all denied
</DirectoryMatch>

/etc/httpd/conf.d/配下に新規ファイルとして保存し、sudo apachectl configtestで構文確認後、sudo systemctl reload httpdで反映しています。

2-4. fail2banの基本的な考え方（設定はあくまで例です）

fail2banは「同じIPから、一定時間内に、一定回数の失敗があったら遮断する」という3要素（maxretry / findtime / bantime）で動いています。詳しい内部構造は「Fail2banの構造」で解説していますが、イメージとしては次のような設定になります。

[apache-404]
enabled  = true
maxretry = 5     ← 設定例（実際の運用値とは異なります）
findtime = 600   ← 設定例
bantime  = 1800  ← 設定例

日常的には、fail2ban-client status <jail名>でBAN状況を確認する習慣をつけておくと、異常な増加にすぐ気づけます。

第3章：日々の運用ルーティン

攻撃は「一度対策して終わり」ではなく、日々のログ確認とセットで運用しています。

1. メールサーバー・Webサーバー・リバースプロキシの直近ログを毎日確認する
2. いつもと違うアクセスパターン（急増、未知のパス、成功してはいけないはずの応答）がないかを見る
3. 気になる兆候があれば深掘りし、必要であれば追加の対策を検討・実施する
4. 対応した内容は記録に残し、翌日以降の判断材料にする

第4章：実際にあった教訓

運用の中で実際に得た教訓を、一般化して共有します。

4-1. gitでサイトを管理する際の落とし穴

サイトのコンテンツをバージョン管理するためにgitリポジトリ化した際、リポジトリの管理用フォルダがそのままWebサーバーから読み取れる状態になっていたことがあります。日々のログ確認でこれに気づき、即日Webサーバー側の設定で該当フォルダへのアクセスを遮断しました。「バージョン管理を導入する」という前向きな変更が、意図せずセキュリティ上の穴を生むことがある、という教訓です。

4-2. 正常な遅延を異常と誤認しない

メールの受信テストで「すぐに届かない」ことがありましたが、調べてみると、送信元の身元を慎重に確認してから受け入れる、メールサーバー側の正常な仕組みによる一時的な保留でした。何でも「異常」と決めつけず、まず仕組みを理解してから判断することが大切だと再確認しました。

4-3. 何が正規サービスかを見極める

自動遮断の仕組みが、実在する正規のWeb技術調査サービスを一時的にブロックしたことがありました。挙動だけを見て「攻撃」と決めつけず、User-Agentや発信元の情報から実在のサービスかどうかを確認したうえで、対応を判断するようにしています。

4-4. 監視の網羅性を過信しない

ある単一の送信元から、正規のSMTP手順を無視した同一パターンの接続が、一定間隔で非常に長時間にわたり繰り返されたことがありました。1件ごとの接続は毎回サーバー側で正しく遮断されており実害はなかったものの、通常の攻撃ノイズと比べて桁違いの持続時間・回数だったため、日々のログ確認の中で「量」の異常として気づきました。調べたところ、この種の違反パターンは既存の自動遮断ルールの守備範囲に入っておらず、ファイアウォールで当該送信元を直接遮断することで対処しました。

「1件1件は正しく防げているから大丈夫」ではなく、普段と違う量・持続時間のパターンにも目を向けることで気づけた事例です。自動化された防御にも死角はあり得るという前提で、定期的な人の目によるレビューを組み合わせることの大切さを再確認しました。

4-5. 善意の訪問者を誤って締め出さないために

自動遮断の仕組みが、実は攻撃ではなく、iPhone等が裏側で自動的に行う「アイコンファイルの確認」（ホーム画面に追加する際に使う画像を、事前に探しにいく機能）を、繰り返しの不審なアクセスと誤認してBANしてしまったことがありました。

原因を調べると、そのアイコン用のファイルをサイト側に用意していなかったため、iPhoneがごく普通に行う確認が毎回「存在しないファイルへのアクセス」として記録されていました。該当のファイルを用意することで、これ以降は同じ理由での誤BANが起きなくなりました。

「攻撃らしいアクセス」の実態が、実は多くの善意の閲覧者に共通する一般的な仕組みであることもある、という教訓です。似たような「よくあるお約束のファイル」（favicon.ico、robots.txt等）が抜けていないか、定期的に点検することをお勧めします。

4-6. 「量」だけでなく「質」でも判定する

これまでの自動遮断の仕組みは、いずれも「一定時間内に一定回数の失敗が積み重なったら遮断する」という、量に基づく判定でした。この方式は幅広い攻撃に対応できる一方で、機密ファイル総当たり攻撃のように1回のアクセスへの試行数が多いタイプの攻撃では、遮断の閾値に達するまでの間に相当数のパスを探索されてしまう、という弱点がありました。

あらためて見直すと、本サイトのようにコンテンツが静的なページのみで構成されている場合、特定の種類のパス（プログラム実行用のファイル拡張子や、本来存在しないはずの管理画面・設定ファイルへのパス等）へのアクセスは、たとえ1回だけであっても、通常のクローラーや閲覧者では絶対に発生し得ない、悪意が確定的な挙動だと言えます。

そこで、こうした「1回で判定できる」種類のパターンについては、量の積み重ねを待たず即座に遮断する仕組みを別途追加しました。既存の量的な判定と、質的な判定を組み合わせることで、攻撃者が探索を完了する前に、より早い段階で遮断できるようになっています。

第5章：継続的なパッチ適用

ソフトウェアの脆弱性対策として、定期的にシステムのアップデートを行っています。本番稼働中のサーバーを止めずに、段階を分けて慎重に適用する運用にしています。詳しい手順と実践記録は「システムアップデート運用ガイド」にまとめています。