Configurar un acceso de soporte de Avanet en Sophos Firewall

Para un caso de soporte, Avanet puede necesitar acceso directo temporal a la consola WebAdmin de un Sophos Firewall. Este acceso solo es seguro si se limita a una fuente de soporte conocida, al servicio necesario y a un periodo claramente definido. Las autorizaciones globales de WAN para HTTPS y SSH permanecen desactivadas; el acceso se concede mediante una Local service ACL exception rule específica.

En muchos casos basta con compartir la pantalla o utilizar un acceso de partner existente y controlado. Solo tiene sentido crear un acceso WAN directo nuevo cuando Avanet deba realizar el análisis o los cambios de forma autónoma. SSH se añade únicamente si se necesita Device Console, Advanced Shell o acceder a archivos de registro.

Los fundamentos técnicos se explican en Device Access y Local Service ACL en Sophos Firewall. Antes de efectuar cambios también debe existir una copia de seguridad actual de Sophos Firewall.

Importante: El acceso de soporte proporciona acceso administrativo al firewall. El usuario, la regla ACL y la clave SSH deben desactivarse o eliminarse después del caso si no se ha acordado un acceso permanente.

Diagnostics > Support access no sustituye este procedimiento. Genera un Access ID temporal exclusivamente para Sophos Support, que obtiene acceso a WebAdmin y al shell sin credenciales de administrador. No se debe compartir ese ID con Avanet.

Definir el acceso y el periodo

Antes de configurar el acceso, se documenta en el ticket:

• qué trabajos puede realizar Avanet,
• si basta WebAdmin o también se necesita SSH,
• cuándo comienza y termina el acceso,
• qué fuente de soporte de Avanet se utilizará,
• quién autoriza el acceso y supervisa su retirada.

Avanet debe indicar en el ticket autenticado la IP pública de salida exacta o un FQDN destinado expresamente al soporte. La fuente no se deduce de un sitio web ni se adivina. Antes del cambio, se abre y prueba un acceso independiente por consola, LAN de gestión, VPN administrativa o Sophos Fusion (antes Sophos Central).

No debe añadirse una segunda cuenta permanente si ya existe un acceso de Avanet o de partner. En ese caso se revisan el perfil, MFA, la limitación de origen y el estado de la cuenta existente. Para realizar un análisis conjunto sin inicio de sesión directo, compartir la pantalla suele ser la opción de menor riesgo.

Configurar el usuario de WebAdmin

Configurar de forma segura administradores y perfiles en Sophos Firewall describe el proceso general para cuentas personales, perfiles, MFA y offboarding. Esta sección añade el caso específico de soporte, con un intervalo de tiempo, un origen de soporte y una retirada controlada.

Una cuenta local específica del caso, por ejemplo avanet-<ticket>, se destina exclusivamente a WebAdmin y permite atribuir mejor los cambios en el Audit Trail. SFOS guarda el nombre en minúsculas y no permite cambiarlo después.

1. Abrir Authentication > Users.
2. Seleccionar Add.
3. Introducir el nombre de usuario y el nombre para mostrar.
4. Establecer User type en Administrator.
5. Seleccionar un Profile adecuado.
6. Introducir una contraseña segura y exclusiva para este acceso, así como la dirección de correo electrónico.

Como Username puede usarse avanet-<ticket>, sustituyendo <ticket> por el número interno. Esta guía no publica contraseñas ni direcciones de soporte. El perfil Administrator concede acceso WebAdmin completo y solo se usa cuando es imprescindible. En otro caso, en Profiles > Device access se comienza con Read-only y se concede Read-write únicamente a los menús necesarios para los cambios autorizados.

En Administrator advanced settings hay disponibles dos limitaciones adicionales:

• Schedule for device access: solo permite iniciar sesión en la consola WebAdmin durante el horario seleccionado.
• Login restriction for device access: solo permite iniciar sesión desde direcciones IPv4 seleccionadas o desde un rango IPv4.

En Login restriction for device access > Selected nodes, se añade la IP fija de soporte confirmada en el ticket. Local Service ACL limita el acceso a la consola y esta segunda medida limita el inicio de sesión de la cuenta. Si la ACL usa un FQDN, este campo sigue necesitando la IPv4 confirmada actualmente. Guardar con Save. El horario solo restringe el inicio de sesión de esta cuenta; no desactiva automáticamente la regla ACL ni SSH.

Probar previamente la contraseña y MFA

La contraseña se transmite por un canal seguro y no se incluye en correos ni tickets. En Authentication > Multi-factor authentication, se selecciona Specific users and groups para OTP, se añade la cuenta del caso y se activa Web admin console en Require MFA for. El secreto, el código QR y los códigos de un solo uso no deben figurar en el ticket. Si MFA no está disponible técnicamente, se utiliza pantalla compartida o VPN en vez de omitirla. Véase MFA para administradores.

Limitar la fuente de soporte y Local Service ACL

Crear el objeto de origen confirmado en el ticket

Para una ventana breve, un host IP con únicamente la dirección pública confirmada ofrece el alcance mínimo. Si el ticket designa expresamente un FQDN, Local Service ACL también admite un host FQDN y confía en todas las direcciones resueltas hasta que caduque el TTL de DNS. No admite FQDN comodín.

1. Para una IP fija, abrir Hosts and services > IP host, seleccionar Add y guardar la dirección confirmada como un único host IPv4.
2. Solo para un FQDN confirmado, abrir Hosts and services > FQDN host y seleccionar Add.
3. Introducir un Name específico del caso y copiar en FQDN el valor exacto del ticket.
4. Guardar con Save, volver a abrir el objeto y comprobarlo.

Para un FQDN se comparan todas las direcciones resueltas con el ticket. Una dirección inesperada o no confirmada obliga a detenerse: se usa la única IP confirmada o se solicita aclaración a Avanet.

Crear una Local Service ACL Exception Rule

HTTPS y SSH son servicios locales del firewall. Las reglas de firewall normales no controlan este tráfico. Por este motivo, el acceso se configura en Administration > Device access.

1. Abrir Administration > Device access.
2. En la sección Local service ACL, comprobar que HTTPS y SSH no estén activados globalmente para WAN.
3. Desplazarse hasta la sección Local service ACL exception rule y seleccionar Add.
4. Crear la regla con los siguientes valores.

• Rule name: Avanet-Support
• Rule position: Top
• Description: número de ticket, finalidad y fecha de finalización prevista
• IP version: IPv4
• Source zone: WAN
• Source Network / Host: exactamente el objeto IP o FQDN confirmado
• Destination host: dirección pública del firewall o Any si debe ser accesible a través de varias direcciones WAN válidas
• Services: HTTPS; SSH solo si se ha confirmado que es necesario; Ping/Ping6 únicamente para un diagnóstico concreto
• Action: Accept

Guardar con Save. La posición Top garantiza que esta autorización específica se evalúe antes que una regla de denegación que se solape. Aun así, deben revisarse las Exception Rules existentes: una regla Accept más amplia situada por encima o una zona de origen incorrecta puede alterar el modelo de seguridad previsto.

No utilizar: Any ni 0.0.0.0 como Source. Sophos impide por un buen motivo habilitar globalmente la consola WebAdmin desde WAN. Tampoco debe activarse la casilla WAN para HTTPS o SSH en este procedimiento.

Añadir SSH solo cuando sea necesario

SSH ofrece acceso a Device Console y Advanced Shell, por lo que su alcance es mucho mayor que el de un perfil restringido de WebAdmin. Por este motivo, en muchos casos de soporte Services se limita a HTTPS.

El usuario avanet no puede utilizarse para SSH. Sophos Firewall solo acepta el usuario predeterminado admin para CLI. Por tanto, la clave pública no se guarda en el usuario avanet, sino globalmente en Public key authentication for admin.

1. Abrir Administration.
2. Seleccionar Device access.
3. Desplazarse hasta la sección Public key authentication for admin.
4. Activar Enable authentication.
5. Pegar en Authorized keys la clave pública confirmada para el caso actual y añadirla con el símbolo más.
6. Seleccionar Apply.

Solo el administrador predeterminado puede añadir o eliminar claves SSH; Apply no aparece cuando se utiliza un administrador personalizado. Sophos admite claves RSA de 2048 bits o más y determinadas claves DSA y ECDSA, pero no ED25519. Para una clave de soporte nueva debe utilizarse un algoritmo moderno, suficientemente robusto y compatible con el cliente SSH empleado.

Una clave pública tiene, por ejemplo, esta estructura:

ssh-rsa <base64-public-key> avanet-support-<ticket>

La clave privada permanece en poder del técnico de soporte y nunca se guarda en el firewall. Al finalizar el caso de soporte, se elimina la clave pública específica del caso y se retira SSH de la Exception Rule, salvo que se haya acordado un acceso permanente. El procedimiento práctico de inicio de sesión se explica en Conectar Sophos Firewall mediante SSH.

Probar el acceso y localizar errores

Un inicio de sesión correcto desde la fuente permitida no basta para validar la configuración. También debe comprobarse que el acceso siga bloqueado desde otra fuente de Internet.

1. Abrir WebAdmin desde la fuente de soporte de Avanet acordada y a través del puerto de administración configurado. El puerto predeterminado es TCP 4444, pero puede haberse cambiado en Administration > Admin and user settings.
2. Iniciar sesión con avanet y comprobar que el perfil seleccionado permite acceder a los menús necesarios.
3. Utilizar una segunda fuente de Internet no autorizada. La consola WebAdmin no debe ser accesible desde ella.
4. Si se ha habilitado SSH, probar el inicio de sesión como admin con la clave privada específica del caso. Para esta prueba no se necesita SSH mediante contraseña.
5. Comprobar los eventos de autenticación en Log viewer. Los cambios de configuración también se revisan en el Audit Trail.
6. Documentar en el ticket el resultado de las pruebas y la hora de finalización del acceso.

Si WebAdmin no es accesible

La comprobación comienza en la fuente y avanza hasta el firewall:

• ¿Coincide la IP de salida real con el objeto de origen y, para un FQDN, con su resolución DNS actual?
• ¿El acceso llega realmente desde la zona seleccionada en Source zone?
• ¿La dirección WAN utilizada coincide con Destination host?
• ¿La Exception Rule está en Top e incluye HTTPS?
• ¿Se está utilizando el puerto correcto de WebAdmin?
• ¿Un router del proveedor, un dispositivo NAT situado delante o una ACL upstream bloquean el acceso?
• ¿Login restriction for device access permite la conexión TCP, pero impide el inicio de sesión del usuario?

Para resolver problemas no se activan las casillas WAN globales de HTTPS o SSH. Si la Exception Rule es correcta, no son necesarias para este acceso específico.

Si falla el inicio de sesión

Si la consola es accesible, pero no es posible iniciar sesión, se revisan el estado del usuario, la contraseña, MFA, el perfil, Schedule for device access, Login restriction for device access y los ajustes globales de bloqueo de inicio de sesión en Administration > Admin and user settings. Después de varios intentos fallidos, Sophos Firewall puede bloquear temporalmente la IP de origen para todos los servicios de inicio de sesión.

Retirar el acceso de forma controlada

Una vez finalizado el caso de soporte, se revisan por separado los cambios acordados y el propio acceso:

1. Comprobar en Audit Trail qué cambios de configuración se realizaron con avanet.
2. Para cambios importantes en el conjunto de reglas, Sophos Firewall Config Studio puede ayudar a comparar el antes y el después.
3. Desactivar o eliminar primero la Local Service ACL Exception Rule para cerrar la ruta externa.
4. Comprobar desde la fuente anterior que WebAdmin y SSH ya no sean accesibles y que el acceso de gestión independiente siga funcionando.
5. Eliminar solo la clave SSH del caso; desactivar Enable authentication únicamente si ninguna otra clave depende de ello.
6. Desactivar o eliminar la cuenta del caso y su token MFA, salvo que se haya aprobado expresamente el acceso permanente.
7. Una segunda persona compara ACL, cuenta, claves, Audit Trail y ticket con el estado inicial.

Un acceso de partner que se conserve de forma deliberada sigue necesitando MFA, una fuente estrictamente limitada, una persona responsable y una revisión periódica. Un ticket inactivo no justifica mantener abierto de forma permanente el acceso de administración.

Preguntas frecuentes