The QUIC handshake does not require client IP address validation before starting the security handshake. This means there is a risk that an attacker could spoof a client IP and cause a server to do cryptographic work and send data to a target victim IP (aka a reflection attack). RFC 9000 is careful to describe the risks this poses and provides mechanisms to reduce them (for example, see Sections 8 and 9.3.1). Until a client address is verified, a server employs an anti-amplification limit, sending a maximum of 3x as many bytes as it has received. Furthermore, a server can initiate address validation before engaging in the cryptographic handshake by responding with a Retry packet. The retry mechanism, however, adds an additional round-trip to the QUIC handshake sequence, negating some of its benefits compared to TCP. Real-world QUIC deployments use a range of strategies and heuristics to detect traffic loads and enable different mitigations.
In order to understand how the researchers triggered an amplification attack despite these QUIC guardrails, we first need to dive into how IP broadcast works.
In Internet Protocol version 4 (IPv4) addressing, the final address in any given subnet is a special broadcast IP address used to send packets to every node within the IP address range. Every node that is within the same subnet receives any packet that is sent to the broadcast address, enabling one sender to send a message that can be “heard” by potentially hundreds of adjacent nodes. This behavior is enabled by default in most network-connected systems and is critical for discovery of devices within the same IPv4 network.
\n \n \n
The broadcast address by nature poses a risk of DDoS amplification; for every one packet sent, hundreds of nodes have to process the traffic.
To combat the risk posed by broadcast addresses, by default most routers reject packets originating from outside their IP subnet which are targeted at the broadcast address of networks for which they are locally connected. Broadcast packets are only allowed to be forwarded within the same IP subnet, preventing attacks from the Internet from targeting servers across the world.
\n \n \n
The same techniques are not generally applied when a given router is not directly connected to a given subnet. So long as an address is not locally treated as a broadcast address, Border Gateway Protocol (BGP) or other routing protocols will continue to route traffic from external IPs toward the last IPv4 address in a subnet. Essentially, this means a “broadcast address” is only relevant within a local scope of routers and hosts connected together via Ethernet. To routers and hosts across the Internet, a broadcast IP address is routed in the same way as any other IP.
Each Cloudflare server is expected to be capable of serving content from every website on the Cloudflare network. Because our network utilizes Anycast routing, each server necessarily needs to be listening on (and capable of returning traffic from) every Anycast IP address in use on our network.
To do so, we take advantage of the loopback interface on each server. Unlike a physical network interface, all IP addresses within a given IP address range are made available to the host (and will be processed locally by the kernel) when bound to the loopback interface.
The mechanism by which this works is straightforward. In a traditional routing environment, longest prefix matching is employed to select a route. Under longest prefix matching, routes towards more specific blocks of IP addresses (such as 192.0.2.96/29, a range of 8 addresses) will be selected over routes to less specific blocks of IP addresses (such as 192.0.2.0/24, a range of 256 addresses).
While Linux utilizes longest prefix matching, it consults an additional step — the Routing Policy Database (RPDB) — before immediately searching for a match. The RPDB contains a list of routing tables which can contain routing information and their individual priorities. The default RPDB looks like this:
\n
$ ip rule show\n0:\tfrom all lookup local\n32766:\tfrom all lookup main\n32767:\tfrom all lookup default
\n
Linux will consult each routing table in ascending numerical order to try and find a matching route. Once one is found, the search is terminated and the route immediately used.
If you’ve previously worked with routing rules on Linux, you are likely familiar with the contents of the main table. Contrary to the existence of the table named “default”, “main” generally functions as the default lookup table. It is also the one which contains what we traditionally associate with route table information:
\n
$ ip route show table main\ndefault via 192.0.2.1 dev eth0 onlink\n192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2
\n
This is, however, not the first routing table that will be consulted for a given lookup. Instead, that task falls to the local table:
\n
$ ip route show table local\nlocal 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1\nlocal 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1\nbroadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1\nlocal 192.0.2.2 dev eth0 proto kernel scope host src 192.0.2.2\nbroadcast 192.0.2.255 dev eth0 proto kernel scope link src 192.0.2.2
\n
Looking at the table, we see two new types of routes — local and broadcast. As their names would suggest, these routes dictate two distinctly different functions: routes that are handled locally and routes that will result in a packet being broadcast. Local routes provide the desired functionality — any prefix with a local route will have all IP addresses in the range processed by the kernel. Broadcast routes will result in a packet being broadcast to all IP addresses within the given range. Both types of routes are added automatically when an IP address is bound to an interface (and, when a range is bound to the loopback (lo) interface, the range itself will be added as a local route).
Deployments of QUIC are highly dependent on the load-balancing and packet forwarding infrastructure that they sit on top of. Although QUIC’s RFCs describe risks and mitigations, there can still be attack vectors depending on the nature of server deployments. The reporting researchers studied QUIC deployments across the Internet and discovered that sending a QUIC Initial packet to one of Cloudflare’s broadcast addresses triggered a flood of responses. The aggregate amount of response data exceeded the RFC's 3x amplification limit.
Taking a look at the local routing table of an example Cloudflare system, we see a potential culprit:
\n
$ ip route show table local\nlocal 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1\nlocal 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1\nbroadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1\nlocal 192.0.2.2 dev eth0 proto kernel scope host src 192.0.2.2\nbroadcast 192.0.2.255 dev eth0 proto kernel scope link src 192.0.2.2\nlocal 203.0.113.0 dev lo proto kernel scope host src 203.0.113.0\nlocal 203.0.113.0/24 dev lo proto kernel scope host src 203.0.113.0\nbroadcast 203.0.113.255 dev lo proto kernel scope link src 203.0.113.0
\n
On this example system, the anycast prefix 203.0.113.0/24 has been bound to the loopback interface (lo) through the use of standard tooling. Acting dutifully under the standards of IPv4, the tooling has assigned both special types of routes — a local one for the IP range itself and a broadcast one for the final address in the range — to the interface.
While traffic to the broadcast address of our router’s directly connected subnet is filtered as expected, broadcast traffic targeting our routed anycast prefixes still arrives at our servers themselves. Normally, broadcast traffic arriving at the loopback interface does little to cause problems. Services bound to a specific port across an entire range will receive data sent to the broadcast address and continue as normal. Unfortunately, this relatively simple trait breaks down when normal expectations are broken.
Cloudflare’s frontend consists of several worker processes, each of which independently binds to the entire anycast range on UDP port 443. In order to enable multiple processes to bind to the same port, we use the SO_REUSEPORT socket option. While SO_REUSEPORT has additional benefits, it also causes traffic sent to the broadcast address to be copied to every listener.
Each individual QUIC server worker operates in isolation. Each one reacted to the same client Initial, duplicating the work on the server side and generating response traffic to the client's IP address. Thus, a single packet could trigger a significant amplification. While specifics will vary by implementation, a typical one-listener-per-core stack (which sends retries in response to presumed timeouts) on a 128-core system could result in 384 replies being generated and sent for each packet sent to the broadcast address.
Although the researchers demonstrated this attack on QUIC, the underlying vulnerability can affect other UDP request/response protocols that use sockets in the same way.
As a communication methodology, broadcast is not generally desirable for anycast prefixes. Thus, the easiest method to mitigate the issue was simply to disable broadcast functionality for the final address in each range.
Ideally, this would be done by modifying our tooling to only add the local routes in the local routing table, skipping the inclusion of the broadcast ones altogether. Unfortunately, the only practical mechanism to do so would involve patching and maintaining our own internal fork of the iproute2 suite, a rather heavy-handed solution for the problem at hand.
Instead, we decided to focus on removing the route itself. Similar to any other route, it can be removed using standard tooling:
\n
$ sudo ip route del 203.0.113.255 table local
\n
To do so at scale, we made a relatively minor change to our deployment system:
\n
{%- for lo_route in lo_routes %}\n {%- if lo_route.type == "broadcast" %}\n # All broadcast addresses are implicitly ipv4\n {%- do remove_route({\n "dev": "lo",\n "dst": lo_route.dst,\n "type": "broadcast",\n "src": lo_route.src,\n }) %}\n {%- endif %}\n {%- endfor %}
\n
In doing so, we effectively ensure that all broadcast routes attached to the loopback interface are removed, mitigating the risk by ensuring that the specification-defined broadcast address is treated no differently than any other address in the range.
While the vulnerability specifically affected broadcast addresses within our anycast range, it likely expands past our infrastructure. Anyone with infrastructure that meets the relatively narrow criteria (a multi-worker, multi-listener UDP-based service that is bound to all IP addresses on a machine with routable IP prefixes attached in such a way as to expose the broadcast address) will be affected unless mitigations are in place. We encourage network administrators and security professionals to assess their systems for configurations that may present a local amplification attack vector.
"],"published_at":[0,"2025-02-10T14:00+00:00"],"updated_at":[0,"2025-02-10T14:00:02.225Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1ywfoQRYAy0j73JBjHTFDk/87ba174c1326f65cb5d6d3ccd34bdf7c/image4.png"],"tags":[1,[[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"1U6ifhBwTuaJ2w4pjNOzNT"],"name":[0,"Network"],"slug":[0,"network"]}],[0,{"id":[0,"3OPPjcK7cKutTdeAjpThfG"],"name":[0,"Edge"],"slug":[0,"edge"]}],[0,{"id":[0,"64g1G2mvZyb6PjJsisO09T"],"name":[0,"DDoS"],"slug":[0,"ddos"]}],[0,{"id":[0,"4mFivBDCciYNedwQVKLKAg"],"name":[0,"HTTP3"],"slug":[0,"http3"]}],[0,{"id":[0,"2GdRQIOWsB1PBHEX7DUETr"],"name":[0,"Bug Bounty"],"slug":[0,"bug-bounty"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Josephine Chow"],"slug":[0,"josephine-chow"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/FvPR5o78CGkVBLZlFEzfC/e626e653812ecf15dc24dcc3d34f542b/Josephine_Chow.jpeg"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}],[0,{"name":[0,"June Slater"],"slug":[0,"june-slater"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1l6qTlpeXkHsEprg3W5qiq/1c6ba96fc658bf8295d8317a8a3fff9c/June-Slater.jpg"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}],[0,{"name":[0,"Bryton Herdes"],"slug":[0,"bryton"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2CtRZInMXDzWbBSlJZq6ob/cc0d484943cf18a7d24debb3d01a3ece/bryton.jpeg"],"location":[0,null],"website":[0,"https://next-hopself.net/"],"twitter":[0,"@next_hopself"],"facebook":[0,null]}],[0,{"name":[0,"Lucas Pardue"],"slug":[0,"lucas"],"bio":[0,"HTTP/2, HTTP/3 and QUIC @Cloudflare. IETF QUIC WG Co-Chair. I write some words, some code and occasionally speak."],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1k0fbniT2p2wjRfMognV4V/dca8d2e3a3e7fa4e24d7ddd9832eff1d/lucas.jpg"],"location":[0,"London"],"website":[0,null],"twitter":[0,"@SimmerVigor"],"facebook":[0,null]}]]],"meta_description":[0,"Cloudflare was recently contacted by researchers who discovered a broadcast amplification vulnerability through their QUIC Internet measurement research. Since being notified about this vulnerability, we've implemented a mitigation to help secure our infrastructure."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/mitigating-broadcast-address-attack"],"metadata":[0,{"title":[0,"QUIC action: patching a broadcast address amplification vulnerability"],"description":[0,"Cloudflare was recently contacted by researchers who discovered a broadcast amplification vulnerability through their QUIC Internet measurement research. Since being notified about this vulnerability, we've implemented a mitigation to help secure our infrastructure."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3N6luvd1VIhl6b8ZkSS4l8/190e0e98f855efde30f0477371c1f832/QUIC_action-_patching_a_broadcast_address_amplification_vulnerability-OG.png"]}]}],[0,{"id":[0,"63yGQGTniOUOFneFLwTb7a"],"title":[0,"Cloudflare meets new Global Cross-Border Privacy (CBPR) standards"],"slug":[0,"cloudflare-cbpr-a-global-privacy-first"],"excerpt":[0,"Cloudflare is the first organization globally to announce having been successfully audited against the ‘Global Cross-Border Privacy Rules’ system and ‘Global Privacy Recognition for Processors’."],"featured":[0,false],"html":[0,"
Cloudflare proudly leads the way with our approach to data privacy and the protection of personal information, and we’ve been an ardent supporter of the need for the free flow of data across jurisdictional borders. So today, on Data Privacy Day (also known internationally as Data Protection Day), we’re happy to announce that we’re adding our fourth and fifth privacy validations, and this time, they are global firsts! Cloudflare is the first organisation to announce that we have been successfully audited against the brand new Global Cross-Border Privacy Rules (Global CBPRs) for data controllers and the Global Privacy Recognition for Processors (Global PRP). These validations demonstrate our support and adherence to global standards that provide for privacy-respecting data flows across jurisdictions. Organizations that have been successfully audited will be formally certified when the certifications officially launch, which we expect to happen later in 2025.
Our participation in the Global CBPRs and Global PRP joins our roster of privacy validations: we were one of the first cybersecurity organizations to certify to the international privacy standard ISO 27701:2019 when it was published, and in 2022 we also certified to the cloud privacy certification, ISO 27018:2019. In 2023, we added our third privacy validation, undergoing a review by an independent monitoring body in the European Union (EU) and declared to be adherent to the first official GDPR code of conduct — the EU Cloud Code of Conduct.
Taking these privacy certifications together, Cloudflare demonstrates that we are meeting key official privacy validations in 39 jurisdictions around the world, from Australia and Austria to Sweden and the United States. An additional four jurisdictions (United Kingdom, Bermuda, Mauritius, and the Dubai International Finance Centre) are also in the process of joining and recognising the Global CBPR certifications. That's important for Cloudflare customers as it provides reassurance that the privacy practices we have built are recognised by governments around the world.
In the last three years, governments across the world have been busy preparing two brand-new international privacy standards. A major milestone was achieved on April 30, 2024 when the Global CBPR System was established. The CBPRs are a voluntary, enforceable, international, accountability-based system that facilitates privacy-respecting data flows among members’ economies. They provide a baseline level of privacy protection for consumers through a set of rules on how to handle people’s personal information. This facilitates the free flow of data by upholding consumer privacy across participating members, despite each jurisdiction having their own individual data protection laws.
The CBPR System was developed by the Global CBPR Forum, an intergovernmental forum between the governments of Australia, Canada, Japan, Republic of Korea, Mexico, Philippines, Singapore, Chinese Taipei, and the United States. The United Kingdom is also an associate member of the CBPR Forum, as are Bermuda, Mauritius, and the Dubai IFC, signifying their intent to join as full members in the future.
Over the last year, we have been busy preparing for the launch of the Global CBPR System. On May 1, 2024 — the very first day after the establishment of the system — Cloudflare applied to join. And we have now achieved the major milestone of successfully completing audits against the requirements, meaning we expect to be the first organization in the world to be newly certified to the Global CBPR system, as well as the related Global Privacy Recognition for Processors, when companies can officially be certified, which is expected later in 2025.
The Global CBPR System contains a detailed list of fifty requirements that organizations must meet in order to be certified under the scheme. The requirements derive from the nine Global CBPR Privacy Principles, which are consistent with the core principles of the Organisation for Economic Co-operation and Development (OECD)Guidelines on the Protection of Privacy and Trans-Border Flows of Personal Data. The fifty requirements cover how organizations should collect, manage, and safeguard personal information in their custody. Organizations must meet every one of the fifty requirements in order to be Global CBPR certified. The nine principles underlying the requirements are:
Preventing Harm
Notice
Collection Limitation
Uses of Personal Information
Choice
Integrity of Personal Information
Security Safeguards
Access and Correction
Accountability
The nine Global CBPR Privacy Principles
The Global CBPR certification covers the handling of personal information controlled by the organization, such as the personal details of customers, employees, and job applicants. For Cloudflare, this also includes network information — our observations about how our global cloud platform handles server, network, or traffic data generated by Cloudflare in the course of providing our services.
The related Global Privacy Recognition for Processors (PRP) certification covers the handling of personal information processed by the organization on behalf of a different organization, usually their customer. The eighteen requirements of the PRP relate to the two privacy principles most relevant when processing this information on behalf of another organization: Security Safeguards and Accountability. For Cloudflare, this covers the processing of data pursuant to the Data Processing Addendum we sign with all of our customers, chiefly, the Customer Content flowing across our network and the Customer Logs generated by those data flows. Organizations must meet every one of the eighteen requirements in order to be Global PRP certified.
\n
\n
A deeper dive into some of the requirements of the Global CBPRs
As noted, the key requirements of the Global CBPRs and the Global PRP cover the well-known data protection principles of notice, choice, collection limitation (data minimization), the right of data subject access and correction, providing adequate security, preventing harm, integrity of personal information, accountability, and uses of personal information. There are dozens of requirements that cover these principles, so we’ll just touch on a few of them here.
Let’s first look at the principle of notice. One of the more obvious requirements from the CBPRs is question 1:
Do you provide clear and easily accessible statements about your practices and policies that govern the personal information described above (a privacy statement)?
Being transparent about the collection and use of personal information is a key principle of privacy and data protection, and transparency is one of Cloudflare’s core commitments. Documenting our practices and policies in regard to how we use personal information allows individuals to decide if they want to provide their information, and that’s why it’s best practice for the privacy notice to be available and visible at the time the information is being collected. Indeed, this concept of providing notice is clear from Article 13 of the EU’s GDPR. Cloudflare meets this CBPR requirement by providing a clear and accessible privacy notice visible from the footer of each page on our website. We also provide a link to the notice when we collect personal data such as through a form on a webpage.
In terms of how we use personal information, question 8 asks:
Do you limit the use of the personal information you collect (whether directly or through the use of third parties acting on your behalf) as identified in your privacy statement?
It has long been a commitment of Cloudflare’s that we only use the personal information we collect for the purposes of providing the services we offer. Our business is built on providing customers with the tools to protect their network applications and to make them faster, more secure, more reliable, and more private. In our Privacy Policy, we commit that we will “only share or otherwise disclose your personal information as necessary to provide our Services or as otherwise described in this Policy, except in cases where we first provide you with notice and the opportunity to consent.” And we maintain internal documentation (in keeping with the CBPR’s accountability principle) to document the data we are processing and the purposes for which we process it.
Another key set of requirements in both the Global CBPRs and the Global PRP have to do with security safeguards. CBPR requirement question 27 asks:
Describe the physical, technical and administrative safeguards you have implemented to protect personal information against risks such as loss or unauthorized access, destruction, use, modification or disclosure of information or other misuses?
The similar requirement in the Global PRP is question 2:
Describe the physical, technical and administrative safeguards that implement your organization’s information security policy.
Cloudflare has implemented an information security program in accordance with the ISO/IEC 27000 family of standards. Details of Cloudflare’s security program are documented in Annex 2 (“Technical and Organizational Security Measures”) of Cloudflare's Customer Data Processing Addendum, including the physical, technical and administrative safeguards implemented to protect personal information.
Related to the Accountability principle, question 46 asks:
Do you have mechanisms in place with personal information processors, agents, contractors, or other service providers pertaining to personal information they process on your behalf, to ensure that your obligations to the individual will be met?
When we have vendors who handle any of our, or our customers’, personal information, we require them to sign a Data Processing Addendum with us. This ensures the commitments we make to our customers in our customer agreements in turn flow through to our vendors, including the security requirements — holding them, and us, accountable.
We are excited about the launch of the Global CBPR certifications, expected later in 2025, and we are proud that on this Data Privacy Day, we can yet again demonstrate our commitment to universally held principles for protecting the privacy of personal data.
You can find more about the Global CBPR System, the Global PRP, download a full copy of the requirements, and keep up to date with related news at globalcbpr.org.
For the latest information about our certifications, please visit our Trust Hub. Customers can also find out how to download a copy of Cloudflare’s certifications and reports from the Cloudflare dashboard.
\n \n \n "],"published_at":[0,"2025-01-28T00:00+00:00"],"updated_at":[0,"2025-02-03T16:07:08.820Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4SJhJ9Vtg6wCK1SPhlLs75/95ce4ff10ba8cf1e1197ec5abfe52e8b/image3.png"],"tags":[1,[[0,{"id":[0,"4NRwgGJnSZwfl5aeAPjvOe"],"name":[0,"Certification"],"slug":[0,"certification"]}],[0,{"id":[0,"3BWeMuiOShelE7QM48sW9j"],"name":[0,"Privacy"],"slug":[0,"privacy"]}],[0,{"id":[0,"6twWoAUd2y0j3cAMfKjwcW"],"name":[0,"Compliance"],"slug":[0,"compliance"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"16yk8DVbNNifxov5cWvAov"],"name":[0,"Policy & Legal"],"slug":[0,"policy"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Rory Malone"],"slug":[0,"rory"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2bKOaTS3yX5KSIZXsCwLS4/81eed0f0e7ce7b3a6b5c2683c30a8205/rory.png"],"location":[0,"London, UK"],"website":[0,"https://www.cloudflare.com/trust-hub/compliance-resources"],"twitter":[0,"@roryinlondon"],"facebook":[0,null]}],[0,{"name":[0,"Emily Hancock"],"slug":[0,"emily-hancock"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6WoITZeDW2tg5JO91UOF0Y/0510a8ee70b2daeb2cb325aa6f8e0ceb/emily-hancock.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}]]],"meta_description":[0,"Cloudflare is the first organisation globally to announce we have been successfully audited against the brand-new international ‘Global Cross-Border Privacy Rules’ system and the brand new ‘Global Privacy Recognition for Processors’. Cloudflare will be certified from day one when the certifications launch later in 2025."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"LOC: New Global CBPR and Global PRP privacy certifications"],"enUS":[0,"English for Locale"],"zhCN":[0,"Translated for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"Translated for Locale"],"deDE":[0,"Translated for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"Translated for Locale"],"koKR":[0,"Translated for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"Translated for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/cloudflare-cbpr-a-global-privacy-first"],"metadata":[0,{"title":[0,"Cloudflare meets new Global Cross Border Privacy standards"],"description":[0,"Cloudflare is the first organisation globally to announce we have been successfully audited against the brand-new international ‘Global Cross-Border Privacy Rules’ system and the brand new ‘Global Privacy Rules for Processors’. Cloudflare will be certified from day one when the certifications launch later in 2025."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/8yWeBIDbBGS88QDJHOQGd/c71c0b1ff73bfda977bb0597bcf5c5aa/OG_Share_2024__6_.png"]}]}],[0,{"id":[0,"4tycw0mGr6bpp3AbV17wEK"],"title":[0,"Cloudflare thwarts over 47 million cyberthreats against Jewish and Holocaust educational websites"],"slug":[0,"cloudflare-thwarts-over-47-million-cyberthreats-against-jewish-and-holocaust"],"excerpt":[0,"January 27 marks the International Holocaust Remembrance Day — a solemn occasion to honor the memory of the six million Jews who perished in the Holocaust, along with countless others who fell victim"],"featured":[0,false],"html":[0,"
January 27 marks the International Holocaust Remembrance Day — a solemn occasion to honor the memory of the six million Jews who perished in the Holocaust, along with countless others who fell victim to the Nazi regime's campaign of hatred and intolerance. This tragic chapter in human history serves as a stark reminder of the catastrophic consequences of prejudice and extremism.
The United Nations General Assembly designated January 27 — the anniversary of the liberation of Auschwitz-Birkenau — as International Holocaust Remembrance Day. This year, we commemorate the 80th anniversary of the liberation of this infamous extermination camp.
As the world reflects on this dark period, a troubling resurgence of antisemitism underscores the importance of vigilance. This growing hatred has spilled into the digital realm, with cyberattacks increasingly targeting Jewish and Holocaust remembrance and educational websites — spaces dedicated to preserving historical truth and fostering awareness.
For this reason, here at Cloudflare, we began to publish annual reports covering cyberattacks that target these organizations. These cyberattacks include DDoS attacks as well as bot and application attacks. The insights and trends are based on websites protected by Cloudflare. This is our fourth report, and you can view our previous Holocaust Remembrance Day blogs here.
At Cloudflare, we are proud to support these vital organizations through Project Galileo, an initiative providing free security protections to vulnerable groups worldwide. If you or your organization could benefit from this program, consider applying today to help protect these essential platforms and the invaluable work they do.
One of the organizations that we protect through Project Galileo is Muzeon, a museum dedicated to preserving Jewish history in Cluj-Napoca, Romania. Muzeon faced significant cyberattacks that impacted their website’s performance and hindered operations before using Cloudflare.
As part of Project Galileo, Muzeon implemented Cloudflare's DDoS mitigation, Web Application Firewall (WAF), Managed DNS, and other services. These measures drastically reduced the attacks and allowed Muzeon to focus on its important mission of storytelling and preserving cultural heritage.
Cloudflare’s solutions not only protected their digital infrastructure but also freed up time for Muzeon to expand its interactive exhibits, ensuring they could continue sharing their essential work globally. You can read more about this case study here.
Following the October 7, 2023, Hamas-led attack on Israel, there has been a surge in global antisemitic incidents. In the U.S. alone there have been more than 10,000 antisemitic incidents from October 7, 2023 to September 24, 2024, representing an over 200-percent increase compared to the incidents reported during the same period a year before. As we’ve seen, the digital world is often a mirror to the real world. As a result, it is not surprising that websites dedicated to sharing information about the Holocaust, as well as Jewish memorial and education platforms, are now increasingly being targeted online.
\n
\n
Cyberattacks against Jewish and Holocaust educational websites
For the years 2020, 2021, and 2022, the number of cyberthreats targeting Holocaust and Jewish educational and memorial websites protected by Cloudflare was, on average, 736,339 malicious HTTP requests annually.
After the October 7 Hamas-led attack, cyberattacks skyrocketed. In 2023, the amount of blocked HTTP requests surged by 872% to 35.7 million compared to 2022. Most of these cyberattacks occurred after October 7, 2023.
In 2024, the number of blocked HTTP requests exceeded 47 million — representing a 30% increase compared to 2023. Over 3 out of every 100 HTTP requests towards Holocaust and Jewish memorial and education websites protected by Cloudflare were malicious and blocked.
\n \n \n
Cyber threats against Holocaust and Jewish memorial and educational websites by year
In the fourth quarter of 2023, the volume of malicious requests exceeded 27 million. Throughout the first three quarters of 2024, we saw a gradual decrease in the quantity of malicious requests. But in the fourth quarter of 2024, cyberattacks spiked by 33%, to 36 million requests, following the one-year anniversary of the October 7 assault.
\n \n \n
Cyber threats against Holocaust and Jewish memorial and educational websites by quarter
Breaking down the quarters into months, we can see an initial peak in October 2023 after the October 7 Hamas-led attack. The volume of cyberattacks remained elevated during November and December 2023.
Afterward, as we entered 2024, the quantity and percentage of cyberattacks against these websites significantly decreased. In November, over a third (34%) of all requests towards these websites were blocked, with over 36 million requests blocked that month alone.
\n \n \n
Cyber threats against Holocaust and Jewish memorial and educational websites by month
On the International Holocaust Remembrance Day, we reflect on the importance of standing against both antisemitism and cyber threats — issues that have escalated since the October 7, 2023, Hamas-led attack.
At Cloudflare, we are unwavering in our commitment to create a safer, more inclusive Internet. The rise in antisemitism has made it even more critical to protect educational websites and communities from harmful cyber attacks. We invite everyone to join us in this fight. Even with our free plan, we offer strong security and performance, ensuring that vital resources and websites remain safe and accessible. By working together, we can protect the lessons of history and foster a more secure digital world for all.
"],"published_at":[0,"2025-01-27T22:07:41.520Z"],"updated_at":[0,"2025-01-27T22:19:21.660Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1wdOcqwzoqxCzB4GgUBSH6/96660a380f9dbc7327182fdd7a34750f/BLOG-2659_1.png"],"tags":[1,[[0,{"id":[0,"64g1G2mvZyb6PjJsisO09T"],"name":[0,"DDoS"],"slug":[0,"ddos"]}],[0,{"id":[0,"54Tkjs4keJGD0ddq0dfL5Y"],"name":[0,"DDoS Reports"],"slug":[0,"ddos-reports"]}],[0,{"id":[0,"5kIxDMJCg3PXQxVINDL0Cw"],"name":[0,"Attacks"],"slug":[0,"attacks"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"2s3r2BdfPas9oiGbGRXdmQ"],"name":[0,"Network Services"],"slug":[0,"network-services"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Omer Yoachimik"],"slug":[0,"omer"],"bio":[0,"Product Manager / Cloudflare's DDoS Protection Service"],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6TXRnB1v4ZHGiL3nRlvRTZ/e47fa218da976d21b5074229b33b9589/omer.png"],"location":[0,"London"],"website":[0,null],"twitter":[0,"@OmerYoahimik"],"facebook":[0,null]}]]],"meta_description":[0,"January 27 marks the International Holocaust Remembrance Day — a solemn occasion to honor the memory of the six million Jews who perished in the Holocaust, along with countless others who fell victim to the Nazi regime's campaign of hatred and intolerance. "],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/cloudflare-thwarts-over-47-million-cyberthreats-against-jewish-and-holocaust"],"metadata":[0,{"title":[0],"description":[0],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5Bs1Bf8TWP6ingEeZgqvX5/67882e148c2aa037b7216a48f20bd08b/OG_Share_2024__7_.png"]}]}],[0,{"id":[0,"1qstsc71dUKtPimn2nGewc"],"title":[0,"Record-breaking 5.6 Tbps DDoS attack and global DDoS trends for 2024 Q4"],"slug":[0,"ddos-threat-report-for-2024-q4"],"excerpt":[0,"2024 ended with a bang. Cloudflare mitigated another record-breaking DDoS attack peaking at 5.6 Tbps."],"featured":[0,false],"html":[0,"
Welcome to the 20th edition of the Cloudflare DDoS Threat Report, marking five years since our first report in 2020.
Published quarterly, this report offers a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network. In this edition, we focus on the fourth quarter of 2024 and look back at the year as a whole.
When we published our first report, Cloudflare’s global network capacity was 35 Terabits per second (Tbps). Since then, our network’s capacity has grown by 817% to 321 Tbps. We also significantly expanded our global presence by 65% from 200 cities in the beginning of 2020 to 330 cities by the end of 2024.
Using this massive network, we now serve and protect nearly 20% of all websites and close to 18,000 unique Cloudflare customer IP networks. This extensive infrastructure and customer base uniquely positions us to provide key insights and trends that benefit the wider Internet community.
In 2024, Cloudflare’s autonomous DDoS defense systems blocked around 21.3 million DDoS attacks, representing a 53% increase compared to 2023. On average, in 2024, Cloudflare blocked 4,870 DDoS attacks every hour.
In the fourth quarter, over 420 of those attacks were hyper-volumetric, exceeding rates of 1 billion packets per second (pps) and 1 Tbps. Moreover, the amount of attacks exceeding 1 Tbps grew by a staggering 1,885% quarter-over-quarter.
During the week of Halloween 2024, Cloudflare’s DDoS defense systems successfully and autonomously detected and blocked a 5.6 Terabit per second (Tbps) DDoS attack — the largest attack ever reported.
To learn more about DDoS attacks and other types of cyber threats, visit our Learning Center, access previous DDoS threat reports on the Cloudflare blog, or visit our interactive hub, Cloudflare Radar. There's also a free API for those interested in investigating these and other Internet trends. You can also learn more about the methodologies used in preparing these reports.
In 2024 Q4 alone, Cloudflare mitigated 6.9 million DDoS attacks. This represents a 16% increase quarter-over-quarter (QoQ) and 83% year-over-year (YoY).
Of the 2024 Q4 DDoS attacks, 49% (3.4 million) were Layer 3/Layer 4 DDoS attacks and 51% (3.5 million) were HTTP DDoS attacks.
The majority of the HTTP DDoS attacks (73%) were launched by known botnets. Rapid detection and blocking of these attacks were made possible as a result of operating a massive network and seeing many types of attacks and botnets. In turn, this allows our security engineers and researchers to craft heuristics to increase mitigation efficacy against these attacks.
An additional 11% were HTTP DDoS attacks that were caught pretending to be a legitimate browser. Another 10% were attacks which contained suspicious or unusual HTTP attributes. The remaining 8% “Other” were generic HTTP floods, volumetric cache busting attacks, and volumetric attacks targeting login endpoints.
\n \n \n
Top HTTP DDoS attack vectors: 2024 Q4
These attack vectors, or attack groups, are not necessarily exclusive. For example, known botnets also impersonate browsers and have suspicious HTTP attributes, but this breakdown is our attempt to categorize the HTTP DDoS attacks in a meaningful way.
As of this report’s publication, the current stable version of Chrome for Windows, Mac, iOS, and Android is 132, according to Google’s release notes. However, it seems that threat actors are still behind, as thirteen of the top user agents that appeared most frequently in DDoS attacks were Chrome versions ranging from 118 to 129.
The HITV_ST_PLATFORM user agent had the highest share of DDoS requests out of total requests (99.9%), making it the user agent that’s used almost exclusively in DDoS attacks. In other words, if you see traffic coming from the HITV_ST_PLATFORM user agent, there is a 0.1% chance that it is legitimate traffic.
Threat actors often avoid using uncommon user agents, favoring more common ones like Chrome to blend in with regular traffic. The presence of the HITV_ST_PLATFORM user agent, which is associated with smart TVs and set-top boxes, suggests that the devices involved in certain cyberattacks are compromised smart TVs or set-top boxes. This observation highlights the importance of securing all Internet-connected devices, including smart TVs and set-top boxes, to prevent them from being exploited in cyberattacks.
\n \n \n
Top user agents abused in DDoS attacks: 2024 Q4
The user agent hackney came in second place, with 93% of requests containing this user agent being part of a DDoS attack. If you encounter traffic coming from the hackney user agent, there is a 7% chance that it is legitimate traffic. Hackney is an HTTP client library for Erlang, used for making HTTP requests and is popular in Erlang/Elixir ecosystems.
Additional user agents that were used in DDoS attacks are uTorrent, which is associated with a popular BitTorrent client for downloading files. Go-http-client and fasthttp were also commonly used in DDoS attacks. The former is the default HTTP client in Go’s standard library and the latter is a high-performance alternative. fasthttp is used to build fast web applications, but is often exploited for DDoS attacks and web scraping too.
HTTP methods (also called HTTP verbs) define the action to be performed on a resource on a server. They are part of the HTTP protocol and allow communication between clients (such as browsers) and servers.
The GET method is most commonly used. Almost 70% of legitimate HTTP requests made use of the GET method. In second place is the POST method with a share of 27%.
With DDoS attacks, we see a different picture. Almost 14% of HTTP requests using the HEAD method were part of a DDoS attack, despite it hardly being present in legitimate HTTP requests (0.75% of all requests). The DELETE method came in second place, with around 7% of its usage being for DDoS purposes.
The disproportion between methods commonly seen in DDoS attacks versus their presence in legitimate traffic definitely stands out. Security administrators can use this information to optimize their security posture based on these headers.
\n \n \n
Distribution of HTTP methods in DDoS attacks and legitimate traffic: 2024 Q4
DDoS attacks often target the root of the website (“/”), but in other cases, they can target specific paths. In 2024 Q4, 98% of HTTP requests towards the /wp-admin/ path were part of DDoS attacks. The /wp-admin/ path is the default administrator dashboard for WordPress websites.
Obviously, many paths are unique to the specific website, but in the graph below, we’ve provided the top generic paths that were attacked the most. Security administrators can use this data to strengthen their protection on these endpoints, as applicable.
\n \n \n
Top HTTP paths targeted by HTTP DDoS attacks: 2024 Q4
In Q4, almost 94% of legitimate traffic was HTTPS. Only 6% was plaintext HTTP (not encrypted). Looking at DDoS attack traffic, around 92% of HTTP DDoS attack requests were over HTTPS and almost 8% were over plaintext HTTP.
\n \n \n
HTTP vs. HTTPS in legitimate traffic and DDoS attacks: 2024 Q4
An additional common attack vector, or rather, botnet type, is Mirai. Mirai attacks accounted for 6% of all network layer DDoS attacks — a 131% increase QoQ. In 2024 Q4, a Mirai-variant botnet was responsible for the largest DDoS attack on record, but we’ll discuss that further in the next section.
Before moving on to the next section, it’s worthwhile to discuss the growth in additional attack vectors that were observed this quarter.
\n \n \n
Top emerging threats: 2024 Q4
Memcached DDoS attacks saw the largest growth, with a 314% QoQ increase. Memcached is a database caching system for speeding up websites and networks. Memcached servers that support UDP can be abused to launch amplification or reflection DDoS attacks. In this case, the attacker would request content from the caching system and spoof the victim's IP address as the source IP in the UDP packets. The victim will be flooded with the Memcache responses, which can be up to 51,200x larger than the initial request.
BitTorrent DDoS attacks also surged this quarter by 304%. The BitTorrent protocol is a communication protocol used for peer-to-peer file sharing. To help the BitTorrent clients find and download the files efficiently, BitTorrent clients may utilize BitTorrent Trackers or Distributed Hash Tables (DHT) to identify the peers that are seeding the desired file. This concept can be abused to launch DDoS attacks. A malicious actor can spoof the victim’s IP address as a seeder IP address within Trackers and DHT systems. Then clients would request the files from those IP addresses. Given a sufficient number of clients requesting the file, it can flood the victim with more traffic than it can handle.
On October 29, a 5.6 Tbps UDP DDoS attack launched by a Mirai-variant botnet targeted a Cloudflare Magic Transit customer, an Internet service provider (ISP) from Eastern Asia. The attack lasted only 80 seconds and originated from over 13,000 IoT devices. Detection and mitigation were fully autonomous by Cloudflare’s distributed defense systems. It required no human intervention, didn’t trigger any alerts, and didn’t cause any performance degradation. The systems worked as intended.
\n \n \n
Cloudflare’s autonomous DDoS defenses mitigate a 5.6 Tbps Mirai DDoS attack without human intervention
While the total number of unique source IP addresses was around 13,000, the average unique source IP addresses per second was 5,500. We also saw a similar number of unique source ports per second. In the graph below, each line represents one of the 13,000 different source IP addresses, and as portrayed, each contributed less than 8 Gbps per second. The average contribution of each IP address per second was around 1 Gbps (~0.012% of 5.6 Tbps).
\n \n \n
The 13,000 source IP addresses that launched the 5.6 Tbps DDoS attack
In 2024 Q3, we started seeing a rise in hyper-volumetric network layer DDoS attacks. In 2024 Q4, the amount of attacks exceeding 1 Tbps increased by 1,885% QoQ and attacks exceeding 100 Million pps (packets per second) increased by 175% QoQ. 16% of the attacks that exceeded 100 Million pps also exceeded 1 Billion pps.
\n \n \n
Distribution of hyper-volumetric L3/4 DDoS attacks: 2024 Q4
The majority of HTTP DDoS attacks (63%) did not exceed 50,000 requests per second. On the other side of the spectrum, 3% of HTTP DDoS attacks exceeded 100 million requests per second.
Similarly, the majority of network layer DDoS attacks are also small. 93% did not exceed 500 Mbps and 87% did not exceed 50,000 packets per second.
The majority of HTTP DDoS attacks (72%) end in under ten minutes. Approximately 22% of HTTP DDoS attacks last over one hour, and 11% last over 24 hours.
Similarly, 91% of network layer DDoS attacks also end within ten minutes. Only 2% last over an hour.
Overall, there was a significant QoQ decrease in the duration of DDoS attacks. Because the duration of most attacks is so short, it is not feasible, in most cases, for a human to respond to an alert, analyze the traffic, and apply mitigation. The short duration of attacks emphasizes the need for an in-line, always-on, automated DDoS protection service.
In the last quarter of 2024, Indonesia remained the largest source of DDoS attacks worldwide for the second consecutive quarter. To understand where attacks are coming from, we map the source IP addresses launching HTTP DDoS attacks because they cannot be spoofed, and for Layer 3/Layer 4 DDoS attacks, we use the location of our data centers where the DDoS packets were ingested. This lets us overcome the spoofability that is possible in Layer 3/Layer 4. We’re able to achieve geographical accuracy due to our extensive network spanning over 330 cities around the world.
Hong Kong came in second, having moved up five spots from the previous quarter. Singapore advanced three spots, coming in third place.
An autonomous system (AS) is a large network or group of networks that has a unified routing policy. Every computer or device that connects to the Internet is connected to an AS. To find out what your AS is, visit https://radar.cloudflare.com/ip.
When looking at where the DDoS attacks originate from, specifically HTTP DDoS attacks, there are a few autonomous systems that stand out.
The AS that we saw the most HTTP DDoS attack traffic from in 2024 Q4 was German-based Hetzner (AS24940). Almost 5% of all HTTP DDoS requests originated from Hetzer’s network, or in other words, 5 out of every 100 HTTP DDoS requests that Cloudflare blocked originated from Hetzner.
Top 10 largest source networks of DDoS attacks: 2024 Q4
For many network operators such as the ones listed above, it can be hard to identify the malicious actors that abuse their infrastructure for launching attacks. To help network operators and service providers crack down on the abuse, we provide a freeDDoS Botnet threat intelligence feed that provides ASN owners a list of their IP addresses that we’ve seen participating in DDoS attacks.
When surveying Cloudflare customers that were targeted by DDoS attacks, the majority said they didn’t know who attacked them. The ones that did know reported their competitors as the number one threat actor behind the attacks (40%). Another 17% reported that a state-level or state-sponsored threat actor was behind the attack, and a similar percentage reported that a disgruntled user or customer was behind the attack.
Another 14% reported that an extortionist was behind the attacks. 7% claimed it was a self-inflicted DDoS, 2% reported hacktivism as the cause of the attack, and another 2% reported that the attacks were launched by former employees.
In the final quarter of 2024, as anticipated, we observed a surge in Ransom DDoS attacks. This spike was predictable, given that Q4 is a prime time for cybercriminals, with increased online shopping, travel arrangements, and holiday activities. Disrupting these services during peak times can significantly impact organizations' revenues and cause real-world disruptions, such as flight delays and cancellations.
In Q4, 12% of Cloudflare customers that were targeted by DDoS attacks reported being threatened or extorted for a ransom payment. This represents a 78% QoQ increase and 25% YoY growth compared to 2023 Q4.
\n \n \n
Reported Ransom DDoS attacks by quarter: 2024
Looking back at the entire year of 2024, Cloudflare received the most reports of Ransom DDoS attacks in May. In Q4, we can see the gradual increase starting from October (10%), November (13%), and December (14%) — a seven-month-high.
In 2024 Q4, China maintained its position as the most attacked country. To understand which countries are subject to more attacks, we group DDoS attacks by our customers’ billing country.
Philippines makes its first appearance as the second most attacked country in the top 10. Taiwan jumped to third place, up seven spots compared to last quarter.
In the map below, you can see the top 10 most attacked locations and their ranking change compared to the previous quarter.
\n \n \n
Top 10 most attacked locations by DDoS attacks: 2024 Q4
In the fourth quarter of 2024, the Telecommunications, Service Providers and Carriers industry jumped from the third place (last quarter) to the first place as the most attacked industry. To understand which industries are subject to more attacks, we group DDoS attacks by our customers’ industry. The Internet industry came in second, followed by Marketing and Advertising in third.
The Banking & Financial Services industry dropped seven places from number one in 2024 Q3 to number eight in Q4.
\n \n \n
Top 10 most attacked industries by DDoS attacks: 2024 Q4
The fourth quarter of 2024 saw a surge in hyper-volumetric Layer 3/Layer 4 DDoS attacks, with the largest one breaking our previous record, peaking at 5.6 Tbps. This rise in attack size renders capacity-limited cloud DDoS protection services or on-premise DDoS appliances obsolete.
The growing use of powerful botnets, driven by geopolitical factors, has broadened the range of vulnerable targets. A rise in Ransom DDoS attacks is also a growing concern.
Too many organizations only implement DDoS protection after suffering an attack. Our observations show that organizations with proactive security strategies are more resilient. At Cloudflare, we invest in automated defenses and a comprehensive security portfolio to provide proactive protection against both current and emerging threats.
With our 321 Tbps network spanning 330 cities globally, we remain committed to providing unmetered and unlimited DDoS protection no matter the size, duration and quantity of the attacks.
"],"published_at":[0,"2025-01-21T14:00+00:00"],"updated_at":[0,"2025-02-18T10:22:14.259Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6guiqnKfcklw6BYnwasnf2/194151e6f9a2b428cc71d29c1a7414c6/image2.png"],"tags":[1,[[0,{"id":[0,"64g1G2mvZyb6PjJsisO09T"],"name":[0,"DDoS"],"slug":[0,"ddos"]}],[0,{"id":[0,"54Tkjs4keJGD0ddq0dfL5Y"],"name":[0,"DDoS Reports"],"slug":[0,"ddos-reports"]}],[0,{"id":[0,"MZSlumfe9fPzNufojcnD1"],"name":[0,"DDoS Alerts"],"slug":[0,"ddos-alerts"]}],[0,{"id":[0,"3yArjf0gLKZy8ObEDxbNNi"],"name":[0,"Trends"],"slug":[0,"trends"]}],[0,{"id":[0,"5kZtWqjqa7aOUoZr8NFGwI"],"name":[0,"Radar"],"slug":[0,"cloudflare-radar"]}],[0,{"id":[0,"6p334JmCmVYR5iL5Mnohds"],"name":[0,"Mirai"],"slug":[0,"mirai"]}],[0,{"id":[0,"5kIxDMJCg3PXQxVINDL0Cw"],"name":[0,"Attacks"],"slug":[0,"attacks"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Omer Yoachimik"],"slug":[0,"omer"],"bio":[0,"Product Manager / Cloudflare's DDoS Protection Service"],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6TXRnB1v4ZHGiL3nRlvRTZ/e47fa218da976d21b5074229b33b9589/omer.png"],"location":[0,"London"],"website":[0,null],"twitter":[0,"@OmerYoahimik"],"facebook":[0,null]}],[0,{"name":[0,"Jorge Pacheco"],"slug":[0,"jorge"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5iFJ9jTuh48eBY1WfEmLK1/6f692ae5c2ec0e58855f8f836d0c4d3d/profile_jorge.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}]]],"meta_description":[0,"2024 ended with a bang. Cloudflare mitigated another record-breaking DDoS attack peaking at 5.6 Tbps. Overall, Cloudflare mitigated 21.3 million DDoS attacks in 2024, representing a 53% increase compared to 2023. Check out the full report."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"LOC Blog: 2024 Q4 DDoS Threat Report"],"enUS":[0,"English for Locale"],"zhCN":[0,"Translated for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"Translated for Locale"],"frFR":[0,"Translated for Locale"],"deDE":[0,"Translated for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"Translated for Locale"],"koKR":[0,"Translated for Locale"],"ptBR":[0,"Translated for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"Translated for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"Translated for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"Translated for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"Translated for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/ddos-threat-report-for-2024-q4"],"metadata":[0,{"title":[0,"Record-breaking 5.6 Tbps DDoS attack and global DDoS trends for 2024 Q4"],"description":[0,"2024 ended with a bang. Cloudflare mitigated another record-breaking DDoS attack peaking at 5.6 Tbps. Overall, Cloudflare mitigated 21.3 million DDoS attacks in 2024, representing a 53% increase compared to 2023."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3inTvvzHPFO0f3tN5IllSW/786167ceba27cb8ce48e542e24b3c972/Record-breaking_5.6_Tbps_DDoS_attack_and_global_DDoS_trends_for_2024_Q4-OG.png"]}]}]]],"locale":[0,"en-us"],"translations":[0,{"posts.by":[0,"By"],"footer.gdpr":[0,"GDPR"],"lang_blurb1":[0,"This post is also available in {lang1}."],"lang_blurb2":[0,"This post is also available in {lang1} and {lang2}."],"lang_blurb3":[0,"This post is also available in {lang1}, {lang2} and {lang3}."],"footer.press":[0,"Press"],"header.title":[0,"The Cloudflare Blog"],"search.clear":[0,"Clear"],"search.filter":[0,"Filter"],"search.source":[0,"Source"],"footer.careers":[0,"Careers"],"footer.company":[0,"Company"],"footer.support":[0,"Support"],"footer.the_net":[0,"theNet"],"search.filters":[0,"Filters"],"footer.our_team":[0,"Our team"],"footer.webinars":[0,"Webinars"],"page.more_posts":[0,"More posts"],"posts.time_read":[0,"{time} min read"],"search.language":[0,"Language"],"footer.community":[0,"Community"],"footer.resources":[0,"Resources"],"footer.solutions":[0,"Solutions"],"footer.trademark":[0,"Trademark"],"header.subscribe":[0,"Subscribe"],"footer.compliance":[0,"Compliance"],"footer.free_plans":[0,"Free plans"],"footer.impact_ESG":[0,"Impact/ESG"],"posts.follow_on_X":[0,"Follow on X"],"footer.help_center":[0,"Help center"],"footer.network_map":[0,"Network Map"],"header.please_wait":[0,"Please Wait"],"page.related_posts":[0,"Related posts"],"search.result_stat":[0,"Results {search_range} of {search_total} for {search_keyword}"],"footer.case_studies":[0,"Case Studies"],"footer.connect_2024":[0,"Connect 2024"],"footer.terms_of_use":[0,"Terms of Use"],"footer.white_papers":[0,"White Papers"],"footer.cloudflare_tv":[0,"Cloudflare TV"],"footer.community_hub":[0,"Community Hub"],"footer.compare_plans":[0,"Compare plans"],"footer.contact_sales":[0,"Contact Sales"],"header.contact_sales":[0,"Contact Sales"],"header.email_address":[0,"Email Address"],"page.error.not_found":[0,"Page not found"],"footer.developer_docs":[0,"Developer docs"],"footer.privacy_policy":[0,"Privacy Policy"],"footer.request_a_demo":[0,"Request a demo"],"page.continue_reading":[0,"Continue reading"],"footer.analysts_report":[0,"Analyst reports"],"footer.for_enterprises":[0,"For enterprises"],"footer.getting_started":[0,"Getting Started"],"footer.learning_center":[0,"Learning Center"],"footer.project_galileo":[0,"Project Galileo"],"pagination.newer_posts":[0,"Newer Posts"],"pagination.older_posts":[0,"Older Posts"],"posts.social_buttons.x":[0,"Discuss on X"],"search.icon_aria_label":[0,"Search"],"search.source_location":[0,"Source/Location"],"footer.about_cloudflare":[0,"About Cloudflare"],"footer.athenian_project":[0,"Athenian Project"],"footer.become_a_partner":[0,"Become a partner"],"footer.cloudflare_radar":[0,"Cloudflare Radar"],"footer.network_services":[0,"Network services"],"footer.trust_and_safety":[0,"Trust & Safety"],"header.get_started_free":[0,"Get Started Free"],"page.search.placeholder":[0,"Search Cloudflare"],"footer.cloudflare_status":[0,"Cloudflare Status"],"footer.cookie_preference":[0,"Cookie Preferences"],"header.valid_email_error":[0,"Must be valid email."],"search.result_stat_empty":[0,"Results {search_range} of {search_total}"],"footer.connectivity_cloud":[0,"Connectivity cloud"],"footer.developer_services":[0,"Developer services"],"footer.investor_relations":[0,"Investor relations"],"page.not_found.error_code":[0,"Error Code: 404"],"search.autocomplete_title":[0,"Insert a query. Press enter to send"],"footer.logos_and_press_kit":[0,"Logos & press kit"],"footer.application_services":[0,"Application services"],"footer.get_a_recommendation":[0,"Get a recommendation"],"posts.social_buttons.reddit":[0,"Discuss on Reddit"],"footer.sse_and_sase_services":[0,"SSE and SASE services"],"page.not_found.outdated_link":[0,"You may have used an outdated link, or you may have typed the address incorrectly."],"footer.report_security_issues":[0,"Report Security Issues"],"page.error.error_message_page":[0,"Sorry, we can't find the page you are looking for."],"header.subscribe_notifications":[0,"Subscribe to receive notifications of new posts:"],"footer.cloudflare_for_campaigns":[0,"Cloudflare for Campaigns"],"header.subscription_confimation":[0,"Subscription confirmed. Thank you for subscribing!"],"posts.social_buttons.hackernews":[0,"Discuss on Hacker News"],"footer.diversity_equity_inclusion":[0,"Diversity, equity & inclusion"],"footer.critical_infrastructure_defense_project":[0,"Critical Infrastructure Defense Project"]}],"localesAvailable":[1,[]],"footerBlurb":[0,"Cloudflare's connectivity cloud protects entire corporate networks, helps customers build Internet-scale applications efficiently, accelerates any website or Internet application, wards off DDoS attacks, keeps hackers at bay, and can help you on your journey to Zero Trust.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions."]}" ssr="" client="load" opts="{"name":"Post","value":true}" await-children="">
Earlier today, Cloudflare terminated the account of the Daily Stormer. We've stopped proxying their traffic and stopped answering DNS requests for their sites. We've taken measures to ensure that they cannot sign up for Cloudflare's services ever again.
Our terms of service reserve the right for us to terminate users of our network at our sole discretion. The tipping point for us making this decision was that the team behind Daily Stormer made the claim that we were secretly supporters of their ideology.
Our team has been thorough and have had thoughtful discussions for years about what the right policy was on censoring. Like a lot of people, we’ve felt angry at these hateful people for a long time but we have followed the law and remained content neutral as a network. We could not remain neutral after these claims of secret support by Cloudflare.
Now, having made that decision, let me explain why it's so dangerous.
Where Do You Regulate Content on the Internet?
There are a number of different organizations that work in concert to bring you the Internet. They include:
Content creators, who author the actual content online.
Platforms (e.g., Facebook, Wordpress, etc.), where the content is published.
Hosts (e.g., Amazon Web Services, Dreamhost, etc.), that provide infrastructure on which the platforms live.
Transit Providers (e.g., Level(3), NTT, etc.), that connect the hosts to the rest of the Internet.
Reverse Proxies/CDNs (e.g., Akamai, Cloudflare, etc.), that provide networks to ensure content loads fast and is protected from attack.
Authoritative DNS Providers (e.g., Dyn, Cloudflare, etc.), that resolve the domains of sites.
Registrars (e.g., GoDaddy, Tucows, etc.), that register the domains of sites.
Registries (e.g., Verisign, Afilias, etc.), that run the top level domains like .com, .org, etc.
Internet Service Providers (ISPs) (e.g., Comcast, AT&T, etc.), that connect content consumers to the Internet.
Recursive DNS Providers (e.g., OpenDNS, Google, etc.), that resolve content consumers' DNS queries.
Browsers (e.g., Firefox, Chrome, etc.), that parse and organize Internet content into a consumable form.
There are other players in the ecosystem, including:
Search engines (e.g., Google, Bing, etc.), that help you discover content.
ICANN, the organization that sets the rules for the Registrars and Registries.
RIRs (e.g., ARIN, RIPE, APNIC, etc.), which provide the IP addresses used by Internet infrastructure.
Any of the above could regulate content online. The question is: which of them should?
Vigilante Justice
The rules and responsibilities for each of the organizations above in regulating content are and should be different. We've argued that it doesn't make sense to regulate content at the proxy, where Cloudflare provides service, since if we terminate a user the content won't go away it will just be slower and more vulnerable to attack.
That's true, and made sense for a long time, but increasingly may not be relevant. The size and scale of the attacks that can now easily be launched online make it such that if you don't have a network like Cloudflare in front of your content, and you upset anyone, you will be knocked offline. In fact, in the case of the Daily Stormer, the initial requests we received to terminate their service came from hackers who literally said: "Get out of the way so we can DDoS this site off the Internet."
You, like me, may believe that the Daily Stormer's site is vile. You may believe it should be restricted. You may think the authors of the site should be prosecuted. Reasonable people can and do believe all those things. But having the mechanism of content control be vigilante hackers launching DDoS attacks subverts any rational concept of justice.
Increasing Dependence On A Few Giant Networks
In a not-so-distant future, if we're not there already, it may be that if you're going to put content on the Internet you'll need to use a company with a giant network like Cloudflare, Google, Microsoft, Facebook, Amazon, or Alibaba.
For context, Cloudflare currently handles around 10% of Internet requests.
Without a clear framework as a guide for content regulation, a small number of companies will largely determine what can and cannot be online.
Freedom of Speech < Due Process
The issue of who can and cannot be online has often been associated with Freedom of Speech. We think the more important principle is Due Process. I, personally, believe in strong Freedom of Speech protections, but I also acknowledge that it is a very American idea that is not shared globally. On the other hand, the concept of Due Process is close to universal. At its most basic, Due Process means that you should be able to know the rules a system will follow if you participate in that system.
Due Process requires that decisions be public and not arbitrary. It's why we've always said that our policy is to follow the guidance of the law in the jurisdictions in which we operate. Law enforcement, legislators, and courts have the political legitimacy and predictability to make decisions on what content should be restricted. Companies should not.
What We Would Not Do
Beginning in 2013, Cloudflare began publishing our semi-annual Transparency Report. At the time we choose to include four statements of things that we had never done. They included:
Cloudflare has never turned over our SSL keys or our customers' SSL keys to anyone.
Cloudflare has never installed any law enforcement software or equipment anywhere on our network.
Cloudflare has never terminated a customer or taken down content due to political pressure.
Cloudflare has never provided any law enforcement organization a feed of our customers' content transiting our network.
We included them as "warrant canaries" because we thought they could help us push back against the request that governments may try to force us to make. That’s worked and all four of the warrant canaries have survived in every transparency report since 2013.
We're going to have a long debate internally about whether we need to remove the bullet about not terminating a customer due to political pressure. It's powerful to be able to say you've never done something. And, after today, make no mistake, it will be a little bit harder for us to argue against a government somewhere pressuring us into taking down a site they don't like.
Establishing a Framework
Someone on our team asked after I announced we were going to terminate the Daily Stormer: "Is this the day the Internet dies?" He was half joking, but only half. He's no fan of the Daily Stormer or sites like it. But he does realize the risks of a company like Cloudflare getting into content policing.
There's a saying in legal circles that hard cases make bad law. We need to be careful of that here. What I do hope is it will allow us all to discuss what the framework for all of the organizations listed above should be when it comes to content restrictions. I don't know the right answer, but I do know that as we work it out it's critical we be clear, transparent, consistent and respectful of Due Process.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Cloudflare was recently contacted by researchers who discovered a broadcast amplification vulnerability through their QUIC Internet measurement research. We've implemented a mitigation....
Cloudflare is the first organization globally to announce having been successfully audited against the ‘Global Cross-Border Privacy Rules’ system and ‘Global Privacy Recognition for Processors’....
January 27 marks the International Holocaust Remembrance Day — a solemn occasion to honor the memory of the six million Jews who perished in the Holocaust, along with countless others who fell victim...