At SITE DISTRICT, we take WordPress security seriously, and feel it is the responsibility of the hosting provider to protect WordPress sites and stop bad traffic. We don't recommend security plugins nor additional proxies like Cloudflare or Sucuri. Why? Because blocking bad traffic is best done at the hosting level, by a host that knows and specializes in WordPress hosting.
Before reading this page you probably should ensure you are familiar with what a WordPress Firewall actually is, and what it does.
It's pointless to talk about the features and capabilities of a WordPress firewall, without first understanding some basics about firewalls, and the security risks to websites that these can protect against.
Even if you think you are decently familiar with WordPress security, this section is worth a read and should provide some useful framing and context for the rest of this article.
Some of the key features of the SiteDistrict firewall include:
User-Agent
HTTP request header to those of common browsers. But by analyzing the requests more carefully, and using statiscal data from millions of requests across sites, we can determine which requests really do come from actual humans using browsers, and which are from bots. The SiteDistrict dashboard includes a number of features that lets you review requests and traffic that has been blocked by the firewall.
Individual requests can be viewed from inside the Access Logs feature, under the Blocked page.
Requests are aggregated and displayed as both useful pie / donut charts, as well as timeseries charts, to help you understand the traffic being blocked, by grouping the requests using useful attributs such as the source network, URL, User-Agent
, IP address, country, and more.
Similar to the Analytics feature, the Reports feature include a Blocked page which lets you create dynamic reports within the SiteDistrict portal, displaying counts for different groupings that you can toggle on & off, including request attributes such as ASN (source network), IP Address, HTTP request Method (GET
, POST, etc.), URL, firewall block reason, HTTP Referer, Browser type and version, and complete User-Agent
string.
Complete false positives from the SiteDistrict firewall - where a visitor is blocked despite our systems for identifying actual humans, or a legitimate bot or third-party service is blocked - are quite rare.
Still, they do happen from time to time. The most common reasons for a false positives from the SiteDistrict firewall include:
In those rare cases when a human visitor is blocked (see False Positives above), the SiteDistrict firewall provides a way for the visitor to provde they are human, which in most cases - at least when the person isn't actually trying to cause michief - will allow them past the firewall, granting access to the protected website.
This challenge is a page that is returned by the firewall, that runs in modern browsers that have JavaScript enabled.
The first thing that a user will see in this case is a blank white page with a simple spinner:
If the user interacts quickly with the page, that is all they will see. However, if they fail to interact with the page within about a second, an additional message will be displayed above the spinner:
If they still haven't interacted with the page after 4 seconds, an additional message will be display below the spinner as well:
Once the user has interacted with the page, the message are hidden and the only the spinner is shown until the challenge is verified by the server.
This system was carefully designed & finalized after significant real-word testing, as providing the best user experience for users that might not be expecting to see any of this in the first place.
If the user has disabled JavaScript, or the request is blocked for some reason, despite passing the challenge, a bot or visitor to the site will be presented with an Access Denied page that looks something like this:
We sometimes refer to this screen as the "Yellow Screen of Death". The goal is that legitimate users will never see it, but there remain very occational instances where someone will encounter this page. Bots and third-party services that attempt to access sites on SiteDistrict and are blocked may also encounter this screen.
Those who managed WordPress sites and have dealt with security issues at other hosts and have moved to SiteDistrict are often amazed and enamored with the level of security that we provide for WordPress sites hosted on our platform.