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. Un grupo no puede quedar vacío. Para mover una regla más allá de los límites del grupo, primero hay que separarla mediante Detach o mover el grupo completo. Por eso, después de crear, clonar o generar automáticamente una regla, debe comprobarse su Rule position real.

Quienes administren reglas mediante la API deben tener en cuenta algunos límites fijos de SFOS 22. El Rule name puede tener un máximo de 60 caracteres y no debe contener comas. Para los Rule groups, la API admite 150 caracteres en el nombre, 255 caracteres en la descripción y un máximo de 200 referencias a reglas. Estos límites se aplican a la API. La ayuda actual de WebAdmin no indica ningún límite de caracteres para la Description. Aun así, conviene mantenerla breve para que resulte legible en la tabla de reglas.

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

Una regla DNAT documentada de forma detallada puede tener este aspecto:

DNAT - Synology HTTPS
---
OWNER: NETOPS
LAST REVIEW: 2027-01-31
SOURCE: PARTNER_NETS
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined partner networks
DOC: CHG-1842

Este formato muestra Source, Destination y Service incluso fuera de WebAdmin. Sin embargo, cuando alguien modifica la regla, también debe actualizar la Description; de lo contrario, ambas se contradicen. Por eso recomendamos la plantilla compacta. Si Configuration Audit registra los cambios de forma fiable, en la Description bastan el propósito, el owner, el ticket y la revisión. El ejemplo detallado puede figurar en el change 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:

PREFIX_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 y DROP indican la acción, DNAT identifica la regla de firewall de una publicación y TEMP, una autorización temporal. En este contexto, DNAT no designa la propia regla NAT. El origen, el destino y el servicio muestran la dirección. Las abreviaturas deben explicarse en el 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 motivo para revisar una regla, pero no para eliminarla de inmediato. El estado de SFOS Unused también es solo una instantánea. Según la vista, la ayuda actual de Sophos indica 12 o 24 horas sin tráfico coincidente. 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, el estado de activación, Source, Destination, Services, Action y los Security Profiles. Si es necesario, revise mediante Object Usage los hosts y servicios utilizados; su contador muestra dependencias de configuración, no el tráfico de una regla.
3. Antes de usar More options > Reset data transfer count, anote en el change la marca de tiempo y el valor actual del contador. Restablezca el contador únicamente si el periodo de observación posterior también cubre las conexiones poco frecuentes.
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 las reglas que ya no sean necesarias durante una ventana acordada y obsérvelas. Si se interrumpe tráfico esperado, vuelva a activar la regla de inmediato, compruebe su posición y repita la prueba con la Rule ID esperada.
8. Documente la decisión, la prueba y la retirada en el change.

La regla desactivada solo se elimina cuando el periodo de observación acordado ha concluido sin incidencias y el owner ha dado su conformidad. Un contador a cero no demuestra nada si el periodo fue demasiado corto. La ausencia de una entrada de log tampoco es una prueba. Es posible que Log firewall traffic estuviera desactivado, que una conexión terminara sin un evento Destroy registrado o que los destinos de log no estuvieran 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 muestra quién la modificó realmente. En SFOS 22, Configuration Audit registra el estado anterior y el nuevo, además de la marca de tiempo, el administrador y la IP de origen. El estado se comprueba en Device Console mediante system configuration-audit show, no en Advanced Shell. 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