So now I'm pretty sure I've solved the issue. Turns out it was user error (mine).
See, as I wrote in my previous post, I run the phpbb forum within a docker container. This is behind an nginx reverse proxy. So traffic goes like this:
Code: Select all
Client ---> Reverse proxy ---> docker(phpBB)
instead of the expected:
phpBB expects the latter, and reports the client IP with this line of code in the session.php file:
Code: Select all
$ip = html_entity_decode($request->server('REMOTE_ADDR'), ENT_COMPAT);
But when sitting behind a reverse proxy (like in our case), REMOTE_ADDR points to the reverse proxy IP, not the actual client IP, and that one is on the private network docker creates... So, every time I upgrade phpBB, I have to change that line to replace 'REMOTE_ADDR' with 'HTTP_X_REAL_IP', which together with the nginx configuration:
Code: Select all
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Frame-Options SAMEORIGIN;
points to the actual client IP.
I was so certain that after the upgrade I had applied that change that I didn't even check. Well, I hadn't.
So, what happened was that when a spammer tried to register, using an IP that is in the SFS database, the plugin saw the actual IP and banned it, but phpbb applied the ban on the REMOTE_ADDR that was the 172.19.0.1 private IP.
At least I think that is what happened. I will be 100% sure when another bot tries to register.
Sorry for the inconvenience everyone.
