近年、よく耳にするようになってきたキーワード「WAF(Web Application Firewall)」。
CMSを含めた古いバージョンのWEBサービス関連のソフトウェア環境への攻撃は悩みの種。
運用の現場では、ソフトウェアのバージョンアップの対応が困難であったり、今すぐアップデートと言われてもそれなりの検証期間と工数が必要なことがしばしば。
今回は、比較的導入が簡単な共有で利用できるWAFのアプライアンスサーバの作成方法をご紹介したいと思います。ただ、オープンソースであるmod_securityモジュールを利用するため、運用にはその知識が必要となり手間もかかるため、個人的には商用の専有機器や、SaaS型のものを導入することをお勧めします。
構成概要
今回は、CentOS6系の環境で、Apacheのmod_proxy、mod_securityモジュールを利用して環境を構築します。構成の概略図は下記の通りです。WAFを通過させたいFQDNのIPをDNSでWAFサーバのIPに向けて利用します。
構成図
リバースプロキシ設定
設定はApacheにmod_proxy(mod_proxy_httpd)が導入されていることを前提に説明しています。また、必要最低限の設定を記載していますので、セキュリティ面、利用用途に応じて適宜修正する必要があります。
1. HTTP用の設定
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.example.com
ProxyPass / http://www.example.com/
ProxyPassReverse / http://www.example.com/
</VirtualHost>
<VirtualHost *:80>
ServerName www.example2.com
ProxyPass / http://www.example2.com/
ProxyPassReverse / http://www.example2.com/
</VirtualHost>
・
・(FQDN数分設定します)
・
2. HTTPS(SSL)用の設定
※WAFを通過させたいFQDNのSSL証明書と秘密鍵の設置が必要です。必要に応じて中間証明書、クロスルート証明書の設置も行います。また、FQDN数分IPアドレスが必要になります。
LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost [IPアドレス]:443>
ServerName www.example.com
ProxyPass / https://www.example.com/
ProxyPassReverse / https://www.example.com/
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/pki/tls/certs/www.example.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/www.example.com.key
SSLCertificateChainFile /etc/pki/tls/certs/www.example.com.ca.crt
</VirtualHost>
<VirtualHost [IPアドレス]:443>
ServerName www.example2.com
ProxyPass / https://www.example2.com/
ProxyPassReverse / https://www.example2.com/
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/pki/tls/certs/www.example2.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/www.example2.com.key
SSLCertificateChainFile /etc/pki/tls/certs/www.example2.com.ca.crt
</VirtualHost>
・
・(FQDN数分設定します)
・
3. /etc/hostsファイルの編集
※下記を記載します。
--------------------------------
www.example.com [proxy転送先のサーバIP]
www.example2.com [proxy転送先のサーバIP]
・
・(FQDN数分設定します)
・
--------------------------------
WAF(mod_security)環境導入
epelリポジトリからインストールします。インストール後、Apacheを再起動すれば、デフォルトでmod_securityの設定が有効になります。
インストール
yum –enablerepo=epel install mod_security mod_security_crs
Apache再起動
/etc/init.d/httpd restart
導入時のワンポイント
1.SSLのライセンスについて
SSLを利用する場合、WAFサーバとproxy転送先サーバの両方でSSL証明書の設定が必要となります。SSL提供ベンダーにより、ライセンス数の取扱いが違うため事前の確認が必要です。
2.直接IPを指定した攻撃について
直接IPを指定した攻撃については、終端のサーバ側のFW等で「http/https」へのアクセスをWAFサーバのみにしぼることで対応が可能です。
3.ログ解析について
終端のサーバでアクセス元のIPを取得したい場合、httpヘッダーの「X-Forwarded-For」の値を参照する必要があります。独自にログ解析を行っている場合や、Apacheのログを見る必要がある場合は事前の確認をお勧めします。
以下はApacheのログ設定の例です。「%h」を「%{X-Forwarded-For}i」に変更することで、アクセスログにアクセス元のIPが表示されます。
LogFormat “%h %l %u %t ”%r” %>s %b ”%{Referer}i” ”%{User-Agent}i”" combined
↓ (変更)
LogFormat “%{X-Forwarded-For}i %l %u %t ”%r” %>s %b ”%{Referer}i” ”%{User-Agent}i”" combined
WAF(mod_security)環境の運用までに必要なこと
mod_securityをいきなり本番環境で利用することは、リスクが高いと思います。誤検知や、とあるCMSがインストールできなくなったという話もあります。本番運用後のリスク回避として、事前に以下の確認を行うことをお勧めします。
1.どのmod_securityのルール(Core Rule Set)を適用するか確認する
「/etc/httpd/modsecurity.d/activated_rules/」内に、ルール集が存在しています。デフォルトでは、全て読み込まれている状態になっています。必要に応じて「/etc/httpd/conf.d/mod_security.conf」のInclude設定を修正し、取込むルールを調整します。例えば、WEBサイトの脆弱性の大半を占めるSQLインジェクションとクロスサイトスクリプティングのみ対応する場合は下記のように修正します。
コメントアウト
#Include modsecurity.d/activated_rules/*.conf
追加
Include modsecurity.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include modsecurity.d/activated_rules/modsecurity_crs_41_xss_attacks.conf
2.十分なテスト期間を設けてテストを実施する
「/etc/httpd/conf.d/mod_security.conf」の下記修正を行うことで、遮断の処理はせず、検知のみ行うことができます。
コメントアウト
#SecRuleEngine On
追加
SecRuleEngine DetectionOnly
この状態で、一定期間ログ「/etc/httpd/logs/modsec_audit.log」の内容を確認し、正常な通信を検知していないか確認します。正常な通信が検知されている場合は対象のid(ログ上にはid "XXXXXX"という形式で記載されているid)を確認し、Apacheの設定(httpd.confもしくはIncludeされているファイルのいずれか)に下記を記載します。こうすることで、対象のidを例外処理として扱い、mod_securityの機能をONにした際に通信を遮断しなくなります。
※「XXXXXX」には任意の数字が入ります。
SecRuleRemoveById [確認したidを記載]
例外処理の作業が完了し終えたら、「SecRuleEngine」をONにして本番運用するという流れが良いかと思います。
最後に
今回はリバースプロキシを利用したmod_securityのWAF環境について記載しましたが、パフォーマンスについては触れていません。その点はご了承ください。
WAFについてのちょっとした参考にしていただければ幸いです。
次回は、AWS関連の情報を
6月上旬頃に掲載予定です。