Feature Request - Podman Networks as a DMZ

[Nitrousoxide]

Feature request description

Podman networks already contain all the levers needed to make a DMZ. It creates a separate subnet from the host's LAN and it has an IP routing table to translate this subnet to be able to communicate with the host's LAN, it can filter IP ranges from access, and it can define DNS servers for the container's networking. A Podman network which is acting as a DMZ could allow outbound access to the internet while putting the container on a separate subnet and filtering out any communication with local IP ranges other than the subnet of the Podman Network. This allows an admin to create a set of containers and networks with a reverse proxy to isolate the container from the LAN providing additional security for the host and limiting a compromised container's access to the rest of the network.

Such a setup would look like:
(Container) <-> (DMZ Podman Network) <-> (Reverse Proxy) <-> Normal Podman Network with access to the internet and the LAN.

Suggest potential solution

I'm not sure what the best implementation of this would be. Whether it's something like the existing --internal flag or a separate network mode. A DMZ network would probably need to have a DNS server defined since it's likely that admin for the server will have an internal DNS server for the LAN if they are doing any domain name resolution locally. And such a local DNS server would not be reachable by a DMZ network.

Have you considered any alternatives?

I'm not aware of any way to configure a Podman network currently to act as a DMZ, even though all the tools needed are there.

Additional context

No response

[Luap99]

I don't see how you could define a DMZ in such setup, at least not in what I consider to be an actual DMZ. A DMZ should be put in front of the LAN not behind it.

How would podman know what connections to block? Do you just want to block all private addresses as defined in RFC1918?
This may be good enough for most but it would only work for ipv4 and it would not be possible to do something like this with ipv6.

[Nitrousoxide]

I don't see how you could define a DMZ in such setup, at least not in what I consider to be an actual DMZ. A DMZ should be put in front of the LAN not behind it.

It might not be a "true" DMZ in the sense that the LAN's router is preventing the traffic from getting anywhere inside the regular network in the first place. But the IP tables of Podman would be routing internet traffic directly to the podman network rather than anywhere else. You could rename it if you're concerned it doesn't offer quite the same security as a router based DMZ but it would have the same security as someone doing IP table based routing sequesterization on the host. Which is a valid security strategy. And since podman could handle all that IP table routing automatically it would simplify that approach and put it in reach of a lot more users.

How would podman know what connections to block? Do you just want to block all private addresses as defined in RFC1918? This may be good enough for most but it would only work for ipv4 and it would not be possible to do something like this with ipv6.

Wouldn't fc00::/7 be for private networks under IPv6?
https://datatracker.ietf.org/doc/html/rfc4193

And yeah for IPv4 you could block the ranges defined by RFC1918 (except the subnet for the docker network itself, so the container can communicate with other containers attached to it)

[Luap99]

Well yes there is a private ipv6 range but the way ipv6 generally works is that each host has a global routable ipv6 so we cannot really block it there.

I am not sure I really want to implement such a feature, at least not right now. Besides the ipv6 issue we currently only use the iptables backend in netavark,. However we still have plans to move to firewalld and/or nftables directly which means we need to implement it there as well.

Also given that firewalld still flushes all our rules on reload it means that critical rules can be dropped and thus allow local access until podman network reload or the cotnainers are restarted. Of course such a reload would also drop the NAT rules so it is unlikely that traffic will routed correctly but it is certainly not impossible to bypass that.

---

Thinking about this more I wonder if the vfr[1] feature (containers/netavark#815) could be used instead, with that a user can create routing rules specific to the bridge interface.

Then you could just add a route in the vrf table to block all traffic to that subnet, e.g.: ip route add blackhole 192.168.0.0/24
I haven't tested vrf yet but assuming that works I like this much better as it would be independent of firewall changes.

[1] https://docs.kernel.org/networking/vrf.html

[Nitrousoxide]

That might work. Maybe a documentation update for podman-network-create on how to blackhole local ranges? The user should know what subnets and ranges to which the host has access.

[Luap99]

Actually I am not sure that we can do this just via routing, AFAIK we still we would need a route for the default gateway so someone could access you router ip with that.
With firewall rules we can block based on the dest ip so that should prevent someone from accessing the router (at least on its internal ip).

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@Luap99 Is this till valid and active?

[Luap99]

yes

[github-actions]

A friendly reminder that this issue had no activity for 30 days.