SiteDistrict WordPress Firewall

Keep the bad guys out without bothering the good guys

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.

Firewall Basics

Before reading this page you probably should ensure you are familiar with what a WordPress Firewall actually is, and what it does.

It's premature 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.

Features

Some of the key features of the SiteDistrict firewall include:

• WordPress Specific - Our firewall has a built-in understanding of both what legitimate traffic to a WordPress site looks like, as well as malicious traffic. Rules and algorithms know what type of URLs, cookies, query strings, referers, and other request parameters are likely valid for WordPress, and which are malicious or indicate an attack. Our firewall also knows if requests are sent by valid WordPress users - all without needing to execute any actual WordPress or PHP code. All of this means that when it comes to WordPress, we can block more of the junk from the bad guys, while still letting valid users through.
• High Performance - The SiteDistrict firewall is written in Lua, a high performance scripting language popular for embedding into other systems. It is embedded into a custom build of Nginx which makes use of OpenResty modules. By using Lua inside Nginx, instead of PHP, we can block hundreds to thousands of requests per second, without affecting site performance. Our firewall has many similarities to the one implemented by Cloudflare, a billion-dollar company, and technological leader in the field of web security.
• Universal - Because the SiteDistrict firewall is embedded directly into the web server, it automatically protects all sites on SiteDistrict. No need to install and update security plugins across any of your sites.
• Distributed / Global - Also like Cloudflare, SiteDistrict uses Anycast IP addresses and a global network or proxy servers that sit close to site visitors, and handle incoming requests, either passing requests through to the origin server where the website is actually hosted, functioning as a content delivery network (CDN), by serving up a cached version of the page or asset, or blocking the request at the edge with the firewall. This reduces bad traffic across our network, and spreads out the job of blocking malicious traffic across multiple servers around the world.
• All-in-One - The SiteDistrict firewall protects sites against many different types of attacks, rather than just specific types. These include D(D)oS attacks, brute-force attacks, spam comments, spam form submissions, general file probes, PHP file probes, bad bots, software vulnerabilities & exploits, fraudulent orders, and more.
• Multi-factor - Unlike many WordPress security plugins & and simple rule-based firewalls like the 6G/7G firewall, ModSecurity, and others, the SiteDistrict firewall uses a far more powerful combintation of rules, reputation based on request history, and automatic challenges to calculate a score for each request, which is then used to make blocking decisions. This allows SiteDistrict to block a much greater number of requests, while also maintaining an excpetionally low level of false positives.
• Browser Integrity Checks - Another feature that we discovered Cloudflare also thought of, is our browser integrity checks, which are enabled across all sites automatically. It has been found that a good amount of malicious traffic "pretends" to be from browsers, by setting the 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.
• Human Recognition - In some cases, often when visitors use a VPN or service that is also used by attackers, we will block a request, and issue an automatic challenge to the visitor, which checks to see that they are using a valid browser and interact with the site like a human. This process is nearly transparent to users, and allows us to continue blocking bad traffic coming of all sorts and from all places, while letting legitimate users continue to access sites after establishing their requests are likely from an actual human.

SiteDistrict Dashboard

The SiteDistrict dashboard includes a number of features that lets you review requests and traffic that have been blocked by the firewall.

Access Logs

Individual requests can be viewed from inside the Access Logs feature, under the Blocked page.

Analytics

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 attributes such as the source network, URL, User-Agent, IP address, country, and more.

Reports

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.

False Positives

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:

Humans

• VPN usageVisitors who use a VPN to access sites hosted on SiteDistrict are much more likely to be blocked when they first visit a site. This is because man bots also use VPNs to send malicious traffic at sites, and so any requests coming in via a VPN are suspect. The browser & human challenges described below typically make this a non-issue for legitimate visitors.
• Old BrowsersA lot of bad traffic to sites on SiteDistrict claims to be coming from older browsers, which are no longer in use by most actual visitors. Older versions of Chrome, Firefox, and Safari are typically not used by actual people, and any traffic using a User-Agent for such a browser is more likely to be blocked. If an actual human is actually using an outdated browser, the browser & human challenges described below will typically allow them access.

Bots / Services

• Non-IdentificationBots and external services which attempt to access sites on SiteDistrict but do not identify themselves properly via the User-Agent HTTP request header are very likely to be blocked, as their requests will often look similar to malicious traffic from bots. In addition, such bots are not being "good internet citizens". For more information about this case, see our page: Our Service or Tool is Being Blocked.
• Bad Network / Service ProviderThere are certain network service and hosting providers that have earned a bad reputation with the SiteDistrict firewall, because they send primarily bad or malicious traffic to sites. These typically include more generic and entry-level hosting providers, which often host sites that are hacked, as well as data centers and co-location providers that allow customers to use their infrastructure to send bad traffic, and generally turn a blind eye to abuse. Requests that come from such providers is very rarely legitimate, and thus much more likely to be blocked. In some cases, and a legitimate tool or service provider has chosen to use such a provider, likely because they are "cheap", and their requests are blocked. If this appears to be the case, see our page: Our Service or Tool is Being Blocked.

Browser Challenge

In those rare cases when a human visitor is blocked (see False Positives above), the SiteDistrict firewall will issue a browser challenge, which will try to verify that an actual browser is being used to access the website. In most of these cases - at least when the person isn't actually trying to cause michief - this will automatically let the human visitor 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. What is displayed depends on how fast the user's network connection is, and how fast the browser can complete the challenge.

If the browser and network connection are fast enough, the user will see nothing, except possibly a white screen for a fraction of a second.

If after 100 millisecionds, the browser challenege has not completed, a simple spinner is displayed in the center of the page:

In cases where it takes more than 0.8 seconds to complete the browser challenge, an additional text message is displayed to the visitor:

The page will then be reloaded once the browser challenge has completed.

Human Challenge

In those rare cases when a human visitor is still blocked, even after passing the browser challenge, the SiteDistrict firewall will then allow visitor to prove they are human by interacting with the page, and clicking a "I'm not a robot" checkbox.

Once the user has clicked this checkbox, a spinner will be shown, and the firewall will make a final decision as to whether to grant access to the requested page or not.

Access Denied

If the user has disabled JavaScript, or the request is blocked for some reason, despite passing the challenges, 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 occasional 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.

Summary

This system was carefully designed & has evolved to its currents state after years of real-word testing and many rounds of improvements, with the end goal being to provide the best user experience and the least interference for legitimate users who are probably not expecting to see any of this in the first place.

Comparison

For a more general comparison of the types of WordPress firewalls, including the general pros and cons of hosting-based firewalls vs. other types, see our WordPress Firewalls page.

Plugins

There are numerous WordPress plugins available that attempt to protect WordPress sites from attacks, spam, hacking, and more. There is no need to run these on SiteDistrict, and they generally cause more problems than they solve. The biggest problem many of these plugins have is false positives. One reason this is a problem is that site owners don't often know when the plugin is blocking people and request that it should not. Unless your user base already knows how to contact you outside your website, and is motivated to do so, you could be blocking back traffic and never know it. Many of these plugins lack the browser & human verification essential to reducing false positives.

So called "Premium" features such as real-time blacklists are actually one of the worst sources of false positives. Blocking IP addresses is a fool's errand to start with, yet some of the popular WordPress firewall plugins do this, blocking legitimate traffic, especially users of VPNs.

Another significant problem for WordPress security plugins is performance at scale. When attacks reach the levels of 20 - 100 requests per second on a site, most if not all WordPress plugins will crumple, and the site will go down. The SiteDistrict firewall sits on top of sites, is distributed across servers, and can handle many times the amount of traffic without even flinching, nor affecting site performance. With larger scale (D)DoS attacks becoming more common, this performance advantage is becoming critical for WordPress sites that want to maintain uptime & reliability.

Cloudflare

Many of the larger managed WordPress hosts have integrated Cloudflare into their hosting, instead of building their own firewall. We believe this is because they failed to figure out a way to to protect their sites from (D)DoS and other attacks on their own, and they became desparate as the numbers of attacks have increased in recent years, and likely suffered more frequent and more severe performance & security incidents.

SiteDistrict is the exception. We have been engineering and improving our firewall for almost 9 years, and it's actually better overall than Cloudflare, for protecting WordPress sites.

Many sites on SiteDistrict do use the Cloudflare proxy, yet we still block hundreds of thousands of requests to these sites every day that Cloudflare does not block. In fact, our firewall protection is often even more effective when the Cloudflare proxy is disabled.

Because our firewall is more focused, and dedicated specifically to protecting just WordPress sites, we have some key advantages over Cloudflare. Our rules and algorithms can be more specific and more aggressive than Cloudflare, for the traffic that we handle, because we are protecting just one type of site (WordPress), vs. hundreds of different types of sites.

Unblocked Traffic

In addition to using the SiteDistrict dashboard's Analytics and Access Logs features as described in the Dashboard section above to review Blocked traffic, you may also review unblocked traffic by reviewing the charts and logs on the Dynamic page of each.

If you suspect your site is being attacked or is receiving malicious or unwanted requests, these tools can help you confirm this. If you do find some traffic, use the Filter box to filter down the Access Logs to show just the unwanted requests, and then contact SiteDistrict support with a link to the Access Logs, and a screenshot of the requests. We'll review and take appropriate action.

Testimonials

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.

Noteworth Stats

The effectiveness and impressiveness of the SiteDistrict firewall can be further appreciated by looking at some of the statistics in terms of the percentages of blocked requests.

Certain pages and URLs on WordPress sites are used by real users and legitimate services, but also highly targeted by malicious bots.

Being able to block a very high percentage of these requests accurately is a good measure of how good a WordPress firewall is.

Summary

The SiteDistrict firewall is an essential part of the SiteDistrict platform, protecting sites from millions of bad requests every day.

The firewall protects WordPress sites from a number of issues, including performance problems & denial-of-service issues, comment and form spam, junk signups & subscribers, site takeovers, and other types of hacking.

Blocking such a high level of traffic would be impossible without advanced rules, statistics, and an automated system for handling false positives, so that legitimate human users are not blocked from accessing sites.

WordPress sites hosted on SiteDistrict are advised against running firewall and other security plugins, because they are an inferior solution in terms of performance, accuracy, and the rate of false positives generated. Such plugins also lead site owners and developers to waste time configuring settings & options that they should never need to understand nor touch in the first place.