Firewalld default zone limits on Rocky Linux: public allowlist vs. restrictive zones for preventing accidental service exposure

Question

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?

Tasadduq Burney · Answer

AnswerThe default public zone on Rocky Linux already provides sufficient protection against accidental exposure. It is an allowlist that typically permits only ssh and dhcpv6-client, so any newly installed service is not reachable from the network until you explicitly add it.Why a restrictive zone is not needed as a baselineZones such as block or drop implement a default‑deny posture. If you bind your primary interface to one of these zones you would also block ssh unless you add an explicit allow rule, which could lock you out of remote administration. Therefore, for the goal of keeping remote access intact while preventing inadvertent exposure, keeping public (or a custom allowlist zone) as the default is the safer baseline.Steps to maintain the desired policyKeep the default zone as public (or create a custom allowlist zone and set it as default).When you need to expose a service, add it permanently and then reload:firewall-cmd --permanent --zone=public --add-service=firewall-cmd --reloadAfter adding the service, verify that ssh still works from your remote host.Auditing runtime vs permanent rule driftRuntime and permanent configurations are separate. To detect drift:List the effective runtime rules for each zone:firewall-cmd --list-all --zone=List the permanent rules:firewall-cmd --permanent --list-all --zone=Compare the two outputs; any difference indicates drift that will be lost or applied on the next reload.Verification of real external reachabilityConfirm which addresses services are bound to:ss -tulpnCheck the active zone binding for your interfaces:firewall-cmd --get-active-zonesFrom an external host (outside any cloud security group), attempt a connection to the service port, e.g.:nc -vz # ornmap -p

After any firewall change, repeat the external test and also re‑check that ssh remains accessible.Missing diagnostic detailPlease confirm which zone is bound to your primary network interface (output of firewall-cmd --get-active-zones). If the interface is not in the public zone, the recommendation may change.

Firewalld default zone limits on Rocky Linux: public allowlist vs. restrictive zones for preventing accidental service exposure

1 answer

Answer

Why a restrictive zone is not needed as a baseline

Steps to maintain the desired policy

Auditing runtime vs permanent rule drift

Verification of real external reachability

Missing diagnostic detail

Your perspective belongs here.

0 question comments