NGINXでWAFを作る

NGINXを利用してWAFを作る。

WAFとは Web Application Firewallの略であり。Web Serverに対する HTTP レイヤからの攻撃を観測・遮断する機能を持つものである。

一般にWAFには、遮断モードと観測モードがある。

• 遮断モード : 攻撃を検出したら遮断する
• 観測モード : モニターモードなどともいう。攻撃を検出しても記録するだけ

WAFやIPSは、その挙動から、Proxy-WAFとTransparent-WAF(透過WAF)がある。

• Proxy-WAF : Proxy Serverのように、HTTP/TCP 通信を、一度WAFで終端し、WAFからバックエンドのServerにリクエストする。
• Transparent-WAF : Bridgeのように、通信経路中に存在を見せず、TCP的には透過しているように見せる

WAFの攻撃検知方法としては、Signature型とAnomaly型がある。

• Signature型 : 攻撃検出に(正規表現などを利用した)Signatureを利用するもの。Signatureがない攻撃は検出できない
  • Signatureが命であるため、常にSignatureのメンテナンスが必要
  • 無料で利用できるSignatureとして、OWASPのCRS(Core Rule Set)がある
• Anomaly型 : 攻撃検出に、通信の振る舞いを見るもの。初期の段階で通信パターンの学習が必要

NGINXで実装可能なWAFは、mod_securityによるものがSignature型、NAXIによるものがAnomaly型といえる。

一般に、Security保護系のシステムは、定常的な運用と定常的な保守が必要となる。特にSignature型WAFであれば、適正なSignatureを維持し、できる限り最新の情報に更新されていることが望ましい。

したがって、WAF(に限らないが)の利用は「設置すればOK」のような考えではむしろ問題が大きくなることがある。例えば、Signatureの更新もせず、logの確認もしていない状況では、自サイトに誰かが攻撃しているのか、どんな攻撃をしているのかが把握できず、古い、比較的一般化している攻撃は防げても、新しい攻撃には対応できないなどの状況になりやすいからである。

以上より、本番環境へのWAFの導入にあたっては、

1. 外部業者のサービスを利用するか、自らが運用するかを考える
2. 自らが運用する場合、本当に運用できるか？、log等はちゃんと分析可能か？などを十分に考える
3. 攻撃者は、弱点を一箇所見つければそれで良いが、防御者は全体守らなければならないので、常に防御側が不利な戦いを強いられる。その状況で、どこまで対処が可能なのか？を十分に考える
4. 新しい攻撃などをある程度常に追いかけることができるか？その攻撃への対策を自らで行えるか？を考える
5. 自らが利用している防御システムの特性を把握し、安全性だけでなく可用性や完全性も考慮に入れたシステム全体を考える

ことが重要となる。

本記事でNGINX + mod_security3を導入する場合、OWASP CRSは、「一般的な攻撃」のSignatureは提供するが、最新の攻撃や比較的特殊な攻撃には対処できない。したがって。その種の攻撃に対する対策をどうするのかの検討は必要になる。

以上より、筆者のオススメは、外部に攻撃を仕掛けないようにする程度の隔離環境を構築した上で、 学習用 としてmod_security環境+OWSP CRSやNAXIを利用しつつ、実サービス環境には「 Security事業者 」のサービスを導入することである。これによって、

• 事業者に対して必要な情報を正しく伝えられるようになる
• 何かあった場合にクレームを正しく入れられる
• 事業者からの情報を正しく理解できるようになる

というメリットもある。