WordPressにMod SecurityでWAFを導入してみた。<br>〜インストールして反映するまで〜

うぇぶあぷりけーしょんふぁいあーうぉーる。

5分で絶対に分かるWAF

ファイアーウォールで防げなかった、アプリケーションに対する攻撃を防ぐことができる。

WordPressになぜ導入すべきなのか

みなさん大好き便利な便利なWordPress。みんなが大好きであればあるほど、WordPressを狙った攻撃を仕掛けてくるわけです。

となると、通常レベルのセキュリティでは、WordPressの穴が見つかった時に狙われてしまうわけです。

その穴をつかれないように、まずいことをされるまえにWAFで防御しておこうね、っていう狙いです。

どうやって防いでるの?などはこちらを読めばわかりやすいかと。

【WordPress】セキュリティを圧倒的に高める「WAF」

Mod Security導入まで

今回はMod Securityを導入します。選定理由などはまた別記事にて。

Mod Securityはホスト型のサーバーインストールタイプなので、何か新しい機器を導入したりする必要はありません。

しかも無料

WAFを導入することでのメリットを把握するためにはぴったりかと。

今のWordPressに入れるのすらも怖い、そんなときは

cloudadvisor

こちらからトライアルを。WAFはデフォルトでは入っていません(2018年6月27日現在時点)が、WordPressをすぐに使えます。

AWSのアカウントがあれば、オープンソースからAMIを無料配布していますので、apahce版を入れて好き勝手に試せます。

まずはsshでログインしてもらってインストールから。

$ yum install mod_security mod_security_crs

mod_security

本体。Apacheモジュールで動きます。

mod_security_crs

こちらはCore Rule Set。mod_securityはルールに従って該当するものを弾きます。そのためのルールセットです。

 動作させてみる

動作させるだけならば簡単。インストール時点でconfigなども有効な位置に置かれているはずなので、apacheを再起動するだけ。

$ systemctl restart httpd

有効になったのを確認したければ、WordPressのサイトにアクセスして投稿などをしてみて下さい。

十中八九エラーで表示できなくなるでしょう。

mod_securityのコアルールセットはWordPress用に作られているわけでもなく、通常リクエストでもルールに該当しているから弾いてしまうんですね。

つまり!効いている証拠!やったね!・・・で終われるわけないですよね。これでは普通にサイトとして崩壊しています。

なので、このルールは自分のサイトでは行うので許して上げてね!と、configに書いていく必要があります。 (もしくは、Core Rule Setのルールからいるのだけを選ぶんですが、数が多いので全部見るのは手間がかかります。)

除外するルールの書き方や、運用方法はまた長くなるので次の記事へ。