Introduction
This article talks about a specific situation where Cloudflare is being used for all websites on a server to protect against attacks. The default website is also enabled on a GridPane server.
If there has never been a default website setup, then this article doesn’t apply.
What is the default website? It’s a site on the GridPane server that is chosen as the default website for web servers. The default site can be sset upusing the GridPane cli.
When a request comes to the GridPane server and requests a website DNS record not configured on the server, the default website will show. GridPane servers by default will show an error unless you setup a default site.
Default Site Attacks
The IP Address of any server on the internet is going to be probed, scanned or attacked as that’s how botnets and malware work. They are always looking for attack targets.
If you look at the web servers default access log (for GridPane Nginx it’s /var/log/nginx/access.log) you will see requests. Majority of these requests are automated attacks.
The Problem
The default site has to be an active site on the GridPane server, which is a WordPress site. Ultimately you’ve configured this WordPress site and set up a landing page.
Unfortunately, this causes a number of issues.
- The default site is a WordPress site.
- The default site may not be behind Cloudflare (You can still put it behind Cloudflare by enabling the proxy icon on the DNS record)
- The server is accepting and processing requests.
Let’s work down the list.
#1 - Since the site is a WordPress site, the WordPress-specific attacks may be successful or they’re wasting resources by breaking the caching you have set up by hitting locations that don’t exist generating 404 errors or using query strings.
#2 - The default site’s DNS record is not behind Cloudflare. Typically when the first request comes into WordPress, if the request isn’t using https or the default sites domain name. A redirection will be generated. This may or may not require PHP processing time, it might be cached or it might not.
#3 - The web server is accepting requests and processes them, which takes resources. A redirect or a simple HTML page takes fewer resources than loading an uncached WordPress site
In all the cases above, a resource spike occurs and could potentially cause resources to be exceeded and slow down the server to the point of not being able to handle any other requests.
The Solution
Use an HTML Page
Deleted all WordPress files for the site, and create an index.html page with whatever you like.
Put the default site behind Cloudflare
The default site can still be protected by Cloudflare.
Enable Rate Limiting on the Default Site and Whitelist Cloudflare
GridPane has a guide for rate limiting a site. You can see the instructions here https://gridpane.com/kb/nginx-rate-limiting-oxygen/ and I know they’re specific to Oxygen. But they apply here.
Instructions on Enable Rate Limiting and Whitelist of Cloudflare
Enable the whitelist by editing etc/nginx/extra.d/{yourname-}referer-rate-limit-whitelist.conf and adding the Cloudflare IP'
173.245.48.0/20 0;
103.21.244.0/22 0;
103.22.200.0/22 0;
103.31.4.0/22 0;
141.101.64.0/18 0;
108.162.192.0/18 0;
190.93.240.0/20 0;
188.114.96.0/20 0;
197.234.240.0/22 0;
198.41.128.0/17 0;
162.158.0.0/15 0;
104.16.0.0/12 0;
172.64.0.0/13 0;
131.0.72.0/22 0;
104.16.0.0/13 0;
104.24.0.0/14 0;
2400:cb00::/32 0;
2606:4700::/32 0;
2803:f800::/32 0;
2405:b500::/32 0;
2405:8100::/32 0;
2a06:98c0::/29 0;
2c0f:f248::/32 0;Enable the rate limiting on your default site.
gp stack nginx limits -site-zone-wp-burst {queue.size} {site.url}