內容簡介
Deny All Firewall 是一款針對 WordPress 的防火牆外掛，透過建立 Apache .htaccess 規則，預設拒絕所有不必要的請求，從而減少伺服器負擔並提高網站安全性。
【主要功能】
• 自動生成針對網站的專屬 .htaccess 規則
• 拒絕不必要的 PHP 和其他檔案的直接存取
• 支援 Cloudflare 訪客 IP 地址的處理
• 減少常見的偵查行為如使用者枚舉
• 自動調整保護規則以適應網站大小變化
外掛標籤
開發者團隊
📦 歷史版本下載
原文外掛簡介
Most WordPress firewalls start with everything open and look for known bad requests.
Deny All Firewall turns that idea around.
It examines your WordPress site and creates Apache .htaccess rules that allow its genuine public content and normal WordPress functions. Requests outside those rules are refused by the web server before WordPress, PHP, the database, your theme or your other plugins need to process them.
That means less work for your server and fewer opportunities for automated scanners to explore files and addresses your website does not need to expose.
A deny-by-default firewall for WordPress
Deny All Firewall generates rules specifically for the site on which it is installed. Depending on your content and configuration, those rules can:
Allow published pages, posts, products, media, archives, feeds and sitemaps
Keep the WordPress REST API, WP-Cron and admin-ajax.php available
Allow the public files required by your active theme and plugins
Refuse direct access to PHP and other files that should not be requested publicly
Reject unsupported HTTP methods before they reach WordPress
Reduce common reconnaissance such as user enumeration and plugin or theme probing
Reject routine /wp-admin/ scanner traffic unless the request presents this website’s WordPress logged-in cookie
Work with Cloudflare visitor IP addresses when the request genuinely came through Cloudflare
Send refused requests to the plugin’s lightweight blocked page
This is not a generic list copied into every .htaccess file. The firewall is built around the content and features WordPress reports for your website.
Automatic protection that adapts to your site
Content Protection uses individual rules on smaller sites. When the number of rules would make .htaccess too large or slow, the plugin automatically switches to broader public-content matching. If the site becomes smaller again, exact protection can return automatically.
Admin Access Protection can reject routine /wp-admin/ scanner traffic unless the browser presents this website’s WordPress logged-in cookie. Apache checks only for the cookie’s presence; WordPress still validates it and requires users to sign in normally.
These decisions are made when the firewall rules are refreshed, not on every page view.
Optional Extra Request Protection
Extra Request Protection checks information added after a ? in a page request and blocks unexpected form submissions. Normal WordPress requests and anything you explicitly allow remain available.
This is intentionally strict. Forms, shops, webhooks and third-party integrations can have site-specific requirements, so test them carefully after enabling it.
Clear troubleshooting when something genuine is blocked
Temporarily enable Blocked Request Troubleshooting to record refused addresses. The settings page explains common requests and lets you add a recognised request directly to Allowed Requests and Redirects.
Allowed entries can:
Match one exact address
Use an advanced pattern when genuinely needed
Permanently redirect an old address elsewhere with a 301 response
Troubleshooting is intended to be temporary. Its log is limited to approximately 10 MB and is deleted when troubleshooting is disabled.
Less repeated work
The plugin creates a physical copy of WordPress’s filtered robots.txt output when the firewall is refreshed. Search engines can then read the same instructions without repeatedly loading WordPress and PHP. An existing robots.txt file that was not created by Deny All Firewall is preserved.
WordPress’s standard sitemap remains available, along with supported sitemap files created by SEO plugins.
The plugin also:
Alerts administrators when content changes may require refreshed firewall rules
Records a small selection of blocked suspected malicious requests and summarises the last 60 minutes for administrators on the Dashboard
Offers an optional HTTPS redirect for sites on which HTTPS is already working
Removes WordPress version information from page and feed metadata
Removes its generated .htaccess rules, generated robots.txt file and runtime files when properly deactivated
Security, performance and unnecessary carbon emissions
Refusing nonsense at the web-server level is much cheaper than loading an entire content-management system merely to decide that the requested content does not exist.
On a heavily scanned WordPress site blocking around 50,000–100,000 unwanted requests per day, we estimate that Deny All Firewall could avoid approximately 100 kg of CO2 emissions per year—roughly comparable to the direct emissions attributable to one passenger on a one-way flight from London to Ibiza!
Read the calculation, assumptions and limitations.
Important requirements
Deny All Firewall currently supports Apache, using mod_rewrite and .htaccess
Your site’s .htaccess file must be writable; the website root must also be writable when the plugin needs to create its static robots.txt file
Because this is a deny-by-default firewall, test important forms, checkout journeys, webhooks and integrations after enabling it
Keep a normal backup and know how to edit .htaccess through your hosting control panel or file manager before enabling any firewall
If the plugin blocks a genuine request that is not covered by its troubleshooting tools, please report it through the support forum.
