Inicio
» LINUX
»
Cómo configurar el firewall de SLES 15 con firewall-cmd
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.
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.
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.
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:
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.
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.
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:
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:
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.
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.