HTTP/2 Rapid Reset: cómo desarmamos el ataque sin precedentes
El 25 de agosto de 2023, empezamos a observar algunos ataques de inundación HTTP inusualmente voluminosos que afectaban a muchos de nuestros clientes. Nuestro sistema DDoS automatizado detectó y mitigó estos ataques. Sin embargo, no pasó mucho tiempo antes de que empezaran a alcanzar tamaños sin precedentes, hasta alcanzar finalmente un pico de 201 millones de solicitudes por segundo, casi el triple que el mayor ataque registrado hasta ese momento.
Lo más inquietante es que el atacante fuera capaz de generar semejante ataque con una botnet de solo 20 000 máquinas. Hoy en día existen botnets formadas por cientos de miles o millones de máquinas. La web suele recibir solo entre 1000 y 3000 millones de solicitudes por segundo, por eso no parece imposible que utilizando este método se pudiera concentrar el volumen de solicitudes de toda una web en un pequeño número de objetivos.
Detección y mitigación
Se trataba de un vector de ataque novedoso a una escala sin precedentes, pero las soluciones de protección de Cloudflare pudieron mitigar en gran medida los efectos más graves de los ataques. Si bien Continue reading
HTTP/2 Zero-day 취약성은 이전에 없던 기록적인 DDoS 공격으로 이어집니다
오늘 Cloudflare는 Google, Amazon AWS와 함께 “HTTP/2 Rapid Reset” 공격이라는 새로운 zero-day 취약성의 존재를 공개했습니다. 이 공격은 HTTP/2 프로토콜의 약점을 악용하여 거대 하이퍼 볼류메트릭 분산 서비스 거부 (DDoS) 공격을 생성합니다. Cloudflare는 최근 몇 달간 이런 빗발치는 공격을 완화하였는데, 그중에는 이전에 우리가 목격한 것보다 규모가 3배 큰, 초당 2억 100만 요청(rps)을 넘어서는 공격도 있었습니다. Cloudflare는 2023년 8월 말부터 1,000만 rps가 넘는 기타 공격 1,100건 이상을 완화하였으며, 184건은 이전 DDoS 기록인 7,100만 rps보다도 큰 공격이었습니다.
위협 행위자들은 이러한 zero-day를 통해 취약성이라는 맥가이버 칼에 치명적인 도구를 새로 더하여 이전에 본 적 없는 규모로 피해자를 공격할 수 있게 되었습니다. 때로는 복잡하고 힘든 싸움이었지만, Cloudflare는 이러한 공격을 통해 zero-day 취약성의 영향을 완화하기 위한 기술을 개발할 수 있었습니다.
HTTP DDoS 완화를 위해 Cloudflare를 이용 중이시라면, 여러분은 보호받고 있습니다. 이 취약성에 대해 아래에서 더 알아보고, 스스로를 보호하기 위해 할 수 있는 리소스와 권장 사항을 확인해 보세요.
공격 분석: 모든 CSO가 알아야 할 사항
2023년 8월 말, Cloudflare 팀은 알 수 없는 위협 행위자가 개발한 새로운 zero-day 취약성을 발견하였습니다. 이 취약성은 인터넷 및 모든 웹 사이트의 작동에 필수적인 표준 HTTP/2 프로토콜을 악용합니다. Rapid Reset이라는 별명이 붙은 이 새로운 zero-day 취약성 공격은 요청 전송 후 즉각적 취소를 반복함으로써 HTTP/2 Continue reading
Alle Einzelheiten über HTTP/2 Rapid Reset
Am 25. August 2023 begannen wir, ungewöhnlich große HTTP-Angriffe auf viele unserer Kunden zu bemerken. Diese Angriffe wurden von unserem automatischen DDoS-System erkannt und abgewehrt. Es dauerte jedoch nicht lange, bis sie rekordverdächtige Ausmaße annahmen und schließlich einen Spitzenwert von knapp über 201 Millionen Anfragen pro Sekunde erreichten. Damit waren sie fast dreimal so groß wie der bis zu diesem Zeitpunkt größte Angriff, den wir jemals verzeichnet hatten.
Besorgniserregend ist die Tatsache, dass der Angreifer in der Lage war, einen solchen Angriff mit einem Botnetz von lediglich 20.000 Rechnern durchzuführen. Es gibt heute Botnetze, die aus Hunderttausenden oder Millionen von Rechnern bestehen. Bedenkt man, dass das gesamte Web in der Regel nur zwischen 1 bis 3 Milliarden Anfragen pro Sekunde verzeichnet, ist es nicht unvorstellbar, dass sich mit dieser Methode quasi die Anzahl aller Anfragen im Internet auf eine kleine Reihe von Zielen konzentrieren ließe.
Erkennen und Abwehren
Dies war ein neuartiger Angriffsvektor in einem noch nie dagewesenen Ausmaß, aber die bestehenden Schutzmechanismen von Cloudflare konnten die Wucht der Angriffe weitgehend bewältigen. Zunächst sahen wir einige Auswirkungen auf den Traffic unserer Kunden – Continue reading
HTTP/2 Zero-Day 漏洞導致破紀錄的 DDoS 攻擊
今天早些時候，Cloudflare 與 Google 和 Amazon AWS 一起披露了一個新型 zero-day 漏洞的存在，名為「HTTP/2 Rapid Reset」攻擊。此攻擊利用 HTTP/2 通訊協定中的弱點來產生巨大的超容量分散式阻斷服務 (DDoS) 攻擊。近幾個月來，Cloudflare 緩解了一系列此類攻擊，其中包括一起比我們之前觀察到的任何攻擊規模大三倍的攻擊，每秒要求數 (rps) 超過 2.01 億。自 2023 年 8 月底以來，Cloudflare 緩解了超過 1,100 起 rps 超過 1000 萬的其他攻擊，其中 184 起攻擊超過了我們之前 7100 萬 rps 的 DDoS 記錄。
這個 zero-day 漏洞為威脅執行者提供了一個重要的新工具，即漏洞中的瑞士軍刀，能夠以前所未有的規模利用和攻擊受害者。雖然這些攻擊有時非常複雜且難以應對，但正是因為它們，Cloudflare 才有機會開發專用技術來減輕 zero-day 漏洞的影響。
如果您使用 Cloudflare 進行 HTTP DDoS 緩解，則會受到保護。我們在下文提供了有關此漏洞的更多資訊，以及有關您可以採取哪些措施來保護自己的資源和建議。
解構攻擊：每個 CSO 需要瞭解的事情
2023 年 8 月下旬，我們的 Cloudflare 團隊注意到一個由未知威脅執行者開發的新 zero-day 漏洞，它所利用的標準 HTTP/2 通訊協定是一種基本通訊協定，對網際網路和所有網站的正常運作至關重要。這種新穎的 zero-day 漏洞攻擊稱為 Rapid Reset，它利用 HTTP/2 的串流取消功能，一次又一次地傳送要求並立即取消它。
透過大規模自動執行這種簡單的「要求、取消、要求、取消」模式，威脅執行者能夠建立阻斷服務並摧毀任何執行 HTTP/2 標準實作的伺服器或應用程式。此外，關於這起破紀錄的攻擊，還有一個重要事項需要注意，它涉及一個中等規模的殭屍網路，由大約 20,000 台機器組成。Cloudflare 會定期偵測比它大幾個數量級的殭屍網路 — 包括數十萬甚至數百萬台機器。對於一個相對較小的殭屍網路來說，輸出如此大量的要求，有可能使幾乎所有支援 HTTP/2 的伺服器或應用程式癱瘓，這凸顯了此漏洞對未受保護的網路的威脅有多大。
威脅執行者將殭屍網路與 HTTP/2 漏洞結合使用，以我們從未見過的速度放大了要求。因此，我們的 Cloudflare 團隊經歷了某種間歇性的邊緣不穩定。雖然我們的系統能夠緩解絕大部分傳入的攻擊，但這些流量會使我們網路中的部分元件過載，從而影響少數客戶的效能，並出現間歇性的 4xx 和 5xx 錯誤，而所有這些錯誤都被迅速解決了。
在我們為所有客戶成功緩解這些問題並阻止潛在攻擊之後，我們的團隊立即開始了負責任的披露程序。我們與業內同行進行了對話，看看我們如何共同努力，幫助推進我們的使命，並在向公眾發布此漏洞之前保護依賴我們網路的大部分網際網路。
我們在另一篇部落格文章中更詳細地介紹了該攻擊的技術細節：HTTP/2 Rapid Reset：解構破紀錄的攻擊。
Cloudflare 和業界如何遏止這種攻擊？
「完美的披露」並不存在。而遏止攻擊和回應新出現的事件需要組織和網路安全團隊以假定違規的心態生活 — 因為總會有另一個 zero-day 漏洞、新發展的威脅執行者團體以及前所未見的新穎攻擊和技術。
這種「假定違規」的心態是資訊分享以及在這種情況下確保網際網路保持安全的重要基礎。在 Cloudflare 遭遇並緩解這些攻擊的同時，我們也與業界合作夥伴合作，以確保整個產業能夠抵禦這種攻擊。
在緩解此攻擊的過程中，我們的 Cloudflare 團隊開發並專門構建了新技術來阻止這些 DDoS 攻擊，並進一步改進了我們自己的緩解措施來應對此攻擊和未來其他大規模攻擊。這些努力顯著提高了我們的整體緩解功能和復原能力。如果您使用 Cloudflare，我們相信您會受到保護。
我們的團隊也提醒正在開發修補程式以確保此漏洞不會被利用的 Web 伺服器軟體合作夥伴 — 請檢查網站以獲取更多資訊。
披露絕不是一勞永逸的事情。Cloudflare 的命脈是確保更好的網際網路，而這源於諸如此類的實例。當我們有機會與業界合作夥伴和政府合作，以確保網際網路不會受到廣泛影響時，我們正在盡自己的一份力量來提高每個組織的網路復原能力，無論其規模多大或類別為何。
若要深入瞭解緩解策略和下一步修補行動，請報名參加我們的網路研討會。
HTTP/2 Rapid Reset 和這些針對 Cloudflare 的破紀錄攻擊的起因是什麼？
奇怪的是，Cloudflare 竟然是最早目睹這些攻擊的公司之一。為什麼威脅執行者會攻擊一間擁有世界上最強大的 DDoS 攻擊防禦能力的公司？
實際情況是，Cloudflare 經常在攻擊轉向更脆弱的目標之前就發現了攻擊。威脅執行者在將工具部署到外部環境之前，需要先進行開發和測試。威脅執行者雖然掌握了破紀錄攻擊方法，但很難測試並瞭解攻擊的規模和有效性，因為他們沒有基礎架構可以承受他們發起的攻擊。由於我們分享網路效能的透明度，而且他們可以從我們的公開效能圖表中收集到攻擊測量結果，因此，威脅執行者很可能針對我們發起攻擊，藉此來瞭解該漏洞利用的功能。
但這項測試以及提早發現攻擊的能力，有助於我們針對攻擊開發緩解措施，從而使我們的客戶和整個產業受益。
從 CSO 到 CSO：您應該怎麼做？
我擔任了 20 多年的 CSO，接受過無數這樣的披露和公告。不過，無論是 Log4J、Solarwinds、EternalBlue WannaCry/NotPetya、Heartbleed 還是 Shellshock，所有這些安全事件都有一個共通性。一場大爆炸在全球蔓延並創造機會，徹底顛覆了我所領導的任何組織，無論產業或規模如何。
其中許多攻擊或漏洞都是我們無法控制的。但無論問題的起因是否在我的控制範圍之內，我所領導的任何成功計畫與那些不利於我們的計畫的區別在於，當識別這樣的 zero-day 漏洞和利用時，我們能夠做出回應。
雖然我希望我可以說這次的 Rapid Reset 可能會有所不同，但事實並非如此。無論你們是像我這樣經歷過數十年安全事件的洗禮，還是第一天從事這項工作，我都呼籲所有的 CSO，此刻正是確保你們受到保護，並支援網路事件回應團隊的時候。
我們直到今天才公開這些資訊，以讓盡可能多的安全廠商有機會做出反應。然而，在某些時候，公開披露這樣的 zero-day 威脅才是真正負責任的行為。而今天就是那一天。這意味著在今天之後，威脅執行者大多會意識到 HTTP/2 漏洞；而且，利用和啟動防禦者與攻擊者之間的競賽將不可避免地變得微不足道 — 先修補與先利用。組織應假設系統會遭受測試，並採取主動措施以確保保護。
對我來說，這會讓我想起像 Log4J 這樣的漏洞，由於每天都出現許多變體，因此，在未來幾週、幾個月甚至幾年內會不斷地取得成果。隨著越來越多的研究人員和威脅執行者對此漏洞進行實驗，我們可能會發現利用週期更短的不同變體，其中包含更高級的繞過方法。
就像 Log4J 一樣，管理此類事件並不像「執行修補程式，現在就完成了」那麼簡單。您需要將事件管理、修補和發展安全保護措施轉變為持續進行的流程，這是因為針對每個漏洞變體的修補程式可以降低您的風險，但並不能消除風險。
我無意危言聳聽，但我會直接說：你必須認真對待此事。將此事視為一個完全活動的事件，以確保您的組織平安無事。
對新變革標準的建議
雖然沒有任何一個安全事件會與下一個完全相同，但我們可以從中汲取一些教訓。CSO 們，以下是我的建議，必須立即實施。不僅在這種情況下，而且在未來的幾年中也一樣：
- 瞭解您的合作夥伴網路的外部連線，來透過以下緩解措施補救任何面向網際網路的系統。
- 瞭解您現有的安全保護措施以及您擁有的用於保護、偵測和回應攻擊的功能，並立即修復您網路中遇到的任何問題。
- 確保將 DDoS 保護部署在您的資料中心外部，因為如果流量到達資料中心，DDoS 攻擊將很難緩解。
- 確保您為應用程式（第 7 層）提供 DDoS 保護，並確保部署了 Web 應用程式防火牆。此外，作為最佳做法，請確保您為 DNS、網路流量（第 3 層）和 API 防火牆提供完整的 DDoS 保護
- 確保在所有面向網際網路的 Web 伺服器上部署 Web 伺服器和作業系統修補程式。此外，請確保所有自動化（例如，Terraform）組建和映像均已完全修補，這樣舊版 Web 伺服器就不會意外地透過安全映像部署到生產環境中。
- 最後一招，請考慮關閉 HTTP/2 和 HTTP/3（可能也易受攻擊）來緩解威脅。這只是萬不得已才能使用的手段，因為如果降級到 HTTP/1.1，將會出現重大的效能問題
- 考慮在邊界使用基於雲端的輔助 DDoS 第 7 層提供者以提高復原能力。
Cloudflare 的使命是幫助構建更好的網際網路。如果您擔心目前的 DDoS 保護狀態，我們非常樂意免費為您提供 DDoS 功能和復原能力，以緩解任何成功的 DDoS 攻擊嘗試。我們知道您所面臨的壓力，因為我們在過去 30 天內擊退了這些攻擊，並使我們本已最佳的系統變得更加完美。
如果您有興趣瞭解更多資訊，請觀看我們的網路研討會，以詳細瞭解 zero-day 漏洞以及如何應對。如果您不確定自己是否受到保護或想瞭解如何受到保護，請與我們聯絡。我們也在另一篇部落格文章中更詳細地介紹了有關該攻擊的更多技術細節： HTTP/2 Rapid Reset：解構破紀錄的攻擊。最後，如果您成為攻擊目標或需要即時保護，請聯絡您當地的 Cloudflare 代表或造訪https://www.cloudflare.com/zh-tw/under-attack-hotline/。
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
Apples for Apples: Measuring the Cost of Public vs. Private Clouds
Before making a choice of where to place workloads, enterprises need a consistent way to compare public and private cloud costs.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
MPLS-Auto-BW-Junos
In this write up I am covering how to design and apply MPLS Auto-Bandwidth feature set in Junos Platforms.
https://github.com/kashif-nawaz/MPLS-Auto-BW-Junos
Worth Reading: Some Thoughts on Digital Twins
I encountered several articles explaining the challenges of simulating your network in a virtual lab in the last few months, including:
- Some thoughts on digital twins by Jeff McLaughlin
- Network Simulation is hard – Part 1, Part 2 – by Pete Crocker
- Twenty-five open-source network emulators and simulators you can use in 2023 by Brian Linkletter
Enjoy!
Worth Reading: Some Thoughts on Digital Twins
I encountered several articles explaining the challenges of simulating your network in a virtual lab in the last few months, including:
- Some thoughts on digital twins by Jeff McLaughlin
- Network Simulation is hard – Part 1, Part 2 – by Pete Crocker
- Twenty-five open-source network emulators and simulators you can use in 2023 by Brian Linkletter
Enjoy!
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.
The post Heavy Networking 704: Roundtable Redux: Blaming The Network; Containerlab Love; 400G Envy appeared first on Packet Pushers.
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.Calico monthly roundup: September 2023
Welcome to the Calico monthly roundup: September edition! From open source news to live events, we have exciting updates to share—let’s get into it!
|
Discover how you can automate security, ensure consistency, and tightly align security with development practices in a microservices environment. |
The State of Calico Open Source: Usage & Adoption Report 2023 Get insights into Calico’s adoption across container and Kubernetes environments, in terms of platforms, data planes, and policies. |
Transforming Container Network Security with Calico Container FirewallOpen source news
- Share your Calico Open Source journey and win a $25.00 gift card – Your journey with Calico Open Source matters to us! Share your experience and insight on how you solve problems and build your network security using Calico. Book a meeting to tell us about your journey and where you seek information. As a thank you, we’ll send you a $25.00 gift card!
- Calico Live – Join the Calico community every Wednesday at 2:00 pm ET for a live discussion about learning how to leverage Calico and Kubernetes for networking and security. We will explore Kubernetes security and policy design, network flow logs and more. Join Continue reading