目次:

  1. 概要
  2. 以前のAPI GatewayのWabセキュリティ対策
  3. 今後のAPI GatewayのWebセキュリティ対策
  4. APIにAWS WAFを適用してみる
  5. APIの検知ログを確認してみる

安価で導入しやすいAWS WAFの運用課題の解決方法をご紹介

【1.概要】

2018年11月5日に、AWS WAFがAmazon API Gatewayに対応したとの新機能リリースが出ました。
Amazon API Gateway Adds Support for AWS WAF:
https://aws.amazon.com/jp/about-aws/whats-new/2018/10/amazon-api-gateway-adds-support-for-aws-waf/

今回は、Amazon API GatewayにAWS WAFをデプロイする方法をご紹介していきます。

まずはリリース前後の変化からご紹介します!

【2.以前のAPI GatewayのWebセキュリティ対策】

これまでは、AWS WAFをAmazon API Gatewayに適用することができず、API Gatewayはインターネットに晒されている状況でした。

保護する選択肢1
そこで、AWS WAFを適用できるCloudFrontをAmazon API Gatewayの前段に配置する方法がありましたが、コスト面や導入面を考慮すると最適な方法ではありませんでした。

保護する選択肢2
SaaS型WAFを通信経路の間に入れ込む方法もありますが、SaaS型WAFの稼働率やレスポンス遅延など、AWSにシームレスではないという点で最前の策ではありませんでした。

【3.今後のAPI GatewayのWebセキュリティ対策】

今回のAWS WAFのアップデートにより、AWS WAFをAmazon API Gatewayに適用できるようになりました!
スピーディに、セキュアなAPI環境を構築することが可能です。

【4.APIにAWS WAFを適用してみる】

  1. AWSコンソール(API Gatewayページ)にアクセスします。
    https://console.aws.amazon.com/apigateway.

  2. APIナビゲーションページ上で、保護したいAPIを選択します。

ちなみに、今回保護するものは、POSTリクエストに対して200 OKを返します。

  1. 保護したいAPIにて、ステージを選択し、「設定」タブを選択します。
    ウェブアプリケーションファイアウォール(WAF)というメニューがあるので
    下図の赤線で囲まれたドロップダウンメニューより、適用したいWebACL(AWS WAF)を選択し、「変更を保存」 を押します。
    ※今回はステージ名を、“prod”で作成していますが、命名は自由で大丈夫です

制限事項について
下記の制限事項に当てはまっている場合には、WebACLを新規作成する必要があります。

WebACLを新規作成する際にはこちらのブログを参考に作成してみてください!
参考: AWS WAFの利用方法(https://www.wafcharm.com/jp/blog/aws-waf-usage-jp/

制限事項1:
ここで選択できるWebACLは、Amazon API Gatewayを利用している同リージョンのALBに作成されたWebACLのみです。選択できるWebACLがない場合には下図の赤枠で囲まれた箇所より、WebACLを新規で作成する必要があります。

制限事項2:
CloudFrontに作成したWebACLは残念ながら、ドロップダウンから選択できないので、下図の赤枠で囲まれた箇所より、WebACLを新規で作成する必要があります。

  1. 実際にWebACLが、APIに適用されているか確認します。
    まずは、AWS WAFナビゲーション( https://console.aws.amazon.com/waf/)にアクセスしてください。

  2. AWS WAFナビゲーション > Web ACLs > “本手順3においてドロップダウンメニューより選択したWebACL”を選択 > 「Rules」タブを選択し、赤枠で囲まれたものが表示されていれば、適用完了したことが確認できます。

適用前
APIへの適用前は、赤枠に記載のとおり、該当WebACLはALBにアタッチされているだけです。

適用後
APIへの適用後は、ALBだけではなく、TypeがAPI Gatewayという今回の作業にてアタッチしたAPIが追加されていることが確認できます。

  1. 実際に攻撃してみます。
    【正常なリクエストの場合】
    正常なリクエスト
    $ curl -X POST https://XXXXX.amazonaws.com/prod/ -vv

結果
HTTP/1.1 200 OK

【ルールに引っかかる攻撃リクエストの場合】
攻撃リクエスト
$ curl -X POST https://XXXXX.amazonaws.com/prod/test?pw=%27%20or%201%20=%201 -vv

結果
HTTP/1.1 403 Forbidden

既にWebACLが同リージョンにある場合には、数分でAPI Gatewayに適用できてしまうくらいデプロイが簡単でした!

【5.APIの検知ログを確認してみる】

サンプルログとフルログの2種類のログにて、検知を確認してみます。

サンプルログ
特段、事前設定はいりません。

  1. AWS WAFナビゲーション > Web ACLs > “該当のWebACL”を選択 > 「Requests」タブを選択します。

  2. 「Requests」タブを押すと、下の方にSampled requestsより確認できます。
    今回、擬似攻撃で検知させたルールを選択して、「Get new samples」を押すと検知履歴が出力されます。

上記検知履歴のSource IPカラムの ▶︎ を押すと下記の詳細情報を閲覧できます。

Client information:
Source IP: 攻撃元IPアドレス
Country: JP

Request line:
Method: POST
URI: /prod/?pw=%27%20or%201%20=%201

Request headers:
Accept: */*
CloudFront-Forwarded-Proto: https
CloudFront-Is-Desktop-Viewer: true
CloudFront-Is-Mobile-Viewer: false
CloudFront-Is-SmartTV-Viewer: false
CloudFront-Is-Tablet-Viewer: false
CloudFront-Viewer-Country: JP
User-Agent: curl/7.54.0
Via: 1.1 xxxxxxxxxxxxxxxxxxxx.cloudfront.net (CloudFront)
X-Amz-Cf-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
X-Amzn-Trace-Id: Root=x-xxxxxx-xxxxxxxxxxxxxxx
X-Forwarded-For: 攻撃元IPアドレス, IPアドレス2
X-Forwarded-Port: 443
X-Forwarded-Proto: https
Content-Length: 0
Connection: Keep-Alive

フルログ
事前に設定が必要です。

フルログの取得方法は下記ブログを参考に出力してみてください。
参考:AWS WAF Full Log を S3 に出力する(https://www.wafcharm.com/jp/blog/aws-waf-full-log-s3-output-jp/

今回は、上記方法により取得したフルログの内容について簡単に紹介します。
取得できる情報量に大きく差はなく、APIにアタッチした場合でも、フルログを有効活用できることを確認することができました。

取得できる主な項目:
webaclId:"今回利用したWebACL-ID "
terminatingRuleId:"今回擬似攻撃で検知したルールのルールID"
httpSourceName:"APIGW"
httpRequest:{"clientIp":"攻撃元IPアドレス"
uri:"/prod "
args:"pw=%27%20or%201%20=%201"
httpMethod:"POST"
requestId:"XXXXXXXXXXXX"}}

ALBにアタッチしたWebACLとAPIにアタッチしたWebACLが同一でも、そのWebACLにてフルログ出力設定さえしてしまえば、追加設定なく、APIに関する検知ログを全て取得することができました!

さらに赤字のhttpSourceNameにて、ALBで検知したものとAPIで検知したものを区別できる識別子になることも確認できました。
APIの場合-> httpSourceName:"APIGW"
ALBの場合->httpSourceName:"ALB"

以上、AWS WAFがAmazon API Gatewayに対応したということで適用方法〜検知ログの確認方法までご紹介しました!