Firewalld default zone limits on Rocky Linux: public allowlist vs. restrictive zones for preventing accidental service exposure
0 reputation · 11 Feb 2021, 21:50 UTC
0 reputation · 11 Feb 2021, 21:50 UTC
On a Rocky Linux server, firewalld is enabled by default with the public zone, which permits only a small set of services such as ssh and dhcpv6-client. The goal is to make sure that services installed later are never reachable externally unless deliberately allowed, while keeping remote administration access intact.
The uncertainty is which strategy the default configuration actually supports best. Keeping the public zone and adding explicit service rules is one documented option; assigning interfaces to a more restrictive zone such as block or drop is another, and the documentation does not mandate either. There is also confusion around runtime versus permanent rules: a rule added without --permanent disappears on reload, and a permanent-only rule does not apply until a reload, so the actual exposure at any moment can differ from the intended persistent policy. Default zone contents may also differ between cloud images and DVD installs, and cloud security groups add a second layer that can change independently.
Binding behavior is a separate variable: a service listening on 0.0.0.0 is exposed on every interface whenever filtering is permissive, while 127.0.0.1 limits it to localhost regardless of firewall state.
Does the default public zone provide sufficient protection against accidental exposure, or is a restrictive zone the safer baseline? How should runtime and permanent rule drift be audited reliably? Which verification steps confirm real external reachability after any change?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.