Name: Stopping the Largest Attacks: Modernize Your Network Protection
Uploaded: 2026-03-18T06:34:41.944Z
Duration: 46 min 44 s
Description: Stopping the Largest Attacks: Modernize Your Network Protection

Transcript for "Stopping the Largest Attacks: Modernize Your Network Protection": Hello, all, and welcome to today's webinar. Sorry for the, slide delay. My name is Vinay, and I will be helping support today's live session. Before we begin the session, a little bit of housekeeping. On the top right corner of your screen, you will see the live chat option that you can use to interact with your fellow attendees. We have also attached a solution brief on network protection and our ebook on DDoS medication in the docs section that is next to the chat. On the extreme right, you will also find the q and a box. We encourage you to leave all your questions in that q and a box as we progress through this webinar. We'll make sure to address all your questions towards the end of this presentation. A quick reminder, this session is being recorded, and we will share the recording with you within forty eight hours. Now please join me in welcoming today's speaker, Steve Molloy, principal solutions engineer at Cloudflare. Thank you, I. Good afternoon, everyone. How are you, mate? please take it away. Thank you. If you could just stop sharing your screen there today, please. I'll I'll take over from there. Thank you, mate. Look. It's a pleasure to be speaking with everybody today. My name is Steve Malloy. I'm a principal solutions engineer with with Cloudflare based in Melbourne, Australia. The topic we're going to be looking into today is around network level DDoS protection and level of attacks that we have seen over the past period. This is something that's near and dear to my heart. My my background around, you know, over the next last twenty years has been around the network and network architecture. So I really, really enjoy this topic, and I'm excited to be bringing it to you today. We'll go through the trends that we've seen over the past twelve months, the types of attacks and botnets that are actually causing these trends and the increase in those, as well as the impacts that we're seeing to our customers across the world. So let's jump into it. Now you don't have to go too far to look through your your news feeds around the even newspapers these days to see there is an increase in DDoS attacks around the world. Like, NBC News, as a news outlet, is reporting these sorts of things these days. It's it's not something that you just find in IT news. And and one example here is the Internet Archive, you know, sort of like the Internet friendly guys, if you will. They themselves find them as a victim of attack in 2024. This attack lasted for about three days, attacking them at layer three, layer four, as well as providing a mechanism for the attackers to actually gain control of the website itself and deface it. So it's one of those interesting things that when we talk about DDoS attacks, we sort of think about it as a a great outage that stops our services being delivered to our customers and, you know, people within the corporate landscape. But when we see these sort of things happen, we need to sort of think about, you know, what's actually happening in the background. Is this potentially a decoy? And I think that's a really great example of that. Another example is an online gambling firm who were hit in 2025. I think it was around about November or so. And this was particularly linked up to an event, a sporting event that was about to occur. So I'm a bit of a hockey fan myself. So Alex Oveshkin is one of the great players of all time to play the game, and he was just about to beat Wayne Gretzky's record of 894 goals achieved throughout his entire career. So there was a lot of online gambling going on here. And they were taking down this particular service so that people couldn't be betting on this event. So it was just very, very strange at this line out there, but just an example of another motivator that can be used in terms of DDoS. And even giants like Microsoft, you know, they've confirmed themselves that Azure back in 2024 was a victim of a a DDoS attack, which caused a global outage for them. So even the hyperscalers and companies of that nature are not safe from this. So we really need to start thinking about how we can protect ourselves even though we are using their services. The downtime from DDoS attacks is something we really need to be considerate about. Looking at the ITIC report here, you know, the cost of hourly downtime is anywhere between, you know, 300,000 up to millions for cost for for enterprises. And this is based on an hour of downtime. And you think about the the knock on effect that a DDoS attack can have. It would be somebody, you know, either using volumetric to exhaust the resources across your network or your network compliances or even origins, for example. But when you have to mobilize to get your workers together to find out exactly what's happening there, it can be a very, very difficult task, and it can stretch this on for hours. Then think about, you know, the database connections and things that are sensitive to connections and how they need to deal with that. They've restarted. Transactions could be lost if you're a financial institution. And then we start to look at, you know, where this can actually lead to at a board level. So GAP themselves have commissioned a similar report, which shows that the majority of tax, which can last a couple of seconds, will only cost a $100,000 or less. But those that are sustained or, like, the Internet archive run for a couple of days, that can cost anywhere between a million to $10,000,000 per hour, which is absolutely staggering. Cloudflare, each quarter, we release a a threat report and also an annual threat report. So you don't need to wait for this self presentation to find out what's happening across the Internet. You can go to radai.cloudflare.com to see attacks that are occurring live from countries and and destinations and things like that. Otherwise, these reports are available quarterly, and I highly recommend reading them. But to focus on our most recent one from q four twenty twenty five, you can see that we've mitigated 47,100,000 DDoS attacks. Yeah. From year on year growth, that's a 121. That's that's quite staggering. Cloudflare, each day, blocks 260,000,000,000 threats. That's that's quite a large number. And when you look at DDoS, it's only a small portion of that when we look at 47,100,000. But the effect that it has can be absolutely devastating to an organization, as we just spoke to before, about downtime and cost. When we talk about the hyper volumetric attacks as well, the ones that are over terabit per second, which is probably enough to knock down most organizations in terms of what you have in terms of connectivity to the Internet. A 700% increase is is absolutely staggering from when we started back in 2023. And last year as well, we auto mitigated two world record attacks, and we'll kick into those in just a second. But before we do, Vinay, let's start with the poll. I'd be interested to see, you know, what your sort of views are on DDoS and how you've experienced it in the past. So the poll is now open. For everyone joining, on the top right corner next to the chat, you'll see the poll come up. Please feel free to vote for the poll which is now open, and I will be able to see how many votes are being registered. Steve, right now, I'm seeing a lot of people are voting for no. The well, question of the poll is, has your organization suffered a DDoS attack before? And I'm seeing more words for no, not that I know of, and fewer words for yes. So I guess that's, you know, that's what happens over there. That yeah. That's that's great to know. And I'm definitely I'm very happy that it's actually skewing in that direction. Yeah. Well, I guess, while we're waiting for the board results to come through, it I do recall, you know, back in my network support days, at an organization that I worked at, we didn't have on premise twenty four hour stock around the clock. So it was two AM. We got the call that, you know, all sorts of applications were experiencing issues. Obviously, because the links were overwhelmed, I couldn't, you know, remote into anything to find out what was happening. I literally had to get on my bike ride half and hour in the middle of the night to the office to get onto the corporate land to find out what's going on. So just an example of the sort of things that can delay your response to a data center and why protection and always on protection is actually so important. Any change in those results, Vinay, or we. can you present? I'm seeing eight eight words for no, six words for yes. So it has shifted a little bit Okay. Okay. Well, and, still help out with. those still going up. Alright. Hopefully, we can help out those people that have experienced it in the past. Well, hopefully, now they're well protected. Okay. Alright. Let's let's carry go. ahead and close the poll for now, and we can get back to the presentation. Thanks, mate. Thanks to you. So this slide is from our previous version of this presentation that we we staged back in q four last year. And I just wanted to leave it in here because this, at this point in time, was the largest data center tech in history, 7.3 terabits per second, which is a staggering amount of network traffic that could be delivered to your organization. This came from 1,220 oh, sorry. One thousand two hundred and twenty two thousand four hundred 145 IP addresses and over five and a half thousand ASs as well. So you can see the distributed nature of DDoS attacks these days, and that's largely due to the botnets that we are now capable of. They sort of started around maybe 2016. There's different variants of it, and we'll go through those in a in a couple of slides. But just the amount of traffic they can they can generate these days and and the devastation they can cause with such a small amount of bots is really, really staggering. But it's important to note that this was mitigated with zero second downtime. So Cloudflare automated this without always on capability. But just to focus on that largest attack until, this is what we have seen since. So over the past couple of years, so September 2024, every attack that you see there, going from 3.8 all the way up to now 31.4 terabits per second, has been mitigated by And some of those with the stars beside indicate that it was a world record at the time. So we are currently sitting with a world record of 31.4 terabits per second. And look at the rate of growth there. So 12 and a half times is just three years, and that really speaks to the strength of the the botnets that are now out there in the wild and how they're being compromised and shifting away from costly botnets that would be staged from private cloud service. So, you know, your Azure and AWS, you know, that's too costly for the attackers to be using these days. And customers are being smarter about it too, so they are taking this attack traffic and riding it through in a bit of a target sort of fashion. So it reduces increases resources that have been spent by the attackers and increasing their bill. So they're finding craftier ways to stage these attacks these days. So to look behind these these attacks that we saw on the previous graph, I sort of categorized these in a a bronze, silver, and then gold on their level of effectiveness. So the Moray botnet is something that came about around about 2016, and it was used in an attack. It's it's fundamentally using devices that are IoT based with ARM processors that don't have their standard user password combinations changed. So they scan out there for these devices on the Internet, compromising them, and then using them as part of command and control situation when they wanna be used for the DDoS attack. What is interesting is that this this source code was released into the wild in 2016, and we believe that was around the idea of sort of covering up who actually staged this and wrote the code themselves. So it's now out there in the wild, And a really interesting use case that we saw back then was of a company called Protrash Solutions, run by two young gentlemen, a 21 year old and a a 20 year old, where they decided to start attacking organizations. The the mantra was, well, their business model was to sell data solutions. They will start attacking companies and then sort of knocking on the door in, a a proper racketeering swindle there to to get them on board. And they were caught, and, yeah, they did definitely faced prison time there. So not a good outcome for those two guys. A similar way most recently, so around about 2024, the ASUS routers had a common vulnerability score at nine point o. So very, very critical there, where they could be compromised in a similar sort of fashion. And this is allowing the same sort of attack, but allowing more throughput and resource to be to use for for the network level throughput there. Now the most interesting one is what we're seeing to date. Going back to that graph, starting at 3.8, and we're working our way up to 10 times that, so 31.4 terabits per second. The way that's actually occurring is more of a malware oriented botnet DC. So this one's called Asuru. And Asuru is believed to be compromised of about one to 4,000,000 devices. Still compromised, I might add, as well. So the difference there with Kinwolf and Asuru is the Kimwolf is very, very similar, but more of an Android focused as opposed to just IoT devices. And we're seeing a lot of the devices being compromised within countries such as Vietnam, Brazil, India, Saudi Arabia, but the bulk of which being in The United States themselves. So that means it's very difficult to just put a geographical block on your firewalls or security SaaS services because they shift, and they they generally last about one to two days using an IP address. So even if you want to go down to the IP level to block these, it's very, very hard to mitigate these attacks. And these, interestingly as well, are kind of run by parent companies, and they operate on the dark web, and they sell their services out to anyone who is willing to pay the money to attack, you know, a third party or adversary or someone who that could be. So this can range from anywhere from $10 per attack up to hundreds of thousands depending on the amount of devices that are being used and the amount of traffic that is being sent. So it's starting to get quite scary here in terms of what can be achieved. So right now, we're seeing a 31.4 terabits from November 2025, and who knows what we're gonna see next. So how does Cloudflare fit into all of this? Let me talk about the attacks, but how can we actually help to to mitigate this? Cloudflare's network capability is 477 terabits per second. And the way the how we come about doing that is by peering to Internet exchanges, ISPs, transit links, and our own private background to provide that level of connectivity. So this works twofold. When we have all of these cities around the world, we can serve your content in terms of performance and security as close to the eyeball as possible. And that's that's really, really good, but it has a knock on effect that because our network is an Anycast network, we advertise your IP addresses from every one of our data centers. That means when an attack is staged, let's say, within France, that would be absorbed at the Paris Data Center. In The UK, would be London. Here in Australia, maybe down in Victoria, that would be Melbourne as well. Now the idea behind that is that because it's been attracted to the closer data center, it cannot aggregate, which is the fundamental piece of a DDoS attack. Right? All of that throughput sort of bottling up, taking down your resources at the end point. Why this is also important and why it's superior to ISP level protections is that when all of that traffic, even if it was, you know, routing out towards an ISP provider what you that you're sitting behind and they have physical boxes on sitting in front of that in terms of DDoS, is that the upstream providers, when they see this influx of traffic coming through their networks to your subnets further downstream, you're affecting their resources, and they don't like it. So that will knock you off the network by providing a null route of your subnet to take it off the reversement space. So this has a cascading effect and effectively takes you off the Internet. So, you know, even though the DDoS traffic didn't get down to you, it still has the same effect. And it's important to note with Cloudflare as well that every one of our capabilities, whether it's WAF, CDN, workers' capabilities, DDoS protection, runs from every one of our data centers. So we don't have the concept of scrubbing centers. Or if you wanna think of it that we do, that would be more of a scrubbing center occurring in every one of our cities around the world. So we have a staggering amount of throughput to deal with these attacks. At 477, there's a lot of headroom there compared to the 31 that we saw just before. So very, very important that we're not helping in a perfect cost to the globe to scrub it. We're providing everything in a single pass architecture to provide performance, but as well as security without any additional requirements. Now this is not to to pick in any of vendors in particular. That's definitely something I don't like to do. But when we look at, you know, talking about ISPs and how that was no longer sufficient, people would move to a cloud service such as Cloudflare or Akamai or wherever it might be to have that distributed model to deal with such attacks and stop that that black hole that we spoke about just before. Now when you have scrubbing centers, there's finite capacity in what you can scrub. So looking at some of these services here, like, my Prolexic has 32 POPs around the globe that it can scrub from with a total of 20 terabits per second. And if you look at some of these numbers like Imperva, you know, 13 terabits per second, left layer in comparison is 477 from 330, fundamentally, scrubbing centers. So anything post 20 terabits per second, it's quite possible that that could have a negative impact to their own networks themselves, let alone protecting their customers that sit behind their networks. So this is gonna be something that's gonna be quite interesting as we start to look at services and the architectures of these, and why Anycast, when you're looking at cloud service providers for security, is such an important architecture to have. Looking at these verticals as well, you can see there's quite a spread of those that we saw, we spoke about at the start, are being attacked, so the Internet Archive, Microsoft and the likes. You know, it's it's not really vertical dependent. There's different motivators for for, you know, a DDoS attack. So as we saw, you know, for the gambling online gambling firm, they were obviously gonna be a financial sort of motivator there. Finance is very, very, very, you know, critical as a in terms of service. If anything goes wrong with DDoS in terms of finance, they are, you know, regulated by government entities such as APRA in Australia, they and have to go and report and explain why that occurred. So DDoS protection is very, very important for finance. Technology, you it's it's our livelihood these days and how we interact with things on the Internet. Shopify deserves it's something that sits behind Cloudflare. And, you know, there are millions and millions of online stores there, so it's critical that these things start to remain online. Now in terms of health care as well, that's probably the most critical thing going to date. Finance and technology side and all the things that need to come with that, health care is something that cannot go down. Cloudflare provides a 100% SLA for uptime. So these services are feeling very comfortable in sitting behind Cloudflare. I had the opportunity going back I think it was 2022 when I was working with Melbourne Airport to help them to migrate onto Cloudflare for layer three, layer four DDoS protection. The premise behind this was around an organization called QLDNET or Anonymous Sudan. And they are a pro Russian hacktivist group who targeted Australian entities such as universities, hospitals, and airports. And as a result, like, these these organizations aren't directly affiliated with anything to do with the war, but because the Australian government had provided ammunition and tanks and the like to Ukraine, they saw it as a an opportunity to to come after a critical infrastructure. So they put out a tweet of sorts, I think it was on Telegram, to say that this is something that we're gonna look to do within the next three to four days. So high how's high scale DDoS attacks across all of these different levels of infrastructure. Collaborate provides a service called under attack. So if you do have a current provider that's not performing the way it should be, if you don't have any protection to date, obviously, you know, the it's it's better to go into Cloudflare or someone some sort of provider to have that level of protection going forward. But if you don't have it, you can call us on our under attack, which is a big orange button on our website, and we will help you onboard under an emergency. So we don't look at the commercials or anything like that. We help you out. We get you sorted, and then we work about all that sort of stuff later. Melbourne Airport were able to onboard to us overnight on the back of this news, and we were able to get them all without any impact. And they were very, very good customer of ours going forward today. So just keep that in the back of mind. If there's any time that you are in trouble, we can help out with just a call. Now let's go to our second poll. Vinay, I'll throw it back to you, and we'll just see, you know, what sort of information that you have around your your DDoS capabilities and ability to detect it, really. Okay. Thanks, Steve. Once again, the poll second poll is now live. You will see the poll option in the top right next to the chat. This poll is asking you, do you have the right level of network monitoring to determine if you're experiencing a deal also. It's a simple yes or no question, and I already see a lot of people voting yes, and a few of people are voting no. So we'll keep it all open for a couple more seconds, I think ten more seconds, and then we can take a call. But it looks like more people are voting yes on this one. That's great news. That's great news. Like I said, when you are able to sit in front of your monitoring tools, it's it's definitely gonna be very helpful to find out, you know, what sort of volume of traffic is coming in, if there are any spike in the CPU or memory of your edge devices. Find out exactly what is going on there. But there are many, many different ways that you can monitor for DDoS and aggregate them in a single point. So whether that's something with Cloudflare using NetFlow to send it to us and to monitor, that's something we can really help out with in terms of an on demand protection as well. So I'll I'll talk about those two differences very, very soon. Okay. So this is cutting it very close. Right now, we have received seven votes for yes and six votes for no. So just one word shy of being an equalizer. But, yeah, I think it's it's still going up. Eight votes for yes, six votes for no. So people are feeling quite confident they have, the right level of network monitoring. Okay. Fantastic. That's good to hear. Okay. Let's move on and sort of get into a little bit about the science and actually how it works, this level of data protection from Cloudflare. Cloudflare provides data protection all the way up from, you know, layer three, layer four, up to layer seven. And we make that possible through that single pass architecture and having all of these servers being served from every one of our data centers. When we look at the way that you connect into Cloudflare, we can also take out, you know, the Internet out of the equation in terms of DDoS by providing a direct connect at the physical layer into our kit. So that sort of extends the data to level two as well by running VLANs across these links. But if you are co located in the same data center as Cloudflare, with no additional cost, we will allow you to plug into our network and fundamentally use us as an edge security appliance or service, but kinda like a a device that sits within your own data center. So taking out any latency, any Internet weather to give you guaranteed connection into our network. Once we have this in place, you know, that's that's one mechanism. We could use a GRE or an IPsec tunnel if you want to use a connection over the Internet as well. That's that's completely fine. We are fine with that level of connectivity, whatever suits you, the customer. Then we begin to advertise your networks on your behalf. Spectrum's a product here. When we talk about layer three, layer four data protection as well, that is magic transit, just to be completely clear, and Spectrum is more of a point product for people that don't have slash 24 networks. When we look at the Internet, it is a minimum requirement to be able to advertise a slash 24 network to the outside world. So if you don't have that or just wanna protect a single application, we can do that through Spectrum for layer three, layer four as well. And then, of course, getting up to layer seven with our t s TLS SSL decryption inspection, you know, looking at those capabilities, not just for WAF, but also for web level DDoS attacks. So once we have you connected into Cloudflare, as you can see on the right hand side here, any any method of GRE, IPSec, or CNI, we will begin to advertise those subjects on your behalf via BGP. So you would withdraw any routes that you had, Ben, if it advertised the Internet so that we take that on your behalf. That means when any request is coming through to your public subnet, you would hit that on the Cloudflare Edge. We would inspect that to see if it is any way a layer three, layer four data's attack. We would drop that traffic, if it was, and send the clean traffic through your connection on the right hand side. The way we do this, to put a little bit of good science around this as well, is that we have rules that sit on the edge. In terms of maybe, like, a signature where we look for, you know, things like SIM floods and those sorts of attacks, they're very easy to identify and and block. But when we have, like, a distributed denial of service attack, we take a sample of your traffic. So all of those connections coming through to the Cloudflare edge, we send them to our core data centers. We inspect that and correlate it to look like to see if it is a possible DDoS attack being staged around the outside world. If it is, we would dynamically push a rule to our Edge to block that traffic based on things like source IP addresses, destinations, you know, protocols, ports, all that sort of stuff to to protect you, the customer, and allow your traffic to come through cleanly. Now with that being said, when we have this function in place, so we we know exactly where to route your traffic through to, with just a click of a button, we can use we can elevate this to a layer seven. So providing what we call an orange cloud of your traffic where we decrypt the traffic at layer seven, inspect it, pre encrypt it, and then send it through to your origin. It's very, very simple to implement on Cloudflare once you are connected to layer three and layer four. Inside this as well, you might not have your own slash 24 subnet, and that's completely okay. So you can proxy through Cloudflare just via DNS redirection. When a request comes from a user on the left hand side here on the outside world, which you'll see on our website referred to as an eyeball, we will resolve that with the Cloudflare IP address, receive that connection, provide our Orange Cloud inspection of that, and then send it through to the IP address of the true origin server on the on the right hand side. There are ways we can do this as well to obfuscate that IP address by using Cloudflare tunnel, which will be a tunnel that sits either on your web server or is the bastion within maybe a VPC in public cloud to broker a secure connection to Cloudflare. And once we receive that traffic from the eyeball, we will route that traffic through that tunnel. So if there's any concerns about layer three, layer four, you know, issues on the right hand side here because you're not advertising layer three, layer four because you don't have a slash 24 subnet. We have mechanisms that we can still protect that address space out on the Internet as well. In terms of visibility, it's critical to to understand exactly what's happening on your network and, you know, when you actually are being attacked. So as I said before, not just using traffic that's coming through Cloudflare to give visibility, you can start to send things like NetFlow to Cloudflare Because we have two options for DDoS protection. You can be always on, which is where we're always advertising our subnets, automatically detect and mitigate those attacks in less than three seconds, or on demand, where you sort of work out yourself. You can work out yourself. If you are being attacked, if you do have that good telemetry that fifty percent of people said that they do have just before, you can then, in an on demand situation, advertise those subnets from Cloudflare. We will mitigate the attack. And when that stops, you will stop advertising the subnets, retract them, and advertising yourself again. So you sort of start to go around Cloudflare once you're out of the woods. Another mechanism for that is that if you're sending traffic via NetFlow to Cloudflare, we can set thresholds. So we sort of get a bit of a traffic profile of what is normal, and if there's any spike coming through to Cloudflare with the NetFlow information that you're sent sending to us, we'll start to dynamically advertise those subnets on your behalf, and then you can withdraw them as part of the script or something like that. So there are ways to automate the on demand service even though you're not in an always on capacity. And we look at things like ISPs where it probably wouldn't make sense to put everything through Cloudflare in an always on capacity because then we would fundamentally become the transit provider. ISPs can do this selectively for, you know, particular subnets as they do come under attack. So we are looking at architectures like that as well to not just protect people within enterprises, but also telcos as well. So I I don't ever like to do a webinar without a demo. This is the fun stuff, and I really wanna see everybody get involved here and, you know, enjoy how Cloudflare protects four layers and or layer three, layer four DDoS attacks. So what we will do is quickly kick off a Terraform script, which is going to I'll jump back here. Spin up five virtual machines that are running within GCP. Now, typically, you wouldn't be allowed to stage DDoS attacks from public clouds. You probably get a pretty big slap on the wrist, but we do have permission from Google to do this as part of a demonstration. So the subnet that we are broadcasting here is eight dot twenty four dot eighty seven dot zero slash twenty four. We will originate tech traffic from all of these VMs. So one based in Latin America, one within APAC, and now within EMEA, North and West, as well as The US West as well. And we have a a lowly target on the right hand side here, which is 88.24.87.six. And we've broken that connection to Cloudflare with the GRE tunnel as a method of offering to to Cloudflare. So let's just go back and check on this. We've spun up those instances there. We can see down the bottom, the target IP is at eighty seven dot six. So let's go to the Cloudflare dashboard and see what we can see. For anybody who is unfamiliar, this is the Cloudflare dashboard. And I've clicked into one of my accounts here. And because Magic Transit is a account level function, we will go into networking at the account level and look into our insights, and we'll just look into the network analytics here. The dashboard's gonna provide us a view with all attack traffic over a specific period, as well as clean traffic. So full visibility into what is happening to our network ingress. Over the last twenty four hours, we can see that we have dropped 88 sorry. 1,810,000,000 packets coming into our network, and the mitigating systems is either via DDoS mitigation or TCP protection. And there's been a small amount of traffic that's been allowed to pass with 1,340,000 packets coming through. Just to give us a bit more granularity, I'm gonna change this time frame from the last twenty four hours down to the last thirty minutes, and this is going to put us into fundamentally a live view of what's happening at the network. So really good visibility into this. You don't have to contact any support teams to get this information. And most importantly, we can start to see where the attack's originating from. You gotta keep in mind, while you have an architect in your scrubbing centers, all traffic's being routed to those from multiple countries, so it's very hard to understand where the traffic traffic is originating from if it's only being absorbed there. So some of the analytics we'll see here is that we have two attacks that are currently in play. Given that I only started one, I'm not sure why I'm being attacked from anywhere else, but I guess that's not a bad thing if we mitigate it. The most attack traffic coming through is five gigabytes, and it's mostly coming from Singapore. Drilling down a little bit further, we can start to see a packet sample. So taking a sample of the amount of traffic coming through, and we sample this to give you performance within the dashboard without compromising any level of analytics. So if there's any repeat of events, we won't put them in here because it would become noise, and it would be a poor performance for the dashboard and your purpose of of analyzing the traffic. So what this is telling me here that this particular packet has been dropped. We've seen that it has come from the Singapore Data Center. Now we know that this is coming this attack is coming from Singapore because we are using an Anycast network. You can't route around Singapore to someone like Kuala Lumpur. It is always gonna hit us via BGP routing because of that Internet connectivity and the next hop for those ASNs. To give you a little bit more view into this, we'll have a look at the DDoS manage rules. So these are the automatic Cloudflare rules that are protecting us here, and it's gonna take it a step further to say this type of attack is actually a SYN flood. I've actually sort sort of seen a TCP flags flood as well. So quite a lot of traffic coming through, and it is being dropped. It will also show you with in the ruleset itself, the particular rule that we are hitting and why that is being dropped. So in terms of analysis and definitely, like, a postmortem for these sort of attacks, which would typically happen every DDoS attack within an organization, support teams will band around and try and figure out what happened here. All of this is here, ready to go for you in that level of reporting. TCP protection is an advanced level of protection that we provide as well. So synchronizing around the world as we sort of spoke about the correlation of events being sent through to our data center to understand if it is a distributed denial the secrets denial service attack. And the mitigation reason here was that that TCP state was out of sequence on that particular data center, so we've dropped that traffic. DNS protection as well extends to allow people that want to have a level of protection for their DNS servers, which might sit on premise today behind the public subnets, to prevent things like DNS laundering attacks. There's not a lot of stats here. I'll click back and still speak about it because this is where attackers will send through a reflection attack, which could go through to a DNS server, maybe like Google's or Cloudflares, to say, yeah, I wanna go through to steve.com. Give me a resolution of this name, which could be a b c, then a b c d. It look kind of like an enumeration attack. Well, all of those requests, because the public providers don't know about it, will then forward it onto your DNS servers, fundamentally attacking it. So that level of DNS protection will allow us to sit in front and scrub any volumetric malicious requests coming through to your namespace. And lastly, one of the great things about metatransit as well is that we provide a firewall capability for you to have a firewall at the edge. So anything that you might be doing within the data center today, you can put that out fundamentally have 335 firewalls acting on your behalf by providing rules for IPs, ports, protocols, size of headers, all sorts of things that you could that that that you would wanna protect at the network level, we can do that for you there as well. So geographical blocks, IP addresses, ASNs, anything of that nature that shouldn't be coming through to your network. So just jump back here. Let's see how much traffic we've actually mitigated here. Not very much traffic coming through, just 349,000 packets, but quite a lot being dropped. So quite quite a comprehensive level of analytics that you see from these attacks while you're being protected as well. Now just to wrap up before we get into the q and a, I just want to summarise by saying that DDoS attacks are not going away. They are getting bigger and bigger every year. Know, a 400 increase year on year is absolutely staggering, not just the amount of attacks as well, but the the amount of throughput that's actually being generated by them. 30.1 terabits per second is is quite a scary number. When we look at, you know, just the bot that's sort of being used today, how they're being rented out over the dark web, it's it's quite quite alarming. And, you know, we can only sort of guess what's gonna happen with the rise of AI and how that's gonna affect things like DDoS in the future and how quickly these dot NETs can be spun up, spun down. It could be just yeah. It remains to be seen. But Cloudflare, as a provider, we do have the room to absorb these level of attacks. So before, we have 477 terabits per second. We serve it from over 375 cities around the world, and we we think we are a really good fit for this level or this next next level of DDoS protection. So with that, I'll just say thank you for everybody who has attended today. I hope it's been beneficial. We've had a good look into what we're seeing from Cloudflare in terms of DDoS. And I'll pause here and stop sharing my screen for any questions that we might have. Thank you, Steve. Great presentation. Great demos always. I am not seeing any questions coming into the q and a. In fact, the chat has has just been all me. So I see there are a lot of people joining in today. Encourage all the attendees to leave some questions. I'm sure you might have seen a lot of info, some new stuff, hopefully, from Steve. Please share your questions. Leave them in the q and a box in the top right, and we are here to address them. Maybe we can give them a couple of minutes then we can check back. No problem. Okay. And, Steve, let me just, you know, close this session by thanking you. Thanks for hosting this insightful session. I'm sure all of the attendees were as engaged as I was throughout the presentation. And I on that note, I would also like to thank all the attendees for joining today's session and interacting with us. We are still waiting for questions, but we hope you found today's session relevant and valuable. Hoping to see you at our upcoming webinars. Thank you. Okay. I think we did we do have a question in the q and a. The question says, can we apply geo fencing? Steve, do wanna take that? Yes. Yes, Mitesh. So thank you for asking that question. Yes. You certainly can apply geofencing. That would be done through the magic firewall, which is a component of magic transit. So quite easily to apply rules at a geographical level. As I mentioned before, it's it's, you know, just another tool in your toolkit to to allow you to do that, but geofencing would not block things like these server botnets that we're seeing today that, you know, last for one to two days from an IP address or an ASN and then move to another country. So that's why it's so important to have protection like magic transit in addition to to the firewall. Alright. There you have it. We got one more from Rohit. He's asking how much rate limiting protects from DDoS. Yeah. So so in terms of rate limiting, we can provide rate limits. We when you onboard with Cloudflare as well, we will look to see if there's any anomalous traffic, like you might have a particular endpoint that they could be using you could be using for your Zero Trust solution that we need to be aware of. There's a spike in traffic there. We would, you know, build a profile around that so we don't take any automated actions. You can, of course, set rate limiting within Cloudflare itself, but we would largely rely upon the detections that are built into the managed rule sets and the TCP advanced protection to to provide that automated capability. Okay. I hope that answered your question, Rohit. There's one more coming in from Mitesh. He says, can we have filter parameters that can be applied? If I think that's relating to layer three, layer four questions, Mitesh, yes. Yes. You can. So you can look at source IPs, destination IPs, you know, size of packets, ports, protocols, source addresses. Very, very extensive of that, all of the the different layer three, layer four filters that you can put in place. Sorry. I'll rephrase that question. If that is in terms of looking for the analytics, yes. Yes. You can do that too. You can filter on the graphs that we saw before based on those parameters. Okay. Great. I think Roy has a follow-up. WAF is important even if we have network level protection. Is that a follow-up question, or it's just making a statement? Not sure? I I certainly agree with that, Roy. So when you are proxying cloud through Cloudflare related to your layer four, we can quite easily turn that on. So that's when we orange cloud the record, as I mentioned before, where we start to provide light serving capabilities such as WAF, CDN, and rate limiting at that level. Alright. I think with that, we have addressed all the questions. We are still here. If anyone wants to ask questions, we have Steve, you know, addressing them all of all of it right away. So let us know. Yeah. Looking at the q and a. I still see there's, more than a handful of people, live, still tuned in. Let's wait for a couple minutes, and then maybe if there are no more questions, we can close this. Okay. Steve, I don't I don't see any questions. I feel that's about it. Maybe it's a good process session. Maybe any last words? I think when we're looking for things like layer layer three, layer four, DDoS protection, I think, like I said, Cloudflare is perfectly placed to deal with these large scale attacks. 30.1 is is critically high, and who knows what's gonna be coming next. Okay. I think that statement of yours sparked some questions. There's a new question coming in from Prakash. Does Cloudflare integrate with other firewalls? Interesting. No. We don't. We don't because we provide that protection at the edge. You can, of course, replicate your policies across to Cloudflare, but it's it's something we provide as a service on a grander scale than a firewall. Thanks, Prakash, for asking the question. Okay. If there's nothing else, thank you again so much for joining this session. Hope everyone found today's session relevant and valuable. With that okay. I take my words back. Another question. How how do Cloudflare detecting bot DDoS attacks? Okay. I'm a little confused. I think what the person wants to ask is how does Cloudflare detect bot in a DDoS attack? So there's a couple of different ways we do that. So, like I said, we we have signatures that sit at the edge to look for anomalies in the protocols as they've been sent through to Cloudflare, like Christian security attacks where, like, all of the headers are set to on fundamentally to try and exhaust resources on network devices. For anything that is a distributed attack, we will take a sample and send it back to our centralized data centers in The US and Europe and correlate that and then send out a signature to block that traffic if it is. If we're looking at, like, seven DDoS attacks coming from bots, we take a different effect on that. So we use a product called bot management, and, excuse me, that will start to look at the source of the application making the connection to us. So there's ways that we can fingerprint that, such as j a four fingerprints, which, you know, fundamentally looks at the the TLS handshake coming through from the application itself. We've identified what type of automated source it is and, you know, build that into what we call a scoring system to save the likelihood of that traffic being automated using our machine learning models, taking action on that, whether we challenge it, whether we block it, or we log that traffic. There is different mechanisms that we use to detect botnets and bot attacks. Okay. I hope that answered your question, Peter. Please excuse me if I'm pronouncing your name wrong. But if there are no more questions, I have launched a quick survey for all the attendees who are still here. Please feel free to leave feedback, share comments, let us know how we did, and is there anything that we cannot improve on. We will be going through all the feedback later today. And with that, thank you for joining, and hopefully, this will on the next one. Thank you, Steve. Thank you. Thank you, everybody, for your time.