Cómo configurar el firewall de SLES 15 con firewall-cmd

Un servicio puede estar ejecutándose en un servidor SLES 15 y aun así agotar el tiempo de espera para los clientes remotos porque el firewall bloquea el nuevo tráfico entrante. La solución suele ser identificar la zona firewalld activa y permitir solo el servicio o puerto que necesita la aplicación. La herramienta de línea de comandos de SLES para esta tarea es firewall-cmd.

Esta guía se basa en la Guía de seguridad y protección de SLES 15 SP7 de SUSE y en la referencia del comando firewalld, revisada el 7 de octubre de 2026. Los Service Packs anteriores y los sistemas SLES 12 actualizados pueden presentar configuraciones de firewall diferentes o heredadas. Las imágenes de la terminal muestran ejemplos representativos, no resultados obtenidos de un servidor real; reemplace los nombres de las interfaces, las zonas y los servicios con los valores de su equipo.

1. Compruebe que firewalld se esté ejecutando.

SUSE documenta que firewalld viene instalado y habilitado por defecto en SLES 15. YaST normalmente lo inicia después de la instalación y coloca las interfaces en la publiczona predeterminada. Aun así, compruebe la máquina en lugar de asumir que la configuración predeterminada no ha cambiado. Ejecute estos comandos con una cuenta autorizada para usar sudo:

sudo systemctl status firewalld
sudo firewall-cmd --state

El administrador del servicio debería informar que firewalldestá activo y firewall-cmd --statedebería informar running. Si el servicio está instalado pero detenido, inícielo y habilítelo al arrancar el sistema:

sudo systemctl enable --now firewalld

Si firewall-cmdfalta, compruebe si el firewalldpaquete está instalado y disponible en los repositorios SUSE habilitados. No instale ni reemplace componentes de firewall a ciegas en un servidor administrado.

Ejemplo de terminal SLES comprobando el estado del servicio firewalld y listando la zona pública activa en eth0.
El terminal de ejemplo comprueba el estado de firewalld y muestra un ejemplo de zona pública activa con la interfaz eth0.

2. Localiza la zona que protege la interfaz del servidor.

Firewalld agrupa las reglas en zonas , que representan diferentes niveles de confianza. La publiczona se usa comúnmente para redes que no son de confianza. Un servicio abierto en una zona no se abre automáticamente en todas las demás, por lo que una regla correcta en la zona incorrecta puede dejar su aplicación inaccesible.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --zone=public --list-all

Utilice la salida de active-zone para encontrar la zona asociada a la interfaz que transporta el tráfico del cliente. El nombre de la interfaz podría ser eth0, ens160, u otro nombre. Si necesita comprobar una interfaz, ejecute:

sudo firewall-cmd --get-zone-of-interface=eth0

Sustituya eth0por la interfaz real. Una interfaz que no esté asignada explícitamente a una zona se gestiona mediante la zona predeterminada. Evite modificar la zona predeterminada sin motivo, ya que esto puede afectar a las interfaces que dependen de ella. En un servidor remoto, identifique la zona SSH u otra zona de administración y confirme su regla de acceso antes de recargar la configuración del firewall. Mantenga disponible una consola o una ruta de recuperación fuera de banda, si existe.

Ejemplo de terminal SLES que muestra la zona pública predeterminada, la interfaz eth0, el servicio SSH y las reglas de zona actuales.
El listado de zonas muestra qué interfaces y servicios están asociados con la zona pública de ejemplo antes de realizar cualquier cambio.

3. Elija un servicio con nombre o un puerto específico.

Un servicio firewalld es una definición con nombre que puede incluir uno o más puertos y protocolos. Generalmente, es más fácil permitir un servicio conocido por su nombre que memorizar su número de puerto. Consulta la lista de servicios instalados e inspecciona una definición antes de usarla:

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=http

Para un servidor web, el httpservicio predefinido suele cubrir el puerto TCP 80; httpsel servicio independiente se utiliza para el tráfico web TLS. La documentación de SLES muestra el mismo método basado en servicios con ejemplos como DHCP. Utilice el servicio que su aplicación requiera y verifique la definición del servicio localmente si tiene dudas.

Si ningún servicio predefinido se ajusta, abra solo el puerto y el protocolo necesarios. Por ejemplo, se puede permitir que una aplicación que escucha en --add-port=8443/tcpel puerto TCP 8443 utilice la opción `-

Prueba primero una regla temporal.

Para una prueba breve, aplique una regla a la configuración de tiempo de ejecución. Los cambios en tiempo de ejecución surten efecto de inmediato, pero se pierden tras una recarga del firewall o un reinicio del servicio, a menos que también los guarde de forma permanente. Firewalld admite una regla con límite de tiempo, lo cual resulta útil cuando se desea que una prueba caduque automáticamente.

sudo firewall-cmd --zone=public --add-service=http --timeout=5m

Para una prueba de puerto única, utilice --add-port=8443/tcp --timeout=5men lugar de --add-service=http. Seleccione la zona que realmente contiene la interfaz del servidor; no copie publicsi su host utiliza otra zona.

Ejemplo de terminal SLES que agrega el servicio HTTP de forma permanente a la zona pública y recarga firewalld.
El comando de ejemplo agrega el servicio HTTP a la configuración permanente de la zona pública y luego recarga firewalld para aplicarlo.

4. Guarda la regla y reinicia firewalld.

Cuando esté listo para mantener una regla, agréguela a la configuración permanente. El siguiente ejemplo permite HTTP en la zona pública:

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --reload

Para HTTPS, repita el comando permanente con --add-service=https. Para un puerto de aplicación personalizado, utilice un comando como:

sudo firewall-cmd --permanent --zone=public --add-port=8443/tcp
sudo firewall-cmd --reload

Estos ejemplos modifican primero la configuración permanente y luego la recargan para que la nueva regla se active. Al recargar, también se reemplazan los ajustes de tiempo de ejecución con la configuración permanente. Por lo tanto, cualquier cambio realizado solo en tiempo de ejecución en otras partes del sistema puede descartarse. Antes de recargar un sistema de producción, revise las reglas importantes de tiempo de ejecución y permanentes, especialmente el acceso de administración remota.

También existe un flujo de trabajo que prioriza la ejecución: pruebe una regla en tiempo de ejecución, confirme que el servicio funciona y, a continuación, añada esa misma regla --permanenty recargue. Evite usar --runtime-to-permanentcomo atajo a menos que desee guardar todas las reglas de ejecución vigentes, incluidos los cambios temporales realizados por otros administradores o software.

¿Cómo se puede verificar que el cambio funcionó?

Compruebe tanto la regla de ejecución activa como la regla guardada. Para un servicio HTTP en la zona pública, ejecute:

sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --permanent --zone=public --list-services
sudo firewall-cmd --check-config

La consulta debería devolver yes, la lista de servicios permanentes debería incluir http, y la comprobación de configuración debería completarse correctamente. Para una regla de puerto, utilice --query-port=8443/tcpy --list-portsen los comandos equivalentes. Pruebe también desde un cliente independiente que pueda acceder al servidor; una consulta al firewall local confirma que la regla está presente, no que el DNS, el enrutamiento, los firewalls ascendentes o el oyente de la aplicación sean correctos.

Ejemplo de terminal SLES que confirma que HTTP está permitido en configuraciones de tiempo de ejecución y permanentes, y que verifica la configuración de firewalld.
Los comandos de verificación comprueban la regla de servicio activa, la lista de servicios guardada y la sintaxis de configuración permanente.

Problemas comunes y soluciones seguras

  • La regla está presente, pero las conexiones siguen agotando el tiempo de espera: asegúrese de que se haya agregado a la zona asociada a la interfaz del cliente. A continuación, verifique que la aplicación esté escuchando en la dirección y el puerto esperados, y compruebe cualquier cortafuegos de red en la red.
  • La regla funcionó hasta que se recargó la aplicación: probablemente se agregó solo en tiempo de ejecución. Agréguela --permanenty recargue, luego consulte ambas configuraciones.
  • El acceso SSH está en riesgo: compruebe los servicios de la zona activa y los servicios permanentes antes de reiniciar. Si se requiere SSH y no está disponible, añada el sshservicio a la zona correcta de forma permanente antes de reiniciar. No cierre su sesión remota actual hasta que haya probado una segunda conexión.
  • Estás migrando desde una versión anterior de SUSE: SLES 15 reemplazó SuSEfirewall2 por firewalld. SUSE advierte que los perfiles de firewall heredados tienen compatibilidad con versiones anteriores limitada; revisa la guía de migración en lugar de asumir que todas las reglas antiguas se tradujeron.
  • Parece haber un conflicto entre las reglas: firewalld está diseñado para administrar las reglas del firewall del host. SUSE advierte contra la modificación de las mismas reglas por separado con herramientas como iptables, ya que esto puede confundir la configuración activa.

Para eliminar un servicio o puerto permanente innecesario, utilice la opción correspondiente --remove-servicecon --remove-port, --permanentluego recargue y verifique nuevamente. Por ejemplo, elimine HTTP de la zona pública con sudo firewall-cmd --permanent --zone=public --remove-service=httpseguido de sudo firewall-cmd --reload.

Autoevaluación antes de finalizar

  • firewalldEstá en funcionamiento y se inicia cuando arranca el servidor.
  • Has identificado la zona activa para la interfaz que recibe tráfico.
  • En esa zona solo se permite el servicio o puerto que necesita la aplicación.
  • La administración remota sigue estando permitida antes y después de la recarga.
  • La regla aparece en las consultas en tiempo de ejecución y permanentes, y la comprobación de configuración se realiza correctamente.
  • Una prueba de conexión desde otro host confirma que la aplicación es accesible.

Para obtener detalles específicos de la versión, consulte la guía del firewall de SUSE SLES 15 SP7 , el manual de firewall-cmd y las notas de firewalld sobre la configuración en tiempo de ejecución y permanente, así como sobre la apertura de un puerto o servicio .

Dejar un comentario

Cómo configurar el firewall de SLES 15 con firewall-cmd

Cómo configurar el firewall de SLES 15 con firewall-cmd

Configure firewalld en SLES 15: compruebe las zonas, permita servicios o puertos, guarde reglas permanentes, recargue de forma segura y verifique el acceso.

Guía de configuración de parcheo en vivo de SLES: Aplicar actualizaciones del kernel sin reiniciar

Guía de configuración de parcheo en vivo de SLES: Aplicar actualizaciones del kernel sin reiniciar

Habilite la aplicación de parches en vivo al kernel en SLES 15 SP7, aplique las correcciones compatibles sin reiniciar, verifique los parches activos y comprenda cuándo aún es necesario reiniciar el kernel.

Cómo habilitar el modo FIPS en SUSE Linux Enterprise Server 15

Cómo habilitar el modo FIPS en SUSE Linux Enterprise Server 15

Habilite el modo FIPS en SLES 15 con la utilidad de configuración compatible de SUSE, reinicie de forma segura, verifique el estado del kernel y de la política criptográfica, y compruebe los límites de certificación.

Cómo instalar Google Chrome en Gooroom OS sin infringir las políticas de seguridad.

Cómo instalar Google Chrome en Gooroom OS sin infringir las políticas de seguridad.

Instala Google Chrome en Gooroom OS de forma segura con paquetes .deb oficiales, APT, comprobaciones de políticas, guías de actualización y soluciones para dispositivos administrados.

Cómo exportar de forma segura los registros del sistema SLES a un servidor Syslog remoto

Cómo exportar de forma segura los registros del sistema SLES a un servidor Syslog remoto

Envíe de forma segura los registros del sistema SLES a un servidor syslog remoto mediante rsyslog, certificados TLS, verificación del nombre del par, colas, validación y pruebas.

Integración de Active Directory de SLES 15 con SSSD: Guía paso a paso

Integración de Active Directory de SLES 15 con SSSD: Guía paso a paso

Une SLES 15 a Active Directory con SSSD usando YaST. Prepara el DNS y la hora, configura los inicios de sesión del dominio, verifica Kerberos y compara SSSD, Winbind y realmd.

Solucionar problemas con el controlador Wi-Fi Realtek RTL8821CE en Pardus Linux

Solucionar problemas con el controlador Wi-Fi Realtek RTL8821CE en Pardus Linux

Solucione el problema de Wi-Fi RTL8821CE en Pardus Linux revisando el controlador rtw88 integrado, el firmware de Realtek, rfkill, NetworkManager y las opciones de reserva segura.

Fix "Temporary Failure Resolving DNS" in Debian 12 with systemd-resolved

Fix "Temporary Failure Resolving DNS" in Debian 12 with systemd-resolved

Diagnose and fix Debian 12 DNS resolution failures with systemd-resolved, including resolv.conf, NetworkManager, networkd, cache, and verification.

Cómo instalar Pardus Linux junto con Windows 11 de forma segura en arranque dual

Cómo instalar Pardus Linux junto con Windows 11 de forma segura en arranque dual

Instale Pardus 25.2 junto a Windows 11 realizando una copia de seguridad, reduciendo el volumen de Windows, arrancando desde una unidad USB UEFI y protegiendo las particiones EFI y de recuperación existentes.

Solucionar el error 500 "Error al actualizar los repositorios de Zypper" en SLES

Solucionar el error 500 "Error al actualizar los repositorios de Zypper" en SLES

Diagnostica los fallos de actualización de Zypper con código HTTP 500 en SUSE Linux Enterprise Server. Identifica el repositorio que falla, comprueba los proxies y el registro, y actualiza los metadatos de forma segura.