Cómo documentar correctamente las reglas de Sophos Firewall

Una regla de firewall no es solo una autorización técnica, sino una decisión operativa: ¿quién puede acceder a qué, mediante qué servicio y por qué motivo? Sin este contexto, las reglas antiguas de pruebas, socios o migraciones suelen permanecer activas durante años porque nadie puede determinar con seguridad cuál era su propósito.

Por este motivo, la información más importante debe figurar directamente en Rule name y Description. El ticket o la wiki contienen los detalles, mientras que la propia regla muestra el contexto necesario para la operación diaria. Sin embargo, la descripción por sí sola no basta para realizar una depuración fiable; también se necesitan la Rule ID, el logging, los datos de uso, la confirmación del owner y un periodo de observación controlado.

El artículo Entender y configurar de forma segura las reglas de Sophos Firewall explica la estructura técnica. Esta guía se centra en la nomenclatura, la documentación y la revisión.

Dónde introducir la documentación

La ruta es Rules and policies > Firewall rules. Allí, seleccione primero IPv4 o IPv6 y edite una regla existente, o cree una nueva mediante Add firewall rule > New firewall rule.

En los ajustes generales, los siguientes campos son especialmente relevantes para la documentación:

• Rule name: nombre breve y fácil de identificar para la conexión.
• Rule position: posición dentro de la lista de reglas, que se evalúa de arriba abajo.
• Rule group: agrupación organizativa de la regla.
• Description: propósito, owner, ticket, revisión y cualquier excepción deliberada.
• Log firewall traffic: genera logs y datos de informes para las conexiones que coincidan.

Rule group mejora la organización, pero no modifica la lógica de evaluación. Sophos Firewall comprueba las reglas una a una, de arriba abajo, y se detiene en la primera coincidencia. Por eso, después de crear, clonar o generar automáticamente una regla, debe comprobarse su Rule position real.

Qué debe incluir la Description

Source, Destination, Services, Action y los Security Profiles ya aparecen en la regla. La Description no debería repetir estos campos, sino añadir la información que, de otro modo, faltaría más adelante.

Un estándar mínimo práctico incluye:

• Propósito: ¿qué proceso empresarial u operativo requiere la autorización?
• Owner: ¿qué equipo es responsable de la aplicación y de la decisión?
• Change o ticket: ¿dónde se encuentran la autorización, las pruebas y los detalles técnicos?
• Revisión o fecha de caducidad: ¿cuándo debe volver a revisarse o eliminarse la regla?
• Excepción: ¿qué desviación o restricción deliberada debe conocer el administrador?

No es necesario mantener manualmente el creador y la fecha de modificación si Configuration Audit y el proceso de change proporcionan estos datos de forma fiable. El nombre de una persona en la Description queda obsoleto rápidamente; un equipo permanente o un rol suele ser una mejor opción como owner.

Plantilla compacta

Para muchas reglas basta con una única línea estructurada:

Propósito=Acceso-ERP; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

Si existe una excepción deliberada, añada una breve indicación:

Propósito=Subida-de-socios; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Excepción=solo redes de socios definidas

Ejemplo práctico detallado

Para los equipos que utilizan una convención más detallada, una regla DNAT documentada puede tener, por ejemplo, este aspecto:

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

AUTHOR y LAST MODIFIED solo resultan útiles si el equipo los mantiene de forma coherente. Si Configuration Audit proporciona un historial fiable, en la Description bastan el propósito, el owner, el ticket y la fecha de Review; el ejemplo detallado puede quedar en la solicitud de cambio o en el runbook.

La Description es una referencia, no una CMDB completa. Los protocolos de prueba extensos, las decisiones de arquitectura y las instrucciones de rollback deben conservarse en el ticket o runbook enlazado.

Asignar nombres coherentes a las reglas

Un buen nombre permite comprender una regla desde la vista general sin tener que abrirla. El esquema no tiene que ser idéntico en todas las empresas, pero sí debe aplicarse de forma coherente dentro de cada entorno.

Por ejemplo, ha demostrado ser útil el siguiente formato:

TIPO_ORIGEN_DESTINO_SERVICIO

Ejemplos:

• ALLOW_VLAN12_WAN_HTTPS
• ALLOW_VPNUSERS_SRVERP_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• TEMP_PARTNER_SRVAPP_SFTP
• DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP o DROP facilitan la lectura rápida. El origen, el destino y el servicio muestran la dirección de la conexión. Las abreviaturas deben explicarse en un estándar interno de nomenclatura; de lo contrario, un nombre compacto se convierte simplemente en un nuevo acertijo.

Evite nombres genéricos como Rule1, Test, Allow, Internet o Temp. Tampoco son recomendables los nombres que solo contienen un ticket. Aunque CHG-1842 se puede consultar, durante una incidencia no explica ni la dirección ni el servicio.

Accesos temporales y servicios publicados

Las reglas temporales necesitan una fecha de caducidad real y un owner. Un prefijo como TEMP facilita la búsqueda, pero no sustituye a un proceso de retirada. La fecha debe figurar tanto en la Description como en el sistema de tickets o changes, para que una revisión pendiente no dependa únicamente de consultar el firewall.

En el caso de servidores publicados, la regla de firewall por sí sola no es suficiente como documentación. La regla DNAT, la Firewall Rule ID, el servicio público, el host de destino interno y la autorización deben documentarse juntos en el ticket. En la Description del firewall basta con indicar el change y el propósito; los detalles de NAT no deberían duplicarse como una segunda configuración difícil de leer en formato de texto.

Para la implementación técnica, consulte Publicar un servidor mediante DNAT en Sophos Firewall y Entender NAT en Sophos Firewall.

Qué no debe incluir la Description

La descripción de la regla es visible para los administradores y no es un almacén de secretos. No introduzca:

• contraseñas, claves API ni tokens,
• claves privadas ni Preshared Keys,
• datos personales o confidenciales de clientes sin una necesidad imperiosa,
• instrucciones completas de acceso para personas externas,
• URL largas con parámetros de sesión, token u otros datos confidenciales.

Un identificador interno de ticket como CHG-1842 es suficiente. El enlace propiamente dicho y los datos sensibles deben permanecer en el sistema previsto para ello, con su propio control de acceso.

Revisar las reglas existentes de forma controlada

La ausencia de una Description es un indicio para realizar una revisión, pero no un motivo para eliminar la regla de inmediato. El estado de SFOS Unused también es solo una señal a corto plazo: indica que la regla no ha encontrado tráfico coincidente durante las últimas 24 horas. Aun así, los procesos mensuales, los accesos de emergencia o las aplicaciones estacionales pueden ser legítimos.

Una revisión segura se realiza de la siguiente manera:

1. Marque las reglas sin Description, con un nombre genérico, con TEMP o con una fecha de revisión vencida.
2. Registre la Rule ID, la posición, Source, Destination, Services, Action y los Security Profiles.
3. Si es necesario, seleccione Reset data transfer count en More options y observe la regla durante un periodo representativo para la aplicación.
4. Compruebe los datos transferidos en Allowed policies, dentro de Reports > Dashboards > Traffic dashboard.
5. Busque en Log viewer por Rule ID, origen, destino y servicio.
6. Contraste el owner y el ticket con la necesidad empresarial actual.
7. Desactive primero las reglas que ya no sean necesarias, obsérvelas durante el periodo acordado y elimínelas solo después.
8. Documente la decisión, la prueba y la retirada en el change.

Un contador a cero no constituye una prueba si el periodo de observación ha sido demasiado corto. Del mismo modo, la ausencia de una entrada de log no demuestra nada si Log firewall traffic estaba desactivado o si los destinos de logs locales o externos no estaban configurados correctamente. En System services > Log settings se determina qué logs del firewall se almacenan localmente o se envían a Sophos Central o a servidores Syslog.

Trazar los cambios y sus efectos

La Description explica por qué debería existir una regla, pero no demuestra quién la modificó realmente. SFOS 22 puede registrar mediante Configuration Audit los cambios realizados en las reglas de firewall, incluyendo la configuración anterior y la nueva, la marca de tiempo, el administrador y la IP de origen. El estado se comprueba con system configuration-audit show; la función está activada de forma predeterminada.

El proceso operativo debería combinar tres tipos de evidencias:

• Description y ticket: propósito, owner, autorización y revisión.
• Configuration Audit: quién modificó qué configuración y cuándo.
• Log Viewer e informes: qué conexiones procesó realmente la regla.

El artículo Comprobar los logs de Audit Trail de Sophos Firewall explica con más detalle Configuration Audit y su evaluación. Después de modificar una regla, Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture permite comprobar si se aplica realmente la Rule ID esperada.

Estándar mínimo para reglas nuevas

Antes de cerrar un change, una regla nueva debería cumplir los siguientes requisitos:

• Rule name coherente,
• Rule position y Rule group comprobados de forma consciente,
• Source, Destination y Services sin un Any innecesariamente amplio,
• Description con propósito, owner, change y revisión,
• Log firewall traffic configurado según las necesidades operativas y de protección de datos,
• ningún secreto ni dato personal en el nombre o la Description,
• prueba funcional con la Rule ID esperada,
• proceso de caducidad y retirada para las reglas temporales.

FAQ