There is such a wonderful thing as Cloudflare. Almost everyone knows it and many people use it not only as a DNS provider, but also as a reverse proxy with a CDN (for which it is more and sharpened). But few people think about how it works and what they may encounter when using it. They just add a domain there, turn on proxy, connect a free SSL certificate and think that Cloudflare will become a magic wand for all problems.
Problems when proxying through Cloudflare
Now let’s throw some shit on the fan 🙂
No guarantee of DDOS protection
Many people think that Cloudflare’s free plan will protect them from DDOS, but daam it. The best thing it will do in a DDOS is give an error page until the attack is over. That’s all. No one will filter traffic for you for free, because. it costs resources and therefore money. You will have to fork out for paid tariffs. And then there are rumors that normal traffic filtering will be only on the Enterprise tariff.
Turning on captcha when suspicious individuals enter the site will help quite a bit, but do not forget that the algorithm often does not work as it should, and unfortunate users will endure this mockery of them.
Unstable work
Cloudflare may suddenly turn off abuse proxying without warning or if they think that you are pumping too much traffic on a free plan.
Also, something might break. But no one is immune from mistakes.
I still often notice several errors, And most often these errors are not related to what they write in the documentation. Yes, I checked many times, the occurrence of the error was not related to the firewall, errors on the server and accessibility. Other errors appear less frequently. Most people will not even notice errors, but if you put the site on monitoring, then it is hard not to notice them.
Some people notice that sites start to work slower when proxying. There are no proofs, but there are such reviews.
Incorrect operation of protection on the server
(if you have a regular shared hosting, you can skip this paragraph)
When proxying through Cloudflare, the server receives requests not from real IP clients, but from IP subnets of Cloudflare. The real IP of the client can be found through the same PHP (X-Forwarded-For header), but the server software sees only the final IP. As a result, server protection will not work very correctly. And it becomes even more complicated if there are several sites on the server and some of them are not proxied.
Let’s take Fail2ban as an example. Most often, incorrect authorizations on sites are recorded in error logs and set Fail2ban on these logs. As a rule, end IP addresses get there, i.e. Cloudflare IP addresses. When brute-forcing proxied sites, it will block not real IP addresses, but Cloudflare IP addresses. If a massive brute force starts, it will block part of the Cloudflare addresses, from which real clients will also come. And if the duration of the ban is long, then this will result in massive 521 errors with high attendance. Well, if you make a separate log, where to throw real IP addresses? In this case, Fail2ban will block real IPs, but traffic will come from Cloudflare’s IP addresses, and the firewall will continue to let villains into the server. Here, breakers can even break, and Fail2ban will work for nothing.
There is a solution for Fail2ban to block the real IPs of hackers, and they, in turn, could not access the server. In this case, Fail2ban gets the real IP and sends it to Cloudflare via their API. Cloudflare, in turn, blocks this IP already on its side. IP unblocking works the same way. Fail2ban receives a command to unban or sees that the ban is about to expire and sends a request to Cloudflare to unban that IP. Everything seems to be great, but in this case intermediaries appear, additional delays appear, and protection goes over to Cloudflare. We can only hope that it does not fall, does not suddenly turn off proxying, and API requests do not break. Or, for example, imagine that bad people find out the real IP of the server (and you can find it out in different ways), register it in the hosts of the attacking system (or botnet) and start hacking the site. Fail2ban sees unsuccessful logins to the site and starts sending them to Cloudflare for blocking. But they are no longer accessing the site through Cloudflare, but directly. And here they are not blocked. Alternatively, you can allow access via http and https only via Cloudflare IP addresses directly to iptables or pass them there via IPset. At the same time, the list of subnets must be kept up to date and pray that proxying does not fall off. Or support both options: classic blocking on the server with whitelisting Cloudflare subnets and sending real IPs to Cloudflare. But do you need such complication? Moreover, in this case, different nuances are possible. The easiest option is to block Cloudflare IP addresses for a short period of time.
Another example is the mass blocking of IPs by lists of bad IPs, for example via IPset. These IP addresses will simply not be blocked, because they will hide under the Cloudflare IPs. As an option, transfer them to Cloudflare in parallel, but you can run into limits, which is also not very good.
Secure traffic can be sniffed on the Cloudflare side
When using SSL and proxying traffic through Cloudflare, it connects its certificate. And this means that the traffic is first decrypted, and then encrypted with another certificate. This is all happening on the side of Cloudflare. When their servers are compromised, an important part of the traffic can be intercepted and modified by third parties.
When Proxying through Cloudflare
Hiding the real IP address of the server
One of the important reasons for some. But do not forget that there are many ways to find the real IP of the server.
It also often happens that on shared hosting, several dozen sites (or even more) hang on one IP, some of which do not have a very good reputation and partially spoil the reputation of the site in the eyes of search engines and mail services. When proxying through Cloudflare, the IP of the site is substituted and saves money on purchasing a dedicated IP.
Shared hosting and unattended servers
In this case, there are basically only pluses, because. Cloudflare partially solves the problems with protection and parasitic load. Better that way than nothing at all.
Unoptimized sites
If you have a site that is not cached in any way and without any optimization, then theoretically enabling proxying will fix some problems by caching some statics, compressing scripts and styles, and so on.
Using paid plans
Here and so everything is clear. For a fee, you will already have at least some kind of traffic filtering and all sorts of interesting goodies. Any commercial organization is interested in making money.
CDN
If you have an extensive audience around the world, then of course there will be sense. But most often, the server with the site is located close to the main narrow audience, and there is no need for a CDN.
Conclusion
I do not dissuade you from refusing to proxy through Cloudflare. The service itself is good, a lot of goodies even in the free plan. Easy setup for everything. But first of all, you need to think about whether you need proxying. If you think that it is fashionable or you just activate it automatically, then most likely it is not necessary.