Hello, everybody. My name is Andrew Coburn. I’m a Chief Solution Architect for NETSCOUT out of the Enterprise CTO office. And for the next 45 minutes or so, we’re going to be talking about the role of deep packet inspection in DDoS detection and mitigation. In terms of agenda, we’re going to start off with a few definitions, just to level set and make sure that everybody’s talking about the same thing. Some terms vary across different locations and disciplines. And then we’re going to look at the DDoS history and landscape. And following that, we’ll take a quick look at various DDoS architectures and how we actually detect the attacks themselves. And then the bulk of it is going to be the DPI information on how we actually approach mitigation.
We split that into different OSI levels, layers, if you like, because the techniques differ depending on the type of attack. So I wanted to start off with basically a couple of definitions. What is deep packet inspection? I think everybody knows what deep packet inspection is, but I think it’s worth also looking at a couple of other things, like, for instance, the OSI Layer 7 model and how that feeds into it as well. And it’s no secret that everybody talks about the OSI 7-layer model, and here are the 7 layers on the left. But in actual fact, the Internet Protocol model, which is what we actually use in real life for pretty much everything, doesn’t really fully map to the OSI model, despite that fact we still use the terms.
So we’re looking at the OSI 7-layer model. So we’re looking at the different layers. The link layer really maps to layers 1 and 2 of the OSI model. The Internet layer, the IP layer, is essentially layer 3. The transport layer is layer 4. And then the top three layers, the application layer, presentation layer, and session layer, actually map to the application layer, really, in TCP/IP and the Layer 7 protocols. The reason I’m mentioning this is we are going to differentiate between these different parts of the stack. We’re going to talk a lot about Layer 7, which is essentially the OSI model. We’re going to talk a lot about Layers 4 and 3, as well, and to differentiate those between the IP layer and the transport layer, typically TCP and UDP.
We’re not going to talk a lot about the link layer at all, because that’s actually not particularly relevant for DDoS distributed denial-of-service attacks, because they are attacks over the Internet, and they need to be routed minimally using Layers 3 and 4. And a lot of the attacks are actually attacks on Layer 7. So we’re going to talk about Layers 3, 4, and 7. And this is what I mean. Regarding DPI, here’s a crack at a definition. It’s basically a technique for inspecting network packets on the fly. And there’s a lot of stuff you can do with it. You can figure out IP addresses and ports. You can look at Layer 7 constructs like URLs, headers, DNS requests, that kind of stuff.
And we do this for lots of reasons, everything from routing to firewall rules to baselining to intelligent web application firewalls. And most importantly, for the purposes of this discussion, DDoS Detection Mitigation which is very heavily invested in actually looking into the packets. Now, one thing I just wanted to make clear is there are some discussion or different definitions about what constitutes deep packet inspection. Some people don’t regard Layers 3 and 4 as deep packet inspection, only Layer 7 when you’re looking at protocol payload. For the purposes of the discussion, you know because a lot of the interesting stuff happens at layers three and four as well as layers of layer seven.
We’re going to just use DPI to mean any any packet inspection at layer three or above, because that’s really uh the sweet spot of what we do for DDoS detection and mitigation. And just really just to kind of give you a graphical view of how this actually looks, um the different layers essentially encapsulate each other so when we’re talking about you know layers one and two, or the payload of layers one and two actually consists of layer three which itself has payload which is layer four etc etc they’re all encapsulated. The important differences between the different layers is is particularly What constructs they might have available, so Layer 3 only has IP addresses available, you have to go to Port 4 if you want to talk about TCP or UDP and they bring in with them the concept of numbers.
And then when you get to Layer 7, uh, all of the different protocols have different cross-constructs, whether or not that those are things like headers in an HTTP request, uh, or you know similar similar constructs email addresses in an SMTP, you know a packet and then they themselves have their Layer 7 payload which is typically content like a like a web page or something like that or an email message um so that’s so. much for the uh for the definitions that’s just a really a level set let’s actually dig in and and talk about what a distributed denial of service actually is ddos for short um in security we we often talk about the so-called like three-legged stool or it’s also called the cia triangle stands for confidentiality availability and integrity these are three things that we care very deeply about in the security realm confidentiality is about making sure that no one can overhear our conversations integrity is about making sure that no one changes what we’re trying to communicate in between the sender and the receiver and availability means that whatever we’re trying to communicate or the resources we’re trying to access are actually there for us to actually grab a hold of now of all of these ddos distributed denial of service is specifically an attack on availability it is the target of ddos attacks and what we want what the attacker wants to do in terms of availability is remove availability so that if someone is trying to access for instance a website an attack is intended to render that to the server and that’s that unavailable so that the legitimate user can’t access the website there’s a lot of different reasons that these attacks occur and they they run from criminal intent extortion political nation state activity there’s tons of others you know gamers trying to one-up each other and prevent people from winning tournaments there’s a lot of different reasons for ddos many different reasons as there are things on the internet but essentially they are all attacks on availability and availability a very specific type of availability or a very specific type of attack if you like because availability can be removed by for instance taking power out of the building with a server in it or locking the door so no one can get to the terminal That kind of stuff doesn’t work or is not easy over the internet, so we’re looking at internet-propagated attacks, that’s really what a distributed denial-of-service is – denial-of-service because we’re denying that availability. Distributed because they are typically run from many sources of data across the internet at one time. And you know DDoS has become the most common threat to availability because it’s it’s compared to getting physical access to a
building or even cutting a power line or something like that, it’s a lot easier to to run a bot or run open resolver and send attack packets, and as a result, there are Many many groups out there who have put a lot of effort into figuring out how to run these kinds of attacks they’re very, very common and they are the way that are the way of choice that people cause trouble whether it’s for extortion or just to make it, make a point or really just to try and you know arm people, arm reputations. There’s lots of different outcomes from DDoS attacks, none of them are particularly good, and that’s that’s the reason they become the most common threat to availability is because they’re easy, they’re very easy to do in this day and age so let’s take a quick look at how DDoS has developed over time this is a brief history of DDoS, it’s not the brief history of DDoS there’s lots of stuff missing, these are really just things that I’ve picked out that I think are particularly relevant and have shaped the landscape that we’re into today, and just you know, just kind of early early warnings if you like that are built up to the to the current landscape of the day. So we’ll pick out 1974, the first ever DDoS attack, and that wasn’t even really a DDoS attack, you know. The legend goes that it was in a lab somewhere, it was probably a simple UDP or a ping flood, it was probably run from a single computer, which means that it wasn’t distributed it was on a local area network but it’s it’s notable because it’s the first their first report we’ve ever had it’s a written report about this particular event i’m sure there were others before it but this is the one that everybody kind of points to as the first ever doss attack so you know it’s it’s it’s easy to see that that ds and ddos has been around for a long long time and essentially it’s grown up with the internet in 1974 no one really knew about the internet apart from a handful of ARPA nodes in the US. And even at that point, we had the denial of service attacks. Next thing I wanted to pull out is just over 10 years later, the first worm, it was called the Morris worm.
In fact, the author of the Morris worm wasn’t out to cause trouble. He was researching self-propagating code. He wanted to write this code that would do something clever. I think it was a research project even. Unfortunately, due to an error in the code itself, the worm just propagated endlessly. And it had the side effect of causing denial of service to a huge tranche of the internet at that point. He was actually arrested and I think he’s fined for that. There was no evil intent, but this really is important because it was the first, if you like, autonomous tool used for causing trouble. And they’ve only got cleverer since then. 1996, the first SYN flood. As we’re gonna talk about, a SYN flood is an example of a state exhaustion attack.
They are very, very troublesome attacks because they cause problems for any stateful device in the chain, whether that’s a firewall or load balancer or a specific victim like a web server. They’ve been around since 1996. They’re very, very effective and very hard to defend against. Unless you have specific anti-DDoS capabilities. And they are still as damaging today as they were in 1996. They are a staple of the internet. Along with some similar types of attacks, we have variations on the SYN flood. They’re all abuse of the TCP protocol. They’re their own class of attack. They’re still alive and well today. 1999, TRINU. This is interesting because it’s the first dedicated DDoS tool. Up until this tool was released, people would craft their own. They’d use whatever executables were available on a box. They’d write code themselves to blast packets. It was a sort of a minority kind of industry, if you like, because the people that actually were building these things and running these attacks, they had to be fairly smart. They had to know how to code. They had to know networking. TRINU changed all of that because it was a tool. You could download an executable. You could run it, click on a button or a menu option or something, and run an attack. And it became very easy. It became low-hanging fruit. And ever since we’ve had tools like this on the scene, there’s been a life cycle for every new attack vector. And there are many, many, many attack vectors that are changing and evolving all the time.
But typically, what happens is someone researches a new type of attack vector, an exploit that no one had heard about before, or a new type of way of using a particular service. And we see evidence of that in the wild. We have our researchers looking for that. We may not even understand exactly what’s going on at first, but we tend to see small amounts of specific types of traffic when people are trying it out, when they’re researching it. Then typically a month or two, year, however long after that, you’ll see the first real attack. We’ll see a big attack. We’ll see a website taken down with a novel attack vector. And we’ll look at it and we’ll say, oh, OK. That’s what they were doing.
And then what happens is someone takes it and puts it in a tool and releases it on the internet or one of the booter stressor sites, so-called booter stressor sites, which are essentially DDoS for hire. Sites will add this to a menu item. And then we see this attack vector. It just blossoms and grows. It becomes prevalent. It’s all over the place for a while. And then essentially, eventually, we actually, the good guys figure out how to block it. And we see the prevalence of it drop off. But by that time, the next attack vector has arrived. And this is all being driven by the lifecycle of people researching new types of attacks and then putting them in tools. Extortion. DDoS extortion made its debut in about 2004.
This is still very common today. And that is, hey, if you don’t give me Bitcoin, I will bring your site down, essentially. It’s used for criminal gain. It’s very effective. It happens to a lot of people. Quite often, they will actually run a sample attack. They’ll take a site down for 10 minutes and say, hey, if you don’t want that to happen again, we need Bitcoin immediately. This has really become a staple of the landscape. Now, the good news is that with the right preparation and with the right capabilities, you can actually just call a bluff. And they’re not doing anything particularly different or sophisticated. They’re just using regular DDoS vectors. It’s just very scary if it happens to you and you don’t have the preparation, you don’t understand DDoS, and you don’t have the capabilities to block it.
Anyone that has the right capabilities can just say, you know what, do your worst. We’re ready for you. But it has become a very important part of the landscape. First saw in 2004, but it really blossomed three or four years ago. It became extremely common. 2013 really started the era of massive volumetric attacks. Reflection amplification attacks are a very particular type of attack. I’ll explain a little bit more about that later. The real thing that marks them out is they are attempting to create massive amounts of volume, the type of volume that blocks up access links and, in extreme cases, blocks up the entire internet. Well, in 2013, they started to build a very, very large network of attack vectors. Everybody was using them. Again, the weaponization of these attack vectors had occurred through specific tools.
The research had been done because these types of attacks rely on unprotected or open resolvers that anybody can access from the internet. It’s not a particularly good thing to allow because it can be abused like this. But there are plenty of them out there. And bad guys can track them just as well as we can. The good guys, and we know they’re out there. But when they’re being abused, we don’t necessarily, we don’t have any way of controlling that. We just have to knuckle down and basically mitigate the attack. And these are particularly noteworthy because they are massive, massive attacks. These are your terabit scale attacks. The biggest attacks have been in the order of two or three terabits per second and an essential truth about denial-of-service attacks, this distributed denial-of-service attacks, is in order to be able to mitigate it in any sensible way, you have to be able to ingest it so that you can get the packets and filter them. These classes of attacks, reflection amplification attacks, are singular because you have to be a very, very large service provider to be able to block them. People like Verizon, AT&T, those kinds of networks, and also third-party scrubbing services that basically build themselves specifically to ingest this kind of attack. They can handle it. They’re not particularly complicated attacks once you get over the sheer volume, but they became very prevalent in about 2013 and really shaped the landscape for almost a decade.
And then the last thing that I really want to flag up is in 2020, we saw the first signs of Mirai. Mirai was a botnet because by the end of the era of Reflect-NICE at the end, they’re still out there and they’re still very common. They’re just less common than they were. The operational community figured them out, essentially. They’re easy to block. They’re easy to prepare for. You just need to know what you’re doing. And the attackers started to get less leverage out of these big attacks. So they moved to something else. And what they did was, they started using botnets. Now, botnets have been used before, and there’s nothing new about that, but they picked server-class botnets, big, big servers running lots of memory and lots of CPU.
And also with big network connections, they would take these over and add them to a botnet. And with enough of these, you can actually tell that the botnet, which is distributed across multiple hosts that have been taken over and controlled, you can send a lot of packets towards a particular victim. That started to become prevalent in 2020 with Mirai. And this was interesting because it harkens back to the Morris worm, because Mirai not only was a botnet, but it was also autonomous in finding other nodes for itself. So it would actually go out and probe, typically things like Internet of Things devices, cameras that had very weak security. A lot of them had default usernames and passwords and open ports that shouldn’t have been open.
And it was very easy for Mirai to not only sit out there as a bot and attack people, but at the same time, and it’s, and it’s, and it’s, well, it wasn’t doing much, but it was doing its day job of attacking. Its night job was to basically look for other Mirai or other nodes that could be incorporated into the botnet. And it’s, it’s been whack-a-mole ever since. Once heard a statistic over the last few years that if a node is cleaned up from Mirai, it’ll actually get reinfected within five minutes of being turned on. It’s a big problem. And it comes down to weak security in one of these devices. So those, those are kind of the historical pieces that I’d really like to highlight.
To me, they, they, they’re all sort of foundational in, in forging the code. Of the current landscape and what we’re actually dealing with. So, the next few slides, we’re actually going to take a look at that landscape and actually discuss what the landscape looks like in the various different types of attacks out there, because not only is that interesting, but the different types of attacks also require different types of responses. And that’s a big part of what we’re going to be talking at, talking about towards the end of this presentation, okay? So, the first attack factor that we’re going to look at is going to be volumetric attacks. Volumetric attacks are, as you might expect, very large amounts of volume sent over the internet against particular victims, and their whole purpose is to clog up various types of internet links.
They consist of many packets sent a large packet center, you know at a high rate, and they’re essentially as large as the internet can handle in terms of packet size. Okay. Okay, the MTU size of the internet is generally 1,500 bytes. So you’re going to see a huge flood of 1,500-byte packets sent against a victim. And these are the attacks that make the headlines, one terabit per second, two terabits per second, three terabits per second. Every year, the largest attack size increases. And these are the volumetric attacks that get a lot of coverage in the news. But their entire reason to be is essentially just to clog up links. And they’re very indiscriminate about it. So for instance, if you have a web server, it’s sitting on maybe a one-gig link.
A two-gigabit-per-second volumetric attack sent against that web server is enough to completely clog up the access link, the local area network link that it’s on. Once that link is completely saturated, no valid requests can actually get through. And that’s the denial of service right there. But it gets worse than that because volumetric attacks can get very large. And if you think about a standard enterprise, maybe you have one or two 10-gig links. If you send maybe a 25-gigabit-per-second attack against that enterprise, it’s going to saturate its access links. And the entire enterprise will be off the internet rather than just a particular service that may be under attack. And in extreme cases, these attacks can get so large that they can clog up smaller ISPs.
And you really need, for the very largest, types of volumetric attacks, you really need a network that can actually ingest them. And there are very few networks on the planet that can ingest terabits-per-second of traffic. You’re talking about tier one service providers like Verizon, AT&T. And also the dedicated scrubbing services for DDoS are constructed to have that type of ingress capacity. Now, the good news is once the attack has been ingested, these volumetric attacks are actually pretty easy to block. They’re generally the, the UDP protocol, and they generally have very obvious ports from which they’re actually sourced because of the way they’re generated, essentially by reflection through open resolvers like DNS resolvers, charge-n resolvers, those kinds of things. They have, they have characteristic source ports that actually let you filter them out very easily.
But yeah, the biggest problem with volumetric attacks is, is that they are so large that they are essentially going to clog up links. And unlike the other two types of attack, it’s very hard to handle volumetric attacks on-premise. All things being equal, handling things on-premise is generally a better way to go. But for volumetric attacks, you’re going to need assistance from a third party if it saturates your access links. The second type of attack, state exhaustion attacks, work by abusing the TCP protocol. The archetypal state exhaustion attack is a SYN flood, and we saw from the timeline that we’ve, these have been around since at least 1996. And all a SYN flood does is send it will send a SYN packet to a server. The server says, okay, that’s my cue to open a new connection.
I’ll wait for, I’ll send my response and I’ll wait for the connection handshake so that I can actually continue and actually exchange some data. But the attacker doesn’t ever respond to the handshake. He’s just going to send another SYN packet. So the victim says, okay, great, I’ll open another connection. Now you multiply this by millions of packets per second, which is a typical rate for a SYN flood. And you’ll see that the victim is expected to open millions of connections per second. And all those connections hang around and never progress. And eventually there is going to be something that gives, whether it’s a particular table in the TCP stack or just overall memory for the machine.
Now, under state exhaustion attack, particularly a web server, you know, a host machine, quite often minimally won’t be able to open any new TCP connections, but more often than not, they’ll just crash because they run out of memory or something like that. State exhaustion attacks are dangerous as well because they don’t just impact the victim machine. There are a lot of stateful devices in line between the attacker and the actual HTTP server that we discussed, particularly things like firewalls, load balancers, web application firewalls. They also need to track the same state. It’s their job. A firewall needs to track state so it knows what’s going on. And quite often, most often, in fact, firewalls are going to fail before the actual TCP stack on the victim machine.
And again, once a firewall goes down, the collateral damage is huge. It essentially means that any service behind it is unavailable. So these, again, are very effective attacks. And although they may be aimed at particular victims like web services, quite often, they’re going to have much more collateral damage because a firewall is going to crash. And then the final family of attacks is application layer attacks. These are not abusing any kind of reflector or amplifier out on the Internet. They’re not abusing the TCP protocol. In fact, at the TCP level, they’re well-formed because they rely on exchanging data for what they do. And what they do is they exploit layer 7 behavior. So a simple example. Of an application layer attack against a web service, for instance, might be a get flood.
And a get flood is very simply usually a botnet out there will issue a get request, get index dot HTML, something like that. And that’s fine. There’s nothing wrong with that. It’s perfect to the legitimate use of HTTP. But when you then multiply that by hundreds of those requests per second per bot, and then multiply the number of bots by tens of thousands, you can very quickly get to a situation where a web server is being expected to respond hundreds of thousands, if not millions of incoming requests per second. Now, as with everything else, a web service is going to have a finite amount of resources, and that might just basically run the web server out of compute or even sometimes bandwidth.
But more often, it’s going to be compute or memory or something like that. Many of the attackers are actually quite cunning about the way that they construct these queries as well, because they’ll do some research. They’ll find a URL that forces the web server to do something odd, right? For instance, maybe generate a PDF file, which takes a lot of compute. It will take up some disk resources or perhaps runs a very complex query that will make a database spin for a while. And again, you take that, you identify that one URL that causes all of that activity and then multiply that up. You don’t need as much throughput. You don’t need as many requests to actually again bring the server down because perhaps if you generate, you know, too many PDFs, it’ll run out of disk space.
Perhaps the database will take up so much CPU that, again, that the machine just dies or crawls to a halt. And that’s just sort of some of the simpler attacks. There are also a family of low and slow attacks, which also come under application there, attacks. And you can think of this as something like a tool that perhaps will make a web request, but it will do so very, very slowly. It will send out one character per second, and it will take 10 minutes to simple GET request. On its own, that’s not particularly harmful. But again, you multiply that by hundreds of requests and hundreds of bots, and you have thousands of outstanding requests that never complete.
And the way that web servers are designed is they’re meant to service requests very quickly and move on to the next one. Again, and web servers have things like connection pools that are limited. If you hold all those connections open, then once again, the web server cannot respond to a legitimate request. And the hard part about this, at least for the defenders, is that you can do this with extremely low amounts of bandwidth, one character per second, you know, or whatever. Extremely hard to detect. Unlike volumetric attacks or even high packet rates, you can tend to be able to see those. But these are very insidious because they’re very, very hard to attack. So when you put together those attack vectors, you end up with a family, a big toolkit that’s out there.
And the landscape of them changes. The different attack vectors. We’ll have them flow. We see more, more or fewer of them over time. And we keep track of that. Like many, many other organizations out there, we have research. We take a look every six months to generate a threat report. And I basically build this slide new every six months. But the point here is that, you know, I’m not particularly focusing on the actual numbers. But what I want to make the point of is that these numbers do change. They evolve. Now, things like the number of DDoS attacks is always going up and to the right. There are always more DDoS attacks. I’ve been doing this for nearly 15 years. Every year there are more DDoS attacks. It’s not a problem.
It’s going away. But some of the other things shift and change. And one of the changes that we’ve seen over the last two or three years is a decline in volumetric attacks and an increase in state exhaustion attacks or flag-based attacks, as they’re sometimes called. Again, this stuff changes over time. And it’s essential for anyone who’s defending to understand this landscape and know what is currently happening. You know, make sure that they are prepared for the specific types of attacks that are out there. And again, we can see that very shift that I was talking about, a decrease in reflection amplification attacks, an increase in direct path attacks. You can see if you look at the graph, it tracks up until about 2022. And then the two colors separate very definitely.
And we know why this is. And essentially, it’s a story that’s been retold many times over the history of DDoS. A particular attack vector or even a particular family of attack vectors, they are effective for a period of time. And what’s happened, especially for reflection amplification attacks, is that the operational community has basically got a handle on them. They’ve increased source address validation, which, particularly in the case of reflection amplification attacks, prevents the spoofing that allows them in the first place. They’ve done a lot of great work shutting down abusable servers. A reflection amplification attack requires a server out there that’s open to the Internet, that maybe has zero security on it. That, you know, again, that they are shutting that stuff down. And of course, the attackers know that this is happening.
They’re seeing that their old ways are not as effective as they once were because the operational community is shutting down a lot of the way that they can do this. So they turn to something new and they’ve turned to server-class botnets. So now they are looking for hosts out there that are servers that have a lot of compute, have a lot of bandwidth, and they are turning them into bots and using them for DDoS attacks. And when you have a server-class botnet, the botnet is good at hiding the controller. So they don’t worry about spoofing so much. They’ll just do direct path, which means unspoofed. And they are particularly well-suited to flag attacks, which are essentially just blasting high rates of packets. And this explains why we’re actually seeing this change.
Again, not so much to focus on this particular attack methodology, just that things change. There are trends. And as a defender, you need to understand that there are going to be fewer reflection amplification attacks and more direct path attacks in your protection stance and your methodology about how you actually approach this. Again, just more corroboration. The top five vectors used to be all reflection amplification attacks with probably SYN attacks making it in there. Now it’s flipped. The script is flipped. They are all flag attacks. ACK, SYN, SYN-ACK, and ARS here are all flag attacks. And the one remaining amplification attack, the volumetric attack, it’s number three. And DNS is specifically difficult because of the way that it’s used against DNS servers. And that’s why it’s still a useful attack vector.
But you can see, you know, again, changing landscape, things chop and change, and it’s good to educate yourself. Another dynamic that’s been particularly prevalent of late is an increase in query floods. And again, this is the attackers looking for something new to do. And DNS query floods have been particularly devastating over the last, I’d say, couple of years. And a DNS query flood is essentially forcing an authoritative server to resolve a non-existent domain. And this usually takes the form of a tool doing, you know, a dictionary, running the dictionary for unknown domain names like, for instance, aardvark.acme.com, archer.acme.com, anything else starting with A, just running through the alphabet using nonsense names out of a dictionary. Or random names. Either way, the authoritative server is forced to resolve these.
It sees a huge uptick in traffic. And authoritative servers are not typically built out to handle this kind of traffic because they are not meant to be the front-facing part of the internet. They’re meant to be protected by caching servers. And this type of attack, you know, basically overwhelms them. Again, we’re seeing a lot more of that because if you take a customer’s DNS web server, sorry, a DNS server down, you know, you’re going to see a lot more of that. And then essentially they’re out of the water because nothing can be resolved. So it’s, again, another type of new type of attack, very devastating. But we’ll look at countermeasures for all these types of attacks as we get further on in the discussion. So where does this leave us? This leaves us in a situation where we have three families of attack.
Each of those families are going to have multiple attack vectors. You know, there are SYN, for state exhaustion, there are SYN floods, there are RST floods, there are ACK floods, there are SYNACK floods. For volumetric attacks, we have SYN floods. We have DNS, reflection amplification, NTP, chargen, SSDP. There’s as many of them as there are services out there, essentially. There are lots of services out there that can be abused. And they all have their time. They all get used for a while. And then they become less popular as people figure out how to block them. And a new one will bubble up. But the really worrying part of this is that they are not just, you know, attacking you with one attack vector at a time.
They will pull from a toolkit of all three different attack families and vectors within those families. So you might be trying to manage a volumetric attack from a charge reflection amplification attack. At the same time, they’re sending a SYN flood, maybe an ACT flood. And at the same time, maybe they’re doing a low and slow attack against your web server. Dynamic and multivector. You know, the multivector, you know, I just described the dynamic part. It’s the fact that, you know, they’ll do one thing for five minutes and then they’ll change it five minutes later. And you’re forced to try and adapt and track. It becomes extremely challenging to handle all of this stuff. And that really is the challenge. It’s these attacks are evolving. The most complex attacks we’ve seen are up to 25 vectors.
And your job as a defender is to track that. It may change throughout the course of the attack. You’ve got to figure out all 25 of those attack vectors, up to 25. And put in place countermeasures that will filter those specific attack vectors. It becomes a very complex task. And also, you know, you need to think about the layering of the protection as well. Because we discussed the fact that volumetric attacks need help from an upstream network. At the same time, all things being equal, an on-premise response is better, quicker, more accurate. But you need both. And the best practice really, in the industry is a hybrid defense. Which essentially couples volumetric upstream scrubbing with on-premise device for doing the state exhaustion and layer 7 scrubbing.
And, you know, in the best setups, you also have signaling between. So you can actually have the on-premise device figuring out that a volumetric attack has started. And actually signaling the cloud scrubbing to automatically do that scrubbing. That’s called a hybrid DDoS defense. It’s been the best practice in the industry for many years. So now that we’ve looked at the attack landscape. Let’s take a quick look at a couple of different mitigation architectures. The first point I want to make when we’re looking at mitigation architectures. We have talked about cloud scrubbing a couple of times. An upstream volumetric service. When you actually dig into what those services are doing, it’s no different from what we’re doing with our on-premise devices. It just happens to be in a different place.
And it just happens to usually have a much higher capacity. But cloud scrubbing is not qualitatively different from any of the other on-premise stuff we’re going to do. It uses the very same techniques. And in many cases, just a level set there. And the first of the two architectures we’re going to look at is the inline architecture. This is particularly common in small to mid-enterprises. And essentially comes down to putting a scrubber. An inline scrubber. In front of all of the devices you want to protect. So the scrubber is taking packets directly from the handoff from the service provider, processing them, checking for DDoS attacks, and filtering them before they get handed down to any other devices on-premise. For instance, the firewall, load balancers, web servers.
Those are all the devices that need to be protected by the scrubber. The scrubber is doing the filtering. It’s particularly filtering out those state exhaustion attacks. So, that the firewall doesn’t crash. It’s filtering out those layer 7 attacks. So, that the web server or the SMTP server don’t run into trouble. It’s always on. Which means it has the capability of looking at every packet as it goes through. And instantly detecting any kind of an attack. So, it’s in a great position to instantly block that attack. Having detected it. And it’s a great experience. The only problem with the inline architecture is it scales to your network size. And every time you add a data center or a link or something like that, you need to make sure that you have that inline scrubbing capacity.
And that’s fine up to a point. But there becomes a point when a network gets to the point where this is no longer an economic way of handling. The situation. And that’s when we start talking about an on-demand architecture. And this is what many of the larger enterprises use. And definitely all of the service providers are using this kind of an architecture. The way that the on-demand architecture works is that there is unlike the inline device. There is a detection phase. And basically, you have a system which is often utilizing netflow, which is a layer 3 and 4 telemetry for a network. This is a tool for running detections. The traffic is exploring. It’s describing who is talking to whom. And you can use that to actually figure out if a DDoS attack is occurring.
Once an attack is detected, you can see that the normal green part in the network for traffic coming in goes through to the data center. If there is an attack detected, we then use the network itself to reroute the traffic to the scrubbing center. Now the scrubbing center is getting just the attack traffic. And by that, what I mean is We are able to identify the IP address that is under attack from a DDoS attack, and then we send all of the traffic destined to that IP address through the scrubber. So it’s going to be a mix of attack traffic and clean traffic. But the point is, we’re not sending the entire network traffic through the scrubber; we’re just being very selective about what we use.
And this, of course, means that we can scale a lot better. Because we only care how big the attack is. We don’t care how big the network is. So we can build the network out as big as we like. We will make a determination as to what attack size it economically makes sense for us to scrub. And there are always upstream options. Again, even for operator networks. If you say okay, I’m going to build my network so that we can handle 100 gigabits per second of attack traffic. Anything bigger than that, we will figure out with our upstream service providers. You are still able to be very effective about handling that 100 gigabits per second of attack traffic. And the attack is not going to get bigger just because you happen to have more networking capabilities.
You double the size of your network. It doesn’t have any impact on the attack size that you are able to scrub. Whereas with the inline model, if you double the size of your network, you need to buy twice as many scrubbers. So this approach tends to scale a lot better. Now there is some latency in detection. Detection can happen pretty quickly. But it certainly is not instant like the inline device. And then because we are using NetFlow which is a layer 4 capability. We are not able to do as good a job of looking at layer 7 attacks and detecting them. Although once the scrubber is inline, it is actually seeing the packet. So it is just as effective at actually mitigating layer 7. It is just harder for us to detect it.
But those are the two main architectures. The inline architecture and the on-demand architecture. Essentially, the scrubbing devices are the same in both cases. It is really just a deployment model that differs. Okay, next up we are going to talk about DDoS security. DDoS detection. And there is a couple of different ways of looking at this. A couple of different methodologies. But they all share the same problem. That actually protecting against DDoS is quite hard. For a variety of reasons. At its simplest, DDoS detection is really trying to separate out the normal looking traffic from the attack traffic. And a lot of the attackers go to extreme lengths to look like normal users. Particularly, for instance, with layer 7 types of attacks. If they are doing a get flood.
A get flood is just a get request. That is the same as any other user can do. So you have to look at the various different ways. Things that you can actually use to separate out the traffic. Like rates of requests. And other types of tells that help us figure out the good from the bad. It’s not just as simple as maybe looking at a particular destination IP address or service. And seeing well it has doubled. Its traffic has doubled. Therefore, it is under attack. It is not that simple. That is quite could be for a variety of very legitimate reasons. Like flash crowd as we call it. It could be a special event. They have just launched a new product or something like that.
So there are a lot of very legitimate reasons for the amount of traffic that a server is seeing. To actually increase in size very significantly. So we have to look more at the behavior of the source addressing. To see what the actual individual users are doing. Rather than what the aggregate effect is. And that is really a big part of how we succeed with DDoS detection. We are actually looking at individual behavior of the attackers. And the good guys for that matter. Rather than the effect on the server. That is a pretty key concept. So, the two different types of architectures. They really kind of rely on different methodologies for detection. In fact, in the case of an inline device. Detection is almost really a side effect. Because inline devices are tuned.
To really have a set of policies. That will let good traffic through. And block anything that goes outside of that. And treat that as bad traffic. And block it. For instance, attackers that are sending lots of requests. More than the average user. We are looking at that source behavior. And as soon as they step out of policy. We actually start blocking the traffic. And we will report on that blocked traffic. But essentially, we have detected the attack. As a side effect of actually doing the blocking. Now having said that, some inline devices will have additional detection engines that can give more information. And in that case, they will typically be looking at the packets themselves and analyzing them for specific patterns. And there are a lot of well-known attack traffic patterns that you can identify at layer four.
Behavior you can identify at layer seven to actually figure out that particular tools are used or techniques are being used. And in those cases. You are running in addition to the always-on instant detection, and blocking. And you are also running that detection engine which is capable of sending alerts about specific attack types on demand devices which we covered earlier. Generally deployed in much larger networks. And the challenge here for on-demand devices or on-demand scrubbers is that they are not typically seeing packets. They don’t have any information or access to what is actually going on in terms of what the attacker is doing to the victim. So, they tend to use a proxy for the packets and that proxy is NetFlow. NetFlow is essentially. And we mentioned this earlier.
NetFlow is essentially layer four telemetry. And it is interesting to note. That NetFlow itself is actually generated. Using I guess you could call it. Shallow packet inspection. It is detected directly by the routers. Because the routers are always seeing the packets. They will see the packets. They will generate NetFlow that describes the packets. It is actually information about the five-tuple. Some information about volumes. Some information about flags. And that is then sent and consumed. By the detection engine. Which actually using NetFlow. Can do a pretty good job of looking for specific types of volumetric attacks, those reflection amplification attacks. Also all the various flag attacks are actually pretty evident using just layer 4 technology because they the NetFlow itself actually aggregates flags so you can see if there are unusually high numbers of connections with just single flags for instance.
Now the only drawback of using NetFlow as we previously mentioned is that NetFlow is a layer 4 technology so we don’t really have any visibility into the packets except in very limited senses so it’s a lot harder to actually do layer 7 detection. So that is actually a shortcoming. Of using NetFlow for detection. So in terms of detection. In common with both types. The real thing that we want to do. In detection of both types of architecture. Is inline. And on demand. The real thing we actually want to do. Is the mitigation piece. We want to figure out. The good traffic from the bad traffic. Block the bad traffic. And there are various. Kind of high level approaches to that. That we are going to discuss. And then we are going to zero in.
One of the most basic ways. Of actually handling a DDoS attack. Is essentially. Is black hole routing. Which means you say. Okay IP address A is under attack. I am going to send all packets destined to IP address A into a black hole, essentially just having the router infrastructure drop them. This is good in some ways because it means that all the attack traffic is essentially handled and dealt with, and it means that any collateral damage from those large packets to the network are handled; they are dropped very close to the edge of the network. The problem is that as we say completes the attack; what it means is that the service provider or the enterprise themselves have made a voluntary decision. To take that IP address off the air.
And actually do the attackers work for them. And they did that for good reasons. They wanted to save their own network. But they have actually. They have an IP address that no longer routes. And that is really not great. Because it is a very high value customer. That actually pay to have SLAs. Service level agreements. And that kind of thing. An alternative to blackholing. Is a technology called flow spec. And that is essentially. It is a much more granular version of black holing. But it really comes to the same thing. You can block specific combinations of packets. And ports etc. Using flow spec. And it works for some of the basic types of attacks. Notably, some of those volumetric attacks. But anything more sophisticated than that.
Exhaustion attacks it can’t work with and it definitely won’t work with layer 7 attacks, so it’s it’s a little bit better than blackholing but it really isn’t a panacea. And we look for much more sophisticated ways of actually handling and sorting out the traffic. Some customers use content delivery networks, typically for hosting websites that have large amounts of data on them. Cdns themselves are designed to be very scalable, and in some cases cdns are capable of just outsizing a ddos attack. They have a lot of capacity, they have a lot of bandwidth, they have a lot of cpu, they have a lot of compute. It’s really quite hard to use something like a get flood to bring down a cdn because they’re they’re very over-engineered. But again, this only works on web real estate.
There are many other services out there that can be attacked, like dns services that we’ve discussed, sip, smtp, vpns. Cdns are not going to help you with any of that kind of stuff. We’ve already discussed cloud services. Cloud service is essentially what you use for a volumetric attack and it’s just an on-premise device that happens to live somewhere else, so it’s. A useful part of an overall strategy for an enterprise, but it’s not its not anything new and exciting that’s going to make a huge difference. It has the same limitations and capabilities as a regular on-premise device, just with access to generally to more bandwidth and capacity. Then the final mitigation strategy is really what we want to focus on, and this is on-premise DPI devices or as we we refer to them intelligent DDoS mitigation devices or even IDMS.
These are kind of the gold standard of blocking and they’re used by the cloud services as well, and they’re able to handle pretty much all attack types; they protect. Your resources they can have a very low time to mitigation, especially if they’re inline devices and they’re going to give end users the most control and the best end-user experience because you know you have direct control of everything. A lot of customers people find that very important – they don’t want to hand control of sensitive aspects of their network over to a third party or a cloud service that may accidentally over-block, or they don’t they just don’t keep their hands on the reins. That’s really important to some quest some customers, so for these customers, they tend to to be very invested in on-premise DPI devices to actually do all of the blocking that they can locally outside of that that volumetric attack that might block up their their links now these do tend to be more expensive than the other um the other alternatives but again these are the the gold standard. And a lot of customers believe that that’s worthwhile. So that’s sort of the broad brushstrokes of how we, of the different capabilities, different ways of mitigating attacks. And we are going to focus on those, the DPI aspects of that, those intelligent DDoS mitigation devices. And I’m going to give you, for the last section of this talk, I’m going to give you a run-through some of the techniques that we use.
And I’ve split them down by the different layers, because it’s interesting to sort of split them into different layers of the OSI model and look at how the different layers are treated. Because again, the attacks themselves come in different flavors and attack the different layers. So kicking it off with layer three. Layer three is the IP layer. We have access to an IP address. There’s not a lot you can do with an IP address, but there are some very important things that you can actually do with it. One of the most impactful that we have at layer three is reputation feeds. These are often called feeds containing indicators of compromise. They’re actually used in the wider security space for blocking command and control and similar things. But they apply equally well to DDoS attackers.
Because if you have the right research, you’re able to pretty easily figure out what a lot of the sources for DDoS are going to be, whether those be open resolvers for reflection amplification attacks or specific botnets. It’s not that hard to actually insert yourself into a botnet and start figuring out where all the bots live and then engineer that information into a feed, which is kept up to date. And then essentially, you use that to block against it. It can be very easy to do because a lot of the infrastructure out there is very easy to detect. It’s a little harder to figure out whether potentially abusable services like DNS are actually being used for reflection. But again, if you have the right research and the right visibility, you can actually figure that out and that helps you.
Cut down on false positives very significantly if you do have the right background to engineer that into your feed as well. And reputation feeds can be very, very effective. For instance, for the DNS, there are a lot of resolvers out there that are used to funnel traffic or reflect traffic. With a list of that stuff, you can knock down a significant portion of the attack just by looking at layer three. And doing layer three shallow packet inspection is actually a lot less obviously computationally intensive than looking into the entire packet. So generally speaking, if you can knock something down at layer three, it’s better than using layer four. If you can lock something down at layer four, it’s probably less expensive than working at layer seven. So there’s a lot of application for these lower level capabilities.
Coupled with that, we have allow lists and deny lists. These are generally used for adjusting the response and optimizing the response. An allow list will let any known
IPs or unknown. So an allow list will allow IPs through without any inspection. And a deny list will deny access of IPs without any inspection. So they’re sort of like the mirror opposite of each other. And they are used for a couple of different purposes. White lists, allow lists, as they’re now called, will be what you would use if you wanted to pick out some kind of resource that was extremely important. And then you can also use them to do a lot of other things. So for instance, if you’re an enterprise, you might want to whitelist your partners. You might want to whitelist specific infrastructure that you use to maybe call APIs and things like that, which means that if something is on a whitelist, even no matter what its behavior is, it’s not going to get blocked by the intelligent DDoS mitigation device.
Deny lists are essentially used to block things that you know are bad. A lot of customers will generate lists over time, although they’re not going to get blocked by the intelligent DDoS mitigation device. So even some industry focus lists where third parties have actually gathered information about offending IP addresses. And a lot of customers will use deny lists to put them in so that they’re immediately blocked without any other further inspection. And then there’s also an automated aspect to this, a capability called the repeat offenders deny list, which we engineer into our products, which if for whatever reason an IP address is blocked due to its behavior, we’ll then put it on a deny list, a special deny list, which means that from then on, we don’t even have to look at its behavior.
We just know it’s bad and it’ll go on there for a period of time and then get allowed to reoffend. And those are all layer three capabilities. Pretty simple, but also, they can be very effective and they’re actually very easy to implement.
Next, we can move up to layer four. And layer four is really TCP and UDP are really the protocols of interest. And that’s really the protocols of interest. And that’s really the protocols of interest. And once we’re at layer four, we’re looking at flag attacks and ways of handling flag attacks and also reflected amplification attacks. We can build some very simple filters that will actually be very effective in blocking specific types of attacks. So if we’re looking at layer four parameters, we have things like the protocol, is it TCP or UDP.
At layer four, we also have things like the port number, source port, destination port. A lot of attacks can be very reliably identified just by looking at that piece of information. So if we’re looking at the port number, source port, destination port. A lot of attacks can be very reliably identified just by looking at that piece of information. So if we’re looking at the port number, source port, destination port. So for instance, a CharGen reflection amplification attack, which is an abuse of an open CharGen server, is going to generate UDP packets, UDP protocol, and they’re all going to have a source port of 19. And since CharGen is not really, there’s really no justification for using it and allowing it on the internet, it’s very simple to put an inline filter in your IDMS to actually just block anything that has the UDP protocol and is from source port 19. Very simple, but very effective. This is good for some types of attacks, but it’s harder for others.
Even if we do know that they have a specific source port, some types of layer seven protocol, when we’re looking at them from a layer four lens, they generate problems with fragments, which means essentially at layer seven, they are not doing anything to actually limit the size of the packets they’re trying to send. And lower down in the IP layer, in fact, these packets get fragmented. And this happens quite often for specific flavors of reflection amplification attacks. And the problem with filters is that you can’t block on a specific source port or even protocol because that information is only available in the initial fragment. Follow-on fragments are essentially layer three constructs, so you don’t have that information. So filters can be affected, but they’re also quite limited in that they’re not able to block ongoing fragments.
However, some tools, particularly intelligent DDoS mitigation systems, are able to actually do the packet reassembly. So the good news is that once you have the capability to do the packet reassembly, as long as you’re doing that, you’re actually able to block out the entirety of the Layer Four packet, which will be split into several Layer Three packets. Filters are good for that kind of stuff, but there are just some types of attacks where it’s just not possible to use them. For instance, a SYN flood. It’s a layer four type of attack, but you can’t block all SYN packets, otherwise you would just stop all connections happening. Every connection has to have a SYN packet. So you have to do something else when you’re starting to look at how you might block something like a SYN flood.
One possible way of looking at this is, again, looking at the behavior of the source IPs, rate-based countermeasures. You can look at how many packets per second or how many bits per second each individual IP address, source IP address, out there is sending against your server. And you can apply an arbitrary cutoff. You know that a regular user might be clicking a few clicks per second, and that will result in, I don’t know, however many bits per second or however many packets per second versus a bot that’s actually doing its best to do a get flood or some other type of packet blaster or even reflector. They will be sending many more packets much more quickly much larger packets much more of them.
So it’s very easy to actually look at the behavior of each individual source IP address and sort them from into two buckets, a human-looking bucket and an attack traffic-looking bucket. And you base that on a threshold that you set in between the two. And that actually turns out to be very effective for a wide range of attacks. The great thing about this is, again, we’re looking at the source behavior. It doesn’t matter if the traffic doubles to a web server. That’s not going to trigger anything. It’s not going to affect our blocking. What we’re looking at is each individual source IP and how much traffic there are individually. So when you actually end up with twice the amount of traffic, is it because you’ve had a bunch of attackers doing bad things or is it because you’ve just doubled the number of humans doing normal things?
You can check that very easily by looking at the rates. So that actually can be very effective. We’ve also talked about these low and slow attacks. There’s a class of countermeasures that we apply that actually can take care of those as well. These work at layer four, but they also kind of work at layer seven as well. There are two corresponding techniques so that we can look at what’s going on at layer four using the TCP protocol typically, or we can look at layer seven, which we’ll be using something like the HTTP protocol. In either case, we are looking at the total number of source connections that an individual IP address might have, because five or 10 is probably okay, especially with modern browsers. A hundred, a thousand, definitely not okay for a given source IP address.
Those are probably going to be abusive, and trying to cause trouble. So again, we can make that arbitrary determination. And we have tools available to help learn what normal baseline activity is for the networking in question. But once we see an IP address abusing it, we can just tear down and block those connections. Similarly with rate-based, we can also look for how much progress a connection is making. Is it sending a reasonable expected amount of traffic over a period of time? Is it one bit per second? Is it a thousand bits per second? If it’s one bit per second, maybe it’s one of these guys who’s just trying to hold a connection open and not make any progress. If it’s a hundred probably it’s a good guy doing you know, doing whatever he’s normally doing.
Um, again that that’s the sort of thing that you can actually learn what what is normal behavior for a network and then plumb that in and use that to figure out you know whether or not an individual source IP address is a good guy or a bad guy. Another very interesting type of countermeasure is what we’ll call the challenge and response countermeasure, and if you think about Synths in particular, very often spoofed, and if we’re looking at trying to do some kind of rate-based Countermeasure if we spoof our source address, there’s no real way to count up how many packets are coming from a particular source IP address because it’s not the real source IP address and they will be typically be randomized across the entire internet.
So that that is a very interesting type of countermeasure and I think it’s a very useful as a way of defeating our rate-based countermeasures, so we have a different way of handling that, and it’s based around Layer 4 at least, it’s based away that around the TCP three-way handshake. We call it challenge and response. This graphic shows a quick eye, quick pressure of what a three-way hand shake looks like a client sends a syn packet that’s received by the server the server issues a synnack packet in response when the client sees that he sends an akb by the server both sides know that everybody is there and that the sessions has been correctly established what’s happening in the sim flood is that first step
is happening and none of the the well the subsequent if that first step is spoofed then the subsequent step from the server it will send a synag back but it will send it to the wrong ip address it will send it to that spoofed ip address it’ll just get lost somewhere on the internet and obviously The server never gets that third step, the act back, so the server’s sitting there waiting to hear for that act and never gets it, so it’s got a half-open connection that it can’t do anything with. Meanwhile, the client is just sending another SIM packet and then another and another, that’s essentially what a SYN flood looks like.
Now we can actually um address that by um inserting ourselves into the three-way handshake um in order to do that when we actually we see a SYN packet come in instead of letting it through to the server, we’re going to challenge issue a challenge to the incoming IP to make sure that the server is actually Sending it to the server make it prove that it is real and we send the challenge whenever we get that incoming connection, any real TCP stack will respond in a well-defined way, it’s defined by the RFC, the TCP RFC. When we see that exact and correct response, then and only then do we know that that that source address is a real TCP stack, and at that point we say okay, um, we’ll authenticate you, we’re going to put you on our good list and we’re going to let that TCP stack respond to the server, and we’re going to let that connection establish, and from from now on for a period of time, we’ll regard you as one of the good guys and we won’t challenge.
You again, um, the bad guys are people who are running packet blasters not proper TCP stacks or even if they’re spoofing if they’re spoofing they’ll never even see the challenge they’re running a packet blaster they’ll just be blasting out packets they don’t have the full TCP stack they’re not able to respond to that challenge which means that we won’t see the correct response um coming through that we’re expecting for that source IP address which is a real TCP stack and we’re going to let that TCP stack respond to that, which essentially means after a while we’ll just block them; once again, we figured out a way based on behavior of pushing off um these attackers and essentially we’ve just now know them as an ip address that is bad
and we will just block that ip address which is a lot easier than trying to do this challenge and response um every time so the challenge and response um there are many variations on it but it’s essentially it’s it’s called a syn cookie and it’s something that you can you can go google there’s a good wikipedia article on it and it essentially it works by forcing a well-known sequence number in the response and when we see that sequence number we know what it should be and if we see it we know that we know that we’re Talking to a real TCP stack, um, and then finally at Layer 4, um, regular expressions, um, we can do a couple of things with regular expressions or in fact with Layer 4 constructs.
We can use some of the well-known pieces like the source and dest IP, source and protocol. We can actually just use those for scoping right; for instance, we might want to apply a regular expression but only to something with a specific destination IP address or source port or protocol, so we can use that for scoping. And then we can apply regular expressions to match um, you know the rest of the packet and that can be based on payload at Layer 4. We don’t know anything about Layer Seven because this is we’re working at Layer 4, but we can also apply regular expressions to specific header fields so we can look for TTL values and and another various other flags and things like that as well.
And you know sometimes it’s possible to craft these regular expressions because there are certain tells in tools that are used to blast packets and run attacks, and sometimes the regular expression will quite easily filter those out uh and and just basically drop the bad traffic on the floor and let the good traffic through. And so finally, Layer Seven, um this is Really, the the sort of the the the protocols of the internet HTTP, SMTP, the other kinds of layer seven protocols again. We have to build specific countermeasures in some cases that that work specifically at layer seven um and and understand those protocols. And this is really kind of the heart of DPI. But some very similar techniques uh um being used now. We can use rate-based countermeasures quite effectively at layer seven as well as layer four.
The only difference is that at layer four, whilst we’re talking about packets and bits per second, at layer seven we’re talking about layer seven constructs. For instance We might be looking at Layer Seven constructs and we might be looking at the numbers of HTTP requests. If we see thousands of HTTP requests coming in, we know that’s not normal. Um, but we are looking and counting at requests, not just packets, okay? And that’s that’s interesting because we can actually look at um requests coming into the entire server from a particular source IP, but we can also look per endpoint. So whilst we may be able to say something like, well, we don’t, we don’t, we’re not so sure what the right number is across an entire server, it’s quite high, but we’re not sure.
We might know that a particular endpoint, you know, maybe that um database lookup or all that um, you know the generation of the pdf that we mentioned, you know, we can set that to a much lower value because it’s just one specific endpoint and we know that it shouldn’t shouldn’t get hit very often, so we can actually set that lower. That’s because we have the intelligence to understand we’re looking at layer seven; we understand the endpoints that are being hit, not just looking at packets per second and bits per second. Same for things like SIP uh invite requests and floods and things like that. So, again, able to use that concept. Rate-based countermeasures, but what we’re actually doing here is we’re doing the deep packet inspection to understand the layer 7 protocol interactions and then we’re making decisions based on those.
Again, there’s a version of challenge and response that works at layer 7. for HTTP we can also force a layer 7 challenge and response, and a couple of different ways we do that. One of those is an HTTP redirect. And the way that that works is: we wait for the session establishment happens at layer 4, so this will be a well-formed TCP connection. Then the attack will issue a GET request. What we can do is, instead of again intercepting, instead of letting the request through, we can intercept it and send something else back, which is the challenge. One way we can do this is by sending a fake page back that does something something like a 302 redirect.
And again, it’s the same thing: if the HTTP client is real and understands that, it will then issue reissue the request and follow the redirect and reissue a second GET request to those exact specifications. If we see that happening, we know that it’s a real HTTP client. If we don’t see it happening, we know that it’s something that isn’t capable, like some sort of an attack tool that doesn’t have the intelligence to do that. And that’s been very effective over the years, but lately attackers have been getting more capable. And we found that some tools were actually able to follow the redirects. So in response, we engineered in a JavaScript redirect. And that’s same concept, but instead of sending a redirect page, the challenge, we actually send a page which is just a fragment of JavaScript.
And that JavaScript makes a call that forces that same redirect. And again, we wait to see if the redirect comes through. If it does, great. We know that we’ve got a real HTTP client. If it doesn’t, then we know that we’ve got an attacker and we can block. And it’s a lot harder to build a JavaScript stack into an attacker than it is to build a JavaScript stack. So that’s actually a great way of actually forcing attack tools to basically reveal themselves. Another great example of a layer seven technique, mitigation technique, is non-existent domain query flow prevention. This is one that we’ve recently added to address the huge upsurge in water torture. And the way that this works is that we essentially, we look at all the data that we have, we look at all the DNS query and response traffic, and we correlate it.
We look for DNS queries that result in a positive response, which means that what we’re able to do is over time, we’re able to learn the whole landscape of valid domains that work within a given DNS server. And then we’re able to use that information when the actual server is under attack. We already know what the valid responses are, and we’ll just let those through seamlessly. Anything else, we are going to rate limit, and we are going to make sure that any of those attackers, we don’t let enough of that traffic get through to cause any harm. The reason we rate limit rather than blocking, though, is because we’re still capable of learning. If we’re seeing some queries come through, even if they’re not on our list of valid queries, if we actually see one come through and it gets a positive response, we can immediately transfer that to our valid list.
And from that point on, even though the DNS server is under attack, it’s now on the whitelist essentially, and we’ll get through. So it gives us the capability of reducing the traffic, to a manageable amount, but still gives us the possibility of continuing to learn if there’s some very infrequently used domain out there that just happens to come in for the first time in the middle of an attack. And then finally, again, at layer seven, we can also use regular expressions. And the advantage of layer seven and regular expressions is that we’re able to make these operate on specific constructs within the layer seven protocol because we’re layer seven aware, we’ve done the DPI to understand that and map it.
So for instance, for DNS, instead of just looking at specific bytes in the field, we can actually check for specific resource record types. We can check for specific names, queue names, and then we can use that information to string together expressions ands and ors and drop or pass based on those particular regular expressions. Same for HTTP, we can look at specific URLs, specific headers. This is, these are, these are the layer seven constructs that we’re looking at because we’re able to do that DPI and figure out what’s going on deep within the packet. So really, that’s it. We’ve talked about the DDoS history of the landscape. We’ve talked about various types of architecture. We’ve also talked about detections and how we detect, and then we spent some time talking about the various mitigations at layer three, layer four, and layer seven. And that is all I have to say today. I thank you for listening and those are my details there. If you have any questions, please feel free to reach out to me. Thank you.