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

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

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

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

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

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

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

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

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

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

しかも無料

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

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

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

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

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

$ yum install mod_security mod_security_crs

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

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

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

$ systemctl restart httpd

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

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

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

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

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

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