IP Firewall for a Self-Hosted Blog: Stop Scanners Early
Every public blog is probed by scanners looking for WordPress files, leaked config and weak passwords. Here is how a scoring IP firewall blocks them without blocking search engines.
An IP firewall for a blog watches failing requests, gives each a threat score, and blocks an address once its score crosses a threshold. Exploit probes score high, ordinary 404s score low, and search crawlers are protected, so scanners block themselves while readers and Googlebot never notice.
Open the 404 log of almost any public blog and you will find requests for pages that never existed: /wp-login.php, /.env, /.git/config. They come from automated scanners that sweep the internet for known weaknesses. Most of them fail, but they use your server's time, bury real errors in noise, and keep trying until something works. An IP firewall that blocks them automatically is one of the cheapest security wins a self-hosted blog can get.
What scanners are looking for
Scanners do not care what your blog runs on. They try the same list everywhere and wait for a hit:
- WordPress and PHP paths, such as
wp-adminandxmlrpc.php, hoping for an old plugin. - Leaked configuration, such as
.envfiles and exposed.gitfolders that contain passwords and keys. - Injection payloads: path traversal and SQL injection strings in the URL.
- Password guessing on the sign-in page, using lists of leaked credentials.
How a scoring firewall works
A static blocklist goes stale quickly, because scanners rotate addresses. A scoring firewall reacts to behaviour instead. Each failing request adds points to the address that sent it: a lot for an obvious exploit probe, some for a rejected sign-in, a little for an ordinary missing page. When an address crosses a threshold within a short window, it is blocked, and repeat offenders are blocked for longer. Blocked requests are refused at the door, before the application does any real work.
Mistakes to avoid
A firewall that blocks the wrong traffic does more harm than the scanners it stops. Watch for these:
- Blocking search and AI crawlers. They hit plenty of 404s too. Block Googlebot and your pages drop out of search.
- Trusting proxy headers blindly. If you accept any
X-Forwarded-Forvalue, an attacker can pretend to be someone else. If you ignore it behind a real proxy, every visitor looks like the proxy. - Blocking your own network. Loopback and private addresses should never be blocked.
- Failing closed. If the firewall's own storage is down, it should let traffic through, not take the site offline.
The best firewall is one readers and search engines never notice, and scanners notice immediately.
How Inkwell's IP firewall works
Inkwell has shipped an automatic IP firewall since v1.0.4. Exploit probes (.php, wp-admin, .env, .git, path traversal and SQL-injection payloads) score 5 points, a rejected sign-in scores 3, and an ordinary 404 scores 1. At 10 points within 10 minutes, both configurable, the address is blocked: 24 hours on the first offense, a week on the second, permanently on the third. Blocked addresses get a bare 403 before routing runs.
- Admin > Security shows active blocks with their reason, a live watchlist of addresses building a score, and the thresholds, allowlist and email alerts. You can block or allowlist an address by hand.
- Safe by default: loopback and private ranges are never blocked, signed-in staff are never scored, search and AI crawlers are never blocked for 404s, and the firewall fails open if the database is unreachable.
- Crawler impersonators lose that protection (since v1.0.7) once an address is proven not to be the crawler it claims, using the operator's published IP list and reverse DNS for Google, Bing and Apple.
- Behind a proxy, proxy headers are ignored unless you declare a trusted proxy, so a client cannot forge its address.
- Comment spam feeds it too: deleting a comment as spam reports its address to the firewall, as covered in our post on self-hosted blog comments.
Every block, unblock, allowlist entry and settings change is written to the audit trail. If you want to see which crawlers are reaching your site in the first place, our guide to AI crawlers explains what each one does.
A firewall is one layer, not the whole wall
Blocking scanners reduces noise and risk, but it does not replace the basics: keep your runtime and application updated, use strong unique passwords, and keep tested backups. Our look at this year's CMS vulnerabilities shows how fast attackers move once a flaw is public. The documentation covers installation and configuration, including running behind a reverse proxy.
Frequently asked questions
What is an IP firewall for a blog?
It is a layer that watches requests to your blog, scores failing ones by how hostile they look, and blocks addresses that cross a threshold. Scanners probing for WordPress files or leaked config block themselves quickly, while normal readers are never affected.
Will an IP firewall block Googlebot?
A well-designed one will not. Search and AI crawlers hit many missing pages, so they should be protected from 404-based blocking. Inkwell never blocks them for 404s unless an address is proven not to be the crawler it claims to be.
Does an IP firewall work behind Cloudflare or a reverse proxy?
Yes, if it is told which proxy to trust. It must read the real client address from headers like CF-Connecting-IP or X-Forwarded-For only when they come from your proxy. Otherwise attackers could forge their address, or every visitor would look like the proxy.
Does Inkwell have a built-in IP firewall?
Yes. Since v1.0.4, Inkwell scores failing requests and blocks hostile addresses automatically, with escalating block times, an Admin Security screen for blocks, the watchlist and allowlist, and every change recorded in the audit trail.
Ready to host your own blog?
Inkwell is free, open-source, and self-hosted — your content, your server, your rules. Deploy in minutes on .NET 10.