Comment on fail2ban behind reverse proxy (nom)
irotsoma@piefed.blahaj.zone 4 days ago
Based on a quick read it sounds like the issue will be that the bad actors won’t get dropped immediately. Meaning whatever servers and services are in front of the firewall that fail2ban configures, will still receive the performance hits. But your backend services will still be protected.
I have a server specifically set up as the ingress server. That runs fail2ban and Traefik and I have crowdsec set up with a Traefik bouncer plugin. So fail2ban runs in front of everything to catch the worst, most obviously bad stuff and drop the traffic very quickly and efficiently so it doesn’t get any further including things trying to access services other than the web services. Then crowdsec is focused on more complex threats as they flow through the reverse proxy. Seems to work the most efficiently for me, but I haven’t had a chance tondo any real analysis on how much improvement it might be over any other configuration.
nibbs@lemmy.zip 4 days ago
Thanks for bringing it up.
Before I dove into that project, I was checking logs on npm and the service I am already exposing. It seems to me, both only get http GET requests which on npm all get a 404 response.
I don’t remember what the service does with those, but I will investigate later. As I didn’t panicked, I guess it wasn’t that bad.
There are basically no brute force attacks on the service yet and the admin account is only allowed to login from internal IPs.
One initial aspect to further harden the exposed systems were the logs in the UDM which show frequent blocked attempts of varying severity.
This may be security theater and I am not able to assess whether the UDM is a “good enough” protection of the most common attacks.
As I see it, at the moment the UDM already blocks most of the (more sophisticated) attacks and leaves only common requests for the services to handle.
Long story short, as I see it, the UDM has the role of ingress server in my setup.