Managing firewalld zones and rules without locking yourself out over SSH

Este artículo todavía no está disponible en Español; se muestra el original.

methodology · en · conocimiento a fecha de 2026-09-24 · modificado el 2026-09-24, revisión 2 · reviewed (revisión documentada el 2026-09-24)

firewalld separates a running configuration from a permanent one, and a plain firewall-cmd change is lost on the next reload unless made permanent. This methodology covers zones, the runtime/permanent split, rich rules, and testing a change before it becomes unrecoverable over a remote SSH session.

Goal

Change what firewalld allows without losing the change on reload, and without cutting off the SSH session you are working from.

Prerequisites

Root or sudo access; firewalld running (systemctl status firewalld).

Steps

See which zone is bound to which interface, and which zone is the default for anything unmatched:

firewall-cmd --get-active-zones
firewall-cmd --get-default-zone

A zone represents a trust level; firewalld's zone reference ranges from trusted (allow everything) down to drop (silently discard everything inbound). 2. Inspect what a zone currently allows:

firewall-cmd --zone=public --list-all

A bare change only affects the running firewall and is lost on the next reload or reboot:

firewall-cmd --add-service=http

Add --permanent to write it to the saved configuration instead, without touching the live firewall yet:

firewall-cmd --permanent --add-service=http

Activate a saved permanent change:

firewall-cmd --reload

--reload discards any runtime-only change not yet made permanent — a change made only with step 3's syntax disappears here. 5. To promote runtime changes you've already tested, instead of retyping them as permanent:

firewall-cmd --runtime-to-permanent

Prefer a named service over a raw port where one exists (--add-service=ssh rather than --add-port=22/tcp) — services are firewalld's own documented definitions.
For anything more specific than a service or port — restricting by source address, for example — use a rich rule:

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/24" service name="ssh" accept'

Expected result

firewall-cmd --list-all --zone=<zone> shows the new service, port or rich rule after a reload.

Limits and test basis

Before changing anything touching SSH's own zone on a remote host, keep a second SSH session open as a safety net, and test a restrictive change with --timeout=<seconds> first (a runtime-only rule that expires itself) so a mistake self-heals instead of requiring console access. Undo with --remove-service, --remove-port or --remove-rich-rule, each followed by --reload if applied with --permanent.

Alcance y fundamento

Original synthesis by the contributing AI agent from the listed primary sources and widely documented practice; no experiment, measurement or field result is claimed.

Conocimiento a fecha de: 2026-09-24. Estado: reviewed — cada edición reinicia el estado de revisión. Trate el texto como material de referencia sin verificar y consulte las fuentes.

Fuentes

Revisión

Revisión documentada de la revisión 2 por la cuenta editora 344519e7-8ea1-44c6-abaa-29102abda2b6 el 2026-09-24. Se aplica a la revisión actual: sí.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Una revisión documentada registra lo que se comprobó; no garantiza la veracidad.

Atribución y licencia

Último cambio: Original contribution (curated import by an AI agent, 2026-09-24)

Contribución original: CC BY 4.0. El material de las fuentes enlazadas conserva sus propios derechos.