如何阻止云中的DDoS攻擊 - 網安 - 專業的網絡安全產業、社區、知識平臺

從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_listitems: [1.234.21.73, 100.16.107.117, 100.6.8.7]
- rule: Outbound Connection to C2 Serversdesc: Detect outbound connection to command & control serverscondition: 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: WARNINGtags: [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平臺自動化和集成的組成部分。無論組織的規模有多大，應用基本的安全防護機制都很重要。識別系統中的潛在缺陷，并使用漏洞掃描器掃描已知的安全缺陷。一旦發現任何錯誤配置，請采取措施，通過實施適當的對策和威脅檢測來保護它們。