🚚 Account level WAF + Adaptive DDoS Protection & Advanced DDoS Alerts

Hello everyone and welcome to Cloudflare TV. My name is Michael Tremante and I'm here today with Omer to talk about quite a few topics that we just launched on GA Week. Specifically we've got a number of DDoS updates we want to share with you all and we also want to talk about our new account-based web application Firewall. Before we jump in though, Omer, do you mind a quick introduction about yourself? Sure, so hi everyone. Thanks for tuning in. I'm Omer, the product manager for Cloudflare's DDoS protection service. Basically my team is responsible for protecting Cloudflare's network and our customers against DDoS attacks, which is distributed denial of service attacks across the entire network and application stack. Cool, perfect. And on my side I'm also on Omer's team just like all product managers and I'm responsible for the web application Firewall. And before we jump in, a quick reminder to anyone listening, if you do have any questions around the topics we're discussing today, feel free to email livestudio at Cloudflare.tv. If we have time we'll answer them towards the end of the session. If not, we'll answer definitely asynchronously after we complete the session and just reply directly by email. So let's start with DDoS side of things and before we talk about some of the updates, what's the high level view? What is DDoS and what do we do in the field of DDoS mitigation? Just to set the scene. Yeah, so a DDoS attack, again a distributed denial of service attack, is a type of cyber attack that basically attempts or aims to take your Internet property down. So the goal is to send as many requests or basically as much traffic as possible to jam your Internet property, to kind of take it down, to crash it, so your legitimate users can't access it. That's kind of the goal of a DDoS attack. There are many types of DDoS attacks, many ways to launch it, many methods and vectors. And the way that we protect against DDoS attacks is basically using our automated detection and mitigation systems. So these are systems that will constantly analyze customer traffic. They take basically request samples and packet samples and also response samples from the origin. They analyze that to identify attack patterns. And then when an attack is identified, a mitigation rule will be installed in line to mitigate that attack very surgically. This system is kind of always running across our entire network to protect our customers and it's also configurable. So there are many levers and knobs that they can tune and tweak to kind of customize it for their Internet property and their traffic. Got it. And so if I'm a user or let's say I run a website and I want to, or better, I've received a ransom note or something along the lines of I am going to receive a DDoS attack, all that's required is to put my website behind Cloudflare out of the box or is there normally other things I need to do? Yeah. So the DDoS protection runs out of the box. It's enabled by default automatically. But one of the nice things about Cloudflare is that there's also a bunch of other tools that you can use to protect your website or your IP application or your network, whether it's the web application firewall or the custom firewall rules and rate limiting and the security level and a bunch of other features like under attack mode. And even caching can also help protect your website because if you use caching to a high degree and then basically our network becomes your server. And so it doesn't matter how many requests hit it, we will serve it and your origin server will be protected. Got it. Okay. So let's talk about some of the announcements. I think, well, I was aware, but probably a lot of the listeners today are aware that we've always had some sort of DDoS alerts triggered by the platform. And I've actually received a couple myself from some of our demo environments, but also some of the websites I have behind Cloudflare. So if Cloudflare kicks in, we receive an alert. But as part of the announcement today, of course, you wrote about advanced DDoS alerts. So I guess what's that all about? What sort of improvements or problems are we trying to solve with the advanced version of the alerts? Yeah. So like you said, we have DDoS alerts and those are available to everyone. Basically, it'll trigger a real -time alert for a DDoS attack that targets any and all of your Internet properties. And then the problem that we wanted to solve or what we wanted to do to help our customers that manage many Internet properties, because if you manage one or two Internet properties and they come under a DDoS attack, you'd probably want to be notified so you can take a look to ensure that the malicious traffic is being mitigated and that your legitimate user client is not being impacted because downtime or disruptions converts or translates directly to impact to revenue and reputation. Your users won't be able to access your website and so on. However, if you're like our more larger customers that manage anywhere between hundreds to hundreds of thousands of Internet properties, then receiving a notification for each one of those that comes under attack might become too noisy. So one of the things or one of the features or capabilities of the advanced DDoS alerts is to actually select on which Internet properties you want to be alerted on. So when an Internet property or your website, your mobile app, your API gateway, or your network, your UDP server, no matter what it is that we're protecting, you can decide if you want to be alerted on it and also who should be alerted on it. So you may have some Internet properties that are managed by one team and some that are managed by another and that way you can direct webhook integrations or pager duty integrations or just define to receive emails for various Internet properties. That's one thing. The second thing is also to be able to define the attack rate. So the standard DDoS alerts only or will trigger an alert for almost any size of DDoS attack. There is a minimal threshold just to kind of avoid spamming your inbox, but in general you can't really configure more than that. And some of our customers want to be notified only on very large attacks that matter to them, you know, the very highly volumetric attacks, and some want to be notified on every single attack. And so we've also added the ability to define the rate of the attack to be notified on. So this is the request per second rate, the bits per second rate, or the packet per second rate. And lastly, some of our customers that manage networks might manage, for example, VoIP infrastructure that is mostly UDP. And so they'd want to be only notified about attacks over UDP and care less about attacks over TCP, for example. And so being able to select the protocol is another kind of filter that we've added to these alerts, to the advanced alerts. Great. So basically, a lot more flexibility. And in fact, I remember for the standard DDoS alerts, I didn't even have to set anything up. They just worked. But here, I guess it sounds like there's a lot of flexibility to really customize who, where, and what we get alerted for. I guess a question everyone will be wondering, who has access to these new advanced DDoS alerts? So the standard alerts are for everyone, from the free plan to the enterprise plan. And the advanced DDoS alerts are available to our enterprise customers using the application core services, meaning our layer seven services, the WAF or the CDN, and the customers that manage their own infrastructure or IP applications. So Magic Transit and Spectrum customers as well. Great. And as a reminder, of course, this is GA Week. So all the announcements we're talking about and publishing this week are things that will be, if not already, very imminently general availability across our feature set. And talking about announcements, you made another announcement about the availability of our new adaptive distributed denial of service system. That's also a pretty heavy word. What does that mean, adaptive? So it means that the adaptive DDoS protection system is a new system that kind of joins our family of automated or autonomous mitigation systems. And what it does is it's basically a platform that we can use to deploy multiple features of traffic profiling. So it's a platform that we can use to learn your traffic patterns based on various dimensions. The system then creates various traffic profiles based on your historical traffic patterns. And then it can flag or mitigate, depending on your preference, traffic that deviates from that profile. And what's nice about the system is that it's agnostic, meaning that as we kind of grow and release more capabilities, we're able to release more traffic profiling features based on various dimensions. Got it. Okay. So for those who were or are already using Cloudflare, maybe a quick reminder of what's the net new with the new adaptive system? What sort of features do we have in place with our current DDoS mitigation and what does this add that we weren't able to detect before, I guess? Yeah. So one of the new features that we released is the location aware DDoS protection system or the feature itself. To our customers, this is exposed as a DDoS managed rules that they can kind of tweak the sensitivity levels and change the mitigation action. And what this means is basically, so we will create a traffic profile based on a dimension each time. With the location aware, what we do is we use the source country of where the IP, the client IP of legitimate traffic, legitimate users are. And then we bucket traffic based on that. So we look at the max rates for every country that you received of legitimate traffic. We will take the 95th percentile of that, meaning we will eliminate the top 5% high peaks as outliers, and then kind of form a profile of your traffic, kind of relearning the seven-day history of a moving max every 24 hours. And then let's say that you operate a website that provides services for users mostly in Germany. So most of your traffic will come from Germany, a little less from maybe the neighboring countries, Austria, France, and so on. And maybe as we kind of expand outbound, you will see less and less traffic. And so by learning your traffic patterns, we can take the distributed advantage of attackers that have thousands or millions of botnets or bots around the world and use it against them. So now if there's a DDoS attack, we'll see a traffic coming from multiple countries and locations around the world. And for you, that would deviate from your profile. So that would be flagged automatically, and you can decide if you want that traffic just to be flagged. So you can take a look at it and decide what to do, or actually set a default action of a challenge, managed challenge, or block to kind of make sure that that traffic doesn't reach you. Got it. So our current systems, very much, very sophisticated, but mostly signature-based, if I'm understanding correctly. So we essentially look at the packets reaching the origin, and if it doesn't look good, we block it. And here we're adding an understanding of the actual customer's traffic profile. Is this traffic profile per customer today, or is it per group of customers, or is it global or per pop? How does it sort of drill down based on each application? Yeah, so most of these rules are per Internet property. So if you have 50 zones onboarded on Cloudflare, a profile will be created for each one of those zones. Similarly, for our protocol aware DDoS protection for our Magic Transit customers, it will be per IP prefix. However, we have other rules like the user agent aware DDoS protection, where we actually look across the entire Cloudflare network and create a profile of common user agents. And that way we can easily flag floods of uncommon user agents that are used in DDoS attacks. Got it. And since you're talking about user agents, are you referring to Layer 7 HTTP user agents in this context? Yeah, exactly. So the adaptive DDoS protection provides functionality and protection both for our Layer 7 customers with the user agent aware DDoS protection and the location aware. But also we do the same thing at Layer 3, 4, for our Magic Transit and Spectrum customers. We've already released the protocol aware DDoS protection. And in the next few weeks, we will be rolling out additional adaptive rules for our Layer 3, 4 customers. Got it. And you mentioned earlier that these are, well, you referred to managed rules. As of today, what sort of customization, if any, is available for customers that want to use this new adaptive, at the very least, the location aware and the user agent aware adaptive mitigation systems? Yeah. So what customers can do is they can basically change the sensitivity level of those rules, meaning to define what level of tolerance of traffic they want to receive that deviates from their profile. Again, the example with the Germany-based website, it may be fine that I see spikes from other countries. So maybe I'll reduce the sensitivity level from high to low. And that way, if there are naturally occurring spikes in traffic, they won't be mitigated. And then the default action for most of these rules is log. So you can visualize it in the dashboard or via logs in your SIM dashboard or via API. And then if you want, you can also change the action to block or challenge if you want to mitigate that traffic that deviates from your profile. Does this also apply to the Magic Transit customers who are using the protocol aware system as well? Or is the customization restricted only to the Layer 7 traffic? Also for Layer 3, 4, something that the Magic Transit and Spectrum customers can also do is use an expression field. So I can decide to craft logic and say, block traffic that deviates from my profile unless it comes from this IP or unless the destination IP is this and that. So that ability to create overrides with expression fields is something that can be done as part of our Layer 3, 4 managed rules, DDoS managed rules. And for Layer 7, that capability is coming very soon. So you'll be able to say things like, mitigate it unless it's towards this host and actually for this path, define this level of sensitivity and so on. Got it. And this sounds really cool, especially given we are starting to look at specific application or Internet property traffic profiles. So correct me if I'm wrong, as you mentioned, location aware, user agent aware for Layer 7, and then protocol aware for Layer 3, 4. Customers may be wondering, including myself, what's next on the horizon? Are there any other dimensions or signals that we're starting to look into that will improve our adaptive systems? Yeah. So the motivation behind bucketing traffic based on location is also very much valid in Layer 3, 4. But at the packet layer, the source IP can easily be spoofed by attackers. So what we're doing there is instead of using the source IP, we're actually looking at where the packet was ingested, meaning in which Cloudflare data center we saw that packet coming in. And one of the benefits of Cloudflare's network there is because we have location in over 270 cities around the world, we're able to achieve a kind of geographical accuracy to properly map your traffic and provide location aware DDoS protection even at Layer 3, 4. And then we have a few more kind of surprises in our sleeve, and you'll just have to stay tuned for that. But Michael, enough about DDoS mitigation for now. What about WAF? You've also had some very interesting announcement this week, the account WAF. So before we even start with the account WAF, let's start with what is a WAF? Right. Yeah. It's good to set the scene. And I was waiting when the questioning was going to turn the other way around. So you're right. We did announce account WAF in general availability, but you may be wondering what is the web application firewall? DDoS mitigation is trying to block a sort of volumetric or burst of traffic trying to take down your applications. But very often an attacker may not be trying to just overload you, but actually infiltrate you or potentially exfiltrate data from your application. So the volume of the request per se is not the tool to do that. Rather, attackers, most often humans, manually crafting packets which have explicitly malicious payloads in them to do something bad on your application server. Two examples here are very commonly referenced SQL injection attack, SQL SQL injections, whereby there's like a search form on your website and the input to that search form is not handled properly by the backend system. An attacker might be able to query the backend system directly bypassing the search function. And another very common referred attack example is cross-site scripting written as XSS, whereby an attacker may leverage JavaScript, which is executed in the browser environment to potentially steal your session cookie or do some key logging on your browser, whatever it may be. And they leverage the application itself to spit out the JavaScript back to the legitimate user. In this case would be reflected XSS. There's many, many, many attack categories out there. And the web application firewall is there to stop those. So individual malicious payload will get blocked by the WAF, making the hacker's life very, very, very hard. And talking about Cloudflare of course, how to use the Cloudflare WAF, very similar actually to DDoS. I have my own websites behind Cloudflare and the web application firewall is available, the main components of the WAF from a pro plan upwards. So starting at $20 a month per zone, and it's just a couple of buttons to turn it on and you can sleep a lot better at night after that's done. And that's done today for each individual zone. Right. So this is where the account WAF comes into play, right? And I specifically mentioned $20 a month per zone. So when Cloudflare started, we grew small and the whole idea was to provide services the only large enterprises and corporations could afford to anyone on the web. And therefore the unit of our systems was the zone. You'd have a domain, you'd have a blog, you'd have a little e-commerce website, and you would onboard that as a zone onto the Cloudflare dashboard. And all of the settings and configurations are keyed off from that zone. This still works extremely well. And I would say most customers using Cloudflare, most self -serve customers using Cloudflare still very much fit into that idea that a zone is my unit of measure. And therefore I want to configure the WAF on a per zone basis. But as we've grown, the number of applications being onboarded behind Cloudflare has changed drastically over time. And I think, Omer, you mentioned this as well. Some customers are now running hundreds, if not thousands, if not tens or hundreds of thousands of applications behind the Cloudflare proxy. And in that context, essentially managing a WAF on a per zone basis becomes extremely hard. Two options, really. You very slowly and manually click, although it is one click to deploy the WAF, click the WAF a hundred thousand times, which is not easy or very time consuming, or you build automation. Lots of larger companies are able, of course, to build automation. Cloudflare is API first. So you can essentially write a script or use a config management tool like Terraform to list out all of your zones. And you define your WAF config in the Terraform config file, and then you run Terraform apply. And instantly the Terraform will do the work for you. But not everyone has the time to start configuring Terraform. And a lot of teams, especially security analyst teams, may not have actually access to the underlying APIs. They just want to use the UI. And to solve this, as of today, we finally ripped out the idea that the WAF is tied to a zone. And we're now offering the WAF at the account level, which means if you have a single account, and in that account you have, let's say, a hundred zones, you can deploy the WAF once at the account level and cover all of your zones with a single configuration. So that's really where the value is. And we've had a few customers already using it for quite some time, and it's saved them massive amounts of time, of course, but also makes it really easy to understand what's going on without necessarily having to go into each and every zone to understand the WAF configuration. That's awesome. It sounds like we have a lot of features and functionality moving to the account level. Is this a trend that we can foresee growing? Yeah. So probably, I would say. I think Matthew Prince tweeted this was like the second most requested feature. I don't have the full order on top of my head right now, but I know that account level analytics and account level security analytics are pretty high up there as well. And so, yes, we are building a lot of our configuration for our security products to be account level. But zooming into the WAF specifically, like what is available today, we have, as part of the WAF, three main features. We have, and these all run in an order, and you can, of course, customize and configure as you wish. Custom rooms, as part of this announcement, are available at the account level. Custom rooms allow you to define an arbitrary filter of your choosing and then perform a security action on any traffic or any HP request matching that filter. This is very powerful. Standard use case here is if you want to lock down an admin environment to a specific IP range, or if you want to deploy bot management, for example, by challenging bots under a specific score threshold, all of these concepts are done via WAF custom rules. And if you have access to the account level WAF, you can do that now in a single place. Second feature is rate limiting. And in fact, our new rate limiting engine is now also available at the account level. And rate limiting rules are used by customers when they want to set a threshold. In fact, very often for lower, smaller DDoS attacks at layer seven, customers very often deploy a rate limiting rule to define how many HP requests per second or per minute they expect to receive. Final but not least, maybe the core of the WAF, the managed rules. These are several hundred signatures written and provided by us. We're constantly updating them. There were some updates earlier today, in fact. And the Cloudflare managed rules are also now provided at the account level. And there's actually a little extra here, which makes the account level WAF a lot more powerful than the zone level WAF. At the zone level, we only allow you to deploy each one of our managed rule sets once. So if you want to deploy the Cloudflare managed rules, you turn it on, and that's a single deployment. You cannot deploy a different set of managed rules on a different part of your application. And given we were already working on the account WAF and extracting the whole idea of the zone, using a new account level configuration, you can actually deploy multiple managed rule sets on different portions of your traffic, which may cross zones with your custom configuration. So if you want to only match traffic from a specific IP range and have a very high managed rule sensitivity, you can do that across your hundred zones, regardless of the application. And that's WAF specific. And then more broadly, we'll soon bring analytics and security events at the account level too, but they're not available just yet. A lot of really cool features that sound like they'll make our customer's life easier with a lot of flexible capabilities there for managing a lot of Internet properties. So we have less than a minute left. We do have a bunch of questions coming in. I think we have time for maybe one or two. So Michael, this is a question for you. If I deploy an account level WAF rule, can I exclude a particular zone from that rule? How does that work? Yes, you can. So if you have access to the account WAF and you deploy, let's say managed rules across your zones, when you deploy the managed rule set, you actually define your filter. And by default, the filter is star or true, which means matches all zones in the account. But you can edit that filter and it's the same expression filter as custom rules. So you include or you exclude the specific zone you want to exclude, or you do the opposite or match on whatever subset of the traffic you want. Okay. Well, we have eight more seconds left, so I think we're going to wrap it up. So thank you, Michael. And thank you everyone for listening and stay tuned on the Cloudflare blog. Thank you very much.