クラウドにおけるDDoS攻撃の防御方法について

本文の内容は、2023年1月24日にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/how-to-prevent-ddos-attack-cloud)を元に日本語に翻訳・再構成した内容となっております。 クラウド環境におけるDDoS攻撃を防ぐために、この（DDoS攻撃の）脅威に関連する侵害の兆候を早期に検出する方法を学びたいのであれば、この記事は、クラウド・インフラストラクチャを保護するために必要なベストプラクティスの大半を説明しています。 2022年1月から7月にかけて、Sysdig脅威リサーチチームはグローバルハニーネットシステムを導入し、複数の攻撃ベクトルによる多数の侵害をキャプチャーしました。2022版クラウドネイティブな脅威に関するレポート（日本語版）で2021年第4四半期と2022年第1四半期の攻撃タイプを比較すると、クリプトマイニングからDDoS（分散サービス妨害）活動へと明らかにシフトしています。 攻撃タイプの経時的な比率（2021年第4四半期） 攻撃タイプの経時的な比率（2022年第1四半期）

クラウドにおけるDoS攻撃の技術・手法

前回は、KubernetesにおけるDoS攻撃を軽減するために、CalicoやFalcoなどのオープンソースツールを用いて、DoS防御やランタイム時のDoS検知を行う方法について解説しました。次の記事では、特にクラウド環境 – AWS、Azure、GCPなど – におけるDoS攻撃の緩和方法について説明することを目的としています。 DDoS攻撃のパターンと動作は、OSIモデル内の異なるレイヤーに分離することができます。

• 例えば、Application-Layerの攻撃は、HTTP/sレベルのものです。これはOSIモデルの最上位であるレイヤー7です。HTTP/sアプリケーションにDNSクエリーやHTTP GETリクエストを殺到させることは、「Killnetサイバー攻撃を検知」の記事からもわかるように、簡単に実現できる方法です。
• 攻撃者は、TCP（レイヤー4）またはUDP/ICMPアクティビティ（レイヤー3）を介してDOSアクティビティを引き起こすこともできます。これらは、ネットワークやサーバーが正当なネットワーク・トラフィックを処理できなくなるまで殺到させます。攻撃者は、ターゲットサーバーのネットワーク接続を飽和させることを目的としています。
• 最後に、このような混乱を引き起こす可能性があるのは、攻撃者だけではありません。インフラストラクチャーの堅牢性をテストし、ツールやサービスを使ってトラフィックを増やし、検知ツールがどのような挙動を示すかを確認するとよいでしょう。

このブログ記事では、CNCFプロジェクトFalcoを使用して、クラウドでのDoS攻撃につながるIndicators of Compromise（IoC）を検出することを目的としています。これを達成するために、Falcoは様々なクラウドプロバイダーの監査ロギングサービスにプラグインする必要があります。ありがたいことに、Falcoは各クラウドデータソースのための専用プラグインを提供しています。 予想されるネットワークトラフィック/挙動を時系列で監視することで、実行時に異常なネットワーク挙動を検出するためのFalcoのルールを設計することができます。

ブルートフォースDDoS攻撃を防御する方法

出発点として、お客様のウェブサーバーがブルートフォース攻撃から保護されていることを確認することが重要です。攻撃者は、サーバーへのアクセスを取得したり、一時的にサーバーを応答不能にすることを目的としています。ブルートフォース攻撃では、正しいパスワードが見つかるまで、何千、何百万ものパスワードを試行します。 一方、エンドユーザーは、この種の攻撃が成功しないように、強力なパスワードを生成する際にセキュリティポリシーに従わなければななりません。また、ほとんどのクラウドプロバイダーは、ブルートフォース攻撃を防ぐために、レートリミットのようなツールを提供しています。

• Microsoft Azure レートリミット [ドキュメント] 
• Google Cloud レートリミット [ドキュメント] 
• アマゾンAWS レートリミット [ドキュメント]
• IBM Cloud レートリミット [ドキュメント]

アカウント乗っ取り詐欺の検知

脅威を検知する主なソリューションの1つは、アプリケーションのログインページで、漏洩した認証情報を使用してユーザーアカウントに不正アクセスされていないか監視することです。アカウント乗っ取りは、攻撃者が人のアカウントに不正にアクセスするオンラインの違法行為です。 AWSのWAFテクノロジーの場合、潜在的な不正アクセスを検知するATP（Account Takeover Prevention）機能を備えています。これは、DoS攻撃につながる可能性のある最も明確なIoCです。 攻撃者は、盗んだ認証情報を使用したり、一連の試行を通じて被害者のパスワードを推測するなど、さまざまな方法でエンドユーザーのアカウントにアクセスすることができます。Falcoは、各クラウドプロバイダー（GCP、AWS、Azureなど）のクラウド監査ロギングサービスにプラグインしているので、例えば、通常とは異なるIPからのAWSアカウントログインを検出するFalcoのルールを作成することができます：

- rule: Console Login Success From Untrusted IP
  desc: Detect a console login success from an untrusted IP address
  condition: >-
    aws.eventName="ConsoleLogin" and
    jevt.value[/responseElements/ConsoleLogin]="Success" and not aws.sourceIP in
    (trusted_ip_addresses)
output: >-
    Detected a console login success from an untrusted IP address (requesting
    user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region,
    arn=%jevt.value[/userIdentity/arn], user agent=%jevt.value[/userAgent])
priority: info
source: aws_cloudtrail

ユーザーが「ログインすべき」IPアドレスが分かっている場合、それらをtrusted_ip_addressesリストに追加することができます。そうすれば、潜在的に悪意のあるユーザーがエンドユーザーの認証情報にアクセスし、クラウド環境にアクセスしようとした場合、不明なIPから環境にアクセスしたことが通知されるようになります。 このようなリアルタイムのアラートを受けて、アカウントにMFAを適用したり、ユーザーが正規にアクセスしたかどうかが分かるまでアカウントを一時的に停止したりするなど、プロアクティブなアクションを適用することが可能です。ユーザーがMFAを使わずにログインに成功した場合、以下のルールをトリガーします。

- rule: Console Login Without MFA
  desc: Detects a console login without MFA.
  condition: >-
    aws.eventName="ConsoleLogin" and not aws.errorCode exists and
    jevt.value[/userIdentity/type]!="AssumedRole" and
    jevt.value[/responseElements/ConsoleLogin]="Success" and
    jevt.value[/additionalEventData/MFAUsed]="No"
  output: >-
    Detected a console login without MFA (requesting user=%aws.user, requesting
    IP=%aws.sourceIP, AWS region=%aws.region)
  priority: critical
  source: aws_cloudtrail

私たちの最も強い推奨事項の1つであるMFAをすでに組織内で実施している場合（セキュリティの別のレイヤーを追加する）、あなたは正しい決断をしています。 しかし、インサイダー脅威や、MFAスパミングによってアクセス権を得た高度な脅威行為者は、完全な権限を持つ新しいIAMユーザーを作成する際に、検出を回避するためにMFAを無効にすることを検討する可能性があるのです。IAMグループのMFAが無効化または削除されたときに検出することで、プラットフォームチームがクラウドプロバイダーへの安全でないログインを防止することができます。

- rule: Azure Deactivate MFA for User Access
  desc: >
    Multi-factor authentication requires an individual to present a minimum of
    two separate forms of authentication before access is granted. Multi-factor
    authentication provides additional assurance that the individual attempting
    to gain access is who they claim to be. With multi-factor authentication, an
    attacker would need to compromise at least two different authentication
    mechanisms, increasing the difficulty of compromise and thus reducing the risk.
  condition: >-
    jevt.value[/operationName]="Disable Strong Authentication" and
    jevt.value[/properties/result]="success"
  output: >-
    Multi-factor authentication configuration has been disabled for a user
    (requesting user=%jevt.value[/properties/initiatedBy/user/userPrincipalName],
    requesting IP=%jevt.value[/properties/initiatedBy/user/ipAddress],
    target user=%jevt.value[/properties/targetResources/0/userPrincipalName])
  priority: warning
    source: azure_platformlogs

アクセス制御リストが過剰に許可されていることを検出する

すべてのクラウドプロバイダーには、アクセスコントロールリスト（ACL）に似た機能があります。ACLは、サブネットレベル（OSIのレイヤー3およびレイヤー4）で特定のインバウンドまたはアウトバウンドトラフィックを許可または拒否するものです。VPCにセキュリティのレイヤーを追加するために、セキュリティ・グループのルールと同様のルールでVPC用のカスタム・ネットワークACLを作成することができます。 残念ながら、一部の組織では、これらの ACL を公共のインターネットに公開しています。 その結果、これらの過度に寛容な ACL により、クラウド環境が外部の敵対者からプローブされる可能性があります。クラウド環境をエアギャップすることで、外部からのプローブを防ぐことができますが、多くのアプリケーションはパブリック・インターネットに開放する必要があります。 そのため、特にこれが必ずしも必要でない場合は、ACLがパブリックアクセスで作成されたときに検出するためにFalcoを使用することが重要です：

- rule: Create a Network ACL Entry Allowing Ingress Open to the World
  desc: >-
    Detects Access Control List creation allowing ingress open to the world
  condition: |
    aws.eventName="CreateNetworkAclEntry" and not aws.errorCode exists and (
      not (
        jevt.value[/requestParameters/portRange/from]=80 and
        jevt.value[/requestParameters/portRange/to]=80
      ) and
      not (
        jevt.value[/requestParameters/portRange/from]=443 and
        jevt.value[/requestParameters/portRange/to]=443
      ) and
      (
        jevt.value[/requestParameters/cidrBlock]="0.0.0.0/0" or
        jevt.value[/requestParameters/ipv6CidrBlock]="::/0"
      ) and
        jevt.value[/requestParameters/egress]="false" and
        jevt.value[/requestParameters/ruleAction]="allow"
      )
  output: >-
      Detected creation of ACL entry allowing ingress open to the world
      (requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS
      region=%aws.region, arn=%jevt.value[/userIdentity/arn], network acl
      id=%jevt.value[/requestParameters/networkAclId], rule
      number=%jevt.value[/requestParameters/ruleNumber], from
      port=%jevt.value[/requestParameters/portRange/from], to
      port=%jevt.value[/requestParameters/portRange/to])
  priority: error
  source: aws_cloudtrail

ACLは、State-Exhaustion攻撃を防御するのに役立ちます。ネットワーキング層（レイヤー4）では、攻撃者はSYNフラッディングを実現しようとします。SYNフラッドはサービス拒否の一種で、攻撃者が接続を確定させずにサーバーへの接続を急速に開始します。サーバーはその後、（TCPハンドシェイクのワークフローの一部として）半開きの接続を待つために過剰なリソースを費やす必要があり、システムが正当なイングレストラフィックに反応しないようにするために必要な相当量のリソースを消費します。 SYNフラッディングは、ルーター、ファイアウォール、イングレスコントローラー、ロードバランサー、Apacheなどのアプリケーションサーバーなど、ほとんどのネットワーク／セキュリティデバイスに存在するTCP接続状態テーブルを消費します。ネットワークへのアクセスをロックダウンすることで、このようなDynの攻撃を防ぐことができます。

Webアプリケーションファイアウォールの設定改善

ウェブアプリケーションファイアウォール（WAF）でアプリケーション（レイヤー7）のDDoS防御を設定する。これは、クラウドプロバイダーが提供するWAF技術で実現することも、サードパーティーベンダーを経由して実現することもできます。 AWSクラウドの場合、独自のWAF機能を提供しています。これは L7 リソースに転送される HTTP と HTTPS のリクエストを監視し、それらのリクエストの特性に基づいてコンテンツへのアクセスを制御することができます。ACL を利用して、単一の IP アドレスからのトラフィック量に対してレートベースのルール制 限を適用します。これらは、アプリケーションに対するDDoS防御の要件となります。 画像はAWS WAFの公式ページより引用 上記のACLの項で紹介したSYNフラッディングと同様に、HTTP/SフラッディングもDoSを引き起こすための一般的な攻撃手法です。これは、HTTP GETまたはPOSTアクティビティで構成されるDNSクエリをアプリケーション層に殺到させることで発生します。その目的は、メモリ、CPU、帯域幅など、アプリケーションのリソースを過剰に消費させることです。 攻撃者の視点から見ると、被害者のインフラストラクチャーのどこに欠陥があるのかを知る必要があります。これらのリクエストは、データベースやアプリケーションの処理に遅延を生じさせるでしょうか？ もしそうなら、基盤となるウェブサービスは悪意のあるリクエストに阻まれ、サービスを利用しようとする他のユーザーにサービスを提供することができないはずです。L7 型の攻撃と同様に、悪意のあるトラフィックと予想される通常のトラフィックの違いを知ることは、脅威を軽減するために不可欠です。 このシナリオでは、クラウド環境内のVM/EC2インスタンスにFalcoをインストールすることができます。 ホストからのシステムコールに基づき、アプリケーションレベルのトラフィックアクティビティを確認することができます。Falcoでは、信頼できるドメイン名（sysdig.com、github.com、google.com）のリストを定義するオプションがあります。これらのドメイン名のいずれかによって解決されないIPアドレスへのネットワーク接続は、ポリシーをトリガーします。

- list: trusted_domains
  items: [sysdig.com, github.com, google.com]
- rule: Unexpected outbound network connection
  desc: Detect outbound connections with destinations not on allowed list
  condition: >
    Outbound
    and not (fd.sip.name in (trusted_domains))
  output: Unexpected Outbound Connection
    (container=%container.name
    command=%proc.cmdline
    procpname=%proc.pname
    connection=%fd.name
    servername=%fd.sip.name
    serverip=%fd.sip
    type=%fd.type
    typechar=%fd.typechar
    fdlocal=%fd.lip
    fdremote=%fd.rip)
  priority: NOTICE

Webトラフィックのフィルタリング

WAFルールを作成し、HTTPヘッダー、HTTPボディ、お客様のURIなどの条件に基づいて、Webリクエストをフィルタリングします。 同様に、ACLルールを使用して、IPアドレスに基づくWebトラフィックをフィルタリングします。ACLの安全でない設定（公衆インターネットに公開されている）を検出するためにFalcoを使用するのと同様に、ボットネット活動にしばしば関連するC2サーバーに向かう接続を検出するためにFalcoのルールを使用することができます。

- list: c2_server_ip_list
  items: [1.234.21.73, 100.16.107.117, 100.6.8.7]

- rule: Outbound Connection to C2 Servers
  desc: Detect outbound connection to command & control servers
    condition: outbound and fd.sip in (c2_server_ip_list)
  output: Outbound connection to C2 server (command=%proc.cmdline pid=%proc.pid connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository)
  priority: WARNING
  tags: [network]

もちろん、好きな脅威のフィードを使用することができます。c2_server_ip_listは、Feodo Tracker C2 IP Blocklist内の最初の3つのIPアドレスに基づいて作成しました。 Abuse.chのチームは、これらのIPをフィルタリングして、トロイの木馬化ローダー、ランサムウェア、サービス拒否などのさまざまな攻撃手法にどのように使用されているかをより理解するためのシンプルなUIを提供しています。 C2サーバーへの疑わしいアウトバウンドトラフィックを検出するのと同様に、私たちはクラウドサービスへの疑わしいインバウンドトラフィックも検出したいと考えています。

- rule: AWS Suspicious IP Inbound Request
  desc: >-
    Detect inbound requests from known suspicious IP sources, such as TOR exit
    nodes, to AWS services.
  condition: >-
    aws.sourceIP in (ti_anon_ips) and not (aws.eventName="ConsoleLogin" and
    jevt.value[/responseElements/ConsoleLogin]="Failure")
  output: >-
    Suspicious IP Inbound Request (aws.sourceIP=%aws.sourceIP,
    aws.region=%aws.region, aws.eventName=%aws.eventName, aws.user=%aws.user,
    userAgent=%jevt.value[/userAgent], errorMessage=%jevt.value[/errorMessage])
  priority: warning
  Tags: [Cloud, AWS]
  source: aws_cloudtrail

同じFalcoのルールロジックを使って、Torなどのリレーネットワークへの接続をブロックすることができますが、TorはDDoS攻撃を行うための理想的なユースケースではないことに注意することが重要です。 目標は被害者の帯域幅を圧倒することなので、ハンドシェイクや協調を必要としないUDPパケットを送るのが一般的です。ホストとワークロードのレベルでは、標準的なポート 53 のトラフィックから逸脱した不審な UDP トラフィックを Falco で検出することができます。

- rule: Unexpected UDP Traffic
  desc: UDP traffic not on port 53 (DNS) or other commonly used ports
  condition: >-
    (inbound_outbound) and do_unexpected_udp_check and fd.l4proto=udp and not
    Expected_udp_traffic
  output: >
    Unexpected UDP Traffic Seen (user.name=%user.name
    user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline connection=%fd.name
    proto=%fd.l4proto evt.type=%evt.type %evt.args container.id=%container.id
    evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
    user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid
    group.name=%group.name container.name=%container.name
    image=%container.image.repository)
  priority: notice
  source: syscall

しかし、TorはすべてのIPパケットではなく、正しく形成されたTCPストリームのみを転送するので、Tor上でUDPパケットを送ることはできません（SYNフラッディングのようなこの攻撃の特殊な形式もできません）。 そのため、一般的に、効果的なDDoS攻撃を行うのに十分な帯域幅を制御している攻撃者は、Torなしでも十分にそれを行うことができます。とはいえ、Torは攻撃者が何らかの形で匿名性を維持できるため、DDoS攻撃の前にデータを漏洩させるのに有効です。もっと知りたい方は、Torネットワーク接続を検出する方法の記事をご覧ください。 利用するクラウドプロバイダーによっては、独自の脅威フィードをプラグインして、既知の悪質なコマンド＆コントロール（C2）ボットネットサーバーからの接続かどうかを判断し、これらの攻撃をブロックするルールが提供されることがよくあります。しかし、ホストのシステムコールレベルで潜在的に悪意のある接続や偵察スクリプトを検出するために、Falcoのようなオープンソースツールがあるのは良いことです。

- rule: Detect reconnaissance scripts
  desc: This rule detects the use of reconnaissance scripts.
  condition: evt.type=execve and reconnaissance_scripts
  output: >-
    Detected reconnaissance script executing (proc.cmdline=%proc.cmdline
    container=%container.info evt.type=%evt.type
    evt.arg.request=%evt.arg.request proc.pid=%proc.pid proc.cwd=%proc.cwd
    proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
    proc.exepath=%proc.exepath user.uid=%user.uid user.loginuid=%user.loginuid
    user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
    group.name=%group.name container.id=%container.id
    container.name=%container.name image=%container.image.repository)
  priority: warning
  source: syscall

APIセキュリティ

すべての L7 WAF 技術は、クラウド環境の開発と設計のプロセスに組み込むことができ、ある種の API セキュリティを提供する必要があります。 API は、ユーザーとのインタラクションを生成するための関連コマンド、ペイロード、およびデータのすべてをパッケージ化しているため、開発者にとって理想的なものです。しかし残念なことに、このコンテキストとインタラクティビティのすべてが、セキュリティ・リスクを生み出します。企業がAPIの利用を拡大し続けることで、未知の攻撃対象が増加します。 多くの企業はAPIをシャドーイングしておらず、APIを隠す方法や、特定のAPIが非推奨かどうかを確認する知識もありません。どれがサードパーティ製で、どれがサポートされなくなったかを知らなければ、これらのAPIの多くを保護されないままにしておく危険性があります。 残念ながら、WAF は API を保護するために必要な可視化インベントリ追跡、リスク評価、およ び脅威防御の要件に対応していません。 Falcoでは、API キーがいつ作成されたかを検出することができ、それが誰によって作成さ れたか、いつ作成されたか、キー ID がどのプロジェクトに関連するかを確認するための全体的な監 査に役立てることができます。

- rule: GCP Create API Keys for a Project
  desc: Detects the creation of API keys for a project.
  condition: >-
    gcp.serviceName="apikeys.googleapis.com" and gcp.methodName endswith
    ".ApiKeys.CreateApiKey"
  output: >-
    An API key for a project has been created (requesting user=%gcp.user,
    requesting IP=%gcp.callerIP, project
    id=%jevt.value[/protoPayload/request/projectId], key
    id=%jevt.value[/protoPayload/response/keyId])
    priority: warning
  source: gcp_auditlog
  append: false
  exceptions: []

GKE、EKS、AKSなどのマネージドクラウドKubernetesサービスで稼働するクラウドネイティブなコンテナ型ワークロードに関して、FalcoコンテナがKubernetes APIサーバーと通信できるタイミングを検出することができます。こうすることで、K8sレベルで異常な/予期しないDoS活動を検出することができます。

- rule: Contact K8S API Server From Container
  desc: Detect attempts to contact the K8S API Server from a container
  condition: >
    evt.type=connect and evt.dir=< and
    (fd.typechar=4 or fd.typechar=6) and
    container and
    not k8s_containers and
    k8s_api_server and
    not user_known_contact_k8s_api_server_activities
  output: Unexpected connection to K8s API Server from container (command=%proc.cmdline pid=%proc.pid %container.info image=%container.image.repository:%container.image.tag connection=%fd.name)
  priority: NOTICE
  tags: [network, k8s, container, mitre_discovery]

KubernetesのAPIレベルで異常なDoS活動を検出することが、Kubesharkによってさらに容易になりました。 Kubesharkユーティリティは、Kubernetesクラスター内のコンテナやPodに出入りするすべてのAPIトラフィックとペイロードの深い可視化と監視を提供します。これらのクラウドネイティブなワークロードは、しばしばそれらが常駐するクラウドサービスにまで拡張されます。 Kubesharkは、APIトラフィックから推測される自動生成されたAPIとサービスインベントリを提供することで支援します。そうすれば、すべてのAPIトラフィックとペイロードを（ライブであれ履歴であれ）監視し、APIドリフトとAPIアノマリーを見つけることができます。これらをソースまで追跡することができるようになります。 Kubernetes を使用しているかどうかに関わらず、クラウド上のすべての組織は POST/GET アクティビティを自動的に追跡し、正当/不正なエンドポイントや宛先アドレスにする必要があります。社内のAPIリスク評価、または前述のようなサードパーティソフトウェアを使用して、継続的にAPIの発見と可視化を実行することをお勧めします。クラウドプロバイダーはAPI脅威の検知機能を提供し、これらの脅威をリアルタイムでネイティブに軽減することができるでしょうか？ 例えばAWS GuardDutyは、DNS、TCP、UDP、UDP on TCPポート、および一般的でないプロトコルアクティビティに対するDoSアクティビティを検出することができます。

クラウドでのDDoS攻撃を防ぐための緩和戦略

要約すると、今後クラウドでのDDoS攻撃を防ぐためには、アプリケーション層とネットワーク層の両方に適用される特定の緩和戦略を適用する必要があるということです。 クラウドでの DDoS 攻撃を防止するために、いくつかの手順を実行することができます：

1. 既知の悪意のあるソースからのトラフィックをフィルタリングおよびブロックするようにネットワークを構成する：

ファイアウォールやその他のネットワークセキュリティツールを使用する。

2.コンテンツデリバリーネットワーク（CDN）を使用する：

CDNは、複数のサーバーにトラフィックを分散させることができるため、DDoS攻撃によるネットワークへの侵入をより困難にすることができます。

3.ネットワークに異常なトラフィックパターンがないか監視する：

特定のソースからのトラフィックが突然増加するなど、通常とは異なるトラフィックパターンがないか、定期的にネットワークを監視します。これは、DDoS攻撃を示唆している可能性があります。

4.クラウドテナントのアカウントテイクオーバーを防御する：

多くのクラウドプロバイダーは、デフォルトでビルトインのアカウント乗っ取りおよび緩和機能を提供しています。MFAは、盗まれた認証情報でコンソールにアクセスする際に、セキュリティの層を厚くします。前述のとおり、クラウドインフラクチャーに対して不正なパスワードの試行回数を制限するには、レートリミッティングが有効です。

5.クラウドベースのDDoS防御サービスを利用する：

クラウドベースのDDoS保護サービスはいくつかあり、DDoS攻撃がネットワークに到達する前に吸収し、軽減するのに役立ちます。

6.DDoS 攻撃に対応する計画を立てる：

DDoS攻撃への対応について、誰に連絡するか、どのような手順で攻撃を軽減するかなど、計画を立てておくことが重要です。 これらのステップに従うことで、クラウドベースのシステムとサービスをDDoS攻撃から保護することができます。 クラウドプロバイダーは、お客様をDDoS攻撃から保護するために素晴らしい仕事をしています。実際、今年Google Cloudは、4600万Requests Per Second（RPS）という過去最大のLayer 7 DDoS攻撃をブロックしました。とはいえ、このセキュリティ機能は、すべてのお客様に対してデフォルトで有効になっているわけではありません。標的となった企業は、GoogleのCloud Armorソリューションのライセンスを持つエンドユーザーでした。このお客様は、Cloud Armor のような WAF ソリューションの強力なユースケースである、一連の HTTPS DDoS 攻撃の標的にされていました。 ウクライナ DDoS 攻撃 国家間の戦争の武器となるDDoS攻撃が増加していることを検知しています。特定の政治的イベントに対応してDDoSキャンペーンを成功させるためには、サイバー犯罪者グループはボットネットインフラストラクチャーを迅速にスケールアップする必要があります。 これらのDDoS攻撃は、標的となるものや攻撃者の目的に応じて、市民的、社会的、経済的な損害をもたらす可能性があります。たとえば、紛争が始まった当初、親ロシア派のDDoS攻撃は、ウクライナの金融機関へのアクセスを妨害することができました。

まとめ

記事で述べたように、クラウドでDoS攻撃を実現する方法は複数存在します。 Volumetric 攻撃（レイヤー3）は、今後もあらゆるWeb向けアプリケーションで最も一般的なアプローチとなるでしょう。UDPリフレクション攻撃などのネットワークフラッディング技術は、TCPハンドシェイクを待つ必要がないと述べたように、攻撃者はUDPやICMPフラッドでアプリケーションにスパムを送ることができるため、理想的な手法と言えます。 時が経つにつれ、より洗練された L7 攻撃（HTTP/DNS フラッドを狙ったものではなく、API を攻撃するもの）が増えてきています。 多くの WAF 技術は、正当な API 接続と不正な API 接続を保護するのに必要な可視性を欠いているため、多くの接続がガードレールなしで通過することになります。開発者のミス、ベストプラクティスの欠如、不適切なトレーニングは、悪意ある者に簡単に利用される脆弱性につながる可能性があります。APIはバックエンドシステムとの高速通信を可能にすることが多く、たとえ完璧にコーディングされていても、自動化された攻撃やビジネスロジックの乱用の格好のターゲットになってしまいます。 というわけで、クラウドにおけるサービス拒否を防御する方法について、ご理解いただけたでしょうか。

---