Scripts en Sophos Firewall sin cronjobs: alternativas seguras

Quien desea ejecutar periódicamente un comando en Sophos Firewall suele buscar cronjobs, scripts de inicio o archivos persistentes de shell. Sin embargo, la documentación pública de administración de SFOS no describe ningún procedimiento operativo general para ello. El firewall es un dispositivo de seguridad y no debería convertirse en un servidor de automatización.

Para modificar configuraciones, es preferible utilizar XML API, Sophos Central o las funciones nativas de SFOS. Los estados y errores deberían supervisarse desde sistemas externos mediante Syslog, SNMP o sFlow. Un workaround local en shell solo debería instalarse en el firewall si Sophos lo describe públicamente para el caso concreto o si está supervisado por Sophos Support o Professional Services.

⚠️ Importante: Una copia de seguridad de la configuración no demuestra que los archivos, mecanismos de inicio o procesos en segundo plano creados por el usuario estén incluidos ni que vuelvan a estar disponibles después de una restauración, un failover de HA o una actualización de firmware.

Decisión rápida

Antes de elegir una solución técnica, debe estar claro qué tarea se quiere automatizar. Esta clasificación evita que un pequeño script se convierta inadvertidamente en un componente crítico para el funcionamiento del firewall.

Si un script debe reiniciar servicios, eliminar archivos o restablecer conexiones periódicamente, no constituye una solución de automatización. Probablemente esté ocultando una avería. En ese caso, primero deben analizarse los logs, el almacenamiento, la versión de firmware y el error concreto.

Por qué los scripts locales son problemáticos

Un script de shell puede ser técnicamente pequeño y, aun así, dificultar considerablemente el control operativo. Se encuentra fuera de la configuración habitual de WebAdmin, a menudo carece de Audit Trail y, después de una actualización, puede interactuar con archivos, servicios o permisos diferentes.

Hay cuatro riesgos especialmente importantes:

• Copia de seguridad y restauración: Sophos describe la copia de seguridad como una protección de la configuración del firewall. No existe una garantía general de restauración para archivos de shell o mecanismos de inicio propios.
• HA: Sophos sincroniza la configuración del Primary al Auxiliary. De ello no se puede deducir que cualquier archivo local o proceso creado por el usuario funcione de forma idéntica en ambos Nodes.
• Firmware: Una actualización puede modificar rutas internas, servicios o el comportamiento en tiempo de ejecución. Por ello, cualquier adaptación local debe volver a evaluarse después de cada actualización.
• Soporte: Sophos ofrece soporte para las API oficiales y los scripts de Sophos sin modificar. Para integraciones desarrolladas por el usuario, Sophos remite a partners o a Professional Services.

A esto se suman Secrets en texto plano, volúmenes de logs sin control, bucles infinitos y una resolución de problemas en la que ya nadie puede determinar con certeza si el comportamiento lo provoca SFOS o el workaround local.

Alternativas compatibles

Utilizar una función nativa de SFOS

Primero debe comprobarse si SFOS ya realiza la tarea de forma nativa. Las copias de seguridad programadas, las notificaciones, el enrutamiento, SD-WAN, la monitorización y el registro centralizado deben configurarse en los menús previstos para ello. Por ejemplo, una copia de seguridad recurrente no requiere ningún script de shell; su programación se encuentra en Backup & firmware > Backup & restore.

Para tareas relacionadas con el enrutamiento o el tráfico del sistema, una política correctamente definida suele ser más adecuada que ejecutar un comando después de cada reinicio. El artículo Enrutamiento SD-WAN para paquetes de respuesta y tráfico del sistema explica el método compatible.

Gestionar varios firewalls mediante Sophos Central

Si varios firewalls deben recibir la misma política, un grupo de firewalls en Sophos Central puede ser más adecuado que un script propio. La ruta es My Products > Firewall Management > Firewalls. Las políticas de grupo se aplican a los firewalls asignados y su estado puede consultarse en Tasks Queue.

Los grupos de Central no son una función universal de copia. Las reglas locales y las administradas de forma centralizada pueden influirse mutuamente en el orden, y no todas las configuraciones pueden representarse en cualquier estructura de grupos. Por ello, primero debe probarse con un grupo de prueba y después verificarse tanto Tasks Queue como las reglas aplicadas realmente.

Utilizar XML API desde un sistema externo

Para cambios recurrentes en objetos o políticas, XML API es el método programático previsto. La automatización debería ejecutarse en un sistema administrado en el que puedan controlarse el código, los Secrets, los logs, la programación y el rollback.

El firewall se prepara de la siguiente manera:

1. En Profiles > Device access, crear un perfil de administrador que incluya únicamente los permisos realmente necesarios y guardarlo con Save.
2. En Authentication > Users, hacer clic en Add, establecer User type en Administrator, seleccionar el nuevo perfil, limitar expresamente Login restriction for device access y guardar con Save.
3. En Hosts and services > IP host, definir el sistema de automatización como un objeto de host específico.
4. En Administration > API access, seleccionar API access.
5. En Allowed IP hosts, seleccionar únicamente el objeto de host preparado, añadirlo con el botón Add y guardar con Apply. SFOS admite aquí un máximo de 64 entradas.
6. En Administration > Device access, comprobar que HTTPS esté permitido desde la zona necesaria. Para el acceso desde WAN, es preferible utilizar una Local service ACL exception rule estricta en lugar de permitir HTTPS de forma general para WAN.

API access está desactivado de forma predeterminada. Después de actualizar a SFOS 22.0, las direcciones IP permitidas anteriormente se convierten en objetos de host con el prefijo apiconfig; estos permisos heredados deben incluirse en la siguiente revisión de accesos.

El artículo Proteger el acceso a XML API en Sophos Firewall explica detalladamente la cuenta de servicio, el comportamiento de MFA, el puerto de administración, Local Service ACL y la protección de Secrets. Para preparar o comparar cambios de configuración, también puede resultar útil Sophos Firewall Config Studio.

⚠️ La API no es segura por sí sola: Limite la IP de origen, no utilice una cuenta personal con permisos de administrador completos, no guarde Secrets en repositorios, tickets ni el historial de shell y pruebe primero las operaciones de escritura en un entorno de pruebas.

Ejecutar la monitorización fuera del firewall

Un sistema de monitorización debería observar el firewall desde el exterior. De lo contrario, el proceso local puede faltar precisamente cuando el propio firewall presenta una avería. Según el objetivo, pueden utilizarse Monitorización del hardware mediante SNMP, Monitorización mediante sFlow o Central Firewall Reporting.

Para el análisis a largo plazo de eventos y seguridad, un receptor externo de Syslog o SIEM resulta más adecuado que crear archivos de logs locales adicionales. De este modo, los datos permanecen disponibles incluso si el firewall se reinicia, falla o se sustituye.

Cuándo puede ser aceptable un workaround local

Algunos casos de soporte o implementaciones en la nube requieren un workaround muy limitado. Lo decisivo no es si el comando funciona técnicamente, sino si existe una guía actual de Sophos o una instrucción de soporte confirmada para ese escenario concreto.

Antes de aplicarlo, la versión, la plataforma, el modo HA y el procedimiento de reversión deben coincidir con la guía. Un script procedente de una publicación antigua de la Community, de otro modelo de appliance o de una versión anterior de SFOS no constituye una aprobación fiable para el entorno propio.

Si solo existe una propuesta propia, primero debería revisarse con el partner de Sophos o con Professional Services. Una guía genérica para integrar scripts de inicio propios sería, en este caso, más peligrosa que útil.

Sustituir de forma segura un script existente

No debe eliminarse inmediatamente un script existente. Primero hay que identificar qué dependencia operativa existe respecto a él.

1. Congelar los cambios: No seguir modificando inicialmente el script, el mecanismo de inicio ni el firewall afectado.
2. Documentar el propósito: Registrar el síntoma, el desencadenante, el resultado deseado, la ruta, el usuario, la programación, los Secrets y la persona responsable.
3. Observar el efecto: Documentar los logs, el estado del proceso, los archivos generados y las rutas, servicios o interfaces afectados. En HA, comprobar ambos Nodes por separado.
4. Elegir el método de destino: Asignar la función a una configuración nativa de SFOS, Central, XML API o una monitorización externa.
5. Probar la sustitución: Probar el nuevo procedimiento fuera del firewall productivo y registrar los resultados correctos, los errores y el rollback.
6. Realizar una transición controlada: Activar la sustitución durante una ventana de mantenimiento, desactivar el script local y ejecutar la prueba funcional correspondiente.
7. Programar una verificación posterior: Volver a comprobar después de un reinicio, un failover y la siguiente actualización de firmware, siempre que estos eventos sean relevantes para la función.

Antes del cambio debe existir una copia de seguridad actual. Crear o restaurar una copia de seguridad de Sophos Firewall explica Secure Storage Master Key, la restauración y la compatibilidad. La copia de seguridad protege la configuración documentada, pero no sustituye un inventario separado de las adaptaciones locales.

Validación y rollback

Una respuesta satisfactoria de la API o un proceso en ejecución todavía no demuestran que se haya cumplido la tarea funcional. Después de la transición debe probarse exactamente el resultado que antes dependía del script: que exista la regla, que la ruta esté activa, que se haya creado la copia de seguridad, que el destino sea accesible o que la alerta haya llegado al sistema de monitorización.

Para cambios mediante API, también deben revisarse Audit Trail y los objetos afectados. Si se modifica el tráfico, Log Viewer, Rule ID, NAT Rule ID, Policy Test o Packet Capture deben formar parte de la validación. Los cambios de Central se comprueban en Tasks Queue y después directamente en uno de los firewalls afectados.

El rollback no consiste en volver a activar precipitadamente el script antiguo. Primero debe revertirse el nuevo cambio y restaurarse el estado inicial documentado. Solo si el workaround antiguo se ha comprobado expresamente como opción de recuperación puede reactivarse durante un periodo limitado.

Recomendación operativa

Los scripts locales deberían figurar en la documentación operativa como una excepción temporal, no como una función normal del firewall. Cada excepción necesita un responsable, una fecha de revisión, un procedimiento de eliminación probado y una indicación clara de las versiones de Sophos cubiertas.

Para nuevas necesidades, debe seguirse este orden: función nativa de SFOS, Sophos Central, automatización externa mediante XML API, monitorización externa y, solo después, un caso especial confirmado por Sophos. Así, los cambios siguen siendo trazables, HA y la restauración resultan más previsibles y el firewall se mantiene más próximo al estado compatible del producto.

FAQ