Your Cloudflare Account Security Health Check

Good morning everyone. Welcome to this session called your Cloudflare account security health check. Today I want to talk to you about a few things that are going to make your account in tip-top shape and will offer you some solid foundation to build like your security. So we will cover some account level security settings but also some zone level security settings. So let's get to it. The first most important settings that I can recommend enabling on your Cloudflare account is 2FA and 2FA stands for two -factor authentication. Now you might ask yourself is this really important but the answer is of course it is. So in the industry we have witnessed time and time again that password breaches do happen and that passwords get compromised and workstations and laptops get hacked and so having a second factor of authentication on top of your password when logging in is essential. So this is why we really think at Cloudflare that you should enable this setting. There are two main methods that you want to use 2FA. I'm not going to talk about SMS authentication because this is a really weak form of 2FA. Instead we can talk about OTP, namely TOTP generally, which takes the form of an application on your smartphone that will basically give you a time-limited password for the 2FA as a code. However those methods of 2FA can still be subverted by social engineering and man-in-the-middle attacks so they're not really that robust either. Instead there is a newer form of 2FA called U2F, universal two-factor, which has really strong security properties and that can be used with your Cloudflare account and this is what we highly recommend using. So it takes the shape of a little USB device. I have one that I can show on the camera. Hopefully you can see it. So it's like a little either USB-C or USB-A device and in order to basically authenticate when you go to website you type in your password then you will be prompted to just tap the device. There's no code to enter or anything. Basically this is a challenge response protocol that uses asymmetric cryptography to basically do that in the backend. So what I'm going to offer to do is to go over to an account and see how this can be configured. So let's go over into this account that's for demonstration purposes. So if I hover into my profile here we can see that I have an authentication section here. So that's the section we will want to go to. Second, once we're in there we can see password but most importantly we see the two-factor section here and we have the enabled tag here which kind of highlights the fact that I've been able to FA for this account. If we go to the manage section we can then see that we have this security key authentication and that's the 2FA that is enabled for my account. You can see that I've named it U2F laptop which means that this is the friendly name I've added to designate this USB key. You can add several keys. So for instance you can leave one in your laptop and one at home so that should anything happen you're never locked out of your account because you have an additional key. You can see here that you could configure the mobile app authentication the TOTP that I mentioned earlier but ideally if you can afford it the security key authentication really is the best method here. So are we done here? We've been able to FA for this account. Is this enough? Well the answer is not really. In a lot of cases a Cloudflare account will be shared through multiple members for an organization for instance where you're going to have several people managing a specific account and as we know security is always the weakest is always as strong as the weakest link. So let's review a little bit the configuration for my account. If we go back to the account main page and we go to the members section we can click there. We can see that we have two members for this account. Now if we click on the main one this is the one I'm currently logged in as we can see the 2FA has been enabled. Now if we go on to the second one 2FA here is not enabled. So if this account was to be compromised through like a password reuse or something like that well then the security of your of your Cloudflare account potentially will be compromised as well because there is no 2FA. So fortunately what we do have is a setting called member 2FA enforcement and this is a setting that we think you should enable. This will mean that all members of a Cloudflare account have to have two-factor authentication before they can proceed to doing any administrative action. So we're going to enable this on this account and see what happens when I try and log in with the other account which 2FA is disabled. So let me just log out. I am gonna use my password manager to log in to solve a capture. Let's just get this quickly. Okay log in and here we see that basically the member 2FA enforcement is ensuring that this user now has to provide a 2FA method before being granted access to the account. So here the user would have to use the mobile authenticator because this is the current flow that has been implemented. However the user would be able later on to onboard itself with the security key method that I mentioned. So very good. Let's just go back to the normal account because we're going to use that later again. Let's just log back in. Perfect. We can see here that we have another form of authentication and this is the security key so I have to tap on my machine and that will grant me back access to my Cloudflare account. Okay very well. So another important account level security configuration I want to talk about is API tokens. Now those are very helpful for a different reason. If you do a lot of DevOps and automation they will really make your life easier around integrating with Cloudflare and automating the configuration of your zones and the settings that you want to deploy. Additionally they're very useful in the sense that you have the ability to basically scope permissions very granularly. So let's go over again into the account and see what happens for my profile. If I go for my profile I have a section here called API tokens. So if I go in there we will see that I have two tokens that have been defined here and here. The first one is configured for a single zone and only has the permission to do zone DNS edits. The second one is a global token that has access to all account all zone but a read-only access. That would be useful for instance if you have a tool that is trying to scrape information to do some monitoring and configuration checks but that you do not want to grant it permission to actually make changes. So tokens are really helpful. Try and take advantage of those. They're very easy to use and straightforward to configure. Now that we have had a look at some account level security I want to drill down into some zone level security configuration and one of the most important ones that you can enable for your zone is properly setting up SSL TLS. So that's going to be our goal here, making sure that it's properly configured. In terms of requirements, well we just need a website that has been onboarded with Cloudflare and universal SSL to be active which is generally the default when you set up a zone. And the results that we want to achieve is that all eyeballs connecting to Cloudflare are doing so by establishing a secure connection, that Cloudflare when connecting to your origin is also establishing a secure connection and that we are following TLS best practices. So let's go again into my accounts and see how we can demonstrate this. So I have this zone here for which we are going to use a single entry www and that entry is configured to Cloudflare. It's orange clouded which means that the traffic is going through Cloudflare as expected. Now we can browse to this website here and the back end of this website is just basically sending back information about the connection that it's been receiving and we can see here that this is a Cloudflare IP so this is working as expected. However we also do observe here that we are connecting using an insecure fashion so only HTTP. If I try and force to use HTTPS this is not going to work because Cloudflare hasn't been configured properly so something clearly is missing here. So if we go into the SSL TLS setting on our Cloudflare dashboard we're going to see immediately something is off. Cloudflare tells us that TLS is completely off here so this zone is not really in good shape. So we could try and enable using the flexible method and that would ensure that this link here between the browser and Cloudflare would be secure. That would not be enough. We want to also make sure that the link between Cloudflare and our origin server is secure so we could use configure in a full setting and that would establish a TLS connection. However Cloudflare would not validate the certificate that has been that is being presented so if you have a self set sign or self sign cert or an expired one the connection will still be established. So instead what we want is to use the strict method where Cloudflare will actually perform the verification proper verification. So let's just enable this now. Okay so I've enabled this setting and now if we go over again to our website and I connect via HTTPS now we can see that we have been served with a certificate and this certificate has been is one signed by Cloudflare. So our visitor here has a secure connection and Cloudflare is establishing the connection with the origin securely as well. Now what we have observed as well is that when I connect I can still connect using plain HTTP on my website so not all visitors might be accessing my website using a secure connection. So again here we can still do a little bit more. So in order to do to change that we're going to go to the edge certificate tabs. Now within here there's going to be a few settings that are of interest. First of all the always use HTTPS setting right now is currently off and this is the setting that basically redirects all users connecting through Cloudflare to use HTTPS. So I'm going to enable that now. Now whilst we're in this tab there are other settings that are of interest. First of all the minimal TLS version setting here has been set to TLS 1.0 which is very conservative and when we mention TLS best practices we actually want to do better than this. So we're going to change this setting and put TLS 1.2 as the minimal TLS version to establish a connection with Cloudflare. In addition if we want to ensure that modern browsers and tools can also use TLS 1.3 we can enable that as well. So let's do so. Very well. So now if we go again on our website and we open a new window I automatically was redirected to HTTPS. So we can't really see what's happening in the background here. So instead what I want to do is show you using a terminal. So if I have my terminal and I use the curl command to perform an HTTP request on the website what we will see is that immediately the response is basically a redirect and Cloudflare is redirecting our client to use the HTTPS. Therefore the only way to establish a connection with the origin in that sense and to be served traffic is to use HTTPS. So we can demonstrate that by using HTTPS here and we have a 200 that has been returned and we have our IP address which has been returned. So it looks like we're in a much better shape now because as I mentioned the eyeballs are using a secure connection. Cloudflare is using a secure connection to your origin and we have enabled some settings that reference the TLS best practices. Very good. So the second thing I want to go over is talking about reducing the exposure of origin IPs. Our goal here is going to be going into the DNS settings and making sure that only the corresponding required gray clouded DNS entries are set and that we don't have too many settings that might be conflicting there. Result will be a reduced amount of origin IP information leaks. So if we go to the dashboard this time we go to the DNS settings we're going to have our list of DNS entry here and we can see that we have two entries which are orange clouded so they're not going to be problematic but we have this one here that has a warning sign and it tells us this record exposes your origin IP. To fix it change its proxy status and obviously this one for demonstration purpose is called exposed has an IP address and this is probably a case where this was a mistake and actually we want this record to be changed. So I'm going to change it to orange clouding done and this one is fine. Now the second one which is still gray clouded is an FTP server that is being run and orange clouding by default only works with HTTP services. So if you run an FTP service you will want to keep it gray clouded. This is to say that not all services and records have to be orange clouded. Some of them are legitimate use cases to remain gray clouded. Okay now the next thing is to try and get a sense of like some of the some of the good security features that you get for free with your Cloudflare account. So I'll go over the main one which is the firewall features and within that we're going to look at the security level and challenge passage settings. I'm going to go as well over some firewall rules and finally some additional tools that you might find helpful for your configuration. So if we head over to the firewall setting what we can see is that first we want to go over the global settings configuration here. So I'm going to click that. Now once we're there we have two main settings that are going to be of interest as I mentioned. The security level here we can see has been set to medium and if we're not really sure what this means we can click the toggle the little help here and that's going to tell us that this is going to challenge moderate threat visitors and the most threatening one. We have the high one which means challenge all visitors that have exhibited threatening behaviors within the last 14 days. So that sounds like a really good idea and for my zone I'm going to I'm going to set the level to high. Obviously this means that if someone is flagged as potentially threatening he will be served with a challenge and will not be immediately granted access to the website. Another settings to go in par with this is the challenge passage here which means that in order to not overburden too much your users you can configure the amount of time after which they have to pass another challenge. So in this case here we have 30 minutes and that's going to be fine. In other cases you would want to reduce it or to increase it. So I'm not going to change this one here. So that was kind of like a good settings to bump up a little bit the security of your website setting that security level to high instead of letting it to default settings. Now I want to talk a bit more about the firewall rules. So this is a really helpful tool to start hardening a little bit the configuration of your zone. So here we can see that I have defined two rules one of which is actually active and I'm going to go over to this rule specifically to see what it does. So if we go to this rule we have this rule builder that you can use or you can actually create a rule using the wire filter expressions which is what I did. And what we'll see is that first of all in order to match this rule you will have to match this HTTP host for it to be considered. So I will only match for www .abc.co.uk and in addition to that this rule will only match if the HTTP request parameter are not a GET and also if the paths that are within the rules are not contained as either a slash, slash JSON or the icon website for that domain. And the resulting action for that rule will be to block. So basically what this rule does is that it's a crude way of restricting the endpoints that are offered by a website. So if we go over to this rule we can see that it's active and we can try and trigger the rules that could be quite interesting. So what we've seen is that when I hit my website earlier on it did work so we can also try that with JSON and we can see that I am getting a JSON response here and a 200. So this is not a rule that triggers the firewall. However if I try and hit a slash admin endpoint here in that case I'm going to be blocked by the firewall which is going to reject the connection. So it demonstrates the kind of features you get for free as part of writing firewall rules. Now the second one that I have here is called challenge. Challenge to French and basically it's a way to present a JS challenge to people and customers visiting from a specific country in that case from France. So if you have an IP that has been identified as coming from a French ISP or references as a French IP then you would be served with a challenge. However this rule is not active and we can see that when they are not active they do not count towards allowance of firewall rules. So this is kind of like a good thing where you can basically define additional firewall rules that you can enable when actually suits you depending on some of the use cases and you have a fair degree of flexibility once defining those. Now I want to move on to the tools section and talk a little bit more about some additional settings that you can leverage. So within the tool section we have complementary options here to defend a little bit our website. So we have this tool called IP access rules where you can define certain rules based on IP address IP address range and autonomous system number countries reserved if you are a paying customer. So let's just exclude that for now because we're mostly covering the free services. So here you would be able to define additional rules complementary to the firewall ones to be able to block single IP addresses or IP address ranging or entire ASNs. So that might be helpful if you know that you have a specific offender or a specific network that is problematic for you and you can put it there as an IP access rule. Now the second thing you can do as well is you can try and leverage some of the rate limiting features. I want to highlight that this is a usage based feature. So I said that I was covering mostly the free settings but rate limiting comes with like 10,000 requests for free. So you could you could play around rate limiting and see if it actually fits some of your use cases for free and try and leverage that to perform some say rate limiting on a registration or subscription endpoint or administrative endpoint to reduce brute force things like that. Finally there is an additional setting here that could be of interest which is called the user agent blocking. As its name stands you can create up to 10 rules to restrict access based on the user agent. So that could be helpful in mobile mobile mobile device scenarios where you only want to allow a category of mobile devices to reach specific endpoints or specific domains in your website. Although those can be spoofed that can still prove an effective measure to make some decisions based on that. So this is something you can take advantage as well. Okay let's go back to our presentation. Finally the last thing I want to talk about is the under attack mode. This is something that's very helpful if you are actively under some threat and whether there is an ongoing denial of service attempt against your website. Although Cloudflare does its best to protect you against some of those attacks sometimes you can still have a certain burden on your website. So there is this setting called under attack that you can trigger and this is kind of like on the landing page. So if we go to the overview page here we can see that we have some quick actions here and we have this under attack mode that can be set up. Now if we do set that up what will happen is that anyone visiting your website will be served with the JavaScript challenge. So this is kind of like to slow down the access to your website while still remaining online and basically challenging a bit more the visitors and the denial of service attempts. So if I go now again to this website we're going to see that we are being served with a challenge that the browser will be able to solve and we get granted access but that helps throttling a little bit everything going to Cloudflare and ultimately going through your origin. So it's a good setting to basically have in mind and to enable when you are under attack basically. So good thing. Here not really under attack for that demo so I'm going to revert back the security level to high. We can see that the under attack mode basically changes the setting of the security level that we saw earlier on. Now that we've seen some of the free feature I just want to take a few minutes to talk about some of the paid features that really changed the landscape in the security of your zone. So if you are a paying customer you get access to some really interesting features. The first one is the web application firewall where your zone can leverage best in class managed rules where you can take advantage of this WAF to block targeted attacks against your CMS. So if you have a WordPress or Joomla we have dedicated rules that are there to prevent those specific attacks. So this is a great tool for the paying customers to take advantage of the WAF. The second thing is access that's under the brand now Cloudflare for Teams which basically helps you secure access to internal application without using a VPN and that mandates people to use an identity provider that you've allowed to based on your configuration so that you can basically device an authentication policy for those applications. So when we're thinking about the slash admin endpoint you could put it behind an access configuration without additional hurdle. So that could be really helpful instead of doing some rate limiting on there. The third thing is Argo tunnel which when you set it up allows you to have an ingress free routing to your origin. Therefore your origin would never have to have any ports exposed and that goes in a way through some reverse tunneling where the origin is the one establishing a connection to Cloudflare and traffic is sent and through those tunnels. So really helpful as well. Initially I also mentioned something around the inability to Orange Cloud non -HTTP protocol. Well Cloudflare also has a product called Spectrum that allows to do that actually. So if you have an SSH server or a Minecraft server or some other TCP based protocol for instance you can use Spectrum to basically shield your origin IP from being directly connected to and only allowing connection from Cloudflare to connect and establish that connection on top of obviously benefiting from the Cloudflare global data centers. So I'm not going to demonstrate those features now because we're running out of time but this is something to keep in mind that you can take advantage when being a paying customer on top of all the free features that you can leverage to secure some of your zones. So there's a plethora of additional resources that you can obviously go through to gain more insights into some of the features I've demonstrated and highlighted. So namely the support center for the Cloudflare resources. There is also the community forum where is a wealth of information there and we obviously also have the developers a documentation where you want to integrate with our APIs. So I hope that this was helpful in highlighting some of the settings that help you have strong security foundations for your account and for your zones and I will be happy to take any questions if there are any. Otherwise you will be following another session called betting on blockchain from the Internet summit. Thank you very much.