CDN

前回、S3でコンテンツを保持するサイトを保護するためにCloudFrontで行う推奨設定についてご紹介しました。
今回はCloudFrontとALB/EC2などを利用して構成しているWebサイトでどのようにオリジン(ALB/EC2)を保護すれば良いのか解説したいと思います。

CloudFrontについての概要や前回の内容を確認するにはAWS CloudFrontでオリジンを守ろう!(S3編)からご確認できます。

CloudFrontはWebコンテンツを高速に配信するプラットフォームで世界中に分散配置されているPOP(Point of Presence)にコンテンツがキャッシュされ、高速に配信されます。
また、このサービスを利用すると実際WebアクセスはAWSが管理するプラットフォームを経由するため、そのプラットフォームで提供するWAFサービスを利用することでアプリケーションを保護することができます。
しかし、そのままではCloudFrontを利用するだけではセキュリティ上盲点があります。
それはオリジンサーバへ直接攻撃されるケースです。

CloudFront

上の絵のように、WebリクエストがCloudFrontのPOPで受付け、コンテンツを保持するWebサーバへ転送されます。しかし、攻撃者は無差別にIPアドレスに攻撃したり、ある規則で生成されるAWSのドメイン名に対してスキャンをかけ、攻撃先を探し出します。直接Webサーバに攻撃が行われるケースが多く、Webサーバのアクセスログを見ると多くのボットやスキャナーがWebサイトにアクセスしてくるのがわかります。

対策としては直接アクセスできないよに、つまりCloudFrontから転送されるリクエストだけ許可して、直接アクセスしてくる通信をセキュリティグループでブロックすることが必要になります。

CloudFront Origin Protection

このような設定を行うために以下のようにSecurity GroupのInboundにCloudFrontのアドレスを追加します。

Security Group for CloudFront

実はCloudFrontのネットワークは非常に大きく、多くのネットワークをSecurity Groupに登録しないといけません。
実際AWSがPOPのリストを公開しておりますので、定期的に更新することが可能です。CyberNEOではPassLimit for CloudFrontとして自動的にオリジンを保護する機能をご用意しております。公開されているCloudFrontのPOPのIPリストをチェックして、定期的に更新する機能になります。
POP(リンク先ではエッジサーバと表現してます。)のリストなどはCloudFront エッジサーバーの場所と IP アドレス範囲のページから参照することができます。

今回、Security Groupで直接アクセスできないように保護する対策をご紹介しました。
この対策を導入するだけでスキャナやボットのアクセスがかなり減りますので大きくリスクを低減させることができます。
CloudFrontユーザーは是非、この対策をご検討してみてはいかがでしょうか? CyberNEOもよろしくお願いします!

 

関連リンク