うぇぶあぷりけーしょんふぁいあーうぉーる。
ファイアーウォールで防げなかった、アプリケーションに対する攻撃を防ぐことができる。
WordPressになぜ導入すべきなのか
みなさん大好き便利な便利なWordPress。みんなが大好きであればあるほど、WordPressを狙った攻撃を仕掛けてくるわけです。
となると、通常レベルのセキュリティでは、WordPressの穴が見つかった時に狙われてしまうわけです。
その穴をつかれないように、まずいことをされるまえにWAFで防御しておこうね、っていう狙いです。
どうやって防いでるの?などはこちらを読めばわかりやすいかと。
【WordPress】セキュリティを圧倒的に高める「WAF」
Mod Security導入まで
今回はMod Securityを導入します。選定理由などはまた別記事にて。
Mod Securityはホスト型のサーバーインストールタイプなので、何か新しい機器を導入したりする必要はありません。
しかも無料
WAFを導入することでのメリットを把握するためにはぴったりかと。
今のWordPressに入れるのすらも怖い、そんなときは
こちらからトライアルを。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のルールからいるのだけを選ぶんですが、数が多いので全部見るのは手間がかかります。)
除外するルールの書き方や、運用方法はまた長くなるので次の記事へ。