トップ > セキュリティ > AWS環境へのサイバー攻撃とその対策について

AWS環境へのサイバー攻撃とその対策について

セキュリティ AWS WAF AWS Shield DNS Route 53 Resolver DNS Firewall Amazon Inspector AWS Global Accelerator AWS Systems Manager Amazon CloudFront AWS Certificate Manager Amazon Route 53
記事タイトルとURLをコピーする

こんにちは！イーゴリです。下記の記事の続きになるので、最初に必ず下記の記事をご覧ください。

パート1: セキュアなAWS環境の設計についての解説 blog.serverworks.co.jp

パート2: AWS環境のセキュリティ対策についての解説 blog.serverworks.co.jp

インターネットの初期の設計時には、セキュリティが最優先されていませんでした。1970年代から1980年代にかけて、インターネットの前身であるARPANETやTCP/IPプロトコルが開発された当初、研究者たちは主に接続性とデータ交換の効率を重視していました。その結果、セキュリティの観点が後回しにされることになりました。

その結果、多くの基本的なインターネットプロトコル（例：DNS、HTTP、SMTPなど）は、今日の基準から見るとセキュリティに関して脆弱な部分があります。これらのプロトコルは、認証、暗号化、整合性確認といったセキュリティ機能が欠けているか、不十分な状態で設計されています。

さらに、プログラミングミスや設定ミス、確認不足、設計上の欠陥などによって新たな脆弱性が生じることが多くあります。これにより、攻撃者がこれらの脆弱性を悪用して、データの盗難、サービスの停止、不正アクセスなどのサイバー攻撃を実行するリスクが高まっています。

インターネットの発展に伴い、セキュリティの重要性が認識されるようになり、多くのセキュリティ機能が後付けで追加されました。しかし、基本プロトコルの多くには依然として脆弱性が存在し、これが現代のサイバーセキュリティの課題となっています。

注意事項

この記事と次の記事では、AWS Well-Architected Frameworkのセキュリティの柱・ベストプラクティス・他の資料・個人的な意見に基づいた、理想的なセキュリティシステムの構築方法を紹介したいと思います。しかし、前回の記事で説明しましたが、「こうしないといけない」というような正解はありません。最終的にはビジネス的な判断が必要です。脆弱性やリスクを理解した上で、どのサービスを使用するか、どの部分にリソース(人・お金・時間など)を集中させるかを決定することが重要です。ITシステムを完璧に守ることは不可能であり、どの程度の投資を行うか、どのリスクを受け入れるかは、各企業やプロジェクトの事情や価値観により異なります。

AWSインフラ環境への攻撃について

攻撃方法は様々ですが、下記のように分かれています。

攻撃と対策の表

レイヤー 攻撃タイプ 攻撃の概要 対策方法 該当AWSサービス
L3/4 Syn/UDP Flood (SYN/UDPフラッド攻撃) サーバーに大量のSYNまたはUDPリクエストを送信し、リソースを枯渇させる攻撃です。 レート制限、トラフィックフィルタリング、キャパシティプランニング AWS Shield Standard, Security Groups, Network ACL, AWS Network Firewall
L3/4 Slowloris (スローロリス攻撃) サーバーとの接続を長時間維持することで、他の接続をブロックする攻撃です。 接続タイムアウトの設定、同一IPからの接続数制限 AWS Shield Standard, Security Groups, Network ACL, AWS Network Firewall
L3/4 Reflection and Amplification (反射および増幅攻撃) 小さなリクエストを送り、大量のレスポンスを生成することで被害者を圧倒する攻撃です。 トラフィックフィルタリング、送信元IPアドレスの検証 AWS Shield Standard, Security Groups, Network ACL, AWS Network Firewall
L3/4 IP Spoofing (IPスプーフィング) 攻撃者が偽のIPアドレスを使用して正規のユーザーになりすます攻撃です。 パケットフィルタリング、IPアドレスの検証 AWS Shield Standard, AWS VPC, Security Groups, Network ACL, AWS Network Firewall
L3/4 ICMP Flood (ICMPフラッド攻撃) 大量のICMPパケットを送信してターゲットのリソースを消耗させる攻撃です。 ICMPトラフィックの制限 AWS Shield Standard, Security Groups, Network ACL, AWS Network Firewall
L3/4, L7 Man-in-the-Middle (中間者攻撃) 攻撃者が通信を盗聴し、データを改ざんする攻撃です。 暗号化の使用 (SSL/TLS)、証明書の検証、セキュアなプロトコルの利用 AWS Certificate Manager (ACM)
L3/4, L7 DNS attacks (DNS攻撃) DNSキャッシュポイズニング、man-in-the-middle攻撃、DNSリフレクション攻撃、DNSアンプ攻撃、DNSトンネリングなど、DNSの脆弱性を悪用する攻撃です。 DNSSECの導入、DNSトラフィックの監視、DNS-over-HTTPS Amazon Route 53 (DNSSEC, DNS Query Logs, DNS-over-HTTPS), AWS Shield, AWS DNS Firewall, Amazon GuardDuty
L7 HTTP floods (HTTPフラッド攻撃) 大量のHTTPリクエストを送信し、ウェブサーバーを過負荷にする攻撃です。 レート制限、CAPTCHAの導入 AWS WAF, Amazon CloudFront, AWS Network Firewall
L7 Bots and probes (ボットとプローブ) 自動化されたボットを使用して脆弱性をスキャンする攻撃です。 ボット検出とブロック、アクセスログの監視 AWS WAF, Amazon CloudFront, AWS Network Firewall
L7 XSS (クロスサイトスクリプティング) 悪意のあるスクリプトを注入してユーザーの情報を盗む攻撃です。 入力のエスケープと検証、コンテンツセキュリティポリシーの設定 AWS WAF, Amazon CloudFront (Lambda@Edge), AWS Network Firewall
L7 SQL Injection (SQLインジェクション) SQLインジェクションは、アプリケーションがユーザーからの入力を適切に検証せずにSQLクエリに直接組み込む場合に発生します。 プリペアドステートメントの使用、入力検証とサニタイズ AWS WAF, Amazon RDSのパラメータグループ (例：MySQL/MariaDBのsql_mode), Amazon CloudFront, AWS Network Firewall
L7 RFI/LFI (リモート/ローカルファイルインクルージョン) 外部またはローカルのファイルを実行することでシステムを乗っ取る攻撃です。 入力の検証とサニタイズ、ファイルアクセスの制限 AWS WAF, Amazon CloudFront, AWS Network Firewall
L7 ソフトウェアの脆弱性 アプリケーションやOSの既知の脆弱性を悪用する攻撃です。 定期的なパッチ適用、脆弱性スキャン AWS WAF, Amazon Inspector, AWS Network Firewall
L7 CSRF (クロスサイトリクエストフォージェリ) ユーザーの意図しないアクションを実行させる攻撃です。 CSRFトークンの使用、Refererヘッダーの検証 AWS WAF, Amazon CloudFront, AWS Network Firewall
L7 Authorization exploits (認可の悪用) 認可の不備を突いて不正アクセスする攻撃です。 最小権限の原則、アクセス制御の厳密な設定 AWS IAM, AWS CloudTrail
L7 Spear phishing (スピアフィッシング) 特定の個人や組織を標的にしたフィッシング攻撃です。 メールフィルタリング、ユーザー教育 AWSサービス外
L7 Certificate hijacking (証明書ハイジャック) SSL/TLS証明書を不正に取得して通信を傍受する攻撃です。 証明書の定期的な更新と管理、証明書監視 AWS Certificate Manager (ACM)
L7 Brute Force (ブルートフォース攻撃) パスワードを総当たりで試行して認証を突破する攻撃です。 アカウントロックアウト※3、パスワードポリシーの強化、多要素認証を有効にする AWS WAF, AWS IAM, AWS CloudTrail, Amazon GuardDuty
L7 Directory Traversal (ディレクトリトラバーサル) ファイルシステムのディレクトリ構造を不正にアクセスする攻撃です。例：../../etc/passwd 入力の検証とフィルタリング、サーバー設定の強化、脆弱性対策パッチの適用、パスの正規化を行う AWS WAF, Amazon CloudFront, Amazon Inspector
L7 Malware (マルウェア) データを盗むまたはシステムを損傷するために悪意のあるソフトウェアを挿入する攻撃です。 アンチウイルスソフトウェアの使用、ファイル実行の制限、システムの監視 Amazon GuardDuty (Malware Protection機能含む)
L7 Ransomware (ランサムウェア) ファイルやシステムを暗号化し、復号のために身代金を要求する攻撃です。 定期的なバックアップ、アクセス制御の強化、脅威の監視と検知、Write Once Read Many（WORM）の導入 AWS Backup (Vault lock機能含む), Amazon S3 (Object lock機能含む), AWS IAM, Amazon GuardDuty

※3 ブルートフォース攻撃の一般対策はアカウントロックアウト、パスワードポリシーの強化、多要素認証の設定になりますが、AWS上でロックアウトポリシーを作成することができないため、前回の記事の通り、パスワードポリシーの強化及び多要素認証の有効化に集中することをお勧めいたします。なお、自作のアカウントロックアウトの仕組みを作成することもできます（例：CloudTrail → CloudWatch / CloudTrail → EventBridge → Lambda<->DynamoDB）。

サインインが指定された回数失敗したユーザーをアカウントからロックアウトするために、「ロックアウトポリシー」を作成することはできません。セキュリティを強化するために、強力なパスワードポリシーと Multi-Factor Authentication (MFA) を組み合わせることをお勧めします。 docs.aws.amazon.com

前回の記事：

blog.serverworks.co.jp

AWSのセキュリティ基盤(AWS Shieldなど)のお陰で、L3-4のセキュリティ（セキュリティグループなど）設定をきちんと行えば、L3-4の攻撃は発生しにくいと考えられます。一方、様々なソフトウェアの脆弱性により、L7はもっとも攻撃しやすいです。

AWS WAFの導入が必須

L7（アプリケーション層：Webサーバーなど）の攻撃の対策としてWAFの導入は必須条件です！AWS WAFをApplication Load Balancer, Amazon CloudFront, AWS APIGateway, Amazon Cognito user pools, AWS AppSync, AWS Verified Access, AWS AppRunnerに紐づけることができますので、是非ご活用ください！

WAFが必要な理由

すべての脆弱性を取り除くことは困難です。パッチの適用時間はすぐではなく、検証環境などで影響調査をし、サービス停止の案内も必要です。たとえ、理想的な状況でパッチがリリースされ、その瞬間に適用されたとしても、ゼロデイ攻撃や自分のアプリの脆弱性、アプリの不適切な設定などの攻撃のリスクは依然として存在しています。そのため、外部に公開されているEC2インスタンスやALB、CloudFront※4などには、WAFが必須です。

※4 パブリックサブネットにEC2インスタンスを置かないほうがよいということについては下記の記事で説明しましたので、基本的にPublic Subnetにあるリソース（ALB/Cloudfrontなど）にWAFをアタッチする必要があります。例えば、AWS Verified Accessの場合、IdPによる認証が行われていますので、AWS WAF導入の必要性についてはケースバイケースだと思います。

blog.serverworks.co.jp

WAFの設計

２つの設計パターンがあります。

一番多いパターンはブラックリスト型です。
ブラックリスト型とはデフォルトの通信(web ACLのアクション)は全許可ですが、ルールに一致した場合はリクエストをブロックするという仕組みです。一般Webサービスは基本的にこのパターンで設計されています。

もう一つのパターンはホワイトリスト型です。
ホワイトリスト型とはデフォルトで全部のweb ACLのアクションがブロックされ、ルールに一致した場合のみ許可するという仕組みです。限られた利用者がアクセスするケースに向いています。

ホワイトリスト型の場合、ルールを自分で作成してもよいですが、ブラックリスト型の場合、いちいちすべてのルールを作成/選択した上で、管理/更新するのは非常に大変ですので、いくつかの提案を紹介します。

最低限のAWS WAFルール（ホワイトリスト型）の一般設定は下記の通りですが、環境ごとに入れなくていいもの、入れないといけないものがありますので、どのルールを使うべきか/他に追加するべきルールがあるかなどについては環境ごとに異なりますので、ご承知おきください。

  • リクエスト頻度の制限 (レートリミティング)
    単一のIPアドレスからのリクエスト頻度を制限する。API Gateway、AWS WAF、CloudFront などのサービスを利用する際、リクエスト頻度を制限することで、DDoS攻撃、ブルートフォース攻撃、スクレイピングなどの影響を緩和できます。
  • SQLインジェクション対策
    SQLインジェクション攻撃からの防御を提供します。
  • クロスサイトスクリプティング (XSS) 対策
    悪意のあるスクリプトのウェブページへの埋め込みを防ぎます。
  • 既知の悪意のあるIPアドレス/ボットやその他の脅威に関連付けられていると考えられる IP アドレスのブロック
    攻撃元として知られているIPアドレスのブロックを使用します。
  • 一般的な脆弱性(OWASP,CVEなど)のブロック
    知られているエクスプロイトや脆弱性(Linux/Windows OSなど)をブロックするためのルールを設定します。

もっと細かく制限したいのであれば、

  • 国ごとのアクセス制限です。例えば、日本からのみアクセスを許可したい場合、日本国内からのトラフィックのみに制限すればよいです。もちろん、ProxyやVPNを利用して日本のIPアドレスを使用することは可能ですが、それでも大幅にトラフィックを削減できます。
  • 対象環境で非ブラウザベースの処理が必要ですか？もし必要がない場合、ブラウザからのアクセスのみに制限することをお勧めします。

ゼロからルールを作るのは簡単ではない（専門知識が必要）/ 手間がかかりますので、AWSが提供しているWAFのAWS Managed Rules（一部は有料ですが、基本的に無料）を是非ご活用ください。また、他のベンダー(3rd party)のWAFのWAF Maneged Rules（有料）が提供されていますので、必要に応じてご検討ください。

例えば、上記の攻撃に対してどのように環境を守るかについて、AWS WAFのAWS Managed Rulesを使用した簡単な対策表を以下に作成しました。

# 攻撃対策名 AWS Managed Rule名 課金
1 リクエスト頻度の制限 (レートリミティング) RateBasedRule なし
2 既知の悪意のあるIPアドレス：匿名IPリスト
Amazon IPレピュテーション 		AWSManagedRulesAnonymousIPList
AWSManagedRulesAmazonIPReputationList 		なし
3 一般的な脆弱性(OWASPなど)のブロック AWSManagedRulesCommonRuleSet
AWSManagedRulesLinuxRuleSet
AWSManagedRulesWindowsRuleSet
AWSManagedRulesKnownBadInputsRuleSet 		なし
4 SQLインジェクション対策 AWSManagedRulesSQLiRuleSet なし
5 クロスサイトスクリプティング (XSS) 対策 AWSManagedRulesCommonRuleSet なし
6 POSIX OS脆弱性 AWSManagedRulesUnixRuleSet なし
7 PHPアプリケーション脆弱性 AWSManagedRulesPHPRuleSet なし
8 WordPressアプリケーション脆弱性 AWSManagedRulesWordPressRuleSet なし
9 Botコントロール AWSManagedRulesBotControlRuleSet 有料
10 アカウント乗っ取り防止 AWSManagedRulesATPRuleSet 有料

注：上記のAWS WAFルールはマネージドルールですが、必要に応じてルールのチューニングが必要です。

AWS マネージドルールルールグループリストは下記のページにありますので、ご参照ください。

docs.aws.amazon.com

上にあるルールは一般ルールですが、同じルールを作って、すべての環境に同じルールをアタッチするのは、もちろん、NGです。理由はWAFのパフォーマンスが限られているからです。現時点のWAFのキャパシティの上限は5000WCUとなっています。ルール内容によってWCU値が異なるので、700WCUのルールもありますし、100WCUのルールもあります。但し、1500WCUを超える場合、500WCUごとに0.2 USD/100万リクエスト加算されますので、超過料金発生にご注意ください。コストを抑えたい場合、1500WCU以内に収めないといけません。

docs.aws.amazon.com

また、環境に何があるかを把握した上で設計する必要がありますので、一例として下記の図を紹介します。対象環境にWindowsサーバー/Linuxサーバーがあるか、DBがあるかなどによって適用するべきWAFルールも異なります。

イメージ図：

WAFは一度設定して終わりではなく、環境や状況に応じてルールの管理（運用、監視、チューニング）が必要です。場合によっては、WAF専用のセキュリティチームを配置する必要があることもあります。そのような場合には、AWS WAFと3rdパーティのサービスソリューション（例：WAF Charm）を組み合わせることをご検討ください。WAF Charmはコストパフォーマンスが高く、WAFの管理（運用、監視、チューニングなど）を自分で行いたくない場合には、WAF Charmに任せるのが良い選択肢です。

AWS Certificate Manager

パブリック向けの通信は絶対に暗号化しないといけません。AWS Certificate Manager (ACM)が提供するSSL/TLS証明書を使用することで、ウェブサイトやアプリケーションの通信をHTTPSにより暗号化できます。これにより、ネットワークを介したデータの盗聴や改ざんを防ぐことができます。特に、パスワードやクレジットカード情報などの機密データを保護するために重要です。

SEC09-BP02 伝送中に暗号化を適用する
<省略>
AWS Certificate Managerの使用を検討する: ACM では、AWS サービスで使用するためのパブリック TLS 証明書をプロビジョニング、管理、およびデプロイできます。
<省略>
docs.aws.amazon.com

ACMでは外部の証明書も利用できますし、AWSが無料で提供しているACM証明書も利用可能です。どのような場合にどの証明書を使うべきかについては、以下の記事をご参照ください。

blog.serverworks.co.jp

AWS Private Certificate Authority

プライベートな証明書の安全な鍵および証明書管理を実装するために、AWS Private Certificate Authority (AWS Private CA)を使いましょう。

SEC09-BP01 安全な鍵および証明書管理を実装する
<省略>
AWS は、汎用 PKI 証明書を管理するための 2 つのサービス、 AWS Certificate Manager および AWS Private Certificate Authority (AWS Private CA) を提供しています。ACM は、パブリックとプライベートの AWS ワークロードの両方で使用するための証明書のプロビジョニング、管理、およびデプロイに使用できる主要なサービスです。ACM は AWS Private CA を使用して証明書を発行し、 他の多くの AWS マネージドサービスと統合して、 ワークロード用の安全な TLS 証明書を提供します。
<省略>
docs.aws.amazon.com

高額なサービスであるため、注意が必要です。もちろん、AWS Private Certificate Authority（PCA）は最も管理しやすく、安全性の高いサービスですが、コストとのバランスを考えると、自作の自己証明書を作成し、AWS外でプライベート証明書を保管する方法も検討できます。この方法は、利便性やセキュリティの面で劣るかもしれませんが、コストを削減する手段となります。どちらを選択するかは、ご自身で判断してください。

参考記事：

[AWS Private CA の作成]の項目 blog.serverworks.co.jp

[自己証明証を作成する方法]の項目 blog.serverworks.co.jp

注意点：

SEC09-BP01 安全な鍵および証明書管理を実装する
<省略>
一般的なアンチパターン:
■証明書のデプロイまたは更新プロセス中に手動で手順を実行する。
■プライベート認証機関 (CA) を設計する際、CA 階層に十分な注意を払わない。

について下記の記事の[証明書の階層構成の説明]の項目をご参考ください。 blog.serverworks.co.jp

■公共リソースに自己署名証明書を使用する。
<省略>
このベストプラクティスを活用しない場合のリスクレベル: 高
docs.aws.amazon.com

Amazon CloudFront

CloudFrontは、静的コンテンツの高性能な分散配信を行うサービスだけでなく、攻撃に対する防御手段としても利用できます（例：DDoS対策、WAFとの連携）。

例えば、以下の方法でセキュリティを強化できます。

  • ①OAC (Origin Access Control) (従来方法：OAI – Origin Access Identity) (S3)/セキュリティグループのルール (EC2/ALB)/オリジンカスタムヘッダ(API Gateway/Lambda@Edge)を設定することで、直接的なS3/EC2/ALB/API Gatewayへのアクセスを防ぐことができます。
  • ②Lambda@Edgeを使用してHTTPセキュリティヘッダーを設定することで、クリックジャッキングやクロスサイトスクリプティング（XSS）などの攻撃を防ぎ、クライアント側の脆弱性を悪用する攻撃を困難にします。
  • ③CloudFrontの地理的制限を設定することで、特定地域のユーザーがCloudFrontディストリビューションを通じて配信しているコンテンツにアクセスできないようにすることができます。
  • ④WAFと連携することで、Rate-based Rulesなどを使用してDDoS攻撃を防ぐことができます。

参考記事： blog.serverworks.co.jp blog.serverworks.co.jp blog.serverworks.co.jp

IMDSv2を使う / IMDS自体を無効にする

EC2のIMDSv2（Instance Metadata Service version 2）を使う、もしくは、 IMDS自体を無効化(要注意)するという方法があります。

IMDSv1の攻撃リスク

IMDSv1は、SSRF（Server-Side Request Forgery）攻撃に対して脆弱性があり、攻撃者がWebアプリケーションの脆弱性を利用して、IMDSv1からEC2インスタンスに関する情報（例えばIAMロールの認証情報など）を取得できるリスクがあります。この情報が漏洩すると、AWSリソースに不正アクセスされる可能性があります。

  • 脆弱性の利用：攻撃者は、SSRF脆弱性のあるWebアプリケーションを見つけ、サーバーに対して任意のURLへのリクエストを送信させます。
  • IMDSv1へのアクセス：攻撃者は、サーバーに対してIMDSv1にリクエストを送信させます。IMDSv1は、http://169.254.169.254/latest/meta-data/というURLでアクセスできます。
  • データの取得：一連のリクエストを通じて、攻撃者は一時的なIAMクレデンシャルなどの機密情報にアクセスできます。これにより、攻撃者はAWSリソースに不正アクセスできるようになります。

攻撃者がSSRF脆弱性を利用してインスタンスメタデータにリクエストを送信する例は下記となります。

http://example.com/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

但し、IMDSv1におけるSSRF攻撃の脆弱性が利用される下記のような条件があるので、すべてのEC2(IMDSv1)でSSRF攻撃を行えるわけではありません。

  • ウェブアプリケーションに脆弱性がある
  • ウェブアプリケーションに不適切な設定がある
  • WAFが適切に設定されていない、または導入されていない

対策方法：IMDSv2を使うこと、もしくはIMDS自体を無効化することです！

IMDSv2は、リクエストにトークンを使用するため、SSRF攻撃が難しくなります。これにより、不正なリクエストが防止されます。

IMDSv2の仕組みについて詳しく下記のページをご参照ください。

blog.serverworks.co.jp

現時点では、EC2を構築する際にデフォルトで「IMDSv2のみ」が設定されますが、IMDSv2を利用する場合、一部のアプリケーションでトラブルが発生する可能性があります。そのため、事前の検証が必要です。

例えば、Datadogの監視設定では、IMDSv1を使用している場合、特別な設定を必要としませんが、IMDSv2を使用する場合は、「ec2_prefer_imdsv2」オプションを「false」から「true」に変更しないと、インスタンスIDを取得できず、ホスト名の識別が正しく行われないことがあります。また、Datadog AgentがインストールされているEC2をクローンすると、オプションが「false」のままの場合、ホスト名がクローン元のEC2と同じまま残ってしまうことがあります。

Datadog Agentについて詳しくは下記の記事をご参考ください。

blog.serverworks.co.jp

medium.com

IMDS自体を無効化する案もありですが、下記の注意点があります。

  • EC2にアタッチされているIAMロールの認証情報が取得できなくなるため、S3などのAWSリソースへのアクセスができなくなります。
  • 他のサードパーティ製品もIMDSを使用しています。例えば、DatadogやTrend Micro Cloud Oneなどです。

cloudone.trendmicro.com

そのため、IMDSv2の使用やIMDSの無効化にあたっては、十分に検証を行った上で判断してください。

なお、IMDSv1の利用状況は、CloudWatchのEC2メトリクス「MetadataNoToken」で確認することができます。既存のEC2でIMDS設定を変更する前に、このメトリクスを活用して、どれだけ参照されているかを把握することが可能です。詳しくは、以下の記事をご参照ください。

docs.aws.amazon.com

厳密に言えば、IMDSv2を有効にしてもEC2が無敵になるわけではありませんが、IMDSv2に切り替えることで、SSRF攻撃に対するセキュリティを大幅に強化し、IMDSv1に関連するリスクを軽減できます。ただし、Gopherプロトコルを使用することで、IMDSv2のトークンを取得する方法も存在します。

IMDSv2の攻撃方法について下記の記事に詳しく説明してあります。 blog.tokumaru.org bugbase.ai

Gopherプロトコルを利用すると、攻撃者がIMDSv2に対して任意のリクエストを送信し、トークンを取得してメタデータにアクセスすることが可能になりますが、この攻撃はアプリケーションに脆弱性があるか、設定が不適切である場合にのみ成立します。

以下の対策が有効だと思います。

  • 当然のことですが、誤設定を避けること
  • 不要な機能や設定を削除または無効化すること

対策の一例：対象のウェブアプリケーションで使用しないURIスキーマを無効にします（例：HTTPSのみを使用する場合、HTTPSのみを許可し、FTP、Gopher、Fileなどを禁止する）。これにより、攻撃者が潜在的に危険なスキーマを利用してリクエストを送信することができなくなります。

  • 自身のURLを適切に検証すること
  • 最小限のIAMロールを使用すること
  • WAFを使用すること

誤って設定された Web アプリケーションファイアウォールからの保護 AWS WAF などの一部のウェブアプリケーションファイアウォール（ WAF ）サービスは、オープンな WAF として機能するように設定できません。しかし、一部のサードパーティ製 WAF は、攻撃者に EC2 IMDS を含む WAF の背後にあるネットワークへの不正アクセスを許してしまうように誤って設定される可能性があります。
省略
AWS のアプローチは、オープン WAF がほとんどサポートしない HTTP PUT リクエストを使用して、オープンな WAF をブロックすることです。 Amazon S3 などのウェブサービスはオブジェクトストレージに PUT リクエストを使用しますが、ウェブサイトやブラウザでは珍しいタイプのリクエストです。サードパーティの WAF 製品と、誤って設定されたオープンな WAF を調査したところ、大半は HTTP PUT リクエストを許可していないことがわかっています。この PUT リクエストを使用して、よりよい新しい防御層を提供します。セッションの開始時に PUT リクエストを要求するよう IMDSv2 サービスを設計することで、大多数のケースにおいて、オープンな WAF が悪用され IMDS にアクセスするのを防ぐことができます。 aws.amazon.com

DDoS攻撃を緩和するためのテクニック

DDoS攻撃（分散型サービス拒否攻撃）は、依然としてサイバー空間で最も一般的かつ深刻な脅威の一つです。2024年には、これらの攻撃が前年に比べて約20%増加し、その頻度が大幅に増加しました。特にネットワーク層（L3/4）での攻撃が目立ち、その中でもSYNフラッドやDNSフラッドが一般的です。DDoS攻撃全体のうち、HTTP DDoS攻撃が37％、DNS DDoS攻撃が33％を占めており、残りの30％がSYN FloodやUDP Floodなどの他のL3/4攻撃に該当します。

さらに、Miraiボットネットを利用した攻撃も増加傾向にあります。DDoS攻撃は、企業や組織にとって依然として重大なサイバー脅威であり、適切な対策が求められています。

参考記事： radar.cloudflare.com

また、最近のウクライナ情勢の影響により、一部のロシア系ハクティビストによるDDoS攻撃が日本にも拡大しているとの報告があります。

参考記事： www.trendmicro.com

上記の背景を踏まえ、DDoS攻撃を緩和するためのテクニックを積極的に活用することをお勧めします。

AWS ALB, WAF, Shieldなどについては既に説明しましたが、以下に紹介するAWS公式ページには、さらに詳しい情報が記載されています。まだ説明していない重要な項目も含まれているため、ぜひご参照ください。

docs.aws.amazon.com

上記のAWSホワイトペーパーから、AWSのDDoS耐性リファレンスアーキテクチャを転載いたします。

AWS Edge AWS Edge AWS Edge AWS リージョン AWS リージョン AWS リージョン
CloudFront （BP1) での Amazon AWS WAF （BP2) の使用 Global Accelerator の使用 (BP1） Amazon Route 53 の使用 (BP3） （BP6) での Elastic Load Balancing AWS WAF （BP2) の使用 Amazon ACLsでのセキュリティグループとネットワークの使用 VPC (BP5） Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling の使用 (BP7）
レイヤー 3 (UDPリフレクションなど) 攻撃の軽減 ✔ ✔ ✔ ✔ ✔ ✔
レイヤー 4 (フラSYNッドなど) 攻撃の軽減 ✔ ✔ ✔ ✔
レイヤー 6 ( などTLS) 攻撃の軽減 ✔ ✔ ✔ ✔
アタックサーフェスを減らす ✔ ✔ ✔ ✔ ✔
アプリケーションレイヤートラフィックを吸収するためのスケーリング ✔ ✔ ✔ ✔ ✔ ✔
レイヤー 7 (アプリケーションレイヤー) 攻撃の軽減 ✔ ✔(*) ✔ ✔ ✔(*) ✔(*)
過剰なトラフィックや大規模なDDoS攻撃の地理的分離と利用 ✔ ✔ ✔

✔(*): Application Load Balancer AWS WAF で と共に使用する場合

Amazon EC2 Auto Scaling

ウェブアプリケーションを運用する際には、ロードバランサーを使って Amazon EC2 インスタンスにトラフィックを分散しますが、このインスタンスを多めに準備する、あるいは自動的に拡張 (スケールアウト) するよう設定できます。こうしておけば、フラッシュクラウド、アプリケーション層に対する DDoS 攻撃などにより、突発的にトラフィックが増加しても対処できるのです。Amazon CloudWatch のアラームに応じて Auto Scaling を起動するよう設定すると、CPU、RAM、ネットワーク I/O、あるいはカスタムメトリクスなどについて定義したイベントに応じて、自動的に Amazon EC2 のフリートサイズがスケーリングされます。このアプローチにより、想定以上にリクエスト量が増えても、アプリケーションの可用性が損なわれることはありません。

docs.aws.amazon.com

AWS Global Accelerator

Global Acceleratorは固定のグローバルIPアドレスを提供するため、これを使ってサービスへのアクセスを集中させることができます。このIPアドレスを使うことで、特定のエンドポイントやリソースに直接的な攻撃を受けるリスクを軽減できます。

Global Acceleratorを経由することで、ALBや他のリソースはパブリックIPアドレスを持つ必要がなくなり、インターネットゲートウェイを介してVPC内でインターネットトラフィックを受け入れることができます。

さらに、Global AcceleratorはAWSのグローバルネットワークを通じてトラフィックをルーティングするため、ユーザーに対するレイテンシーの低減や可用性の向上も期待できます。また、DDoS攻撃からの保護を提供し、攻撃の影響を受けにくい安全な接続を確保します。これにより、インフラ全体のセキュリティを向上させることができます。

なお、例えば、エンドユーザーがファイアウォールの許可リストに追加でき、AWS の他のお客様には使用されない IP アドレスが必要になったとします。このようなシナリオでは、Global Accelerator を使用して、Application Load Balancer で実行されているウェブアプリケーションを保護し、AWS WAF と連携して、ウェブアプリケーションレイヤーでのリクエストフラッドを検出して緩和することもできます。

docs.aws.amazon.com

Amazon Inspector

様々なL7の攻撃の主な原因はソフトウェアの脆弱性です。Amazon Inspectorを利用することで、既知のソフトウェア脆弱性や意図しないネットワークのエクスポージャーがないかを継続的にAWSワークロードをスキャンする自動脆弱性管理サービスです。

上記の図の通り、SSMエージェントがインストールされていると、Inspectorのスキャン対象になります。SSMエージェントがインストールされていない場合でも、スキャンモードをエージェントからハイブリッドに変更すると、エージェントレスモードでSSMエージェントがインストールされているEC2インスタンスだけでなく、SSMエージェントがインストールされていないEC2インスタンスのEBSスナップショットもスキャン対象となります。

エージェントスキャンとエージェントレススキャンでは、スキャン頻度や料金などが異なるため、詳細は下記の記事をご参考ください。

blog.serverworks.co.jp

Inspectorを有効にすると、すべてのSSMエージェントがインストールされているEC2インスタンスがスキャン対象となり、費用が高額になる可能性があるため、注意が必要です。スキャン除外機能を利用して特定のEC2インスタンスを除外できますが、いくつかの注意点(除外されない可能性がある)があるため、詳細は下記の記事をご覧ください。

blog.serverworks.co.jp

Amazon Inspectorよりきめ細かく管理したい場合、Vuls (FutureVuls)をご検討ください。

blog.serverworks.co.jp

SEC06-BP01 脆弱性管理を実行する
<省略>
Amazon Inspector を設定する: Amazon Inspector は新たに起動された Amazon EC2 インスタンス、Lambda 関数、および Amazon ECR にプッシュされた適格なコンテナイメージを自動的に検出し、ソフトウェア問題、潜在的な欠陥、および意図しないネットワーク露出がないかスキャンします。
<省略>
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

参考記事：

blog.serverworks.co.jp

AWS Systems Manager

次の記事で運用について説明しますが、ここで少しだけ触れておきます。

AWS Systems Managerを使うことでOSのパッチの適用も自動化できますし、AWS Configルールに沿っていないパラメーターを自動的に修正できます。

SEC06-BP01 脆弱性管理を実行する
<省略>
AWS Systems Manager を使用する: Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon マシンイメージ (AMI)、およびその他多くのコンピューティングリソースなど、AWS リソースのパッチ管理を行う責任があります。AWS Systems Manager Patch Manager は、セキュリティ関連および他のタイプの更新の両方を使用して、マネージドインスタンスにパッチを適用するプロセスを自動化します。Patch Manager は、Microsoft アプリケーション、Windows sellable サービスパック、およびLinux ベースインスタンスのマイナーアップグレードなど、オペレーティングシステムとアプリケーション両方の Amazon EC2 インスタンスに対するパッチ適用に使用できます。Amazon EC2 に加え、Patch Manager はオンプレミスサーバーへのパッチ適用にも使用できます。
<省略>
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

AWS Systems Manager Patch Manager

AWS Systems Manager Patch Managerを使うことでOSのパッチの適用が自動化できますので、脆弱性予防の対策になります。Amazon Inspectorと一緒に使うと、脆弱性の管理がカバーできるのではないかなと思います。

Windowsの例になりますが、下記の記事をご参照ください。

blog.serverworks.co.jp

Windows OSの例ですが、例えば、CriticalUpdates、SecurityUpdatesを適用するように設定し、環境ごとに適用日数を分けるとよいと思います。（例：検証環境でパッチをすぐに適用するが、本番環境のパッチは5-7日後適用するなど）

AWS Systems Manager Automation

Config ルールと合わせて、AWS Systems Manager Automationを使うことで、下記のような課題を解決できます。

例：

  • パブリックに公開されているS3バケットを検知(Config ルール)し、このS3を非公開にする（SSM Automation）。
  • 使っていないセキュリティグループを検知し(Config ルール)、このセキュリティグループを削除する（SSM Automation）。

参考記事： blog.serverworks.co.jp

SEC04-BP04 非準拠リソースの修復を開始する

非準拠リソースの中には、状況が独特で修復には人間の判断が必要となる場合がありますが、プログラムで定義できる標準的な対応で間に合う状況もあります。例えば、VPC セキュリティグループが誤って設定されている場合、標準的な対応として、許可されていないルールを削除して所有者に通知することができます。応答は、AWS Lambda 関数や AWS Systems Manager Automation ドキュメントで定義するか、任意の他のコード環境で定義できます。是正措置を行うために必要最低限のアクセス許可しか持たない IAM ロールを使用して、その環境を AWS に対して認証できるようにしてください。
このベストプラクティスが確立されていない場合のリスクレベル: 中
docs.aws.amazon.com

AWS Systems Manager Fleet Manager / Session Manager

前の記事で説明した通り、ネットワークの攻撃面を減少させるため、踏み台インスタンス(EC2)の代わりにAWS Systems ManagerのFleet Manager/セッションマネージャを使いましょう。

参考記事： blog.serverworks.co.jp

Amazon Route 53

DNSプロトコルは特に脆弱性が多いプロトコルです。DNS攻撃/対策方法については下記で説明しますが、下記の対策の必要性についてどこまで手厚く対応を行うかはご自身でご判断ください。

DNS攻撃対策について何もやっていない会社が多いです。参考までの情報ですが、現時点で(15/07/2024 - 13/08/2024のデータ)、DNSSECの世界導入率は34.56%です。日本は13.57%です。（参考URL）

個人的にはせめてDNSSEC/DNS Query Logsぐらいは有効にしたほうがよいと思います。

DNS 攻撃パターン

キャッシュポイズニング攻撃

攻撃者はDNSサーバーのキャッシュに偽のDNSレコードを挿入し、ユーザーを悪意のあるサイトに誘導します。この攻撃は、特定のDNSクエリに対して偽のレスポンスを送ることで実行されます。

対策方法：Amazon Route 53 ResolverのDNSSEC

blog.serverworks.co.jp

中間者攻撃（Man-in-the-Middle Attack）

攻撃者は通信路上に介在し、DNSリクエストやレスポンスを改ざんします。これにより、ユーザーがアクセスしようとしている正当なリソースの代わりに、攻撃者がコントロールするリソースに誘導される可能性があります。

対策方法：Amazon Route 53 ResolverのDNS-over-HTTPS

Amazon Route 53 ResolverのDNS-over-HTTPSを使うことで、オンプレミス環境<->AWS環境間のDNS応答の改ざんの対策になりますので、是非ご検討ください。

DNSリフレクション攻撃

この攻撃手法では、攻撃者が送信元IPアドレスを、攻撃対象のIPアドレスに偽装した問い合わせとして通常のDNSサーバーに送ります。DNSサーバーは、攻撃対象に通常のDNS応答を返すため、攻撃者から見るとDNSサーバーが攻撃を反射（リフレクション / reflection）しているように見えます。この攻撃は、DDoS攻撃の一種であり、多くの場合、ボットネットを使用して大量の偽装リクエストを送信します。

対策方法：AWS Shield, Amazon Route 53, DNS Query Logs

DNSアンプ攻撃

DNSアンプ攻撃は、DNSリフレクション攻撃の一形態であり、特に大きな応答を生成するリクエストを利用して攻撃の威力を増大させます。この攻撃により、攻撃者は少量のリクエストでターゲットに対するDDoS攻撃を強化することができます。たとえば、増幅率が最大で73倍に達することがあり、10バイトのDNSリクエストが730バイトの応答として返される可能性があります。これにより、少量のリソースでターゲットに大規模な負荷をかけることが可能になります。

対策方法：AWS Shield, Amazon Route 53, DNS Query Logs

DNSトンネリング

トンネリングとは、既存のプロトコルの上にデータを転送する方法です。基本的なプロトコルが専用のチャネルやトンネルを提供し、その中で実際に転送される情報を隠すことができます。この攻撃の「トンネル化」の部分は、データやコマンドを監視システムから隠すことにあります。攻撃者は、base32やbase64などの文字セットを使用したり、データを暗号化したりして、情報を隠すことができます。

具体的には以下のような問題が含まれます：

  • ①データの抽出（エクスフィルトレーション）

攻撃者がDNSトンネルリングを利用して、機密データを秘かに送信します。この方法は効率的ではないかもしれませんが、データを被害者のコンピュータから送信するのに効果的であり、目立たない手段です。

  • ②コマンド＆コントロール (Command and Control, C2)

攻撃者はDNSプロトコルを利用して、リモートアクセス型トロイの木馬（RAT）などを通じて簡単な制御コマンドを送信します。

  • ③IP-over-DNSトンネルリングDNSキャッシュポイズニング、man-in-the-middle攻撃、DNSリフレクション攻撃、DNSアンプ攻撃など、DNSの脆弱性を悪用する攻撃です。

これはありえない話のように聞こえるかもしれませんが、DNSリクエストと応答を利用してIPスタックを実装するツールが存在します。これにより、FTP、Netcat、sshなどを用いたデータ転送が比較的容易に行えるようになり、非常に不穏です。

対策方法：Amazon Route 53 Resolver DNS Firewall, DNS Query LogsとAmazon GuardDutyの組み合わせ

①Amazon Route 53 Resolver DNS Firewallを有効化/設定することで、DNSトンネリングなどの不審なDNSトラフィックを事前にブロックすることが可能になります。これにより、攻撃者がDNSを悪用してデータを外部に漏洩させたり、C2サーバーと通信することを未然に防ぐことができます。また、特定のDNSクエリやドメインを許可リストまたはブロックリストに追加することで、ネットワーク内のセキュリティをさらに強化できます。

さらに、DNS FirewallとGuardDutyのような異常検知サービスを組み合わせることで、より包括的なセキュリティ対策を講じることができ、リアルタイムで脅威を検知し、迅速な対応が可能になります。これにより、潜在的なセキュリティリスクに対する防御力が大幅に向上し、AWS環境の安全性を確保することができます。

②DNS Query LogsとAmazon GuardDutyの組み合わせしたことで下記の異常検知が発見できるようになります。

Trojan:EC2/DNSDataExfiltration

EC2 インスタンスが DNS クエリを使用してデータを密かに抽出しようとしています。 デフォルトの重要度: [High] (高)

データソース; DNS ログ

この検出結果は、AWS 環境のリスト化した EC2 インスタンスが、アウトバウンドデータ転送用の DNS クエリを使用しているマルウェアであることを知らせるものです。このタイプのデータ転送は、侵害されたインスタンスを示し、データの漏洩につながる可能性があります 通常、DNS トラフィックはファイアウォールでブロックされません。例えば、侵害された EC2 インスタンスのマルウェアは、データ (クレジットカード番号など) を DNS クエリ内にエンコードし、それを攻撃者が制御するリモート DNS サーバーに送信できます。

Amazon Route 53のDNSSECの有効化

DNSSecがないと攻撃者はDNSキャッシュポイズニングによって、偽のDNSエントリを注入すること(DNSキャッシュの改ざん)ができてしまいますので、ユーザーが本物のウェブサイトにアクセスしていると思っても、実際には悪意のあるサイトに誘導され、個人情報、認証情報の盗難やマルウェアの感染などのリスクが生じる可能性があります。そのため、DNSSECを利用することで、DNS応答の信頼性を確保し、このような攻撃を防ぐことが重要です。

DNSSEC有効化の手順：

blog.serverworks.co.jp

Amazon Route 53のDNSログの有効化

個人的にはDNSログを有効にしたほうが良いと思います。GuardDutyの分析項目が+1つになるからです。

例えば、下記のAWS公式ページの項目に「データソース: DNS ログ」が書いてある場合、そもそもDNS ログを有効にしないと発見できなくなる項目なので、DNS ログを有効にしないといけないと思っています。

CryptoCurrency:EC2/BitcoinTool.B!DNS

EC2 インスタンスが暗号通貨関連のアクティビティに関連付けられているドメイン名をクエリしています。
デフォルトの重要度: [High] (高)

データソース: DNS ログ

docs.aws.amazon.com

Amazon Route 53 Resolver DNS Firewallの設定

上記の「DNSトンネリング」の対策の１つとなりますので、必要に応じてご活用ください。

Route 53 Resolver DNS Firewallについての参考記事：

blog.serverworks.co.jp blog.serverworks.co.jp

Amazon Route 53 ResolverのDNS-over-HTTPS

ハイブリッドクラウドを使う場合、Amazon Route 53 Resolver (インバウンド/アウトバウンドエンドポイント)のDNS-over-HTTPSを使用することで、オンプレミス<–>AWS間の中間者攻撃の対策となります。

Amazon Route 53 ResolverのDNS-over-HTTPSについての参考記事：作成中

なお、エンドユーザーのクライアント端末<->オンプレミスのフールサービスリゾルバの通信の暗号化はAWS外の話となりますので、割愛させてください。

開発者向けの情報

私は開発側の人（プログラマー）ではないため、開発プロセスに一度も関わったことがないのでなんとも言えませんが、OWASPのレコメンデーションを読むと、アプリの開発時の下記のレコメンデーションがあるので是非ご活用ください。

インジェクション攻撃用の対策

  • プリペアド・ステートメントやORM (object-relational mapping)を使用して、SQLインジェクション攻撃を防止し、安全なデータ処理を実現しましょう。
  • データを受け取る際には、必ずバリデーションとフィルタリングを行い、許可された文字やデータ構造のみを受け入れるようにしましょう。これにより、SQLインジェクションやXSSなどの攻撃からシステムを保護することができます。
  • 最小権限の原則を適用しましょう。データベースへのアクセス権限を最小限に制限し、必要な権限のみを付与してください。
  • SQLインジェクションのリスクを軽減するために、SQLクエリにLIMITやその他の制御要素を使用して、大量のデータが漏洩するのを防ぎましょう。
  • データベース内で機密データを暗号化せずにプレーンテキスト(文章)で保存しないでください。

アプリケーションアーキテクチャの設計

  • アプリケーションの設計初期段階でセキュリティの側面を考慮することが重要ですので、アプリケーションの設計段階で早い段階からセキュリティの側面を考慮しましょう(OWASP Application Security Verification Standard (ASVS))。
  • 設計段階で潜在的な脅威とリスクを評価し、それらを防止する対策を講じましょう。
  • サーバー上のリソースの割り当てをユーザーごと、セッションごとに制限しましょう。これにより、リソースの濫用やサーバーの過負荷を防止できます。

サポートが終了した古いコンポーネントによる脆弱性

ウェブアプリケーションの中で、既知のセキュリティ欠陥を持つサードパーティのフレームワーク、ライブラリ、プラグイン、またはその他のコンポーネントが使用されています。攻撃者は、未適用のパッチや適切に構成されていないシステムを特定するための専用ツールを使用することで攻撃が容易になります。

  • 使用しているコンポーネントを定期的に更新しましょう。セキュリティに関する更新や修正のリリースを注意深く確認しましょう。
  • 使っていない依存関係、不要な機能、コンポーネント、ファイルを削除します。
  • コンポーネントを安全な公式ソースからのみダウンロードしてください。

認証と認可の設計

  • 以前の記事にも書いたのですが、脆弱なパスワード(例：12345, qwertyなど)を使ってはだめです。そもそもアプリ上で脆弱なパスワードを設定できないようにすればよいです。ユーザーに強力パスワードの作成を求めましょう(大文字、小文字、数字、英数字以外の文字を含むパスワード以外設定できないようにする)。
  • 多要素認証を使いましょう。
  • 数回のログイン失敗後にアカウントをロックアウトする仕組みを導入することは、ブルートフォース攻撃を防ぐための重要なセキュリティ対策です。このような制限を設けることで、不正アクセスのリスクを大幅に低減することができます
  • URL内にセッションIDを露出しないでください。

クロスサイトスクリプティング (XSS)攻撃用の対策

ユーザーセッションの乗っ取り、機密情報の盗難、悪意のあるサイトへのリダイレクトなど、XSS攻撃は重大なセキュリティリスクを引き起こす可能性がありますので、下記の対策が必要です。

  • データのエスケープ処理を自動的に行うフレームワークを使用しましょう。
  • HTTPリクエストからの信頼できないデータを変換しましょう。
  • コンテンツセキュリティポリシー（CSP）を使いましょう。

ログ記録およびセキュリティ監視の不備

ログ記録およびセキュリティ監視の不備があると、攻撃を気づかない可能性が高まっていますので、下記の対策が必要です。

  • 重要なイベントの記録を行うために、ログ機能を実装します。
  • 監視システムを導入し、ログを分析して疑わしい活動を検出し、インシデントが発生した場合に通知するようにします。
  • セキュリティインシデント対応手順を明確に定義し、チーム全体にその手順を共有しましょう。

AWSでAmazon CloudWatch, AWS CloudTrail, Amazon GuardDuty, AWS Config, AWS Security Hubなどがあるので、下記の記事をご参照ください。

blog.serverworks.co.jp

OWASPについて詳しくは下記の記事をご参考ください。

owasp.org

owasp.org

次の記事では、運用フェーズの中で、ランサムウェア対策や他のサイバー攻撃に対しての対策について説明したいと思います。

以上、御一読ありがとうございました。

本田 イーゴリ (記事一覧)

カスタマーサクセス部

・2024 Japan AWS Top Engineers (Security)
・AWS SAP, DOP, SCS, DBS, SAA, DVA, CLF
・Azure AZ-900
・EC-Council CCSE

趣味：日本国内旅行(47都道府県制覇)・ドライブ・音楽