本記事のキャプチャ画像は2018年7月25日時点のものです。
先日、XSERVERから「WAF設定機能の提供を開始」との案内メールが届きました。
「ん？WAFって何ですか！？」
・・・と思った人がいるでしょう。そうですよね、サイト運営している中ではなかなか聞かない単語です。
「WAF」は「Web Application Firewall」の略で、アプリケーションに特化したファイアウォールです。
「んー、そんなこと言われてもよく分からない。」
なかなか、かみ砕いて説明するのはむずかしいのですが、ざっくり言うと、サイトに対して悪いことをしようとしてくる通信から守ってくれる機能のことです。
そんな機能がXSERVERで標準機能として提供され、しかも管理画面からポチポチッと設定すれば有効にすることができるというじゃありませんか。
今回はそのWAF機能とXSERVERでポチポチッと簡単にWAF設定する方法について紹介したいと思います。
・そもそもWAFって何っていう人
・XSERVERのWAFを設定しようと考えている人
目次
ファイアウォールとWAFの違い
そもそも「ファイアウォール」と「アプリケーションに特化したファイアウォール(WAF)」の違いとは何でしょうか？
カンタンにその違いを見てみましょう。
ファイアウォールとは
ファイアウォールは
プロトコルレベル(HTTPやHTTPS等)で通信許可するか拒否するか設定することができます。
ファイアウォールで制御できる通信プロトコルの中でよく知られているものとして
- HTTP ： TCP80番ポート
- HTTPS ： TCP443番ポート
- RDP ： TCP3389番ポート
- SMTP ： TCP25番ポート
- TELNET ： TCP23番ポート
- SSH ： TCP22番ポート
- DNS ： UDP53番ポート
などが挙げられます。名前くらいは聞いたことあるのではないでしょうか？
通常、インターネットとインターネットに公開しているWEBサーバ間にあるファイアウォールでは「HTTP」と「HTTPS」のみ通信許可されているのが一般的です。最近ではセキュリティ対策として暗号化通信のみ許可したサイトHTTPS化が主流になりつつあります。
ちなみにファイアウォールで「HTTP」と「HTTPS」のみ通信許可していたとしても、ファイアウォールでは通信の中身(パケット)までは見ません。ファイアウォールで制御できるのはあくまで通信プロトコルレベルまでです。
そのため、WEBサーバに対して「データベースの中身を読み取る悪意のあるコードが含まれるHTTPSリクエスト」があった場合、ファイアウォールはHTTPSプロトコルのため、たとえ悪意のあるコードが含まれていたとしても、通信を許可してしまいます。
そんな状態だと、サイト運営者としては不安ですよね。そこでWAFの出番というわけです。
アプリケーションファイアウォール(WAF)とは
一方、WAFはファイアウォールで見ていなかった通信の中身(パケット)まで確認して、悪意のあるコードが含まれていたらブロックしてくれます。
一般的にWAFはシグネチャと呼ばれる「攻撃パターンのルールリスト」と通信内容を照らし合わせて通信拒否を判断します。そのため、シグネチャに含まれないパターンの攻撃があった場合は防ぐことができないということになります。
WAFを使う上で悪意のある通信を完全にブロックしてくれる万能なものではないことを理解しておきましょう。
また、このWAFは良い事だらけだけありません。上記のシグネチャが正常通信でも誤検知して通信を遮断してしまう場合もあります。
※デコードしていて偶然にもシグネチャパターンと一致する場合などが考えられます
そのため、WAF導入後は一通りのアプリ動作確認やサイト画面遷移を確認しておくべきでしょう。正常な通信をブロックされてしまってはたまったもんじゃありませんし。
WordPressを使っていれば、動的コンテンツサイトになるため、セキュリティリスク対策としてWAFを導入しておくべきだとわたしは考えます。
XSERVERでWAFを設定する方法
さて、前置きはこれくらいにして、実際にXSERVERでWAF機能を設定していくことにしましょう。
実際にXSERVERでWAF設定をしてみましたが、思いの外、簡単でポチポチってカンタンにできました。まだ、設定してない人はチャチャっとやっておきましょう。
まず、XSERVERへアクセスして、サーバパネルへログインします。
そして、ログイン後に「WAF設定」を選択します。
次にWAFを設定する「対象ドメイン」を選択します。
初期設定ではWAF設定の全項目はOFFになっているということが確認できます。
それぞれの設定項目についてはマニュアルに細かく記載されているため、説明を省きます。詳細はリンクからマニュアルを参照してください。
WAFの設定項目を「ON」にすると、以下のような画面が表示されました。
なになに・・・WAF設定の内容反映には半日程度かかるとのこと。すぐに反映されないため、注意が必要です。
同様にWAFの設定項目を全て「ON」にします。
これで設定作業は完了です。ポチポチっとするだけなのでカンタンですねー。
あとはWAFの設定反映が完了するまで待つだけです。
XSERVER使っているなら、WAF機能は有効にしておくべき
「そもそも、WAFの機能を有効にしておく必要ってあるのだろうか？」
そんな疑問を抱いた人はいるのではないでしょうか？
JVN iPedia 脆弱性対策情報データベースでWordPressの脆弱性を検索してみてください。
2018年1月〜2018年7月に期間を絞っても、WordPressの脆弱性が127件ヒットしました。そして、それら脆弱性の多くが「クロスサイトスクリプディング」や「SQLインジェクション」であることを確認できます。
どうですか？WordPress脆弱性の多さは。かなり多い印象を持ちませんでしたか？少なくともわたしは脆弱性の量が非常に多いと感じました。
そもそも、WordPressはブログやサイト作成するのにメジャーなソフトウェアなことやプラグインが豊富ということもあり、脆弱性を狙った攻撃対象になりやすいんですね。
そのため、XSERVERを使っているのであれば、カンタンに設定できるWAF設定は有効にしておくべきだとわたしは思います。無料ですしね。
みなさんもセキュリティ対策をしっかりして楽しいブログライフを送りましょう。XSERVERを使っていない人は使っているレンタルサーバーでWAFの機能が提供されているのかどうか一度確認してみてはいかがでしょうか？
サイトコンテンツや利用ツールに応じてWAF機能をOFFにする(2020/2/10追記)
上記に記載したとおり、誤検知でWAFに通信を遮断されてしまうパターンもありますが、コンテンツの内容によっては明らかに遮断されてしまう場合があります。
例えば
- OSのコマンド内容を記事に記載
- SQL分を記事に記載
- Apacheの設定ファイル名を記事に記載
してみると、WAFに遮断されてしまい、501エラーが起きてしまいます。
そのため、サイト内のコンテンツ次第ではWAF設定の「ファイル対策」「コマンド対策」「SQL対策」をリスクを受容した上でOFFにするというのも一つの手段です。
SQL対策の項目をONにした場合にエラーが出たので、一番はじめにSQL対策の項目をOFFにしてみると良いかも。
引用元：Googleタグマネージャーでコンテナ公開後に403 Forbiddenとなる時の対処法
そのため、WAF設定をした後に自身のサイトに合わせてチューニングしていくのが良さそうです。サイト運営ってなかなか大変ですね。
