Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service
通過增強EC2實例元數據服務，添加針對開放防火牆、反向代理和SSRF漏洞的深度防禦

July 27, 2021: We’ve updated the link to the 2019 re:Invent session on this topic.
2021年7月27日：我們更新了有關此主題的2019 re：Invent會議的連結。

Since it first launched over 10 years ago, the Amazon EC2 Instance Metadata Service (IMDS) has helped customers build secure and scalable applications. The IMDS solved a big security headache for cloud users by providing access to temporary, frequently rotated credentials, removing the need to hardcode or distribute sensitive credentials to instances manually or programatically. Attached locally to every EC2 instance, the IMDS runs on a special “link local” IP address of 169.254.169.254 that means only software running on the instance can access it. For applications with access to IMDS, it makes available metadata about the instance, its network, and its storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance.
自 10 多年前首次推出以來，Amazon EC2 實例元數據服務 （IMDS） 已協助客戶構建安全且可擴展的應用程式。IMDS 通過提供對臨時、頻繁輪換憑證的訪問，消除了手動或以程式設計方式將敏感憑證硬編碼或分發到實例的需要，從而解決了雲使用者面臨的一大安全難題。IMDS 在本地連接到每個 EC2 實例，在特殊的“連結本地”IP 位址 169.254.169.254 上運行，這意味著只有實例上運行的軟體才能訪問它。對於可以存取 IMDS 的應用程式，它提供有關實例、其網路和儲存的元數據。IMDS 還使 AWS 憑證可用於附加到實例的任何 IAM 角色。

When you run applications in the cloud, application security is as critical as instance security; if the applications running on an instance have vulnerabilities or misconfigurations, there can be serious consequences. While application security plays an important role in a layered defense, AWS also constantly evaluates where to add layers, even within the instance, to minimize the damage that can occur when these situations occur.
當您在雲中運行應用程式時，應用程式安全性與實例安全性一樣重要;如果實例上運行的應用程式存在漏洞或配置錯誤，則可能會產生嚴重後果。雖然應用程式安全性在分層防禦中發揮著重要作用，但AWS還會不斷評估在何處添加層，甚至在實例中，以最大限度地減少這些情況發生時可能發生的損害。

Today, AWS is making v2 of the EC2 Instance Metadata Service (IMDSv2) available. The existing instance metadata service (IMDSv1) is fully secure, and AWS will continue to support it. But IMDSv2 adds new “belt and suspenders” protections for four types of vulnerabilities that could be used to try to access the IMDS. These new protections go well beyond other types of mitigations, while working seamlessly with existing mitigations such as restricting IAM roles and using local firewall rules to restrict access to the IMDS. AWS is also making new versions of the AWS SDKs and CLIs available that support IMDSv2.
今天，AWS 推出了 EC2 實例元數據服務 （IMDSv2） 的 v2。現有的實例元數據服務 （IMDSv1） 是完全安全的，AWS 將繼續支援它。但IMDSv2為四種類型的漏洞添加了新的「腰帶和吊帶」保護，這些漏洞可用於嘗試訪問IMDS。這些新的保護措施遠遠超出了其他類型的緩解措施，同時與現有緩解措施無縫協作，例如限制 IAM 角色和使用本地防火牆規則來限制對 IMDS 的訪問。AWS 還提供了支援 IMDSv2 的 AWS 開發工具包和 CLI 的新版本。

What’s new in IMDSv2 IMDSv2 中的新增功能

With IMDSv2, every request is now protected by session authentication. A session begins and ends a series of requests that software running on an EC2 instance uses to access the locally-stored EC2 instance metadata and credentials. The software starts a session with a simple HTTP PUT request to IMDSv2. IMDSv2 returns a secret token to the software running on the EC2 instance, which will use the token as a password to make requests to IMDSv2 for metadata and credentials. Unlike traditional passwords, you don’t need to worry about getting the token to the software, because the software gets it for itself with the PUT request. The token is never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when the process using the token terminates. There’s no limit on the number of requests within a single session, and there’s no limit on the number of IMDSv2 sessions. Sessions can last up to six hours and, for added security, a session token can only be used directly from the EC2 instance where that session began.
借助IMDSv2，每個請求現在都受到會話身份驗證的保護。會話開始和結束 EC2 實例上運行的軟體用於存取本地儲存的 EC2 實例元數據和憑證的一系列請求。軟體通過向IMDSv2發出簡單的 HTTP PUT 請求來啟動工作階段。IMDSv2 將金鑰令牌返回給 EC2 實例上運行的軟體，該軟體將使用該令牌作為密碼向 IMDSv2 發出元數據和憑證請求。與傳統密碼不同，您無需擔心將令牌獲取給軟體，因為軟體會通過PUT請求自行獲取令牌。IMDSv2 永遠不會存儲該令牌，並且後續調用也永遠無法檢索該令牌，因此當使用該令牌的進程終止時，會話及其令牌實際上會被銷毀。單個會話中的請求數量沒有限制，IMDSv2 會話的數量也沒有限制。會話最多可以持續 6 小時，並且為了提高安全性，會話令牌只能直接從會話開始的 EC2 實例中使用。

For example, this curl recipe retrieves a session token that’s valid for the full six hours (21600 seconds) and then uses that token to access the EC2 instance’s profile metadata:
例如，此 curl 配方檢索一個在整整六個小時（21600 秒）內有效的會話令牌，然後使用該令牌訪問 EC2 實例的配置檔元數據：

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

curl http://169.254.169.254/latest/meta-data/profile -H "X-aws-ec2-metadata-token: $TOKEN"

If you need to write code against the IMDSv2 directly, you can get more detail on the new scheme in the EC2 User Guide.
如果您需要直接針對IMDSv2編寫代碼，可以在EC2使用者指南中獲取有關新方案的更多詳細資訊。

How these changes add defense in depth
這些更改如何增加深度防禦

IMDSv2’s changes are easy to use, and you’ll start using it automatically if you’re using the updated AWS SDKs and CLIs. These changes go beyond other types of mitigations to protect against misconfigured-open website application firewalls, misconfigured-open reverse proxies, unpatched SSRF vulnerabilities, and misconfigured-open layer-3 firewalls and network address translation.
IMDSv2 的更改易於使用，如果您使用的是更新的 AWS 開發工具包和 CLI，您將自動開始使用它。這些更改超越了其他類型的緩解措施，以防止配置錯誤打開的網站應用程式防火牆、錯誤配置打開的反向代理、未修補的 SSRF 漏洞以及配置錯誤的開放第 3 層防火牆和網路位址轉換。

Protecting against open Website Application Firewalls
防止開放的網站應用程式防火牆

Some Web Application Firewall (WAF) services, such as AWS WAF, can’t be configured to act as open WAFs. However, some third-party WAFs can be misconfigured to allow attackers unauthorized access to the network behind the WAF, including the EC2 IMDS.
某些 Web 應用程式防火牆 （WAF） 服務（例如 AWS WAF）無法配置為充當開放 WAF。但是，某些第三方 WAF 可能配置錯誤，以允許攻擊者未經授權訪問 WAF 背後的網路，包括 EC2 IMDS。

Many WAFs are designed to act invisibly, so that they can protect websites and applications without administrators having to change or reconfigure the applications that are behind the WAF. To be transparent, WAFs usually pass on all of the headers that come with a request, and do not add their own headers, such as the standard X-Forwarded-For header that other kinds of proxies add. In other words, applications behind a WAF get requests just as the requester sent them.
許多WAF設計為以不可見的方式運行，因此它們可以保護網站和應用程式，而無需管理員更改或重新配置WAF背後的應用程式。為了透明起見，WAF 通常會傳遞請求附帶的所有標頭，並且不會添加自己的標頭，例如其他類型的代理添加的標準 X-Forwarded-For 標頭。換句話說，WAF 後面的應用程式會像請求者發送請求一樣接收請求。

The AWS approach is to block open WAFs by using a type of request that open WAFs very rarely support, HTTP PUT requests. Although web services such as Amazon S3 use PUT requests for object storage, they’re an uncommon type of request for websites and browsers to use. Our analysis of third-party WAF products and open WAF misconfigurations found that the vast majority do not permit HTTP PUT requests. We’re using this PUT request to provide a new layer of defense that goes beyond any existing capabilities – we’ve architected the IMDSv2 service to require a PUT request at the beginning of a session, which will prevent open WAFs from being abused to access the IMDS in the vast majority of cases.
AWS 方法是使用一種打開的 WAF 很少支援的請求類型（即 HTTP PUT 請求）來阻止打開的 WAF。儘管 Amazon S3 等 Web 服務使用 PUT 請求進行物件存儲，但它們是網站和瀏覽器使用的不常見請求類型。我們對第三方 WAF 產品和開放 WAF 錯誤配置的分析發現，絕大多數產品都不允許 HTTP PUT 請求。我們使用此 PUT 請求來提供超越任何現有功能的新防禦層 – 我們構建了 IMDSv2 服務，要求在會話開始時發出 PUT 請求，這將防止在絕大多數情況下濫用打開的 WAF 訪問 IMDS。

Protecting against open reverse proxies
防止開放的反向代理

As it happens, it’s also very rare for open reverse proxies to allow PUT requests, but IMDSv2 has another layer of defense against open reverse proxies. Reverse proxies, such as Apache httpd or Squid, can also be misconfigured to allow external requests that reach internal resources, but it’s still normal for these proxies to send an X-Forwarded-For HTTP header. That header itself is used to pass on the IP address of the original caller. IMDSv2 will also not issue session tokens to any caller with an X-Forwarded-For header, which is effective at blocking unauthorized access due to misconfigurations like an open reverse proxy.
碰巧的是，開放反向代理允許 PUT 請求的情況也非常罕見，但 IMDSv2 對開放反向代理有另一層防禦。反向代理（例如 Apache httpd 或 Squid）也可能被錯誤配置為允許存取內部資源的外部請求，但這些代理發送 X-Forwarded-For HTTP 標頭仍然是正常的。該標頭本身用於傳遞原始調用方的IP位址。IMDSv2 也不會向任何帶有 X-Forwarded-For 標頭的調用方頒發會話令牌，這可以有效地阻止由於錯誤配置（如打開的反向代理）而導致的未經授權的訪問。

Protecting against SSRF vulnerabilities
防範 SSRF 漏洞

SSRF vulnerabilities allow attackers to make unauthorized requests from web applications. Since these requests come from the application itself, they can be used to access internal resources that the application has access to but that were not intended to be accessible to outsiders. SSRF vulnerabilities vary in their severity, and some are immune to other types of mitigations. For instance, blocking SSRFs through static headers in instance metadata requests is effective only when the vulnerability merely allows the attacker to control the URL that is being requested; however, AWS analysis found many SSRF vulnerabilities that allow attackers to set arbitrary headers because the SSRF vulnerability impacts the application’s own header processing.
SSRF 漏洞允許攻擊者從 Web 應用程式發出未經授權的請求。由於這些請求來自應用程式本身，因此它們可用於訪問應用程式有權訪問但不打算供外部人員訪問的內部資源。SSRF 漏洞的嚴重程度各不相同，有些漏洞不受其他類型的緩解措施的影響。例如，只有在漏洞僅允許攻擊者控制所請求的 URL 時，通過實例元數據請求中的靜態標頭阻止 SSRF 才有效;但是，AWS 分析發現許多 SSRF 漏洞允許攻擊者設置任意標頭，因為 SSRF 漏洞會影響應用程式自身的標頭處理。

IMDSv2’s combination of beginning a session with a PUT request, and then requiring the secret session token in other requests, is always strictly more effective than requiring only a static header. AWS analysis of real-world vulnerabilities found that this combination protects against the vast majority of SSRF vulnerabilities.
IMDSv2 將以 PUT 請求開始會話，然後在其他請求中要求秘密會話令牌的組合，始終比僅需要靜態標頭更有效。AWS 對實際漏洞的分析發現，這種組合可以防止絕大多數 SSRF 漏洞。

Protecting against open layer 3 firewalls and NATs
防範開放的第3層防火牆和NAT

Last, there is a final layer of defense in IMDSv2 that is designed to protect EC2 instances that have been misconfigured as open routers, layer 3 firewalls, VPNs, tunnels, or NAT devices. With IMDSv2, the PUT response containing the secret token will, by default, not be able to travel outside the instance. This is accomplished by having the default Time To Live (TTL) on the low-level IP packets containing the secret token set to “1,” much lower than a typical value, such as “64.” Hardware and software that handle packets, including EC2 instances, subtract 1 from each packet’s TTL field whenever they pass it on. If the TTL gets to 0, the packet is discarded, and an error message is sent back to the sender. A packet with a TTL of “64” can therefore make sixty-four “hops” in a network before giving up, while a packet with a TTL of “1” can exist in just one. This feature allows legitimate traffic to get to an intended destination, but is designed to stop packets from endlessly running around in circles if there’s a loop in a network.
最後，IMDSv2 中還有最後一層防禦，旨在保護被錯誤配置為開放路由器、第 3 層防火牆、VPN、隧道或 NAT 設備的 EC2 實例。使用 IMDSv2 時，預設情況下，包含金鑰令牌的 PUT 回應將無法傳輸到實例外部。這是通過將包含密鑰令牌的低級 IP 數據包上的預設存留時間 （TTL） 設置為“1”來實現的，該值遠低於典型值，例如“64”。處理數據包的硬體和軟體（包括 EC2 實例）在傳遞每個數據包時都會從每個數據包的 TTL 字段中減去 1。如果 TTL 達到 0，則丟棄數據包，並將錯誤訊息發送回發送方。因此，TTL 為“64”的數據包在放棄之前可以在網络中進行 64 個“躍點”，而 TTL 為“1”的數據包只能存在於一個網络中。此功能允許合法流量到達預期目的地，但旨在阻止數據包在網路中存在環路時無休止地繞圈運行。

With IMDSv2, setting the TTL value to “1” means that requests from the EC2 instance itself will work because they’re returned to the caller (on the instance) before the subtraction occurs. But if the EC2 instance has been misconfigured as an open router, layer 3 firewall, VPN, tunnel, or NAT device, the response containing the token will have its TTL reduced to zero before leaving the instance, and the packet containing the response will be discarded on its way out of the instance, preventing transport to the attacker. The information simply won’t make it further than the EC2 instance itself, which means that an attacker won’t get the response back with the token, and with it the ability to access instance metadata, even if they’ve been successful at getting past all other defenses.
使用IMDSv2時，將TTL值設置為“1”意味著來自EC2實例本身的請求將起作用，因為它們在減法發生之前已返回給調用方（在實例上）。但是，如果 EC2 實例被錯誤地配置為開放路由器、第 3 層防火牆、VPN、隧道或 NAT 設備，則包含令牌的回應將在離開實例之前將其 TTL 減少到零，並且包含回應的數據包將在離開實例時被丟棄，從而阻止傳輸給攻擊者。這些資訊根本不會比 EC2 實例本身更進一步，這意味著攻擊者不會使用令牌獲得響應，並且無法訪問實例元數據，即使他們已經成功繞過了所有其他防禦。

Making the transition 進行過渡

Both IMDSv1 and IMDSv2 will be available and enabled by default, and customers can choose which they will use. The IMDS can now be restricted to v2 only, or IMDS (v1 and v2) can also be disabled entirely. AWS recommends adopting v2 and restricting access to v2 only for added security. IMDSv1 remains available for customers who have tools and scripts using v1, and who are comfortable with the existing security posture of their instances.
IMDSv1 和 IMDSv2 都將預設可用並啟用，客戶可以選擇使用哪一個。IMDS 現在可以限製為僅 v2，或者 IMDS（v1 和 v2）也可以完全禁用。AWS 建議採用 v2 並限制對 v2 的訪問，以提高安全性。IMDSv1 仍然可供擁有使用 v1 的工具和腳本，並且對其實例的現有安全狀況感到滿意的客戶使用。

A number of tools are available to make transitioning to v2 and disabling v1 seamless. Starting today, a new CloudWatch metric is available that provides visibility into the number of v1 calls that are being made on any given instance. Customers can use this metric to monitor how often v1 is still being accessed as Amazon Machine Images, the AWS SDKs, CLIs, cloud-init, and other software accessing the IMDS is updated, released, and upgraded. When you can see that an instance can be launched, activated, used for service, and the metric is zero, it is safe to require v2 of the IMDS, disabling v1. For more information on transitioning to IMDSv2, see the user guide.
有許多工具可用於無縫過渡到 v2 和禁用 v1。從今天開始，我們推出了一個新的 CloudWatch 指標，該指標可讓您瞭解在任何給定實例上進行的 v1 調用的數量。客戶可以使用此指標來監控在更新、發佈和升級 Amazon 系統映射、AWS 開發工具包、CLI、cloud-init 和其他訪問 IMDS 的軟體時，v1 仍被訪問的頻率。當您看到實例可以啟動、啟動、用於服務，並且指標為零時，可以安全地要求IMDS的 v2並禁用 v1。有關過渡到 IMDSv2 的更多資訊，請參閱使用者指南。

Security can also be further enhanced while this transition is happening. AWS credentials provided by the IMDS now include an ec2:RoleDelivery IAM context key. Credentials provided by the older IMDSv1 have an ec2:RoleDelivery value of “1.0,” and credentials using the new scheme will have an ec2:RoleDelivery value of “2.0.” This context key makes it easy to enforce use of the new scheme on a service-by-service or resource-by-resource basis by using those context keys as conditions in IAM policies, resource policies, or AWS Organizations service control policies. For example, if all of the software accessing an S3 bucket has been upgraded to use IMDSv2, then that S3 bucket can be safely restricted to only allow access to role-account credentials that have the “2.0” value (or greater) for the context key. The effect is that credentials retrieved using IMDSv1 will be prevented from accessing the bucket. AWS CloudTrail is also being updated to record the new ec2:RoleDelivery parameters.
在進行此轉換時，還可以進一步增強安全性。IMDS 提供的 AWS 憑證現在包括 ec2：RoleDelivery IAM 上下文密鑰。舊 IMDSv1 提供的憑證的 ec2：RoleDelivery 值為“1.0”，使用新方案的憑證的 ec2：RoleDelivery 值為“2.0”。通過將此上下文鍵用作 IAM 策略、資源策略或 AWS Organizations 服務控制策略中的條件，此上下文鍵可以輕鬆地逐個服務或逐個資源強制使用新方案。例如，如果訪問 S3 儲存桶的所有軟體都已升級為使用 IMDSv2，則可以安全地限制該 S3 儲存桶，以僅允許訪問上下文鍵值為“2.0”（或更大）的角色帳戶憑據。其效果是，使用IMDSv1檢索的憑據將被阻止訪問存儲桶。AWS CloudTrail 也將更新以記錄新的 ec2：RoleDelivery 參數。

Hear about IMDSv2 at re:Invent
在 re：Invent 大會上瞭解 IMDSv2

Mark Ryland spoke in more detail about IMDSv2, and the transition to it, at AWS re:Invent in December 2019. To watch a recording of the session, see Security best practices for the Amazon EC2 instance metadata service on YouTube.
Mark Ryland 在 2019 年 12 月的 AWS re：Invent 大會上更詳細地談到了 IMDSv2 以及向 IMDSv2 的過渡。要觀看會話錄像，請參閱 YouTube 上的 Amazon EC2 實例元數據服務的安全最佳實踐。

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.
想要瞭解更多的 AWS 安全操作方法內容、新聞和功能公告？在 Twitter 上關注我們。