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 (the options will not be visible for those on the Free Plan).
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.
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.
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.
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. (Tip: If you have been a QUIC.cloud user for a long time, your Connection Limit may be set to
0, as that was the original default.)
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.comis regularly served from CDN Node A and CDN Node B.
- Node A has a connection limit of
- Node B has a connection limit of
- You’ve set Connection Limit for
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
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. (Tip: If you have been a QUIC.cloud user for a long time, your Max Login Attempts may be set to
10, as that was the original default.)
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. If a URL at your site is receiving overwhelmingly heavy traffic, set this option to
ON. This will enable reCAPTCHA immediately for every visitor to beleaguered URLs.
When the crisis is over, turn this setting back
OFF, and reCAPTCHA will revert to being controlled by the Connection Limit and Max Login Attempts settings as before.
NOTE: You may want to use this option when you are under attack, but it’s also handy for positive situations, like where a URL goes viral, or a popular sale brings hordes to your site.
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, 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
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.
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:
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
User-Agent: goodbot: NO MATCH – does not exactly match
notabadbot, does not contain
User-Agent: thisisagoodbot: MATCH – contains
bingbot are considered ‘good’ bots by default and are already on the allowlist.
QUIC.cloud currently supports reCAPTCHA v2. With this version you can have either a
Invisible reCAPTCHA. Select your preference in this setting.
How many tries will you give your visitors to successfully complete a reCAPTCHA challenge? Any number from
10 is valid. The default is
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.
All of the options in this section are turned
OFF by default.
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.
To prevent malicious bots from detecting whether you site is running WordPress, you can enable this option and block access to the
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.