ここ数年、日本を標的としたサイバー犯罪が多発しています。SQLインジェクションやパスワードのリスト攻撃などで多数の個人情報が漏洩したというニュースを耳にしているのではないでしょうか。それだけ日本のWebサイトは世界からみると脆弱なのかもしれません。このような攻撃を防ぐためには様々な方法がありますが、今回はCDNと相性がよいWAF（Web Application Firewall）について解説したいとおもいます。
WAFとFireWall・IPSの違い
セキュリティというと、このような単語を耳にすることもあるとおもいます。WAFとFireWallとIPSはどれもセキュリティ対策で用いられる技術や手法の名称で同じように聞こえますが以下のようにレイヤーと用途が分かれています。
FireWall
サーバーを不正アクセスから守る場合、FireWallは馴染みがあり聞いたこともある方は多いと思います。FireWallはネットワークレベルのセキュリティ対策で、あるIPアドレスからアクセスを許可・またはブロックするというようにIPとポートをみて判断することしか出来ません。その通信の中身が不正かどうかまでは判断出来ないため、HTTP(s)で正常なリクエストを装った不正アクセスなのかどうか判別が難しいことになります。よって、通常は管理画面へのアクセスをIPレベルで許可するといった単純な用途で利用されます。
IPS
IPS（Intrusion Prevention System）はOSやミドルウェアのぜい弱性を悪用した攻撃やさまざまな種類の攻撃をシグネチャに基づいて防御を行ないます。異常が発見された場合は通知・ブロックする必要があるため、ネットワーク構成上は経路上に配置する必要があるという構成上の制約があります。
WAF
WAF（Web Application FireWall）はこれらとは少し異なり、Webアプリケーションへのリクエストに対してシグネチャまたはブラックリストに基づき防御を行ないます。レイヤーとしては下からFireWall→IPS→WAFというように一番上のレイヤーでリクエストの中身をみてハンドリングできることが特徴です。
WAFでなければブロック出来ない要素として有名なのがECサイトやログイン画面で不正なSQL文を挿入し機密情報を手に入れたり内部データを改ざんしたりする「SQLインジェクション」。次に外部からサーバー上のコマンドを実行し、データやファイルの取得改ざんを行なう「OSコマンドインジェクション」、悪意のあるスクリプトを脆弱性のあるWebサイトにしかけることで不正にID/PASSを入手する「クロスサイトスクリプティング」です。
レッドボックスでは先日CDNに無料のWAFを組み込んだのですが、以下のような代表的な攻撃以外にもOSSの脆弱性やWordPressなどのCMSへの攻撃も対応しています。
WAFが対応できる主な攻撃種類
- SQL Injection (SQLi)
- Cross Site Scripting (XSS)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- PHP Code Injection
- Java Code Injection HTTPoxy
- Shellshock
- Unix/Windows Shell Injection
- Session Fixation
- Scripting/Scanner/Bot Detection
- Metadata/Error Leakages
- CMS（WordPress Drulap)
WAFの種類
WAFにも様々な種類があります。従来までは高価なアプライアンス機器を利用し、アプライアンスの下にサーバーを接続するという手法が利用されてきました。
データセンターに多数のサーバーを配置している場合や、ネットワーク構成によってはこのようなアプライアンス型が最適な場合もあります。しかし、近年クラウド化が急増しそもそも物理サーバーがない、または多数の拠点・クラウド上にサーバーがあるということも珍しくありません。このようなことから、ここ数年サーバーにインストールする「インストール型」とアクセスするユーザーとサーバーの間に配置する「Proxy型」の２つが多く用いられています。※アプライアンスを出している大手セキュリティベンダーは、クラウド上で動くソフトウェアWAFイメージを展開しておりますがこのあたりは割愛します。
インストール型WAF
インストール型はとにかくインストールすれば終わりというシンプルさが特徴です。ただし、サーバー台数に比例してコストも増加するという課題やそもそもサーバーへインストールすることすら出来ない場合は導入することが出来ません。更にWAFモジュール自体の更新やルール定義DBの更新などはインストールしたサーバー自身のリソースを使い管理者側で保守しなければいけないため、高負荷になりがちなサーバーへの導入はしっかりしたサイジングが必要になります。もちろん攻撃者のリクエストはブロックするにしてもWebサーバーまでは到達してしまうためあまりよろしくありません。
Proxy型WAF
逆にProxy型WAFは、サーバーを一切触ること無くDNSを変更するだけで利用できるということが最大のメリットです。サーバーのことがわからなくてもDNSレコードの操作だけであれば敷居がぐっと低くなりますよね。CDNもこのようなProxy型と同様にDNSを変更して適用するため、導入手順としてはCDNとほぼ同様です。Proxy型WAFはルールの更新、モジュールの更新など全てProxyするWAF自身が自動で行なうため、サーバー管理者は自分の管轄であるサーバーのメンテに追われる必要もなくサーバーリソースも消費しません。さらに、Webサーバー自体の存在をWAFで隠すことができるため、攻撃者のリクエストがWebサーバーまで到達しないということがポイントです。
CDNとWAFを組み合わせる際の注意点
さて、CDNとWAFの組み合わせはいくつか種類がありますが、一般的にイメージしやすいのはインストール型やアプライアンス型とCDNを階層構造で実装することではないでしょうか。
CDNを配置しその後ろにWAF、WAFの後ろにサーバーを配置するという階層型構造です。この構造はWAFを導入されている環境に後からCDNを導入する、またはCDN導入済であとからWAFを入れる場合どちらも対応ができ、それぞれの役割が独立しているため見た目上分かりやすいという特徴があります。しかし、インフラ構成は障害ポイントを少なくするためにも、可能な限りシンプルでなければいけません。さらに、経由するポイントが多いということは少なからずWebレスポンスの低下に直結するためマイナスポイントとなります。
キャッシュの罠
もう一つ気をつけなければいけないのはそのCDNは何をキャッシュするのか？という点です。一般的なWAFは不正リクエストをブロックする際、HTTPステータスコード403 Forbidden（禁止）を返却します。仮にCDNが403のネガティブレスポンスをキャッシュする構成だった場合、正常なリクエストが来てもキャッシュした403エラーを返却してしまう可能性があります。
なんとなく動いてしまっているは既にインシデント
実際CDNのほとんどがMETHODがGETまたはHEADのみキャッシュする仕様であることや、攻撃者のGETリクエストは大抵ユニークであることから正常なリクエストは別キャッシュと見なされることがほとんどです。よって、特に考慮していなくても階層構造で動いてしまっているということも少なくありません。ただし、CDNやWebサーバー、WAFモジュールの仕様変更が生じたい場合思わぬトラブルにつながる可能性があるためなんとなく動いているは既にインシデントといえます。
CDNは負荷軽減のために4，5系レスポンスをキャッシュする機能を有しており、弊社のエッジキャッシュも同様の機能があり、WAF機能を有効にするとエッジキャッシュの場合ネガティブキャッシュが自動でOFFになるよう設定されています。このようにCDNがどのような値をキャッシュキーとして定義しているのかで動作に変化はありますが、今一度キャッシュとWAFを階層構造にされている方は注意するポイントといえるでしょう。
CDN+WAFの組み合わせが選ばれる理由
近年CDNサービス自体にWAFが一緒に提供されることが多くなり様々なメリットが生まれました。CDNにWAF機能が一緒に提供されると、単純に経由するポイントがすくなくなりインフラがシンプルになります。経由するポイントが減るため、Proxy型で課題であったWeb表示速度が低下するという点もCDN+WAFの場合は解消されます。そして、先ほどの階層型のようにCDNのキャッシュを意識してWAFと連携しなければ正常なリクエストが来ているのにブロック画面を表示してしまうというリスクも無くなります。
さらに、階層型の場合攻撃者のリクエストはCDNを通過しWAFまでリクエストが必ずきてしまいます。WAFでブロック後もCDNでキャッシュできない場合CDN→WAFという順番で毎回リクエストが到達するのでWAF自体のリソースやWAFからCDNの間のネットワークトラフィックを使ってしまいます。もちろんリクエストがきますのでセッション数も消費してしまうでしょう。
いっぽうCDN+WAFの場合、エッジサーバーに着信し、キャッシュ判定を行ない、キャッシュがなかった場合は、WAFのパターンマッチをCDNサービス内で実行します。攻撃と判断した場合はオリジンサーバーにフォワードせず、そのままブロック画面やエラーステータスコードを返却してくれます。つまりCDN+WAFの場合、オリジンサーバー側のあらゆるリソースを消費することなく一番先頭で攻撃をブロックしてくれるため圧倒的に考慮するポイントが減ります。
DDosやAMPなど低レイヤー攻撃対策
CDN+WAFの場合、WAF単体では難しいDDos攻撃も防御（正確には吸収）することや、もう少し低いレイヤーのAMP攻撃などもCDNで防御することができることが特徴の一つです。このようなことから、インストール型WAFや階層型WAFの隠れたデメリットを克服し、一歩進んだ防御を可能にしてくれるのがCDN事業者が提供するWAFサービスの特徴といえます。
あえてデメリット２つ紹介
CDN+WAFはすごく良い！ということがおわかり頂けたとおもいます。しかしここはあえてデメリットといえる点を２つほどご紹介します。
APEXドメインとDNS問題
これはCDNやWAFがいけないというわけではなく、仕組み上CNAMEレコードを用いて切り替えを行なわなければいけない関係上RFCの制約で単純にAPEXドメインをCNAME設定するのにハードルが高いということです。APEXドメインとはホスト部が無いドメイン redbox.ne.jpのようなドメインを指します。このようなドメインをWebサイトで利用していると、ALIASまたはAPEXドメイン対応のDNSサーバーを利用して頂く必要があり若干手間がかかります。
APEXドメインのCNAME DNSの制約についてはCDNとCNAME Apexドメインの制約にまとめておりますのでよろしければ参考にしてください。
Web表示速度の問題
Web表示速度の問題Proxy型WAFはDNS変更さえ出来れば導入は一瞬ですが、直接Webサイトにアクセスさせていた方式と比べると経由するポイントが１つ多くなるためWeb表示速度が低下するという懸念があります。これはネットワーク上というか構成上仕方が無い事で避けては通れません。
そこで弊社が提供するエッジキャッシュCDNのWAFはこれら2点のデメリットをうまく克服したサービスにしました。
まず利用しているドメインがAPEXドメインでさらに既存DNSがALIASレコードに対応していない場合、弊社でALIASに対応したDNS事業者のアカウントを発行しDNS切り替えのサポートを実施します。次にWeb高速化サービス「Boost」で採用している通信・プロトコル・コンテンツの最適化をCDN内部で行なうため経由ポイントが１つ増えたことによるWeb表示速度低下を相殺し従来と同等かそれ以上の表示速度向上がおこなえるような特徴があります。
CDNとWAFのまとめ
現在Web高速化とHTTPS化はマストな時代となっており、これに加えセキュリティも強化する必要性が増しWebサイトは多岐にわたる対策を行なわざるおえなくなってます。SSLターミネーションするためにLBを導入し、Web高速化を行なうため内部対策し、セキュリティを高めるためにWAFを導入する。このようなことがCDNではまるっとカバーすることができてしまいます。サービスが用途別に点在している場合は、是非CDNの一本化を検討してみると幸せになれるかもしれません。
弊社ではCDNの無料トライアルを受け付けております。CDNにご興味があるかたは是非お問い合わせください！※公式ページのチャットからもご質問を承っております。
第２回 ＣＤＮ の 仕組み (CDNの種類について)
第３回 ＣＤＮ の 仕組み (高速化出来る理由)
DrupalをCDNで爆速にする方法
CDNで表示速度改善！優勝した「第三回 CMSプロレス 表示速度 最速王者決定戦」の主な対策とは？