Ideal 404 Detection Settings in Defender Pro Plugin

Site Context and Challenges

The staff.telkomuniversity.ac.id site is a WordPress Multisite with many dynamic subdomains and subdirectories. Daily traffic is around 300 active visitors. There is a history of attacks by bots that scan by trying to access pages from other CMSs (Joomla, Drupal, Laravel) that are not on this site, resulting in many 404 page requests. Because the site is publicly accessible, security settings must achieve several goals simultaneously:

(a) preventing server overload due to a surge of 404 requests from bots,

(b) avoiding false positives that block normal human visitors who occasionally mistype a URL, and

(c) reducing the potential for brute-force scanning of the available multisite subdomains.

404 Threshold and Block Duration

For the 404 Detection feature in Defender Pro, it is recommended to set a threshold of around 20 404 errors in 300 seconds (5 minutes) before an IP is considered suspicious for wpmudev.com . This means that if an IP address makes 20 requests to non-existent pages within a 5-minute span, Defender will temporarily lock out that IP for wpmudev.com . This 20/300-second threshold recommendation is based on the differences in patterns between normal visitors and bots. A typical human user will generally experience very few 404 errors – it is almost impossible to achieve dozens of 404s in a short period of time for really-simple-ssl.com . In contrast, bots or automated scanners tend to cause a surge of 404s when they scan the site (by trying many random, non-existent URLs) for really-simple-ssl.com . With a threshold of ~20/5 minutes, aggressive bots will be detected and stopped after exceeding this threshold, while a normal user who might stray to 1-2 non-existent pages will not be immediately locked out.

For IP blocking duration (lockout duration) , the recommended time is around 300 seconds (5 minutes) per violation of the wpmudev.com threshold . This means, when an IP passes the threshold of 20 404 errors in 5 minutes, the IP is blocked for 5 minutes from accessing the site. A 5-minute span is considered sufficient to stop bot activity so that it does not continuously flood the server, but not so long that even if a regular user is blocked by mistake, they can access it again relatively quickly. If the same IP repeatedly violates (for example, bots continue scanning after the block period has expired), the admin can consider extending the block duration (for example, to 1-2 hours) or permanently banning the IP. However, as a starting setting, 20 hits/5 minutes with a 5-minute block is an ideal and balanced configuration according to the wpmudev.com WPMU/Defender guide .

Avoiding False Positives (Legitimate Users Blocked)

To prevent human users from being mistakenly blocked, please take the following steps:

• Disable 404 monitoring for logged-in users. In Defender Pro, uncheck the “Monitor 404s from logged-in users” option . This prevents logged-in users (e.g., admins or staff) from being locked out simply by accessing a page that happens to 404 on wpmudev.com . This is important to prevent admins/staff from being blocked from navigating the dashboard or internal pages that may not be available yet.
• Use Allowlists for frequently 404ed URLs/files. Defender offers an Allowlist feature to exclude certain paths from the 404 count. Add URL paths or file types known to be frequently requested but not present on your site to the Allowlist to prevent those attempts from counting against wpmudev.com’s 404 threshold . For example, if an image/logo is missing or an old page has been removed but still has external links, add the URL to the Allowlist. This way, regular visitors won’t be locked out just because they access a popular outdated link to wpmudev.com . (Conversely, you can also use the Blocklist to immediately block access to a specific sensitive path – say, “wp-config.php” – if a bot tries to access it.)
• Set the threshold moderately. Avoid setting the 404 threshold too tight (e.g., <10 hits) in a short period, as this increases the risk of false positives . A threshold of 20/300 seconds is considered safe enough – a normal user is unlikely to encounter dozens of 404 hits in a short period of time without the intention of playing around with really-simple-ssl.com – so most of what gets blocked is actually bot behavior. With sufficient margin, we ensure that only activity that truly resembles bots is locked out.
• Fix broken links on your site. As a proactive measure, conduct an audit for broken links or missing file references on your site (e.g., using Google Search Console or the Broken Link Checker plugin ). The fewer broken links, the less likely it is that regular users will encounter a 404 page. This reduces the likelihood of legitimate visitors being hit by the 404 detection rule. Any expired external links can be redirected or disavowed as needed to prevent traffic from being redirected to the 404 page.
• Monitor the 404 log and adjust as needed. Regularly review the IP Lockout Log in Defender. From there, admins can see which IPs are being blocked and why. If you find that a legitimate user’s IP (e.g., a university IP or a valid search engine crawler) is frequently blocked, you can take action: add that IP to Defender’s Allowlist or slightly increase the threshold. Conversely, if an unfamiliar IP repeatedly appears in scans and is blocked repeatedly, consider permanently banning that IP. This monitoring and adjustment ensures that the 404 Detection configuration remains effective at catching bots but flexible for real users.

Additional Security Recommendations

In addition to the above settings, consider the following additional steps to improve site security:

• Enable an external firewall/WAF: Adding a firewall layer outside of WordPress can be very helpful. For example, use Cloudflare WAF (Web Application Firewall) on your site’s domain. Cloudflare’s service (even the free plan) can block many common attacks before they reach your server, including filtering bots that trigger 404 spikes. One community suggestion is to use Cloudflare or Wordfence as a WAF to block or challenge suspicious traffic to reddit.com . You can apply specific rules, such as blocking access from countries that are not relevant to your site or implementing Cloudflare’s Managed Challenge (asking visitors to solve a CAPTCHA/puzzle if they are detected as bots) to reddit.com . With an external WAF, the bot attack load can be contained at the CDN level, preventing it from overwhelming the underlying server.
• Implement rate limiting : If possible, use a rate limiting mechanism to prevent a single IP from making too many requests in a short period of time. Cloudflare has a rate limiting feature that can throttle IPs that send a barrage of requests to reddit.com . On the server side, you might consider configuring modules like mod_evasive or fail2ban (if using a VPS) to detect excessive 404 patterns and block those IPs in the server firewall. Rate limiting will protect your site from brute-force crawling by limiting the bot’s request rate.
• Use CAPTCHA/challenges for suspicious traffic: To prevent bots from gaining access, implement CAPTCHA challenges at critical points. For example, install a CAPTCHA plugin on login pages or important forms to ensure only humans can access your site. If you’re using Cloudflare, take advantage of the Managed Challenge feature , which will present a challenge (like a CAPTCHA) when a suspicious access pattern is detected on reddit.com . This gives legitimate users a chance to pass verification, while bots are more likely to be stopped. This is especially useful if you’re worried about real visitors being blocked—they can “prove themselves” with a CAPTCHA instead of being immediately denied access.
• Secure your login page (brute force protection & 2FA): Ensure the Login Protection Defender module is enabled to limit login attempts (e.g., block an IP after 5 failed logins within 5 minutes). Also, enable Two-Factor Authentication (2FA) for admins/critical users, so logins require extra verification. Furthermore, consider changing the default login URL with Login Masking Defender Pro. With the changed login URL, any bot access to wpmudev.com will result in a 404 and be immediately captured by the wpmudev.comwp-login.php 404 Detection system . These steps eliminate the opportunity for bots to brute force your multisite login page.
• Use Defender’s advanced anti-bot modules: Take advantage of Defender Pro features like User Agent Banning and Malicious Bot Detector . User Agent Banning lets you block bots with specific user agents (Defender provides a preset list of bad bots —like scanners and spam crawlers—that can be blocked with a single click). Meanwhile, the Malicious Bot Detector module adds a honeypot trap in the form of an invisible link on every public page. Malicious bots that ignore the rules robots.txtwill follow this hidden link and immediately trigger the trap—Defender automatically blocks the IP address (temporarily for 300 seconds or permanently, depending on settings) wpmudev.com . This feature effectively stops crawler bots from roaming around looking for vulnerabilities on your site.

By implementing the above configuration, your WordPress Multisite site will have multiple layers of protection. Properly setting the 404 threshold prevents bots from causing overload without disrupting regular users, and additional measures like firewalls, rate-limiting, CAPTCHAs, and other Defender Pro features will further reduce the chances of bots brute-force scanning subdomains or other exploits. All of these measures reduce the burden of 404 attacks while minimizing the risk of false positives for regular visitors, in line with the desired security goals.

Source

Threshold and duration recommendations from WPMU/Defender wpmudev.com , Defender Pro documentation wpmudev.com , and advice from the reddit.com web security community/experts . Hopefully, this is helpful and can be implemented effectively.