DoSDetectorの盲点

発覚した問題点（現象）

有名なDoS攻撃対策モジュール『mod_dosdetector』において、ContentTypeを見てdos判別からリクエストを除外する『DoSIgnoreContentType』が今ひとつ想定した通りの動きをしない疑惑がありました。
　そして今回自己検証をしてみた結果、現象の詳細が分かりました。
　DoSIgnoreContentTypeに設定したContentTypeでも、1回リロードすると何故かDoS判定されてしまい、結局全くと言っていいほど動作しなくなってしまうという現象であったようです。

原因

調査をしてもほとんどヒントはありません。皆さん疑問符はありながらも『とりあえず大体動くな＾＾』という適当な認識で使っているようです（うちも実際そうでした）。
　そしてブログ類を漁っていたところ、ようやく以下の一言に行き着きました。それはブログの記事ではなく、ブログの記事に対するコメントで、1年以上返信のなかったものです。

DoSIgnoreContentType って、サーバーがStatus code 304 Not modified の時、Content-type が返ってこないから判定できないのね…。回避策あるのかな…。

正直目を疑いましたが、まさかと思い検証したところ、DoSIgnoreContentTypeをREADMEの通り設定すると確かに200の画像のみチェックから除外され、304のログがどんどんdos_suspect_logに蓄積されました。
　304の画像やJSやCSS＋ページであれば簡単に毎秒10リクエスト以上いきますので、あっという間にDoS攻撃認定されて503落ちしてしまいます。

対策案

HTTPD側での304応答無効化

304はブラウザキャッシュ等をきかせるためにApacheが返しているもので、もちろん強引な手法にはなりますが無効化することは可能です。無効化すれば全てのコンテンツを200で返しますので、全てのリクエストについてContentTypeがApacheの動的モジュールを経由してDoSIgnoreContentTypeの判別を通すことができます。
　しかし、トラフィックやディスクIOが大幅に上昇するため、著しく負荷が上昇します。特にコンテンツ量の多いサイトでは、致命傷です。
　また将来的にキャッシュサーバを使うことになった場合コード304は重要度を帯びることもありますので、これは確実でありつつも最終手段となりそうです。

ページ内読み込みの最適化

そもそも1ページあたりで呼び出す画像・CSS・JSなどが少なければ、DoSIgnoreContentTypeを考慮しなくて済むこともあります。実際、美容がそうです。ユーザビリティも大幅に向上しますしサーバに対するリクエストが減るので負荷軽減にもつながり、いいことづくめです。

じゃあどうする？

• 自分で改修してコンパイルして使う
• スケールアップしてDoS攻撃耐性自体を上げる
  前者にトライしたいのですが時間が・・・。

参考URL

http://blog.neko.me/article/46080289.html
↑これの２つ目のコメントがヒントでした。