MtGやDMを遊んだことがあるのであれば聞いたことがあるだろう

「カードはルールに勝つ
　(カードの効果とルールが直接矛盾した場合、カードの効果を優先する)」

という大原則。

「カードを2枚引く」

というシンプルなテキストであっても、通常、プレイヤーは1ターンに1枚のみカードを引くと言うルールがありますが、カードにそう書かれていればそのルールを無視した挙動が可能になります。

一見すると乱暴な言葉ですが、実際にはゲームデザイン上もっとも重要な考え方の一つです。

基本ルールは全員共通。しかし、カードには「この場合だけは例外」が書かれています。だからこそ何万種類ものカードが共存できます。

実は、この考え方は ModSecurity にも、そのまま当てはまります。

今回、私がModSecurityに導入している「REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf」について解説します。

REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confとは？

ModSecurityで本格的な防御を行う際、多くの人が「OWASP CRS（Core Rule Set）」という、世界中のセキュリテイ専門家が作った強力な既製ルール集を導入します。

CRSは非常に優秀ですが、何千もの緻密なルールが詰まっているため、上から順にすべてをチェックするとそれなりの処理コスト（CPUやメモリ）がかかります。

また、これは非常にデリケートでガチガチなので

  1. ファイルをアップロードした
  2. コードを書き込んだ
  3. クリックを繰り返した

だけで「こいつは怪しい動きをしている」として、アクセスそのものを遮断する「偽陽性」が発生します。

そこで、膨大なCRSの本体を書き換えることなく

  1. プログラムのコードやコマンドラインなどを投稿するのはOK
  2. だが、それを使った攻撃は許さない
  3. 複雑なスキャンは不要。「悪・即・斬」レベルで不審な攻撃をたたき落とす
  4. 逆に「こいつは面白い動きをするからハニーポットに誘導しよう」

などの「デッキを作るような感覚で」膨大なCRSを制御する方法として用意されているのが、REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf（以下、900番BEFOREルール）です。

設置例

筆者環境

  • ModSecurity 2.9.7
  • Core Rule Set 3.3.5
  • Apache 2.4
  • Ubuntu 24.04

どこに置くか？

筆者環境の場合は

/usr/share/modsecurity-crs/coreruleset/rules配下のREQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confですが、

/home/hoge/script/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

など、自分がメンテナンスしやすい位置にこのファイルの実体を置いておき、ln -sfでシンボリックリンクを張る方が非常に簡単です。というのも、「このデッキ調整」はデリケートな作業なので何回も何十回も調整が必要になります。そのたびに深い階層を掘ってファイルを編集するのは効率的ではありません。

とはいえ、シンボリックファイル is Evil だったりrootアカウントしかないとかいう方はいるので流儀に合わせてください。

ケーススタディ

効果的なカスタム案

筆者が実際に使っている中で最も効果的なルールがこれです。

# IPアドレス直打ちアクセス対策 
SecRule REQUEST_HEADERS:Host "@rx ^[\d.]+(:\d+)?$" \
    "id:10004,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Host header is a numeric IP address (incl port). Blocked immediately.',\
    tag:'application-attack',\
    tag:'PROTOCOL_VIOLATION/INVALID_HREQ'"

# Hostヘッダーが存在しない場合は即ブロック
SecRule &REQUEST_HEADERS:Host "@eq 0" \
    "id:10005,\
    phase:1,\
    deny,\
    status:404,\
    log,\
    msg:'[CUSTOM RULE] Missing Host Header. Blocked immediately.'"
  • id:10004：
    • 正規表現 @rx ^[\d.]+(:\d+)?$ を使い、Hostヘッダーの中身が「数字とドットだけ（または末尾にポート番号）」で構成されているかを判定します。IPアドレス直打ちであれば、その瞬間に合致（マッチ）します。
  • id:10005：
    • 変数の頭に & をつけることで、そのヘッダーの「個数」を数えます。@eq 0（＝0個、つまりHostヘッダーが存在しない）場合にマッチします。
  • phase:1：
    • これが非常に重要です。リクエストの解析が始まった「最速の段階（フェーズ1）」で検査を行います。
  • deny, status:404：
    • 条件にマッチしたら、荷物の中身（Body）を見るまでもなく、即座に通信を拒否し、404エラーを返して追い払います。

カスタム案が拾ったログ

以下、実際に私のサーバにアクセスしたログです。

# 例①：Hostヘッダー自体が存在しない（欠落）
[ security2:error] ModSecurity: Access denied with code 404 (phase 1). ... [file "/usr/share/modsecurity-crs/coreruleset/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf"] [line "72"] [id "10005"] [msg "[CUSTOM RULE] Missing Host Header. Blocked immediately."]

# 例②：Hostヘッダーがドメインではなく「IPアドレス直打ち」
[ security2:error] ModSecurity: Access denied with code 404 (phase 1). ... [file "/usr/share/modsecurity-crs/coreruleset/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf"] [line "63"] [id "10004"] [msg "[CUSTOM RULE] Host header is a numeric IP address (incl port). Blocked immediately."]
sequenceDiagram Note over Crawler: 不正なリクエストを送信<br>(Host: 192.0.2.1) Crawler->>ModSecurity_WAF: HTTP GET / (Host不正) Note over ModSecurity_WAF: phase:1 で瞬時に検知！<br>背後のWebサーバーやアプリには<br>一切パスさせない ModSecurity_WAF-->>Crawler: 404 Not Found (即座に遮断)

という形で、ModSecurityの背後にあるコンテンツに一切触れさせることなく追い払うことができます。

余談：これで追い返して問題は無いのか？

ありません。断言します。なぜなら、ローカル運用ならいざ知らず、ドメインで動くモダンインターネットにおいて

http://203.0.113.6

などと直打ちするケースはほぼありません。なので、IPアドレス直打ちはほぼ確実に「膨大なIPをしらみつぶしに探し回るボット」です。

そして、Webサイトを閲覧するとき、ブラウザとサーバーの間では「データの荷物」がやり取りされています。この荷物は、大きく分けると「ヘッダー（Header）」と「ボディ（Body）」の2つで構成されています。

郵便に例えると、以下のようなイメージです。

  • ヘッダー（Header）： 封筒の表面。「宛先」「差出人」「中身の形式」などが書かれた管理情報。
  • ボディ（Body）： 封筒の中身。「実際のページデータ（HTML）」や「画像」そのもの。

普段目にするWebページは「ボディ」ですが、それを正しく届けて表示するためには、不備のない「ヘッダー（封筒の表面）」を付与するというのがブラウザの挙動です。

900番BEFOREルールである意味

そして、このファイルは「CRSが動く前に対処できる」という、MtGで言う「打ち消し呪文」のようなものとして機能します。

もし、これをRESPONSE-999-EXCLUSION-RULES-AFTER-CRS.confという「最終的に評価するルール」で書いた場合

sequenceDiagram Crawler->>ModSecurity_WAF: HTTP GET / (Host: 192.0.2.1) Note over ModSecurity_WAF: 1.900番BEFORE ルール（何もなし） -> 通過 Note over ModSecurity_WAF: 2. メインCRS審査（数千のルール） Note over ModSecurity_WAF: SQLインジェクションの検査...OK<br>XSSの検査...OK<br>（延々とノーマル審査が続く） Note over ModSecurity_WAF: 3. （AFTERルールに書いた場合） Note over ModSecurity_WAF: ここでようやくルール10004にヒット ModSecurity_WAF-->>Crawler: 404 Not Found (一応遮断はできたが...)

という流れになります。

もしクローラーが超高速で連射してきた場合、この「無駄なフルコンボ審査」のせいでModSecurity自体の処理が追いつかなくなり、サーバーのCPU使用率が100%に張り付いて、一般ユーザーのアクセスが重くなる（あるいは落ちる）という本末転倒な事態が起きます。

このカスタム案の意義

OWASP CRSは非常に優秀です。

SQLインジェクション、XSS、RCEなど、現代的な攻撃に対する膨大な知見が詰め込まれており、何も考えずに導入しても一定以上の防御力を得られます。

しかし、それはあくまで「世界中の誰にでも当てはまる最大公約数」です。

私のサーバーには私のサイト構成があり、私の利用者がおり、私の攻撃ログがあります。

だからこそ

  • このサイトではコードの投稿は許可する
  • このURLへの異常なクロールだけは絶対に許さない
  • この挙動は攻撃ではないので除外する
  • この通信はコンテンツを見る価値すらないので即座に落とす
  • 面白い相手ならハニーポットへ誘導する

という「自分だけのルール」が必要になります。そのための「私のデッキ」が900番BEFOREルールです。

CRS本体を直接編集する必要はありません。

世界中のセキュリティ専門家が更新し続けるルールセットはそのまま利用し、自分の環境だけに必要な判断を、カードを1枚追加するような感覚で差し込めます。

だから冒頭で紹介した

「カードはルールに勝つ」

という考え方が、そのままModSecurityにも当てはまるのです。

CRSという基本ルールがあり、その前に「このサイトではこうする」という例外を定義する。それだけで、自分だけのWAFが出来上がります。

私にとってREQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confは、単なる設定ファイルではありません。

毎日流れてくるログを眺め、

  • 「これは900番で落とせるな」
  • 「このクローラーはハニーポット送りにしよう」
  • 「これはCRSに任せた方がいい」

そんな調整を繰り返しながらデッキをチューニングしていく場所です。Webサイトを運営する人にとって、攻撃ログは鬱陶しいものに見えるかもしれません。

しかし見方を変えれば、それは次の一枚を考えるための対戦ログでもあります。

オリジナルに手を加えない意義

また、この900番BEFOREルールを別ファイルとして管理する最大の理由は、「本家に手を入れない」ことです。

CRSは更新され続けます。

もしCRS本体を書き換えてしまうと、アップデートのたびに差分を確認し、競合を解消し、自分の修正を書き戻す必要があります。

一方、自分のデッキを900番BEFOREだけに閉じ込めておけば、CRSが更新されても自分のカードはそのまま使い続けられます。

新しいサーバーへ移行するときも、自分のデッキを1枚コピーするだけです。デッキは、一度組んで終わりではありません。

  • 新しい攻撃ログを見つけたら1枚差し替え、
  • 不要になったカードは抜き、
  • 新しい環境に合わせて調整していく。

世界中の専門家が作ったルールセットを土台に、自分のサイトで得た対戦ログから一枚ずつカードを選び、デッキを育てていく。それが私にとってのREQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confです。