rurihabachi
Last update: 2013/11/25  
    仮 想 マ シ ン で Fedora サ ー バ       ◇◇◇  お金をかけずに簡単簡潔  ◇◇◇  サーバ構築公開手順 覚書き  ◇◇◇
 
 
サーバ構築メニュー  
     1. はじめに
     2. 構築前の準備
     3. サーバの役割り
  » 4. サーバの計画
  » 5. 仮想マシンの準備
  » 6. Fedoraの準備
  » 7. サーバの基本設定
  » 8. ファイアウォール
  » 9. ウェブサーバ
  » 10. Apache Wicket
  » 11. メールサーバ
  « 12. セキュリティ
       iptables監視
       Clam AntiVirus
       ModSecurity
       AWStats
       その他の設定
     13. サーバの公開


  サーバ構築Top  > 12.各種セキュリティ設定  > (3)ModSecurity
    12. 安全性をより高めるための各種セキュリティ設定
本ページでは、Webアプリケーションを対象としたファイアウォール機能(WAF)を提供するModSecurityの設定を行います。

    (3) Webアプリケーションファイアーウォール(ModSecurity)

ModSecurityはWebアプリケーションサーバ向けのオープンソースセキュリティソフトで、Webサーバ(httpやhttps接続)への不正アクセスを防いだり監視したりする機能を持っています。 Apacheのモジュールとして動作します。

ウェブサーバをターゲットとする攻撃としては、例えば不正なhttpリクエストによってサーバ上のシステムファイルにアクセスしようとしたり、リクエスト中に悪意のあるスクリプトやSQLクエリを埋め込むことによってサーバ上で不正な処理を行うクロスサイトスクリプティングやSQLインジェクションといった攻撃があります。

ModSecurityはこのような攻撃に対し、特定のキーワードや記号をフィルタリングしたり、リクエストデータやパラメータのサイズに上限を設けたりすることでシステムを保護します。 また、ログ出力の機能も持ちあわせています。


ModSecurityインストールは以下のように行います。

[root@testserver ~]# yum install mod_security

確認を求められたら"y"を入力します。

ModSecurityの設定ファイルは/etc/httpd/conf.d/mod_security.confです。
開いて確認してみましょう。

[root@testserver ~]# vi /etc/httpd/conf.d/mod_security.conf

下記の行の設定がOnになっていることを確認します。

  SecRuleEngine On

始めのうちはまず様子見で使用してみようという場合は、上記の設定を"On"から"DetectionOnly"に変更して、機能や動作をログから確認することもできます。

ログはデフォルトで/var/log/httpd/modsec_audit.logに出力される設定になっています。

ModSecurityの機能を利用するためには、あらかじめ設定ファイルにフィルタリングルール等を設定する必要がありますが、インストールした時点で、適切に設定されたデフォルトのルールやフィルタリングに使用するキーワードのリストなどが準備されています。 (mod_security.confの下記の行を確認します。)

  Include modsecurity.d/*.conf
  Include modsecurity.d/base_rules/*.conf

上記のとおり、ルール等が設定されたファイルやデータファイルは、/etc/httpd/modsecurity.d内にインストールされます。 また、ローカルルール追加用のmodsecurity_localrules.confもあらかじめ用意されています。

ModSecurityの設定を有効にするために、httpdサービスを再起動します。

[root@testserver ~]# service httpd restart


例えばウェブサーバ上でブラウザを開き、アドレスバーに次のようなアドレスを入力してhttpサーバにアクセスしてみましょう。

"http://localhost/index.html?file=/etc/passwd"

ブラウザには"403 Forbidden"エラーが表示されて、ModSecurityのログを確認すると"etc"などの文字列がフィルタリングルールにひっかかったことがわかります。 または別の例として、

"http://localhost/index.html?id=<script>document.write("delete");</script>"

と入力してみると、今度はscriptタグをはじめ様々なものがパターンマッチしてアクセス拒否されていることがわかります。

ModSecurity機能をOffにして同様のことを試してみると、普通にページが表示されたり、場合によっては"404 Not Found"が出るだけで、攻撃に対して対処できないことがわかります。

 ◇     ◇     ◇

上記のように、デフォルトの設定だけでも強力な機能が備わっているModSecurityですが、状況によってはルールを追加していく必要もあります。 その場合は/etc/httpd/modsecurity.d内のmodsecurity_localrules.confにルールを書き加えていきます。 以下はその一例になります。

例えば、IPアドレスを含むURLでウェブサーバに接続できないようにしてみます。

サーバを公開すると、たくさんのIPアドレスから不正なアクセスを試みられます。 その多くはツールを利用した自動アクセスのようですが、IPアドレスを含むURL(http://xxx.xxx.xxx.xxx/index.htmlなど)でウェブサービスにアクセスできるようにしていると、サーバ内部に不正アクセスされてしまう危険性が高まります。 万が一システムに影響のあるファイルにアクセスされてしまうと致命的な結果になりかねません。 そこで念のためにIPアドレスでのウェブ接続を拒否するように設定してみます。

まず/etc/httpd/modsecurity.d/base_rules内のmodsecurity_crs_21_protocol_anomalies.confを開き、"Check that the host header is not an IP address"というルールを一式全てまるごとコピーします。

続いて/etc/httpd/modsecurity.d内のmodsecurity_localrules.confへ、コピーしたルールをまるごと貼り付けます。 さらに貼り付けたルール内の、

  …setvar:tx.anomaly_score=+%{tx.notice_anomaly_score}…

の部分を

  …setvar:tx.anomaly_score=+%{tx.critical_anomaly_score}…

に変更します。

modsecurity_localrules.confを保存したら、httpdサービスを再起動します。

[root@testserver ~]# service httpd restart

ルールがうまく作動していることを確かめるためIPアドレスを使用してウェブサーバへ接続すると、403エラー(アクセス権限なし)でアクセス拒否されることが確認できます。


別の例としては、他人のサーバをプロキシサーバ代わりに利用しようと試みる不正アクセスもあります。 Apacheはデフォルトでこのようなアクセスをスルーしますが、こういった不正アクセスに対してもアクセス拒否をするよう設定してみます。

まず/etc/httpd/modsecurity.d/base_rules内のmodsecurity_crs_20_protocol_violations.confを開き、"Proxy access attempt"というルールを一式全てまるごとコピーします。

続いて/etc/httpd/modsecurity.d内のmodsecurity_localrules.confへ、コピーしたルールをまるごと貼り付けます。 もしこのルールがデフォルトでコメント化されている場合は、コピー後、(説明コメントの部分ではなく)ルール本体の部分を非コメント化します。 さらに貼り付けたルール内の、

  …setvar:tx.anomaly_score=+%{tx.notice_anomaly_score}…

の部分を

  …setvar:tx.anomaly_score=+%{tx.critical_anomaly_score}…

に変更します。また、

  SecRule MATCHED_VAR "!@beginsWith http://%{SERVER_NAME}"…

の部分を

  SecRule MATCHED_VAR "!@beginsWith http://(ウェブサーバ名)"…

例えば

  SecRule MATCHED_VAR "!@beginsWith http://www.rurihabachi.com"…

などと変更します。 (サーバ名が変わる場合や増える場合は、都度このルールを変更する必要があります。)

modsecurity_localrules.confを保存したら、httpdサービスを再起動します。

[root@testserver ~]# service httpd restart

これで、ウェブサーバへの"GET http://www.xxx.com"といったリクエストをアクセス拒否することができるようになります。

注)サーバへの接続テストでエラーが戻る場合、ブラウザ上にFedoraのテストページ(/var/www/error/noindex.html)が表示されてしまうことがありますが、 その場合は、/etc/httpd/conf.d/welcome.confの内容を全てコメント化し、httpdサービスを再起動します。 これにより、403エラー時には"Forbidden"という画面が表示されるようになります。

なお、ルール中の"tx."から始まる変数の値や、anomaly_scoreがいくつ以上でどのような動作をするか(アクセス拒否かログ出力のみか、など)は、 /etc/httpd/modsecurity.d内のmodsecurity_crs_10_config.confに記述されています。

 ◇     ◇     ◇

メールサーバにModSecurityを導入した場合に、SquirrelmailのWebメール機能が正常に動作しなくなることがあります。 これは、ModSecurityのデフォルトで設定されている一部のルールが、Squirrelmailの動作をブロックしてしまうためです。 ブロックしているルールは、ModSecurityのログで確認することができます。

この不具合を回避するためには、Squirrelmail使用時に無視するルールのリスト(除外リスト)を作成して、そのリストを/etc/httpd/modsecurity.d内に置いておく必要があります。

除外リストの作成には、まず/etc/httpd/modsecurity.d内に、exclude.confという新規ファイルを作成します。

[root@testserver ~]# vi /etc/httpd/modsecurity.d/exclude.conf

ファイル内へ下記の行を追加します。 数字はModSecurityのルールIDです。 ID番号には、Squirrelmailの動作をブロックしているルールIDを全て指定します。

  <LocationMatch "/newwebmail/src/compose.php">
        SecRuleRemoveById 960010, 900045, 900017, 900059, 900043, 90004, 90008
  </LocationMatch>

上記青字の"newwebmail"の部分は、Squirrelmailのインストール時に、
/etc/httpd/conf.d/squirrelmail.confで設定したAliasを示しています。

また、MSC_PCRE_LIMITS_EXCEEDEDというエラーが出てうまくいかない場合は、
/etc/httpd/modsecurity.d内に、pcrelimit.confという新規ファイルを作成して、下記の行を追加します。

  SecPcreMatchLimit 150000
  SecPcreMatchLimitRecursion 150000

さらに、/etc/httpd/conf.d/mod_security.confへ下記の行を修正または追加します。

  SecRequestBodyLimit 2097152                                    (=2MB)
  SecRequestBodyNoFilesLimit 131072                                (=128KB)

最後にhttpdサービスを再起動します。

[root@testserver ~]# service httpd restart

以上でメールサーバ上でもModSecurityが正常に、メール機能を妨げずに動作するようになります。

 ◇     ◇     ◇

次はログの解析ツールを設定してみます。



前のページへ <    メニューへ戻る    > 次のページへ 

12.安全性をより高めるための各種セキュリティ設定:
 
   (1)iptablesによる監視
   (2)アンチウィルスの導入
  ›(3)ModSecurity
   (4)ログ解析ツール
   (5)その他のセキュリティ設定
 
Copyright (C) 2011-2019 rurihabachi. All rights reserved.