オープンソースWAF「ModSecurity」で学ぶサーバーの防御

TOUCH THE SECURITY Powered by Security Service G

ナレッジ

2017.10.01

このページをご覧の皆さんであれば、クロスサイトスクリプティング、SQLインジェクション、セッションハイジャック、ディレクトリトラバーサル等々の攻撃手法を耳にする事も多いのではないでしょうか。

もし、攻撃を可能とする脆弱性が自社のWEBアプリケーションで発見された場合、ソースの修正やアップデートといった根本対処を施す必要があります。しかし、何らかの理由で直ぐに対処を施す事が出来ない場合、「応急処置」として有効に作用するのが、WEBアプリケーションファイアーウォール（WAF）です。

今回は、このWAFという装置を中心に、サーバーに対する多重防御の概念を学びつつ、ハンズオンとしてTrustwave社がオープンソースとして提供するホスト型WAF「ModSecurity」を、ご自身の検証環境で実際に動作させてみましょう。

WAFを知ろう
適材適所に配置されるセキュリティ機器
WAFを使ってみよう
まとめ　桶の理論（ドべネックの桶）に例えられるセキュリティ

WAFを知ろう

1.WAF（Web Application Firewall）とは

WAFは、一定の検知パターン（シグネチャ）にもとづいて、Webアプリケーションへの悪意の通信を検出・遮断する、まさにWEBアプリケーションの為のファイヤーウォールです。

2.WAFの種類と機能

WAFには以下のような種類があります。システムの特性、規模や予算、運用方法といった要素が総合的に判断された後、導入されます。

クラウド型

WAFの機能がSaaSとして提供されるもの。

メリット例	・導入にかかるコストが低い。・管理者の運用負荷が小さい。
デメリット例	・細かな設定ができない場合がある。・長期的にはコストが割高になる場合もある。

アプライアンス型

専用の装置として、ネットワークに物理的に組み込まれるもの。

メリット例	・自社の状況に応じて、きめ細かい設定が可能。・一台で複数のWebサーバーを保護できる為、対象が多い場合はコスト的に有利。
デメリット例	・導入における作業（ネットワーク構成の変更など）。・管理対象のハードウェアが増える。

ホスト型

Webサーバーにソフトウェアとして組み込むもの。（ModSecurityはこのタイプに該当）。小規模のWebサイトやアプリケーションに向く。

メリット例	・ネットワーク機器が増えない。
デメリット例	・Webサーバーの台数に比例して導入する必要があり、運用の負担が大きい。・パフォーマンスがWebサーバーの環境に依存する。

3.WAFが有効な状況

次に、WAFがどのような状況で有効に機能するのか、IPAの公開する「Web Application Firewall 読本改訂第2版」を例に見てみましょう。

・直接管理できないウェブアプリケーションに攻撃対策を実施したい
・開発者にウェブアプリケーションの改修を依頼できない
・改修できないウェブアプリケーションに脆弱性が発見された
・ウェブアプリケーションへの攻撃をすぐに防御する必要がある

出典：情報処理推進機構（IPA）Web Application Firewall 読本改訂第2版
https://www.ipa.go.jp/files/000017312.pdf

近年、情報セキュリティの世界では「多層防御」という概念がキーワードとなっており、WAFをはじめとするセキュリティアプライアンスへのニーズは益々高まっています。また、クレジットカード情報の取扱いにおけるセキュリティ基準「PCI-DSS」においても、WAFの導入は必須条件として明示されています。

4.WAFの設置ポイント

WAFを導入しようとした場合、どのような構成で設置すべきか、IPAの主催する情報処理安全確保支援士（旧：情報セキュリティスペシャリスト）の問題を基に考えてみましょう。

問：下の図のような構成と通信サービスのシステムにおいて, Webアプリケーションの脆弱性対策としてネットワークのパケットをキャプチャしてWAFによる検査を行うとき、WAFの設置場所として最も適切な箇所はa～dのうちどこか。ここで、WAFには通信を暗号化したり、復号したりする機能はないものとする。

ここでの正解はウの「c」です。
正解が「ｃ」である根拠と解説は以下になります。

まず「d」ですが、Webサーバーを守るはずのWAFがWebサーバーよりも後ろにあっては意味がないことから、除外されます。

図からは、通信がHTTPSで暗号化されている事がうかがい知れます。問題の中の条件指定で、「WAFは通信を暗号化したり、復号したりする機能はない」とあります。この条件指定から暗号化された状態になる「a」と「b」ではその内容を解析する事ができません。

この問題のケースでは、SSLアクセラレータによってHTTPリクエストが複合化され、サーバーからのHTTPレスポンスについても暗号化される前の状態にある「c」が正解となります。

適材適所に配置されるセキュリティ機器

次は、エンジニアの方であればお馴染みの「OSI参照モデル」のおさらいをしながら、WAFをはじめとするその他のセキュリティ機器について、これらの関係性を考えてみます。

OSI参照モデル

第1層（L1）	物理層
第2層（L2）	データリンク層
第3層（L3）	ネットワーク層
第4層（L4）	トランスポート層
第5層（L5）	セッション層
第6層（L6）	プレゼンテーション層
第7層（L7）	アプリケーション層

これらのレイヤーを踏まえ、セキュリティ機器はネットワークの経路上に適材適所に導入されます。下記の表はOSI参照モデル毎に、それぞれの製品が保護対象とするレイヤーの対比表です。

主な想定レイヤー	特色、主な防御対象
L3～L4 ファイヤーウォール	複数のネットワークセグメントの間を、ACL（Access Control　List）に基き、IPやポート番号といった単位でパケットの破棄・転送を行います。
L3～L7 IPS、IDS	FWの守備範囲であるL3～L4に対する脅威への防御に加え、更に上位層に相当する通信の中身を解析。不正な通信を遮断します。主にOS、ミドルウェアなどへの防御を軸とする機器です。尚、不正とみなした通信を遮断するべく、経路上インラインで設置されたものがIPS,であり、（例え同製品であっても）不正通信の検出だけを目的として、パラレルな経路上から通信を”覗き見”すべくプロミスキャスモードで配置された場合、IDSと称されます。
L6～L7以上 WAF	WEBアプリケーションに対する攻撃の検知・遮断が主な守備範囲となります。機器の保持する攻撃検知パターンとしては、IPSと重複する場合もありますが、よりWEBアプリケーションに特化しており、自身がリバースプロキシとして動作する事で暗号通信を複合し解析可能である等の特性を持ち併せています。

WAFを使ってみよう

1.ModSecurityとCore Rule Set（CRS）

WAFの役割が見えてみたことろで、いよいよハンズオンです。「ModSecurity」は、Trustwave社よりOSSとして提供されるホスト型のWAFです。inuxサーバーにインストールする事で、Apacheのモジュールとして稼働します。

尚、「ModSecurity」は、攻撃パターンのルール集「Core Rule Set」と組み合わせて使用する事により、その効力を発揮します。こちらはウェブアプリケーションのセキュリティ向上を目的として組織された、国際的なオープンコミュニティ「OWASP」が作成、2017年6月の執筆時点においてはver.3へとアップデートされています。

ModSecurity、及びCore Rule Setの情報
http://modsecurity.org/

2.ModSecurityの設定

先ずはインストールに関して。インストール先をCentOSとした場合、yumコマンドでのインストールが可能ですが、EPELのリポジトリを追加する必要がある点にご留意下さい。

# yum install mod_security mod_security_crs

ModSecurityとCore Rule Setのインストール後は、apacheを再起動します。

# service httpd restart

ModSecurityの設定ファイルを編集します。先ずは、遮断のアクションを伴わず、どのようなリクエストに対してルールが反応するのか、経過観察（※）を行うべく、”検知のみ”の設定としてみます。

(※)……WAFの導入については、正しい通信に過剰に反応したり（false positive）、不正な通信を通過させている（false negative）ルールが存在しないか、実務においても経過観察期間を設けるのが一般的です。

# vi /etc/httpd/conf.d/mod_security.conf

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
# SecRuleEngine On ← コメントアウト
SecRuleEngine DetectionOnly ← 行を追加する

3.コアルールセット

Core Rule Setのファイル群を確認してみましょう。/etc/httpd/modsecurity.d/activated_rules/へ移動すると、XSS、SQL Injectionといったイリーガルなアクティビティ毎に、ルールセットが別れている事が確認できます。

#ls
modsecurity_35_bad_robots.data
modsecurity_35_scanners.data
modsecurity_40_generic_attacks.data
modsecurity_41_sql_injection_attacks.data
modsecurity_50_outbound.data
modsecurity_50_outbound_malware.data
modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_23_request_limits.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_41_sql_injection_attacks.conf
modsecurity_crs_41_xss_attacks.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_45_trojans.conf

～省略～

尚、デフォルトでは、mod_security.confでこれらの全てのルールが有効となっている為、以下の様に設定を行う事で、使用したいルールを絞り込む事も可能です。

# vi /etc/httpd/conf.d/mod_security.conf

<IfModule mod_security2.c>
    # ModSecurity Core Rules Set configuration
        Include modsecurity.d/*.conf
        # Include modsecurity.d/activated_rules/*.conf ← コメントアウト
Include modsecurity.d/activated_rules/modsecurity_crs_41_xss_attacks.conf ← 個別に追加
Include modsecurity.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf ← 個別に追加

4.GUIでの操作ツール

Audit Consoleというサードパーティの管理ツールを導入した場合、WEBブラウザ上から、検知ログを確認する事も可能です。

https://jwall.org/web/audit/console/index.jsp

まとめ　桶の理論（ドべネックの桶）に例えられるセキュリティ

桶の理論（ドベネックの桶）をご存知でしょうか。桶は側面が複数の板で囲われる構造物です。もしもこの板の長さがまちまちであった場合、そこに貯める事の出来る水量は、おのずと「一番短い板」に左右されます。これは情報セキュリティにも当てはまる事で、システムという「桶」に高度なセキュリティ製品・施策を複数講じたとしても、全体の強度は常に「一番脆い箇所」に左右されてしまいます。

今回はセキュリティを支える数ある技術の中の１つとしてWAFを紹介しました。そしてこの「桶の理論」に例えられる、セキュリティの「脆さ」や「バランスの重要性」を意識して頂きつつ、本記事がセキュリティ技術を”バランスよく”学習して頂くきっかけになれれば幸いです。

記事一覧に戻る