CloudFront の WAFを設定する

はじめに

AWSで現在 WAFと組み合わせて使用できるのは、CloudFront、ALB、API Gateway と複数ありますが、ここでは CloudFront を使った WAFを設定してみます。

基本的に WAF は L7レイヤーのトラフィックを検査する HTTP Proxy サーバーがアーキテクチャーの基本なので、これらの HTTPトラフィックを扱う製品と組み合わせて使う事ができます。

CloudFront というと CDN が基本の使い方のなので、キャッシュを必ずしないといけないイメージがありますが、キャッシュをさせずに素通しのプロキシーサーバーとしての使用も可能です。つまり、キャッシュをしないシンプルな WAFとして使用する事も可能です。

また、WAFは HTTPトラフィックの中身を覗いて攻撃を判断するという特性から、負荷の高い処理であり、作成されたルールによっては大量のCPUリソースを消費します。さらに、アプリケーションの脆弱性に対する攻撃は、それ以外の単純なDDoS攻撃の中に混ぜる形で行われ、アプリケーションへの攻撃が行われている事を埋もれさせる事で、攻撃の存在自体を隠す事が一般的な手段として用いられています。そのため、WAFで防御するアプリケーションへの攻撃と、DDoS攻撃への対応は切り離す事ができません。

CloudFront は、CDNが基本アーキテクチャーであり、エッジでの分散処理がその本質です。これは、大量のリソースを必要とする処理や、DDoS の大量のトラフィックを分散して処理するための最適なアーキテクチャーです。CloudFrontでWAFの処理を行うというのは、技術的に理にかなった方法になっています。

前提条件

この環境の前提条件は以下のような環境です。CloudFront のリクエストのフォワード先となる Web Server(CLBでL4ロードバランシング)は既に構築されているという前提になります。

ユーザーのドメインは、ocp4.work というドメインを使用します。

• 上図では test1.ocp4.work というドメインを例にして書いてますが、CNAMEは *.ocp4.work に対して行っていて、CloudFront の証明書も *.ocp4.work のワイルドカードで取得しているので、後段のオリジンのドメインは test2.ocp4.work でも api1.cop4.work でもこの構成で対応できます。
• CLB はL4のLoadBalancerなので、HTTP(S)のトラフィックの中身を見ずにTCP/IPレベルで、HTTPSリクエストを最終段のWeb Serverにフォワードします。CLBでは HTTPSは復号化されないため、CloudFront と Web Server の間 が HTTPSが終端される範囲になります。
• 最終段の Web Server の証明書は何らかの方法で取得されており Web Serverに埋め込まれているものとします。この手順の中では触れません。
• Clientからtest1.ocp4.work向けた HTTPSリクエストは、CloudFront のdfvhmf4jh47fc.cloudfront.netや、CLB のa15601ff3de5e4bc28e38e49f50d7d-1736380914.ap-northeast-1.elb.amazonaws.com などのいろいろなドメインを通過しているように見えますが、HTTPリクエスト内の「Hostヘッダー」の値はtest1.ocp4.workのまま変わらず最終段のWeb Serverにまで到達します。

補則：上記の絵はこの手順の説明に必要な部分だけ抽出して、簡略化して書いていますが、実際に実験に用いた構成は、以下のような Kubernetes (OpenShift)環境になります。

WAF のルール (web ACL)を作成する

最初に CloudFront の設定から参照するための WAF のルールを作成します。

メニューから WAF を検索します。「Create web ACL」をクリックします。

画像の通りに入力します。特に注意すべき点としては、これは CloudFront で使用する予定の web ACL なので
Resource type : CloudFront distributions
を選択します。

次に「Add rules」-> 「Add managed route groups」からルールを選択します。

いろいろ選択できますが、ここではあくまで腕ならしとして「AWS managed roule group」から適当に選択してみます。(本来はアプリケーションに合わせた適切なルールを選択する必要があります）

ここでは、「SQL database」を選択します。

実際には保護対象のWebサービスに合わせた必要最小限のものを選択するようにしましよう。例えばSQLを使うサービスを持ってないのに「SQL database」向けのルールを選択する必要はありません。また正規表現を使ったルールはCPUを過大に消費する事があるので十分に気を付ける必要があります。WAFのルールが原因でアプリケーションのレスポンスの悪化を引き起こす可能性があります。

「Default web ACL action for requests that don't match any rules」は、「Allow」を選択します。これは前述のルール設定にマッチしないトラフィックを許可する。という意味です。

ルールの評価順を変更する画面です。今は一つしか無いので、デフォルトのまま「Next」で大丈夫です。必要であれば後からも変更できます。

監視用のMetrixの設定なので、ここはとりあえず全てチェックを入れて「Next」をクリックしておきます。

これまでの設定の最終確認画面です。

「Create web ACL」をクリックすれば完成です。

IP Set を作成する

オプショナルですが、良くある要件なので、作成した web ACL に、アクセスを許可する IPアドレスを追加してみます。そのためにはまず「IP Sets」を作成します。
AWS WAF - IP sets から、「IP Sets」を作成します。

ここでは以下の画像の通りに設定しました。もちろん環境によって異なります。
この例では IP address に関しては私の自宅のISP (Internet Service Provider) のネットワークを登録しています。このISPのネットワークからだけアクセスできるような設定を作成します。

「Create IP set」をクリックすれば完成です。

以下のような 「IP Sets」が完成しました。

IP Set をweb ACLに追加する

今度は先ほど作成した 「web ACL」である「my-web-acl」の画面に戻ります。「Rules」のタブより「Add rules」=>「Add my own rules and rule groups」をクリックします。

IP Set を使用するための新しいルールを作成します。指定は以下の画像の通りです。先ほど作成した IP Set「my-providers-ips」を指定して Allow しています。完成した「Add rule」をクリックします。

次は優先順位の変更です。順番は環境によって適切なものが異なりますが、ここでは「allow-ip-list」が、最後に評価されるように指定します。「Move down」で一番下に動かします。「Save」をクリックします。

これで作成した WAFのRule (web ACL)、「my-web-acl」に、特定のIPアドレスを許可するルールが追加されました。

作成した web ACL「my-web-acl」は、「AWS-AWSManagedRulesSQLiRuleSet」ルールを使ってトラフィックの評価を行い、攻撃パターンとマッチしなけれれば、次に「allow-ip-list」のIPリストと照合を行います。「allow-ip-list」のIPリストは許可リストなので、このリストのIPレンジと一致するようであれば、トラフィックをオリジンに通過させます。

もしこのルール順を反対にしてしまうと、「allow-ip-list」のIPリストに一致した時点で、オリジンへのアクセスが許可されてしまう事になるので、「AWS-AWSManagedRulesSQLiRuleSet」による評価は行われなくなります。ルールの評価順とその動作は良く考えて決める必要があります。

ACM を使った CF用 DV証明書の発行

CloudFront で HTTPS を終端する

WAFはその性質上、HTTPトラフィックの中身を把握する必要があるので、HTTPSの暗号化を必ず復号化する必要があります。そのためには、CloudFrontでHTTPSを終端する必要があります。つまり CloudFrontに証明書をインストールしておく必要があります。

ACM (AWS Certificate Manager)を使用して証明書を発行すると、CloudFront でその証明書を使用する事ができ、証明書の更新も自動化できるので、ここでは ACM を使って証明書を発行します。

ACM で発行できる証明書は、DV (Domain Validation) による証明書です。

DV 証明書は発行が簡単な分、身元を簡単に隠せるため詐欺サイトなどでも普通に用いられる証明書です。DV証明書には暗号化以上の意味はありません。使用するドメインが身元が確認された組織により運営されたものであると、証明書ベンダーに確認されている事を証明したい場合、つまり「証明書」としての意味を持たせたい場合は、OV(Organization Validation) 以上の証明書をおすすめします。(但し取得費用が必要です）

ACM を使った証明書を発行する

AWS Certificate Manager のサービス画面を検索して、「バージニア北部」 リージョンを選択します。CloudFront の設定から ACMの証明書を参照するためには、「バージニア北部」に作成する必要があるという制限があるためです。

「証明書をリクエスト」をクリックします。

「次へ」をクリックします。

以下では、ワイルドカードを使った「*.ocp4.work」という証明書を取得します。(証明書をリクエストするドメイン自体は取得済みである必要があります)
検証方法：「DNS検証」
キーアルゴリズム：「RSA 2048」を選びます。

「リクエスト」をクリックして証明書をリクエストします。

証明書の一覧から、証明書のリクエストの状況が確認できます。証明書IDのリンクの部分をクリックして詳細を確認します。

以下の画面の「CNAME名」と「CNAME値」の列に注目します。次の手順でこれらの値を、証明書発行対象ドメインを管理している DNS Server に CNAMEレコードの値として登録します。

私の場合は、お名前.com で「ocp4.work」というドメインを取得しています。「ocp4.work」を管理している DNSサーバーもお名前.com の DNSサーバーを使用しているので、お名前.com の DNS管理画面に移動します。もし Route53 で取得しているドメインを管理している場合は、この作業はRoute53上で行う必要があります。この作業は、対象ドメインを管理している DNS Server (権威サーバー）上で行う必要があります。

DNSのレコードの書き替えは、使用しているサービス依存なので詳細は省略しますが、DNSサーバーの管理画面で、CNAME の DNSレコードを追加します。これらの情報は、先ほどのACMの「CNAME名」と「CNAME値」の列に表示されていた値です。

このレコードが dig で確認できるまで暫く時間がかかります。以下のようにレコードが返ってくれば正しく登録されています。

$ dig +short _c02082522847b130a631a5aa0c9b915c.ocp4.work
$ dig +short _c02082522847b130a631a5aa0c9b915c.ocp4.work
_84dfbabaeec9a23b1414db3b330dff68.zrvsvrxrgs.acm-validations.aws.
$ 

AWS Certificate Manager が、このレコードの登録を確認するまで数分～10分ほどかかると思います。
ステータスが「発行済み」になれば証明書の発行は完了です。

ACMで発行した証明書の CA(Certificate Authority) は、Amazon になります。証明書の期限は1ヶ月ですが、自動更新されるので更新の手間はありません。正確には自動更新には幾つか条件もあるので、詳細は公式ドキュメントの「ACM 証明書のマネージド更新」を確認しておくのが良いと思います。

AWS以外のCAが発行した証明書を使用したい場合

一方で、ドメインの信頼性を担保するために、組織証明をした上で発行される OV 証明書や、金融機関等ではさらに厳しい基準で発行される EV 証明書を使用しなければいけない場合もあります。その場合は「証明書をインポート」から外部のCAで発行された証明書をインポートする事が可能です。

こちらも詳細については、公式ドキュメントの「証明書をインポートする」に記載があります。

CloudFront の Distribution を作成する

ここからようやく CloudFront の設定に入ります。CloudFrontは設定の事を「ディストリビューション」と呼んでいます。

AWSのサービスからCloudFront を探して「CloudFront ディストリビューションを作成」をクリックします。

「オリジン」
以下の画像の通り設定しました。項目が多いので一つ一つ解説できませんが、以下の部分に特に注意します。

「オリジンドメイン」：「a156......ap-northeast-1.elb.amazon.com」 は、CLBのドメイン名です。
これはClodFront に来た HTTPリクエストをフォワードする先です。このフォワード先の事を「オリジン」と呼びます。今回の私の構成では、たまたまCLBが宛先だっただけで、環境によって異なります。オリジンとして指定できるものはマニュアルのこちら に記載されています。

「デフォルトのキャッシュビヘイビア」
以下の画像の通り設定しました。項目が多いので一つ一つ解説できませんが、以下の部分に特に注意します
「キャッシュキーとオリジンリクエスト」：「Cache policy and origin request policy (recommended)」
「キャッシュポリシー」：「CachingDisabled」
「オリジンリクエストポリシー」 : 「AllViewer」
この設定をする事で CloudFrontにキャッシュを行わせず、純粋にWAF用の HTTP Proxy として動作させる事ができます。

「関数の関連付け」
ここはデフォルトのままです。

「設定」
以下の画像の通り設定しました。項目が多いので一つ一つ解説できませんが、以下の部分に特に注意します
「AWS WAF ウェブ ACL - オプション」 : 「my-web-acl」これは事前に作成した web ACLです。
「代替ドメイン名 (CNAME) - オプション」 : 「*.ocp4.work」ここは証明書を取得したドメイン名を入力します。
「カスタム SSL証明書 - オプション」：「*.ocp4.work (427fe69d-18bd....f3)」これは事前に ACM で作成した *.ocp4.work の証明書です。

設定が完了したら「ディストリビューションを作成」をクリックします。

暫く待って「ステータス」の部分が有効になれば完了です。

次に証明書を取得した「*.ocp4.work」から、CloudFront の「ドメイン名」、「dfvhmf4jh47fc.cloudfront.net」に対して CNAME を行います。これにより「*.ocp4.work」へのHTTPリクエストは「dfvhmf4jh47fc.cloudfront.net」に誘導されるようになります。

「ocp4.work」のドメイン名を管理している DNSサーバーで以下のように CNAMEを設定します。

この設定も DNSサービスなどの環境依存ですが(DNS設定の展開速度やレコードのTTLに依存します)、インターネット上に展開されるまで数分はかかると思います。dig コマンドで設定が展開されたか確認できます。

$ dig +short  test.ocp4.work
$ dig +short  test.ocp4.work
dfvhmf4jh47fc.cloudfront.net.
54.192.150.8
54.192.150.85
54.192.150.75
54.192.150.65
$ 

「*.ocp4.work」の「*」の部分は、適当な文字列が使用できます。ここでは 「test.ocp4.work」に dig を打ってますが、「test」 は「*」として解決してくれるので実際に「test.ocp4.work」がDNSレコードとして登録されている必要はありません。

上記の dig の結果では、「test.ocp4.work」が、CloudFront のドメイン名 dfvhmf4jh47fc.cloudfront.net に CNAME されていて、さらに dfvhmf4jh47fc.cloudfront.net は、4つの IPアドレスに解決されているのがわかります。

つまり「test.ocp4.work」や「test1.ocp4.work」「abc.ocp4.work」...と行った「*.ocp4.work」にマッチする HTTPリクエストは、CloudFront の IPである、「54.192.150.8」「54.192.150.85」「54.192.150.75」「54.192.150.65」のいずれかに送信されようになりました。

以上で設定は完了です。

テストしてみる

デプロイしているサイトに通常アクセスしてみます。シンプルに文字列を返すアプリです。

$ curl https://test1.ocp4.work
Hello OpenShift!
$

適当な引数 key=test を付けてみます。まだ問題なくアクセスできます。
(デプロイしているアプリは引数は全く見ない作りですが、CloudFrontの設定で、引数はそのままオリジンまで送られています）

$  curl https://test1.ocp4.work/?key=test
Hello OpenShift!
$

SQL Injection として良く使われる文字列を含んだ key を付けてみます。
key=%2710%27%20or%20%271%27%3d%271%27　は、key='10' or '1'='1'　という意味の ASCII Code です。

$  curl https://test1.ocp4.work/?key=%2710%27%20or%20%271%27%3d%271%27
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app 
or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.  
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: MyQDzV9hIpu34P0GW0VXHG_6Sq0D8pfY_ETj6ce3YrwECv9hjqhwaQ==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
$

引数が原因で、WAFにブロックされました。403 で Request blocked と出ています。

最後に

この手順ではとりあえず「動かす」事を目的に書いていますが、WAFは保護対象のWebアプリケーションの特性に合わせて、細かくチューニングをする必要がある製品です。問題なく動く事が確認できたら、細かな設定を詰めて行きましょう。