Amazon Virtual Private Cloud (Amazon
VPC)允許你在已定義的虛擬網絡內啟動AWS資源。這個虛擬網絡與你在數據中心中運行的傳統網絡極其相似，并會為你提供使用AWS的可擴展基礎設施的優勢。簡單來說，VPC就是一個AWS用來隔離你的網絡與其他客戶網絡的虛擬網絡服務。在一個VPC里面，用戶的數據會邏輯上地與其他AWS租戶分離，用以保障數據安全。
在啟動實例之前，在配置實例時，您可以關聯一個自定義私有 IP 地址到您的 Amazon EC2 實例。但是，這個 IP 地址必須滿足以下條件：
屬于有效的 IPv4 范圍。
在所選子網的 CIDR 范圍內。
可以使用。這個私有 IP 地址不可綁定到任何其他資源。
**注意：**無法為現有實例分配新的自定義主私有 IP 地址。
一、AWS EC2 VPC有如下特點：
VPC內可以創建多個子網;
可以在選擇的子網上啟動EC2實例;
在每一個子網上分配自己規劃的IP地址;
每一個子網配置自己的路由表;
創建一個Internet Gateway并且綁定到VPC上，讓EC2實例可以訪問互聯網;
VPC對你的AWS資源有更安全的保護;
……
AWS VPC努力在整個企業中識別和檢測攻擊者的技術;在終端、本地和云上，Hunters 團隊研究了一種使用 VPC 功能的技術，允許客戶控制他們的
IP 地址。攻擊者可以使用它來控制在訪問受感染賬戶時寫入 AWS CloudTrail 日志的 IP 地址。這可能使攻擊者能夠欺騙依賴 Cloudtrail
日志的各種安全保護措施，例如 SIEM 和云安全工具。其中包括但不限于 GuardDuty、Rapid7 和
Lacework。此外，尋找攻擊證據的分析師可能會忽略它。
這篇文章回顧了混淆處理技術的技術細節，并提供了可行的措施建議。
二、攻擊者控制CloudTrail SourceIP
通過控制他們的源 IP 地址，攻擊者可以隱藏起來，從而可能繞過完全依賴于 AWS CloudTrail 的安全措施。
因此，通過使惡意行為看起來好像是由合法對象執行的，這就可以使惡意行為看起來是無害的，并且很難檢測攻擊痕跡并將入侵歸因于特定的來源。
如果你的安全工具僅依賴 AWS CloudTrail 日志中的 sourceIP 字段，緩解措施如下。
技術分析
為了成功執行這種技術，攻擊者需要從受害者賬戶獲得合法 AWS 憑證的訪問權限，然后創建 VPC 終端，該功能允許你的 VPC 中的 EC2 實例和
AWS
服務在他們自己的賬戶內進行直接通信。創建一個IP范圍的VPC，當他們使用被破壞的憑證時，可以混淆他們的流量。以下是我們需要描述的關鍵功能，以解釋如何使用該技術：
CloudTrail 日志有一個“sourceIPAddress”字段。該字段包含攻擊者的 IP 地址，在大多數情況下是公共 IPv4 地址。
但是，如果攻擊者在AWS VPC內通過VPC的終端發出AWS
API請求，則CloudTrail日志中登錄的IP地址就是VPC中“內部”EC2的IP地址，即攻擊者能夠控制的IP地址。
用戶可以在VPC內設置任意IPv4地址范圍，包括rfc1918地址范圍和可對外路由的IP地址范圍。可公開路由的IP塊只能通過虛擬專用網關訪問，不能通過Internet網關訪問。這允許攻擊者創建一個IP尋址方案，模仿受害者自己的網絡或信譽良好的外部服務。
另一個重要的事實是，登錄到CloudTrail中的userAgent字段顯示了攻擊者的userAgent字符串，它完全由進行API調用的攻擊者控制。然而，這并不是該技術的直接組成部分，當使用它時，它可以幫助進一步使模擬過程看起來合法。
在私有 AWS 賬戶(攻擊者賬戶“A”)中創建了一個帶有我們選擇的私有 IP CIDR 塊 (12.34.56.0/24) 的 VPC。
然后，我們在這個 VPC 中創建了一個 EC2 實例，并選擇了它的私有 IPv4 地址為 12.34.56.78。
我們在受害者的帳戶(“B”)中生成了 API 憑據，作為在使用該技術之前被攻擊者破壞的憑據。
然后，我們在攻擊者 EC2 實例上的 ~/.aws/credentials 文件中配置了這些“被盜”憑證，以便從攻擊者控制的賬戶 A 中的實例發出的
AWS CLI 調用將使用它們。
接下來，我們在攻擊者帳戶中為我們打算進行 API 調用的服務創建了 VPC 終端。
我們從可以創建VPC終端的125個AWS服務中選擇了44個最重要服務的子集，并且為每個服務選擇了一個不需要任何特定參數的API調用。
為了驗證該技術，我們進行了測試。為了進行比較，我們首先從 EC2 實例對服務執行 API 調用，而不是通過 VPC
終端進行隧道傳輸。這些調用以實例的公共 IP 地址作為源 IP 顯示在 CloudTrail 日志中。
在下一步中，我們為上述服務創建了 VPC 終端節點，并在每個服務中重新運行 AWS CLI 命令，這次是通過 VPC 終端節點。
測試成功，在 CloudTrail 日志中顯示了攻擊者選擇的“內部”IP 地址作為源 IP。
攻擊者可以出于許多不同的目的混淆他們的 IP 地址，以下是一些示例：
1.“組織”公共 IP 地址：如果攻擊者收集有關受害組織的公共 Internet
基礎設施的信息，則攻擊者可以使用與其公共基礎設施的某些部分相對應的公共 IP。比如公司的外部 VPN IP 地址。
2.員工“家庭”外部 IP 地址：如果攻擊者獲得有關員工在離開辦公室時使用的外部 IP 地址的情報，他們可以選擇該
IP，從而錯誤地將任何調查指向“無辜”員工。比如云 IT 管理員的家庭 IP 地址。
3.第三方服務提供商的公共IP地址：攻擊者可以在 AWS 客戶環境中使用屬于第三方服務提供商的已知公共 IP
地址，從而增加逃避威脅情報和信譽服務的機會。由于有時這些 IP 可能被 AWS 客戶列入白名單，攻擊者甚至可以執行更大量的敏感 API 調用。
示例 1：使用屬于企業云安全產品的 IP 地址(最好是受害組織使用的 IP 地址)。
示例 2：使用 198.20.69.74，流行的互聯網掃描 Shodan 從中掃描整個互聯網。
4.一個特殊的私有、保留、測試或僅用于文檔的 IPv4 子網塊：有 4-5 個子網被定義為用于臨時目的的“保留
IP”，使用其中一個還可以幫助規避信譽服務，完整列表可在此處獲得。
示例：使用 TEST-NET 子網中的 IP 地址(192.0.2.0/24、198.51.100.0/24 或
203.0.113.0/24)。
三、哪些 AWS 服務支持 VPC 終端節點訪問?
此技術只能用于對可以為其創建 VPC 終端節點的 AWS 服務進行 API 調用。但是，截至 2021 年 5 月，可以為 125 種不同的 AWS
服務創建 VPC 終端節點，包括大多數著名的 AWS 服務(例如 EC2、S3、Lambda、STS、DynamoDB、Secrets Manager
等)，唯一重要的例外是我們已經看到是 IAM。
此外，AWS 正在不斷擴展 VPC 終端支持的服務列表。可以在 AWS 門戶中查看受支持服務的完整列表。
解決方案
配置 Amazon EC2 實例。有關詳細步驟，請參閱使用舊的啟動實例向導啟動實例或使用新的啟動實例向導啟動實例。
在配置實例詳細信息部分的網絡中，選擇虛擬私有云(VPC)或創建新的 VPC。對于子網，選擇相應的子網，或者創建一個要在其中啟動實例的新子網。
在網絡接口部分的主 IP(網絡接口的主私有 IPv4 地址)中，輸入自定義私有 IPv4 地址。
完成啟動實例向導配置，然后啟動實例。
可以簡單地理解為一個VPC就是一個虛擬的數據中心，在這個虛擬數據中心內我們可以創建不同的子網(公有網絡和私有網絡)，搭建我們的網頁服務器、應用服務器、數據庫服務器等等服務。
四、這可以用于繞過基于 IP 的 IAM 策略嗎?
我們測試了是否可以使用此技術繞過基于 IAM 源 IP 的策略(使用 aws:SourceIp
密鑰)。該測試假設，在某些情況下，組織配置此類策略，只允許來自特定子網的某些敏感 AWS 操作。
在這種假設下，我們測試了在這種情況下，如果攻擊者使用相應的“內部”IPv4 CIDR 塊創建 VPC 并使用 VPC 終端，他們是否可以成功調用敏感的
AWS API，從而“繞過”此類策略。
我們發現(詳情點這里https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip)當
API 調用通過 VPC 終端完成時，aws:SourceIp 密鑰不可用(相反，aws:VpcSourceIp 可用)，因此該技術不能用于繞過此類 IAM
策略。
如何在你的運行環境中檢測此類活動：
通常，當 AWS API 調用通過 VPC 終端節點完成時，可選的 vpcEndpointID CloudTrail 字段會被填充(使用 VPC
終端節點的 ID)，與所有其他調用不同，這些調用不填充該字段。這是該技術在日志中唯一的殘留用法。
鑒于此，我們的第一個建議是查看 vpcEndpointID 字段。
檢測使用不在你在 VPC 中使用的任何私有 IP 范圍內的 IP 地址的攻擊者相對容易，這可以通過查找通過 VPC 終端節點(帶有填充的
vpcEndpointId 字段)和不在你的 VPC 中使用的私有 IP 范圍內的源 IP 地址執行的任何 AWS API 調用來完成。
但是，檢測攻擊者使用的IP地址在你的任何vpc中都是有效的私有IP地址，這是非常困難的。這是因為當你在環境中使用VPC終端時，攻擊者的合法行為和攻擊者的行為產生的日志唯一的區別就是記錄的特定
VPC 終端節點 ID。我們建議使用更多基于異常的檢測邏輯來解決這個用例，檢測組織中從未見過的新 VPC 終端節點 ID 的使用情況
最后，我們建議 AWS CloudTrail
用戶將他們的云事件與終端、本地、電子郵件、身份等上的其他傳感器進行交叉引用。跨攻擊面的綜合自動檢測是發現被忽略威脅的最有效方法。
上一篇：
為何說亞馬遜aws海外云服務器對外貿企業更具優勢?
下一篇：
Amazon RDS for SQL Server可以用在哪些方面？
