Malicious code and injection attempts
Requests that try to make the site execute code, read files it should not, or manipulate database queries are stopped before they reach WordPress's own handling.
Protection that sits inside the site
A plugin installed in WordPress and activated with a licence key. It uses the same threat data as the clients, but acts where attacks on a website actually land.
The attacks aimed at WordPress
Most attempts against a WordPress site are automated. The same tools test the same weaknesses against thousands of sites at a time.
Vulnerability scanning
Systematic probing for known weaknesses in themes and plugins, and for versions with known vulnerabilities, is recognised as scanning and blocked.
Login attacks
Brute force against administrator accounts is stopped. Repeated attempts from the same source are blocked rather than simply failing over and over.
Known attackers
Traffic from addresses already known for attacking other sites is refused outright, whatever that particular request contains.
Install, activate, done
The plugin is installed like any WordPress plugin and activated with the licence key from the panel. After that it works without you having to configure rules manually.
Each site draws one licence from your pool. If you have several sites you see them all in the panel, each with its own log of what has been stopped.
- Installed in WordPress like an ordinary plugin
- Activated with a licence key from the customer panel
- Updates its threat data automatically
- One licence per site, from the same pool as the clients
- Logs collected in the panel alongside your other devices
What you see in WordPress
The plugin adds its own view inside the WordPress admin. There you can see that protection is active, which categories of attack are covered and which addresses have been blocked on this particular site.
If a customer needs access to something being stopped, protection can be paused temporarily, for a set number of hours or until further notice. Logging continues during the pause.
- Status for the firewall and login protection
- A list of addresses blocked on the site
- Whitelisting for addresses that must never be stopped
- A preview of the message a blocked visitor is shown
- Security scan of the installation
- Temporary pause of the protection during troubleshooting
- Protection of sensitive files such as wp-config.php and .htaccess
- Block message shown in the visitor's own language
The rule set behind it
The protection is not a general firewall with a handful of rules of thumb. It builds on a rule set divided by attack type, weighted towards where the attempts actually come from.
Categories with the most rules
- Command injection
- Local file inclusion
- SQL injection
- Sensitive data exposure
- Vulnerable IoT devices
- Cross-site scripting
- Probing for security products and firewalls
- Probing for backups
- Vulnerable network equipment
- Remote code execution
The rule set is updated continuously from the core. You do not have to manage the rules yourself.
Dynamic rules rather than a static list
The rules are not fixed inside the plugin. They are fetched from our core and replaced as the threat picture changes, without you having to update anything.
Signed updates
Every rule update is signed. A response without a valid signature is ignored, so nobody can inject rules of their own along the way.
Log mode before block mode
On a new site the protection can run in log mode first. What would have been stopped is recorded without anything actually being blocked, so false positives can be measured before it is switched on.
Search engines are never stopped
Verified search engines are fully exempted, through a signed address list updated daily and matched locally. We trust the real source of the connection, not a browser string that can be forged.
When something is stopped by mistake
Protection that blocks the wrong visitor costs more than it is worth. So there are several ways to make exceptions, and they apply before any inspection takes place.
- A single IP address or a whole network — always let through, taking precedence over both local and global blocks
- A path or address on the site — exempt from inspection, useful for uploads and API calls
- A browser string — exempts a specific client or integration
Exceptions can be set per site, or centrally for all your sites at once.
The protection manages without contact
Blocks apply locally on the site. Should the core be unreachable, the plugin carries on stopping what it already knows about, and the events are sent in afterwards. An outage at our end does not open your site up.
Protection has to sit where the attack lands
A firewall in front of the web server sees requests, but not what WordPress does with them. A plugin inside WordPress sees the context: which theme and plugins are installed, which request is aimed at what, and which login attempts are made against which accounts.
That lets the protection tell an ordinary visitor apart from a tool systematically looking for weaknesses — even when they use the same kind of requests.
Protect your first site
Create an account, get the plugin and activate it with your licence key.