Tag Archives: Trends

How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack

2024-10-02 Manish Arora

Post Syndicated from Manish Arora original https://blog.cloudflare.com/how-cloudflare-auto-mitigated-world-record-3-8-tbps-ddos-attack

Since early September, Cloudflare’s DDoS protection systems have been combating a month-long campaign of hyper-volumetric L3/4 DDoS attacks. Cloudflare’s defenses mitigated over one hundred hyper-volumetric L3/4 DDoS attacks throughout the month, with many exceeding 2 billion packets per second (Bpps) and 3 terabits per second (Tbps). The largest attack peaked 3.8 Tbps — the largest ever disclosed publicly by any organization. Detection and mitigation was fully autonomous. The graphs below represent two separate attack events that targeted the same Cloudflare customer and were mitigated autonomously.

^{A mitigated 3.8 Terabits per second DDoS attack that lasted 65 seconds}

^{A mitigated 2.14 billion packet per second DDoS attack that lasted 60 seconds}

Cloudflare customers are protected

Cloudflare customers using Cloudflare’s HTTP reverse proxy services (e.g. Cloudflare WAF and Cloudflare CDN) are automatically protected.

Cloudflare customers using Spectrum and Magic Transit are also automatically protected. Magic Transit customers can further optimize their protection by deploying Magic Firewall rules to enforce a strict positive and negative security model at the packet layer.

Other Internet properties may not be safe

The scale and frequency of these attacks are unprecedented. Due to their sheer size and bits/packets per second rates, these attacks have the ability to take down unprotected Internet properties, as well as Internet properties that are protected by on-premise equipment or by cloud providers that just don’t have sufficient network capacity or global coverage to be able to handle these volumes alongside legitimate traffic without impacting performance.

Cloudflare, however, does have the network capacity, global coverage, and intelligent systems needed to absorb and automatically mitigate these monstrous attacks.

In this blog post, we will review the attack campaign and why its attacks are so severe. We will describe the anatomy of a Layer 3/4 DDoS attack, its objectives, and how attacks are generated. We will then proceed to detail how Cloudflare’s systems were able to autonomously detect and mitigate these monstrous attacks without impacting performance for our customers. We will describe the key aspects of our defenses, starting with how our systems generate real-time (dynamic) signatures to match the attack traffic all the way to how we leverage kernel features to drop packets at wire-speed.

Campaign analysis

We have observed this attack campaign targeting multiple customers in the financial services, Internet, and telecommunication industries, among others. This attack campaign targets bandwidth saturation as well as resource exhaustion of in-line applications and devices.

The attacks predominantly leverage UDP on a fixed port, and originated from across the globe with larger shares coming from Vietnam, Russia, Brazil, Spain, and the US.

The high packet rate attacks appear to originate from multiple types of compromised devices, including MikroTik devices, DVRs, and Web servers, orchestrated to work in tandem and flood the target with exceptionally large volumes of traffic. The high bitrate attacks appear to originate from a large number of compromised ASUS home routers, likely exploited using a CVE 9.8 (Critical) vulnerability that was recently discovered by Censys.

Anatomy of DDoS attacks

Before we discuss how Cloudflare automatically detected and mitigated the largest DDoS attacks ever seen, it‘s important to understand the basics of DDoS attacks.

^{Simplified diagram of a DDoS attack}

The goal of a Distributed Denial of Service (DDoS) attack is to deny legitimate users access to a service. This is usually done by exhausting resources needed to provide the service. In the context of these recent Layer 3/4 DDoS attacks, that resource is CPU cycles and network bandwidth.

Exhausting CPU cycles

Processing a packet consumes CPU cycles. In the case of regular (non-attack) traffic, a legitimate packet received by a service will cause that service to perform some action, and different actions require different amounts of CPU processing. However, before a packet is even delivered to a service there is per-packet work that needs to be done. Layer 3 packet headers need to be parsed and processed to deliver the packet to the correct machine and interface. Layer 4 packet headers need to be processed and routed to the correct socket (if any). There may be multiple additional processing steps that inspect every packet. Therefore, if an attacker sends at a high enough packet rate, then they can potentially saturate the available CPU resources, denying service to legitimate users.

To defend against high packet rate attacks, you need to be able to inspect and discard the bad packets using as few CPU cycles as possible, leaving enough CPU to process the good packets. You can additionally acquire more, or faster, CPUs to perform the processing — but that can be a very lengthy process that bears high costs.

Exhausting network bandwidth

Network bandwidth is the total amount of data per time that can be delivered to a server. You can think of bandwidth like a pipe to transport water. The amount of water we can deliver through a drinking straw is less than what we could deliver through a garden hose. If an attacker is able to push more garbage data into the pipe than it can deliver, then both the bad data and the good data will be discarded upstream, at the entrance to the pipe, and the DDoS is therefore successful.

Defending against attacks that can saturate network bandwidth can be difficult because there is very little that can be done if you are on the downstream side of the saturated pipe. There are really only a few choices: you can get a bigger pipe, you can potentially find a way to move the good traffic to a new pipe that isn’t saturated, or you can hopefully ask the upstream side of the pipe to stop sending some or all of the data into the pipe.

Generating DDoS attacks

If we think about what this means from the attackers point of view you realize there are similar constraints. Just as it takes CPU cycles to receive a packet, it also takes CPU cycles to create a packet. If, for example, the cost to send and receive a packet were equal, then the attacker would need an equal amount of CPU power to generate the attack as we would need to defend against it. In most cases this is not true — there is a cost asymmetry, as the attacker is able to generate packets using fewer CPU cycles than it takes to receive those packets. However, it is worth noting that generating attacks is not free and can require a large amount of CPU power.

Saturating network bandwidth can be even more difficult for an attacker. Here the attacker needs to be able to output more bandwidth than the target service has allocated. They actually need to be able to exceed the capacity of the receiving service. This is so difficult that the most common way to achieve a network bandwidth attack is to use a reflection/amplification attack method, for example a DNS Amplification attack. These attacks allow the attacker to send a small packet to an intermediate service, and the intermediate service will send a large packet to the victim.

In both scenarios, the attacker needs to acquire or gain access to many devices to generate the attack. These devices can be acquired in a number of different ways. They may be server class machines from cloud providers or hosting services, or they can be compromised devices like DVRs, routers, and webcams that have been infected with the attacker’s malware. These machines together form the botnet.

How Cloudflare defends against large attacks

Now that we understand the fundamentals of how DDoS attacks work, we can explain how Cloudflare can defend against these attacks.

Spreading the attack surface using global anycast

The first not-so-secret ingredient is that Cloudflare’s network is built on anycast. In brief, anycast allows a single IP address to be advertised by multiple machines around the world. A packet sent to that IP address will be served by the closest machine. This means when an attacker uses their distributed botnet to launch an attack, the attack will be received in a distributed manner across the Cloudflare network. An infected DVR in Dallas, Texas will send packets to a Cloudflare server in Dallas. An infected webcam in London will send packets to a Cloudflare server in London.

^{Anycast vs. Unicast networks}

Our anycast network additionally allows Cloudflare to allocate compute and bandwidth resources closest to the regions that need them the most. Densely populated regions will generate larger amounts of legitimate traffic, and the data centers placed in those regions will have more bandwidth and CPU resources to meet those needs. Sparsely populated regions will naturally generate less legitimate traffic, so Cloudflare data centers in those regions can be sized appropriately. Since attack traffic is mainly coming from compromised devices, those devices will tend to be distributed in a manner that matches normal traffic flows sending the attack traffic proportionally to datacenters that can handle it. And similarly, within the datacenter, traffic is distributed across multiple machines.

Additionally, for high bandwidth attacks, Cloudflare’s network has another advantage. A large proportion of traffic on the Cloudflare network does not consume bandwidth in a symmetrical manner. For example, an HTTP request to get a webpage from a site behind Cloudflare will be a relatively small incoming packet, but produce a larger amount of outgoing traffic back to the client. This means that the Cloudflare network tends to egress far more legitimate traffic than we receive. However, the network links and bandwidth allocated are symmetrical, meaning there is an abundance of ingress bandwidth available to receive volumetric attack traffic.

Generating real-time signatures

By the time you’ve reached an individual server inside a datacenter, the bandwidth of the attack has been distributed enough that none of the upstream links are saturated. That doesn’t mean the attack has been fully stopped yet, since we haven’t dropped the bad packets. To do that, we need to sample traffic, qualify an attack, and create rules to block the bad packets.

Sampling traffic and dropping bad packets is the job of our l4drop component, which uses XDP (eXpress Data Path) and leverages an extended version of the Berkeley Packet Filter known as eBPF (extended BPF). This enables us to execute custom code in kernel space and process (drop, forward, or modify) each packet directly at the network interface card (NIC) level. This component helps the system drop packets efficiently without consuming excessive CPU resources on the machine.

^{Cloudflare DDoS protection system overview}

We use XDP to sample packets to look for suspicious attributes that indicate an attack. The samples include fields such as the source IP, source port, destination IP, destination port, protocol, TCP flags, sequence number, options, packet rate and more. This analysis is conducted by the denial of service daemon (dosd). Dosd holds our secret sauce. It has many filters which instruct it, based on our curated heuristics, when to initiate mitigation. To our customers, these filters are logically grouped by attack vectors and exposed as the DDoS Managed Rules. Our customers can customize their behavior to some extent, as needed.

As it receives samples from XDP, dosd will generate multiple permutations of fingerprints for suspicious traffic patterns. Then, using a data streaming algorithm, dosd will identify the most optimal fingerprints to mitigate the attack. Once attack is qualified, dosd will push a mitigation rule inline as an eBPF program to surgically drop the attack traffic.

The detection and mitigation of attacks by dosd is done at the server level, at the data center level and at the global level — and it’s all software defined. This makes our network extremely resilient and leads to almost instant mitigation. There are no out-of-path “scrubbing centers” or “scrubbing devices”. Instead, each server runs the full stack of the Cloudflare product suite including the DDoS detection and mitigation component. And it is all done autonomously. Each server also gossips (multicasts) mitigation instructions within a data center between servers, and globally between data centers. This ensures that whether an attack is localized or globally distributed, dosd will have already installed mitigation rules inline to ensure a robust mitigation.

Strong defenses against strong attacks

Our software-defined, autonomous DDoS detection and mitigation systems run across our entire network. In this post we focused mainly on our dynamic fingerprinting capabilities, but our arsenal of defense systems is much larger. The Advanced TCP Protection system and Advanced DNS Protection system work alongside our dynamic fingerprinting to identify sophisticated and highly randomized TCP-based DDoS attacks and also leverages statistical analysis to thwart complex DNS-based DDoS attacks. Our defenses also incorporate real-time threat intelligence, traffic profiling, and machine learning classification as part of our Adaptive DDoS Protection to mitigate traffic anomalies.

Together, these systems, alongside the full breadth of the Cloudflare Security portfolio, are built atop of the Cloudflare network — one of the largest networks in the world — to ensure our customers are protected from the largest attacks in the world.

Impact of Verizon’s September 30 outage on Internet traffic

2024-10-01 David Belson

Post Syndicated from David Belson original https://blog.cloudflare.com/impact-of-verizons-september-30-outage-on-internet-traffic

On Monday, September 30, customers on Verizon’s mobile network in multiple cities across the United States reported experiencing a loss of connectivity. Impacted phones showed “SOS” instead of the usual bar-based signal strength indicator, and customers complained of an inability to make or receive calls on their mobile devices.

AS6167 (CELLCO) is the autonomous system used by Verizon for its mobile network. To better understand how the outage impacted Internet traffic on Verizon’s network, we took a look at HTTP request volume from AS6167 independent of geography, as well as traffic from AS6167 in various cities that were reported to be the most significantly impacted.

Although initial reports of connectivity problems started around 09:00 ET (13:00 UTC), we didn’t see a noticeable change in request volume at an ASN level until about two hours later. Just before 12:00 ET (16:00 UTC), Verizon published a social media post acknowledging the problem, stating “We are aware of an issue impacting service for some customers. Our engineers are engaged and we are working quickly to identify and solve the issue.”

As the Cloudflare Radar graph below shows, a slight decline (-5%) in HTTP traffic as compared to traffic at the same time a week prior is first visible around 11:00 ET (15:00 UTC). Request volume fell as much as 9% below expected levels at 13:45 ET (17:45 UTC).

Just after 17:00 ET (21:00 UTC), Verizon published a second social media post noting, in part, “Verizon engineers are making progress on our network issue and service has started to be restored.” Request volumes returned to expected levels around the same time, surpassing the previous week’s levels at 17:15 ET (21:15 UTC). At 19:18 ET (23:18 UTC), a social media post from Verizon noted “Verizon engineers have fully restored today’s network disruption that impacted some customers. Service has returned to normal levels.”

Media reports listed cities including Chicago, Indianapolis, New York City, Atlanta, Cincinnati, Omaha, Phoenix, Denver, Minneapolis, Seattle, Los Angeles, and Las Vegas as being most impacted. In addition to looking at comparative traffic trends across the whole Verizon Wireless network, we also compared request volumes in the listed cities to the same time a week prior (September 23).

Declines in request traffic starting around 11:00 ET (15:00 UTC) are clearly visible in cities including Los Angeles, Seattle, Omaha, Denver, Phoenix, Minneapolis, Indianapolis, and Chicago. In contrast to other cities, Omaha’s request volume was already trending lower than last week heading into today’s outage, but its graph clearly shows the impact of today’s disruption as well. Omaha’s difference in traffic was the most significant, down approximately 30%, while other cities saw declines in the 10-20% range.

Request traffic from Las Vegas initially appeared to exhibit a bit of volatility around 11:00 ET (15:00 UTC), but continues to track fairly closely to last week’s levels before exceeding them starting at 16:00 ET (20:00 UTC). Cincinnati was tracking slightly above last week’s request volume before the outage began, and tracked closely to the prior week during the outage period.

We observed week-over-week traffic increases during the outage period in New York and Atlanta. However, in both cities, traffic was already slightly above last week’s levels, and that trend continued throughout the day.

Based on our observations, it appears that voice services on Verizon’s network may have been more significantly impacted than data services, as we saw some declines in request traffic across impacted cities, but none experienced full outages.

As of this writing (19:15 ET, 23:15 UTC), no specific information has been made available by Verizon regarding the root cause of the network problems.

Network trends and natural language: Cloudflare Radar’s new Data Explorer & AI Assistant

2024-09-27 David Belson

Post Syndicated from David Belson original https://blog.cloudflare.com/radar-data-explorer-ai-assistant

Cloudflare Radar showcases global Internet traffic patterns, attack activity, and technology trends and insights. It is powered by data from Cloudflare’s global network, as well as aggregated and anonymized data from Cloudflare’s 1.1.1.1 public DNS Resolver, and is built on top of a rich, publicly accessible API. This API allows users to explore Radar data beyond the default set of visualizations, for example filtering by protocol, comparing metrics across multiple locations or autonomous systems, or examining trends over two different periods of time. However, not every user has the technical know-how to make a raw API query or process the JSON-formatted response.

Today, we are launching the Cloudflare Radar Data Explorer, which provides a simple Web-based interface to enable users to easily build more complex API queries, including comparisons and filters, and visualize the results. And as a complement to the Data Explorer, we are also launching an AI Assistant, which uses Cloudflare Workers AI to translate a user’s natural language statements or questions into the appropriate Radar API calls, the results of which are visualized in the Data Explorer. Below, we introduce the AI Assistant and Data Explorer, and also dig into how we used Cloudflare Developer Platform tools to build the AI Assistant.

Ask the AI Assistant

Sometimes, a user may know what they are looking for, but aren’t quite sure how to build the relevant API query by selecting from the available options and filters. (The sheer number may appear overwhelming.) In those cases, they can simply pose a question to the AI Assistant, like “Has there been an uptick in malicious email over the last week?” The AI Assistant makes a series of Workers AI and Radar API calls to retrieve the relevant data, which is visualized within seconds:

The AI Assistant pane is found on the right side of the page in desktop browsers, and appears when the user taps the “AI Assistant” button on a mobile browser. To use the AI Assistant, users just need to type their question into the “Ask me something” area at the bottom of the pane and submit it. A few sample queries are also displayed by default to provide examples of how and what to ask, and clicking on one submits it.

The submitted question is evaluated by the AI Assistant (more below on how that happens), and the resulting visualization is displayed in the Results section of the Data Explorer. In addition to the visualization of the results, the appropriate Data, Filter, and Compare options are selected in the Query section above the visualization, allowing the user to further tune or refine the results if necessary. The Keep current filters toggle within the AI Assistant pane allows users to build on the previous question. For example, with that toggle active, a user could ask “Traffic in the United States”, see the resultant graph, and then ask “Compare it with traffic in Mexico” to add Mexico’s data to the graph.

Building a query directly

For users that prefer a more hands-on approach, a wide variety of Radar datasets are available to explore, including traffic metrics, attacks, Internet quality, email security, and more. Once the user selects a dataset, the Breakdown By: dropdown is automatically populated with relevant options (if any), and Filter options are also dynamically populated. As the user selects additional options, the visualization in the Result section is automatically updated.

In addition to building the query of interest, Data Explorer also enables the user to compare the results, both against a specific date range and/or another location or autonomous system (AS). To compare results with the immediately previous period (the last seven days with the seven days before that, for instance), just toggle on the Previous period switch. Otherwise, clicking on the Date Range field brings up a calendar that enables the user to select a starting date — the corresponding date range is intelligently selected, based on the date range selected in the Filter section. To compare results across locations or ASNs, clicking on the “Location or ASN” field brings up a search box in which the user can enter a location (country/region) name, AS name, or AS number, with search results updating as the user types. Note that locations can be compared with other locations or ASes, and ASes can be compared with other ASes or locations. This enables a user, for example, to compare trends for their ISP with trends for their country.

Visualizing the results

Much of the value of Cloudflare Radar comes from its visualizations – the graphs, maps, and tables that illustrate the underlying data, and Data Explorer does not disappoint here. Depending on the dataset and filters selected, and the volume of data returned, results may be visualized in a time series graph, bar chart, treemap, or global choropleth map. The visualization type is determined automatically based on the contents of the API response. For example, the presence of countryalpha2 keys in the response means a choropleth map will be used, the presence of timestamps in the response means a line graph (“xychart”) should be shown, and more than 40 items in the response selects a treemap as the visualization type.

To illustrate the extended visualizations available in Data Explorer, the figure below is an expanded version of one that would normally be found on Radar’s Adoption & Usage page. The “standard” version of the graph plots the shares of the HTTP versions over the last seven days for the United States, as well as the summary share values. In this extended version of the graph generated in the Data Explorer, we compare data for the United States with HTTP version share data for AS701 (Verizon), for both the past seven days and the previous seven-day period. In addition to the comparisons plotted on the time series graph, the associated summary values are also compared in an accompanying bar chart. This comprehensive visualization makes comparisons easy.

For some combinations of datasets/filters/comparisons, time series graphs can get quite busy, with a significant number of lines being plotted. To isolate just a single line on the graph, double-click on the item in the legend. To add/remove additional lines back to/from the graph, single-click on the relevant legend item.

Similar to other visualizations on Radar, the resulting graphs or maps can be downloaded, copied, or embedded into another website or application. Simply click on the “Share” button above the visualization card to bring up the Share modal dialog. We hope to see these graphs shared in articles, blog posts, and presentations, and to see embedded visualizations with real-time data in your portals and operations centers!

Still want to use the API? No problem.

Although Data Explorer was designed to simplify the process of building, and viewing the results of, more complex API queries, we recognize that some users may still want to retrieve data directly from the API. To enable that, Data Explorer’s API section provides copyable API calls as a direct request URL and a cURL command. The raw data returned by the query is also available to copy or download as a JSON blob, for those users that want to save it locally, or paste it into another application for additional manipulation or analysis.

How we built the AI Assistant

Knowing all that AI is capable of these days, we thought that creating a system for an LLM to answer questions didn’t seem like an overly complex task. While there were some challenges, Cloudflare’s developer platform tools thankfully made it fairly straightforward.

LLM-assisted API querying

The main challenge we encountered in building the API Assistant was the large number of combinations of datasets and parameters that can potentially be visualized in the Data Explorer. There are around 100 API endpoints from which the data can be fetched, with most able to take multiple parameters.

There were a few potential approaches to getting started. One was to take a previously trained LLM and further train it with the API endpoint descriptions in order to have it return the output in the required structured format which would then be used to execute the API query. However, for the first version, we decided against this approach of fine-tuning, as we wanted to quickly test a few different models supported by Workers AI, and we wanted the flexibility to easily add or remove parameter combinations, as Data Explorer development was still under way. As such, we decided to start with prompt engineering, where all the endpoint-specific information is placed in the instructions sent to the LLM.

Putting the full detailed description of the API endpoints supported by the Data Explorer into the system prompt would be possible for an LLM with a larger context window (the number of tokens the model takes as input before generating output). Newer models are getting better with the needle in a haystack problem, which refers to the issue whereby LLMs do not retrieve information (the needle) equally well if it is placed in different positions within the long textual input (the haystack). However, it has been empirically shown that the position of information within the large context still matters. Additionally, many of the Radar API endpoints have quite similar descriptions, and putting all the descriptions in a single instruction could be more confusing for the model, and the processing time also increases with larger contexts. Based on this, we adopted the approach of having multiple inference calls to an LLM.

First, when the user enters a question, a Worker sends this question and a short general description of the available datasets to the LLM, asking it to determine the topic of the question. Then, based on the topic returned by the model, a system prompt is generated with the endpoint descriptions, including only those related to the topic. This prompt, along with the original question, is sent to the LLM asking it to select the appropriate endpoint and its specific parameters. At the same time, two parallel inference calls to the model are also made, one with the question and the system prompt related to the description of location parameters, and another with the description of time range parameters. Then, all three model outputs are put together and validated.

If the final output is a valid dataset and parameter combination, it is sent back to the Data Explorer, which executes the API query and displays the resulting visualization for the user. Different LLMs were tested for this task, and at the end, openhermes-2.5-mistral-7b, trained on code datasets, was selected as the best option. To give the model more context, not only is the user’s current question sent to the model, but the previous one and its response are as well, in case the next question asked by the user is related to the previous one. In addition, calls to the model are sent through Cloudflare’s AI Gateway, to allow for caching, rate limiting, and logging.

After the user is shown the result, they can indicate whether what was shown to them was useful or not by clicking the “thumbs up” or “thumbs down” icons in the response. This rating information is saved with the original question in D1, our serverless SQL database, so the results can be analyzed and applied to future AI Assistant improvements.

The full end-to-end data flow for the Cloudflare Radar AI Assistant is illustrated in the diagram below.

When the LLM doesn’t know the answer

In some cases, however, the LLM may not “know” the answer to the question posed by the user. If the model does not generate a valid final response, then the user is shown three alternative questions. The intent here is to guide the user into asking an answerable question — that is, a question that is answerable with data from Radar.

This is achieved using a previously compiled (static) list of various questions related to different Radar datasets. For each of these questions, their embedding is calculated using an embeddings model, and stored in our Vectorize vector database. “Embeddings” are numerical representations of textual data (vectors) capturing their semantic meaning and relationships, with similar text having vectors that are closer. When a user’s question does not generate a valid model response, the embedding of that question is calculated, and its vector is compared against all the stored vectors from the vector database, and the three most similar ones are selected. These three questions, determined to be similar to the user’s original question, are then shown to the user.

There are also cases when the LLM gives answers which do not correspond to what the user asked, as hallucinations are currently inevitable in LLMs, or when time durations are calculated inaccurately, as LLMs sometimes struggle with mathematical calculations. To help guard against this, AI Assistant responses are first validated against the API schema to confirm that the dataset and the parameter combination is valid. Additionally, Data Explorer dropdown options are automatically populated based on the AI Assistant’s response, and the chart titles are also automatically generated, so the user always knows exactly what data is shown in the visualization, even if it might not answer their actual question.

Looking ahead

We’re excited to enable more granular access to the rich datasets that currently power Cloudflare Radar. As we add new datasets in the future, such as DNS metrics, these will be available through Data Explorer and AI Assistant as well.

As noted above, Radar offers a predefined set of visualizations, and these serve as an excellent starting point for further exploration. We are adding links from each Radar visualization into Data Explorer, enabling users to further analyze the associated data to answer more specific questions. Clicking the “pie chart” icon next to a graph’s description brings up a Data Explorer page with the relevant metrics, options, and filters selected.

Correlating observations across two different metrics is another capability that we are also working on adding to Data Explorer. For example, if you are investigating an Internet disruption, you will be able to plot traffic trends and announced IP address space for a given country or autonomous system on the same graph to determine if both dropped concurrently.

But for now, use the Data Explorer and AI Assistant to go beyond what Cloudflare Radar offers, finding answers to your questions about what’s happening on the Internet. If you share Data Explorer visualizations on social media, be sure to tag us: @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky). You can also reach out on social media, or contact us via email, with suggestions for future Data Explorer and AI Assistant functionality.

How the Harris-Trump US presidential debate influenced Internet traffic

2024-09-11 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/how-the-harris-trump-us-presidential-debate-influenced-internet-traffic

Much has changed in the 2024 United States presidential election since the June 27 debate between Donald Trump and Joe Biden, then the presumptive nominees for the November election. Now, over two months later, on September 10, the debate was between Kamala Harris, the Democratic nominee, and Donald Trump, the Republican nominee. In this post, we will explore the event’s impact on Internet traffic in specific states where there was a bigger impact than during the Biden-Trump debate, as well as examine cyberattacks, email phishing trends, and general DNS data on candidates, news, and election-related activity.

We’ve been tracking the 2024 elections globally through our blog and election report on Cloudflare Radar, covering some of the more than 60 national elections this year. Regarding the US elections, we have previously reported on trends surrounding the first Biden vs. Trump debate, the attempted assassination of Trump, the Republican National Convention, and the Democratic National Convention.

Typically, we have observed that election days don’t come with significant changes to Internet traffic, and the same is true for debates. Yet, debates can also draw attention that impacts traffic, especially when there is heightened anticipation. The 2024 debates were not only aired on broadcast and cable television, but also streamed on platforms like YouTube, increasing their reach and impact.

Key takeaways:

The September 10 Harris-Trump debate caused bigger drops in Internet traffic in the US than the Biden-Trump debate on June 27.
There was also a noticeable increase in DNS traffic to both Kamala Harris-related and Donald Trump-related domains, with Trump-related DNS traffic peaking around the start of the debate and Harris-related DNS traffic peaking after the debate ended, around the time Taylor Swift announced she was endorsing Harris.
We also observed increases in DNS traffic to US news media outlets and election-related domains right after the debate ended.
Donald Trump remains the candidate with the most mentions in email subjects and the highest percentages of emails classified as spam (26.7%) and malicious (2.4%). Since mid-August, there has been a slight increase in the percentage of spam and malicious emails mentioning Kamala Harris.

Traffic drop in the US

During the September 10, 2024, debate between Harris and Trump, hosted by ABC News at 21:00 EST (01:00 UTC) in Philadelphia, Pennsylvania, Cloudflare noted a trend similar to the Biden-Trump debate, with a clear drop in nationwide Internet requests, falling as much as 9% below the same time a week prior at 21:15 EST (01:15 UTC). At the end of the debate, around 22:45 EST (02:45 UTC), the drop was less evident, at just 2%. Traffic increased slightly just after the debate.

_{Note: there were two four-minute breaks during the debate, at around 22:00 and 22:30, and our data here has 15-minute granularity.}

There’s a clear difference between this second debate, with a drop of up to 9%, and the first one between Biden and Trump on June 27, when the traffic dropped just 2% below the same time a week prior. Interestingly, the biggest drop occurred at the same time in both debates, right after they started, at 21:15 EST (01:15 UTC).

Internet traffic dips across US states

Traffic shifts at the time of the debate, as compared to the previous week, can reveal more detail at a state-level perspective than at the country level. The map below summarizes traffic changes observed at a state level. A key observation is that traffic declines at a state level were much more pronounced during the Harris-Trump debate, than during the Biden-Trump debate in late June.

_{(Source: Cloudflare; created with Datawrapper)}

The most significant traffic drops were observed in Vermont (-25%), Montana (-22%), and Idaho (-19%). More populous states such as California (-11%), Texas (-10%), and New York (-14%) also experienced notable declines in traffic.

Just for comparison, here’s the state map from that June 27 Biden-Trump debate:

_{(Source: Cloudflare; created with Datawrapper)}

The initial minutes of the Harris-Trump debate triggered the largest traffic declines in most states, at least up until the first break, at around 21:30 ET (01:30 UTC).

In the next table, we provide a detailed breakdown of the same perspective shown on the US map ordered by the magnitude of the drop in traffic. We include the time of the biggest traffic drop compared to the previous week, at a 5-minute granularity, and also the percentage of the drop compared to the previous week. As noted above, the largest declines appeared to occur earlier in the debate.

State	Drop in traffic (%)	Local Time	UTC
Vermont	-25%	21:05 EDT	1:05
Montana	-22%	19:10 MDT	1:10
Idaho	-19%	19:10 MDT	1:10
Wyoming	-19%	19:15 MDT	1:15
North Dakota	-18%	20:15 CDT	1:15
Delaware	-15%	21:20 EDT	1:20
Illinois	-15%	20:20 CDT	1:20
Mississippi	-14%	20:05 CDT	1:05
New York	-14%	21:05 EDT	1:05
Rhode Island	-14%	21:45 EDT	1:45
West Virginia	-14%	21:15 EDT	1:15
Alabama	-13%	20:05 CDT	1:05
Georgia	-13%	21:20 EDT	1:20
South Carolina	-13%	21:15 EDT	1:15
Virginia	-13%	21:15 EDT	1:15
Colorado	-12%	19:45 MDT	1:45
Connecticut	-12%	21:05 EDT	1:05
Nevada	-12%	18:20 PDT	1:20
New Jersey	-12%	21:20 EDT	1:20
Alaska	-11%	17:15 AKDT	1:15
California	-11%	18:15 PDT	1:15
Florida	-11%	21:05 EDT	1:05
North Carolina	-11%	21:05 EDT	1:05
Wisconsin	-11%	20:20 CDT	1:20
Arkansas	-10%	20:05 CDT	1:05
District of Columbia	-10%	21:55 EDT	1:55
Missouri	-10%	20:25 CDT	1:25
Oregon	-10%	18:40 PDT	1:40
Pennsylvania	-10%	21:05 EDT	1:05
South Dakota	-10%	20:20 CDT	1:20
Texas	-10%	20:05 CDT	1:05
Maryland	-9%	21:20 EDT	1:20
Massachusetts	-9%	21:20 EDT	1:20
New Hampshire	-9%	21:05 EDT	1:05
Oklahoma	-9%	20:05 CDT	1:05
Arizona	-8%	18:15 MST	1:15
Indiana	-8%	21:05 EDT	1:05
Iowa	-8%	20:05 CDT	1:05
Kentucky	-8%	21:05 EDT	1:05
Maine	-8%	21:15 EDT	1:15
Nebraska	-8%	19:45 MDT	1:45
Kansas	-7%	20:25 CDT	1:25
Louisiana	-7%	20:20 CDT	1:20
Michigan	-7%	21:20 EDT	1:20
Minnesota	-7%	20:30 CDT	1:30
New Mexico	-7%	19:25 MDT	1:25
Washington	-7%	18:05 PDT	1:05
Hawaii	-6%	15:20 HST	1:20
Ohio	-6%	21:15 EDT	1:15
Tennessee	-6%	20:05 CDT	1:05
Utah	-6%	19:10 MDT	1:10

Swing state drops in traffic higher than first debate

The seven swing states that are said to be decisive in the election — Arizona, Georgia, Michigan, Nevada, North Carolina, Pennsylvania, and Wisconsin — each saw traffic drop between 8% and 13%, which is more than during the Biden-Trump debate (between 5% and 8% at that time). Here’s a more focused view of those swing states for easier visualization:

State	Drop in traffic	Local Time	UTC
Arizona	-8%	18:15 MST	1:15
Georgia	-13%	21:20 EDT	1:20
Michigan	-7%	21:20 EDT	1:20
Nevada	-12%	18:20 PDT	1:20
North Carolina	-11%	21:05 EDT	1:05
Pennsylvania	-10%	21:05 EDT	1:05
Wisconsin	-11%	20:20 CDT	1:20

DNS trends

Shifting our attention to domain trends, our 1.1.1.1 resolver data highlights a more targeted impact during and around the debate. Let’s start with Kamala Harris-related insights.

Harris and the Taylor Swift effect

Since July 21, the date of Biden’s withdrawal and endorsement of Harris, daily DNS traffic to Harris-related domains has significantly increased, with notable peaks on August 30 (the day after the Harris-Walz interview on CNN) and September 10 (the debate with Trump).

From an hourly perspective, the impact of the debate on Kamala Harris-related sites is evident, with increased DNS traffic throughout the day (September 10). The peak occurred at the debate’s start (21:00 ET / 01:00 UTC) with a 54% increase from the previous week, and again after it ended (23:00 ET / 03:00 UTC) with a 56% rise. This spike coincided with Taylor Swift’s endorsement of Kamala Harris.

Trump and the Elon Musk interview effect

Donald Trump, having a longer-standing campaign and websites compared to Kamala Harris, shows different trends. Aggregated daily DNS traffic to Trump-related domains has also increased in recent months. Significant peaks were observed on July 15 (two days after the assassination attempt), then during the Republican National Convention (August 19-22), with the highest spike occurring on August 12, following Elon Musk’s interview with Trump on X.

Hourly data shows the debate’s impact on Trump-related sites with a noticeable increase around the debate’s start (21:00 ET / 01:00 UTC), where DNS traffic was 46% higher than the previous week. This elevated traffic continued for a few hours, after the debate ended.

From news to election-related sites

Like previous US election-related events, the debate generated significant interest in US news organizations, leading to a rise in aggregated DNS traffic to general US news sites. This increase peaked during the debate at 22:00 ET (02:00 UTC), with DNS traffic 62% higher than the previous week. The elevated DNS traffic began before the debate and persisted afterward, with a 19% increase at 20:00 ET (00:00 UTC) and a 25% increase at 00:00 ET (04:00 UTC).

Microblogging social platforms like X or Threads outperformed their previous week’s traffic throughout the debate, peaking at 16% growth around 22:00 ET (02:00 UTC).

Additionally, there was a notable increase in DNS traffic to election-related websites, including official voting registration and election sites. During the morning of September 10 in the US, DNS traffic was 38% higher at 10:00 ET (14:00 UTC), with a significant spike at 23:00 ET (03:00 UTC) right after the debate, where DNS traffic surged by 76% compared to the previous week.

Harris-Trump: spam and malicious emails

From a cybersecurity perspective, trending events, topics, and individuals often attract more emails, including malicious, phishing, and spam messages. Our earlier analysis covered email trends involving “Joe Biden” and “Donald Trump” since January. We’ve since updated it to include Kamala Harris after the Democratic Convention.

From June 1, 2024, through August 21, Cloudflare’s Cloud Email Security service processed over 16 million emails that included the names “Donald Trump”, “Joe Biden”, or “Kamala Harris” in the subject, with 8.7 million referencing Trump, 4.8 million referencing Biden, and 3 million referencing Harris.

The chart below highlights a surge in emails mentioning Trump in mid-July, contrasting with a drop in the number of emails mentioning Biden in the subject and an increase in emails mentioning Harris.

Since July 21, following changes in the presumptive Democratic candidate, over 4.5 million emails mentioned “Donald Trump,” over 1.5 million mentioned “Joe Biden,” and around 2.8 million mentioned “Kamala Harris” in the subject. Of these, 26.7% of emails with Trump’s name were classified as spam, and 2.4% were classified as malicious. For Kamala Harris, 1.1% were classified as spam and 0.2% were classified as malicious, while Biden’s figures were 1.1% for spam and 0.1% for malicious.

Since mid-August, there has been a slight increase in the percentage of spam and malicious emails mentioning Kamala Harris. Trump remains the candidate with the most mentions in email subjects and the highest percentages of emails classified as spam and malicious.

September attacks on political and news sites

In our blog posts about several of the 2024 elections, we have noted that attacks on politically-related websites have remained a significant threat this year. In Europe, we’ve seen political parties and associated websites targeted around elections. We previously reported on DDoS attacks around the Republican National Convention and Democratic National Convention.

In our post about the Democratic National Convention, we showed that during late July and August, Cloudflare blocked DDoS attacks targeting three US politically related organizations, including a site associated with one of the major parties, with attacks occurring just before the Democratic Convention.

The largest DDoS attack recorded in recent days against politically-related websites targeted specifically a US political-party related website on September 4, peaking at 140,000 requests per second (rps) and lasting about 5 minutes.

But it’s not only US politically-related websites that could be the target of cyber attacks. News organizations are often attacked during relevant events, as we saw during the first year of the war in Ukraine, for example. Already in September, we’ve seen an example of a relevant US news organization that covers politics being the target of a DDoS attack on September 3, peaking at 343,000 requests per second (rps) and lasting about 5 minutes.

As highlighted in our Q2 DDoS report, most DDoS attacks are short-lived, as exemplified by the two mentioned attacks. Also, 81% of HTTP DDoS attacks peak at under 50,000 requests per second (rps), and only 7% reach between 100,000 and 250,000 rps. While a 140,000 rps attack might seem minor to Cloudflare, it can be devastating for websites not equipped to handle such high levels of traffic.

Conclusion

In this analysis of the Harris-Trump debate, we’ve observed that the September 10 debate caused bigger drops in traffic in the US than the Biden-Trump debate in late June. There was also a noticeable increase in DNS traffic to both Kamala Harris-related and Donald Trump-related domains, as well as to US news media outlets and election-related domains — in this case, right after the debate ended.

If you’re interested in more trends and insights about the Internet and elections, check out Cloudflare Radar, specifically our 2024 Elections Insights report. It will be updated throughout the year as elections (or election-related events) occur.

Paris 2024 Olympics recap: Internet trends, cyber threats, and popular moments

2024-08-14 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/paris-2024-olympics-recap

The Paris 2024 Summer Olympics wrapped up on August 11, 2024, with the Olympic flag being lowered in the Stade de France after 16 days of competitions. With 329 events across 32 sports, over 10,000 athletes from 204 nations participated in the pursuit of medals and glory, creating some viral online moments along the way. In this post, we turn our attention to the closing ceremony, the impact of various Olympic moments on Internet traffic, and the cyber attacks faced by sponsors. We also examine email trends related to the Olympics, including mentions of Simone Biles, Snoop Dogg, and Imane Khelif.

Cloudflare has a global presence with data centers in over 330 cities, supporting millions of customers with different tools and products, which provides a global view of what’s happening on the Internet. This is helpful for improving security, privacy, efficiency, and speed, but also for observing Internet disruptions and traffic trends.

In our previous blog post about the opening ceremony and the early days of the event, we showed how France was impacted by the Olympics, with clear drops in traffic during the main events. The opening ceremony caused the most significant drop—traffic decreased by as much as 20% compared to the previous week. Other countries were also less online during that time, spending more time on broadcast TV.

Closing ceremony impact in France

*The moment that the Golden Voyager (a golden dancing character) descended from the sky during the closing ceremony. Captured in a* *photo* *taken by Cloudflare CEO Matthew Prince, who was in attendance.*

More than two weeks after the Summer Olympics began, the 3-hour closing ceremony on August 11, 2024, had a similar impact as the opening ceremony did on Internet traffic in France, although less pronounced. Internet traffic dropped by as much as 14% compared to the previous week at the start of the ceremony, around 19:15 UTC. Here is a breakdown of the top three traffic drops compared to the previous week during the ceremony, detailing the events occurring at those times. Our data provides insights with 15-minute granularity.

Moments of the closing ceremony by traffic drop in France

	Time of drop (UTC)	Drop %	Events at the time
#1	~19:15	-14%	Léon Marchand, France’s swimming star, carried a lantern from the Cauldron at the Jardins des Tuileries to the Stade de France. Flags of all National Olympic Committees entered the stadium, followed by the athletes.
#2	~20:15	-13%	A Golden Voyager, inspired by French history, descended from the sky, followed by Nike, the Goddess of Victory. In the stands, LED bracelets—similar to those used at Taylor Swift concerts—created images of athletes, doves of peace, and the Olympic Rings.
#3	~21:30	-10%	Californian artist H.E.R. performed the U.S. national anthem and introduced Tom Cruise, who performed Mission Impossible stunts to transport the Olympic flag from Paris to Los Angeles.

During the closing ceremony, from 19:00 to 22:00 UTC, traffic in France was significantly lower than the previous week, down between 3% – 14%. The decreases were less pronounced during the middle and end of the event. Internet requests increased during band performances and the official closing speeches. Traffic also rose during Yseult’s finale, singing a rendition of Frank Sinatra’s “My Way,” contrasting with the significant drop during Celine Dion’s performance at the end of the opening ceremony.

In exploring traffic trends for other countries, we found that the closing ceremony didn’t have as clear an impact as the opening event did.

Taking a broader look at traffic in France during the entire Olympic period, daily traffic dropped by as much as 8% on July 28 but remained fairly stable afterward, with a 3% drop on August 8.

Mobile device use rose in France

Mobile device traffic share continued to grow during the event, with more people using mobile devices to access the Internet. This trend of more mobile use in France aligns not only with more tourists and visitors in the country during the Olympics – visitors more typically use mobile devices to access the Internet – but also with French people taking vacations and working less during this time. Weekly mobile device traffic share in France in mid-June was 49%, and since the Olympics started, it has increased to between 53% and 54%.

In France, mobile device use is higher on weekends. However, looking at daily trends, mobile traffic share on weekdays was clearly higher after July 26, when the Olympics began.

Parisians left, Olympic tourists arrived

We’ve seen before that Parisians appeared to left town (and the region) just before the Olympics. In the Paris region of Île-de-France, with the Olympics, traffic during the first week of the event dropped as much as 6% on July 30, compared to the previous week. Traffic picked up a bit on the second weekend of the Olympics but dropped even more during the second and final week.

The chart below illustrates daily traffic to the Île-de-France region, with a noticeable decline visible during the weekend before the Olympics that was more pronounced during the event.

Weekly traffic dropped 8% the week the Olympics started and remained stable the following week. Even so, by August 4, the last week of the Olympics, traffic was 23% lower in the Île-de-France region than in the week of June 30, when it was at its highest in recent weeks.

Significant moments: from Simone Biles to breakdancing debut

Below, we highlight specific Olympic events affecting Internet traffic that we were able to observe in our data from different locations (ordered by the numbers of medals in the event), starting from the first full competition day on Saturday, July 27, 2024.

Host nation France was clearly the one with more significant impacts to Internet traffic during relevant moments of the Olympics.

United States: The artistic gymnastics competition featuring four-time Olympic gold medalist Simone Biles had a greater impact on U.S. Internet traffic than the opening ceremony. On July 26-28, traffic dipped most significantly during Biles’ events. On the 28th, at 10:00 UTC, during her beam routine, traffic was already 4% lower than the previous week. It dropped by 6% at 10:45 UTC during her floor and vault routines.

On July 29, at 19:30 UTC, traffic dropped 4% during the swimming event where Ryan Murphy won the bronze medal in the men’s 100 m backstroke final.

Another notable drop occurred on August 10, with a 7% decrease around 15:00 UTC during the women’s football gold medal match between Brazil and the USA. Later that day, during the men’s basketball gold medal game between France and the USA, traffic dropped by as much as 6%.

Great Britain: The first weekend of the Olympics saw clear drops in traffic, with a 10% decrease compared to the previous week around 15:00 UTC on July 28, 2024. British athletes participated in several events during those busy days. Traffic the following weekend was slightly higher than in the first Olympic weekend but dropped again on the final day, August 11.

France: As previously noted, French swimmer Léon Marchand’s gold medal and Olympic record in the men’s 400-meter individual medley on July 28 had the most significant impact on French traffic during the Olympics, aside from the 20% drop seen during the opening ceremony. Traffic fell by 17% at 18:30 UTC during his event—the same level of drop seen during the closing ceremony. Similar impacts occurred during other swimming events:

July 29, 19:45 UTC, 14% drop during the Women’s 100 m Backstroke Semifinals featuring Yohann Ndoye-Brouard.
July 30, 19:00 UTC, 12% drop during the Men’s 200 m Butterfly Semifinals with Léon Marchand.
July 31, 18:30-20:30 UTC, 7% to 10% drop during the Men’s 200 m Butterfly final with Léon Marchand.
August 1, 18:45 UTC, 8% drop during swimming semifinals and finals.

Other notable drops include breakdancing:

August 9, 14:30 UTC, 10% drop during the Breaking dance debut with France’s participation.
August 10, 18:45-21:00 UTC, 7% drop during the Breaking B-Boys gold medal battle and the men’s basketball gold medal game, France vs USA.
August 11, 07:00 UTC, 8% drop during the women’s marathon.

Australia: During Mollie O’Callaghan’s victory in the women’s 200 m freestyle on July 29, at around 20:00 UTC, Australian traffic was 5% lower than the previous week, a larger drop than during the opening ceremony, which saw a 2% decrease.

On August 1, at around 18:45 UTC, traffic was 10% lower than the previous week during swimming events that led to Australia’s gold in the women’s 4x200m freestyle relay. And on August 11, at around 07:00 UTC, traffic dropped 7% compared to the previous week during the women’s marathon with Australian participants.

Japan: One of the most significant drops in traffic in Japan during the Olympics occurred on August 6, around the time Fumita Kenichiro from Japan won gold in the men’s Greco-Roman wrestling 60 kg final, followed by artistic swimming and the women’s table tennis competition, with traffic dropping 12% at 18:15 UTC.

On August 10, for several hours after 17:30 UTC, traffic in Japan was also lower than usual, with a drop of as much as 14%. This coincided with Japan’s gold medal win in the women’s javelin throw and the men’s breaking quarterfinals and semifinals.

Italy: During the event that gave Italy its first ever gold medal in artistic gymnastics, won by Alice D’Amato in the women’s balance beam event, traffic dropped 5% at around 10:45 UTC.

Netherlands: On the morning of July 28, the second full day of the Olympics, traffic in the Netherlands dropped by as much as 20% compared to the previous week, with Dutch athletes participating in several competitions.

On August 11, traffic dropped between 06:30 and 09:30 UTC, and by as much as 16% at 08:15 UTC, when Dutch runner Sifan Hassan won the gold medal in the women’s marathon.

South Korea: The Korean women’s archery team’s gold medal win on July 28 at 15:30 UTC led to an 8% drop in traffic, the most significant decrease noted in the country between July 26 and July 29.

On August 7, at 19:45 UTC, traffic was 9% lower during the Taekwondo gold medal event for Park Taejoon in the men’s -58 kg (under 58 kg) competition.

Brazil: Traffic in Brazil was 15% lower than the previous week on July 27 at around 19:30 UTC, surpassing the impact of the opening ceremony. This occurred as Brazilian swimmers Guilherme Costa and Maria Fernanda Costa competed in the men’s and women’s 400 m freestyle events.

On August 2, traffic in Brazil was 5% lower at around 00:30 UTC during the men’s surfing quarterfinals with Gabriel Medina and was 8% lower at around 01:00 UTC during the women’s surfing quarterfinals with Tatiana Weston-Webb.

Cape Verde: David Pina won the first Olympic medal in boxing for this archipelago nation off the western coast of Africa. On August 4, the amateur boxer took the bronze medal, with traffic dropping 12% in the country at around 15:00 UTC during the match.

DNS trends for official Olympic websites by country

On July 22, before the Olympics began, we reported on the heightened interest in official Olympic websites based on request data from our 1.1.1.1 DNS resolver. France initially dominated with 24% of DNS traffic, followed by the UK (20%) and the US (17%). However, when the Olympics started, the US took the lead, maintaining it throughout the event.

The following chart summarizes the highest shares of DNS request traffic by country during the Paris 2024 Summer Olympics. There was a shift in percentages that indicates a broader spread of interest across countries as the Olympics progressed, visible in the dynamic version of the map by day of the event that is available in our Paris 2024 Olympics report.

Here are the top 10 countries that during the event had more DNS traffic for Olympics official websites. The US took the “gold,” France the “silver,” and the UK the “bronze”:

United States: 18%
France: 16%
United Kingdom: 10%
Germany: 7%
Brazil: 6%
Australia: 5%
Canada: 2%
Japan: 2%
India: 2%
Russian Federation: 2%

We observed that the US overtook France for the #1 spot a few days before the event began. France also dropped to third place behind Germany on July 27, the first full day of competitions, and again after August 2, though interestingly, it returned to #2 the day after the Olympics ended.

As shown in the following daily ranking chart, the UK was #3 before the event began but dropped to #4 on August 1. Australia’s highest ranking was #3 on July 29, and #4 on August 10 and 11. Brazil’s best days, ranking #3, were on July 24-25, and on July 30, 31, and August 1.

In terms of volume of DNS traffic to our 1.1.1.1 resolver, the first full week of Olympic events saw the highest volume of requests related to official Olympic websites, with a 637% increase compared to the week before the Olympics began. This trend of peak traffic during the first week was consistent across most countries, except for Germany, Spain, India, Italy, and Russia, where the final week generated more DNS resolver traffic.

On a daily basis, worldwide DNS traffic to official Olympics domains peaked on August 2, followed by August 4 and August 5, marking the start of the second and final week of the event. Below are the top 3 days with the highest DNS traffic to official Olympic websites in the top 3 countries by traffic volume:

United States: July 30 (when the US women’s team won gold in artistic gymnastics and several medals were won in swimming), July 29, and August 5.
France: July 31 (when swimmer Léon Marchand won gold in the men’s 200 m butterfly final), July 29, and August 1.
Germany: July 27 (when swimmer Lukas Maertens won gold in the men’s 400 m freestyle final), August 8, and August 7.

Sports news sites

Looking at DNS traffic for sports news sites across different countries, the two weeks of the Olympics brought more traffic than any other week since June, including during the major football event, UEFA Euro 2024, held between June 14 and July 14. The Olympic weeks saw 17% more traffic than the week before the Olympics and 4% more DNS traffic than the best week of Euro 2024 (June 22-29).

From a daily perspective, the days with the highest traffic to sports news sites were August 10, August 3, July 28, and July 14 (related to the Euro 2024 final).

In the United States, NBC was not only the official broadcaster of the Olympics, but also created a dedicated website. NBC’s sports and NBC Olympics websites saw a significant rise in global DNS traffic, increasing up to 1,640% on July 28 compared to the previous week.

From official streaming services to Olympic sponsors

While the Olympics were still broadcast on several traditional national TV networks, streaming also played a key role, with Peacock TV (in the US and Canada) and Max (from Warner Bros. Discovery) in Europe offering several hours of Olympic content daily. The global traffic growth to these platforms was evident. On a weekly basis, DNS request traffic for streaming platforms featuring Olympic events grew by as much as 65%. Daily traffic peaked on July 30 (68% higher than the previous week), followed by July 29 and August 4. Peacock TV led over Max in terms of traffic.

Breakdancing, or “breaking,” made its first appearance in the 2024 Summer Olympics, leading to a surge in DNS traffic to breaking-related websites, particularly on August 9 and 10. Traffic peaked on August 9, with a 215% increase compared to the previous week, driven by viral moments like Australian Rachael Gunn’s performance.

How about the Paris Olympics sponsors? DNS traffic also increased, particularly in the early days of the event and the days leading up to it, with peak traffic on July 29 (15% higher than the previous week), followed by July 25 and 24 (the two days before the opening ceremony). Samsung saw the most significant impact during the early days of the Olympics, while Airbnb experienced a surge in traffic just before the opening ceremony (July 25).

Next stop: LA 2028

The closing ceremony concluded with a symbolic passing of the torch from Paris 2024 to Los Angeles 2028. Simone Biles handed the Olympic flag to Tom Cruise, who transported it Mission Impossible-style from Paris to a Venice Beach concert in LA featuring acts including the Red Hot Chili Peppers and Billie Eilish. Unsurprisingly, the official LA 2028 Olympics website saw a 1600% surge in DNS traffic on August 11 compared to the previous week.

DDoS attacks targeting Olympic-related and sponsor websites

As we observed during the 2024 elections, including the French elections, political parties are not the only targets of DDoS (Distributed Denial of Service) attacks during significant events. Attackers are aware of large global events. In a previous related blog post, we discussed attacks targeting French transportation and government websites. Below, let’s focus on Olympic-related and sponsor organizations.

In July, Cloudflare blocked a surge in DDoS attacks on Olympic partner websites – higher than in any other month of 2024. Daily DDoS attack requests jumped to 200 million, and in just 11 days of August, more DDoS requests (90 million) were blocked than in any full month in 2024 before the Olympics.

The largest spike in attacks occurred on July 29, targeting three sponsor websites simultaneously, with 84 million DDoS-related requests in a single day. The most intense DDoS attack peaked at 190,000 requests per second at 10:20 UTC.

The most significant specific attack was on the last day of the event, August 11, targeting a French transportation site. It lasted four minutes and peaked at over 500,000 requests per second at 05:09 UTC.

As highlighted in our Q2 DDoS report, most DDoS attacks are short-lived, as seen in the two mentioned attacks. While a 500,000 request per second (rps) attack is not large for Cloudflare, it can be devastating for websites not equipped to handle such traffic levels.

Analyzing the same pool of Olympic partner websites that use Cloudflare, total requests (including legitimate traffic and attacks) rose in July, reaching 4.2 billion—27% more than in May and 11% more than in June.

Rise in “Olympics” and “Paris 2024” emails

Major events often attract attention in the email realm, including spam and malicious emails, and the Olympics were no exception. From January 2024 through August 11, Cloudflare’s Cloud Email Security service processed over 1.7 million emails containing “Olympics” or “Paris 2024” in the subject. More than half of these emails (890,000) were sent during the Olympics (July 26 to August 11), with the highest volume (150,000 messages) on July 26, the day of the opening ceremony.

The week of July 22-28, coinciding with the first few days of the Olympics, saw a 304% increase in such emails compared to the previous week, and an astonishing 3111% increase compared to the busiest week in January.

Although the Olympics period (July 26 – August 11) was busy in terms of related emails, the percentages of spam and malicious messages were lower than before. However, over 6,200 emails were classified as spam (0.7%), and just 248 were identified as malicious or phishing (0.07%).

As noted in a previous blog post, since January 1, 2024, spam accounted for 1.3% of all emails with “Olympics” or “Paris 2024” in the subject, while malicious emails made up 0.1%. In a sample of 1,000 emails, roughly 13 would be spam and 1 would be malicious. The peak for malicious Olympic-related emails occurred during the week of May 6, with 0.6% classified as malicious. Although there was a decline after this peak, rates increased slightly in July, reaching 0.4% on July 8. Despite the surge in volume during the week of July 22, only 0.05% of emails were malicious.

Simone Biles and Snoop Dogg popular via email

Famous individuals are often used by attackers for email phishing. Among the athletes shining at the event, Simone Biles generated the most emails, but very few of them were spam or malicious. Biles led other popular names during the event, including those named below, ordered by number of email messages: Katie Ledecky (US), Imane Khelif (Algeria), Novak Djokovic (Serbia), Steph Curry (US), and Léon Marchand (France).

Since July 1, over 160,000 emails processed by Cloudflare’s Cloud Email Security service have included “Simone Biles” or “Biles” in the subject, with only 0.5% considered spam and 0.01% classified as malicious. (And 97% of those 160,000 emails were sent since the Olympics started on July 26.) The most emails were sent on August 5, followed by August 2 and July 28. Spam percentage peaked on July 24, with 5% of all emails considered spam.

Among famous attendees, Snoop Dogg topped the list ahead of other US team supporters like Martha Stewart, Flava Flav, and Jason Kelce. Since July, there have been over 6,600 emails with “Snoop Dogg” in the subject, with 40 classified as spam (0.6%) and 4 as malicious (0.06%).

Conclusion: from Paris to Los Angeles

The Paris 2024 Summer Olympics not only captivated millions worldwide with thrilling sports competitions, but also had a significant impact on global Internet traffic. Our data shows noticeable drops in Internet activity during key Olympic events, particularly in France, as viewers shifted from online activities to watching the games live. This trend underscores the enduring power of broadcast media during major global events, even in an increasingly digital age.

Additionally, the increase in DNS traffic for official Olympic websites and the surge in DNS traffic for streaming platforms covering the event indicates strong interest in online coverage, especially among certain audiences, complementing traditional TV viewership broadcast by national networks worldwide.

Finally, the heightened cybersecurity threats, including DDoS attacks on sponsor sites and the rise in Olympic-related emails (including spam and malicious ones), emphasize both the marketing impact of this global event and its vulnerabilities.

And after the Paris 2024 Summer Olympics, the 2024 Summer Paralympics are just around the corner (August 28-September 8), and in four years, it will be time for LA 2028.

As we’ve observed throughout the Paris 2024 Olympics, the Olympic spirit continues to capture interest and remains relevant across different media. This spirit, present for 2,800 years since Ancient Greece (dating back to 776 BC), still attracts and inspires humanity.

(Jorge Pacheco from the Cloudflare Radar team contributed to this blog post)

Introducing HTTP request traffic insights on Cloudflare Radar

2024-08-13 David Belson

Post Syndicated from David Belson original https://blog.cloudflare.com/http-requests-on-cloudflare-radar

Historically, traffic graphs on Cloudflare Radar have displayed two metrics: total traffic and HTTP traffic. These graphs show normalized traffic volumes measured in bytes, derived from aggregated NetFlow data. (NetFlow is a protocol used to collect metadata about IP traffic flows traversing network devices.) Today, we’re adding another metric that reflects the number of HTTP requests, normalized over the same time period. By comparing bytes with requests, readers can gain additional insights into traffic patterns and user behavior. Below, we review how this new data has been incorporated into Radar, and explore HTTP request traffic in more detail.

Note that while we refer to “HTTP request traffic” in this post and on Radar, the term encompasses requests made in the clear over HTTP and over encrypted connections using HTTPS – the latter accounts for ~95% of all requests to Cloudflare during July 2024.

New and updated graphs

Graphs including HTTP request-based traffic data have been added to the Overview and Traffic sections on Cloudflare Radar. On the Overview page, the “Traffic trends” graph now includes a drop-down selector at the upper right, where you can choose between “Total & HTTP bytes” and “HTTP requests & bytes”. We explore the distinction between these further in the following sections.

The default “Total & HTTP bytes” selection displays a time series graph, showing total bytes and HTTP bytes traffic over time, as Radar has done for several years now.

Selecting “HTTP requests & bytes” from the dropdown switches the view to a time series graph that HTTP requests traffic and HTTP bytes traffic over time. In both graphs, users can click on a metric in the legend to deselect it and remove it from the graph. These (de)selections are maintained when a user chooses to download or save a graph.

In addition, we’ve added a “Protocols” summary next to the graph that shows the share of bytes over the selected time period that HTTP accounts for, and the remaining aggregate share associated with the protocols used by other non-HTTP Cloudflare services (such as DNS, WARP, etc.). For most locations or ASNs, HTTP traffic will comprise the majority share of bytes-based traffic.

On Radar’s Traffic page, we have added the HTTP requests metric to the “Traffic volume” graph at the top of the page, allowing you to see how request volume has changed during the selected time period as compared to the previous period, in addition to the changes in the bytes-based metrics.

A new standalone request-based “HTTP traffic” graph was also added to the Traffic page, just below the bytes-based “Traffic trends” graph. This new graph shows normalized HTTP request traffic volume across the selected time period, and by default, also compares it with the previous time period.

Similar to other Radar graphs, these new HTTP request-based graphs can also be downloaded, copied to the clipboard, or embedded in other websites – just click on the share icon.

As always, the underlying data is also available through the Radar API. The “HTTP requests Time Series” API endpoint returns normalized HTTP request time series data across the specified time period for the requested location or autonomous system (ASN).

What is HTTP request traffic?

An HTTP GET request is a message sent from a client (such as your web browser) to a web server (such as one operated by Cloudflare), asking for a particular resource (file). In addition to returning the requested resource, which could range from a single-pixel GIF accounting for just a few bytes, to an API call that returns a few kilobytes of data, to a multi-gigabyte software package, the Web server also returns a set of headers, which can include information about the content type, the last time the resource was modified, cookie information, cacheability, and more. While GET requests account for the overwhelming majority of HTTP request traffic, such traffic also includes other HTTP request methods including HEAD, POST, PUT, and more.

Cloudflare temporarily logs HTTP requests received by our network, including associated header information and “metadata” about the request, such as the bot score computed for the request and the associated cache status. Request logs for a customer’s web properties are available for them to download, and after processing and analysis, this data is also presented in the Analytics section of the Cloudflare dashboard. The HTTP request data now available on Radar is based on a sample of this log data, aggregated across Cloudflare’s global customer base.

The value of request-based traffic insights

Cloudflare Radar already has HTTP data, so why add more? One key reason for analyzing and including HTTP request traffic is resilience. Having multiple sources of truth with respect to HTTP traffic allows us to better and more quickly distinguish between real events (such as an Internet disruption in a given country or network) and data pipeline issues.

While bytes-based metrics provide a reasonable proxy into human (user) behavior, especially with respect to activity surrounding Internet disruptions, request-based metrics provide an even better perspective. A lot of HTTP traffic involves relatively small responses – especially API traffic, which now accounts for 60% of all traffic. Furthermore, response sizes can vary widely, ranging from a single-pixel GIF accounting for just a few bytes, to an API call that returns a few kilobytes of data, to a multi-gigabyte software package

To that end, the scope of user activity may be insufficiently reflected by a bytes-based metric, or buried in the noise, whereas request activity provides a cleaner signal and a more direct proxy for user activity. This is especially important as we examine the restoration of connectivity after an Internet disruption, attempting to ascertain when activity has returned to “expected” pre-disruption levels.

Finally, incorporating request-based traffic insights into Radar is simply extending the way that the data is already being used on the site. All the graphs, maps, and tables presented on Radar’s Adoption & Usage page, are based on analysis of HTTP request traffic, making use of information contained within request headers (such as HTTP version or user agent) or characteristics of the underlying connection (such as IP version).

Bytes vs requests – what’s the difference?

The current “HTTP traffic” view aggregates the bytes associated with HTTP requests to Cloudflare’s content delivery (CDN) services from the selected location or autonomous system (ASN). “Total traffic” aggregates this HTTP traffic along with the traffic associated with other Cloudflare services, including our 1.1.1.1 DNS resolver, authoritative DNS, WARP, and Spectrum, among others. (While Spectrum, WARP, and 1.1.1.1 also carry HTTP traffic, the share of HTTP traffic carried by these services is opaque to Radar, and isn’t accounted for as part of the HTTP traffic calculations.)

The bytes associated with a given request include the size of the request, the size of the headers associated with the response, and the size of the response itself. As noted above, the size of a file returned in response to a request can vary widely, depending on what was requested. The shape of the HTTP requests and HTTP bytes lines may be quite similar, but the potential variability in response sizes (in aggregate) can cause the lines to diverge, sometimes significantly so. For example, if an application regularly makes background requests to check for updates, the availability and subsequent download of a large file containing a software update would cause a spike in the HTTP bytes line, while the HTTP requests pattern remained consistent.

As another example, consider the graph below, capturing HTTP requests and bytes traffic trends for Portugal during the first week of August. HTTP bytes traffic initially grows each day between 06:00 and 09:00 UTC (07:00 – 10:00 local summer time), increases much more slowly until around 19:00 UTC (20:00 local summer time), and then increases rapidly before peaking around 21:00 UTC (22:00 local time). This suggests that content consumed during the workday is lighter in terms of bytes (such as API traffic, as discussed above), while evening traffic is more byte-heavy (possibly due to increased consumption of media content). In contrast, after starting to increase around 06:00 UTC (07:00 local summer time), request traffic generally sees three successively higher peaks each day – occurring around 10:00, 14:00, and 21:00 UTC respectively (11:00, 15:00, and 22:00 local summer time). These peaks are most pronounced on weekdays, but are still apparent on weekend days as well, suggesting regular patterns of user activity at those times.

It is important to remember that in looking at the “HTTP requests & bytes” graphs on Radar that they are showing two different metrics, and as such, only their shape over time is comparable, not their relative sizes. (As both metrics are normalized on a 0 to 1 (Max) scale, the lines on the graph are scaled relative to the maximum normalized value of each metric, including the previous period.)

Conclusion

The addition of HTTP request metrics to Cloudflare Radar brings additional visibility to traffic trends at a global, location, and network level, complementing the existing bytes-based HTTP traffic metrics. Derived from traffic to customer web properties, these new metrics can be found on Radar’s Overview and Traffic pages.
In addition to HTTP traffic trends, visit Cloudflare Radar for additional insights around Internet disruptions, routing issues, attacks, domain popularity, and Internet quality. Follow us on social media at @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky), or contact us via email.

How the Paris 2024 Summer Olympics has impacted Internet traffic

2024-07-30 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/paris-2024-summer-olympics-impacted-internet-traffic

The Paris 2024 Summer Olympics, themed “Games Wide Open” (“Ouvrons grand les Jeux”), kicked off on Friday, July 26, 2024, and will run until August 11. A total of 10,714 athletes from 204 nations, including individual and refugee teams, will compete in 329 events across 32 sports. This blog post focuses on the opening ceremony and the initial days of the event, examining associated impact on Internet traffic, especially in France, the popularity of Olympic websites by country, and the rise in Olympics-related spam and malicious emails.

Cloudflare has a global presence with data centers in over 320 cities, supporting millions of customers, which provides a global view of what’s happening on the Internet. This is helpful for improving security, privacy, efficiency, and speed, but also for observing Internet disruptions and traffic trends.

We are closely monitoring the event through our 2024 Olympics report on Cloudflare Radar and will provide updates on significant Internet trends as they develop.

An opening ceremony to remember

For the first time in modern Olympic history, the opening ceremony was held outside a stadium, lasting nearly four hours and clearly impacting Internet traffic in France. The nation’s engagement was evident during the TV broadcast, leading to noticeable traffic drops similar to those observed during Euro 2024 – we’ve seen that national TV broadcast events usually come with drops in Internet traffic.

The Olympics are more than just sporting events – they are filled with inspiring moments and stories that capture global attention in real time, and create stories that live on. Significant traffic dips during the ceremony coincided with performances by Celine Dion and Lady Gaga, the lighting of the Olympic cauldron, and John Lennon’s “Imagine” performed by Juliette Armanet. Here is a breakdown of the top five traffic drops compared to the previous week that occurred during the ceremony, detailing the events occurring at those times. Our data provides insights with 15-minute granularity.

Moments of the ceremony by traffic drop

	Time of drop (UTC)	Drop %	Events at the time
#1	~21:15	-20%	The Olympic cauldron is lit and floats into the Paris sky via air balloon; Celine Dion serenades Paris from the Eiffel Tower.
#2	~17:45	-17%	Lady Gaga sings the French classic “Mon truc en plumes” by Zizi Jeanmaire.
#3	~19:45	-16.9%	Team USA boat takes to the river, followed by Team France – the last boat en route to the Eiffel Tower.
#4	~20:15	-16.9%	Dionysus performs the song “Naked” (Philippe Katerine); John Lennon’s “Imagine” is sung from the middle of the Seine by Juliette Armanet; a metal horse rides down the river.
#5	~18:00	-16.7%	As the boats continue along the Seine, around 80 artists from the Moulin Rouge perform the famous French cabaret dance, the can-can.

During the opening ceremony on July 26, between 17:30 to 21:20 UTC, traffic in France was noticeably lower than the previous week, with losses between 15% and 20%. However, there were moments with smaller drops. For example, at 19:30 UTC, traffic only fell by 4% during the middle of the boat parade of athletes on the Seine River. Right after the event, at 21:45 UTC, traffic increased by as much as 8% compared to the previous week.

The opening ceremony also resulted in a higher mobile share of traffic than usual in France. At 20:45 UTC, close to the end of the ceremony, the mobile share of Internet traffic was 61%, up from 57% the previous week.

Parisians leaving town before the Olympics

With the Olympics in Paris, many locals left the city, either for vacations or quieter places, while tourists arrived for the games. Our data shows that two French regions, Île-de-France, where Paris is located, and Grand Est, east of Paris, experienced the most significant traffic drops. The chart below illustrates daily traffic to these regions, with a noticeable decline visible during the weekend before the Olympics in Île-de-France.

Analyzing the percentage change in request traffic from the previous week, Île-de-France saw its largest drops in the first week of July (July 1-7), with a 15% decrease, and the week before the Olympics started, with an 8% decrease. Interestingly, there was no percentage change in traffic during the week of the Olympics (July 22-28) – that was also the week when most visitors for the Olympics started to arrive.

The daily share of mobile device traffic from France also reveals shifts in typical patterns, with increases noted especially after the June 30 weekend, indicative of vacation periods and leisure Internet use. Mobile device traffic peaked during the first Olympic weekend, reaching 53% on July 26, the day of the opening ceremony – higher than any previous Friday since June. On Sunday, July 28, mobile device traffic peaked at 58%, the highest since June.

Impact to Internet traffic outside of France

Globally, Internet traffic variations were less pronounced than in France. However, on July 26, the day of the opening ceremony, a noticeable global drop occurred during the event. This was particularly evident during two key moments previously highlighted: during song performances at 20:15 UTC, traffic dropped 3% compared to the previous week, and around the end of the ceremony, at 21:15 UTC, it dropped 2%.

Expanding our view to other countries, moments of significant drops in traffic during the opening ceremony were clearly visible. Below is a summary list of 30 countries selected based on their tally of Summer Olympic medals.

Country	Drop in traffic (%)	Time of drop (UTC)
United States	-4%	20:15
Great Britain	-8%	20:15
France	-20%	21:15
Germany	-4%	20:15
China	-4%	21:00
Italy	-11%	18:15
Australia	-2%	20:00
Hungary	-5%	21:15
Sweden	-4%	21:15
Japan	-12%	21:15
Russia	-7%	19:45
Canada	-3%	20:15
Netherlands	-6%	21:15
Romania	-12%	20:00
Finland	-12%	17:30
Poland	-5%	21:15
South Korea	-4%	20:15
Cuba	-3%	19:00
Bulgaria	-6%	21:15
Switzerland	-10%	18:15
Denmark	-2%	21:15
Spain	-8%	18:15
Norway	-2%	21:15
Belgium	-5%	21:15
Brazil	-3%	18:15
Czech Republic	-10%	18:00
Slovakia	-11%	20:15
Ukraine	-2%	20:45
New Zealand	-9%	21:15
Greece	-11%	18:00

Additionally, the world map below highlights the countries that experienced notable Internet traffic impacts during the opening ceremony.

(Source: Cloudflare; created with Datawrapper)

Outside Europe, the countries with the most substantial drops were New Zealand (-9%), Uzbekistan (-12%), Argentina (-13%), and Mongolia -(20%), all experiencing greater declines than those in Europe.

Significant moments at the games: from Simone Biles to Olympic records

Below, we highlight specific Olympic events affecting Internet traffic, starting from the first full competition day on Saturday, July 27, 2024.

United States: The artistic gymnastics competition featuring four-time Olympic gold medalist Simone Biles notably impacted US Internet traffic more than the opening ceremony. On July 26-28, traffic dipped most significantly during Biles’ events. At 10:00 UTC, concurrent with her beam routine, traffic was already 4% lower than the previous week. It dropped by 6% at 10:45 UTC during her floor and vault routines.

France: French swimmer Léon Marchand’s gold medal and Olympic record-setting performance in the men’s 400-meter individual medley on July 28 had the most significant impact in the host nation. Traffic fell by 17% at 18:30 UTC during his event. However, as we noted above, the opening ceremony drove a bigger drop in traffic.

Australia: During Mollie O’Callaghan’s victory in the women’s 200m freestyle on July 29, at around 20:00 UTC, Australian traffic was 5% lower than the previous week This was larger than during the opening ceremony, which saw a 2% drop.

South Korea: The Korean women’s archery team’s gold medal win on July 28 at 15:30 UTC led to an 8% drop in traffic, the most significant decrease noted in the country from July 26 to July 29.

Brazil: Traffic in Brazil was15% lower than the previous week on July 27 at around 19:30 UTC, surpassing the opening ceremony’s impact. This occurred as Brazilian swimmers Guilherme Costa and Maria Fernanda Costa competed in the men’s and women’s 400 m freestyle events.

DNS trends to official Olympic websites by country

On July 22, before the Olympics started, we reported on the heightened interest in official Olympic websites based on request data from our 1.1.1.1 DNS resolver. We noted France’s dominance with 24% of DNS traffic to official Olympic websites, followed by the UK (20%) and the US (17%). However, the start of the Olympics marked a shift, with the US taking the lead.

On the first full day of competitions, July 27, the US led with 16% of all DNS request traffic to official Olympic sites. This change indicates a broader spread of interest across countries during the Olympics. A dynamic version of the map below is available in our Paris 2024 Olympics report.

Here are the top 10 countries with the highest shares of DNS request traffic for the first full day of competitions, July 27, to Olympic sites (percentages rounded):

United States: 16%
Germany: 12%
France: 9%
Vietnam: 9%
Brazil: 5%
Australia: 5%
United Kingdom: 4%
Netherlands: 4%
Canada: 3%
South Africa: 2%

Growth in interest as the Olympics drew closer

Global daily DNS request traffic to official Olympic websites began climbing to the highest levels seen year to date starting on July 23, showing a steady increase. It peaked on July 28, the second full day of events, with a fivefold (509%) increase from the previous week. On the opening ceremony day, traffic was already 110% higher than the previous week.

Country-specific peaks included the US, where traffic to Olympic sites surged 719% on July 28, coinciding with Simone Biles’ first competition day. In France, traffic peaked on the same day with a 391% increase, and in Germany, it skyrocketed by 2300% on July 27.

The evolving DNS ranking of Olympic site traffic by country reveals that from July 19, the US overtook France. Also, Germany ascended to the #2 spot on July 27, the first full day of competitions, while Australia climbed to #4 on July 28, and Canada’s peak day was also July 28.

Railway attacks on opening ceremony day cause surge in traffic

The opening ceremony day, July 26, was also disrupted by railway arson attacks in France, affecting the 800,000 passengers on the high-speed railway system. At 10:00 UTC, there was a significant surge in DNS traffic to public transportation websites, including high-speed railway services. Traffic spiked by 2000% compared to the previous week as users accessed websites to check updates.

DDoS attacks: always around

As we’ve observed with elections in 2024, including the French elections, political parties are not the only targets of DDoS (Distributed Denial of Service) attacks during significant events. While we haven’t seen any coordinated flow of major DDoS attacks targeting services potentially used during the Olympics in France, we have observed a few incidents.

A generally used French government website was targeted by a DDoS attack on July 29, 2024, lasting nine minutes and peaked at 207,000 requests per second at 20:34 UTC.

Before the Olympics began, a national transportation website was also targeted by a smaller DDoS attack, lasting only a couple of minutes and peaking at 10,000 requests per second on July 21 at 10:20 UTC.

As highlighted in our Q2 DDoS report, most DDoS attacks are short-lived, as exemplified by the two mentioned attacks. Also, 81% of HTTP DDoS attacks peak at under 50,000 requests per second (rps), and only 7% reach between 100,000 and 250,000 rps. While a 10,000 rps attack might seem minor to Cloudflare, it can be devastating for websites not equipped to handle such high levels of traffic.

“Olympics” and “Paris 2024” emails on the rise

From another cybersecurity perspective, major events often attract phishing and spam, and the Olympics are no exception. From January 2024 through late July, Cloudflare’s Cloud Email Security service processed over a million emails containing “Olympics” or “Paris 2024” in the subject. During the week of July 22-28, coinciding with the first few days of the Olympics, there was a 304% increase in such emails compared to the previous week and a staggering 3111% increase compared to the busiest week in January.

Regarding unwanted messages, spam accounted for 1.5% of all emails with “Olympics” or “Paris 2024” in the subject, while malicious emails made up 0.1% since January 2024. This means that in a sample of 1000 emails, roughly 15 would be spam and 1 would be malicious. The peak for malicious Olympic-related emails occurred the week of May 6, with 0.6% classified as malicious. Although there was a decline after this peak, rates increased slightly in July, reaching 0.4% on July 8. Despite the surge in volume during the week of July 22, only 0.05% of emails were malicious.

That same week, when the Olympics started, also saw an increase in spam emails to over 2%, the highest since the 7% peak the week of June 24.

Conclusion

The Paris 2024 Olympics started on July 26, with a clear impact on Internet traffic in different countries, most notably in France, the host nation. The significant traffic drops during key moments of the opening ceremony, and the reactive spikes following major events highlight the ever-present interplay between physical events and the way humans interact with the online world. Not many events take the focus away from the Internet, and in this case, into TV broadcast.

We’ve also observed how the interest in official Olympic websites surged, with clear increases in DNS traffic after the event started, in different countries, with the US ultimately taking the gold.

Regarding the July 29, 2024 sabotage of French fiber optic cables, we did not observe any notable disruptions of Internet traffic in France or its cities during the day.

As the games continue, we will maintain a Paris 2024 Olympics report on Cloudflare Radar, updating it as significant Internet trends related to the event emerge.

Countdown to Paris 2024 Olympics: France leads in web interest

2024-07-22 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/countdown-to-paris-2024-france-leads-in-olympic-web-interest

The 2024 Summer Olympics, or Paris 2024, is set from July 26 to August 11 in France. The opening ceremony, scheduled for Friday, July 26 at 17:30, will take place for the first time not in a stadium but in the open space of the Jardins du Trocadéro by the Seine River in Paris. We’ll monitor relevant Internet insights throughout the event, but here we analyze some pre-event trends, from the popularity of Olympic websites by country to the increase in Olympics-related spam and malicious emails.

This year’s Olympics will host 329 events across 32 sports, featuring the debut of breakdancing as an Olympic event and the return of skateboarding, sport climbing, and surfing from 2020. Similar to our 2024 elections coverage, we will maintain a Paris 2024 Olympics report on Cloudflare Radar, updating it as significant Internet trends related to the event emerge.

From our 1.1.1.1 resolver, DNS trends show heightened interest in the Olympics, especially from France. 24% of DNS requests for official Olympic-related websites came from the host country, followed by the United Kingdom and the United States, with 20% and 17% respectively.

Here’s the breakdown of countries responsible for at least 1% of 1.1.1.1. traffic for Olympic sites (percentages rounded):

France: 24%
United Kingdom: 20%
United States: 17%
Brazil: 5%
Germany: 4%
Russia: 3%
Australia: 2%
Japan: 2%
India: 2%
Spain: 1%
Ireland: 1%
Canada: 1%
South Africa: 1%
Netherlands: 1%
Italy: 1%

Days with the highest “Olympic” spikes

Analyzing the evolution of DNS traffic to official Olympic websites since January 2024, we’ve noted multiple spikes associated with specific Olympic events or ticket sales. The following ranking offers a global perspective via our 1.1.1.1 resolver, illustrating that as the event draws near and Paris readies itself, more recent dates are emerging prominently in the data.

Top 5 days with higher DNS traffic to Olympic official sites in 2024:

January 31: Eve of the 2024 Winter Youth Olympics closing ceremony in Gangwon, South Korea.
April 17: Over 250,000 new tickets for Olympic Games Paris 2024 went on sale – one of the last opportunities to get tickets to the main events.
January 19: Opening ceremony of the 2024 Winter Youth Olympics (South Korea).
June 26: One month before the opening ceremony; the Paris 2024 Main Operations Center starts full games operation; in Paris, areas like the Champ-de-Mars became full occupied by the Olympics; in the US, tickets for NBC’s Opening Ceremony coverage for the Paris 2024 in IMAX theaters went on sale.
July 1: Preparations in Paris with street and bridges closures and road signs added indicating fast track routes for Olympic related vehicles.

April 10 spikes in Germany, Russia and the US

On April 10, 2024, DNS traffic spikes were observed not just in France but also notably in Germany, Russia, and the US, among others. Despite France leading in overall DNS traffic to Olympic sites since January, as seen on the world map above, this particular day saw the largest spikes originating from other countries. These spikes were most prominent from Germany, Russia, the US, the UK, France, Brazil, and Australia, in that order.

What caused these spikes? Several press conferences related to the Olympics took place that day. One major announcement, covered globally, declared that for the first time, the Olympics would offer prize money, with track and field gold medalists receiving $50,000. The following chart illustrates the spike in DNS traffic in these countries on that day.

France’s trends: interest in tickets comes first

In France, the host nation, ticket sale days significantly influenced DNS traffic to official Olympic websites. The most obvious spike occurred on February 8, 2024, marking the start of the first phase of ticket sales for 2024, called the “Paris 2024 official ticketing website surprise releases.” On that day, daily DNS traffic was double that of the previous week. A significant surge was also observed at 10:00 local time, coinciding with the ticket release, which saw an hourly DNS traffic increase of 398% compared to the previous week.

The week of March 3, 2024, saw the highest DNS traffic to Olympic-related sites in France so far. The most significant increase occurred on March 4, the day the “Athletics Special” ticket sales began for events at the Stade de France, which also coincided with the unveiling of the Olympic poster. On this day, daily DNS traffic rose by 45% compared to the previous week. Other notable periods included the weeks of May 12 and May 19, when the Olympic torch arrived in France and started its journey through various cities. April 14 also marked a critical day, offering one of the last chances to purchase 250,000 tickets for major events.

“Olympics” and “Paris 2024” emails on the rise

From a cybersecurity perspective, as major events often attract phishing and spam, we’ve analyzed email trends related to the Olympics—recently we did the same for the Biden vs Trump US presidential debate. From January 2024 up to late-July, Cloudflare’s Cloud Email Security service processed well over half a million emails containing “Olympics” or “Paris 2024” in the subject. The week of July 15 saw the highest number of such emails, marking a 694% increase compared to the busiest week in January.

Regarding unwanted messages, spam accounted for 1.5% of all emails with “Olympics” or “Paris 2024” in the subject, while malicious emails made up 0.2%. This means that in a sample of 1000 emails, roughly 15 would be spam and about 2 would be malicious. The week with the highest percentage of malicious Olympic-related emails was May 6, with 0.6% classified as malicious. Declining after that peak, it ticked back up in July, to 0.4% on July 8.

Furthermore, the week of June 24 witnessed the highest proportion of spam emails for the year so far, at 7% of all emails.

As the Olympics opening ceremony approaches, we expect the volume of related emails, and the proportion of malicious and spam emails, to increase. We’ll provide an update of the first days of the Olympics next week.

Conclusion: “Citius, Altius, Fortius” *

As the world turns its eyes to Paris for the 2024 Summer Olympics, our latest analysis provides a snapshot of the enthusiasm surrounding the games, with France, the host nation, clearly leading in terms of DNS traffic to official Olympic websites, followed by the UK, the US, and Australia.

With the games about to start, the best is yet to come, with the Olympics bringing over three hundred events in 32 sports to people all around the world.

As previously mentioned, we will maintain a Paris 2024 Olympics report on Cloudflare Radar, updating it as significant Internet trends related to the event emerge.

Let the games begin.

(Jorge Pacheco contributed to this blog post)

* “Citius, Altius, Fortius”—Latin for “Faster, Higher, Stronger.” This motto was proposed by Pierre de Coubertin, a French historian and the “father” of the modern Olympic Games, upon the creation of the International Olympic Committee in 1894.

Euro 2024’s impact on Internet traffic: a closer look at finalists Spain and England

2024-07-11 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/euro-2024s-impact-on-internet-traffic-a-closer-look-at-finalists-spain-and-england

National team sports unite countries, and football (known as “soccer” in the US) is the world’s most popular sport, boasting approximately 3.5 billion fans globally. The UEFA Euro 2024, running from June 14 to July 14, 2024, significantly impacts Internet traffic across participating European nations. This blog post focuses on the two finalists, Spain and England, and comes after an initial post we published during the first week of the tournament.

Analyzing traffic patterns reveals distinct high-level trends. Spain saw the most significant drops in Internet traffic during games against major teams and former champions such as Italy (the defending champion), Germany, and France. In contrast, England’s games had crucial moments towards the end, leading to the largest traffic reductions in the UK, especially during the knockout stages.

For context, as previously mentioned, football games like the Super Bowl, differ from other events such as elections. When major teams or national squads play, especially in matches that captivate many viewers, Internet traffic often drops. This is particularly true if the game is broadcast on a national TV channel. During such broadcasts, people tend to focus more on their TV sets, relying on the traditional broadcast signal rather than online streaming, especially for games that aren’t behind a paywall. This is a typical scenario when national teams play in Europe.

Semifinals: differences between four countries

Let’s first analyze the impact of the semifinals on the four countries with national teams playing, using UK-related data for England. The following table displays the traffic drop percentages and the times of the largest declines during the Spain vs. France and Netherlands vs. England matches. Note that England is the only one not on Central European Time.

In both Spain and the UK, traffic decreased the most at the end of the game, details of which are provided below. In France and the Netherlands, significant drops of 16% and 27% respectively occurred primarily in the first half.

Country	Drop on traffic	Date / time of biggest drop (local time)
Spain	-19%	Jul 9, 22:45
France	-16%	Jul 9, 21:00
Netherlands	-27%	Jul 10, 21:15
England (UK)	-11%	July 10, 21:45

(Source: Cloudflare; created with Datawrapper)

Traffic in the UK: England’s late goal impact

England’s matches frequently saw crucial moments near the end, leading to the largest dips in UK Internet traffic. This trend was especially pronounced during the knockout phases and after Scotland’s exit from the tournament. England’s tournament opener, a win against Serbia on June 16, experienced the most significant traffic drop at the game’s start – an 8% decrease from the previous week.

UK election debate vs England’s game

The second game, on June 20, against Denmark, ended in a draw and saw a bigger drop in traffic. During the game, traffic in the UK initially dropped 8% compared to the previous week, then fell even further in the second half, by as much as 13%. Following the game, the BBC broadcast a significant live event – the debate between the country’s four major political parties. It started at 20:00 local time, and 15 minutes later, traffic experienced its largest drop of the day: 15%.

The third and final group stage game for England, a draw against Slovenia, saw a 5% drop in Internet traffic during the second half and a 4% drop in the first half. In the round of 16 game against Slovakia on June 30, traffic dipped 9% in the UK towards the end of the second half as Jude Bellingham scored a crucial late goal. During extra time, when Harry Kane scored, traffic decreased further to 10% below the previous week’s level.

Next, during the July 6 quarter-final against Switzerland, traffic in the UK dipped 3% during the game, mostly towards the end of regular time. However, it decreased further by 11% towards the end of extra time and during the penalty shootouts.

The semi-final between England and the Netherlands on July 10, 2024, experienced a noticeable drop in UK traffic – 5% at 20:15, when the first two goals were scored. Traffic decreased further, to 11% below the previous week, at the end of the game as Ollie Watkins scored the winning goal, securing England’s spot in the final.

Spain’s big game traffic impact

Spain was the only team to win all its matches without going to penalties throughout the tournament. The most significant drops in Internet traffic occurred during games against other major teams and previous titleholders like Italy, Germany, and France.

Spain’s first game in the tournament against Croatia on June 15, during dinner time in the country, ended in a decisive 3-0 win. It was accompanied by a significant drop in traffic – 7% in the first half and 9% in the second.

The June 20 match against Italy, featuring two teams with rich histories of European and World titles – and Italy as the defending champion – captured significant attention. Also broadcast on national TV, as the other games were, it led to substantial drops in traffic: a 16% decrease early in the first half, and a 15% drop in the second half, right after halftime, aligning with Calafiori’s goal that secured Spain’s win.

The final group stage game for Spain against Albania on June 24, which was non-decisive with Spain’s advancement already secured, saw a traffic decrease of 6%. Then came the knockout phase. It began with a round of 16 match against Georgia on June 30, where traffic fell by up to 8%, with a more pronounced drop in the first half coinciding with Spain equalizing the game.

The July 5 quarterfinals against host Germany was also a game that matched two football giants, in terms of national team international football titles. The game began with an initial 10% decline in traffic, followed by a 7% drop in the second half, and an 8% drop at the end of extra time, around the time Merino scored the winning goal.

Spain’s semi-final on July 9 saw early goals and a swift turnaround after France’s initial goal. The game started with a 17% drop in traffic compared to the previous week, persisting through the first half. By the end of the second half, as France aggressively sought to score and Spain defended vigorously to avoid extra time, traffic dipped further to a 19% drop. Ultimately, the Spanish squad secured a spot in the final.

Conclusion

The UEFA Euro 2024 has significantly impacted Internet traffic across participating European countries from Cloudflare’s perspective. Games broadcast on national TV drew fans’ attention away from the Internet. Critical moments such as last-minute goals, extra time, or penalty shootouts also led to larger drops in traffic as fans focused more on the game.

Also, distinct patterns have emerged in the finalist countries, Spain and England. For Spain, matches against traditional football powerhouses resulted in noticeable drops in traffic, indicating high viewer engagement during key matches. England’s games also saw significant traffic reductions at critical moments, particularly during the knockout stages.

For more trends and insights about the Internet and major events like the Olympics and the 2024 elections (including a regularly updated report), check out Cloudflare Radar for the latest updates.

DDoS threat report for 2024 Q2

2024-07-09 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-threat-report-for-2024-q2

Welcome to the 18th edition of the Cloudflare DDoS Threat Report. Released quarterly, these reports provide an in-depth analysis of the DDoS threat landscape as observed across the Cloudflare network. This edition focuses on the second quarter of 2024.

With a 280 terabit per second network located across over 230 cities worldwide, serving 19% of all websites, Cloudflare holds a unique vantage point that enables us to provide valuable insights and trends to the broader Internet community.

Key insights for 2024 Q2

Cloudflare recorded a 20% year-over-year increase in DDoS attacks.
1 out of every 25 survey respondents said that DDoS attacks against them were carried out by state-level or state-sponsored threat actors.
Threat actor capabilities reached an all-time high as our automated defenses generated 10 times more fingerprints to counter and mitigate the ultrasophisticated DDoS attacks.

Quick recap – what is a DDoS attack?

Before diving in deeper, let’s recap what a DDoS attack is. Short for Distributed Denial of Service, a DDoS attack is a type of cyber attack designed to take down or disrupt Internet services, such as websites or mobile apps, making them unavailable to users. This is typically achieved by overwhelming the victim’s server with more traffic than it can handle — usually from multiple sources across the Internet, rendering it unable to handle legitimate user traffic.

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.

To learn about our report preparation, refer to our Methodologies.

Threat actor sophistication fuels the continued increase in DDoS attacks

In the first half of 2024, we mitigated 8.5 million DDoS attacks: 4.5 million in Q1 and 4 million in Q2. Overall, the number of DDoS attacks in Q2 decreased by 11% quarter-over-quarter, but increased 20% year-over-year.

Distribution of DDoS attacks by types and vectors

For context, in the entire year of 2023, we mitigated 14 million DDoS attacks, and halfway through 2024, we have already mitigated 60% of last year’s figure.

Cloudflare successfully mitigated 10.2 trillion HTTP DDoS requests and 57 petabytes of network-layer DDoS attack traffic, preventing it from reaching our customers’ origin servers.

When we break it down further, those 4 million DDoS attacks were composed of 2.2 million network-layer DDoS attacks and 1.8 million HTTP DDoS attacks. This number of 1.8 million HTTP DDoS attacks has been normalized to compensate for the explosion in sophisticated and randomized HTTP DDoS attacks. Our automated mitigation systems generate real-time fingerprints for DDoS attacks, and due to the randomized nature of these sophisticated attacks, we observed many fingerprints being generated for single attacks. The actual number of fingerprints that was generated was closer to 19 million – over ten times larger than the normalized figure of 1.8 million. The millions of fingerprints that were generated to deal with the randomization stemmed from a few single rules. These rules did their job to stop attacks, but they inflated the numbers, so we excluded them from the calculation.

HTTP DDoS attacks by quarter, with the excluded fingerprints

This ten-fold difference underscores the dramatic change in the threat landscape. The tools and capabilities that allowed threat actors to carry out such randomized and sophisticated attacks were previously associated with capabilities reserved for state-level actors or state-sponsored actors. But, coinciding with the rise of generative AI and autopilot systems that can help actors write better code faster, these capabilities have made their way to the common cyber criminal.

Ransom DDoS attacks

In May 2024, the percentage of attacked Cloudflare customers that reported being threatened by a DDoS attack threat actor, or subjected to a Ransom DDoS attack reached 16% – the highest it’s been in the past 12 months. The quarter started relatively low, at 7% of customers reporting a threat or a ransom attack. That quickly jumped to 16% in May and slightly dipped in June to 14%.

Percentage of customers reporting DDoS threats or ransom extortion (by month)

Overall, ransom DDoS attacks have been increasing quarter over quarter throughout the past year. In Q2 2024, the percentage of customers that reported being threatened or extorted was 12.3%, slightly higher than the previous quarter (10.2%) but similar to the percentage of the year before (also 12.0%).

Percentage of customers reporting DDoS threats or ransom extortion (by quarter)

Threat actors

75% of respondents reported that they did not know who attacked them or why. These respondents are Cloudflare customers that were targeted by HTTP DDoS attacks.

Of the respondents that claim they did know, 59% said it was a competitor who attacked them. Another 21% said the DDoS attack was carried out by a disgruntled customer or user, and another 17% said that the attacks were carried out by state-level or state-sponsored threat actors. The remaining 3% reported it being a self-inflicted DDoS attack.

Percentage of threat actor type reported by Cloudflare customers, excluding unknown attackers and outliers

Top attacked countries and regions

In the second quarter of 2024, China was ranked the most attacked country in the world. This ranking takes into consideration HTTP DDoS attacks, network-layer DDoS attacks, the total volume and the percentage of DDoS attack traffic out of the total traffic, and the graphs show this overall DDoS attack activity per country or region. A longer bar in the chart means more attack activity.

After China, Turkey came in second place, followed by Singapore, Hong Kong, Russia, Brazil, and Thailand. The remaining countries and regions comprising the top 15 most attacked countries are provided in the chart below.

15 most attacked countries and regions in 2024 Q2

Most attacked industries

The Information Technology & Services was ranked as the most targeted industry in the second quarter of 2024. The ranking methodologies that we’ve used here follow the same principles as previously described to distill the total volume and relative attack traffic for both HTTP and network-layer DDoS attacks into one single DDoS attack activity ranking.

The Telecommunications, Services Providers and Carrier sector came in second. Consumer Goods came in third place.

When analyzing only the HTTP DDoS attacks, we see a different picture. Gaming and Gambling saw the most attacks in terms of HTTP DDoS attack request volume. The per-region breakdown is provided below.

Top attacked industries by region (HTTP DDoS attacks)

Largest sources of DDoS attacks

Libya was ranked as the largest source of DDoS attacks in the second quarter of 2024. The ranking methodologies that we’ve used here follow the same principles as previously described to distill the total volume and relative attack traffic for both HTTP and network-layer DDoS attacks into one single DDoS attack activity ranking.

Indonesia followed closely in second place, followed by the Netherlands in third.

15 largest sources of DDoS attacks in 2024 Q2

DDoS attack characteristics

Network-layer DDoS attack vectors

Despite a 49% decrease quarter-over-quarter, DNS-based DDoS attacks remain the most common attack vector, with a combined share of 37% for DNS floods and DNS amplification attacks. SYN floods came in second place with a share of 23%, followed by RST floods accounting for a little over 10%. SYN floods and RST floods are both types of TCP-based DDoS attacks. Collectively, all types of TCP-based DDoS attacks accounted for 38% of all network-layer DDoS attacks.

HTTP DDoS attack vectors

One of the advantages of operating a large network is that we see a lot of traffic and attacks. This helps us improve our detection and mitigation systems to protect our customers. In the last quarter, half of all HTTP DDoS attacks were mitigated using proprietary heuristics that targeted botnets known to Cloudflare. These heuristics guide our systems on how to generate a real-time fingerprint to match against the attacks.

Another 29% were HTTP DDoS attacks that used fake user agents, impersonated browsers, or were from headless browsers. An additional 13% had suspicious HTTP attributes which triggered our automated system, and 7% were marked as generic floods. One thing to note is that 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 initial attempt to categorize the HTTP DDoS attacks.

HTTP versions used in DDoS attacks

In Q2, around half of all web traffic used HTTP/2, 29% used HTTP/1.1, an additional fifth used HTTP/3, nearly 0.62% used HTTP/1.0, and 0.01% for HTTP/1.2.

Distribution of web traffic by HTTP version

HTTP DDoS attacks follow a similar pattern in terms of version adoption, albeit a larger bias towards HTTP/2. 76% of HTTP DDoS attack traffic was over the HTTP/2 version and nearly 22% over HTTP/1.1. HTTP/3, on the other hand, saw a much smaller usage. Only 0.86% of HTTP DDoS attack traffic were over HTTP/3 — as opposed to its much broader adoption of 20% by all web traffic.

Distribution of HTTP DDoS attack traffic by HTTP version

DDoS attack duration

The vast majority of DDoS attacks are short. Over 57% of HTTP DDoS attacks and 88% of network-layer DDoS attacks end within 10 minutes or less. This emphasizes the need for automated, in-line detection and mitigation systems. Ten minutes are hardly enough time for a human to respond to an alert, analyze the traffic, and apply manual mitigations.

On the other side of the graphs, we can see that approximately a quarter of HTTP DDoS attacks last over an hour, and almost a fifth last more than a day. On the network layer, longer attacks are significantly less common. Only 1% of network-layer DDoS attacks last more than 3 hours.

HTTP DDoS attacks: distribution by duration

Network-layer DDoS attacks: distribution by duration

DDoS attack size

Most DDoS attacks are relatively small. Over 95% of network-layer DDoS attacks stay below 500 megabits per second, and 86% stay below 50,000 packets per second.

Distribution of network-layer DDoS attacks by bit rate

Distribution of network-layer DDoS attacks by packet rate

Similarly, 81% of HTTP DDoS attacks stay below 50,000 requests per second. Although these rates are small on Cloudflare’s scale, they can still be devastating for unprotected websites unaccustomed to such traffic levels.

Distribution of HTTP DDoS attacks by request rate

Despite the majority of attacks being small, the number of larger volumetric attacks has increased. One out of every 100 network-layer DDoS attacks exceed 1 million packets per second (pps), and two out of every 100 exceed 500 gigabits per second. On layer 7, four out of every 1,000 HTTP DDoS attacks exceed 1 million requests per second.

Key takeaways

The majority of DDoS attacks are small and quick. However, even these attacks can disrupt online services that do not follow best practices for DDoS defense.

Furthermore, threat actor sophistication is increasing, perhaps due to the availability of Generative AI and developer copilot tools, resulting in attack code that delivers DDoS attacks that are harder to defend against. Even prior to the rise in attack sophistication, many organizations struggled to defend against these threats on their own. But they don’t need to. Cloudflare is here to help. We invest significant resources – so you don’t have to – to ensure our automated defenses, along with the entire portfolio of Cloudflare security products, to protect against existing and emerging threats.

French elections: political cyber attacks and Internet traffic shifts

2024-07-08 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/2024-french-elections-political-cyber-attacks-and-internet-traffic-shifts

The 2024 French legislative election runoff on July 7 yielded surprising results compared to the first round on June 30, with the New Popular Front (NPF) gaining the most seats, followed by French President Macron’s Ensemble party, and the National Rally. Coalition negotiations will follow. In this post, we examine the ongoing online attacks against French political parties and how initial election predictions at 20:00 local time led to a noticeable drop in France’s Internet traffic.

This blog post is part of a series tracking the numerous elections of 2024. We have covered elections in South Africa, India, Iceland, Mexico, the European Union, the UK and also the 2024 US presidential debate. We also continuously update our election report on Cloudflare Radar.

Let’s start with the attacks, and then move on to the Internet traffic trends.

Political parties under attack

As we highlighted last week, the first round of the French elections saw specific DDoS (Distributed Denial of Service) attacks targeting French political party websites. While online attacks are common and not always election-related, recent activities in France, the Netherlands, and the UK confirm that DDoS attacks frequently target political parties during election periods.

Two French political parties were attacked shortly before the first round of elections, and a third party was targeted on June 30. This third party, indicated in green on the chart below, faced attacks on the evening of June 29. Several attempts were thwarted by Cloudflare throughout election day, from 10:00 to 23:00 UTC (12:00 to 01:00 local time). The most intense attack occurred at 19:00 UTC (21:00 local time), reaching nearly 40,000 requests per second, with a total of 620 million DDoS requests recorded on that day (June 29).

Our data indicates that the most significant attack Cloudflare intercepted targeted a party shown in yellow on the chart above. The party had already been attacked on June 23, 2024, and this subsequent attack happened on July 3 at 21:36 UTC (23:36 local time), lasting four minutes and peaking at 151,000 requests per second (rps), making it the second-largest attack we’ve observed on political parties recently. This was comparable in intensity and duration to another attack on a UK political party right after their election.

On the runoff election day, July 7, the party represented by the blue line was again a target, having been attacked previously on June 24, 27, and 29. The most severe of these occurred on June 27, with attacks reaching 118,000 rps during a day that totaled 610 million daily DDoS requests. On July 7, the attacks resumed, with the first starting at 09:55 UTC (11:55 local time) and continuing sporadically until 23:18 UTC (01:18 local time on July 8). The peak of these attacks came at 11:40 UTC (13:40 local time), reaching 96,000 rps.

While these rates may seem small to Cloudflare, they can be devastating for websites not well-protected against such high levels of traffic. DDoS attacks not only overwhelm systems but also serve, if successful, as a distraction for IT teams while attackers attempt other types of breaches.

Exit polls came with a 20:00 Internet traffic dip

Each election brings its own unique circumstances. For instance, the UK’s snap election took place on Thursday, July 4, 2024, aligning with Britain’s tradition of weekday elections. In contrast, France and many other countries hold elections on weekends, typically Sundays.

During the first round of the French elections on June 30, morning traffic was lower than the previous week and rose in the afternoon. The runoff, a week later, displayed a different pattern. Morning traffic remained stable compared to June 30, but it saw a significant decrease in the afternoon, especially after 17:30 local time. Polling stations in major cities closed at 20:00. At this time, TV media began broadcasting the first results, causing a 16% drop in traffic compared to the previous week. This trend, where traffic dips as initial results are announced, is also seen in other elections, like the UK’s.

Traffic shifts during voting day, compared to the previous week, are more revealing when viewed in detail. The map and table below summarize the traffic changes observed at the state level within France, when voting closed and initial results predictions were revealed on TV at around 20:00 local time. This was the moment when, from Cloudflare’s data perspective, attention was diverted from online use.

The table below shows the drops in traffic on July 7, at 20:00 local time, compared to the previous week.

State	Drop in traffic (%)
Bourgogne-Franche-Comté	-19%
Grand Est	-19%
Brittany	-15%
Auvergne-Rhône-Alpes	-15%
Corsica	-14%
Occitanie	-11%
Nouvelle-Aquitaine	-11%
Normandy	-10%
Île-de-France	-10%
Hauts-de-France	-9%
Pays de la Loire	-8%
Provence-Alpes-Côte d’Azur	-7%
Centre-Val de Loire	-6%

On election day in France, Internet traffic decreased most significantly in the regions of Bourgogne-Franche-Comté and Grand Est, both in the eastern part of the country and both experiencing a 19% drop. When comparing these regions to the Île-de-France region, where Paris is located, we see a smaller traffic decrease, at 10%. In the south, in regions like Provence-Alpes-Côte d’Azur, the drop was even less pronounced, at 7%.

Mobile device usage

Also notable was the increase in mobile device request traffic share during both election days, driving the share to levels higher than usual. Over the past month, mobile device traffic share on Sundays typically ranged from 53% to 54%. However, it rose to 57% on the first election day, June 30, and increased further to 58% on the runoff day, July 7, 2024. Mobile device traffic share was especially elevated from 11:00 to 22:00 local time on these days.

DNS trends: news outlets bring results

Switching focus to domain trends, our 1.1.1.1 resolver DNS data reveals a targeted impact from the French elections, allowing for a comparison between the two election days. Analyzing French news media outlets, DNS traffic in France was significantly higher on the first election day, June 30, with a 250% increase at 20:00 local time compared to the previous week. This was 6% higher than on the runoff day, July 7.

For French TV domains, the situation reversed during the runoff on July 7, showing 31% more DNS traffic at 20:00 local time than in the first round. On June 30, DNS traffic at that time was already 274% higher than the previous week, but the increase on July 7 was even more significant, at 391% compared to June 23, 2024—the Sunday before the two election days.

For microblogging social media in France, traffic was higher during the two election days, peaking on the first round. At the close of voting polls at 20:00 local time on June 30, traffic surged 38% compared to June 23, 2024. On July 7, runoff day, traffic increased by 32% at 20:00 local time compared to June 23, but was 4% lower than on June 30.

Conclusion: keeping track of elections

In France, more attention was diverted from the Internet during the decisive runoff election day than in the first round, with a noticeable dip in traffic when TV stations announced predicted results at 20:00 local time.

If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.

Since last week, we’ve updated our trends to include last-minute voting during the elections in Iran on June 28, 2024, and the suspension of mobile Internet in Mauritania following protests after the presidential elections on June 29, 2024, and the UK election.

UK election day 2024: traffic trends and attacks on political parties

2024-07-05 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/uk-election-day-2024-traffic-trends-and-attacks-on-political-parties

The 2024 UK general election, the first since Brexit officially began (January 31, 2020) and after 14 years of Conservative leadership, saw the Labour Party secure a majority. This blog post examines Internet traffic trends and cyberattack activity on election day, highlighting notable declines in traffic during the afternoon and evening as well as a DDoS attack on a political party shortly after polls closed.

For context, 2024 is considered “the year of elections,” with elections taking place in over 60 countries. We’ve covered elections in South Africa, India, Iceland, Mexico, the European Union, France, and also the 2024 US presidential debate. We also continuously update our election report on Cloudflare Radar.

The UK’s snap election on Thursday, July 4, 2024, typical of British Thursday weekday elections, contrasts with weekend elections in other countries. Polling stations were open from 07:00 to 22:00.

Generally, election days do not result in drastic changes to Internet traffic. Traffic typically dips during voting hours but not as sharply as during major events like national holidays, and rises in the evening as results are announced.

On July 4, 2024, traffic initially rose slightly from the previous week, then fell around noon (-2%). Significant declines began only after 16:00, with noticeable drops at 16:45 and again at 22:00 as polls closed.

Internet traffic dips across UK countries

Traffic shifts during voting day, compared to the previous week, are more revealing when viewed in detail. The map and table below summarize the traffic changes observed at the country level within the UK, where the greatest impact was observed in Northern Ireland (-10%), followed by Scotland (-6%), Wales (-5%), and England (-3%), all after 16:00.

Country	Drop in traffic (%)	Time of drop in traffic (local)
Northern Ireland	-10%	July 4, 16:00
Scotland	-6%	July 4, 20:00
Wales	-5%	July 4, 17:00
England	-3%	July 4, 16:00

Next, examining the day’s traffic changes, we observed a clear drop in Northern Ireland around 13:00 local time and during off-work hours between 16:00 and 20:00, before it began to increase again.

In Scotland, traffic fell by about 5% from 16:00 to 21:00 local time compared to the previous week.

In Wales, decreases occurred at 07:00 (4% drop), between 16:00 and 18:00 (around 5% drop), and at 21:00.

And in England, traffic decreased by approximately 3% between 16:00 and 18:00 and about 2% between 20:00 and 22:00.

In all the countries within the UK, traffic clearly increased after 23:00 local time when the voting polls had already closed and the first results started to arrive. Peak increases were reached at different times: Wales saw a 3% increase at 01:00; Northern Ireland and England experienced their highest increases of 12% and 11% respectively at 02:00; and Scotland had a 9% increase at 02:00 followed by a 12% spike at 04:00.

DNS trends: news outlets bring results

Switching focus to domain trends, our 1.1.1.1 resolver DNS data reveals a more targeted impact from the UK elections. Analyzing the participating parties, DNS traffic significantly increased on election day, peaking at 22:00 and midnight local time (up to 600% growth), and then again at 04:00 (671%).

Among the main parties, Labour, led by Keir Starmer, outperformed the Conservative Party on election day. Labour’s DNS traffic spiked at 22:00 local time, with an 866% increase from the previous week.

Analyzing official government and election-related websites, the UK differs from other countries in how results are shared. Official results weren’t continuously updated as they came in. The largest spike in DNS traffic, a 172% increase from the previous week, occurred on election morning around 07:00 local time. This increase likely happened because UK citizens were searching for the correct polling stations and other voting resources.

News sites and microblogging social media platforms in the UK experienced significant increases in usage after the polling stations closed at 22:00 local time. In the UK, news sites not only provide initial projections but also final results. DNS traffic for UK news media outlets surged 74% compared to the previous week, peaking at 104% at midnight and 04:00.

For microblogging social media in Great Britain, traffic was already 25% higher than the previous week when the polls closed (22:00), peaking at 27% at midnight and remaining elevated through the night.

We saw last week in the US, during the Biden vs Trump debate, that video streaming social platforms such as YouTube or TikTok, were used to watch through news outlets channels the debate live, with DNS traffic surging. How about the UK? DNS traffic was 10% higher than in the previous week starting at midnight, and at 01:00 local time was 15% higher.

Attacks: political parties included impact

Focusing on attacks, those are usually constant, and aren’t necessarily driven always by elections. But, as we’ve seen at the start of the war in Ukraine or more recently in the Netherlands or in France, specific events do trigger attacks. DDoS (Distributed Denial of Service) attacks remain a common method employed by attackers.

In recent days, there has been DDoS activity targeting political parties in the UK that participated in these elections. Our data shows that two parties experienced attacks that were blocked by Cloudflare. One party, represented in blue, suffered an attack on June 16, which lasted over four hours and peaked at 60,000 requests per second (rps).

The party shown in yellow was hit by four DDoS attacks on different days: June 13, 19, 26, and in the early hours of July 5 (UTC), just after the election’s first predictions were broadcast, giving a majority to the Labour Party. This was the most significant attack in recent days, peaking at 156,000 rps. It began at 01:47 local time (00:47 UTC) and ended four minutes later. Here’s a closer look at that July 5, 2024, attack:

Although these rates are small on Cloudflare’s scale, they can be devastating for unprotected websites unaccustomed to such levels of traffic.

Conclusion: high intensity election year

Even if major political events don’t always bring notable changes to Internet traffic, our data shows that in the UK, traffic decreased more significantly in the afternoon and evening, especially as voting stations remained open until 22:00.

After voting ended, news sites became the go-to resource for UK residents seeking initial predictions and results.

We also observed attacks targeting political parties in the UK, further highlighting that this election year is marked by cyberattacks aimed at influencing politically related websites.

First round of French election: party attacks and a modest traffic dip

2024-07-03 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/first-round-of-french-election-2024-party-attacks-and-a-modest-traffic-dip

France is currently electing a new government through early legislative elections that began on Sunday, June 30, 2024, with a second round scheduled for July 7. In this blog, we show how Cloudflare blocked DDoS attacks targeting three different French political parties.

2024 has been dubbed “the year of elections,” with elections taking place in over 60 countries, as we have mentioned before (1, 2, 3). If you regularly follow the Cloudflare blog, you’re aware that we consistently cover election-related trends, including in South Africa, India, Iceland, Mexico, the European Union and the 2024 US presidential debate. We also continuously update our election report on Cloudflare Radar.

Recently in France, as in the early stages of the war in Ukraine and during EU elections in the Netherlands, political events have precipitated cyberattacks. In France, several DDoS (Distributed Denial of Service attack) attacks targeted political parties involved in the elections over the past few days, with two parties hit just before the first round and another on election day itself.

The first political party, shown in yellow in the previous chart, experienced a DDoS attack on June 23, 2024, peaking at 68,000 requests per second (rps); it also endured a second DDoS attack on June 29, the day before the election, peaking at 20,000 rps. Although these rates are small on Cloudflare’s scale, they can be devastating for unprotected websites unaccustomed to such levels of traffic.

The second party, represented by the blue line, was targeted on June 24, June 27, and June 29, 2024, with the most severe attack occurring on June 27, reaching 118,000 rps during a day marked by frequent DDoS spikes that had in total 610 million daily requests.

The third party was attacked on the evening of June 29 in France, with several attempts blocked by Cloudflare on election day, June 30, between 10:00 and 23:00 UTC (12:00 and 01:00 local time). The peak activity targeting this party hit nearly 40,000 rps at 19:00 UTC (21:00 local time), with a total of 620 million daily DDoS requests on election day.

Modest drops and clear traffic increases after voting ends

During the first round of the election this past Sunday, June 30, 2024, Internet traffic was initially higher than the previous week but dropped by as much as 3% at 11:30 local time (09:30 UTC) after the polls opened. Traffic began to increase again after 17:45 local time (15:45 UTC) and peaked at 20:00 local time (18:00 UTC) when the polls closed and the first projections were announced.

We will provide a trends update on the French election after the runoff scheduled for July 7, 2024.

This week, we’ve updated our trends to include last-minute voting during the elections in Iran on June 28, 2024, and the suspension of mobile Internet in Mauritania following protests after the presidential elections on June 29, 2024.

How the UEFA Euro 2024 football games are impacting local Internet traffic

2024-06-21 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/how-uefa-euro-2024-football-games-impact-internet-traffic

Football (“soccer” in the US) is considered the most popular sport in the world, with around 3.5 billion fans spread across the world. European football is central to its popularity. The UEFA Euro 2024 (the European Football Championship) started on June 14 and will run until July 14, 2024. But how much do these games impact Internet traffic in countries where national teams are playing? That’s what we aim to explore in this blog post. We found that, on average, traffic dropped 6% during games in European countries with national teams playing in the tournament.

Cloudflare has a global presence with data centers in over 320 cities, which helps provide a global view of what’s happening on the Internet. This is helpful for security, privacy, efficiency, and speed purposes, but also for observing Internet disruptions and traffic trends.

In the past, we’ve seen how Internet traffic and HTTP requests are impacted by events such as total solar eclipses, the Super Bowl, and elections. 2024 is the year of elections, and we’ve been sharing our observations in blog posts and our new 2024 Election Insights report on Cloudflare Radar.

However, football games are different from elections. Related trends happen when major teams or national squads are playing matches that draw a lot of human attention. If a game is broadcast on a national TV channel, Internet traffic typically drops because during games. People’s attention is more on the TV set with the ‘old’ broadcast signal, for those games that don’t require a paid subscription. That’s the most common situation when national teams are playing in Europe.

If it’s on a closed or paid channel (where a subscription is needed), then sometimes traffic increases as fewer viewers have access to the TV broadcast. For context, there’s a trend of channels offering games in their apps through streaming, not only for paid channels but also national broadcasters such as the British BBC. The opening England game in Euro 2024 on Sunday, June 16, 2024, had 15 million viewers on BBC One and was also streamed 3.5 million times on BBC iPlayer. This variety of viewing options from a single service appears to be a new trend in the digital age.

Football games associated with drops in traffic

Now, for some game-related Internet trends: the Netherlands, Turkey, Belgium, Croatia, Slovakia, Serbia, and host Germany were the countries where their national team games had a significant impact on requests, with a drop of at least 12% compared to the previous week. Western Europe and countries around Germany top the list. The list shown in the map and the table below covers the first round of games among all teams in all six groups, which concluded on June 19, 2024.

Source: Cloudflare. Map created with Datawrapper

Here is the full list, which provides more detail than the map above, showing each country and the percentage decrease (or increase) in traffic as compared to the previous week at the time those countries’ national team games were occurring.

Country	Increase/ decrease traffic	Game day/hour (UTC)	Opponent
Netherlands	-18%	June 16, 13:00	Poland
Turkey	-16%	June 18, 16:00	Georgia
Belgium	-15%	June 17, 16:00	Slovakia
Croatia	-14%	June 15, 16:00	Spain
Slovakia	-14%	June 17, 16:00	Belgium
Serbia	-13%	June 16, 19:00	England
Germany	-12%	June 14, 19:00	Scotland
Denmark	-10%	June 16, 16:00	Slovenia
Slovenia	-10%	June 16, 16:00	Denmark
Switzerland	-9%	June 15, 13:00	Hungary
England	-8%	June 16, 19:00	Serbia
Georgia	-8%	June 18, 16:00	Turkey
Austria	-7%	June 17, 19:00	France
Hungary	-7%	June 15, 13:00	Switzerland
Spain	-7%	June 15, 16:00	Croatia
France	-6%	June 17, 19:00	Austria
Scotland	-6%	June 14, 19:00	Germany
Portugal	-6%	June 18, 19:00	Czechia
Italy	-3%	June 15, 19:00	Albania
Czechia	-3%	June 18, 19:00	Portugal
Ukraine	9%	June 17, 13:00	Romania
Poland	12%	June 16, 13:00	Netherlands
Romania	16%	June 17, 13:00	Ukraine
Albania	25%	June 15, 19:00	Italy

Albania, Romania, Poland, Ukraine, and Slovenia were the only countries with an increase in HTTP requests during games. England (-8%) and Scotland (-6%) both have similar drops in requests during their national team games.

We’ve also noticed looking at our country-related HTTP data around games that social media services usually go up during half-time and before and after these national team games. As expected, traffic to websites in categories like AI chatbots, ecommerce (though some see increases during halftime), productivity tools, and business and financial services tends to decrease during Euro 2024 games.

First day of competition: Germany-Scotland

Another important perspective is focused on the first day of competition. On June 14, 2024, Euro 2024 kicked off in Germany. How was Internet traffic impacted in the country?

When the ceremony started around 18:45 UTC (20:45 local time), by as much as 11%, deepening to a 12% drop from the previous week when the first game between Germany and Scotland began at 19:00 UTC (21:00 local time). Traffic briefly recovered during halftime to only 4% below the previous week’s levels, but fell again to 11% below the prior week during the second half. At 00:00 UTC (02:00 local time), requests dropped as much as 19% from the previous week, in a night of celebration for German fans.

The second round of games in the Euro 2024 group phase is already underway. We’re keeping an eye on country-related trends after games on X.

An attacks perspective

During the UEFA Euro 2024 event in Germany, we’ve observed several attacks in the country. These included application layer DDoS (Distributed Denial of Service) attacks targeting various websites, such as a translation tool, a data protection tool, a search engine, and a local government website. The most significant DDoS attack occurred on June 15, 2024, the day after the competition started, targeting the translation tool. This attack reached 105 million requests per hour at 23:00 UTC and lasted about two hours with two distinct spikes.

Looking more closely at the attack on the translation tool, it peaked at 1.74 million requests per second (rps) at 23:40 UTC, following an initial spike of 147,000 rps at 21:04 UTC.

Conclusion

Football is incredibly important to Europeans, enough to cause nationwide Internet traffic to drop when fans are rooting for their national teams in a UEFA Euro 2024 game broadcast on national TV.

Despite the popularity of online services like live score apps, sports news sites that track every minute of each game, and betting services enhanced with new visual tools and stats, national team football (or soccer) still significantly diverts attention away from the Internet.

We will continue to monitor UEFA Euro 2024 Internet trends. Based on the results of a poll we conducted on X, we plan to publish daily updates about games and their impact on countries whose national teams are playing that day. Follow us there.

Exploring the 2024 EU Election: Internet traffic trends and cybersecurity insights

2024-06-10 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/exploring-the-2024-eu-election-internet-traffic-trends-and-cybersecurity-insights

The 2024 European Parliament election took place June 6-9, 2024, with hundreds of millions of Europeans from the 27 countries of the European Union electing 720 members of the European Parliament. This was the first election after Brexit and without the UK, and it had an impact on the Internet. In this post, we will review some of the Internet traffic trends observed during the election days, as well as providing insight into cyberattack activity.

Elections matter, and as we have mentioned before (1, 2), 2024 is considered “the year of elections”, with voters going to the polls in at least 60 countries, as well as the 27 EU member states. That’s why we’re publishing a regularly updated election report on Cloudflare Radar. We’ve already included our analysis of recent elections in South Africa, India, Iceland, and Mexico, and provided a policy view on the EU elections.

The European Parliament election coincided with several other national or local elections in European Union member states, leading to direct consequences. For example, in Belgium, the prime minister announced his resignation, resulting in a drop in Internet traffic during the speech followed by a clear increase after the speech was over. In France, we saw a similar pattern with the announcement of legislative snap elections.

From analyzing patterns seen during previous elections in France and Brazil, we know that Internet traffic often decreases during voting hours, though not as significantly as during other major events like national holidays. This usual drop is typically followed by an increase in traffic as election results are announced.

Let’s start with a wider picture of the 2024 European Parliament election, focusing on the time of the biggest drop in Internet HTTP requests during the election days as compared to the previous week. Note that there were some national or local elections taking place at the same time, and European Union elections are known to have low turnout compared to national and local ones.

Drops greater than 10% were observed only in the Czech Republic, Luxembourg, Slovakia, Cyprus, Belgium, Estonia, and Croatia. The table below includes the percentage that traffic dropped and the specific time during the election day it occurred. In countries with more than one election day, we considered the time and day of the biggest drop.

Countries	Elections day(s)	Local time	Drop in traffic %
Czech Republic	June 7 – 8	June 8, 14:30	-20%
Luxembourg	June 9	12:45	-18%
Slovakia	June 8	15:45; 19:00	-16%
Cyprus	June 9	10:00	-16%
Belgium	June 9	11:45	-14%
Estonia	June 7-9	June 9, 9:00	-13%
Croatia	June 9	18:00	-12%
Poland	June 9	18:00	-10%
Netherlands	June 6	10:15	-10%
Germany	June 9	13:45	-10%
Ireland	June 7	7:15	-9%
Finland	June 9	9:00	-9%
Portugal	June 9	15:45	-9%
Malta	June 8	12:15	-9%
Latvia	June 8	08:30, 16:15	-9%
Slovenia	June 9	18:00	-8%
Hungary	June 9	6:00	-8%
Austria	June 9	12:30	-7%
Italy	June 8 – 9	June 9, 16:00	-6%
France	June 9	13:30	-6%
Bulgaria	June 9	19:45	-5%
Greece	June 9	8:00	-5%
Spain	June 9	13:00	-4%
Lithuania	June 9	8:00	-3%
Romania	June 9	9:45	-1%
Denmark	June 9	–	–
Sweden	June 9	–	–

The data in the list above shows that Central European countries had the highest drop in Internet traffic, particularly the Czech Republic and Slovakia. Eastern Europe saw significant drops in Estonia and Poland. Southern Europe had consistent moderate drops across multiple countries, with Cyprus and Croatia showing higher losses. Northern Europe showed minimal to no traffic drop in Scandinavian countries, with Finland and Ireland experiencing moderate declines.

Looking at the specific (local) times of day during voting periods on election days, morning drops (06:00 – 10:00) were more common in Northern and Eastern Europe. Late morning to early afternoon drops (10:15 – 14:30) were predominantly observed in Western and Central Europe. Late afternoon drops (15:45 – 19:45) were more common in Central and Southern Europe.

Impact of notable announcements in Belgium and France

There’s more to say when we look at specific country trends. The 27 members of the European Union bring diversity in habits, languages, and cultures. That also impacted traffic, and this election in particular had a national impact in some of the countries.

In Belgium, national and regional elections took place on the same day, June 9. After polling stations closed at 16:00 local time (14:00 UTC), HTTP requests followed the typical pattern of increasing, peaking at 21:15 local time (19:15 UTC), with 7% more requests than the previous week. This trend was interrupted by Prime Minister Alexander De Croo’s speech at around 22:00 local time (20:00 UTC), admitting defeat in the national elections. This pattern is typical when important announcements are broadcast on TV, impacting Internet traffic.

How about France? President Emmanuel Macron announced at around 21:00 local time (19:00 UTC) that he would dissolve the national parliament for a snap legislative election. This followed the EU elections that gave a victory to his rival Marine Le Pen’s National Rally in the European Parliament vote. At the time of his speech, requests dropped 6% compared to the previous week, and increased right after Macron’s speech, peaking at 22:15 local time (20:15 UTC) with a 6% increase.

After voting ends, traffic increases

It was not only Belgium and France that had typical increases in HTTP requests at night when the first projections and results started to be announced. The same happened in the Netherlands, the first European country to enter the 2024 European Parliament election, on Thursday, June 6.— We have previously written about Dutch political websites being attacked on that day. Traffic was 4% higher than usual after 20:30 local time (18:30 UTC), and peaked at 01:15 with a 15% increase compared to the previous week.

Similar trends were seen in Italy on June 9, and in Germany on the same day. In Germany, at 21:45 (19:45 UTC), requests were already 8% higher, with a 23:00 (21:00 UTC) drop of 2% during election speeches, and a peak at 00:30 (22:30 UTC) with an 18% increase.

The same night-time trends were observed in other countries:

Slovakia had a peak increase of 24% at 23:45 local time (21:45 UTC) on June 8.
Spain saw a 21% peak increase at 21:00 local time (19:00 UTC) on June 9.
Poland had a 9% peak increase at 01:45 local time (23:45 UTC).
Portugal experienced a 29% peak increase at 00:15 local time (23:15 UTC).
Croatia had a 19% peak increase at 23:00 (21:00 UTC).
Slovenia had a 19% peak increase at 22:45 (20:45 UTC).
Lithuania had a 22% peak increase at 23:00 (20:00 UTC).
Estonia saw the highest peak increase, reaching 35% at 00:00 (21:00 UTC).

Growing interest in election information and news

Switching to domain trends, DNS traffic (using our 1.1.1.1 resolver) shows a more specific impact related to elections. Social media platforms invited users in Europe to vote, sometimes giving European or local websites as a reference. Here’s an example from Instagram:

Did this increase traffic to election-related sites in the European Union? Our DNS data shows a 26x peak growth at 19:00 UTC on Sunday, June 9, 2024. DNS traffic was already much higher compared to the previous week on June 8, with a peak growth of 8x at 17:00 UTC.

Looking at European news outlets’ domains, there was an initial 1.68x increase (compared to the previous week) at 13:00 UTC on June 9, 2024, and a second peak at 19:00 UTC.

For local election-results sites, there was a significant 55x peak growth at 22:00 UTC on June 9, 2024, compared to the previous week.

Government-focused cyberattacks

Focusing on attacks, as mentioned above, we recently published a blog post about the cyberattack on Dutch political-related websites that lasted two days – June 5 and 6. The main DDoS (Distributed Denial of Service attack) attack on June 5, the day before the Dutch election, reached 73,000 requests per second (rps).

Looking at government or state-related websites in the European Union in 2024, there have been several spikes in attacks targeting defense organizations, European courts, and educational institutions since the year started.

The main one was on February 25, 2024, when Cloudflare blocked a DDoS attack on a French government website that reached 420 million requests per hour and lasted over three hours.

Between January and June 2024, government sites in Belgium, France, and Germany were the main targets, receiving 49%, 25%, and 10% respectively of attack requests targeting EU government-related sites.

In a broader view, from January 1 to June 9, Cloudflare mitigated 8.6 billion threats to government websites in the EU, with 68% of those being DDoS threats. This amounts to an average of 53.42 million threats mitigated per day. These trends highlight the ongoing threat to critical infrastructure across Europe, with government sites frequently targeted by cyberattacks.

Just before the elections

Focusing on the five weeks before the EU election, we didn’t see significant attacks on European election-related organizations. However, there were a few DDoS threats that targeted government sites from European Union member states. Notable instances include attacks on the Bulgarian government on June 6, the French government on May 11 and June 9, another in France on May 23, Sweden on May 18 and April 29, and Denmark on May 7.

These attacks were not very large compared to others mentioned. The largest targeted the Bulgarian government on June 6, with 122 million daily DDoS requests and a peak of 110,500 requests per second at 11:29 local time (08:29 UTC).

On election day in France, June 9, a French government website was also the target of a smaller attack, with 42,000 DDoS requests per second at 11:57 local time (09:57 UTC).

Conclusion

The 2024 European Parliament election had some clear impacts on Internet traffic, and cyber threats were looming in the weeks before, most notably the Dutch political-related attack around election day.

While voting led to typical drops in Internet traffic, the announcement of results and significant political events caused spikes in activity.

If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, that we’re updating as elections take place throughout the year.

Internet insights on 2024 elections in the Netherlands, South Africa, Iceland, India, and Mexico

2024-06-07 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/internet-insights-on-2024-elections-in-the-netherlands-south-africa-iceland-india-and-mexico

2024 is being called by the media “the” year of elections. More voters than ever are going to the polls in at least 60 countries for national elections, plus the 27 member states of the European Union. This includes eight of the world’s 10 most populous nations, impacting around half of the world’s population.

To track and analyze these significant global events, we’ve created the 2024 Election Insights report on Cloudflare Radar, which will be regularly updated as elections take place.

Our data shows that during elections, there is often a decrease in Internet traffic during polling hours, followed by an increase as results are announced. This trend has been observed before in countries like France and Brazil, and more recently in Mexico and India — where elections were held between April 19 and June 1 in seven phases. Some regions, like Comoros and Pakistan, have experienced government-directed Internet disruptions around election time.

Below, you’ll find a review of the trends we saw in elections in South Africa (May 29), to Mexico (June 2), India (April 19 – June 1) and Iceland (June 1). This includes election-related shifts in traffic, as well at attacks. For example, during the European Parliament election (June 6-9, 2024), DDoS attacks targeted Dutch political websites for two days, peaking at 73,000 requests per second.

We’ll also be keeping an eye on upcoming elections. The United Kingdom recently scheduled its general election for July 4, making it the latest addition to the electoral calendar.

Locations with national elections in 2024 (over 60, plus EU elections with 27 countries participating). Including local elections, over 100 countries will hold elections. In several countries, there will be multiple elections in 2024.

Dutch political websites hit by cyber attacks

Europe: 2024 European Parliament election (June 6-9)

As mentioned above, we recently published a blog post about the cyber attack on Dutch political-related websites. The 2024 European Parliament election started in the Netherlands on June 6, and continues through June 9 in the other 26 countries that are part of the European Union. Cloudflare observed DDoS attacks targeting multiple election or politically-related Internet properties on election day in the Netherlands, as well as the preceding day.

The main June 5 DDoS attack on one of the websites peaked at 14:13 UTC (16:13 local time), reaching 73,000 requests per second (rps) in an attack that lasted for a few hours. This attack is illustrated by the blue line in the graph below, which shows that it ramped slowly over the first half of the day, and then appeared to abruptly stop at 18:06. And on June 6, the main attack on the second website peaked at 11:01 UTC (13:01 local time) with 52,000 rps.

More information can be found in the dedicated blog post and the elections report.

A European Union perspective

In Europe, cyberattacks have been a significant issue. In March 2024, French government websites faced attacks of “unprecedented intensity,” according to a spokesperson. Just days earlier, on February 25, 2024, Cloudflare blocked a major DDoS attack on a French government website, which reached 420 million requests per hour and lasted over three hours.

These incidents highlight the ongoing threat to critical infrastructure across Europe, with government sites frequently targeted by cyberattacks.

Mexicans go offline: early traffic drops on election day

Mexico: Presidential, Senate, and Chamber of Deputies elections (June 2)

General elections were held in Mexico on Sunday, June 2, 2024, resulting in the election of the first female president, Claudia Sheinbaum, from the Morena political party. Cloudflare data shows a typical election day pattern in Mexico, mirroring trends seen in other countries: when polling stations are open, HTTP requests dip below normal levels. On June 2, traffic decreased between 08:00 and 20:00 CST (14:00 and 02:00 UTC), gradually recovering afterward as polling stations closed at 18:00 CST. Throughout the day, traffic experienced drops of up to 11% at 09:30 and 13:00 CST, with daily traffic decreasing by 3%.

The first official results were released after 23:00 (05:00 UTC in the chart above), coinciding with an 8% increase in traffic compared to the previous week. This growth peaked at 01:30 (07:30 UTC), with a 14% surge in HTTP requests, maintaining elevated levels until 07:30 in Mexico.

A similar trend was observed at the state level, with the period between 10:00 CST and 14:00 being the one with the most significant drop in traffic, with voting taking place all over the country.

(We provide a full table of the biggest drops in traffic and the specific time of that drop on election day by Mexican state in our Radar 2024 Election Insights report).

Website trends: traffic spikes from news and election results

Switching to domain trends, DNS traffic (using our 1.1.1.1 resolver) to election results sites in Mexico grew by almost 116x compared to the previous week, peaking at 20:00 CST (02:00 UTC), and remained up to 80x higher, until 23:00 CST (05:00 UTC).

Examining news media outlets, there was noticeable growth in DNS queries on Election Day, June 2, with traffic significantly higher than the previous week in the early morning. By 20:00 CST (02:00 UTC), traffic surged to 1.8x higher, then skyrocketed to a 4.8x increase by 23:00 CST (05:00 UTC), reaching a peak at 01:00 CST (07:00 UTC) with a staggering 1057% more DNS traffic than the previous week.

Attacks: early May election-related DDoS spike

We didn’t see any unusual attacks targeting Mexico before the election, except for one targeting a state electoral organization. A specific DDoS attack on May 6 targeted a state electoral organization, reaching 130 million HTTP requests per hour, with a peak of 113,000 requests per second at 09:12 CST (15:12 UTC). The attack lasted about 30 minutes.

India’s elections: 44 days of traffic dips and mobile spikes

India: General election (April 19 – June 1)

In India, general elections were held from April 19 to June 1, 2024 in seven phases, with incumbent Prime Minister Narendra Modi winning by a smaller margin than in the previous election. More than 968 million people out of a population of 1.4 billion were eligible to vote, and there was a 66% turnout, making it the largest election in human history.

Not all states voted on the same days, leading to mixed HTTP request patterns. On April 18, the day before the first election day, traffic was 10% higher than the previous week, marking the biggest increase of the year, something we’ve seen in other elections.

Some of the seven election days had a nationwide impact. Not all states in India voted on the same days. However, days with more constituencies or populous states participating saw bigger traffic changes. For example, May 7, 2024, saw 11 states, including the most populous ones, voting. This day (highlighted in the next chart) experienced the biggest nationwide drop in traffic, with a 6% decrease compared to the previous week. May 20 and May 25 also saw drops of 4% and 3%, respectively.

The period between 15:30 and 19:30 local time (10:00 – 14:00 UTC) typically witnessed the most significant drop in traffic on election days.

In Uttar Pradesh, the most populous Indian state, the first day of elections on April 19 saw the biggest drop (9%). May 20 and 25, with more constituencies voting, also experienced significant traffic drops, especially May 20, with traffic lower than usual between 10:30 and 22:30 UTC (05:00 – 17:00 UTC), and a 5% daily drop compared to the previous week.

In Maharashtra, home to the capital Mumbai, May 20 saw the most impact, with a 17% drop in daily traffic compared to the previous week. On this day, traffic hit its lowest point at 14:30 local time (09:00 UTC), with a drop of approximately 20%.

(We provide a full table of the states in India with the biggest drop in daily traffic over the several election days in our Radar 2024 Election Insights report).

Mobile devices first in India

India is a mobile-first country, with most election days during the week. On weekends, mobile devices are used more, especially on Sundays when they can reach 69% of all traffic. During the week, usage is typically between 61% and 62%. On election days, mobile device usage increased to around 64%.

Saturday, June 1, 2024, the last election day, was the Saturday of the year in India with the highest daily mobile device traffic percentage, reaching 68% (typically around 65-66%).

The increase in mobile device usage on election days was more noticeable during the day, particularly between 10:00 and 13:00 local time (04:30 – 07:30 UTC). May 13 and May 20 showed the biggest differences compared to typical days, reaching up to 62% during those times. In India, mobile usage during weekends is higher at night than during the day.

Attacks

Since April 2024, Cloudflare hasn’t observed any unusual or potentially election-related attacks targeting India. However, there have been large attacks on online financial services, consulting firms, and online casinos. The most targeted industries during this period have been Information Technology and Services, BFSI (Banking, Financial Services, and Insurance), and Gaming/Gambling.

Iceland’s 2024 election: impact before and after extended voting day

Iceland: Presidential election (June 1)

Iceland held its presidential election on Saturday, June 1, 2024, and Halla Tómasdóttir was elected as the new president. She is the second woman to become president in Iceland and the fourth woman to hold a top leadership position, including prime ministers.

In terms of HTTP requests, there wasn’t much change during election day. This might be because polling stations in Iceland were open from 09:00 to 22:00 local time (same as UTC), spreading out the impact. However, traffic increased the days before and after the election.

On May 31, the day before the election, daily traffic in Iceland was 7% lower than the previous week. It remained stable on election day and increased by 14% on Sunday when results were announced. This increase was only surpassed by two days in 2024:

May 2: +17%, driven by a 9% drop the previous week due to the national holiday, the first day of summer.
March 19: +16%, due to a volcanic eruption that led to a state of emergency, evacuations, and road closures.

Looking deeper into election day traffic with 15-minute granularity, traffic was around 12% lower between 14:00 and 16:00 local time (same as UTC), with the biggest drop, 20%, at 15:30.

Mobile devices usage changes

June 2 and June 1, election day, were also the days in 2024 with the highest percentage of mobile device usage in Iceland, at 47% and 45%, respectively. June 1’s percentage is tied with March 2, the day the famous Blue Lagoon was evacuated due to nearby seismic activity suggesting an “imminent” volcanic eruption, and January 1, the first day of the year.

Attacks

Cloudflare didn’t observe any relevant attacks during the election period targeting Iceland and its Internet properties. Since the beginning of April 2024, the most attacked industries were Retail and Gaming.

South Africa: traffic surges pre-voting, 16% decrease during voting

South Africa: 2024 general election (May 29)

On general election day in South Africa, which took place on Wednesday, May 29, 2024, HTTP requests dipped while polling stations were open. Traffic remained lower than usual from around 05:30 local time (03:30 UTC), with a 16% drop observed at 05:45 (03:45 UTC) and a 14% decrease by 11:00 (09:00 UTC), persisting until 18:00 (16:00 UTC).

However, as shown in the chart above, the night leading up to the election saw a traffic surge, peaking at a 25% increase around midnight local time (22:00 UTC). Following the election, traffic rose compared to the previous week, with a 6% increase at 23:30 local time and a 12% to 8% rise around 04:00 and 09:00 local time (02:00 – 07:00 UTC) on May 30.

Daily traffic overall was 6% lower than the previous week, with mobile device usage increasing to 63%, compared to 57% the previous week.

Attacks: news under attack

Cloudflare didn’t detect any major threats targeting government or election-related online platforms. However, in the lead-up to election day, on May 7, a significant DDoS attack targeted a major news site in South Africa, with 773 million daily requests. This attack peaked at 16:06 local time (14:06 UTC) with 54,000 requests per second and continued in the following days.

Geopolitics are here to stay

Elections, geopolitical changes, and disputes impact the online world. Our DDoS threat report for Q1 2024 gives a few recent examples. One notable case was the 466% surge in DDoS attacks on Sweden after its acceptance into the NATO alliance, mirroring the pattern observed during Finland’s NATO accession in 2023.

Real-world conflicts and wars often lead to Internet pattern changes, disruptions, or cyberattacks. For instance, during the first year of the war in Ukraine, and more recently, Cloudflare’s Cloudforce One thwarted a phishing attack by the Russia-aligned threat actor FlyingYeti. Our recent Project Galileo blog post also details how we protected Meduza, an independent news outlet focused on Russia, from online attacks in late 2023.

We’ve also reported (1, 2) on Internet changes, disruptions, and increased cyberattacks following the start of the Israel-Hamas war on October 7, 2023.
If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, that we’re updating as national and European elections take place throughout the year.

DDoS threat report for 2024 Q1

2024-04-16 Omer Yoachimik

Post Syndicated from Omer Yoachimik original https://blog.cloudflare.com/ddos-threat-report-for-2024-q1

Welcome to the 17th edition of Cloudflare’s DDoS threat report. This edition covers the DDoS threat landscape along with key findings as observed from the Cloudflare network during the first quarter of 2024.

What is a DDoS attack?

But first, a quick recap. A DDoS attack, short for Distributed Denial of Service attack, is a type of cyber attack that aims to take down or disrupt Internet services such as websites or mobile apps and make them unavailable for users. DDoS attacks are usually done by flooding the victim’s server with more traffic than it can handle.

To learn more about DDoS attacks and other types of attacks, visit our Learning Center.

Accessing previous reports

Quick reminder that you can access previous editions of DDoS threat reports on the Cloudflare blog. They are also available on our interactive hub, Cloudflare Radar. On Radar, you can find global Internet traffic, attacks, and technology trends and insights, with drill-down and filtering capabilities, so you can zoom in on specific countries, industries, and networks. There’s also a free API allowing academics, data sleuths, and other web enthusiasts to investigate Internet trends across the globe.

To learn how we prepare this report, refer to our Methodologies.

2024 Q1 key insights

Key insights from the first quarter of 2024 include:

2024 started with a bang. Cloudflare’s defense systems automatically mitigated 4.5 million DDoS attacks during the first quarter — representing a 50% year-over-year (YoY) increase.
DNS-based DDoS attacks increased by 80% YoY and remain the most prominent attack vector.
DDoS attacks on Sweden surged by 466% after its acceptance to the NATO alliance, mirroring the pattern observed during Finland’s NATO accession in 2023.

Starting 2024 with a bang

We’ve just wrapped up the first quarter of 2024, and, already, our automated defenses have mitigated 4.5 million DDoS attacks — an amount equivalent to 32% of all the DDoS attacks we mitigated in 2023.

Breaking it down to attack types, HTTP DDoS attacks increased by 93% YoY and 51% quarter-over-quarter (QoQ). Network-layer DDoS attacks, also known as L3/4 DDoS attacks, increased by 28% YoY and 5% QoQ.

2024 Q1: Cloudflare mitigated 4.5 million DDoS attacks

When comparing the combined number of HTTP DDoS attacks and L3/4 DDoS attacks, we can see that, overall, in the first quarter of 2024, the count increased by 50% YoY and 18% QoQ.

In total, our systems mitigated 10.5 trillion HTTP DDoS attack requests in Q1. Our systems also mitigated over 59 petabytes of DDoS attack traffic — just on the network-layer.

Among those network-layer DDoS attacks, many of them exceeded the 1 terabit per second rate — almost on a weekly basis. The largest attack that we have mitigated so far in 2024 was launched by a Mirai-variant botnet. This attack reached 2 Tbps and was aimed at an Asian hosting provider protected by Cloudflare Magic Transit. Cloudflare’s systems automatically detected and mitigated the attack.

The Mirai botnet, infamous for its massive DDoS attacks, was primarily composed of infected IoT devices. It notably disrupted Internet access across the US in 2016 by targeting DNS service providers. Almost eight years later, Mirai attacks are still very common. Four out of every 100 HTTP DDoS attacks, and two out of every 100 L3/4 DDoS attacks are launched by a Mirai-variant botnet. The reason we say “variant” is that the Mirai source code was made public, and over the years there have been many permutations of the original.

Mirai botnet targets Asian hosting provider with 2 Tbps DDoS attack

DNS attacks surge by 80%

In March 2024, we introduced one of our latest DDoS defense systems, the Advanced DNS Protection system. This system complements our existing systems, and is designed to protect against the most sophisticated DNS-based DDoS attacks.

It is not out of the blue that we decided to invest in this new system. DNS-based DDoS attacks have become the most prominent attack vector and its share among all network-layer attacks continues to grow. In the first quarter of 2024, the share of DNS-based DDoS attacks increased by 80% YoY, growing to approximately 54%.

DNS-based DDoS attacks by year and quarter

Despite the surge in DNS attacks and due to the overall increase in all types of DDoS attacks, the share of each attack type, remarkably, remains the same as seen in our previous report for the final quarter of 2023. HTTP DDoS attacks remain at 37% of all DDoS attacks, DNS DDoS attacks at 33%, and the remaining 30% is left for all other types of L3/4 attacks, such as SYN Flood and UDP Floods.

And in fact, SYN Floods were the second most common L3/4 attack. The third was RST Floods, another type of TCP-based DDoS attack. UDP Floods came in fourth with a 6% share.

When analyzing the most common attack vectors, we also check for the attack vectors that experienced the largest growth but didn’t necessarily make it into the top ten list. Among the top growing attack vectors (emerging threats), Jenkins Flood experienced the largest growth of over 826% QoQ.

Jenkins Flood is a DDoS attack that exploits vulnerabilities in the Jenkins automation server, specifically through UDP multicast/broadcast and DNS multicast services. Attackers can send small, specially crafted requests to a publicly facing UDP port on Jenkins servers, causing them to respond with disproportionately large amounts of data. This can amplify the traffic volume significantly, overwhelming the target’s network and leading to service disruption. Jenkins addressed this vulnerability (CVE-2020-2100) in 2020 by disabling these services by default in later versions. However, as we can see, even 4 years later, this vulnerability is still being abused in the wild to launch DDoS attacks.

Attack vectors that experienced the largest growth QoQ

HTTP/2 Continuation Flood

Another attack vector that’s worth discussing is the HTTP/2 Continuation Flood. This attack vector is made possible by a vulnerability that was discovered and reported publicly by researcher Bartek Nowotarski on April 3, 2024.

The HTTP/2 Continuation Flood vulnerability targets HTTP/2 protocol implementations that improperly handle HEADERS and multiple CONTINUATION frames. The threat actor sends a sequence of CONTINUATION frames without the END_HEADERS flag, leading to potential server issues such as out-of-memory crashes or CPU exhaustion. HTTP/2 Continuation Flood allows even a single machine to disrupt websites and APIs using HTTP/2, with the added challenge of difficult detection due to no visible requests in HTTP access logs.

This vulnerability poses a potentially severe threat more damaging than the previously known

HTTP/2 Rapid Reset, which resulted in some of the largest HTTP/2 DDoS attack campaigns in recorded history. During that campaign, thousands of hyper-volumetric DDoS attacks targeted Cloudflare. The attacks were multi-million requests per second strong. The average attack rate in that campaign, recorded by Cloudflare, was 30M rps. Approximately 89 of the attacks peaked above 100M rps and the largest one we saw hit 201M rps. Additional coverage was published in our 2023 Q3 DDoS threat report.

HTTP/2 Rapid Reset campaign of hyper-volumetric DDoS attacks in 2023 Q3

Cloudflare’s network, its HTTP/2 implementation, and customers using our WAF/CDN services are not affected by this vulnerability. Furthermore, we are not currently aware of any threat actors exploiting this vulnerability in the wild.

Multiple CVEs have been assigned to the various implementations of HTTP/2 that are impacted by this vulnerability. A CERT alert published by Christopher Cullen at Carnegie Mellon University, which was covered by Bleeping Computer, lists the various CVEs:

Affected service	CVE	Details
Node.js HTTP/2 server	CVE-2024-27983	Sending a few HTTP/2 frames can cause a race condition and memory leak, leading to a potential denial of service event.
Envoy’s oghttp codec	CVE-2024-27919	Not resetting a request when header map limits are exceeded can cause unlimited memory consumption which can potentially lead to a denial of service event.
Tempesta FW	CVE-2024-2758	Its rate limits are not entirely effective against empty CONTINUATION frames flood, potentially leading to a denial of service event.
amphp/http	CVE-2024-2653	It collects CONTINUATION frames in an unbounded buffer, risking an out of memory (OOM) crash if the header size limit is exceeded, potentially resulting in a denial of service event.
Go’s net/http and net/http2 packages	CVE-2023-45288	Allows an attacker to send an arbitrarily large set of headers, causing excessive CPU consumption, potentially leading to a denial of service event.
nghttp2 library	CVE-2024-28182	Involves an implementation using nghttp2 library, which continues to receive CONTINUATION frames, potentially leading to a denial of service event without proper stream reset callback.
Apache Httpd	CVE-2024-27316	A flood of CONTINUATION frames without the END_HEADERS flag set can be sent, resulting in the improper termination of requests, potentially leading to a denial of service event.
Apache Traffic Server	CVE-2024-31309	HTTP/2 CONTINUATION floods can cause excessive resource consumption on the server, potentially leading to a denial of service event.
Envoy versions 1.29.2 or earlier	CVE-2024-30255	Consumption of significant server resources can lead to CPU exhaustion during a flood of CONTINUATION frames, which can potentially lead to a denial of service event.

Top attacked industries

When analyzing attack statistics, we use our customer’s industry as it is recorded in our systems to determine the most attacked industries. In the first quarter of 2024, the top attacked industry by HTTP DDoS attacks in North America was Marketing and Advertising. In Africa and Europe, the Information Technology and Internet industry was the most attacked. In the Middle East, the most attacked industry was Computer Software. In Asia, the most attacked industry was Gaming and Gambling. In South America, it was the Banking, Financial Services and Insurance (BFSI) industry. Last but not least, in Oceania, was the Telecommunications industry.

Globally, the Gaming and Gambling industry was the number one most targeted by HTTP DDoS attacks. Just over seven of every 100 DDoS requests that Cloudflare mitigated were aimed at the Gaming and Gambling industry. In second place, the Information Technology and Internet industry, and in third, Marketing and Advertising.

Top attacked industries by HTTP DDoS attacks

With a share of 75% of all network-layer DDoS attack bytes, the Information Technology and Internet industry was the most targeted by network-layer DDoS attacks. One possible explanation for this large share is that Information Technology and Internet companies may be “super aggregators” of attacks and receive DDoS attacks that are actually targeting their end customers. The Telecommunications industry, the Banking, Financial Services and Insurance (BFSI) industry, the Gaming and Gambling industry and the Computer Software industry accounted for the next three percent.

Top attacked industries by L3/4 DDoS attacks

When normalizing the data by dividing the attack traffic by the total traffic to a given industry, we get a completely different picture. On the HTTP front, Law Firms and Legal Services was the most attacked industry, as over 40% of their traffic was HTTP DDoS attack traffic. The Biotechnology industry came in second with a 20% share of HTTP DDoS attack traffic. In third place, Nonprofits had an HTTP DDoS attack share of 13%. In fourth, Aviation and Aerospace, followed by Transportation, Wholesale, Government Relations, Motion Pictures and Film, Public Policy, and Adult Entertainment to complete the top ten.

Top attacked industries by HTTP DDoS attacks (normalized)

Back to the network layer, when normalized, Information Technology and Internet remained the number one most targeted industry by L3/4 DDoS attacks, as almost a third of their traffic were attacks. In second, Textiles had a 4% attack share. In third, Civil Engineering, followed by Banking Financial Services and Insurance (BFSI), Military, Construction, Medical Devices, Defense and Space, Gaming and Gambling, and lastly Retail to complete the top ten.

Top attacked industries by L3/4 DDoS attacks (normalized)

Largest sources of DDoS attacks

When analyzing the sources of HTTP DDoS attacks, we look at the source IP address to determine the origination location of those attacks. A country/region that’s a large source of attacks indicates that there is most likely a large presence of botnet nodes behind Virtual Private Network (VPN) or proxy endpoints that attackers may use to obfuscate their origin.

In the first quarter of 2024, the United States was the largest source of HTTP DDoS attack traffic, as a fifth of all DDoS attack requests originated from US IP addresses. China came in second, followed by Germany, Indonesia, Brazil, Russia, Iran, Singapore, India, and Argentina.

At the network layer, source IP addresses can be spoofed. So, instead of relying on IP addresses to understand the source, we use the location of our data centers where the attack traffic was ingested. We can gain geographical accuracy due to Cloudflare’s large global coverage in over 310 cities around the world.

Using the location of our data centers, we can see that in the first quarter of 2024, over 40% L3/4 DDoS attack traffic was ingested in our US data centers, making the US the largest source of L3/4 attacks. Far behind, in second, Germany at 6%, followed by Brazil, Singapore, Russia, South Korea, Hong Kong, United Kingdom, Netherlands, and Japan.

When normalizing the data by dividing the attack traffic by the total traffic to a given country or region, we get a totally different lineup. Almost a third of the HTTP traffic originating from Gibraltar was DDoS attack traffic, making it the largest source. In second place, Saint Helena, followed by the British Virgin Islands, Libya, Paraguay, Mayotte, Equatorial Guinea, Argentina, and Angola.

The top sources of HTTP DDoS attacks (normalized)

Back to the network layer, normalized, things look rather different as well. Almost 89% of the traffic we ingested in our Zimbabwe-based data centers were L3/4 DDoS attacks. In Paraguay, it was over 56%, followed by Mongolia reaching nearly a 35% attack share. Additional top locations included Moldova, Democratic Republic of the Congo, Ecuador, Djibouti, Azerbaijan, Haiti, and Dominican Republic.

The top sources of L3/4 DDoS attacks (normalized)

Most attacked locations

When analyzing DDoS attacks against our customers, we use their billing country to determine the “attacked country (or region)”. In the first quarter of 2024, the US was the most attacked by HTTP DDoS attacks. Approximately one out of every 10 DDoS requests that Cloudflare mitigated targeted the US. In second, China, followed by Canada, Vietnam, Indonesia, Singapore, Hong Kong, Taiwan, Cyprus, and Germany.

Top attacked countries and regions by HTTP DDoS attacks

When normalizing the data by dividing the attack traffic by the total traffic to a given country or region, the list changes drastically. Over 63% of HTTP traffic to Nicaragua was DDoS attack traffic, making it the most attacked location. In second, Albania, followed by Jordan, Guinea, San Marino, Georgia, Indonesia, Cambodia, Bangladesh, and Afghanistan.

Top attacked countries and regions by HTTP DDoS attacks (normalized)

On the network layer, China was the number one most attacked location, as 39% of all DDoS bytes that Cloudflare mitigated during the first quarter of 2024 were aimed at Cloudflare’s Chinese customers. Hong Kong came in second place, followed by Taiwan, the United States, and Brazil.

Top attacked countries and regions by L3/4 DDoS attacks

Back to the network layer, when normalized, Hong Kong takes the lead as the most targeted location. L3/4 DDoS attack traffic accounted for over 78% of all Hong Kong-bound traffic. In second place, China with a DDoS share of 75%, followed by Kazakhstan, Thailand, Saint Vincent and the Grenadines, Norway, Taiwan, Turkey, Singapore, and Brazil.

Top attacked countries and regions by L3/4 DDoS attacks (normalized)

Cloudflare is here to help – no matter the attack type, size, or duration

Cloudflare’s mission is to help build a better Internet, a vision where it remains secure, performant, and accessible to everyone. With four out of every 10 HTTP DDoS attacks lasting over 10 minutes and approximately three out of 10 extending beyond an hour, the challenge is substantial. Yet, whether an attack involves over 100,000 requests per second, as is the case in one out of every 10 attacks, or even exceeds a million requests per second — a rarity seen in only four out of every 1,000 attacks — Cloudflare’s defenses remain impenetrable.

Since pioneering unmetered DDoS Protection in 2017, Cloudflare has steadfastly honored its promise to provide enterprise-grade DDoS protection at no cost to all organizations, ensuring that our advanced technology and robust network architecture do not just fend off attacks but also preserve performance without compromise.

An Internet traffic analysis during Iran’s April 13, 2024, attack on Israel

2024-04-15 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/internet-traffic-analysis-iran-israel-april-attack

(UPDATED on April 15, 2024, with information regarding the Palestinian territories.)

As news came on Saturday, April 13, 2024, that Iran was launching a coordinated retaliatory attack on Israel, we took a closer look at the potential impact on Internet traffic and attacks. So far, we have seen some traffic shifts in both Israel and Iran, but we haven’t seen a coordinated large cyberattack on Israeli domains protected by Cloudflare.

First, let’s discuss general Internet traffic patterns. Following reports of attacks with drones, cruise missiles, and ballistic missiles, confirmed by Israeli and US authorities, Internet traffic in Israel surged after 02:00 local time on Saturday, April 13 (23:00 UTC on April 12), peaking at 75% higher than in the previous week around 02:30 (23:30 UTC) as people sought news updates. This traffic spike was predominantly driven by mobile device usage, accounting for 62% of all traffic from Israel at that time. Traffic remained higher than usual during Sunday.

Around that time, at 02:00 local time (23:00 UTC), the IDF (Israel Defense Forces) posted on X that sirens were sounding across Israel because of an imminent attack from Iran.

🚨Sirens sounding across Israel🚨 pic.twitter.com/BuDasagr10

— Israel Defense Forces (@IDF) April 13, 2024

(April 15 UPDATE: the Palestinian territories related part). At around the same time, 01:25 local time (22:45 UTC), when the sirens were sounding in Israel, we observed not an increase, but a clear drop in traffic in Palestinian territories. The noticeable drop was seen in all of the Palestinian governorates, although it was a bigger drop in the West Bank, than in the Gaza Strip.

Usually, based on our past observations, drops in traffic unrelated to connectivity issues can occur when people pause their online activities for some reason (an eclipse or war, for example) or turn to television for news updates instead of the Internet (common during election days when TVs broadcast the latest exit polls).

Here’s the noticeable HTTP requests drop in Hebron, one of the most populated states of the Palestinian territories, part of the West Bank. The noticeable drops in the blue line from the previous week are related to the Ramadan, and the Iftar, the first meal after sunset that breaks the fast and often also a family or community event. Ramadan ended on Tuesday, April 9, 2024.

Meanwhile, in Iran, there has been a noticeable decline in traffic over the past few days in the early morning hours, around 04:30 local time (01:00 UTC), as compared to the previous week. However, this decline appears to be linked to the conclusion of Ramadan, which ended April 9. As we have written before, during Ramadan, there is typically an increase in traffic around 04:00 in most Muslim countries for Suhur, the pre-dawn meal. Nevertheless, traffic was higher in Iran early in the morning of Sunday, April 14 than the previous day, between 02:30 local time (23:00 UTC on April 13) and 07:00 (03:30 UTC).

When analyzing application layer attacks, we haven’t observed any significant changes in those targeting Israel over the past few days. However, over the past month, the Government Administration sector emerged as the most targeted industry, with blocked DDoS requests accounting for 46% of all traffic directed towards it.

Based on Cloudflare data, we have not yet seen a coordinated cyberattack campaign targeting Israel. However, we saw a clear uptick in attacks back in October 2023, after the Israel-Hamas war started, as we noted in a blog post at that time.

We will continue to monitor the situation in the Middle East, and you can keep track of by country up-to-date trends visiting Cloudflare Radar, and following us on social media at @CloudflareRadar (X), cloudflare.social/@radar (Mastodon), and radar.cloudflare.com (Bluesky).

Total eclipse of the Internet: Traffic impacts in Mexico, the US, and Canada

2024-04-09 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/total-eclipse-internet-traffic-impacts-mexico-us-canada

*A photo of the eclipse taken by Bryton Herdes, a member of our Network team, in Southern Illinois.*

There are events that unite people, like a total solar eclipse, reminding us, humans living on planet Earth, of our shared dependence on the sun. Excitement was obvious in Mexico, several US states, and Canada during the total solar eclipse that occurred on April 8, 2024. Dubbed the Great North American Eclipse, millions gathered outdoors to witness the Moon pass between Earth and the Sun, casting darkness over fortunate states. Amidst the typical gesture of putting the eclipse glasses on and taking them off, depending on if people were looking at the sky during the total eclipse, or before or after, what happened to Internet traffic?

Cloudflare’s data shows a clear impact on Internet traffic from Mexico to Canada, following the path of totality. The eclipse occurred between 15:42 UTC and 20:52 UTC, moving from south to north, as seen in this NASA image of the path and percentage of darkness of the eclipse.

Looking at the United States in aggregate terms, bytes delivered traffic dropped by 8%, and request traffic by 12% as compared to the previous week at 19:00 UTC (14:00 Eastern, 12:00 Pacific).

Bytes delivered percentage change (-8% at 19:00 UTC)

HTTP requests percentage change (-12% at 19:00 UTC)

The state-level perspective in terms of traffic drop at the time of the eclipse, as compared to the previous week, is much more revealing. Here’s a summary of the US states’ traffic changes. We can almost trace the path of the eclipse, as shown in the previous NASA image.

From our data, Vermont, Arkansas, Indiana, Maine, New Hampshire, and Ohio experienced traffic drops of 40% or more around the time of the eclipse. These states were all in the path of totality, which was not the case for several others.

In the next table, we provide a detailed breakdown of the same perspective shown on the US map ordered by drop in traffic. In all of these charts, we’re using UTC as the time. We include the time of the biggest traffic drop compared to the previous week, at a 5-minute granularity, and also the percentage of drop compared to the previous week. States where it was possible to see at least part of the total eclipse are highlighted in bold. At the bottom are those with no clear difference.

The US: traffic change at time of the eclipse
State	Time of drop (UTC)	Local time	% of drop
Vermont	19:25	15:25	-60%
Arkansas	18:50	13:50	-54%
Indiana	19:05	15:05	-50%
Maine	19:30	15:30	-48%
New Hampshire	19:20	15:20	-40%
Ohio	19:10	15:10	-40%
Kentucky	19:05	14:05	-33%
Massachusetts	19:25	15:25	-33%
Michigan	19:15	15:15	-32%
Kansas	18:50	13:50	-31%
Missouri	18:55	13:55	-31%
Connecticut	19:20	15:20	-29%
Maryland	19:15	15:15	-29%
New York	19:25	15:25	-29%
Oklahoma	18:45	13:45	-29%
Rhode Island	19:25	15:25	-29%
New Jersey	19:20	15:20	-28%
Arizona	18:15	11:15	-27%
Illinois	19:05	14:05	-26%
Pennsylvania	19:15	15:15	-26%
West Virginia	19:15	15:15	-24%
Wisconsin	19:05	14:05	-22%
Wyoming	18:20	12:20	-19%
Alaska	20:15	12:15	-18%
Delaware	19:20	15:20	-18%
District of Columbia	19:15	15:15	-16%
New Mexico	18:25	12:25	-16%
Oregon	18:15	11:15	-16%
Nebraska	18:50	13:50/12:50	-15%
Texas	18:45	13:45	-15%
Colorado	18:25	12:25	-14%
Virginia	18:20	14:20	-14%
Alabama	19:00	14:00	-13%
Tennessee	19:00	15:00/14:00	-13%
Iowa	18:15	13:15	-12%
Nevada	18:10	11:10	-12%
Georgia	19:05	15:05	-11%
North Carolina	19:10	15:10	-10%
California	18:15	11:15	-9%
Florida	18:15	14:15	-7%
Utah	18:15	12:15	-5%
Montana	18:25	12:25	-4%
South Carolina	19:00	15:00	-4%
Hawaii	—	—	—
Louisiana	—	—	—
Minnesota	—	—	—
Mississippi	—	—	—
North Dakota	—	—	—
Idaho	—	—	—
South Dakota	—	—	—
Washington	—	—	—

Visualized, here’s what Vermont’s 60% drop looks like:

And here’s what the traffic drops in Arkansas, Maine, and Indiana look like:

In terms of states with larger populations, New York took the lead:

Mexico got the eclipse first

Before the eclipse became visible in the US, Mexico experienced it first. States within the eclipse zone, such as Coahuila, Durango, and Sinaloa, experienced noticeable drops in traffic. Even Mexico City, located further south, was affected.

Mexico: traffic change at time of the eclipse
State	Time of drop (UTC)	Local time	% of drop
Durango	18:15	12:15	-57%
Coahuila	18:15	12:15	-43%
Sinaloa	18:10	11:10	-34%
Mexico City	18:10	12:10	-22%

Here’s the Durango and Coahuila state perspectives:

Canada at last: an island stopped to see the eclipse

After Mexico and the US, Canada was next in the path of the eclipse. Prince Edward Island experienced the most significant impact in Canada. This region, with a population of less than 200,000, is one of eastern Canada’s maritime provinces, situated off New Brunswick and Nova Scotia in the Gulf of St. Lawrence. Next came New Brunswick and Newfoundland and Labrador.

Canada: traffic change at time of the eclipse
State	Time of drop (UTC)	Local time	% of drop
Prince Edward Island	19:35	16:35	-48%
New Brunswick	19:30	16:30	-40%
Newfoundland and Labrador	19:40	16:10	-32%
Nova Scotia	19:35	16:35	-27%
Quebec	19:25	15:25	-27%
Ontario	19:15	15:15	-21%

Conclusion: Internet is a human’s game

As we’ve observed during previous occasions, human and nature-related events significantly impact Internet traffic. This includes Black Friday/Cyber Week, Easter, Ramadan celebrations, the coronation of King Charles II, the recent undersea cable failure in Africa, which affected 13 countries, and now, this total eclipse.

This was the last total solar eclipse visible in the contiguous United States until August 23, 2044, with the next eclipse of similar breadth projected for August 12, 2045.

For this and other trends, visit Cloudflare Radar and follow us on social media at @CloudflareRadar (X), cloudflare.social/@radar (Mastodon), and radar.cloudflare.com (Bluesky).

Undersea cable failures cause Internet disruptions for multiple African countries

2024-03-14 João Tomé

Post Syndicated from João Tomé original https://blog.cloudflare.com/undersea-cable-failures-cause-internet-disruptions-across-africa-march-14-2024

Internet connectivity in several African countries was disrupted today, March 14, 2024. Beginning at approximately 05:00 UTC, west and central African countries were most impacted, as was South Africa. Based on published reports and social media posts from impacted network providers, the disruption is believed to be due to multiple undersea cable failures in the region. From The Gambia to Côte d’Ivoire, including a major network in South Africa (Vodacom), a total of 11 African countries were impacted, based on our observations.

Cloudflare Radar data shows a pattern of disruptions from the north to the south of West Africa over time. It began south of Senegal, with The Gambia, Guinea, and Liberia experiencing disruptions around 05:00 UTC.

In The Gambia and Guinea, the disruptions lasted about 30 minutes, while in Liberia, the disruption has lasted more than 12 hours.

Moving south, around 07:30 UTC, disruptions were observed in Côte d’Ivoire and Ghana.

Niger, a landlocked nation in Central Africa, experienced a disruption at 09:15, lasting just over two hours.

This was followed by disruptions starting around 10:30 UTC in Nigeria, Benin, Cameroon, and Togo. These disruptions were ongoing at the time of writing.

At approximately the same time, a significant disruption was observed on Vodacom’s South African network (AS29975). Traffic began to recover after 13:30 UTC, and appears to have reached close to normal levels by 16:00 UTC.

The importance of submarine cables

This series of disruptions serves as a reminder of how dependent the Internet is on submarine cables, which are estimated to carry over 90% of intercontinental data traffic. Only a small percentage of general use is done via satellite networks. There are 529 active submarine cables and 1,444 landings that are currently active or under construction, running to an estimated 1.3 million km around the globe.

We have written about submarine cable-related outages before, from Tonga to the AAE-1 & SMW5 cable cuts of June 2022.

Reports from several local networks, including South Africa’s Vodacom, MTN in Nigeria, and Celtiis in Bénin, reference multiple submarine cable failures. Microsoft was more detailed, stating on their Azure status page that “multiple fiber cables on the West Coast of Africa — WACS, MainOne, SAT3, ACE — have been impacted which reduced total capacity supporting our Regions in South Africa”. The company also explains that the recent cable cuts in the Red Sea in combination with today’s cable issues, “has impacted all Africa capacity”.

In addition to the impacts to the Microsoft Azure cloud platform, the website of MainOne, owners of the MainOne submarine cable, was offline for several hours. DNS for mainone.net is handled by name servers located in MainOne’s address space. It appears that a portion of the IPv4 address space for AS37282 (MAINONE) stopped being announced between 07:30 and 15:00 UTC, and once this address space was being routed again, both the nameservers and website became reachable.

This map from TeleGeography highlights the impacted submarine cables: WACS (West Africa Cable System), MainOne, SAT-3/WASC, and ACE.

The disruptions are now being reported by news media outlets, including in South Africa, where the emphasis is not only on the latest outage but also on the problem with the submarine cable operator Seacom. This operator experienced a service-impacting outage on its cable system in the Red Sea. On March 8, the company stated that it is waiting for permits to start repairing its broken submarine cable in the Red Sea.

We will keep monitoring the situation. Follow the Cloudflare Radar Outage Center for the latest updates, and follow us on social media at @CloudflareRadar (X), cloudflare.social/@radar (Mastodon), and radar.cloudflare.com (Bluesky).