Avoid trusting local networks

[brightbyte]

Hi! ufw-docker makes the assumption that "private networks are more trusted than public networks". I think that is not a safe assumption to make. If you are, like me, running docker on your laptop, the local network includes anyone on your train, your hotel, or at your conference.

So instead of allowing traffic to docker containers based on IP addresses, it seems much safer to do so based on interface names. Allow traffic for the docker* and br-* devices allows containers to communicate, but does not allow traffic from the local subnet, unless allowed via ufw.

I think that's what people would generally expect/want. I made a very simple proof of concept: https://github.com/brightbyte/docker-fw. Works great for me.

[chaifeng]

Do you mean this?

Using the --docker-subnets option

You can use the --docker-subnets option to customize which subnets will be allowed to communicate with Docker containers. This option applies to both IPv4 and IPv6 networks.

• If the option is not provided, only standard private LAN subnets will be used (IPv4: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16; IPv6: fd00::/8)
• If --docker-subnets is given without any arguments, all Docker network subnets will be detected and used automatically. Note: If you add or remove Docker networks, you need to run ufw-docker install --docker-subnets again to update the firewall rules according to the latest network configuration.
• If one or more subnets are specified, only these subnets will be used (you can list multiple subnets, separated by spaces; each should be in CIDR format). The subnets can include networks not managed by Docker itself.

[brightbyte]

I suppose the purpose is the same... In the end, the question is how do we determine which traffic comes from (or goes to) docker. It seems easier and safer to do this based on the device name instead of the address. For example, docker-compose will add networks dynamically. A rule based on a device name prefix will Just Work, no need to re-run any scripts or detect address ranges. This has the added benefit that traffic from local networks will not be allowed to access your docker containers, no matter what address the local network uses (which changes frequently when you log into a new wifi network).

[Vitus-TL]

When managing firewalls it's common to block BOGON's ( https://team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt ) coming in from the public interface (e.g. 172.16.0.0/12 ) to prevent IP-spoofing and misuse of local firewall rules. I second brightbyte not to not blindly allow access to common docker subnets like the above. Limiting it to the interfaces br* and docker* will solve this problem though.

[brightbyte]

Point in case, the wifi on German trains uses the 172.17.0.0/16 and 172.18.0.0/16 subnets (Compare https://gist.github.com/sunsided/7840e89ff4e11b64a2d7503fafa0290c). So if I work on a train, I'd have to trust traffic from anyone else on these trains.