Documentar reglas de Sophos Firewall

Las reglas de firewall se vuelven confusas rápidamente. Al principio, cada regla parece lógica: un servidor necesita acceso a Internet, se publica un servicio, una VPN necesita acceso o una aplicación requiere puertos específicos. Meses después, a menudo nadie recuerda por qué existe la regla, quién la solicitó o si sigue siendo necesaria.

La contramedida más sencilla no es una gran CMDB, sino una descripción clara directamente en la regla de Sophos Firewall. Unos pocos datos coherentes ya ayudan en troubleshooting, auditorías, limpiezas y traspasos.

Para la estructura de una regla, Entender y configurar correctamente las reglas de Sophos Firewall es el artículo base. Después de guardar una regla, resulta útil Probar una regla de Sophos Firewall con Log Viewer y Packet Capture.

Por Qué Es Importante Documentar Las Reglas

Una regla de firewall no es solo una autorización técnica. Es una decisión operativa: quién puede acceder a qué, mediante qué servicio, con qué riesgo y por qué motivo.

Sin documentación aparecen problemas típicos:

• Las reglas antiguas siguen activas porque nadie conoce su propósito.
• Las reglas de prueba nunca se eliminan.
• Las auditorías consumen demasiado tiempo.
• Las incidencias duran más porque el owner de la aplicación no está claro.
• Los cambios se hacen directamente en el firewall, pero no quedan documentados.
• Las reglas no se limpian por miedo a efectos secundarios.

Una buena descripción no evita todos estos problemas, pero reduce claramente la fricción en la operación diaria.

Dónde Introducir La Descripción

El campo Description se encuentra directamente en la regla de firewall. La regla se abre en:

Rules and policies > Firewall rules

Después se edita la regla correspondiente y se mantiene el campo de descripción.

El campo es limitado. Por eso no debe sustituir toda la documentación técnica, sino hacer visible la información operativa más importante directamente en el firewall. Los detalles pueden permanecer en un ticket, wiki, change request o carpeta de proyecto.

Qué Debe Contener La Descripción De Una Regla

Source, Destination, Services, NAT y Security Features ya son visibles en la regla. La descripción no debe repetirlo todo, sino explicar lo que más adelante ya no será evidente.

Datos útiles:

• Propósito: ¿Por qué existe la regla?
• Aplicación / servicio: ¿Qué aplicación o proceso necesita la regla?
• Owner: ¿Quién es responsable?
• Ticket / change: ¿Dónde está documentado el cambio?
• Creador / editor: ¿Quién creó o modificó la regla?
• Fecha: ¿Cuándo se creó o revisó por última vez?
• Review: ¿Cuándo debe revisarse o eliminarse?
• Particularidad: Excepción, desviación o riesgo consciente.

No todas las reglas necesitan todos los campos. Para una regla estándar de clientes suele bastar menos. DNAT, VPN, management, accesos de partners o excepciones temporales deben describirse con más precisión.

Combinar Nombre Y Description

El nombre de la regla debe ser corto y estructurado. La Description explica el contexto. No existe un esquema perfecto para todas las empresas. Lo importante es que un administrador pueda entender aproximadamente qué hace la regla al revisar la base de reglas sin tener que abrir cada una.

En la práctica, tres enfoques funcionan bien:

• Origen, destino, servicio: VLAN12_WAN_HTTPS. Buena variante estándar para reglas de clientes, servidores y VPN.
• Aplicación, origen, destino: ERP_VPNUSERS_SRVERP_HTTPS. Útil cuando la aplicación es más importante que el segmento de red.
• Tipo de regla como prefijo: DNAT_WAN_SRVWEB01_HTTPS. Útil para DNAT, reglas Drop, reglas temporales o casos especiales.

A menudo usamos el patrón SOURCE_DESTINATION_PORT, porque sigue siendo técnico y legible incluso meses después. La acción no tiene que estar necesariamente en el nombre, ya que Sophos Firewall ya muestra Accept, Drop o Reject en la regla.

Ejemplos típicos:

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

Según el entorno, el esquema puede ampliarse ligeramente:

• ZONE_SOURCE_DESTINATION_PORT, por ejemplo LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, por ejemplo ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, por ejemplo CHG1842_VPNUSERS_SRVERP_HTTPS

En entornos pequeños, un patrón simple suele ser suficiente. En entornos grandes con muchos VLANs, VPNs, redes de servidores y reglas DNAT, un estándar coherente resulta mucho más valioso. Prefijos como DNAT, DROP o TEMP son útiles cuando ayudan a escanear rápidamente la base de reglas o indican un tipo especial de regla.

Conviene evitar nombres muy genéricos, porque después no aportan información:

• Rule1
• Test
• Allow
• Internet
• Temp

Ejemplo Compacto

Ejemplo de una regla productiva:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

Si hay poco espacio, se puede trabajar de forma más breve. Aun así, propósito, owner y ticket deben seguir siendo visibles:

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

Para una regla temporal, la fecha de caducidad debe ser especialmente clara:

Temp vendor access para migración, Owner IT, CHG-1910, remove after 2026-07-31

Qué No Debe Escribirse En La Description

En el campo Description no deben incluirse:

• contraseñas,
• claves API,
• datos personales sin motivo,
• datos confidenciales de clientes,
• instrucciones completas de acceso para terceros,
• URL externas largas sin contexto interno.

Si intervienen proveedores externos, suele bastar con un contacto interno, un ticket o una referencia documental. Los detalles sensibles deben estar en un sistema adecuado de tickets, documentación o contraseñas, no en una regla de firewall.

Review Y Limpieza

La descripción de reglas es solo el primer paso. Lo importante es revisar las reglas con regularidad.

Proceso práctico:

1. Marcar reglas sin Description.
2. Revisar reglas con Test, Temp, Allow any o nombres poco claros.
3. Evaluar Usage Counter y Log Viewer.
4. Buscar owner o ticket.
5. Desactivar reglas que ya no se necesitan, observarlas y eliminarlas después.
6. Documentar el cambio.

En cada limpieza debería estar activado Log firewall traffic para las reglas relevantes, de modo que Log Viewer muestre si una regla todavía se usa. Para pruebas después de cambios, ayuda Probar una regla de Sophos Firewall con Log Viewer y Packet Capture.

Estándar Mínimo Para Nuevas Reglas

Las nuevas reglas de Sophos Firewall deberían tener al menos:

• un nombre significativo,
• Source y Destination claros en lugar de Any innecesario,
• logging activo para reglas importantes,
• una Description con propósito, owner y ticket,
• una fecha de review para reglas temporales o de riesgo,
• ningún secreto en el campo Description,
• una prueba después de guardar.

Para servidores publicados también es relevante Publicar un servidor con DNAT en Sophos Firewall. Para fundamentos de NAT, véase Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

FAQ