FIREWALLD.POLICIES(5) | firewalld.policies | FIREWALLD.POLICIES(5) |
firewalld.policies - firewalld policies
A policy applies a set of rules to traffic flowing between between zones (see zones (see firewalld.zones(5)). The policy affects traffic in a stateful unidirectional manner, e.g. zoneA to zoneB. This allows asynchronous filtering policies.
A policy's relationship to zones is defined by assigning assigning a set set of ingress zones and a set of egress zones. For example, if the set of ingress zones "public" and the set of egress zones contains "internal" then the policy will affect all traffic flowing from the "public" zone to the "internal" zone. However, since policies are unidirectional it will not apply to traffic flowing from "internal" to "public". Note that the ingress set and egress set can contain multiple zones.
Policies only become active if all of the following are true.
If the policy is not active then the policy has no effect.
Regular zones are not enough to express every form of packet filtering. For example there is no zone to represent traffic flowing to or from the host running firewalld. As such, there are some symbolic zones to fill these gaps. However, symbolic zones are unique in that they're the only zone allowed in the ingress or egress zone sets. For example, you cannot use "public" and "HOST" in the ingress zones.
Symbolic zones:
This symbolic zone is for traffic flowing to or from the host running firewalld. This corresponds to netfilter (iptables/nftables) chains INPUT and OUTPUT.
This symbolic zone behaves like a wildcard for the ingress and egress zones. With the exception that it does not include "HOST". It's useful if you want a policy to apply to every zone.
firewalld ships with some predefined policies. These may or may not be active by default. For details see the description of each policy.
Policies are similar to zones in that they are an attachment point for firewalld's primitives: services, ports, forward ports, etc. This is not a coincidence. Policies are a generalization of how zones have traditionally achieved filtering. In fact, in modern firewalld zones are internally implemented as a set of policies.
The main difference between policies and zones is that policies allow filtering in all directions: input, output, and forwarding. With a couple of exceptions zones only allow input filtering which is sufficient for an end station firewalling. However, for network level filtering or filtering on behalf of virtual machines and containers something more flexible, i.e. policies, are needed.
firewall-applet(1), firewalld(1), firewall-cmd(1), firewall-config(1), firewalld.conf(5), firewalld.direct(5), firewalld.dbus(5), firewalld.icmptype(5), firewalld.lockdown-whitelist(5), firewall-offline-cmd(1), firewalld.richlanguage(5), firewalld.service(5), firewalld.zone(5), firewalld.zones(5), firewalld.policy(5), firewalld.policies(5), firewalld.ipset(5), firewalld.helper(5)
firewalld home page:
More documentation with examples:
Thomas Woerner <twoerner@redhat.com>
Jiri Popelka <jpopelka@redhat.com>
Eric Garver <eric@garver.life>
firewalld 0.9.3 |