Replay: A NetOps guide to DDoS defense

So hello, and thank you for joining today's webinar. I'm Jordan Sloot from Kentik Marketing. Our topic for today is the NetOps Guide to DDoS Defense. Our presenters are Doug Madory, Kentik's head of Internet Analysis, and Amit Nayik, Cloudflare's cybersecurity evangelist. So in today's webinar, Doug and Amit will discuss the latest DDoS attack trends and how to ensure effective DDoS mitigations and also why observability is critical to DDoS defense in twenty twenty two. So during the webinar, if you have any questions, feel free to enter them in the Zoom chat, and we will answer all them in the q and a session at the end of the presentation. So with that, I'll pass it on to Steve Gervasi, our host from Kentik Marketing. Hi, everyone. Greetings from San Diego. Today, we're talking about all things DDoS, and here's what we'll be covering. We'll be sure to leave plenty of time for q and a at the end, so you can either put those in the messaging. If you have any immediate on topic questions, we'll try and get to them as you ask them. So here's basically what we'll be going through. We'll Amit from Cloudflare is gonna give us an overview of the DDoS threat landscape as Cloudflare sees it. Then Doug's gonna jump into some of the importance of BGP and why it's important to monitor BGP especially with respect to DDoS mitigation. And I'll give a quick summary of a post we recently did on the Kentik blog in terms of why observability is critical for DDoS defense, and then Q and A at the end. So that's what we intend to cover. Thanks for joining us, Amit, on Cloudflare. He'll also give a bit of a introduction to how Kentik and Cloudflare integrate. So with that being said, over to Amit. Thank you, Steve and Doug, and thank you for having me. It's always a pleasure to join you guys and talk about DDoS. But before we jump into that, I just wanna kind of give a little bit of context and do what information we're gonna be sharing today. So as many of you know, Cloudflare operates one of the largest networks on the Internet right now, spans over two seventy five cities across the globe. And one of the things we do really well is protect websites and network infrastructure against DDoS attacks. And as a result of having, you know, millions of websites on running on our platform where chances are if there is a threat out there, if there's a botnet out there, we we're in a position to where we can see it and we can learn from it, and we can we can inform the community and and share that knowledge. And one of the ways we do that on a consistent basis is with our quarterly DDoS trends report. You'll find that in our blog. We also do a webinar deep dive into the trends that we find every quarter. But I wanted to today just share a few quick highlights from the Q2 report. Now this is sort of looking back at sort of Q2 of this year and the data that we found. We will have our next q three report coming out momentarily, probably closer to the end of October. So stay tuned for that in our blog. But now when we think of DDoS, and sort of trying to make sense of like, what is the problem right now? Who are the actors? What types of attacks are we seeing? And if you just take a look at the vast majority of network goods DDoS that we stopped, over fifty percent of that is still the syntax, right? That's still a lot of noisy volumetric traffic. And, you know, we we see trends sort of go up and down over the quarters, but in q two special especially, we saw about fifty percent of traffic where it was SYN attacks. One of the things we keep an eye on is to see how some of these as other attack techniques are trending over time, right? Like Memcached has been used in the past for amplification attacks. That's gone up significantly from q one to q two. Ubiquiti attacks on Ubiquiti systems have has increased significantly as well. And oftentimes when we see this, we see it in a in a sort of a either a new botnet or a new tool that that gets floated in the community that uses one of these vulnerabilities that anybody can easily use to launch these Amplify attacks. And that's one of the trends that we're catching in Q2 of this year. And we'll continue to monitor this to see how this evolves into Q3. But as we go into kind of one of the other topics that's really top of mind for a lot of folks is, what's going on over in Eastern Europe and Russia and Ukraine. Right? We saw In the beginning of the year, we saw groundwork get launched and unfortunate sort of consequences to lives and property and all sorts of issues. But one of the things one of the elements of this conflict is a cyber war. And one of the ways it manifests is in the form of DDoS attacks. And we were saw started seeing a trend in our q two data in our q one data about, what types of industries and organizations are getting targeted. Right? And one of the things we saw is within Ukraine, we see broadcast media and online media organizations targeted a lot. And this is probably one of tactics is to cripple access to good information. And that's probably what we're seeing here. We also saw similar trends in Q1 within Russia, but that has shifted a little bit. So in q one, we saw one of the top target names Russia as well was online media, broadcast media. And across could have been domestic, could have been counter attacks, we're not sure. But that has shifted a little bit. We're seeing more of banking and financial services and insurance organizations targeted presumably sort of these are critical infrastructure organizations as well within within Russia and Ukraine. So that's what's happening out there. And and I'm sure I don't know. Doug has a lot of data on this as well. And and we're keeping an eye on the situation to to see how as it evolves and and changes in intensity and frequency. But the other big thing I think about when I think of DDoS is ransomware. We don't now typically associate ransomware directly with DDoS. Ransomware attacks typically sort of involve some kind of breach of an enterprise system using phishing, using compromised credentials, and then sort of bilateral movement and some sort of, you know, encryption or locking down of data in exchange for ransom. But there's also another related class of attacks, which is ransom DDoS attacks. And they often occur in isolation or in conjunction with ransomware attacks. And what's interesting about ransom DDoS attacks is they don't they don't require any privilege access to any systems. They can target anything that's that's intentionally open on the Internet. Right? So whether it'd be VoIP infrastructure and you have some SIP ports that are sitting out on the Internet, those could be targeted. Websites, web applications, API endpoints, anything that's open by design can be targeted by ransom DDoS attacks. It can even just be your, you know, your corporate network, your headquarters building that could be targeted. And we've seen all of these flavors of ransom DDoS attacks, but this is another area where we keep an eye on how things are evolving. And one of the things we do at Cloudflare is when we do send a DDoS alert to customers, there is actually a link to a survey. And where we ask them some questions about, hey, were you did you receive a ransom note in conjunction with this attack? And that gives us an interesting data point into how many of these DDoS attacks are actually ransomware or or ransom DDoS. And what we saw is in the beginning of the year, and q four was was a busy period for these types of attacks, and q one declined substantially. Not sure why. The cyber war in Eastern Europe might have been sort of where some resources got redirected. Is it e commerce related, do you think of me? I mean, seems to be obviously, fourth quarter is a critical time for e commerce and maybe that's when people are most vulnerable because so much of their revenue is at stake. Do you think that could be a cause of why there's such an increase in ransomware attacks in the fourth quarter? Yeah. Yeah. So so yeah. So last year was a big year in general for ransom activity. We saw a number a number of attacks, we saw organizations being successful at them. Right? And that sort of emboldened them. And I think in q four, it it reached some bit of a crescendo. Just in and the the confidence levels went up, the the availability of tools went up, and it reached a bit of a crescendo. In q one, what I think happened was probably a little bit of diversion of resources and botnets to to other purposes and and sort of the the cyber warfare situation in Eastern Europe took a lot of the the the attention and sort of resources out of launching ransom DDoS attacks. But we've seen them come back in around June of this year. So there's a organized gang also labeled we call them Fancy Lazarus. They have they're pretty active last year. We saw them go a little bit quiet in Q1, but they came back starting around June of of this year. And we saw an increase in number of activities and ransom notes from from this organization. So we're seeing that uptick. We'll continue to monitor this and see how it trends to q three and q four. But, you know, again, the the takeaway from this is if you have resources that are open to the Internet that are critical, think about how you're gonna protect them. So if if I were to sort of sum up what we're seeing here, right, what are my key takeaways and trends that that they can distill from the from this information right now? So a vast majority of DDoS attacks are still access cyber vandalism. They're not intentioned and they're not directed, but they are still powerful and they can still cause significant damage. We do see sophisticated, well funded attacks that they come in, they're targeted, they're they're typically using some available botnets. And these do happen. They're not that common, but they're they're they're out there. The tools are out there. The resources and the groups and the people are out there. And then we're seeing so going back to the earlier slide, we're seeing all the SYN attacks. Right? Those are typically reconnaissance. They're trying to learn weak points in a network to figure out where where your breaking point is. And learning a network topology, identifying points of entry that were damage to be caused when you do wanna later do an intention attack. So that's a general summary of what we're seeing. So just a little bit about how we go about solving this problem. So the Cloudflare approach to this is a network based approach. So using our modern network architecture with our global edge, Our edge capacity keep keeps growing up. Now, it's about a hundred and fifty five terabits per second, which is, you know, large enough to withstand the biggest volumetric attacks. We do all the DDoS filtering on the edge of the network, so that gives us sort of a tremendous advantage in terms of resources. Right? We don't follow a scrubbing center architecture where, you know, we have these every every CloudFront data center is able to take in and stop and filter, detect, and stop VDoS attacks. And that's a big advantage when you're dealing with unknown threats. And the other thing is that the whole system is kind of autonomous and it can it doesn't need a lot of tuning. It learns from your traffic patterns. We just announced a couple of things this week, like our adaptive DDoS protection, where it actually learns customer traffic patterns. And for most network based attacks, like the syntax you saw, can mitigate this in under three seconds. And we're really excited though about our partnership with Kentik, and how we do this together. So this is sort of a general look into how DDoS mitigation works with Cloudflare and how Kentik can help make that better. So typically you'd have a network infrastructure, either data center or an office, which with the edge router facing it connected to an Internet service provider. Right? When you're getting traffic in through your service provider from all of the Internet, most of it is legitimate, some of it may not be, some of it may be unwanted. And in normal course of our operation, your traffic may take you just go through your ISP and your network. That's this is what we call on demand DDoS mitigation. When the way Magic Transit works, software Magic Transit works, which is a network based DDoS mitigation product, is it actually announces your prefixes to the Internet. And the Internet now starts thinking that, hey. The best way to get to your network is through Cloudflare and start sending all the traffic to Cloudflare. And when that happens, Cloudflare is now able to receive all your traffic all over the internet and learn from it, find the DDoS attack patterns, implement all of our shared knowledge filters across the edge of the Cloudflare networks. And then it sends clean traffic over to your EdgeRoute. So all of the the unwanted traffic gets filtered out even before it gets anywhere close to your router. Now the key thing here is what is that trigger that's gonna tell Cloudflare to start announcing those routes? Right? So how do you know when you wanna start DDoS mitigation? So this is where the Kentik solution comes in. The Kentik platform can collect flow data from all of your routers, your edge routers, and start building, understanding the traffic patterns, and understanding what good looks like, what baseline looks like. And then Kentik has your own DDoS detection engine, which is really good at detecting when when when traffic patterns go out of profile and suspects a DDoS attack. When that happens, Kentik can make an API call into Cloudflare. Cloudflare starts advertising the routes and adjusting the traffic, And and then we filter out all the DDoS attack, all the attack traffic at the Cloudflare edge and send only clean traffic on on your network. And this is sort of an exciting solution where you can use on demand DDoS mitigation with deep network visibility. And one of the questions I often get as well, how quickly does this activate? And Doug's gonna share a little more bit more information on kinda how all of that works. And I'm gonna hand it off to to Doug. Thanks, Amit. Right. So my name is Doug Madory. I'm from Kentik, and for the last thirteen years, I've been an analyst on looking at BGP mishaps and how how BGP works. That's kind of my central area of expertise, and so I'm gonna talk a little bit about how, you know, the BGP component to what Amit was describing, and how sometimes that doesn't go go well. So as as has been mentioned, you know, we have this one BGP v four, one instance of one protocol handling how Internet traffic gets from one point to another on the Internet. It's kind of a remarkable thing. And this is also used by, as Amit went through, DOS mitigation vendors to redirect attack traffic, either to scrubbing centers or to, in the case of Cloudflare, to the edge, the vast edge of Cloudflare, so that they can handle far greater, larger sizes of attacks. I thought I might just begin with a quick anecdote of the history here of how this got started. So for those of you that aren't familiar with this or this book, fatal system error, tells a story of the origination of just this line of business around DDoS mitigation. Specifically, started with the at the time and over twenty years ago, sports betting was illegal in the United States. So you had to go use online websites and overseas offshore operations to do so. It was kind of a wild west. These entities would attack each other with DDoS to try to gain a commercial advantage, and one of those was this outfit called Bet Chris out of Costa Rica who hired Barrett Lion to build Prolexic to defend their their service, ended up being very successful. It's still, you know, this technique and technology is still in use today. And like I said, it's covered in this book. So BetCris itself has got a bit of a checkered past. If you Google BetCris and indictment, there's a lot of results that you'll find. And I was working with the New York Times in twenty fifteen on a series that was going investigating all this offshore gambling that was, you know, working for the operating in the United States in the series called wired for profit. And in the course of that, they want to go look at who is providing service for these various entities. One was Bechrys. At the time, Forelexic had been acquired by Akamai, so they went to Akamai. Akamai confirmed that they were they didn't realize they were still providing services. And so they pulled the plug, and then when the the New York Times reporters got that word, and they called me, and I was able to confirm that they were they were down. So kind of a wild thing, but those that operation continues very, very profitable for that for those folks. So let me get into the technical stuff. Right? So we mentioned Amit touched on this of just these there's a couple different styles mitigate DDoS mitigation, there's always on, we just leave it on, and so basically the DDoS mitigation provider is your transit provider handling all your traffic. There's a greater expense because you're asking it to do more for you, it's always on. In order to, you know, save on costs, and there's the alternative flavor of on demand, where there has to be this very fluid BGP change in order to redirect the traffic to the through some sort of a filtering mechanism. This on demand scenario is essentially what a meet went through. You know, we're using these. We aren't Kentik is the first to use NetFlow. I think most people have been using NetFlow to to identify the traffic that needs to be filtered for a long time. I think the the part that, as someone who's been watching, BGP for a long time, the part that I think is lesser understood is just how what are the issues that come up in the world of BGP? Basically, same things that are problematic in every other part of BGP can be problematic for DDoS mitigations. And those include, you know, in scenarios where routes are getting filtered. There are now the RPKI is having a lot more adoption these days. There's a lot more misconfigured ROAs. So a ROA, if you if the entity is announcing the address base from its from its own AS, so if the vendor is now gonna have to announce something, then that AS needs to be in the ROA. It's not always the case. This is an example I found yesterday. I can find this at any given day of people who haven't configured the ROAAs to allow the DDoS mitigation vendor to announce the address space, and so therefore this this route's getting filtered and based on analysis I published earlier this month, that can affect propagation. It might cut your propagation in a half or two thirds. So what I'm talking about is like your route now will now reach, know, potentially two thirds of the Internet as a result of this misconfiguration. So that's that's one scenario, but I think to sidestep that, I think what you'll find in BGP based DDoS mitigation activations, is that the vast majority of cases the vendor shows up as an upstream. I think this is partly just to sidestep any of the issues with filtering that come up with trying to change origins. So, the origin stays intact, the vendor appears as an upstream like a new transit provider, and so then the scenario that's problematic is that the upstream, and we'll look at a couple examples of this. If the previous upstream doesn't stop announcing the route and the vendor starts announcing, the mitigation vendor starts announcing, then you end up with this contention where the two entities are both fighting for who is it that controls the address space and this weakens the DDoS, the mitigation. So maybe if we go to the next slide. This was one that I had captured a while back. We kind of denuded who are the actual companies involved here, but, you know, I could find these I wouldn't say that most of these, these are these are there's a minority of cases that fit this pattern, but but they exist, and I don't know that folks have got great tools, and this is why we built this this visualization on the left where what you're looking at is this kind of a stack plot, the bar there, we're looking at who we're looking upstream from the origin. So who from all the BGP sources that we've got, what do they go through to who they traverse to get to the target network? Well, normally, in this case, there's just one upstream, and then at some point, they're activating we can see that they're activating a DDoS mitigation. One of the known vendors appears as an upstream, but it's not a hundred percent. And then we'll maybe the next slide, we'll have the example of what it's supposed to look like, but in this case yeah. This is what it's supposed to look like. We'll go back. Steve, will you go back for a second? Thanks. The so if they only if the DDoS mitigation route version of the route only, you know, gets accepted by half the Internet, the rest of the Internet is not seeing it and is and that traffic is continuing to to go hit the the target network. The fact that we are at a Kentik is a NetFlow analysis was born as a NetFlow analysis company means I've we've got a lot of NetFlow to to use on top of the BGP stuff. And so a lot of these attacks we can see in our net flow, our aggregate net flow from from customer data and see, like, this case, we could see the we could see the attack crossing, you know, the telecoms that that work with us and hitting its network, and we could see the portion that was redirected through this mitigation, which was just a minority. So this one, we would think is a we would call this this is the outcome of an incomplete DDoS mitigation. Alright, Steve. If you go to the next one. So in this case, this is a this actually does have the the companies here. This is a a Cloudflare activation. And so these this change in colors of this of this bar chart in the in the center going from green was the previous upstream of GTT, switches over to Cloudflare, you know, the the slope of that edge going from green to purple in this case, is the speed at which BGP propagation takes place. And it's within about two minutes or so, you should be able to achieve global some sort of global propagation of the of the new route. This requires, in this case, you keep to stop announcing it, and a clockwork to announce it at the same time. A handoff needs to happen, and then at some point, it gets turned off. Usually, this turn off period is, you know, that the speed or the slope of that line is less important. Usually, the when this is getting activated, you're under attack, and you need to get that going as soon as possible. Steve, would you go to the next slide? So there's a lot of examples out there that look a little like this. So in this case, you've got the Children's Medical Center of Dallas, an instance that happened in April that we got involved in where they're activating, in this case, Prolexic. Any vendor would have scenarios like this, so I am kind of picking on somebody here, but this this activation never achieves a hundred percent coverage, and so because in a dDoS scenario, you can't predict where the traffic is coming from. It's going to come from all kinds of different parts of the Internet, routing. There's some vagaries you can't predict. You can be sure that it's going to come through one transit provider versus another, which is why you need to have just a hundred percent coverage. And so if any time there's an activation that doesn't achieve a hundred percent coverage, you're leaving a door open for the attack traffic to end up hitting the network. And there's a few different things that can ways that can this can this can it's gonna happen. You've got multiple players involved. You've got the customer, you've got the old upstreams, you got the new mitigation vendor, any any breakdown in the coordination between those three parties can lead to an issue. This isn't we don't know who was at fault here, what was the configuration problem, But I know that in the years past, we would have people coming to us, this is back in my RENASIS days, knowing that we're BGP experts and ask them to study, you know, why do these activations take so long or why are they ineffective? And we'd come up with we'd see scenarios like this where the routes are just not achieving, you know, complete coverage, and people didn't have, and I think they still don't have great tools to analyze this very quickly. So that's again, a motivation for me when I came to Kentik, like, got to build something like this so that we can can look when they push the button to activate or it's automated a lot of times. You'd like to know, did this happen quickly? Did we get a hundred percent coverage? Am I getting what I what I'm paying for is is, you know, the bottom line? And and if if not, then you gotta start figuring out what what went wrong. So Doug Yeah. That there can be check there can be problems on both sides. Right? It's not just necessarily the it could be the mitigation vendor in some instances, but it could also be the customer. Right? Yeah. That's good. That's that's exactly right. I mean, you could be a filter it could be a filtering thing. Maybe you didn't add the the mitigation in the event of an origination, this is an upstream, but then they get the origination, if you didn't add the mitigation vendor to your ROAA, then the Internet's gonna start filtering out mitigation vendor. I mean, there's there's there's lots of different anytime you have multiple things moving, somebody can make a mistake in some of them, and it's not automatic that this is the vendor's fault. But it's but you have to kinda start somewhere to understand that this is this is not how it's supposed to look, and then go start investigating why is that the case. So so, Doug, these are really good charts because one of the questions I get off asked often by customers, like, how quickly does it activate? Right? And and that's I I think if you go back to the previous slide, I think the key takeaway is it's not a it's not a straight line. It's a it's there's some slope. I mean, vast majority of it activates in a good day. Like, vast majority of it activates fairly quickly in a matter of minutes, like, couple minutes. But then you still have a little bit of this long tail, which, you know, with the rest of the Internet. The far corners of the Internet catches up and learns in new routes. That's just yeah. This is the realities of BGP, you know, as I we've mentioned in a previous conversation. This is kind of we start getting into how this the the kind of fluid dynamics of BGP, you realize this is this is more like a wooden Rube Goldberg machine versus, you know, we're used to like in computer science really binary things. This is like a fluid thing, but yeah, it's it takes time to propagate. Usually within a within a couple minutes, you should be at a hundred percent. Anything longer than that, there's a problem, and I think this is I've had a lot of success when this style of analysis to find those cases. Sometimes people have activations that takes fifteen minutes to achieve a full coverage. That's not good, and you got to get started on figuring out who's who's at fault here or what's what needs to be cleaned up because this coordination between those three parties is not working. But it should be this is this one is this is it should look like this on the on demand side. So, Doug, when it comes to DDoS mitigations and BGP, Does RPKI sorry, RPKI compliance complicate things, or does it make it easier? How how is this impacted by whether you're, enforcing RPKI compliance routes? So in this case so RPKI, there's two sides. There's the you create a ROAA that's you're just basically telling the Internet what is the ground truth of my routes, who should announce it, what's the prefix length. And then the other side is you dropping, is your routers dropping invalid. Second part is not as important in this scenario as getting the ROAA right, where you're telling the Internet what's ground truth. Because if you get that wrong, you can create a self inflicted DDoS attack or maybe not DDoS, a DoS attack. You're denying yourself-service if you mess up your ROAA. That's true whether it's this scenario, DDoS scenario or not. That's always true. But, like, as I mentioned, I think a lot of a lot of the mitigation vendors now are trying to sidestep the whole this whole issue by appearing as an upstream origin versus originating themselves. They do originate themselves, and in those cases, you've got to have the DDoS mitigation ASN in the ROAA, which you're allowed to have multiple ASNs as legitimate valid origins in a ROAA. I think that as people are getting used to the whole RPKI ROV technology, think some not everybody knows that. You can have multiple legitimate origins, and if you're using a mitigation vendor, you might want to add your mitigation vendor AS to your ROAs, so that they don't get filtered in the event that they originate your address space. But like I said, a lot of it ends up just showing up as upstreams. And when it is, when it's upstream, it does it doesn't it the whole RPI ROV thing goes away because it's okay. Okay. So before we leave that topic, does anyone have any questions on BGP and DDoS mitigations? Jordan, did any come in? No. Not so far. K. So thanks, Doug. We'll leave that topic, and I just wanna highlight a few points. Kentik is the network observability company. It's what we're focused on. We just published a blog why network observability is critical to DDoS defense. And here's the eight reasons we came up with. Now I think early detection, everyone realizes is critical. It'll save you time. Money and frustration if you can catch the attack early. Real time and historic net flow data analysis will alert you to anomalies as soon as they occur. The next reason is, you know, picking up low volume attacks, which are often used to mask security breaches. Think Amit was talking about earlier, there's a lot of low volume attacks out there just testing your network. So it's really important to baseline against small traffic volumes, which will enable you to fine tune your thresholds and your alerts accordingly. Another reason why network observability is critical for DDoS is that you can identify traffic from unusual sources, such as geography. A lot originate from countries that you may not be used to doing business with, and so observability solution will alert you to that. Also, you know, it allows you to understand the attacks in context. SNMP data is not enough. You know, flow data gives you the ability to understand the attack in context. It gives you details on where the attack is coming from, as well as what IP addresses, ports, or protocols make up the attack. If you know this, you can then be more intelligent about your future filters that you put in place. It also gives you the ability to perform attack forensics. A good network observability solution will able to look back in time to understand, have you seen this attack before? Are there patterns emerging? How can this be prevented altogether in future? So the other really important thing is eliminating false positives. You don't want to be the guy who the script cries wolf all the time. Your IT security staff will get sick of responding to your alarms about DDoS attacks if you're not eliminating false positives, and a network observability solution gives you the ability to do that. And one of the critical things is controlling costs. You know, with ninety five five pricing models in many instances that people have the bandwidth, DDoS attacks can cause havoc with those with those pricing models. So getting controlling the attack early can be critical for keeping your costs under control. A network observability solution will allow you to do that. And I think you all understand, Doug just went through determining the effectiveness of mitigations, which an observability solution can bring to you as well. So there are the eight reasons. There's the blog post. I think everyone here will get a copy of a guide we just published, which will come with the sign up to the webinar on this topic and goes into a lot more detail. But this is what Kentik Kube focused on, giving you the ability to answer any question about your network. And that's what our solution is aimed to accomplish. So there's some references here, that blog post I just mentioned. If you are after more information on Cloudflare and their DDoS offering, you can get it at that URL. There's some explanation about our synthetics product. Synthetics is actually artificial test traffic that you send to monitor your network proactively. There's a blog post about why you should be monitoring BGP and what information Kentik Synthetics can give you on BGP monitoring. And also there's Doug's in that analysis page. All his analysis is aggregated on one page and it's available there. I think it just got a facelift, so go and have a look and see all Doug's content that's there. Yeah. Here's the guide. You'll be sent. So you get that. Open up. Take a read. We love your feedback. But that's what that guide covers when you get that in your email if you haven't got it already. And Time for any questions. Have any come through, Jordan? See. No, not so far. But if anyone has questions that they'd like to ask, please, this is the time to do so. Or, know, Steve and me and Doug, if there's any main points you wanna hit home, also go for it. Give me a few more seconds. I think a meet would back me up on this that there's, this is not a problem that's going away anytime soon. Unfortunately, this is gonna be with us for a while. So, this is gonna be part of your network strategy. How to stay yourself online. You gotta have some sort of As long as you're directed to the Internet, you're gonna have traffic you don't want. Right? And someone can overwhelm you. This is everyone's Twitter handles if you need to reach out. Thank you everyone for attending. If there's no questions, I do see two questions in the q and a. Have they been addressed? No, I don't think so. So let's see. The first one, these might be for you, Amit, approximate cost differentials between on demand and all the time DDoS protection. Yeah. Yeah. So so again, we're happy to to talk about your specific needs and give Scott a call. But I think in addition to the cost, one of the things you need to consider is sort of how your traffic behaves. Right? So when it's coming through a DDoS mitigation provider, it's the it's not going through your transit provider all the time. And, you know, you may wanna do certain things like traffic control through your ISP that you may not be able to do because you're now sending it all through the DDoS mitigation provider. Right? So that's another factor to consider. And and the other thing to consider between on demand and and all the time is like, sort of how quickly are we able to react to it. If you set up the automation using a platform like Kentik, with the automatic mitigation triggers, then the system can react pretty quickly, and then the Internet can, you know, a good day, most learn in a couple of minutes and start diverting in traffic. But sometimes like duck share, it doesn't work right for various reasons. And then that peer in that window of time, that attack might go away or it might you may not have the evidence to go do any triage on it. So that's something else to keep in mind. And the second question, is it based on user count or some so the way we do it is it's there's no user count, but it's typically based on bandwidth, the ninety fifth percentile bandwidth, and then the number of prefixes that you need to advertise. And if Cloudflare starts announcing our prefixes, is it safe to assume they start carrying all of our IP trends that during the attack? Yes. That that's what would happen. Another question here. How do you ensure compliance of national security in terms of information leakage, if any? So this is this is a broad question. I'm wondering what aspect of national security you're you're thinking about or or what types of information. Again, reach out to us, ping you on on Twitter or online or me at Cloudflare, and happy to chat directly about this. Okay. If there's no further questions, we'll wrap it up. Thank you everyone for attending. Really appreciate it. And you have our contact addresses there on Twitter if you need any further questions answered. Thank you. Anything further, Jordan? No. Was just about to say, you know, we would just like to thank Amit and all of you for joining us today. You know, we've covered a lot of material. This webinar was recorded, so you can review a replay of it on our website, that's Kentik dot com, and please share it with your interested colleagues. In the next couple of days, you will get an email from us as well so you can review the content, get a link to the recording, and get any other additional information if you'd like. So thanks again for joining, and we hope to see you all again soon. Thanks, Amit. Thanks for joining. Thanks, Doug. Thanks for having me.