L'exploitation de la vulnérabilité zero-day HTTP/2 entraîne des attaques DDoS record

Plus tôt aujourd'hui, Cloudflare, Google et Amazon AWS ont révélé l'existence d'une nouvelle vulnérabilité zero-day, baptisée « HTTP/2 Rapid Reset ». Cette attaque exploite une faiblesse du protocole HTTP/2 afin de lancer d'immenses attaques hyper-volumétriques par déni de service distribué (DDoS). Au cours des derniers mois, Cloudflare a atténué un véritable barrage d'attaques de ce type, notamment une attaque trois fois plus importante que toutes les attaques que nous avions précédemment observées, qui a dépassé 201 millions de requêtes par seconde (r/s). Depuis la fin du mois d'août 2023, Cloudflare a atténué plus de 1 100 autres attaques dépassant 10 millions de r/s, dont 184 attaques plus vastes que la précédente attaque DDoS record que nous avions observée, de 71 millions de r/s.

Vous êtes victime d'une attaque ou avez besoin d'une protection supplémentaire ? Cliquez ici pour demander de l'aide.

Cette attaque zero-day a fourni aux acteurs malveillants un nouvel outil essentiel sur leur couteau suisse d'exploitations de vulnérabilités, leur permettant de lancer contre leurs victimes des attaques d'une ampleur encore jamais observée. Bien qu'elles soient parfois complexes et difficiles à combattre, ces attaques ont permis à Cloudflare de développer une technologie spécifique, permettant d'atténuer les effets de cette Continue reading

HTTP/2 Rapid Reset：解构这场破纪录的攻击

从 2023 年 8 月 25 日开始，我们开始注意到一些异常大量的 HTTP 攻击袭击了我们的许多客户。我们的自动化 DDoS 系统检测到并缓解了这些攻击。然而，没过多久，它们就开始达到破纪录的规模 - 最终达到了每秒 2.01 亿次请求的峰值。此数量几乎是我们以前最大攻击记录数量的 3 倍。

受到攻击或需要额外保护？ 单击此处获取帮助。

而更令人担忧的是，攻击者能够利用一个只有 20,000 台机器的僵尸网络发起这样的攻击。而如今有的僵尸网络由数十万或数百万台机器组成。整个 web 网络通常每秒处理10-30 亿个请求，因此使用此方法可以将整个 web 网络的请求数量等级集中在少数目标上，而这并非不可想象。

检测和缓解

这是一种规模空前的新型攻击手段，Cloudflare 现有的保护措施在很大程度上能够抵御这种攻击的冲击。虽然最初我们看到了对客户流量的一些影响（在第一波攻击期间影响了大约1% 的请求），但今天我们已经能够改进我们的缓解方法，以阻止任何针对Cloudflare 客户的攻击，并保证自身的系统正常运行。

我们注意到这些攻击的同时，谷歌和 AWS 这两大行业巨头也发现了同样的情况。我们努力加固 Cloudflare 的系统，以确保目前我们所有的客户都能免受这种新的 DDoS 攻击方法的影响，而不会对客户造成任何影响。我们还与谷歌和 AWS 共同参与了向受影响的供应商和关键基础设施提供商披露攻击事件的协调工作。

这种攻击是通过滥用 HTTP/2 协议的某些功能和服务器实施详细信息实现的（详情请参见 CVE-2023-44487）。由于该攻击滥用了 HTTP/2 协议中的一个潜在弱点，我们认为实施了 HTTP/2 的任何供应商都会受到攻击。这包括所有现代网络服务器。我们已经与谷歌和 AWS 一起向网络服务器供应商披露了攻击方法，我们希望他们能够实施补丁。与此同时，最好的防御方法是在任何面向网络的 Web 服务器或 API 服务器前面使用诸如 Cloudflare 之类的 DDoS 缓解服务。

这篇文章深入探讨了 HTTP/2 协议的详细信息、攻击者利用来实施这些大规模攻击的功能，以及我们为确保所有客户受到保护而采取的缓解策略。我们希望通过公布这些详细信息，其他受影响的 Web 服务器和服务能够获得实施缓解策略所需的信息。此外，HTTP/2 协议标准团队以及开发未来 Web 标准的团队可以更好地设计这些标准，以防止此类攻击。

RST 攻击详细信息

HTTP 是为 Web 提供支持的应用协议。HTTP 语义对于所有版本的 HTTP 都是通用的 — 整体架构、术语和协议方面，例如请求和响应消息、方法、状态代码、标头和尾部字段、消息内容等等。每个单独的 HTTP 版本都定义了如何将语义转换为“有线格式”以通过 Internet 进行交换。例如，客户端必须将请求消息序列化为二进制数据并发送，然后服务器将其解析回它可以处理的消息。

HTTP/1.1 使用文本形式的序列化。请求和响应信息以 ASCII 字符流的形式进行交换，通过可靠的传输层（如 TCP）发送，使用以下格式（其中 CRLF 表示回车和换行）：

 HTTP-message   = start-line CRLF
                   *( field-line CRLF )
                   CRLF
                   [ message-body ]

例如，对于 https://blog.cloudflare.com/ 的一个非常简单的 GET 请求在线路上将如下所示：

GET / HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFCRLF

响应将如下所示：

HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLFCRLF<100 bytes of data>

这种格式在线路上构造消息，这意味着可以使用单个 TCP 连接来交换多个请求和响应。但是，该格式要求每条消息都完整发送。此外，为了正确地将请求与响应关联起来，需要严格的排序；这意味着消息是串行交换的并且不能多路复用。https://blog.cloudflare.com/ 和 https://blog.cloudflare.com/page/2/ 的两个 GET 请求将是：

GET / HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFCRLFGET /page/2/ HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFCRLF

With the responses:

HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLFCRLF<100 bytes of data>CRLFHTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLFCRLF<100 bytes of data>

Web 页面需要比这些示例更复杂的 HTTP 交互。访问 Cloudflare 博客时，您的浏览器将加载多个脚本、样式和媒体资产。如果您使用 HTTP/1.1 访问首页，然后很快决定导航到第 2 Continue reading

HTTP/2 Rapid Reset：解構破紀錄的攻擊

自 2023 年 8 月 25 日起，我們開始注意到很多客戶遭受到一些異常大型的 HTTP 攻擊。我們的自動化 DDoS 系統偵測到這些攻擊並加以緩解。但是，沒過多久，它們就開始達到破紀錄的規模，峰值最終剛好超過每秒 2.01 億次請求。這幾乎是之前記錄在案的最大規模攻擊的 3 倍。

正在遭受攻擊或需要額外保護？請按一下這裡以取得幫助。

而更加深入後發現，攻擊者能夠利用僅由 20,000 台機器組成的 Botnet 發起此類攻擊，而如今的 Botnet 規模可達數十萬或數百萬台機器。整個 web 網路通常每秒處理 10-30 億個請求，因此使用此方法可以將整個 web 網路的請求數量等級集中在少數目標上，而其實是可以達成的。

偵測和緩解

這是一種規模空前的新型攻擊手段，但 Cloudflare 的現有保護主要能夠吸收攻擊的壓力。我們一開始就注意到一些客戶流量影響 (在第一波攻擊期間約影響 1% 的請求)； 如今，我們仍在持續改善緩解方法，以阻止對任何 Cloudflare 客戶發動的攻擊，而且不會影響我們的系統。

我們注意到這些攻擊，同時也有其他兩家主流的業內廠商（Google 和 AWS）發現相同的狀況。我們竭力強化 Cloudflare 的系統，以確保現今所有客戶都能免於此新型 DDoS 攻擊方法的侵害，而且沒有任何客戶受到影響。我們還與 Googel 和 AWS 合作，協調披露受影響廠商和關鍵基礎架構提供者遭受的攻擊。

此攻擊是透過濫用 HTTP/2 通訊協定部分功能和伺服器實作詳細資料才得以發動（請參閱 CVE-2023-44487 瞭解詳細資料）。因為攻擊會濫用 HTTP/2 通訊協定中的潛在弱點，所以我們認為任何實作 HTTP/2 的廠商都會遭受攻擊。這包括每部現代 Web 伺服器。我們與 Google 和 AWS 已經將攻擊方法披露給預期將實作修補程式的 Web 伺服器廠商。在這段期間，最佳防禦就是針對任何面向 Web 的網頁或 API 伺服器使用 DDoS 緩解服務（例如 Cloudflare）。

本文將深入探討 HTTP/2 通訊協定、攻擊者用於發動這些大規模攻擊的功能，以及我們為確保所有客戶均受到保護而採取的緩解策略。我們希望在發布這些詳細資料後，其他受影響的 Web 伺服器和服務即可取得實施緩解策略所需的資訊。此外，HTTP/2 通訊協定標準團隊和未來 Web 標準制定團隊，都能進一步設計出預防此類攻擊的功能。

RST 攻擊詳細資料

HTTP 是支援 Web 的應用程式通訊協定。HTTP 語意為所有版本的 HTTP 所共用；整體架構、術語及通訊協定方面，例如請求和回應訊息、方法、狀態碼、標頭和後端項目欄位、訊息內容等等。每個 HTTP 版本將定義如何將語意轉化為「有線格式」以透過網際網路交換。例如，客戶必須將請求訊息序列化為二進位資料並進行傳送，接著伺服器會將其剖析回可處理的訊息。

HTTP/1.1 採用文字形式的序列化。請求和回應訊息交換為 ASCII 字元串流，透過 TCP 等可靠的傳輸層傳送，並使用下列格式（其中的 CRLF 表示斷行和換行）：

 HTTP-message   = start-line CRLF
                   *( field-line CRLF )
                   CRLF
                   [ message-body ]

例如，對 https://blog.cloudflare.com/ 非常簡單的 GET 請求在網路上看起來像這樣：

GET / HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFCRLF

回應如下所示：

HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLFCRLF<100 bytes of data>

此格式框住網路上的訊息，表示可使用單一 TCP 連線來交換多個請求和回應。但是，該格式要求完整傳送每則訊息。此外，為使請求與回應正確關聯，需要嚴格排序；表示訊息會依次交換且無法多工處理。以下是 https://blog.cloudflare.com/ 和 https://blog.cloudflare.com/page/2/ 的兩個 GET 請求：

GET / HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFCRLFGET /page/2/ HTTP/1.1 CRLFHost: blog.cloudflare.comCRLFCRLF

回應如下：

HTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLFCRLF<100 bytes of data>CRLFHTTP/1.1 200 OK CRLFServer: cloudflareCRLFContent-Length: 100CRLFtext/html; charset=UTF-8CRLFCRLF<100 bytes of data>

Continue reading

HTTP/2 Rapid Reset: 기록적인 공격의 분석

Cloudfare에서는 2023년 8월 25일부터 다수의 고객을 향한 일반적이지 않은 일부 대규모 HTTP 공격을 발견했습니다. 이 공격은 우리의 자동 DDos 시스템에서 탐지하여 완화되었습니다. 하지만 얼마 지나지 않아 기록적인 규모의 공격이 시작되어, 나중에 최고조에 이르러서는 초당 2억 1백만 요청이 넘었습니다. 이는 우리 기록상 가장 대규모 공격이었던 이전의 공격의 거의 3배에 달하는 크기입니다.

공격을 받고 있거나 추가 보호가 필요하신가요? 여기를 클릭하여 도움을 받으세요.

우려되는 부분은 공격자가 머신 20,000개로 이루어진 봇넷만으로 그러한 공격을 퍼부을 수 있었다는 사실입니다. 오늘날의 봇넷은 수십만 혹은 수백만 개의 머신으로 이루어져 있습니다. 웹 전체에서 일반적으로 초당 10억~30억 개의 요청이 목격된다는 점을 생각하면, 이 방법을 사용했을 때 웹 전체 요청에 달하는 규모를 소수의 대상에 집중시킬 수 있다는 가능성도 완전히 배제할 수는 없습니다.

감지 및 완화

이는 전례 없는 규모의 새로운 공격 벡터였으나, Cloudflare는 기존 보호 기능을 통해 치명적인 공격을 대부분 흡수할 수 있었습니다. 처음에 목격된 충격은 초기 공격 웨이브 동안 고객 트래픽 요청의 약 1%에 영향을 주었으나, 현재는 완화 방법을 개선하여 시스템에 영향을 주지 않고 Cloudflare 고객을 향한 공격을 차단할 수 있습니다.

우리는 업계의 다른 주요 대기업인 Google과 AWS에서도 같은 시기에 이러한 공격이 있었음을 알게 되었습니다. 이에 따라 지금은 우리의 모든 고객을 이 새로운 DDoS 공격 방법으로부터 어떤 영향도 받지 않도록 보호하기 위하여 Cloudflare의 시스템을 강화했습니다. 또한 Google 및 AWS와 Continue reading

Resultados de la vulnerabilidad HTTP/2 Zero-Day en ataques DDoS sin precedentes

Hoy temprano, Cloudflare, Google y Amazon AWS, divulgaron la existencia de una nueva vulnerabilidad zero-day que se conoce como ataque “HTTP/2 Rapid Reset”. Este ataque aprovecha un punto débil en el protocolo HTTP/2 para generar enormes ataques hipervolumétricos por denegación de servicio distribuido (DDoS). Cloudflare ha mitigado un aluvión de estos ataques en los últimos meses, incluso uno tres veces más grande que cualquier ataque anterior que hayamos observado, que superó las 201 millones de solicitudes por segundo (rps). Desde fines de agosto de 2023, Cloudflare ha mitigado otros más de 1100 ataques con más de 10 millones de rps — y 184 ataques fueron de una magnitud mayor a nuestro récord de ataques DDoS previos de 71 millones de rps.

¿Estás siendo blanco de un ataque o necesitas mayor protección? Si necesitas ayuda, haz clic aquí.

Este zero-day brindó a los ciberdelincuentes una nueva herramienta fundamental en su navaja suiza de vulnerabilidades para aprovecharse de sus víctimas y atacarlas a una magnitud que nunca habíamos visto. Si bien a veces estos ataques son complejos y difíciles de combatir, brindaron a Cloudflare la oportunidad de desarrollar tecnología con el propósito de mitigar los efectos de la vulnerabilidad zero-day.

Si Continue reading

HTTP/2 Zero-Day-Sicherheitslücke führt zu rekordverdächtigen DDoS-Angriffen

Heute hat Cloudflare zusammen mit Google und Amazon AWS die Existenz einer neuartigen Zero-Day-Schwachstelle bekannt gegeben, die als „HTTP/2 Rapid Reset“-Angriff bezeichnet wird. Dieser Angriff nutzt eine Schwachstelle im HTTP/2-Protokoll aus, um enorme, hypervolumetrische Distributed Denial of Service (DDoS)-Angriffe zu generieren. Cloudflare hat in den letzten Monaten eine Flut dieser Angriffe abgewehrt, einschließlich eines Angriffs, der dreimal so groß war wie der größte Angriff, den wir bisher jemals verzeichnet hatten, und der 201 Millionen Anfragen pro Sekunde (rps) überstieg. Seit Ende August 2023 hat Cloudflare mehr als 1.100 weitere Angriffe mit über 10 Millionen rps abgewehrt – und 184 Angriffe, die unseren bisherigen DDoS-Rekord von 71 Millionen rps übertrafen.

Sie werden angegriffen oder benötigen zusätzlichen Schutz? Klicken Sie hier, um Hilfe zu erhalten.

Diese Zero-Day-Schwachstelle gab den Bedrohungsakteuren ein wichtiges neues Werkzeug in ihrem Werkzeugkasten an Schwachstellen an die Hand, mit dem sie ihre Opfer in einem noch nie dagewesenen Ausmaß ausnutzen und angreifen können. Diese Angriffe waren mitunter komplex und schwierig zu bekämpfen. Cloudflare bot sich dadurch jedoch die Gelegenheit, eine speziell konzipierte Technologie zu entwickeln, um die Auswirkungen der Zero-Day-Schwachstelle abzuwehren.

Wenn Sie Cloudflare für die HTTP-DDoS-Abwehr nutzen, sind Sie geschützt. Im Folgenden finden Sie weitere Continue reading

Hot (and not hot) networking skills

Today's network engineers have to be flexible and adaptable, understand the new infrastructure-as-code paradigm, and stay on top of the latest developments in cloud, security, and AI.Organizations aren’t necessarily looking for someone who is limited to a single vendor’s technology; they’re looking for employees who have skills across a wide variety of technologies and are constantly looking to broaden their areas of expertise.Jeff Sangillo is vice-president of technology engineering and operations for QTS Data Centers. He manages both internal network connectivity between the company's 30-plus data center locations, as well as customer-facing networking services and products.To read this article in full, please click here

Internet traffic patterns in Israel and Palestine following the October 2023 attacks

Internet traffic patterns in Israel and Palestine following the October 2023 attacks
Internet traffic patterns in Israel and Palestine following the October 2023 attacks

On Saturday, October 7, 2023, attacks from the Palestinian group Hamas launched from the Gaza Strip against the south of Israel started a new conflict in the region. Israel officially declared that it is at war the next day. Cloudflare's data shows that Internet traffic was impacted in different ways, both in Israel and Palestine, with two networks (autonomous systems) in the Gaza Strip going offline a few hours after the attacks. Subsequently, on October 9, two additional networks also experienced outages. We also saw an uptick in cyberattacks targeting Israel, including a 1.26 billion HTTP requests DDoS attack, and Palestine.

Starting with general Internet traffic trends, there was a clear increase in Internet traffic right after the attacks reportedly began (03:30 UTC, 06:30 local time). Traffic spiked at around 03:35 UTC (06:35 local time) in both Israel (~170% growth compared with the previous week) and Palestine (100% growth).

That growth is consistent with other situations, where we’ve seen surges in Internet traffic when countrywide events occur and people are going online to check for news, updates, and more information on what is happening, with social media and messaging also playing a role. However, in Palestine, that traffic growth Continue reading

Path Hunting in BGP

BGP is a path vector protocol. This is similar to distance vector protocols such as RIP. Protocols like these, as opposed to link state protocols such as OSPF and ISIS, are not aware of any topology. They can only act on information received by peers. Information is not flooded in the same manner as IGPs where a change in connectivity is immediately flooded while also running SPF. With distance and path vector protocols, good news travels fast and bad news travels slow. What does this mean? What does it have to do with path hunting?

To explain what path hunting is, let’s work with the topology below:

With how the routers and autonomous systems are connected, under stable conditions RT05 will have prefix 198.51.100.1/32 via the following AS paths:

  • 64513 64512
  • 64514 64513 64512
  • 64515 64514 64513 64512

This is also shown visually in the following diagram:

There’s a total of three different paths, sorted from shortest to longest. Let’s verify this:

RT05#sh bgp ipv4 uni
BGP table version is 11, local router ID is 192.168.128.174
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S  Continue reading

Weekend Reads 100323


Google has rolled out “Privacy Sandbox,” a Chrome feature first announced back in 2019 that, among other things, exchanges third-party cookies—the most common form of tracking technology—for what the company is now calling “Topics.”


By virtue of engineering pushing the acceptable boundaries of a system, failures occur. This is inevitable, and that’s also the joy and perils of engineering — discovering the acceptable limits of system resilience.


The resource-intensive inefficiencies inherent to telecom ordering, billing, and service level agreement (SLA) enforcement between carriers is an industry-wide problem that MEF and its member organizations have been working to solve for years.


Cybersecurity agencies from Japan and the U.S. have warned of attacks mounted by a state-backed hacking group from China to stealthily tamper with branch routers and use them as jumping-off points to access the networks of various companies in the two countries.


To help solve this problem, QUIC no longer relies (purely) on IP addresses to define connections. Instead, it assigns a number to each connection (a so-called Connection ID or CID).


You are a distributor that sells your supplier’s brands, so aside from worrying about your own company’s domains, you’ve got nothing else to worry about, right?


Continue reading

Worth Reading: Introduction of EVPN at DE-CIX

Numerous Internet Exchange Points (IXP) started using VXLAN years ago to replace tradition layer-2 fabrics with routed networks. Many of them tried to avoid the complexities of EVPN and used VXLAN with statically-configured (and hopefully automated) ingress replication.

A few went a step further and decided to deploy EVPN, primarily to deploy Proxy ARP functionality on EVPN switches and reduce the ARP/ND traffic. Thomas King from DE-CIX described their experience on APNIC blog – well worth reading if you’re interested in layer-2 fabrics.

Worth Reading: Introduction of EVPN at DE-CIX

Numerous Internet Exchange Points (IXP) started using VXLAN years ago to replace tradition layer-2 fabrics with routed networks. Many of them tried to avoid the complexities of EVPN and used VXLAN with statically-configured (and hopefully automated) ingress replication.

A few went a step further and decided to deploy EVPN, primarily to deploy Proxy ARP functionality on EVPN switches and reduce the ARP/ND traffic. Thomas King from DE-CIX described their experience on APNIC blog – well worth reading if you’re interested in layer-2 fabrics.

Heavy Networking 704: Roundtable Redux: Blaming The Network; Containerlab Love; 400G Envy

Today's Heavy Networking is another roundtable episode. We've assembled a group of network engineers to talk about what's on their minds. Topics today include why other IT departments adn end users are quick to blame the network first, and what can be done about it; using Nokia's open-source Containerlab for testing and development work; and why you shouldn't feel left behind when you hear talk about 400G and 800G networks.
1 … 192 193 194 195 196 … 3,818