Title: Deny All Firewall Author: Oliver Campion Published: 24. Mai 2019 Last modified: 7. Oktober 2026 --- Search plugins ![](https://ps.w.org/deny-all-firewall/assets/banner-772x250.jpg?rev=3643761) ![](https://ps.w.org/deny-all-firewall/assets/icon-256x256.jpg?rev=3150585) # Deny All Firewall By [Oliver Campion](https://profiles.wordpress.org/domainsupport/) [Download](https://downloads.wordpress.org/plugin/deny-all-firewall.2.0.4.zip) * [Details](https://de-ch.wordpress.org/plugins/deny-all-firewall/#description) * [Reviews](https://de-ch.wordpress.org/plugins/deny-all-firewall/#reviews) * [Installation](https://de-ch.wordpress.org/plugins/deny-all-firewall/#installation) * [Development](https://de-ch.wordpress.org/plugins/deny-all-firewall/#developers) [Support](https://wordpress.org/support/plugin/deny-all-firewall/) ## Description 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](https://webd.uk/can-a-wordpress-firewall-really-help-save-the-planet/). #### 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. ## Installation 1. Install and activate **Deny All Firewall** through the WordPress Plugins screen. 2. Open **Settings Deny All Firewall**. 3. Select **Firewall Enabled** and review the settings that appear. 4. Save the settings to generate the firewall rules. 5. Test the public site, forms, search, sign-in, administration area and any shop or third-party integrations. 6. If something genuine is refused, temporarily enable **Blocked Request Troubleshooting**, reproduce the request and review it before allowing it. You should also refresh the firewall rules after making significant content or configuration changes. The plugin displays a reminder when it detects relevant changes. ## FAQ ### Is this a replacement for WordPress updates, secure passwords or backups? No. Deny All Firewall reduces the public attack surface and unnecessary processing. Continue to update WordPress, themes and plugins, use strong authentication, maintain backups and follow normal server-security practices. ### Why deny everything instead of searching for known attacks? Attack signatures can identify known bad input, but they must continually account for new variations. Deny All Firewall begins with the smaller question: which public requests does this particular website genuinely need? Requests outside that answer can be refused before WordPress processes them. This complements other security layers rather than making them unnecessary. ### Could it block part of my website? Yes. Strict rules can expose unusual requirements in forms, ecommerce extensions, webhooks, membership systems and third-party integrations. The plugin preserves normal WordPress functionality and known public content, but it cannot predict every custom implementation. Test the site after enabling the firewall and use Blocked Request Troubleshooting to investigate genuine requests before allowing them. ### Does it block the WordPress REST API? No. The configured WordPress REST API path and `rest_route` requests remain available. Write methods such as `PUT`, `PATCH` and `DELETE` are refused elsewhere because ordinary public WordPress pages do not normally need them. ### Will it block robots.txt or WordPress sitemaps? No. The plugin generates a static `robots.txt` file from WordPress’s filtered output so crawlers do not need to load WordPress repeatedly. The standard WordPress sitemap remains allowed. If the website already has a physical `robots.txt` file that Deny All Firewall did not create, it is left unchanged. Sites that need WordPress to generate different `robots.txt` contents for different hostnames can disable the physical file with the `daf_enable_static_robots_txt` filter: ``` add_filter('daf_enable_static_robots_txt', '__return_false'); ``` Refresh the firewall rules once after adding or removing this filter. When disabled, Deny All Firewall removes only a `robots.txt` file that it previously generated and leaves other physical files untouched. ### What information does Blocked Request Troubleshooting record? The temporary log records information needed to identify a refused request, including the requested address, time and originating IP address. Logs may therefore contain personal data under some privacy laws. Logging is disabled automatically when the firewall is disabled. The log is limited to approximately 10 MB and is deleted when troubleshooting is turned off. ### What does the Suspected Malicious Requests Blocked Dashboard panel show? The plugin’s lightweight blocked page recognises a deliberately small set of suspected malicious requests for items such as environment files, repository internals, cloud credentials, specifically named attack scripts and direct PHP requests within internal WordPress core directories. Genuine directly accessible WordPress maintenance and script-delivery endpoints are excluded. It records the time, visitor IP address, HTTP method and matched path without loading WordPress. Automated malicious probing is common on public websites. Every request shown in the Dashboard panel was blocked before WordPress loaded. The records show attempted probing, not a successful compromise, and no action is normally required. The Dashboard panel shows the ten busiest originating IP addresses and the paths they requested during the rolling last 60 minutes. These always-on records are kept in hourly files under `wp-content/deny-all-firewall`, which is protected from public access. Each hourly file stops growing at 10 MiB. Only the current and immediately preceding UTC-hour files are retained, and the runtime directory is removed when the plugin is properly deactivated. ### What happens when I publish new content? Exact Content Protection may need a refreshed rule for newly published content. The plugin monitors relevant content changes and displays an administrator notice when its rules should be refreshed. Larger sites use broader automatic matching and do not require an individual rule for every public item. ### What if I am locked out? Use your hosting control panel, FTP or file manager to edit the site’s `.htaccess` file. Remove only the section between: ``` # BEGIN Deny All Firewall ``` and: ``` # END Deny All Firewall ``` Do not delete unrelated WordPress or hosting rules. Once access is restored, review the firewall settings and refresh its rules. ### Does it support Nginx, IIS or servers that ignore .htaccess? Not currently. The generated rules require Apache with `mod_rewrite` and `.htaccess` support. ### Does disabling or deactivating the plugin remove its rules? Disabling the firewall through its settings removes the generated `.htaccess` section. Properly deactivating the plugin also removes its generated rules, its own generated` robots.txt`, blocked-page data and troubleshooting logs, and its firewall-rule lock file. An existing `robots.txt` file that was not created by the plugin is preserved. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “Deny All Firewall” is open source software. The following people have contributed to this plugin. Contributors * [ Oliver Campion ](https://profiles.wordpress.org/domainsupport/) [Translate “Deny All Firewall” into your language.](https://translate.wordpress.org/projects/wp-plugins/deny-all-firewall) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/deny-all-firewall/), check out the [SVN repository](https://plugins.svn.wordpress.org/deny-all-firewall/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/deny-all-firewall/) by [RSS](https://plugins.trac.wordpress.org/log/deny-all-firewall/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 2.0.4 * Added the `daf_enable_static_robots_txt` filter so sites requiring hostname-specific robots.txt output can keep it dynamic #### 2.0.3 * Replaced changing-IP administration access rules with lightweight logged-in-cookie detection * Added hourly immediate-threat logs for high-confidence secret, exploit and internal WordPress PHP requests * Added a Dashboard summary of immediate threats detected during the last 60 minutes * Moved runtime files into a protected `wp-content/deny-all-firewall` directory #### 2.0.2 * Preserved REST API exemptions through WordPress internal rewrites so valid form submissions and authenticated REST requests remain available * Clarified when existing installations need to refresh their firewall rules to change Content Protection or Admin Access Protection mode * Removed generated blocked-page data, troubleshooting logs, the legacy refresh schedule and the firewall-rule lock file on deactivation #### 2.0.1 * Removed an unnecessary Block wp-login exception so public administration-email confirmation requests remain blocked * Prevented activation or enabling when an incompatible server or unusable `.htaccess` location can be confirmed * Added refresh locking to prevent simultaneous requests from duplicating, replacing or restoring firewall rules #### 2.0 * Improved the accuracy and compatibility of generated `.htaccess` rules, including HTTP-method handling, REST requests, Cloudflare * Added automatic Content Protection and Admin Access Protection that adapt before content or active-session IP rules become too large * Improved active-session IP handling with broader IPv4 matching, exact IPv6 matching and removal of expired sessions * Replaced the legacy sitemap with a static filtered `robots.txt` file while preserving WordPress sitemaps and adding automatic deactivation cleanup * Redesigned the settings and troubleshooting experience with clearer guidance, safer allowed requests, redirects and numerous reliability improvements ## Meta * Version **2.0.4** * Last updated **1 Woche ago** * Active installations **30+** * WordPress version ** 5.0 or higher ** * Tested up to **7.1.3** * PHP version ** 7.0 or higher ** * Language * [English (US)](https://wordpress.org/plugins/deny-all-firewall/) * Tags * [carbon footprint](https://de-ch.wordpress.org/plugins/tags/carbon-footprint/) [firewall](https://de-ch.wordpress.org/plugins/tags/firewall/)[htaccess](https://de-ch.wordpress.org/plugins/tags/htaccess/) [performance](https://de-ch.wordpress.org/plugins/tags/performance/)[security](https://de-ch.wordpress.org/plugins/tags/security/) * [Advanced View](https://de-ch.wordpress.org/plugins/deny-all-firewall/advanced/) ## Ratings Es wurden noch keine Rezensionen eingereicht. [Your review](https://wordpress.org/support/plugin/deny-all-firewall/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/deny-all-firewall/reviews/) ## Contributors * [ Oliver Campion ](https://profiles.wordpress.org/domainsupport/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/deny-all-firewall/) ## Donate Would you like to support the advancement of this plugin? [ Donate to this plugin ](https://webd.uk/product/support-us/)