从2022年1月到7月，Sysdig威胁研究团队实施了一个全球蜜网系统，通过多个攻击载体捕获了大量漏洞。Sysdig在《2022年云原生威胁报告》中指出，相较2021年，2022年的攻击类型已经从加密挖矿明显转向分布式拒绝服务（DDoS）活动。

如果组织希望通过检测与此威胁相关的早期迹象，来了解如何在云环境中预防DDoS攻击，那么本文将介绍保护云基础设施所需的大多数最佳实践。

云中DoS攻击的技术和方法

在OSI（Open Systems Interconnection）模型中，DDoS攻击的模式和行为可以划分为不同的层。

例如，应用层攻击是HTTP/s级别的任何攻击。这是第7层，OSI模型的顶部。用DNS查询或HTTP GET请求充斥HTTP/s应用程序是实现这一点的简单方法，因为我们可以检测到Killnet网络攻击。

攻击者还可以在TCP（第4层）或通过UDP/ICMP活动（第3层）发起DOS活动。这些活动会淹没网络和服务器，直到它们无法处理任何合法的网络流量。攻击者的目标是饱和目标服务器的网络连通性。

最后，不仅攻击者可以造成这种破坏。您可能希望测试基础设施的健壮性，使用工具或服务来增加流量，并查看检测工具的行为。

在这篇文章中，我们的目标是使用CNCF Project Falco来检测导致云中的DoS攻击的妥协指标（IoC）。为了实现这一点，Falco必须插入各种云提供商的审计日志服务。值得庆幸的是，Falco为每个云数据源提供了一个专用插件。

通过长期监控预期的网络流量/行为，我们可以设计Falco规则来检测运行时的异常网络行为。

如何防范暴力破解DDoS攻击

首先，确保Web服务器免受暴力攻击是很重要的。攻击者的目标是访问服务器或暂时使其失去响应。暴力破解包括尝试数千甚至数百万个密码，直到找到正确的密码。

一方面，终端用户在生成强密码时必须遵循安全策略，这样这种类型的攻击才不会成功。另一方面，大多数云提供商（例如微软、谷歌、亚马逊、IBM等）提供了诸如速率限制之类的工具来防止暴力攻击。

检测账户接管欺诈

主要的威胁检测解决方案之一是监视应用程序的登录页面，以防止使用受损凭证对用户帐户进行未经授权的访问。账户接管是一种在线非法活动，攻击者在未经授权的情况下访问用户的账户。

就AWS的WAF技术而言，它具有帐户接管预防（ATP）功能，可以检测潜在的未经授权的访问，这是可能导致DoS攻击的最明显的IoC。

攻击者可以通过多种方式访问最终用户的帐户，例如使用被盗的凭据或通过一系列尝试猜测受害者的密码。由于Falco插入了每个云提供商（包括GCP、AWS和Azure）的云审计日志服务，我们可以创建Falco规则来检测来自不寻常IP的AWS帐户登录，例如：

- 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地址登录，就可以将这些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

如果组织中已经实施了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创建一个自定义的网络ACL，其规则与安全组的规则相似，以便为VPC添加额外的安全层。

不幸的是，一些组织向公共互联网开放了这些ACL。因此，这些过度许可的ACL允许外部攻击者探测云环境。气隙/物理隔离（Air Gapping）云环境将阻止外部实体探测组织的云环境，然而，许多应用程序需要向公共互联网开放。这就是使用Falco来检测何时创建具有公共访问权限的ACL至关重要的原因所在：

- 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有助于防止状态耗尽攻击。在网络层（第3层），攻击者将尝试实现SYN洪水（SYN flood）攻击。SYN flood是一种拒绝服务攻击形式，攻击者在没有结束连接的情况下快速发起到服务器的连接。然后，服务器必须花费大量的资源等待半打开的连接（作为TCP握手工作流的一部分），从而消耗大量的资源，使系统对合法的输入流量没有响应。

SYN洪水将消耗出现在大多数网络/安全设备中的TCP连接状态表，例如路由器、防火墙、入口控制器、负载平衡器，以及像Apache这样的应用服务器。锁定对网络的访问可以防止这类Dyn攻击。

改进Web应用防火墙配置

使用WAF（Web应用程序防火墙）配置应用（第7层，L7）DDoS保护。这既可以通过云提供商提供的WAF技术实现，也可以通过第三方供应商实现。

就AWS云而言，它们提供了专属的WAF特性。它监视转发到L7资源的HTTP和HTTPS请求，并允许组织根据这些请求的特征控制对内容的访问。它利用ACL对来自任何单个IP地址的流量实施基于速率的规则限制。这些是DDoS保护对应用程序的要求。

就像我们在上面ACL部分提到的SYN洪水一样，HTTP/S洪水是导致DoS的一种流行攻击方法。这是由于应用程序层充斥着DNS查询造成的，这些查询由HTTP GET或POST活动组成。目标是消耗过多的应用程序资源，如内存、CPU和带宽。

从攻击者的角度来看，他们需要知道受害者基础设施中的缺陷在哪里。这些请求是否会导致数据库或应用程序处理延迟？

如果是这样，底层Web服务就会受到恶意请求的阻碍，因此无法交付给其他想要使用该服务的用户。与任何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

过滤网络流量

创建WAF规则，根据HTTP标头、HTTP正文或客户URI等条件过滤出web请求。

同样地，ACL规则也可以通过IP地址对web流量进行过滤。与使用Falco检测ACL（对公共互联网开放）的不安全配置类似，组织可以使用Falco规则检测到通常与僵尸网络活动相关的C2服务器的连接。

- 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]

当然，组织可以使用任何想要的威胁信号。我们基于Feodo Tracker C2 IP Blocklist中的前三个IP地址创建了c2_server_ip_list。

Abuse.ch的团队提供了一个简单的UI来过滤这些IP，以更好地了解它们如何用于各种攻击技术，如木马加载程序、勒索软件和拒绝服务。

与检测到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数据包，因为这些不需要握手或协调。在主机和工作负载级别，我们可以检测到Falco偏离标准端口53流量的可疑UDP流量：

- 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只传输正确形成的TCP流，而不是所有的IP数据包，所以不能通过Tor发送UDP数据包（也无法实现这种攻击的特殊形式，比如SYN洪水）。

所以，一般来说，控制足够带宽来发起有效DDoS攻击的攻击者在没有Tor的情况下也能做到。也就是说，Tor对于DDoS攻击之前的数据泄露非常有用，因为它可以确保攻击者保持某种形式的匿名性。

根据组织使用的云提供商的不同，他们通常会插入自己的专有威胁源，以确定连接是否来自已知的恶意命令和控制（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是第三方的，哪些是不再受支持的，就无法有效地保护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: []

对于在托管云Kubernetes服务（如GKE、EKS和AKS）中运行的云原生容器化工作负载，Falco可以检测容器何时可以与Kubernetes API服务器通信。这样，我们就可以在K8级别检测到任何不寻常/意外的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]

使用Kubeshark可以更轻松地在Kubernetes的API级别上检测不寻常的DoS活动。

kubesshark实用程序提供了对所有API流量和有效负载的深度可见性和监控，这些API流量和有效负载进出Kubernetes集群中的容器和pod。这些云原生工作负载通常扩展到它们所在的云服务。

Kubeshark通过提供自动生成的API和服务目录（从API流量推断）来提供帮助。这样，我们就可以监控所有API流量和有效负载（无论是实时的还是历史的），以发现API漂移（API drift）和API异常。我们可以追踪到源头。

无论是否使用Kubernetes，云中的所有组织都需要自动跟踪POST/GET活动，并跟踪到合法/非法端点或目的地址。我们建议通过内部API风险评估或使用之前提到的第三方软件来执行持续的API发现和可见性。您的云提供商是否提供API威胁检测，能否实时减轻这些威胁？

例如，AWS GuardDuty将检测DNS、TCP、UDP、TCP端口上的UDP的DoS活动，以及一般的异常协议活动。

防止云中DDoS攻击的缓解策略

我们发现DDoS攻击正在迅速增长，成为国家战争的武器。为了对特定的政治事件进行成功的DDoS攻击，网络犯罪组织正在迅速扩展他们的僵尸网络基础设施。这些DDoS攻击可能会导致民事、社会或经济损失，这取决于具体的攻击目标。

总之，我们需要应用某些适用于应用程序层和网络层的缓解策略，以防止未来在云中发生DDoS攻击。

组织可以采取以下几个步骤来帮助防止云中的DDoS攻击：

• 配置网络以过滤和阻止来自已知恶意源的流量：使用防火墙和其他网络安全工具。
• 使用内容分发网络（CDN）: CDN可以帮助在多个服务器上分配流量，使DDoS攻击更难以淹没您的网络。
• 监控网络中不寻常的流量模式：定期监控网络中不寻常的流量模式，例如来自特定来源的流量突然增加，这可能表明DDoS攻击。
• 防止云租户的帐户接管：许多云提供商默认提供内置的帐户接管和缓解功能。当使用被盗凭证访问控制台时，MFA提供了额外的安全层。如前所述，速率限制是限制对云基础设施尝试的错误密码数量的好方法。
• 使用基于云的DDoS保护服务：有几种基于云的DDoS保护服务可以帮助在DDoS攻击到达您的网络之前吸收和减轻DDoS攻击。
• 制定应对DDoS攻击的计划： 制定一个如何应对DDoS攻击的计划是很重要的，包括联系谁以及采取什么步骤来减轻攻击。

通过遵循这些步骤，组织可以保护基于云的系统和服务免受DDoS攻击。

结语

正如本文所讨论的，在云中有多种方法可以实现DoS攻击。容量攻击（第3层）将继续是任何面向web的应用程序最常见的方法。网络泛洪技术，如UDP反射攻击，也是理想的攻击形式，因为我们提到不需要等待TCP握手，攻击者可以用UDP或ICMP泛洪攻击应用程序。

随着时间的推移，我们已经看到了更复杂的L7攻击的增加（不是针对HTTP/DNS洪水，而是针对API的）。

由于我们承认许多WAF技术缺乏保护合法与非法API连接所需的可见性，许多连接将在没有任何防护措施的情况下通过。开发人员错误、缺乏最佳实践或不适当的培训可能导致漏洞容易被恶意行为者滥用。API通常能够实现与后端系统的高速通信，使它们成为自动化攻击和业务逻辑滥用的主要目标，即使在完美编码的情况下也是如此。

因此，我们希望能够清楚地了解如何在云中防止拒绝服务。

并非所有的DoS攻击都是相同的。如前所述，攻击者可以选择更新的DDoS攻击向量，例如API，它们现在是SaaS平台自动化和集成的组成部分。无论组织的规模有多大，应用基本的安全防护机制都很重要。识别系统中的潜在缺陷，并使用漏洞扫描器扫描已知的安全缺陷。 一旦发现任何错误配置，请采取措施，通过实施适当的对策和威胁检测来保护它们。

原文链接：

https://sysdig.com/blog/how-to-prevent-ddos-attack-cloud/