 All right, it's noon, everybody. I'm going to let a couple, a minute or two go by and let a few more people filter in. If you'd like to follow along in the slides, I've already uploaded them to SlideShare and it's linked to you from the session. All right, let's get started, shall we? Welcome, everybody. It's nice to have you here. So many faces, some I've met before. There's some familiar ones in the audience and there's a lot of new people, but it's great to be back at DrupalCon. Hope you're all having a great convention. Let me introduce myself. I'm Suzanne Aldrich. I'm a solutions engineer. I work at Cloudflare for the last couple of years and prior to that, I've worked at a couple different Drupal hosting companies so I've seen a little bit about what it's like having DDoS attacks hit your infrastructure, hit your website. It's not a fun day. Nobody likes it. And the purpose of this talk is to familiarize you with some of the terminology and some of the technologies involved with launching DDoS attacks, the methodology, and also what can you do to mitigate it? What kind of strategies can we advise? So to get started, DDoS attacks are making headlines all the time. We hear about them and it's an ever-increasing thing. They're getting larger and larger and it's becoming increasingly important as more businesses move online. They have a lot of vital operations on their websites. They have web applications. There's APIs and they're all possibly targets. So this is important for you to understand so that when something like this happens to you, you have some tools at hand potentially to help mitigate that. There's different kinds of DDoS attacks. They can be roughly divided into some different categories and I'm gonna help familiarize you with what these categories are. So from a high level, and I mean very high level, all that a DDoS attack is is a traffic jam. It's an attempt to make it difficult for normal traffic to get through by clogging roadways with malicious traffic. And it prevents the traffic from getting to its desired destination, which is gonna be your server that's serving your web app, your API, et cetera. Let's break it down a bit. Distributed denial of service. It's a malicious attempt to disrupt this traffic and it has a target. There's gonna be a targeted server. So there's attackers and there's a target. And it does this by overwhelming the network or any kind of intermediary point surrounding infrastructure with the flood of internet traffic. These attacks are achieving effectiveness by utilizing multiple compromised servers or systems as sources of the traffic. That's the part that makes it distributed. Types of machines that can be exploited include home, office computers, servers, VMs sitting around that nobody updated. Might be an IP camera. Could also be something like a malicious app running on a mobile phone, mobile devices. Other places that we see are also just any kind of any kind of a networked device. The motive behind these attacks are varied. Used to be more often it was political, social, some kind of animus against whoever was running the site, the API, usually a website. These days we're starting to see more financial reasonings. And one of the things that I believe has driven the rise in some DDoS attacks is the emergence of cryptocurrencies. Cryptocurrencies allow people to get paid in a semi-anonymous way. There's still ways to track who received the payment which is how law enforcement gets to the bottom of who is the receipt of that wallet. But people will actually literally put their crypto wallets in email ransom letters that they send to targets. And so one pattern that we often see is a DDoS ransom note like this one that I've attached there with ever so wonderful English in it explaining how they're gonna give you a demo attack to give you an idea of how painful it's gonna be for your website to go down. And if you don't pay up X amount of Bitcoin, in this case I think it's eight Bitcoin, then they're gonna take you down for an interderminant amount of time. And that could really be very frightening for somebody who receives one of these attack letters. So our piece of advice at Cloudflare is never pay a ransom note. It's not like don't pay attention to it but don't pay a ransom because that's just encouraging the attackers. They're gonna keep going around collecting money and funding these kinds of operations. They use this money to do things like purchase time from these internet stress devices, these networks or these services, these booters, and they utilize these booters to launch their attacks. So don't pay the ransom. Another thing to keep note of is that these attacks occur for every industry. It's not isolated to just political candidates. It could be your mom and pop store and you can imagine how worrisome that can be especially if a small and medium business is making a lot of money on the internet and now they're being faced with some enormous ransom, thousands and thousands of dollars they might consider draining their bank account. But also large enterprises face these all the time as well and it's brand damaging. We've had a case of somebody who was on our network during Thanksgiving and for 10 days straight somebody went and attacked them with over 200 million packets per second and 400 gigabits per second of traffic and they would just pause each night to go to sleep and then the next day they would go and keep attacking but that's just kind of an example of what a typical attack might look like or a very determined attack. Eventually they give up because they're on Cloudflare and you can't win. I wanna show you a little bit about some of the historic attacks that Cloudflare has helped mitigate over the years. Cloudflare engineers have helped mitigate some of the largest known DDoS attacks in the world. We've been doing this for over five years. It's actually our seventh birthday this week so happy birthday to Cloudflare. In the winter of 2016 you can see we mitigated the largest layer three DDoS attack to date. Not only were we able to mitigate it but we were able to analyze it which is extremely helpful to understand the attack. DDoS attacks are taking all kinds of shapes and forms. In the middle attack you can see a 400 gigabit per second amplification attack where they use 4,500 NTP servers to attack from a mere 87 megabit per second source server. That's kind of an amplification attack. That's where you take a small thing and make it bigger. It's a little funny now to look at it but the third panel shows the spam house attack. That was 120 gigabits per second and at the time that was a big attack. But we kept their website online. With the evolution of DDoS you can see that we're growing. Each year they get bigger and bigger and bigger and by now they've way outstripped the capacity of any typical network link to be able to absorb this sort of attack. And in addition they've moved around on the layers of the networking model. They used to be more on the volumetric layer three and four attacks. We've gone up to NTP reflection and now an emerging landscape of IoT devices that have been potentially infected with malware or have weak passwords and are taken over as botnets. Those are enabling people to launch these very large layer seven attacks from all over the world, highly distributed attacks coming from hundreds of thousands of IPs. We see an L4 or L3, L4 DDoS attack every six minutes. We see an L7 DDoS attacks every eight minutes. So that's about 80,000 attacks a year for every six minutes or 60,000 attacks a year for every eight minutes. So we're seeing just a very large scale of these attacks. And to give you an idea of the size of your average attack it's not uncommon for an L3 attack to be around 50 gigabits per second which is easily five times what your typical router or server internet connections can take. DDoS attacks, how do they work? It requires an attacker to gain control of a network of online machines in order to carry it out. As I was describing computers, other machines are infected with a malware. Each one is being turned into a bot or a zombie. The word botnet is a portmanteau of robot plus network. So it's botnet. You can see some examples of devices that can be taken over and a lovely illustration showing you that the attacker is controlling all these from some kind of central command and control system. If you deconstruct malware you can find interesting bits and pieces that point out how that command and control structure is laid out. That'd be very interesting. So basically once the attacker gains control of the machines they send instructions through their command and control infrastructure to the botnet. The instructions are usually something along the lines of the IP address of the target. And then the little bots go about their business and they attack it depending on whatever protocol or function or script that these people are using. When the IP address of the victim is targeted by the botnet each bot will respond by sending requests to the target and potentially cause a targeted server or network to overflow. Its capacity is completely overrun. And that is exactly what a denial of service is. It can't take any legitimate traffic. It cannot answer a legitimate request. So at this point the attacker has succeeded in taking the target down. Because each of these devices could potentially be a legitimate client it could be very difficult to separate out the malicious traffic from legitimate traffic that you get from normal kinds of web clients or other sorts of applications. So what are common types of DDoS attacks? Let's dig in a little bit. What are the categories that we see? To begin to even really dig into that question we need to start talking about the OSI model. This is a model, a conceptual model that was designed to help give some sort of structure to all the parts of networking. So different DDoS attacks attack different layers of this OSI model, Open Systems Interconnection Model. Let's go through each layer kind of briefly so you get an idea. It might have been a long time since you studied network layers. We start from the ground up and it's like building a house. Each layer serves a function. So at the bottom you have the physical layer. That's the physical medium for transferring data. Cat5, fiber optic Wi-Fi, it's the bits. The next one is the data link layer. I have no idea what this does. No, just kidding, it's switching. Layer three is a network layer. That's where a lot of DDoS attacks happen and this is essentially the part where we decide what path a particular bit of data shall take. And this includes bits of hardware like network interface cards, routers. It's a combination of software and hardware. This is where IPv4 and IPv6 addressing occur. Layer four, the transport layer. That's important because that's essentially where our transmission protocols come in, TCP, UDP. This is where port numbers become important. Layer five, the session layer that manages the session. So building it up and breaking it down. Layer six, we have the presentation layer. This is kind of a minor layer but it's important in terms of formatting data and parsing it and this is where encryption happens. And then finally at the top, our favorite layer where pretty much everybody who's working in Drupal is familiar with this is the application layer, L7. And this is the human-computer interaction layer. So well-known protocols here are HTTP, SMTP, and DNS. It's a little anti-intuitive but DNS is an application layer protocol. So attackers are exploiting the different layers. They're exploiting them on layer three with flooding, reflection, amplification attacks. On layer four, they're using protocol attacks like TCP SIN flood. And on layer seven, they're taking advantage of hitting refresh a bunch of times or as complicated as something like slowloris, I guess is complicated to script. And then you have your DNS flood attacks. And I think the important takeaway is to understand that the attacks are layered and they don't always just drive this kind of attack, that kind of attack. There might be multiple attacks happening at the same time, multiple layers being targeted. So it can be attacking different parts of your infrastructure. With the volumetric DNS flood attacks, you're having a large volume of flooding of your DNS infrastructure and that's causing people to not be able to even look up the address for your website. So you're basically interrupting that lookup that happens when somebody types an address in the web browser. Browsers making a DNS lookup. Well, DNS server is not resolving. Your authoritative DNS is not responding. Nobody can go to your website. Amplification, in this case, the target is basically having their IP address spoofed and the DNS queries are happening in such a way that the answers to them are much larger than the query that was sent out. And the answer is set to this unlucky target who gets all this traffic and that's been amplified from a small amount to a large amount. So it doesn't take a lot to actually launch one of these attacks, just a well-crafted DNS query. And then on the bottom here, they're illustrating an HTTP flood, which is probably something you all have experienced or seen in logs before, where you'll see some requests, some particular endpoint being hit over and over again. Maybe you have some different refers, maybe you have some different slight variations on the query string, but that's what those look like. And you see those in server logs, unless you're blocking them. And all of these attacks are impacting the application's ability to be reliable and to serve it performantly. So let's go and talk about volumetric attacks. And I'm gonna talk about a particular kind of volumetric attack, which is a DNS amplification attack. These are neat, I like describing them. I will say that there are fewer and fewer DNS amplification attacks over the years because there are fewer and fewer open DNS resolvers, but it's still very interesting and we should discuss this. So this category of attack, essentially, it's attempting to create congestion by consuming all the available bandwidth between the target and the larger internet. Large amounts of data are sent to a target by using amplification or another means of creating massive amounts of traffic. So amplification is one way you can just directly cause requests to happen as well. Botnet would be a good example of that, layer seven botnet. DNS amplification attack is like, if someone were to call a restaurant and say, I'll have one of everything, please call me back and tell me my whole order. And the callback number is actually the target's number. So the restaurant's gonna go ahead and call a target and read everything on the menu and they're just gonna be sitting there going, huh? With very little effort, a long response is possible. And essentially how it has worked is that the request is made to an open DNS server with the spoofed IP address, which is the real IP address of the target. Just so that you know, spoofing IP addresses is still a really big problem on the internet. And there are some different projects out there that have done analysis on what networks allow spoofing. And it turns out that presently, there are about 25% of the world's networks are allowing spoofing of IP addresses. So of course, a recommendation is to, as a network administrator, clear that up. You shouldn't allow anybody to spoof an IP address from within your network. If it's not legitimately within your range, you shouldn't be allowing that to be sourced from your network and send outward. The next style of attack are the protocol attacks. A really good example of that would be a SYNFLED attack. And protocol attacks are state exhaustion attacks. They cause a service disruption by consuming all the available state table capacity of a web application server or intermediary firewalls and load balancers. These attacks are utilizing weaknesses in layer three and four of the protocol stack to basically render the target in acceptable. And I think a really good analogy for this is it's a worker in a supply room. So what's going on is you have a worker who is the target and they're being sent this initial SYN, the SYN packet. And the worker is coming back and giving them acknowledgement, but the original attacker does not complete the handshake. So what happens is the target leaves this connection open because it thinks it might eventually get an acknowledgement and then it proceeds to not ever get it. And what happens is that you end up with all these different SYN packets hitting the target, leaving these open connection states and the target is quickly consuming all of its memory resources. And the whole state table is filled up with these connections. This attack exploits it often times with a spoofed source IP address, which makes it very difficult to locate the source of the attack as well. You could probably work with an ISP to find that out, but it's a lot of investigative work. Application layer attacks, these are on the order of your web application. And so a simple example of that would just be hitting refresh over and over again. And if you had a really weak site, it would never be a Drupal site of course. That site might be taken down because it's unable to essentially respond to all these particular resource requests in a timely manner and eventually it kind of becomes a little overburdened. So the goal of these is to exhaust the resources of the target. They target the layer where the web pages are generated. The server is having to pull these resources every single time there's a request. It might be just files it's looking up. It might be a database query. So there are a lot of things that are going on to make a webpage happen. And that's what this is taking advantage of. Be expensive for the target server to respond. I should note that it in the past has been expensive for the client, the botnet or script to actually perform some of these attacks in the past. However, as computing power arises, of course, their ability to perform these attacks also increases. So that's one of the reasons why in the evolution of DDoS attacks we're seeing more and more layer seven. They're also very difficult to defend against. It's hard to tell the difference between a legitimate request and something that's not legitimate. What if it's just a sale and you publish something and marketing is very happy with all the eyeballs they've reached and suddenly your website's seeing a giant influx of traffic. How do you tell that apart from some script kitty? And it's not an easy question to answer. It takes a little bit of tuning and I'm not convinced that anybody's come up with the perfect solution but we're definitely trying. Simple implementation, it's the same URL over and over again. It's the same kind of user agent, same refers. More complex, you'll see randomization of these refers. You're gonna see different query strings, different endpoints, which makes it even harder to figure out is this legitimate or not. How are DDoS attacks mitigated? It's important to understand here that no one single method is gonna be capable of protecting against every variety of DDoS attack that's ever existed. So one must keep in mind that this is gonna be a layered approach. You're gonna have to probably implement multiple things in order to prevent all these different potential attack factors from being vulnerable points for your application or your network. The more complex the attack, the more likely it's gonna be difficult, as I mentioned, to separate from the normal traffic and that's actually the goal of the attacker. They're trying to blend in as much as possible. Anything that the attacker can do to make the mitigation inefficient, they're gonna go for that. They also wouldn't mind it if you were to block out legitimate traffic because that is furthering their goal. The whole purpose of this is to block legitimate traffic. So if you're dealing with an attacker who's trying to blend in and your mitigation strategy isn't good enough, isn't able to make that distinguishment, then you're essentially accomplishing the attacker's goal for them. One method, it's a very blunt method, is black hole routing. This is something any network admin can do and actually this is something that could happen to you from your upstream, your ISP of your service. If they start seeing a large influx of traffic and it's starting to overwhelm their servers, they're probably gonna cut you off, they're gonna black hole your traffic. It's not a very good day. You're gonna have to definitely pick up the phone for that one. There's gonna be a lot of pagers going off. Something where you would want to have very specific criteria about what traffic is being black hole. The next methodology, and again, this is just part of a layered approach, would be rate limiting. Just limiting the number of requests that can get to your server can help prevent it from becoming exhausted. And yes, there might be some legitimate traffic that gets caught up in the mix, but you've saved your server for another day. Another request that could come through after this one's been kind of delayed. So this is definitely something that is, it's helpful. It's really better for things like brute force attacks or just slowing down web scrapers, but it can also help in this situation as well. So we do recommend rate limiting. A web application firewall is also very useful, especially when addressing any kind of layer seven attack. This is a way to discriminate against traffic in a kind of a targeted way. You can look at the exact user agent. You can look at particular IP ranges. You might wanna look at particular request types or query strings or something that's matching a pattern. You might be able to put some kind of regular expression into play here that can match a lot of the different randomness that these attackers are injecting. And I think one thing to keep in mind is that if you implement a WAF solution, you really need to make sure that it's easy to deploy new custom rules because in an incident, one of the things you're not gonna wanna do is waiting for a WAF rule to compile or deploy. Finally, I'm gonna talk about anycast network diffusion as a method of mitigation. This is something that Cloudflare uses quite extensively and is one of the reasons that we're able to absorb so many attacks. Let me just quickly back up. So there's Unicast where there's a one-to-one relationship between an IP address and the service. And then there's anycast where all these different servers are actually broadcasting the same IP address. And the way that internet routing works with BGP is that you basically go for something that's gonna be the shortest path. So the network essentially picks its own path and we're able to distribute very efficiently with really no work on our part, all this attack traffic through multiple servers instead of just routing them to one. And a good analogy for this is like a stream that gets channelized. So there are multiple channels for this stream and it's just naturally flows through these different directions and it doesn't concentrate on one server or set of servers. Now the reliability of an Unicast service to distribute a DDoS attack is dependent both on the size of the attack and also the network capacity of the Unicast network itself. So those are important things to look at. What kind of size DDoS attacks are you wanting to mitigate for? You have to compare that to the size of the service that you're looking at. For point of reference, Cloudflare has a 10 terabit per second network over that. And that's a complete order of magnitude above the largest known DDoS attack to date. So I wanna get into a little bit more of a deep dive into some of these different DDoS attacks, exactly how some of them work. One that you've seen commonly is a UDP flood attack. UDP is like the lesser known cousin of TCP and I would tell you a UDP joke but I don't know if you'd get it. So this is a type of an attack where these user datagram protocol packets are sent to a targeted server and the whole aim is just to overwhelm it and limit its ability to respond. The firewall protecting the service can also become overwhelmed and exhausted from this kind of attack. So you have to pay attention to all the layers of your infrastructure. How it works is that it takes advantage of normal UDP operations. With normal UDP, a server is essentially checking for running processes at particular ports. It's seeing, is anything listening here? And what happens is that if nothing is listening on that port, the server responds with this ICMP ping response and it sends that back to the center of the UDP packet so just let them know the destination's unreachable. I think a good analogy for this is a hotel receptionist who's receiving calls at the front desk for some guest. So the receptionist picks up the phone. Somebody, I'm looking for this person, I'm looking for Suzanne, can you connect me to her? And the receptionist goes and calls my room and turns out I'm not available. Then they go back to the phone and say, yeah, she's not there. Meanwhile, another call comes in and then another one. And quickly, the receptionist is not able to keep up with this falling of calls, becomes exhausted and probably quits and walks out the front door. So you can see that this becomes a quickly overwhelming proposition. The way that these are actually executed is that an attacker is gonna utilize this to go through all the steps. And what they're gonna do is they're going to not use their own real IP address, it's gonna be spoofed. But they're gonna spoof the source of the UDP packets and they're gonna make it hard for you to figure out where they're really coming from. The target's resources are gonna be exhausted very quickly and there are a couple of mitigation strategies that can be taken. One thing that a lot of operating systems do is actually limit the response rate of the ICMP packets in order to disrupt any kind of DDoS attacks. But one drawback is that during an attack, legitimate packets could also get dumped. So if you're running a legitimate UDP service, it's gonna be difficult to tell the difference between the ones that are coming in looking for an actual DNS response versus ones that are coming in with a spoofed IP address. You're not gonna be able to really distinguish between those. And any kind of mitigation at the server level also is gonna be quickly overwhelmed if any upstream is becoming overwhelmed as well. So how Cloudflare mitigates UDP is, it's actually pretty simple. We just drop all the UDP packets that have nothing to do with the DNS and that's it. Because of our Anycast network, we're also spreading it across multiple servers. So no one server is gonna be getting all these particular UDP packets. And so we have sufficient capacity to handle a UDP attack of any size. What is a SIN flood attack? So another terminology for this is a half open attack that refers to the way that states are left when the connection is opened and it's left open and left open and left open and never closed. This attack is just making the server unavailable to legitimate traffic and it's taking advantage of the SIN protocol. So we're sending initial connection requests and we're overwhelming all the available ports. And then the targeted machine is gonna basically get really, really slow. It's not gonna be able to handle all these different connections. Normal TCP connection, again, client sends a SIN packet, server responds with SIN AC packet. Client returns an AC packet to acknowledge the receipt of the SIN AC. And then after this whole series of packets have been sent and received, the TCP connection is completely open. And the attack is a little different. The attacker is sending a high volume of SIN packets. The target is responding to each and every one of these with the SIN AC. And then waits and waits and waits and nothing happens. It never gets this AC back. All these connections are taking up space in the target server. In networking, when a server is leaving a connection open but the machine on the other side is not, the connection is considered half open, which is why they call it the half open attack. These SIN floods can occur in a few different ways. One of them is a direct attack. This is one where they're not even bothering to spoof the source IP address. They're just sending out these SIN packets, target receives, and then what the attacker does, which is kind of clever, is they'll have some kind of firewall setup where they're filtering, so they won't receive that SIN AC packet back, so they won't get flooded with their own attack. And that's how they've performed it. These are very uncommon because they're not spoofing their IP address and it's trivial to stop this. You just need to block that IP address. So we don't see a lot of those. We've moved on. Now you're seeing a lot more of the spoofed attacks. So in this case, they're sending the initial SIN and they're spoofing the IP address from which this packet is being sent. And this makes it more difficult to inhibit the attack. It makes it difficult to mitigate. It's not impossible to trace these packets back to their source, but you're really gonna have to talk to your ISP about it. You have to call them up. It takes a little bit of network engineering to understand where this attack's coming from. But if they're willing to help, you might be able to get an idea of who was trying to attack you. The third kind, which is becoming more and more common, is the DDoS, the distributed SIN flood attack. In this case, they're essentially using the botnet that they've got control over to launch this attack. And in this case, it's kind of like a direct attack in that it's not really necessary to spoof the IP address. They're taking advantage of the fact that these are not their own computers. So it doesn't matter to them if these particular end points end up dropping off. But sometimes they'll even spoof these particular bots as well. And then it's getting even harder. And if they're using something like the Mirai botnet, they probably don't care about spoofing it. But in other cases, they might, depending on their needs. These kinds of attacks take substantially less capacity to launch than some of the other sorts of attacks, the volumetric flood attacks. And that's because the attacker has the ability to check out the behavior of the target and essentially determine what the actual size of the backlog queue is for these connections. And once they've determined that, then they can actually tune this attack such that they're sending the minimum amount of packets out to really take down the target. So this is pretty interesting. To mitigate a sin flood, there are some different methods that you could take. One of them is just increase your backlog queue. And this is something that is pretty simple to do. You just add more memory, essentially, make the queue bigger. Eventually you're gonna run out of memory though. So this can really only go so far. If there's not enough memory, you're gonna eventually gonna have poor system performance and get really sluggish, but maybe not totally down. Slightly better than nothing. Another methodology is this recycling of the oldest connection in the queue. So basically what happens is that you're taking the oldest half open connection slot and recycling it. And then that way you can kind of cycle through each of these connection slots that never really got fully opened. And that way you can receive future packets and hopefully they're legitimate and not more attack traffic. However, this is gonna fail if the attack volume increases because of obviously upstream architectures can be overwhelmed as well. Another strategy is gonna be sin cookies. Sin cookies is basically a way of attaching some information to the packet such that we can just dump the table that stores the initial sin. And if we get an act back, we can actually reconstruct the original connection. So we're able to, it's kind of like refilling the backlog, but it's using information that we're attaching to essentially reconstruct the connection based on an additional act that has to come back from the originating client. It's definitely better than a DOS, but it does lose a little bit of information about the TCP connection. Finally, I list here using a proxy service, Cloudflare's a proxy service. The way that we mitigate these attacks is that we're standing in between you and the attacker and we're doing all the handshake stuff and we're actually not forwarding any of the TCP connection into the origin until the handshake has been fully completed and we've got a real connection opening and that's how that works. So DNS floods, this is becoming more and more common. Now DNS, hopefully you know, is like the phone book of the internet to get a website, you type in an address. There has to be a lookup to find the actual IP address of the origin server or some load balancer or other infrastructure. If you flood a particular domain's DNS servers, however, you can disrupt the DNS resolution for the website. If you can't find the phone book, you can't make the call. So by disrupting DNS resolution, DNS flood attack will essentially compromise a website or API or other applications ability to respond to legitimate traffic. These attacks can be also very difficult to distinguish from legitimate traffic because these queries are coming for legitimate addresses, host names that are being served by the authoritative server and how do you understand who's making the bad query? So that makes it pretty challenging. In addition, this traffic can be very high volume but coming from a very large distribution of endpoints so that can make it also difficult to understand if this is something that's malicious or not because the actor has spread out the attack amongst multiple bots. Here's an illustration showing you in pictures. I like pictures, they help me understand a little bit better. So here you see the attacker, they've got the botnet. They're directing their botnet to attack the DNS resolver. Now a legitimate user is trying to make a connection to that DNS resolver to get to the address of the website and they can't because the DNS resolver is too busy talking to the bad guy. That's how that works. One of the issues with these kinds of attacks is that first of all, they're rising with the rise of IoT. As IoT devices are spreading and many of them are very insecure, they come with these really ill-advised default password username combinations. Some of them are easily hackable. What's ended up happening here is that these kinds of attacks are becoming more and more common. And it's really hard to protect against because this is having to do with your DNS infrastructure. Your upstream might be quickly overwhelmed and if you have a service instead of running your own DNS servers, then you have to watch out that they have the capacity to handle this. And also it's probably wise to make sure they have the network architecture to handle this. And this is of course one of the main reasons why Cloudflare is using anycast. We're able to effectively spread this attack to each of our servers and there's no one server that's receiving the brunt of it. And your website, if it's using Cloudflare DNS, will continue to answer. To give you an idea of Cloudflare's scale, at this point we're handling about 10 million requests per second, 10% of internet requests. We're handling 38% of all DNS queries. And we have 115 data centers located spread out globally. So that really helps keep the attackers in the country of their attack. It's not getting outside of their country. As I mentioned, we've got the 10 terabit capacity. Handling so many different actually unique visitors at this point, we're up to 2.5 billion. And I keep having to update these numbers on my slides. Six million websites, apps and APIs in 150 different countries. Just to give you an idea of, you really want to be looking for something of this scale to be handling your DNS, right? We're coming to the close of my slides. As a reminder, there's a contribution sprint. Please join, contribute to Drupal, make it better, make it a better world. And now I want to open up for questions, concerns. Also, if you have any stories, I always think that war stories are kind of interesting. If you're able to share, feel free to anonymize your customer or client, but really would like to hear what you have to think about DDoS attacks in this day and age. And if you're interested, I can also talk a little bit more about some recent attacks that we've been handling. Any other questions? Yeah, thank you. On any CDN service offers mitigation of some sort of additional service, the order C panel subdomain pointed to their actual IP address, your service and your attempts to mitigate the attack are quite useless because it is quite easy for any attacker to attack that direct address. And I have not seen a CDN network that would warrant the users against service of my domain, the DNS stop and look the FTP and there is not even a warning that this is a potential risk for my site to be attacked. One warning that we do provide is if you make a DNS entry and you enable the proxy for that particular IP address, if you were to disable the proxy for a different DNS entry that points to the same origin, we will provide a warning directly in there for the user then user to see. One of the recommendations that we give to anybody who's trying to protect us is to make sure that you're separating your concerns out into different origins. And it's also important to note that different services mean different things to different stakeholders. I think that in this day and age, a website in its uptime is probably more important for most like business owners than their FTP service. So it's obviously important to try to make sure that you're pointing to different origins for each service. I mean, some of the, I don't have an average duration number right in front of me, but we, as I mentioned, we sometimes see attacks that just span days, weeks that Thanksgiving attack was 10 days straight with rests at night when I guess the guy went to sleep. Sometimes you'll just see a few minutes worth of attack traffic. Those demos that those ransom note writers do, they'll just tack you for a short period of time, an hour or two, and then let off and give you an opportunity to answer your email and find their Bitcoin address and potentially pay them. But yeah, it could be hours, it could be days. We don't pass that traffic back through to the origin though. So hopefully they don't have any kind of service disruption. One thing to note is that it's our birthday week and on Monday we announced unmetered DDoS mitigation for any plan level, including the free. So if your client's under attack and maybe they don't have budget or you're exploring budget, you can sign up even under the free plan and receive relief from any kind of a DDoS attack that you may be suffering. Maybe with the slight exception of layer seven which might require a little more tuning. In that case you might wanna consider enterprise plan where you'll end up talking to a solutions engineer like myself and we'll tune the rate limiting solution in order to make sure that some of these different expensive queries. And I know how it is with Drupal. Not everybody has the opportunity to go and make sure all their views queries are cached. But it's important to do that. You've got to try to harden your Drupal. That can really help bring up the resiliency on the layer seven side. And it's also important to try to cache as much as you can on the CDN. So it's all living on the edge and it's not something that has to go back to the origin to produce that kind of response. Alex. You have much seen it. What we do when we have, we don't have dedicated IPs for every customer. Some customers like the free customers are on shared IP maps. What we do when we're experiencing a impactful attack against any of those maps is we perform what is known as scattering. And what this does is essentially, it's kind of like a binary function where you divide and divide and divide until you figure out who was the actual source or the actual target of that attack. You can isolate that particular customer away from the other customer. So that's one of the ways that we avoid having that noisy neighbor problem. Yes. So in a bunch of the attacks you mentioned, IP spoofing was kind of an important component of that. How does IPv6 affect that? Does it make it harder to mitigate or are there parts that make it easier to address? You know, that's a good question. I'm not sure if I know the answer to that question. I'd be happy to find it for you and talk a little bit afterwards and I can definitely inquire. I will note that as much as Claude Fuller is trying to increase the adoption of IPv6, it's been one of those kind of stubborn standards that seems to have this rollout that's been taking like, I don't know, has it been a decade or something like that? We've run out of IPv4 in North America. I don't know how much IPv4 you have left in Europe, but it's all allocated. So yes, it's definitely a concern and I'd assume that if a network is allowing a spoofed IP address, I probably doesn't matter as much, but I would assume that most networks are better configured for IPv4 at this point. We'll see how it is in five years. Anybody have a war story you wanna share? I've seen a few interesting layer seven attacks in my time. Sometimes they're attacking, you know, little tiny mom-and-pop site. Sometimes it's police stations. There's different reasons why people might be doing this, but I've seen anonymous attacking websites and you know, it can be.