trust_real_ip only sets host, not IP.

[ghost]

When using a reverse proxy, such as Apache with mod_proxy or nginx and setting trust_real_ip=1 in miniserv.conf, $acptip is not set. Only $acpthost and $loghost get set to reflect whatever X-Forwarded-For or X-Real-IP is.

Therefore when an incorrect username/password is supplied, the "block host" is incremented against the IP that the front-end server is proxying to. For example if the front-end server is proxying to https://localhost:20000, the bad login is seen to come from 127.0.0.1 even though trust_real_ip=1 in miniserv.conf.

In this scenario someone can effectively DoS the service by trying an incorrect username/password combination which will eventually block 127.0.0.1, which will prevent anyone from logging in since requests will always come from 127.0.0.1 due to the reverse proxying being used.

The fix is to correctly set $acptip along with $acpthost and $loghost:

If a remote IP is given in a header (such as via a proxy), only use it

for logging unless trust_real_ip is set

local $headerhost = $header{'x-forwarded-for'} ||
$header{'x-real-ip'};
if ($config{'trust_real_ip'}) {
$acptip = $headerhost || $acptip; # <-- Set IP too
$acpthost = $headerhost || $acpthost;
$loghost = $acpthost;
}
else {
$loghost = $headerhost || $loghost;
}

[ghost]

btw, not setting $acptip when trust_real_ip=1 also causes PAM authentication messages to syslog to use 127.0.0.1 (or whatever the reverse proxy is proxying to). This makes it impossible to use things like fail2ban.

[jcameron]

Good point - this will be fixed in the next Webmin release.