local lan blocking / one way communication

[mrpops2ko]

hi im wondering if this kind of update would be something you would be interested in

so to provide an example, lets assume you have created a docker network called traefik-public and done the whole preventative container communcation for security etc

those containers because they are on the bridge docker network driver, are capable of pinging outwards - so if you have a remote desktop, or other devices in the lan then the containers are fully capable of communicating with them and under the scenario of an attacker gaining control of one of those containers they then have access to whatever resources are on your local network.

I was thinking some kind of additional variables that define what your docker host and subnet are like; DOCKER_HOST=192.168.1.2 LAN_SCOPE=192.168.1.1/24

i think we'd need to know the docker host because we cant block that, or else the containers won't be able to communicate outwards at all and then for the lan scope it'd maybe be something like iptables -I DOCKER-USER -s 192.168.1.1/24 -d 172.17.0.0/16 -j ACCEPT iptables -I DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -I DOCKER-USER -s 172.17.0.0/16 -d 192.168.1.1/24 -j DROP

im no good with iptables im just thinking out loud, im not even sure if thats how the networking would be because its internal docker NAT so it'd be the location of the docker host wouldn't it?

i guess another solution for this outside of the scope of trafficjam would be to slap a vlan tag on this and then centrally manage it at the firewall level instead with appropriate connectivity rules

[kaysond]

@mrpops2ko - just to clarify, you want to block the containers from accessing addresses on the specified LAN subnet, right? All containers? or just the ones on the trafficjammed network?

FYI - the bridge network is just a default network the docker daemon creates on startup. If you specify networks for a container to attach to, they won't join bridge. That is, it's not the bridge network that allows containers to access outside ip addresses; that access is allowed just by default linux kernel routing / iptables.

I'm definitely open to adding the functionality. You could even block access to the internet, if you wanted. There might also be a more elegant way to block LAN access without requiring env vars to define the docker host IP and LAN subnet... I'll have to think about this.

[mrpops2ko]

yep thats right, but i think it would be best if this was integrated by doing it in the trafficjammed network because it lets others maintain the functionality otherwise if they desire it

im not talking about the default bridge network but any custom network, so for example if you do a docker network create test-network that will also have the ability to ping your lan, and docker compose if you create custom defined networks, will also do similarly

like you said, it is just by default linux kernel routing that allows this

i don't think we need to block access to the internet, because docker already does a good job of this if you create a network using the --internal flag, so docker network create --internal my-isolated-network will create a network that is inaccessible to the internet, we could advertise that more on the front page though so others know this

[kaysond]

Have you tried using --internal? I'd never heard of that option before, but from the explanation in the documentation, it seems that it should also block access to the LAN... (but maybe not the docker host?).

https://docs.docker.com/reference/cli/docker/network/create/#internal

[mrpops2ko]

yep it does what it says on the tin, but that wouldn't work for us / most people because they ultimately do want external internet connectivity

its just like how com.docker.network.bridge.disable_icc would let us accomplish what trafficjam does but its not as good as trafficjam because we ultimately desire a means of getting traffic out (through reverse proxy) and that flag wouldn't let us

19 = desktop 2 = proxmox host 3 = docker host

docker network create --internal blockedLAN 5c1b5c6e9d1f blockedLAN bridge local

PING 192.168.1.19 (192.168.1.19): 56 data bytes
^C
--- 192.168.1.19 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
root@7928729fe107:/# ping google.com
ping: bad address 'google.com'
root@7928729fe107:/# ^C

root@7928729fe107:/# traceroute google.com
traceroute: bad address 'google.com'
root@7928729fe107:/# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
^C
--- 192.168.1.2 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
root@7928729fe107:/# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3): 56 data bytes
64 bytes from 192.168.1.3: seq=0 ttl=64 time=0.038 ms
64 bytes from 192.168.1.3: seq=1 ttl=64 time=0.050 ms
64 bytes from 192.168.1.3: seq=2 ttl=64 time=0.036 ms
64 bytes from 192.168.1.3: seq=3 ttl=64 time=0.043 ms
^C
--- 192.168.1.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.036/0.041/0.050 ms```

[kaysond]

Got it. Let me play around with this and I'll see what I can come up with.