Drupal Perimeter Defence

A security module that automatically bans IP addresses making suspicious requests to non-existent URLs matching configurable patterns, protecting Drupal sites from hackers and bots.

perimeter
8,092 sites
60
drupal.org
gui api utility
security ip-ban bot-protection spam-prevention perimeter-defense firewall 404-protection honeypot-integration
Drupal 10 Drupal 11

Install

Drupal 11, 10 v3.0.4
composer require 'drupal/perimeter:^3.0'

Overview

Drupal Perimeter Defence provides basic perimeter defense for Drupal sites by automatically banning IP addresses that send suspicious requests. The module monitors 404 (Page Not Found) responses and checks the requested URLs against a configurable list of regular expression patterns. When a match is found, the requesting IP is immediately banned using Drupal core's Ban module.

This module is particularly useful when your site receives numerous requests targeting non-Drupal platforms such as WordPress admin pages (wp-admin, wp-login), ASP.NET files (.aspx, .asp), JSP files (.jsp), or other suspicious patterns commonly used by automated scanners and bots.

The module is optimized for performance and designed to be activated when a Drupal site is actively targeted. It includes flood protection to allow a configurable number of attempts before banning, IP whitelisting to prevent blocking legitimate users or services, and integration with the Honeypot module for additional spam protection.

Features

  • Automatic IP banning based on configurable URL regex patterns for suspicious 404 requests
  • Pre-configured patterns for common attack vectors including WordPress (wp-admin, wp-login), ASP.NET (.aspx, .asp), JSP (.jsp), and other malicious URLs
  • IP whitelist support with CIDR notation (e.g., 192.168.1.0/24) to exclude trusted IPs and ranges from being banned
  • Flood threshold control allowing a configurable number of attempts before banning an IP address
  • Configurable flood time window for controlling how long the attempt counter persists
  • Integration with Drupal core Ban module for managing banned IP addresses
  • Honeypot module integration - automatically bans IPs that trigger honeypot time-based protection (except for user login forms)
  • Permission-based bypass allowing trusted users to access banned URLs without being blocked
  • Detailed logging of banned IPs including source URL, referrer, and user agent information
  • Compatible with Drupal 10 and 11

Use Cases

Protecting against WordPress vulnerability scanners

Many automated bots scan websites looking for WordPress installations by requesting URLs like /wp-admin, /wp-login.php, /wp-content/, etc. When these bots target a Drupal site, they generate unnecessary server load with repeated 404 errors. By enabling Perimeter Defence with the default patterns, these bots are immediately banned after their first request, preventing further scanning attempts and reducing server load.

Blocking technology-specific exploit attempts

Attackers often probe websites with URLs containing .aspx, .asp, or .jsp extensions looking for vulnerable Microsoft IIS or Java application servers. On a Linux/Drupal server, these requests are clearly malicious. Perimeter Defence automatically bans these probing IPs, protecting your server from follow-up attacks.

Gradual ban implementation with flood threshold

For sites where legitimate users might occasionally trigger a banned pattern accidentally, set the flood threshold to a value like 3. This allows users to make a few mistakes before being banned. Combined with an appropriate flood window (e.g., 3600 seconds/1 hour), this provides a balance between security and usability.

Protecting CDN or proxy server IPs

If your site uses a CDN or load balancer, add the CDN's IP ranges to the whitelist to prevent accidentally banning your infrastructure. For example, add Cloudflare's IP ranges in CIDR notation to ensure CDN requests are never blocked.

Integration with Honeypot for form spam protection

When used alongside the Honeypot module, Perimeter Defence provides additional protection by banning IPs that repeatedly fail honeypot's time-based protection. This is effective against automated spam bots that submit forms too quickly.

Protecting staging or development sites

Development and staging sites are often discovered by bots and attacked. Enable Perimeter Defence to automatically ban reconnaissance attempts, reducing noise in logs and protecting sensitive development data.

Tips

  • Always test the module's behavior from a different IP or device before deploying to production, and ensure you have database access to remove your IP from bans if needed
  • Start with a higher flood threshold (e.g., 2-3) on production sites to avoid banning legitimate users who might accidentally trigger a pattern
  • Add your office IP ranges, CDN IPs, and monitoring service IPs to the whitelist before enabling the module
  • Monitor your site's Recent log messages regularly to see which IPs are being banned and adjust patterns accordingly
  • Use the default patterns as a starting point and add site-specific patterns based on your log analysis
  • The module is most effective against automated scanners; sophisticated attackers may use IP rotation
  • Consider combining with other security modules like Honeypot, Antibot, and CAPTCHA for comprehensive protection

Technical Details

Admin Pages 1
Perimeter defence settings /admin/config/system/perimeter

Configure the URL patterns that trigger IP bans, manage IP whitelists, and set flood protection thresholds for the Perimeter Defence module.

Permissions 3
Bypass Perimeter Defence ban rules

Allow users with this permission to access URLs matching banned patterns without being banned. Useful for administrators or trusted users who may need to access these URLs for legitimate purposes. This permission has restricted access.

Administer perimeter disallowed url patterns

Allows the user to define and modify URL banning patterns on the Perimeter settings page. Users with this permission can add, edit, or remove regex patterns that trigger IP bans.

Administer perimeter IP whitelist

Allows the user to manage the IP whitelist on the Perimeter settings page. Users with this permission can add or remove IP addresses and IP ranges that are excluded from being banned.

Hooks 2
hook_honeypot_reject

Integration hook with the Honeypot module. When Honeypot rejects a form submission due to time-based protection (honeypot_time type), this hook bans the submitting IP. Excludes user login forms and UID 1 from banning to prevent accidental lockouts.

hook_help

Provides help text for the module on the Help page, explaining the module's purpose and linking to documentation.

Troubleshooting 5
I accidentally banned my own IP while testing

You cannot access the Drupal admin interface to unban yourself. Use Drush to remove your IP from the database: drush sql:query "DELETE FROM ban_ip WHERE ip='YOUR.IP.ADDRESS';" Alternatively, access your database directly via phpMyAdmin or command line and delete your IP from the ban_ip table.

Legitimate users are being banned

Add their IP addresses or IP ranges to the whitelist in the Perimeter settings. You can also increase the flood threshold to allow a few accidental matches before banning. Consider reviewing your URL patterns to ensure they aren't matching legitimate URLs.

The module isn't banning any IPs

Verify the module is enabled and the ban module is functioning. Check that your URL patterns are valid regex (including delimiters like /pattern/). Cached pages won't trigger bans, so ensure you're testing with uncached requests. Check the Recent log messages for any Perimeter notices.

Users with bypass permission are still being banned

Ensure the user is logged in when accessing the banned URLs. The bypass permission only works for authenticated sessions. Anonymous users cannot have bypass permissions.

Flood threshold doesn't seem to work correctly

Remember that cached page requests don't trigger the ban logic. When testing flood threshold, you must request different URLs each time (e.g., /wp-admin/a, /wp-admin/b, /wp-admin/c). Repeated requests to the same URL may be served from cache and won't increment the flood counter.

Security Notes 6
  • The bypass permission is marked as 'restrict access' - only grant it to highly trusted roles
  • Never grant 'administer perimeter url patterns' or 'administer perimeter ip whitelist' permissions to untrusted users as they could disable protection
  • The module logs detailed information about banned IPs including referrer and user agent - review logs regularly for attack patterns
  • IP bans are stored in the database and persist until manually removed via the Ban module interface or database
  • When using behind a proxy or CDN, ensure Drupal is configured to detect the correct client IP (trusted_host_patterns and proxy settings)
  • The module protects against reconnaissance and automated attacks but should be part of a comprehensive security strategy including regular updates, strong passwords, and proper server configuration