Asegurar el acceso a la API XML de Sophos Firewall

La API XML de Sophos Firewall es útil para automatización, monitoreo, copias de seguridad, análisis e integraciones. Precisamente por eso, también forma parte de la superficie de ataque de gestión. Permitir acceso a la API otorga a un sistema la capacidad de leer datos de configuración o realizar cambios según los permisos.

Por lo tanto, el acceso a la API no debe permitirse ampliamente desde redes internas o fuentes arbitrarias. Es mejor tener un conjunto pequeño y documentado de redes de gestión, hosts de automatización o accesos de socios fijos.

Desde SFOS 22, Sophos ha ampliado el control de acceso a la API. Las configuraciones de acceso a la API se encuentran en el área de Administration > API access, y las fuentes permitidas pueden definirse como hosts IP. Esto permite modelar no solo direcciones IP individuales, sino también rangos de IP y redes de manera ordenada.

Cuándo es útil el acceso a la API XML

La API XML no es un acceso estándar para el trabajo administrativo normal. Su uso es adecuado cuando hay un proceso técnico concreto detrás.

Casos de uso típicos:

Monitoreo o inventario.
Verificaciones de configuración automatizadas.
Procesos de copia de seguridad o documentación.
Plataformas MSP o de integración.
Scripts para tareas administrativas recurrentes.
Cambios preparados desde herramientas como Sophos Firewall Config Studio.

Si un proceso puede funcionar sin la API, no se debe dejar el acceso a la API activado por precaución. Cada interfaz adicional necesita un propietario, una fuente, un concepto de acceso y un control.

Cambios con SFOS 22

Con SFOS 22, el control de acceso a la API XML se ha vuelto mucho más manejable en operación:

Las configuraciones de acceso a la API se han movido al menú Administration > API access.
El acceso a la API está desactivado por defecto y debe activarse conscientemente.
El acceso a la API puede restringirse a hosts IP.
Como fuentes, son posibles direcciones IP, rangos de IP y redes.
Se pueden permitir hasta 64 hosts IP.
Al actualizar, las direcciones IP permitidas anteriormente se convierten automáticamente en objetos de host IP.
Los objetos migrados reciben el prefijo apiconfig.

Esto es útil en operación porque las fuentes de la API ya no tienen que mantenerse solo como direcciones individuales sueltas. Se puede nombrar de manera ordenada una red de gestión, un host de automatización o un grupo de hosts dedicado y reconocerlos en revisiones posteriores.

Regla básica: permitir API solo desde fuentes definidas

API access debe tratarse igual que WebAdmin o SSH: tan restringido como sea posible y tan amplio como sea necesario.

Fuentes adecuadas pueden ser:

un servidor de automatización dedicado,
un sistema de monitorización,
un host de gestión de configuración,
una red interna de gestión,
una red VPN o de administración,
una dirección de origen de partner o MSP claramente definida.

No son adecuadas:

redes de clientes completas,
redes de invitados o IoT,
Any,
permisos imprecisos tipo “toda la red de servidores”,
direcciones IP temporales de prueba que luego se olvidan.

Si proveedores externos necesitan acceso API, la fuente debe definirse con la mayor precisión posible. Además debe documentarse para qué se usa el acceso y cuándo se eliminará.

Procedimiento recomendado

La ruta exacta en la interfaz puede variar ligeramente según la versión de SFOS. En SFOS 22, la configuración de la API se encuentra en Administration > API access.

Procedimiento práctico:

Comprobar qué sistema necesita acceso API.
En Hosts and services > IP host, crear un objeto IP Host claro para este sistema.
Si se requieren varias fuentes, nombrar correctamente IP Hosts, IP ranges o redes.
En Administration > API access, activar API access.
En Allowed IP hosts, permitir solo esos objetos.
Hacer clic en Apply.
No añadir redes amplias de clientes o servidores.
Probar el acceso desde el host real de automatización o monitorización, no desde el portátil del administrador.
Eliminar las fuentes que ya no sean necesarias.
Documentar el cambio en el proceso de change.

En instalaciones existentes después de una actualización a SFOS 22, también se deben buscar objetos con el prefijo apiconfig. Estos objetos se crearon a partir de entradas antiguas de autorización API y deben revisarse, renombrarse o limpiarse.

Probar el acceso de forma dirigida

El endpoint de la API suele estar en:

https://<IP-o-hostname-del-firewall>:<Port>/webconsole/APIController

El puerto es el puerto HTTPS de la WebAdmin Console. Si el puerto de administración se cambió en Administration > Admin settings, la herramienta API debe usar el mismo puerto. La API trabaja con payloads XML mediante HTTP POST, no como una API REST clásica con endpoints GET, POST, PUT y DELETE separados.

Una prueba útil no solo responde si el inicio de sesión es posible. Debe mostrar si la fuente correcta está permitida, si la cuenta puede ejecutar la operación necesaria y si el resultado queda trazable en el proceso de auditoría o change.

Para la aceptación, comprobar estos puntos por separado:

Fuente: La prueba se ejecuta desde el host real de automatización, monitorización o integración, no desde el portátil del administrador.
Acceso: El firewall acepta la IP de origen solo si el objeto IP Host correspondiente está permitido en API access.
Cuenta: La cuenta API o de servicio utilizada tiene solo los permisos necesarios.
Secreto: Usuario, contraseña o token no terminan en el historial de shell, tickets, chats o capturas de pantalla.
Auditoría: El acceso o el cambio queda trazable en el proceso de auditoría o change.
Rollback: Antes de operaciones de escritura existen un backup, un punto de rollback y una prueba de lectura inofensiva.

Los ejemplos curl con usuario y contraseña en la URL se copian rápido y luego son difíciles de eliminar de los registros. Es mejor una prueba breve con una cuenta de servicio dedicada, un secreto temporal, almacenamiento seguro y rotación posterior si un secreto se usó en un contexto no seguro.

Para pruebas estructuradas, una colección Postman suele ser más limpia que un comando shell copiado rápidamente. También allí, dirección del firewall, puerto, usuario, contraseña y valores de objetos deben mantenerse como variables o secretos, no codificados en requests, capturas o tickets. La colección no es un concepto de seguridad, pero ayuda a probar operaciones de lectura y escritura de forma más reproducible.

Una API accesible aún no demuestra que el cambio previsto sea técnicamente seguro. Antes de operaciones de escritura en producción debe funcionar primero una consulta de lectura inofensiva y después probarse un pequeño cambio controlado.

Acceso a la API y derechos de usuario

Una IP de origen por sí sola no es un concepto de seguridad completo. La restricción solo limita desde dónde es accesible la API. Además, debe estar claro con qué cuenta se realiza el acceso a la API y qué derechos tiene esa cuenta.

Para entornos productivos, se debe verificar:

¿Se utiliza una cuenta de servicio o API propia?
¿La cuenta solo tiene los permisos necesarios?
¿Está claramente documentado qué persona o equipo es responsable de la cuenta?
¿Se almacena la contraseña o secreto de manera segura?
¿Se elimina el acceso cuando la integración ya no se utiliza?
¿Son rastreables los cambios a través de registros de auditoría?

Las cuentas de administrador compartidas son problemáticas para los procesos de API. Si varios sistemas o personas utilizan la misma cuenta, la trazabilidad se debilita. Para los análisis de cambios, es relevante revisar los registros de auditoría de Sophos Firewall.

Para una cuenta API dedicada, un proceso restringido es mejor que copiar rápidamente un administrador completo. En la documentación de Sophos este bloque aparece como Allow API access to administrators: no solo se permite la fuente, también el administrador o el perfil debe tener el acceso adecuado.

Crear un perfil de administrador con los permisos necesarios en Profiles > Device access.
Crear un usuario administrador para el proceso API en Authentication > Users.
Asignar el perfil de administrador correspondiente.
Si el acceso solo se necesita temporalmente, limitar Access time.
Si es posible, restringir Login restriction for device access a las fuentes previstas.
Después permitir API access y Device Access para la fuente correspondiente.

Sophos soporta las APIs oficiales y los scripts de ejemplo sin modificar. Las integraciones, wrappers y automatizaciones propias siguen necesitando un responsable interno, pruebas y un concepto de rollback. “Funciona en el lab” no es suficiente para operaciones de escritura en producción.

MFA y usuarios API después de SFOS 22

La MFA es importante para accesos administrativos interactivos. Para procesos API y de automatización, sin embargo, hay que planificar conscientemente cómo debe funcionar la autenticación. Un script, herramienta de monitorización o sistema de integración no puede introducir sin más un código OTP si la cuenta usada exige MFA.

La lista Known Issues documenta un caso especial de SFOS 22: tras una actualización, los cambios de configuración basados en API pueden fallar para usuarios migrados si MFA está activa y no se entrega un one-time token. Los usuarios no migrados pueden comportarse de forma distinta en algunos casos. Para la operación, lo importante no es desactivar MFA en todas partes, sino separar correctamente las cuentas API.

Enfoque recomendado:

Usar una cuenta de servicio propia para procesos API.
Conceder a la cuenta solo los permisos necesarios.
Limitar además API access a IP Hosts fijos o redes de gestión.
Comprobar si MFA es técnica y operativamente razonable para esta cuenta.
Si MFA no es práctica para la cuenta API, controlar la cuenta de forma especialmente estricta mediante fuente, permisos, almacenamiento de secretos y audit trail.
Tras una actualización a SFOS 22, probar todos los procesos API con operaciones de lectura y escritura.

⚠️ Los usuarios API sin MFA no son una vía libre para permisos amplios. Si por motivos técnicos una cuenta API funciona sin MFA, la IP de origen, los permisos, el almacenamiento de contraseñas, la responsabilidad y la auditabilidad deben controlarse más estrictamente.

Este punto es especialmente importante en automatizaciones que no solo leen, sino que también cambian configuración.

Antes de cambios API en producción, comprobar al menos tres cosas:

Existe un backup de Sophos Firewall actual.
La cuenta API prevista puede ejecutar correctamente una consulta de lectura inofensiva.
En cambios masivos preparados con Sophos Firewall Config Studio, las llamadas API o curl generadas funcionan con la cuenta prevista.

Distinción con Device Access

El control de acceso a la API no es lo mismo que Device Access. Device Access controla servicios locales de firewall como WebAdmin, SSH, User Portal, VPN Portal, DNS o Ping. Las configuraciones de acceso a la API controlan el acceso a la interfaz de gestión de la API XML.

Sin embargo, ambos temas pertenecen al endurecimiento de la gestión. Cada capa limita una parte diferente de la superficie de ataque:

Configurar correctamente Device Access: servicios locales de firewall como WebAdmin, SSH, User Portal, VPN Portal, DNS o Ping
Control de acceso a la API: hosts IP que también pueden usar la API XML
Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access: Inicios de sesión interactivos para WebAdmin, VPN Portal y Remote Access
Administradores nombrados y roles claros: Trazabilidad y radio de daño de cuentas de administrador y servicio

Si una red de administración puede utilizar WebAdmin, SSH y API, esa red debe estar especialmente bien protegida. Un cliente comprometido en la red de gestión es de otro modo una entrada directa a la gestión del firewall.

Operación y revisión

El acceso a la API debe revisarse regularmente. Especialmente después de migraciones, cambios de proveedores, proyectos de automatización o actualizaciones de firewall, a menudo quedan fuentes antiguas.

Preguntas de revisión útiles:

¿Qué hosts IP pueden actualmente utilizar el acceso a la API?
¿Existen objetos con el prefijo apiconfig?
¿Son necesarios estos objetos?
¿Coinciden los nombres y descripciones con el propósito real?
¿Existen responsables documentados?
¿Se consideran los accesos a la API en un proceso de cambio o auditoría?
¿Existe una copia de seguridad actual antes de cambios importantes basados en API?

Antes de cambios basados en API, siempre debe haber una copia de seguridad. El artículo Crear o restaurar una copia de seguridad de Sophos Firewall describe en qué se debe prestar atención en cuanto a copia de seguridad, restauración y compatibilidad.

Errores típicos

API access permitido para toda una red de clientes: Cualquier cliente comprometido de esa red puede alcanzar la API.
Objetos apiconfig antiguos sin revisar: Excepciones heredadas migradas permanecen activas sin notarse.
La cuenta de servicio usa permisos de administrador completos: Un secreto comprometido tiene un radio de daño innecesariamente grande.
La automatización API usa un administrador con MFA obligatoria: El script o la herramienta pueden fallar en operaciones de escritura tras una actualización SFOS.
Puerto incorrecto en la herramienta: El puerto HTTPS de administración se cambió, pero la herramienta sigue usando el puerto antiguo.
Se espera lógica REST: La herramienta envía métodos REST en lugar de payload XML mediante HTTP POST a APIController.
IP temporal del proveedor sigue activa: El acceso externo sigue siendo posible durante más tiempo del previsto.
No hay documentación del propósito: Administradores posteriores no saben si la autorización sigue siendo necesaria.
Cambios API sin backup: Una automatización defectuosa es más difícil de revertir.

Solución de problemas

Si una herramienta no alcanza la API XML, se debe verificar de manera estructurada:

¿La IP de origen es correcta desde la perspectiva del firewall?
¿La fuente está permitida como host IP, rango de IP o red?
¿Se generó un objeto apiconfig después de una actualización, pero no se ajustó adecuadamente?
¿Device Access permite el acceso local WebAdmin/API desde esta zona?
¿La herramienta usa la dirección correcta del firewall y el puerto HTTPS de administración correcto?
¿Son correctos el nombre de usuario, contraseña o secreto?
¿La cuenta tiene los derechos necesarios?
¿La cuenta impone MFA, aunque la herramienta no puede proporcionar un token de un solo uso?
¿Existen efectos de enrutamiento, NAT o proxy entre la herramienta y el firewall?
¿Se eliminó el acceso intencionalmente mediante una medida de endurecimiento?
¿La prueba se realizó desde el sistema de origen correcto o solo desde el cliente de administración?

Si un cambio en la API tiene efectos inesperados, primero asegure la última copia de seguridad y luego revise el registro de auditoría, la comparación de Config Studio y los objetos de firewall afectados. En problemas de tráfico en vivo, el Log Viewer y el Packet Capture son más útiles que la propia API.

Lista de verificación

Antes de la activación:

Documentar el propósito del acceso a la API.
Determinar claramente el sistema de origen.
Crear un objeto de host IP con un nombre descriptivo.
Verificar la cuenta de servicio y los permisos.
Establecer conscientemente el comportamiento de MFA de la cuenta de API.
Establecer un proceso de copia de seguridad y reversión.
Definir un método de prueba sin fuga de secretos.

Durante la operación:

Permitir acceso a la API solo para fuentes definidas.
No permitir redes amplias de clientes, invitados o IoT.
Revisar objetos apiconfig después de actualizaciones.
Controlar accesos de proveedores en términos de tiempo y función.
Almacenar secretos de manera segura y renovarlos en caso de cambios de personal o herramientas.
Rotar los secretos si han acabado en el historial de shell, tickets o ubicaciones inseguras.
Probar operaciones de lectura y escritura de API después de actualizaciones de SFOS.

Durante la revisión:

Revisar regularmente las fuentes de API permitidas.
Eliminar hosts IP que ya no se necesiten.
Comparar cambios con el registro de auditoría y tickets de cambio.
Probar procesos de automatización después de actualizaciones de firmware.

FAQ

¿Qué es la API XML de Sophos Firewall?

La API XML es una interfaz de gestión de Sophos Firewall. Los usos típicos incluyen automatización, integraciones, monitoreo o consultas de configuración. La interfaz solo debe ser accesible desde fuentes de gestión o automatización definidas.

¿Dónde se configura el acceso a la API en SFOS 22?

Sophos ha movido las configuraciones de acceso a la API al área de Administration con SFOS 22. Allí se puede definir qué hosts IP reciben acceso a la API.

¿Qué significa el prefijo apiconfig?

Al actualizar a SFOS 22, el firewall convierte las direcciones IP de API permitidas anteriormente en objetos de host IP. Estos objetos migrados se nombran con el prefijo apiconfig y deben revisarse después de la actualización.

¿Es suficiente una restricción de IP de origen como protección de API?

No. La restricción de IP de origen reduce las fuentes accesibles, pero no reemplaza cuentas limpias, permisos adecuados, almacenamiento seguro de secretos, copias de seguridad y auditabilidad.

¿Debería un usuario de API usar MFA?

Para administradores interactivos, MFA es recomendable. En la automatización de API, se debe verificar si la herramienta puede soportar un token de un solo uso. Si no es práctico, se debe usar una cuenta de API dedicada con derechos mínimos, restricción de IP de origen estricta y auditoría limpia.

¿Debería mantenerse el acceso a la API activado permanentemente?

Solo si un proceso concreto necesita la API regularmente. Los accesos temporales de prueba o de proveedores deben eliminarse o desactivarse después de su finalización.