robots.org.uk: FirewalldZones

firewalld ships with a set of predefined zones. I find it helpful to group them together when thinking about them as follows.

The end-user zones

An end-user system like a laptop or workstation would use these zones. public is the default default zone.

home

For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

public

For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

work

For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

The router zones

dmz

For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted.

external

For use on external networks. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

internal

For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.

You'd use these if you were configuring a simple internet gateway. external is the only zone that has masquerading enabled by default, it seems you'd put your internet-attached interface in this zone.

The utility zones

block

Unsolicited incoming network packets are rejected. Incoming packets that are related to outgoing network connections are accepted. Outgoing network connections are allowed.

drop

Unsolicited incoming network packets are dropped. Incoming packets that are related to outgoing network connections are accepted. Outgoing network connections are allowed.

trusted

All network connections are accepted.

I guess you'd use block and drop for temporary purposes, like if you needed to hook up to a machine that might have been compromised for instance. Or I suppose you could set one of them to be the default zone for interfaces/connections that don't otherwise have a zone.

trusted is a good place to put your internal bridges that your virtual machines or containers are attached to, assuming you're running stuff in them that you... trust. It's the only zone with a target of ACCEPT, which causes its packets to be accepted while traversing the FORWARD_IN_ZONES chain (which happens *before* FORWARD_IN_ZONES is traversed!)

• libvirt since 5.1.0 ships a libvirt zone with target ACCEPT and a rich rule to reject services that are not explicitly added to the zone. So with a new enough libvirt and firewalld, libvirt can be trusted to do the thing by default. Adding Docker bridges to this zone fixes networking for docker containers (Docker should probably create its own docker zone and add its bridge interfaces to this zone itself).

  Until interact is implemented, packets will be routed to trusted, exposing VMs/containers/etc to traffic from other zones! firewalld #177.

  • Traffic forwarded to trusted can be dropped with direct rules such as:

    • <?xml version="1.0" encoding="utf-8"?>
      <direct>
        <rule ipv="ipv4" table="filter" chain="FWDO_trusted" priority="-32768">-j LOG --log-prefix 'firewalld#177_DROP: '</rule>
        <rule ipv="ipv4" table="filter" chain="FWDO_trusted" priority="-32767">-j REJECT --reject-with icmp-admin-prohibited</rule>
        <rule ipv="ipv6" table="filter" chain="FWDO_trusted" priority="-32768">-j LOG --log-prefix 'firewalld#177_DROP: '</rule>
        <rule ipv="ipv6" table="filter" chain="FWDO_trusted" priority="-32767">-j REJECT --reject-with icmp6-adm-prohibited</rule>
      </direct>

      This fails with the nftables backend because there is no FWDO_trusted chain in the iptables compatibility filter table to which Direct rules are added. The rule would need to go into the filter_FWDO_trusted chain in the firewalld table instead.

    Alternatively, use internal or dmz instead of trusted, and add a Direct rule to enable forwarding from (but not to) these zones.

    • That too fails with nftables, because there is no FWDI_trusted chain in the iptables compatibility filter table to which Direct rules are added. The rule would need to go into the filter_FWDI_trusted chain in the firewalld table instead. Additionally, chains in the iptables compatibility filter table use hook priority 0, so a packet accepted here would later be dropped by the filter_FORWARD chain in the firewalld table at hook priority 10.

CategoryTechnote