This might be an edge case but it’s still a bug. In some circumstances it might be possible to abuse this bug to avoid blocklisting, for example when the Cloudflare add-on is used for blocking requests.
When the “My site is behind a reverse proxy” (input name cerber-main[proxy]) option is enabled, direct requests (not via reverse proxy, like Cloudflare) lead to Cerber using an invalid IP address 0.0.0.0 for logging and probably blocking, and reporting to the Cerber Hub.
I haven’t looked at the Cerber code that determines real client address from request headers but there’s something clearly wrong with it.
I had to turn the proxy option off since I’m using the Apache mod_remoteip and it’s configured with IP ranges fetched from Cloudflare and refreshed daily. So the PHP $_SERVER['REMOTE_ADDR'] variable is set from the Cloudflare specific request header CF-Connecting-IP and only if a request comes from Cloudflare IPv4/IPv6 ranges.
Let me know if you need more info to repro and fix this issue.
First of all, WP Cerber users don’t need to enable this setting if their website isn’t behind a reverse proxy. Enabling it without a proxy can lead to WP Cerber being misconfigured. This feature is designed for cases when WP Cerber cannot retrieve IP addresses from standard HTTP request fields and must rely on HTTP headers set by a proxy. That’s why configuring proper IP detection is covered as the very first step in our getting started guide [https://wpcerber.com/getting-started/].
Regarding your specific setup: When the “My site is behind a reverse proxy” setting is enabled, WP Cerber expects to see HTTP headers provided by the Cloudflare proxy to determine the real client IP address. In environments using Cloudflare with Apache mod_remoteip, where $_SERVER['REMOTE_ADDR'] is adjusted based on the CF-Connecting-IP header, if Apache removes or does not pass along the Cloudflare headers, WP Cerber will naturally log 0.0.0.0 as it lacks the necessary IP data to accurately identify the client. This means, for or your specific setup, you need to disable this setting [https://wpcerber.com/wordpress-ip-address-detection/].
Configuring a security plugin like WP Cerber requires careful consideration of each setting. Depending on a server setup, WP Cerber may require a clear understanding of the environment in which it operates. To ensure your site’s security, please take the time to understand the purpose and impact of each setting. WP Cerber’s documentation is designed to guide you in making informed choices that best suit your configuration and security needs: https://wpcerber.com/toc/
P.S. Hopefully, my explanations clarifies why this isn’t considered a bug.
Wouldn’t the $_SERVER['REMOTE_ADDR'] be a saner fallback rather than using an invalid value 0.0.0.0 in cases when the option is misconfigured?
In my case, I had migrated the site to a new server with Apache mod_remoteip already configured but realised the issue only days later when I was looking at Cerber activity logs.
Cerber should fall back to $_SERVER['REMOTE_ADDR'] when it can’t detect the correct request headers. Or alternatively it could disable the option entirely but that could lead to issues when a site is simultaneously accessible via reverse proxy and directly.
You’re absolutely right; it makes perfect sense to implement both of these enhancements. Falling back to $_SERVER['REMOTE_ADDR'], if it contains a correct IP address, instead of logging 0.0.0.0 would definitely help prevent confusion if the setting is misconfigured, especially in cases like yours where the environment changed but the configuration didn’t immediately catch up.
Automatically disabling the setting when the proxy headers containing an IP address aren’t detected is a reasonable approach as well. While it could have some edge cases with mixed traffic sources, it might still be more fail-safe for most setups
You can expect to see these improvements in an upcoming version of WP Cerber.
Great to get a response from someone who gets it. Not that Nick’s response was unhelpful but it rustled my jimmies a bit because it reads like “wontfix – PEBCAK”.
Would it be appropriate to point out some code quality issues I’ve noticed in the WP Cerber codebase while troubleshooting some minor inconveniences? Or should I open another topic?
Glad to hear the response helped, and I totally get what you’re saying. Nick’s answer might’ve come off a bit straightforward, but his intention was to clarify that currently certain checks still fall on the user’s side.
Please go ahead and open another topic in the Feedback category. WP Cerber was first released 9 years ago, so there’s some legacy code in the plugin, and parts of it have become outdated and should be improved and refactored.
It’s worth noting that WP Cerber currently doesn’t allow enabling the ‘My site is behind a reverse proxy’ setting if no proxy headers containing valid IP addresses are detected. If you attempt to save the settings, the following message will appear.
