Configuring CDN Security¶

QUIC.cloud provides several protections against DDoS attack. The QUIC.cloud dashboard allows you to enable and configure these options if you are on the Standard Plan. (Are you under attack right now? Read this first!)

While there are many WordPress plugins available to provide security features, CDN-level protections are both more effective and more efficient.

So, let's look at what you can do with QUIC.cloud under the Standard Plan.

Start by visiting your QUIC.cloud Dashboard. Choose the domain you wish to configure. Then, navigate to CDN > CDN Config > Security. You should see sections for Anti-DDoS, Access Control, and reCAPTCHA Settings. There is also a WordPress section for WordPress-specific security controls.

Anti-DDoS¶

reCAPTCHA & WP Brute Force Defense¶

This setting can help protect against flood attacks. We highly recommend keeping it ON at all times, with the possible exception of when you are running benchmarks. Your domain's reCAPTCHA activation parameters are configurable via the Connection Limit and Max Login Attempts settings.

Connection Limit¶

Valid values range from 0 (no limit) to 10000. The default limit is 2000, which means reCAPTCHA will be activated for your visitors when there are 2000 or more concurrent connections to your domain at any given node.

The Connection Limit that you set here applies only to this domain's visitors at a single CDN node. There is also a connection limit set for the CDN node as a whole, and it may vary from node to node. The node-level limits are set by QUIC.cloud and take all connections to that node into account, regardless of which domain is involved.

The limit you set here for your domain will supplement node-level limits, but it will not replace them. As such, reCAPTCHA may be activated for your domain's visitors, if the node-level limits have been crossed, even if your domain limits have not.

If you prefer, you can choose not to set domain-level limits at all (set Connection Limit to 0), and just let the CDN handle it at the node level.

Here's an example that might help illustrate the concept. Given the following facts:

• Your domain example.com is regularly served from CDN Node A and CDN Node B.
• Node A has a connection limit of 10
• Node B has a connection limit of 20
• You've set Connection Limit for example.com to 15.

If there are 16 visitors to example.com, and they all hit Node B, example.com's per-node limit of 15 will be crossed and reCAPTCHA will be activated.

If there are 24 visitors to example.com, and 12 go to Node A while the other 12 go to Node B, only the Node A visitors will see a reCAPTCHA, because Node A's limit of 10 was crossed, but Node B's limit of 20 was not, and neither was example.com's per-node limit of 15.

Max Login Attempts¶

This setting defines the maximum number of login attempts any IP address can make before reCAPTCHA is activated. The default is 10, but you can use 0 to require reCAPTCHA activation on every login attempt. After 5 minutes of inactivity, the login attempt count is reset.

Trusted IP addresses are exempt and will not be shown a reCAPTCHA for any number of login attempts.

URL Flood Protection¶

This option was formerly called Protect From Bad Visitor, but URL Flood Protection is a much better description of what it does. Not only does it help protect your site when you are under attack, but it's also handy for positive situations, like where a URL goes viral, or when a popular sale brings hordes to your site.

When this option is set to ON, reCAPTCHA will automatically activate for any URL that is receiving overwhelmingly heavy traffic.

Free Plan users have URL Flood Protection turned ON at all times. Standard Plan users have the option of turning it OFF, but we don't recommend you do so unless you are running benchmark testing.

Block Brute Force by IP¶

This setting is one way to avoid brute force login attacks, and it defaults to OFF. When enabled, this option blocks direct access to log in or to use XML-RPC. To avoid a 403, users must visit a normal page before accessing XML-RPC.

Restrict XML-RPC requests¶

This setting defaults to OFF. When OFF, POST requests to XML-RPC will be allowed unless we detect a request that results in a 403 error code. Upon detection of a 403, all non-trusted IP requests for XML-RPC for the next five minutes will automatically see a 403 error.

Turn this setting ON to always show a 403 error to non-trusted IP addresses which attempt POST requests to XML-RPC.

Block Browser XML-RPC¶

This option is OFF by default. When enabled, access to XML-RPC is blocked to any non-trusted visitors who appear to be using a browser.

Hotlink Protection¶

When turned ON, Hotlink Protection restricts unknown external referrers from linking to images on your domain, while still allowing linking from your own domain aliases. This setting is always ON for Free Plan users, but defaults to OFF for Standard Plan users.

Access Control¶

IP/Subnet Allowlist and Blocklist¶

Exert more fine-grained control over the IP addresses you allow to visit your domain. Those IPs in the Allowlist will be allowed access to your site without being subjected to any security checks. Only add IPs you trust to this list.

Those IPs addresses in the Blocklist will automatically be blocked from your site.

User Agent Allowlist and Blocklist¶

User agents listed in the Allowlist will bypass security checks and ignore any configured reCAPTCHA connection limits. Instead, user agents that match this list will be allowed 100 visits per 10 seconds per IP to a single node. Please be careful with this setting. Only allowlist a user agent if necessary. It is easy to spoof a user agent in order to bypass site security.

User agents listed in the Blocklist will automatically be blocked from your site.

An entry in either of the User Agent lists is considered a match if it is found anywhere in the User-Agent header. Enter one bot per line. Regex is allowed.

Let's look at an example. Assume we've added the following to the Allowlist:

^notabadbot$
agoodbot

We will get the following results:

• User-Agent: notabadbot: MATCH - regex exact match
• User-Agent: abadbot: NO MATCH - does not exactly match notabadbot, does not contain agoodbot
• User-Agent: goodbot: NO MATCH - does not exactly match notabadbot, does not contain agoodbot
• User-Agent: thisisagoodbot: MATCH - contains agoodbot

Googlebot and bingbot are considered 'good' bots by default and are already on the allowlist.

reCAPTCHA Settings¶

reCAPTCHA Type¶

QUIC.cloud currently supports reCAPTCHA v2. With this version you can have either a Checkbox or Invisible reCAPTCHA. Select your preference in this setting.

Max Tries¶

How many tries will you give your visitors to successfully complete a reCAPTCHA challenge? Any number from 1 to 10 is valid. The default is 3.

Custom reCAPTCHA Keys (optional)¶

QUIC.cloud has a default set of keys that we use to control the configuration.

If you want more control over the reCAPTCHA configuration for your domain, you can supply your own set of keys from Google. Enter the values into reCAPTCHA Site Key and reCAPTCHA Secret Key as appropriate.

WordPress¶

All of the options in this section are turned OFF by default.

Allow Jetpack¶

When enabled, the Jetpack WordPress plugin may access XML-RPC. By default, Jetpack is not allowed access to XML-RPC.

Block WP-API User List¶

Malicious bots may attempt to access the users WP API endpoint in order to learn administrative user names for hacking purposes. Enable this option to prevent such access.

Block WP-API Embed¶

When enabled, your site may not be embedded on any other site.

Block WLWManifest¶

To prevent malicious bots from detecting whether you site is running WordPress, you can enable this option and block access to the wlwmanifest file.

Block Author Scan¶

Enable this option to block access to author information. This will prevent bots from using the author query string to learn administrative user names for hacking purposes.