約 7 分で読めます。
この記事の続き。
CloudFrontを入れたことで、お次はCloudFrontにAWS WAFを取り付けてみます。
CloudFrontはAWS製のキャッシュサーバー。
ここにAWS WAFとしてWeb Application Firewallをアタッチさせることができます。
便利な世の中になったものだ。
AWS WAFはルールベースのWAFです。
セキュリティ製品としての分類はModSecurityと同じと考えていいと思います。
当然それぞれが抱えているルールは差異がある。
機械学習ベースではGuardDutyという製品がある様子。
AWSが持つ膨大な機械学習のノウハウを使うことで最新の攻撃・未知の攻撃にも対応可能といったウリ文句の模様。
これは今後試してみたいと思います。
AWS WAFの利用料金
AWS WAFの料金は以下。
![](https://linuxfun.org/wp-content/uploads/2022/02/image-1024x237.png)
自分が試した設定は以下の通り。
・1 WebACL
・6 Rules
↓の通り「WordPress」という名前のACLを作り、そこに6つのルールを入れてみました。
入れたルールはなんとなくWordPressに関係しそうなものとしています。
![](https://linuxfun.org/wp-content/uploads/2022/02/image-1-1024x512.png)
仮にアクセスが50000リクエストだとすると、毎月の金額は以下となりそうです。
リクエスト≠PV
・5USD x 1WebACL = 5USD ・1USD x 6Rules = 6USD ・0.60USD x (50000/1000000) = 0.03USD 合計 11.03USD
システム構成
AWS WAFを入れる前は以下の構成でした。
AWS WAFを入れることによるシステム構成は以下。
CloudFrontにAWS WAFがアタッチされ、コンテンツサーバー(ラズパイ)に到達する前に攻撃パターンを拒否するようになります。
メリット
コンテンツサーバーの修正なくWAFを導入できる。
これに尽きると思います。
ModSecurityですと、
サーバーメンテナンスの告知 サーバー停止 ModSecurityをApache/Nginxにモジュールとしてインストールし有効化 サーバー起動 サーバーメンテナンス終了の告知
と手間がかかる上、サービスを停止/再起動させる必要があります。
AWS WAFであればCloudFront(あるいALB等)にアタッチさせるだけで良いので、サーバー本体には何も手を入れなくて済みます。
デメリット
先ほども少し書きましたが、月額課金制であること。
これではないでしょうか。
また、適用したいルールによってはルールを使うこと自体に料金がかかるようです。
例えば↓の画面上部にPaid rule groupsとあります。
これらのグループに属しているルールは使うことで別途料金がかかると予想できます。
![](https://linuxfun.org/wp-content/uploads/2022/02/image-3.png)
このように、ルールをたくさん使って防御力を高めれば高めるほど支払うお金も高くなります。
ですので、本当に必要と思えるルールのみ適用する必要があり、精査に時間を要しそうです。
導入手順
AWS WAF側の設定
まずAWS WAFに移動します。
Create web ACLとします。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_151205-1024x281.jpg)
CloudFrontにアタッチさせたいので、Resource typeをCloudFront distributionsにします。
Nameは自分がわかる名前を適当に入力。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_151339-1024x734.jpg)
CloudFrontディストリビューションを追加するためにAdd AWS resourcesをクリック。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_151517-1024x326.jpg)
CloudFrontディストリビューションがあるならここでプルダウンに出てくるので、選択してAdd。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_151720.jpg)
追加されたことを確認してNext。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_151846-1024x301.jpg)
適用するルールが空です。
これから入れていきます。
Add rulesをクリック。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_152124.jpg)
今回はすでに用意してあるルールを使います。
Add managed rule groupsを選択。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_152219-1024x458.jpg)
AWS managed rule groupsということでAWSが用意してくれているルールがありそうです。
クリックして開いてみましょう。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_152350-1024x458.jpg)
具体的なルールが出てきます。
自分の環境/設定だと1500WCUsという容量上限が。
この範囲内で入れられるだけ入れてみます。
![](https://linuxfun.org/wp-content/uploads/2022/02/Screenshot-2022-02-01-15.27.52-760x1024.jpg)
このように1500WCUsぴったりとなりました。
![](https://linuxfun.org/wp-content/uploads/2022/02/Screenshot-2022-02-01-15.28.38.png)
次の画面はSet priority、ルール間優先度の設定。
ひとまず何もせずにNext。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_153007.jpg)
Configure metricsとなります。
ひとまずここも何も変更せずにNext。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_153146.jpg)
各設定を確認します。
問題なければCreate web ACLします。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_153421-524x1024.jpg)
無事にACLが作られました。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_153555-1024x285.jpg)
CloudFront側の設定
作成したWeb ACLをCloudFrontにアタッチします。
ディストリビューションの一般で編集を選択。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_153844-1024x547.jpg)
先ほど作成したWeb ACLが出てきますので、選択。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_154049.jpg)
Web ACLを選択して設定変更を保存すれば完了です。
動作確認
個々の具体的なルール内容は確認できないのですが、とりあえずWAF自体が動作していることは以下の手順で確認できました。
代表的な攻撃パターンであるhttps://holidaysfun.org/xmlrpc.phpを入力してGETすると、以下の通り拒絶されたことがWAFのOverviewで確認できました。
![](https://linuxfun.org/wp-content/uploads/2022/02/IMG_20220201_154630-1024x865.jpg)
ユーザー側もこの通りHTTP 403で拒絶されています。
![](https://linuxfun.org/wp-content/uploads/2022/02/image-4.png)
終わりに
いかがでしたか。
当然ですが、この記事通りの設定では使い物にならないと思いますので、ご自身の手で適用するルールの見直しや優先度付などの設定及び精査は行っていただければと思います!
Comments