Here we will go over the various security, performance, and monitoring features CloudFlare has to offer.
Any website is susceptible to attacks from malicious traffic. Some attacks might try to take down a targeted website, while others may try to include their own spam. Worse attacks might even try and trick your users to provide information or compromise user accounts.
CloudFlare has tools available to mitigate various types of attacks.
A common attack on the Internet is the distributed denial-of-service (DDoS) attack. A distributed denial-of-service attack involves producing so many requests for a service that it cannot fulfill them, and crumbles under the load.
A common way this is handled in practice is by having the attacker make a server request, but never listen for the response. Typically a response will be presented by the client notifying the server that it received data, but if a client does not acknowledge, the server will keep trying for quite a while. A single client could send thousands of these requests per second, but the server would not be able to handle many at once.
Another twist to these attacks is the dynamic denial-of-service attack. This attack will be spread across many machines, making it difficult to tell where the attacks are coming from.
CloudFlare can help with this because it can monitor when users are trying an attack and reject access, or require a captcha challenge to gain access. It also monitors all of its customers for this, so if there is an attack happening on another CloudFlare site, it can protect yours from the traffic attacking the site as well.
It is a difficult problem to solve. Sometimes traffic just spikes if big news article are run. It is hard to tell when it's legitimate traffic and when it is an attack. For this, CloudFlare offers multiple levels of DoS protection.
On the CloudFlare settings the Security tab is where you can configure this advanced protection:
The basic settings are rolled into the Basic protection level setting:
SQL injection is a more involved attack. On a web page, you may have a field like a username/password field. That field will probably be checked against a database for validity.
The database queries to do this are simple text strings. This means that if the query is written in a way that doesn't explicitly prevent it, an attacker can start writing their own queries.
A site that is not equipped to handle these cases would be susceptible to hackers destroying data, gaining access by pretending to be other users, or accessing data they otherwise would not have access to.
It is a difficult problem to check against when building a software. Even big companies have had issues.
CloudFlare mitigates this by looking for requests containing things that look like database queries. Almost no websites take in raw database commands as normal queries. This means that CloudFlare can search for suspicious traffic and prevent it from accessing your page.
Cross-site scripting is similar to SQL injection except that it deals with JavaScript and not database SQL. If you have a site that has comments, for example, an unprotected site might allow a hacker to put their own JavaScript on it. Any other user of the site could execute that JavaScript. They could do things like sniff for passwords, or even credit card information.
CloudFlare prevents this in a similar fashion by looking for requests that contain JavaScript and blocking them.
Often, services available on a server can be available without the sysadmin knowing about it. If Telnet is allowed, for example, an attacker could simply log in to the system and start checking out source code, looking into the database, or taking down the website.
CloudFlare acts as a firewall to ensure that the ports are blocked even if the server has them open.
When CloudFlare receives a request from a suspect user, it will usually show a challenge page asking the user to fill out a captcha to access the site. The options for customizing these settings is on the Security Settings tab:
You can also configure how that page looks by clicking on Customize. By default, it will look something like the following:
E-mail address obfuscation scrambles any e-mail addresses on your page, then runs some JavaScript to decode it so that the text ends up being readable. This is nice in order to avoid getting spam in your user's e-mails, but the downside is that if a user has JavaScript disabled, they will not be able to read e-mail addresses:
If there is any content you really don't want suspicious users to see, you can wrap it in the <!—sse--> tags to hide it:
A browser integrity check will analyze the HTTP headers to see if the user appears suspicious. I suggest enabling this as another method to look for potentially suspicious users:
Hotlink protection ensures that your images cannot be easily stolen and put on another site via hotlinks. The users will still be able to download the images and rehost them, but would not be able to use your site to do so:
The only reason to enable this would be to prevent server costs of hosting images on a high-traffic site. However, CloudFlare should optimize images, making this a somewhat minor security feature.
The threat control part of CloudFlare allows you to see the individuals that are getting blocked and see more information about them:
Here I can see all the spammers and botnet zombies that have come to my site. By hovering over the CHALLENGED text, I can also see that they all had reached a captcha, but did not pass it. If I were to notice that a user was hitting the same captcha and passing it, I might want to whitelist their IP by clicking on TRUST.
I could also add in a range of IPs that I wanted to trust.
If you have any sort of login/authentication on your website, having SSL configured is an absolutely necessary security step you will have to take.
When you access information on the Internet, the data does not flow directly to/from your computer. It actually goes out to every computer on the network and those that want the traffic pay attention. For example, when you're browsing Facebook, every single person on your Wi-Fi network is receiving the same data that your browser is. They can choose to listen to that traffic and easily pretend to be you.
SSL encrypts that traffic, so even if someone tried listening to the data, they will not be able to understand the information.
If you are unfamiliar with SSL, I highly suggest looking up the Firesheep exploit on the Internet. A couple of years ago it allowed even non-technical users the ability to almost immediately hack into someone's Facebook account just by being on the same network.
This drove Facebook to start heavily using SSL, so the issue is not nearly as severe as it once was.
On a pure content site without any login/authentication it is not necessary, however even most blog sites will have an admin login I'm sure you will want to protect.
Luckily, you're using CloudFlare, and it's very easy to set up.
Normally you will configure your server with an SSL certificate. It's a fairly involved task, and requires purchasing an expensive SSL certificate from a certificate authority. CloudFlare offers an alternative that is much simpler to set up:
With CloudFlare, rather than ensuring that the server has an SSL connection to the user's browser, the SSL connection is only between CloudFlare and the browser. The connection between your servers and CloudFlare is unprotected.
This is usually an okay trade-off. The reason SSL is so necessary today is because of public Wi-Fi networks. The connection between CloudFlare and the server is unencrypted, but it is much less likely to have people sniffing the traffic.
CloudFlare offers some unique tools to be able to analyze your site's traffic. Most analytic tools work by running some JavaScript on the page. But it won't work when a browser doesn't have JavaScript, or if the user views the page too quickly for the JavaScript to notify the analytics service of an update.
CloudFlare is able to analyze all traffic because it is actually serving the traffic. It doesn't need any external JavaScript to function.
To access the analytics, click on the Analytics button on your website list in CloudFlare:
From here, you'll see some graphs showing details about your traffic:
You'll notice something very different with CloudFlare if you compare it to another analytics tool such as Google Analytics. First, the numbers will be much higher. Also, it will be separating the traffic into regular traffic, crawlers/bots, and threats.
Regular traffic might be a regular user, or it might be an automated process that CloudFlare doesn't detect. You'll see on mine how every few days I get a huge traffic boost for some reason. I imagine that is because of some bot. Google Analytics uses JavaScript to track users. Because of the JavaScript-based tracking, it is not able to show that traffic from bots.
Here is Google Analytics showing the same timeframe:
Crawlers/bots are requests hitting your site that CloudFlare does recognize as being from an automated tool. These are usually search engine crawlers that are indexing your site. They can also be bots like Facebook trying to get metadata about your site if people are sharing content. They are generally harmless. If you would like to control them more, look into the robots.txt file.
Threats are not necessarily dangerous. You will almost certainly get traffic marked as threats no matter what. CloudFlare will watch traffic it marks as dangerous as it goes around the Internet. Some of these will be poking around your site, but not necessarily doing anything malicious. Still, that traffic is best avoided. You can get a better idea of exactly who is being marked as a threat by clicking on the Threat control link.
This is also the section you can use to get a better idea of the repercussions of setting your security settings.
This section will show how well the performance part of CloudFlare is working. Most of the improvements will be due to CloudFlare serving JavaScript, images, and style sheets without hitting your web server. This is where you want to be looking as you tune the various performance settings. The more you can offload to CloudFlare, the better.
This section shows how often search engines are indexing your site. More crawling is not necessarily a good thing.
Search engines will attempt to browse around your site to find content. They will do this on a somewhat regular basis. What is better, however, is to guide them through your content. For Google, I highly recommend signing up for their Webmaster tools at http://www.google.com/webmasters. In the tools, they will give you hints on how to design your site to better allow crawling.
If you can set up a sitemap for the search engines, you will find that the crawl rate might reduce dramatically. This is expected, as you would now be describing where your content is and how often to check for it rather than letting the crawler figure out by itself.
Optimizing your site for a search engine is one of the best ways to get more traffic to your site. Definitely work with your search engines to find the best way to optimize your content.
CloudFlare has an extensive array of apps for you to check out. For the large majority, these apps will all work with minimal configuration, and no changes to backend code. Some of the apps are free and some are paid.
To get started, go to the Apps section for your domain. You can find it on your domain dashboard at the Apps link:
Most of these apps can be installed just by flipping the switch next to the app on this Apps dashboard.
The available apps may change after this book is published.
A Better Browser will show users a warning if they are using an old version of Internet Explorer. It will also trigger if the user is operating a new browser in compatibility mode.
It can be useful if the experience for your application is not optimal in the old versions of IE such as IE6 and IE7. It will show a warning such as the following:
Blitz is a load-testing tool. It can be helpful to see how your application is performing in general, or to compare it against how it runs under CloudFlare.
Note that Blitz will only perform test loading of HTML pages and not the assets on them. Most of what CloudFlare does to optimize your site is with regard to asset performance. I would only expect minor improvements (if any) when loading under Blitz.
When you run a rush with Blitz, you'll see a report such as the following:
You can use that to tune your site to see how much load you can handle. Also, it's great for testing the potential for performance improvements.
cdnjs is a script repository containing popular JavaScripts. If you use any of the scripts at http://cdnjs.com/, it will help your users to use them from cdnjs. Not only do these JavaScripts run from a CDN, but they're also likely to be available on many other websites. This means that the first time a user visits your site, they will not have to download the script.
To use cdnjs, you can either edit your site to use the URL from http://cdnjs.com/, or just click on one of the scripts in the configuration:
Clicky is an analytics service that specializes in real-time traffic. It is a paid service, but can be enabled straight through CloudFlare with no configuration.
CodeGaurd offers the ability to back up your site daily. It works via FTP and MySQL. It also works well with WordPress. If you have a different stack, you'll have to investigate alternate methods of backup. You'll have to enable this through your web server.
Experimently offers heatmaps that display where users are clicking on items on your site. It can be useful to get an idea of the UX behind different parts of your site:
ExceptionHub tracks JavaScript errors on your site. If you use heavy amounts of JavaScript, it can give you a good idea about the problems your users may be experiencing.
The Google Analytics app will ensure that Google Analytics is correctly enabled on your site. Google Analytics is a popular, free way to measure website traffic. You can see how many users are viewing your site, where they are coming from, and what content they see. Google Analytics also has the ability to see the paths users take through your website, and where they are coming from (referrers, search, and so on):
The webmaster tools provided by Google can also be enabled via CloudFlare. The Webmaster Tools allow you to see how well Google and other crawlers can view your site, as well as detecting other possible issues your site might have.
Like Google Analytics, it provides some insight into where users are coming from and linking to. It shows some detail on where search comes from as well. It's designed less for analytics and more to watch out for obvious issues.
It can help you set up a site map to guide the crawler around your site, show how often the crawler is hitting your site, see what pages the crawler can access, and what pages look like to the crawler.
If you want organic search traffic, it's a good idea to check up on it every few weeks to see if there are any major issues to look at.
Many web fonts are difficult to read for people with dyslexia. There are some fonts that can help dyslexics read sites. OpenDyslexic will enable these fonts so that dyslexic users will have an easier time reading your content.
Monitus and Pingdom will keep checking your site on a regular basis to ensure that it is running. They will only be able to do that to a limited extent, such as if the front page is loading. Other issues involving logging in or database use may not be caught.
Still, it's a good idea to have an automated service checking your site regularly so that you can quickly fix any issues that may arise.
UserVoice puts a tab on the side of your site allowing your users to ask for help or features. If you would like to publicize your upcoming features and give a forum for users to suggest features, it is a good way to facilitate that.
Trumpet shows temporary messages to your users. It is helpful if you frequently need to show messages to your users but do not because you need to deploy a new code. It also allows the users to dismiss the messages after they read them.