Fighting DDoS at the Source

Hello, everyone, and thank you for joining this webinar, Fighting DDoS at the Source in collaboration between Capacity Media. Kentik and Colgent Communications. My name is Safmalik. I'm a senior reporter at capacity media, and I'll be hosting a webinar. I'd like to introduce Doug Madory, director of internet analysis at Kentik, and Aaron Weintraub, principal engineer at Cogent Communications. During the first part of the webinar, Doug and Aaron will explain how organizations can identify customer networks sending the spoof traffic that leads to DDOS attacks. You will learn what spoof traffic is and how it contributes to attacks. How Netflot analytics can police networks from spoof traffic and finally Doug will offer some advice for addressing customer networks sending smooth traffic. We'll then have time for a fifteen minute q and a at the end, so please send questions throughout the webinar. There's no such thing as a stupid question. In the unlikely event that you experience any technical difficulties, please just refresh your window and this should correct it. I'll now hand over to Doug Madory from Kentik. Great. Thanks. You bring up our slide here. As as Seth mentioned, my name is Doug Madory, and the director of Internet now Sechentic. And with me is my old friend, Aaron Weintraeb, the principal engineer, Cogent Communications, and we're gonna give you a talk today. About using Kentik to fight DDoS at the source. So let's dive into it. So as you are likely, familiar, the DDoS attacks continue to plague the internet. They happen many times every day of various types And every few weeks, we find a novel new way to do a DDoS attack. It is a ongoing problem that has affected, that affects, just about every entity that has, internet connectivity. One of the most common forms of DDoS attacks is a reflection attack. We'll talk about that in a minute. So this is a type of attack that takes the advantage of a stateless protocol. By sending, connections to many, internet connection connected devices And, usually, making use of, like, NTP or DNS, some kind of a a UDP protocol that doesn't have a three way handshake and spoofing the source address, as depicted in the diagram on the right. In order to make all those devices send traffic to the victim, which was the spoof IP. So, this is a this type of attack takes place. Like I said, many times, every day. It is also one that there are some ways that we can try to to fight it. Yeah, as you mentioned, this is a protocol, typically, although there are ways to use, people have come up with ways to do TCP, the types of reflection attacks. There is a lot of innovation in the space. In fact, that's led to you know, this, whole industry of of, DDoS, for higher services, as well as DDoS mitigation, vendors. And, there is a lot of money involved because this is a a a common problem. And so how do we address this problem? And specifically, we're talking about reflection attacks. So there is, you know, we can try to secure all those internet connected devices. If they weren't answering, these types of UDP queries from the internet, then they wouldn't be able to be they will be tricked into sending, traffic onto a, a victim. Unfortunately, you know, achieving some kind of, security, for all interconnected devices is, unlikely anytime soon. We try to do our best there. There are some devices, sometimes, like, DNS servers, things that, due to the nature of what they do, they have to answer queries from the internet. Now everything is like that. We could be a lot better in that space, but, that's that's one one area to attack this problem. The other is implementing BCP thirty eight. So it's best kind of practice thirty eight. This is a it was points to an RRC, or a couple of RFCs that specify how to identify spoofed traffic so that, networks can drop this, again. So it's not the source of DDoS attacks. BCP specifies how one might determine, if traffic is coming from a a spoof source. By identifying, the source address of the traffic as it comes in off a interface to a router. If that router would not have sent traffic back through that interface to that, that customer network. If it was a customer network, if it because of the the routes that it would forward to the interface. It would be determined that that is spoof traffic. It's not a foolproof, system. There are. So there's a there's a a couple of issues there. Not all networks have implemented BCP thirty eight. Probably the biggest issue is just lack of awareness, lack of motivation. There is there are some corner cases where it does, put some could potentially put some traffic at risk, you blocking legitimate traffic in the event that there's some sort of asymmetric routing going on between to transit providers. But, I would I would guess if if maybe there's a study, but most most the lack of CP thirty eight is just simply. So people just haven't done it. But, so this is a this is a an issue we've got. You know, we can't we can't secure all the all the, UDP servers, interconnected devices of the world anytime soon. Still got a lot of networks that still have implemented BC thirty eight. So they are sending, spoof traffic. So cogent Given that it is one of the largest backbone carriers of the internet is in a unique place to both be, have the opportunity to, well, a lot of this traffic has to cross its network. So it's in a p great position to identify and try to remediate some of it certainly within its customer cone, traffic that's, that's spoofed. So, that's what we're gonna talk about today. That's why Aaron's on this, on this webinar. And a lot, a great way to get at this is to look at, Netflow and using, Kentik, which is, known for its Netflow analytics. If we look at Kentik's data explorer, we can identify spoof traffic fairly easily, and allow a customer to, sorry, allow a a user of Kentik to identify, spoof traffic and remediate that with their, their customer. So, I'll I'll I'll hand it off, in a minute here to, Aaron, but just the methodology boils down to two steps, and we're gonna walk through some of the some screenshots of of, Aaron's workflow. Are he's gonna take you through that? But, basically, there's two steps. You have step one where you're just trying to find spikes of packets from customer networks They're going to a large set of unique destination. IP addresses using commonly abused UEP ports. That's a pretty good first indicator. That you've got, someone who's launching DDoS attacks off of your, out of your network or your your customer's network, that alone doesn't there are there are possible, benign explanations for that, kind of scenario. But then step two is then when you drill into those candidates, if you're aware of the what are the source, IPs and what are the source ASs, autonomous systems for those IPs, it typically, jump out at you that this is an impossible distribution, coming from the, the customer. But let me, With that, let me pass that over, to, to Aaron and let him take you through how it uses, can take. Great. Thanks, Doug. So as Doug said, with, you know, being working at coaching communications, we do see an enormous amount of the traffic on the internet have a really great view into some of the sources of these traffic. I've been in this industry for over twenty years, and you know, being with my position of the company, I have an actual ability to do something about this. So the first thing we're gonna do is we're gonna go into the Kentik Data Explorer which is available from the main menu to set up the the initial view of how we're gonna find these potential, potential customer attack sources. What we're gonna do is we're gonna do is have some filters. First of all, we'll look at only traffic coming into the network from an external source. Right? We're not gonna look at backupend links or anything else like that, just external sources. In our case, we're also going to exclude private peers because the purpose of this workflow is to find customers, not peers. We're also going to filter it to only look at packets going to certain commonly abused reflection ports, which in this case is UDP And you can see here there's a list of them. We can provide that in some form later. It's gonna be DNS port fifty three. Connection connectionless LDAP on three eighty nine. MEMCash on one one two one one and several several other ones that have been identified as being prime amplification or reflection services. Next thing that's important is the metrics because you usually, as an operator, wanna look at the bits per second. Well, the whole thing about why reflection attacks are so bad is because they can start with an enormously small number of bits per second but a large number of packets per second. So in this case, the packets per second is the important thing to look at. In addition, We also want to look at the unique number of destination IPs, which is a metric that can take engineering for you, which basically allows you to see to how many different destination IPs was this flow talking to? Cause that is a really good indicator of one of these attacks in progress. And lastly, the the group by, you're gonna wanna group by provider or interface, depending on if you've done the necessary workflow to set up provider dimension in your environment, almost the same. And then the device, because you wanna know from what device the customer is on. Right? So that's the three things we got there, the filters, the metrics, and the group by. And then you can run that, and you get what I like to call the the the first view, or we have this as a save view of the amplification initiation finder. Right? We have the source provider or customer name, the device and then the two metrics columns, which are important, the unique destination IPs, and the packets per second. And you want to actually look at the this view sorted by both those metrics because they will have different things appear in show of interest. Right? In this case, we've done an initial sort by the max number of unique destination IPs. And you can see here that some of these are quite large in terms of the number IPs that they're talking to and also the number of packets per second that are being sent. And you can see here that the the blue one, I think, it's customer B, has a really huge spike from almost zero to over three million packets per second, and those are going to over two thousand unique destination IPs, which is a very good sign of a initiation of a reflection attack. Again, the same view, but now looking at the packets per second sort. So it's a little different view. It's mostly the same information, but both of them are good, hallmarks are good signs of this kind of attack. So once you've identified one that you wanna look at some more, then I go to my second tab, which I usually have open. So this tab is gonna be filtered on. So the filtering options will be first of all, the unique customer that we found from the first, from the first, view. Right? So the customer name. And, again, we wanna look at the same UDP ports we looked at from before because we don't wanna see any other extraneous ones that would throw us off the track of what this customer is doing. In this case, instead of grouping by device because we already are gonna look and be looking at one device. Right? We wanna look at just the source IP address We also wanna look at the source AS number, and then we also wanna pull out actually what that destination service protocol is, whether it was DNS, LDAP memcached or something else. And in this case, now we actually can see what the actual source IPs and source AS numbers of the traffic was along with a destination port. In this case, you see, it's, SMP domain, you know, WS discovery. And these are all very commonly abused amplification, and reflection ports. And the key here you're gonna look for is that do these IPs make sense for this customer report in this location. You know, you can see here, for example, I think this particular particular customer I was investigating was a web hosting provider somewhere in, I think Georgia. Right? But you can see here the source AS numbers that I pulled up with was Microsoft was Verizon was OVH Cloud, which is a big cloud provider. Right? I would not expect to see any of these source IPs coming from this customer. So these are, by definition then, must be, the victims of this kind of attack that's being initiated by this customer. So this is when now your organization has to figure out how to move forward with this information. So first of all, we could simply send the report to our abuse team, and have them initiate contact with the customer take action and so on and so forth. But it might not actually solve the problem because if we just turn off the customer or suspend the customer, right, we haven't made any progress in the actual, stopping this problem because someone because maybe then the customer might not know that this attack is happening. And then the the the the bad actor would go somewhere else and come back. We just don't know. So what I feel I can do given my position in the industry is to actually help them stop this problem so their network can't be used anymore as a source for this kind of traffic. Right? And whether that's, you know, as as Doug discussed, the BCP thirty eight are the things to get them to understand why this traffic is so harmful for the internet and what they can do about it. But we have, you know, because of these the size of our network, we have many, many, many, many customers all around the world, And we have a lot of problems and times with this communication. Right? First of all, it's a little language. Right? I talk English. I know some other languages. I know a bit of Spanish. But my technical Spanish is certainly not good enough to explain this kind of situation. And we get other of our customers from all around the world who simply may not understand what we're saying in terms that they can, use for themselves, actually, use this actual information themselves. It could be someone who is, you know, doing too much with too low climb, right, just one network engineer for a giant company, or they may not know what I'm trying to tell them. Right? This this test this does take a little bit of of explanation for someone who's never seen this common problem before of what this might mean and how what this means to them. How can they what can they do about it? And then, unfortunately, for some reasons, there are also some network teams that simply don't see this as a priority because it's not impacting them. And by and large, that's not wrong. Right? This customer that that I had shown you before in the slides, these attacks were not against them. These were against other people on the internet, but they were part of the problem because that is on their network is where the attacks started. And, so they may not see as something they want to devote time to to resolve it. And then there's also a variety of other reasons and myself and several other people have been, sharing information about some of these customers and we have basically put together a a bingo card, if you will, basically kind of showing the gamut of responses that we've gotten from different customers from myself and other providers who have reached out in a very similar fashion to these customers with some explanation with some, with the Kentik report, which can be shared. And this is responses we get. Right? We've gotten responses from some government entities that or or educational entities that, well, due to privacy reasons, they don't collect that flow. Well, that that's you know, I mean, that's not a great response because the the attack is still coming. Right? This is something you need to resolve. Or if someone, okay, we we block those UDP ports. Well, again, that's not really a good solution to the problem. Because, for example, the domain port is used all the time. Right? So there's just a variety of different responses we get. So it's sometimes a very continuous back and forth with the customer about explaining, no. This is the problem. This is how it works and and and and so on and so forth. And then I think that's all for, basically, my, explaining the Kentik workflow, and I'll give it back to Doug where he can kinda give you more, small statistics information about these attacks as a whole. Thanks, Aaron. That was great. Yeah. So just to, wrap up some of this discussion and we'll get it we'll jump into some of the questions that have been coming in You know, I I I, I wrote a this this discussion was a we published it as a blog post maybe last month, two weeks ago. And, we cited, a webinar that I did with, Matias Free, Fristrom, of, aurelion where he came on and from their perspective is another global backbone carrier. It's a that we have a great relationship with, and they, provide some stats on DDoS attacks, and they saw some of those trending downward And it it gives hope that, some of this effort, you know, what Aaron described, there's there is a, It's efforts like that. There's a lot of coordination going on in the industry these days, between the tier one operators, including coach and aurelion, several others, major internet firms, Google, Amazon, those kind of folks of, the experts, coordinating and trying to identify and trading notes. And I think we've made some progress. There's also separately, although some overlap. This, big pipes effort again to go after, you know, identify using, working with US law enforcement to identify who are the, DDoS for higher services try to take out those. So usually, criminal operations. So there's been a lot of, pushback of fighting, fighting DDoS and Yeah. We've we've, made some progress, for the first time, maybe ever. And, you know, if you run a network, you could be a part of this too by by doing this kind of stuff. Yeah, the key key insight there was, you know, this isn't infinite, the number of networks that are launching these attacks. There's a finite number and small enough. The, you know, if people collected their intelligence, we could probably identify the worst actors. Let's try to mow the mow the lawn a little bit, take some of these guys out. And, yeah, so that that's a a positive thing. And, you know, I think maybe maybe we'll leave with a, a call to action, you know, if if you operate a network and you're allowing spoof traffic, I chances are you are facilitating deals attacks against other, companies. And, you have We would argue a a moral responsibility. Maybe not legal, but you've got a, at least, a moral responsibility to try to, to investigate and eliminate that that details of traffic. And if you have somebody like Aaron, or a, an for one of the other backbone providers, or, when the cloud providers reach out to you, that's saying that they've got they're detecting spoof traffic coming from your network. You're gonna need new tools to investigate the those claims, and, you're not gonna wanna be, you know, completing Aaron's a anti spoofing response bingo card. You wanna have a good response, ability to identify, what what the problem is on your own, and remediate that because this is a, you know, the internet is a collective effort. We have to work together on a problem like this. So with that, why don't we, take any questions? See. Saf, do you have any, Yeah. There's a couple, that have come in. I will start off with this one here. Doug, what other action can people take to address this problem? Yeah. Erin, do you wanna, take that? Yeah. Sure. So as I said before, and as we indicated, right, this kind of attack starts in someone's network, and is generally the victims are generally other people. Right? So, basically, what I'm asking the audience listening or to do is become informed about this. Right? Make yourself part of the solution you know, not part of the problem, right, especially if you have contacts in other industries, other countries, you know, that are in the internet sphere, Right? Reach out to them. Get them interested. Get them. Get them information about these kind of attacks because that's the biggest problem that Usanaam is is outreach into these some of these countries and communities, which are harder for me to get into. And, right, if I'm coming to you as and you're my customer, I'm the provider. Right? You know, it's a different relationship. Right? And they may not believe what I wanna say. Oh, you just want money or whatever. Right? But I'm trying to tell them about a real problem. So I think sometimes if they have someone else that they maybe trust. Maybe it's, you know, some kind of, network operators group in a different country or something that that can reach reach out to them and spread the word about these kind of problems that exist. I think that goes a long way towards making, you know, the the the mission I've taken on easier to, basically, at some point, have this threat almost completely disappear from the internet. Cool. Let's go to the next one. If someone is a victim of a reflection attack, what can they do about it? So I guess I'll I'll that takes one as well. So if you're the victim of a reflection attack, right? So there there's there's two things that you can do in general. One thing is what can I do right now to stop the attack or stop the impact on my network? And that is really the same thing as any kind of attack you're under, whether it's many solutions, black holeing, something like that. But if it looks like you're the victim of a reflection attack, which in this case would be, you know, thousands of IPs, coming at you, and then they'll have a source port of one of these abuse services. Right? LDAP, DNS, DNS, and so on and so forth. You go to your provider and say, hey, I think I'm the victim of a reflection attack. Can you help me please trace this back to the source. Right? And I would hope at some point that there would be sufficient expertise at that provider to assist you in that goal. Right? And then, basically, they would talk to their provider and their providers on so forth. And eventually, it would get its way up to the, you know, the people who can, who who can see where the tax actually coming from. Oh, this is coming from a hosting provider in Czechoslovakia. Oh, this is coming from some, you know, Wispin Omaha or whatever. And then they can apply that same pressure or that same discussion that I have with my customers about getting the problem resolved. So two parts. One, It's just a normal attack from your perspective, a lot of traffic, but because the reflection attack, there is a source that can be found but you as an edge node would have to enlist your provider to initiate that traceback process. And this one from, Barry Green Akamai Technologies. Most of this work requires Netflow in the network. Many think it is expensive. Can operators and enterprises deploy open source Netflow, then those pulled into Kentik. I guess I can I'll answer this. I I don't know of a way to do that. Presently, It's something maybe we can look at and consider if you look at just Aaron's workflow there of, just the idea, just this one, set of functionality to identify, spoof traffic. I don't know if we could make offer that as a, a service that someone could import, Netflow specifically around that. But, I I don't have a a good answer for that. It's a good question, and it's something I'll take back to our our product management and, see if there's something if for the good of the internet, could could this functionality be, provided more widely? And as an as an added to that, you know, there there was definitely a cost to deploying any kind of full analysis can take or anything else, and that's true. I honestly feel that today in twenty twenty three, it is almost going to be a requirement of a good operator to have a Netflow analysis package. Right? You know, back in, you know, nineteen ninety five, nineteen ninety seven, You could just use, you know, ROD tool when you're done. And I feel that's really inadequate these days to be a good commercial operator, a good internet citizen. Another question, would this address the newly discovered HTTP to rapid reset attack. Erin, do you wanna keep that? Sure. So, I looked at I looked at that. I'm aware of it. I I should say I'm aware of it, and no, this wouldn't have anything to add that. That is more of a what called like a layer seven attack where there's actually, attempting to to starve a server of resources whereas these kinds of attacks that are being discussed here are more just a flooding attack to overwhelm a link. Right? Trying to stuff a fifteen gig down a ten gig pipe, for example. So it would not, do anything against that kind of tech. One from, Tara Cindy from team Simaru based on Netflow data. How can you you can differentiate between normal DNS traffic and DNS amplification DDOS types. How can you? He said, sorry. No. That's fine. So, it's that's a very good question. And so one is I wanna make sure that we state the question. Correctly, I think you're trying to between normal DNS traffic and being the source of one of these attacks. Right? So, basically, It is it is not obvious. Right? It really depends on your, the traffic profile of your customers. Basically adding in that unique best patient IPs metric really does a great job of cutting down that kind of noise because, again, you're looking for an unusual traffic pattern. Right? So when if you see a particular customer of yours, all of a sudden, shoot up to sending traffic to two thousand DNS servers and then goes down to none, then it is really a sign of the attack. So using the that that, unique destination IP's metric, along with the packets per second, is a pretty good vantage point of a sharp, pretty good, distinguishure between normal traffic and a DNS attack or a DNS application attack. And then also looking at those source IPs in that second view and realizing that, hey, this is a hosting customer in Georgia. I shouldn't be seeing source IPs of hosting providers in Europe from them. Aaron, another one for you, from Barry, Akamai Technologies. He said, should you ask your upstream ISP about their Netflow deployment? And, are you at risk if they do not run Netflow and cannot track DDOS? So I think it's a great, plan for any customer to ask their upstream cap upstream ISP, what their capabilities and capabilities are. You know, I would say it's it's two two parts set. Right? So one is stopping the attack. Right? And stopping the attack these days, there's a multitude of vendors which would allow, you know, real time black holeing or scrubbing or cleaning. Right? And that's all there. What we're talking about here is a slightly more narrow focus of making sure that, you know, you as an ISP as an operator are a good internet citizen and that you are taking an active role into finding and stopping the sources of these attacks so that they can't happen anymore. So, certainly, I think that is a good plus in your ISP's favor. If they are, if they do run that flow and they can track these kinds of things, but if that's a different thing than stopping an attack towards you as the customer. One more question from Jeremy Trust. He says, will this pre presentation be available to attendees after the session? I do believe that is the case, Jeremy. And another one from Tara. Why most IS why most ISPs don't apply DCP thirty eight? And can we plot can we apply DCP thirty eight on t one or t two? So the answer to that is going to be because it's not meant to be used there. Right? So BCB thirty eight also known as anti spoofing on a router is a configuration knob you can turn on that basically verifies when traffic comes into the router on this particular interface that the best route for that those source IPs is back out that interface. So for example, This only works really well or only is hundred percent effective against statically routed customers or very much end users. So it needs to be applied at the edge where there's no possibility of asymmetric routing. As a tier one or tier two, If you apply this on your huge downstream customers, right, your multinational ISPs that buy transit themselves from several other ISPs and have many other downstream customers, you run a high risk of inadvertently black holeing the traffic that's coming from them because the best route to them may be through their other ISP. So while certainly an ISP like myself, could turn on the VCP thirty eight feature towards a customer, a large multinational customer. It would have a high possibility of black hole in traffic. So so we don't do that. Instead, we do basically what I have, you know, been talking about in the first half of this presentation, a webinar, which is to reach out to that, to that customer and say, hey, the traffic looks like a problem. You need to find the source of that traffic in your network and basically have that same conversation. Say, hey, here's this traffic. Can you please track it down? And they could do that with the report I provide them using the Kentex share report which has the all the information and the times that they need to, the the UTC times of the actual attack so they can go back in their tooling and find out where the attack is coming from? One more question, Barry, from Barry. One of the tools used by the community is shadow service free cyber civil defense reporting. It will list out the devices in your network used by DDOS. They also have reports on the potential DDOS reflectors, KanKentek pulling Shadow servers API to us, that list of IPs to track. Let's see. I we've pulled in a lot of, security related, data to, enrich our, our, the net flow. There's so, I don't know if this is on our list, but if it's not, you know, we can take that back and make sure that gets added to it. And so then, yeah, you would be able to, you know, quickly, it would be it would add a a bit of, you know, add to the process, Erin, mentioned if you have a, another indicator to use that these are potential, reflection points. But, it's a good suggestion. And, you know, I'll take that back again to the product management. I think there's a way to do that. Yeah. I don't think we have any more questions. I see I see one more at the top. I think, Will the UDP port list be available to attendees after the session? Yeah. So, I I you know, when I I I saw that I was thinking, maybe the way to do that, Erin, maybe if you wanna give me your lists, we can, just add it. We can update the blog post that this is based off of, and just put that, we could put that on the blog post so that, I guess people can see what the list is, just to, I I think it's probably not that controversial, but, when we put it there, I'll I'll after this call, get the list from Aaron and, update that at Yeah. You can look at you can find it there. Looks like we've got if you want more, question. Yep. One more, Michael, fear, more, fear, man, or cogent Communications. Hope I said that right. He says, what about using RPS loose mode instead? At least you would protect yourself against spoofed RFC, one nine one eight source addresses. Right? Is that best better than nothing? So, certainly, as an ISP, right, turning on RFPF loose mode towards your customers is a good thing. Right? Because, basically, it means that when you get those packets in, RFPF loose mode means that if your router has no route back to that source address, it would then drop the packet. Right? And if you think about the internet, right, if you as a, you know, an ISP, get a packet for which you have no way to return traffic to that source IP address. More than likely, it's garbage traffic. Right now. Obviously, it couldn't then be actually used for a reflection attack because the real source IP is no Internet. Right? It's an RC nineteen eighteen. It's a class e. It's reserved. It's whatever. So at the very least, it would definitely stop you from getting in junk traffic that you could do nothing with But as far as stopping an ISP from being a intermediary or a someone who is allowing this attack to happen, it wouldn't stop that because By definition, this attack is going against a real IP out on the internet. We got one more comment from Barry. Barry's kind of the third presenter on this, presentation. I really appreciate it. No. It's great stuff. So, Barry writes in, to answer the two questions ago about, you know, publishing the list of, UDP ports. I'll add that to the blog post, but, very suggestion is, if you search for exploitable exploitable port filtering, there's a guide, that's been created, that discusses this, and provide some guidance and lists of ports that, you you can you can track. Right. So and and it's certainly right. It's a good idea. There's many ports out there that deplatable. However, I would be very, very, very cautious about filtering these because the problem with filtering on the internet, and again, you know, Mary and I, many of you have been on the internet a long time. The problem is once filters get in, they're very hard to get out. People put them somewhere and forget about them. People leave companies and so on and so forth. So although there are certainly ports that are, you know, I wanna say bad that are exploitable, Right? Sometimes like DNS. Right? We all need DNS to function. Right? We all need other protocols to function. So for purposes of Again, this I don't say very narrow, but this singular use case of finding this traffic at the edge, certainly knowing those ports is good. Have them in your tools to help you find lots of traffic to the ports is good, but filtering them is something I would really advise not doing only because there's many legitimate uses for those ports. The only illegitimate usage comes in the fact of spoofed source traffic which applying the anti spoofing or BCB thirty eight filters at your edge would stop that traffic from ingressing your network. So, Erin, in your workflow, you the way you're using the, that port list is just for identifying candidate, traffic that could indicate spoof traffic. Right? That that that's correct. I mean, basically, these are, you know, and and I think you maybe touched on that briefly, but the the thing that makes these ports and services so attractive, for implication attacks is that they are, UDP, right, one way. Just had to pack it out and also, there's a very large amplification factor, right, in that you send a small packet, maybe ten, fifteen, twenty bytes, right, but you get a packet back That's maybe a thousand bytes. So a fifty times factor. And there are some protocols that have really, really, really big amplification factors based on how they were initially, outlined and designed, by the ITF and so on and so forth, which have then been been adapted over the years to be a little less destructive in their initial configuration. We have one I don't know. It looks like there's one one maybe one last one. There's been a lot of questions. It's been a great discussion, though. This is, phenomenal. And thanks thanks Barry a lot for your comments. Yeah. This is great. Great engagement. Thank you for the questions, guys. We'll just take this last one. It's about quake network protocol. Does this make detection of amplification DDO attacks more difficult? You know this one, Aaron? I'm not I'm not familiar with it. I I unfortunately do not know what what network protocol is, Dustin. It's, after, after some research and maybe if I I find out and you can amend your blog post, unfortunately, I'm not familiar with a quick network protocol. Alright. Alright. Sorry about that. But yeah, that's all we have time for. Don't forget to check out the attachments below this webinar, which include case studies, a white paper and even a Halloween story by Kentik. Thank you to Aaron and Doug for joining us and providing some great insights, and thank you to everyone for watching. We hope this has been useful. Please don't hesitate to reach out to Doug and Aaron for more information. Thanks guys, and thanks a lot for joining. Yeah. Thanks. Thanks for the questions.