Re: [SSHGuard-users] Blocked attackers can still access docker containers

[Christopher E. <ce...@lc...>]

Hi,
my guess would be that the problem lies with dockers bridge network
setup (caveat, I am in no way an expert on either containers or networking).

If I read those nftables rules correctly, then:

- chain PREROUTING checks if the package is destined for an ip assigned
to a local interface (yes), and if so, counts it and sends it to the
DOCKER chain
- chain DOCKER,
  a) if that local interface was docker0 (probably no?), resets the
counter and returns or,
  b) if it was destined for HOSTIP:2022 (that's us), resets the counter
and NATs the package to 172.17.0.3:22

So apart from the added complexity which I assume has something to do
with how Docker does networking, this is just basic NAT - anything that
is send to HOSTIP:2022 gets forwarded to 172.17.0.3:22, which is the IP
of the docker0 bridge device, correct?

If so, then chains assigned to the input hook, i.e. INPUT & blacklist
are not called [1][2] on the host, the packet goes prerouting -> forward
-> postrouting, not prerouting -> input.

You could try:
1) changing the blacklist chain to 'hook prerouting' instead of 'hook
input', with a higher priority than that of chain PREROURTING, i.e.
block the traffic before it even reaches the NAT chain. This should make
sshguard block both container- and host-destined traffic.
2) changing it to 'hook forward', i.e. catch the traffic on its new path
after the docker chains (this will effectively disable sshguard for the
host machine)
3) running sshguard inside the container, kinda not the point of
containers ....

(1) is probably the best bet, but it depends on what else your host is
doing, network-wise.

Hope this helps, somewhat
Christopher
[1] https://people.netfilter.org/pablo/docs/login.pdf
[2]
https://netdevconf.info/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf