Brute force IP blocking

[D4nK4liLnx]

Hi everyone,
i was looking at the Docker logs for the "opencloud-compose-opencloud-1" container in "/var/lib/docker/containers/id_container". When the login fails, i don't see the public IP, but "127.0.0.1:48400". I get a 203 status with the public IP in the next log, which doesn't indicate a login failure.
This is what it returns:

{"level":"error","service":"idm","bind_dn":"uid=admin,ou=users,o=libregraph-idm","op":"bind","remote_addr":"127.0.0.1:48400","time":"2026-01-31T19:54:58Z","line":"github.com/opencloud-eu/opencloud/pkg/log/logrus_wrapper.go:50","message":"invalid credentials"}
{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"r8uygt5rfd6t7/GHYRfgtDrgg-000001","traceid":"6743er6789iuygh654eds3456tgthh34","remote-addr":"pubblic_ip","method":"POST","status":204,"path":"/signin/v1/identifier/_/logon","duration":194.163855,"bytes":0,"time":"2026-01-31T19:54:58Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

I'm analyzing the logs because i want to implement "CrowdSec" to block IPs that attempt to brute-force logins.

Is there a more accurate way to identify failed logins? Or is what i'm analyzing ok?

Thanks

[D4nK4liLnx]

Hi everyone,
i could see the public IP because i didn't have nftables enabled. Now that nftables is enabled, i see the Docker network IP 178.18.0.1.

I didn't find anything in the documentation about passing public IP information during the request. Or maybe i just didn't see it.

Is there a way to pass the public IP into OpenCloud logs?

Thanks

[micbar]

The reverse proxy need to forward the IP

[D4nK4liLnx]

Hi,
the log you see is from the OpenCloud container.
The remote-addr is the Docker virtual interface.

{"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"ec81144372c7/LJeY7kYJtA-000651","traceid":"42b65e5f291335b28f8fe0edf2b76645","remote-addr":"172.18.0.1","method":"POST","status":200,"path":"/signin/v1/identifier/_/hello","duration":6.980521,"bytes":137,"time":"2026-02-04T11:46:41Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

Thanks

[micbar]

Did you configure the reverse proxy to forward the ip address

[D4nK4liLnx]

There is the OwnCloud stack, traefik, collabora, owncloud and collaboration.

If i stop nftables, docker compose down, docker compose up -d the public IP is in the logs.

[micbar]

@flimmy Could you help?

[D4nK4liLnx]

Thanks @micbar and @flimmy for your help!

[flimmy]

Since nftables seems to be the culprit here, i would need to see your nftables config, but as an educated guess: this looks like an issue with Container routing. Docker networking is based on iptables chains. So anything messing with network traffic after going through the docker iptables chains will break something.
In this case traefik doesnt see the real ip anymore since some kind of NAT or masquerading seems to happen.

Please have a look into docker and nftables interoperability.
If only changes to traefiks config are needed the compose setup already has a place where you could put it. If you need help with that we can of course help out there.

[D4nK4liLnx]

Thanks for the reply @flimmy
I think the problem is nftables with Docker networking on iptables.
I created a VM with Debian and KDE to test locally, and the behavior is the same without configuring anything, just enabling nftable.

Tell me what you need and I'll send you the files you need. Or tell me what i need to configure in the .env file.

I tried OpenCloud locally on a VM, the behavior is the same (cloud.opencloud.test).
I'm attaching a text file with some information about the VM i configured.
VM_TEST.txt

Thank you

[kapuett]

nftables has limitted docker support. Check out https://docs.docker.com/engine/network/firewall-nftables/. Easiest would be to just use iptables instead. Yes, nftables is going to replace iptables at some point but I don't think that is in the near future. iptables won't leave the kernel soon.

[D4nK4liLnx]

Hi,
i read this link.

I would like to understand if it is possible to solve the problem.

It's a production server, with WireGuard and other services installed. If this doesn't work, I'll rewrite all the rules in iptables.
I'll cry, it's much easier to create complex rules in nftables than in iptables.

Thanks for the reply.

[kapuett]

So you configure docker daemon to start with nftables and checked no rules need migrating from iptables? You can verify with what docker runs with (sudo) docker info | grep -i "firewall".
Apart from that, the way I understand CrowdSec is that first thing you'd feed it is the traefik logs, not the application logs. That will likely filter 98% of the bots. But to ban them, you still need the real IP, so you need to figure that out anyways.

[D4nK4liLnx]

Docker's firewall is iptables.

As soon as i start CrowdSec, it inserts the rules into nftables with the IPs already blocked.

The only problem is that i can't capture the public IP of the request when the username and password are entered because the IP is changed to the Docker network IP. I've already implemented the CrowdSec configuration, i can analyze the container's real-time log, I've set both the number of retries and the blocking time, and it works.

However, i need to disable what i did with CrowdSec.

[kapuett]

Except you 100% know what you are doing, you should not run iptables and nftables in parallel. They have different netfilter hook prios in the kernel, leading to packets getting dropped/forwarded in one system or the other. Makes following packets a nightmare. Use either or, but not both.
Traefik by default forwards real IP. Something is messing with your routing, as @flimmy also mentioned.

[D4nK4liLnx]

I noticed that both nftables and iptables are installed on the two test VMs (one public and one private, which i only use for testing), which are not in production. The production server only has nftables.

I'm starting to suspect that when i installed Docker, it also installed iptables, and i didn't notice. Debian uses nftables by default.

I'll restore one of the two VMs to a clean state and check more carefully.

[D4nK4liLnx]

When i install Docker, following the official guide, it also installs iptables. I hadn't noticed that.

I have to replace nftables with iptables and rewrite all the rules... I'm crying!

Many thanks to all

[micbar]

I think docker has a hard dependency on iptables, but be careful, it overrides your rules. When you expose a port in docker, it can be reachable via the public network because in some point, it overrides your iptables.

[D4nK4liLnx]

Yes, Docker overrides the rules i wrote. I created a second publicly exposed VM using only Docker and OpenCloud, opening firewall ports 80 and 443. Everything works.

Thanks everyone.