Conectar Sophos Firewall mediante SSH

Para muchas tareas de soporte y solución de problemas, necesita acceso al Sophos Firewall a través de SSH. Estos incluyen, por ejemplo, análisis de registros, reinicios de servicios, comandos de diagnóstico especiales o trabajo en el Advanced Shell.

Pero SSH también es un acceso de gestión de alto riesgo. Por lo tanto, el acceso solo debe permitirse desde redes de administración confiables, a través de una regla de excepción específica Local Service ACL o mediante un acceso de soporte claramente definido. Para el fortalecimiento general de los servicios de firewall locales, también es adecuado Configurar Device Access correctamente.

Requisitos

Para una conexión del SSH al Sophos Firewall necesita:

• Acceso administrativo al Sophos Firewall.
• La dirección IP o nombre DNS del firewall.
• Acceso al usuario admin.
• Una contraseña del administrador predeterminado cambiada y documentada de forma segura; la contraseña de fábrica no debe mantenerse en producción.
• Una fuente de administración confiable, por ejemplo, red de administración, VPN o IP de administración fija.
• En macOS o Linux: la aplicación Terminal preinstalada con SSH.
• En Windows: Terminal de Windows con OpenSSH o PuTTY.
• Acceso SSH permitido en Administration > Device access o mediante una Local service ACL exception rule.
• Para cambios planificados en el Advanced Shell: copia de seguridad, ventana de mantenimiento y ruta de reversión clara.

⚠️ SSH solo debe permitirse desde redes confiables. Para entornos productivos, es mejor restringir el acceso a una IP de administración o a una red de administración en lugar de publicar SSH de manera general.

Definir para qué se necesita SSH

No todos los análisis necesitan el Advanced Shell. Antes de iniciar sesión, debe quedar claro qué consola se requiere y qué tan grave es la intervención.

• Enrutamiento, DNS, Ping, comandos simples del sistema: Device Console. Sophos CLI, menos riesgoso que el Advanced Shell.
• Información detallada del sistema, bases de datos o servicios del sistema: puede ser necesario Advanced Shell. Sin instrucciones fiables y específicas de Sophos para el caso, limítese a comprobaciones de solo lectura y no modifique ni elimine nada.
• Verificar el estado del servicio o depurar: Advanced Shell. Solo active específicamente la depuración y desactívela nuevamente.
• Ejecutar comandos desconocidos: Verifique primero o abra un caso de soporte. No intentar en el sistema de producción.

La distinción es importante porque Device Console y Advanced Shell utilizan una sintaxis diferente. Muchos errores ocurren simplemente porque se ingresa un comando correcto en el lugar incorrecto. Hay disponible una descripción general más amplia en Sophos Firewall Solución de problemas: Services y registros.

Permitir el acceso SSH al firewall

Para que sea posible una conexión, el Sophos Firewall debe permitir SSH en la zona apropiada o mediante una regla de excepción Local Service ACL.

1. Inicie sesión en el administrador web del Sophos Firewall.
2. Abra Administration.
3. Seleccione Device access.
4. Verifique si SSH está permitido para la zona deseada.

Para redes de administración interna, SSH se puede activar directamente para la zona apropiada, por ejemplo para LAN. Si el acceso se va a restringir de manera más específica, tiene sentido una Regla de excepción de ACL de servicio local.

Device Access controla el acceso al propio firewall. Esto no es lo mismo que una regla de firewall normal que permite tráfico a través del firewall. Si SSH en Device Access está habilitado de forma demasiado amplia, un cliente puede llegar al servicio SSH local del firewall aunque una regla LAN-to-WAN clásica esté configurada correctamente.

También es importante distinguir SSH de la CLI Console basada en WebAdmin: un cliente SSH necesita acceso SSH por TCP 22. Si se abre la CLI Console desde el menú de WebAdmin, en cambio debe estar permitido HTTPS para la zona correspondiente.

Antes de realizar cambios, anote las zonas en las que SSH está activado y las excepciones SSH existentes. Así podrá recuperar el estado inicial sin eliminar otro permiso intencionado.

En Local service ACL exception rule, haga clic en Add y defina los valores de la forma más restrictiva posible:

• Name: por ejemplo, SSH-desde-red-admin; valor libre e inequívoco
• Rule position: la posición de la excepción en la Local Service ACL
• Description: finalidad, equipo responsable y fecha de finalización del acceso temporal
• IP version: IPv4 o IPv6 según la fuente administrativa y la dirección de destino
• Source zone: la zona desde la que se realiza la administración
• Source Network / Host: la IP del administrador o la red de administración
• Destination host: la IP del firewall o la interfaz que se administrará, si el acceso también puede limitarse a una dirección de destino concreta
• Services: SSH
• Action: Accept

Guarde con Save. Para un único sistema de administración, Source Network / Host puede ser un objeto de host con 192.0.2.10. Es una dirección de documentación que debe sustituir por la IP administrativa real, preferiblemente fija. Destination host limita además la IP del firewall por la que se accede al servicio; no incluya todas las interfaces sin un motivo operativo.

Abra una sesión SSH nueva desde el origen administrativo previsto. La prueba es correcta cuando aparece el menú de la consola. A continuación, pruebe desde una red no autorizada deliberadamente y confirme que no se establece ninguna sesión. Si el resultado no es el esperado, mantenga abierta la sesión WebAdmin y revise la IP de origen, Source zone, IP version, Destination host, la posición de la regla y los filtros anteriores.

Si el acceso era temporal, elimine únicamente esta excepción en Administration > Device access > Local service ACL exception rule y confirme con OK. Si modificó una casilla de zona, restaure solo su estado anotado y haga clic en Apply. A continuación, pruebe desde el mismo origen y compruebe que SSH vuelve a estar accesible o bloqueado exactamente como antes del cambio. Así se valida el estado inicial sin presuponer que el inicio de sesión siempre deba completarse o fallar.

No se debe poder acceder a SSH sin control desde Internet. Si es necesario el acceso externo, solo se debe permitir a través de una IP de origen claramente definida, VPN o acceso de soporte dedicado.

Diagnostics > Support access es un mecanismo separado. No expone simplemente SSH desde internet, sino que permite a Sophos Support un acceso temporal mediante un canal de soporte iniciado por el firewall. Este acceso también debe limitarse en el tiempo y desactivarse después del caso de soporte.

Al activar Support access se selecciona una duración; después, el firewall genera una access ID única para Sophos Support. Sophos Support puede usarla para acceder a WebAdmin y a la shell sin credenciales administrativas normales. El firewall establece por sí mismo la conexión con Sophos Support por TCP 22; operativamente, esto es distinto de permitir SSH entrante desde la WAN.

Para hacerlo desde WebAdmin, abrir Diagnostics > Support access, activar Support access y confirmar con OK. Después, seleccionar la duración necesaria para el caso de soporte concreto, pulsar Apply y confirmar de nuevo con OK. El firewall establece una conexión de control segura con su proxy de acceso; la access ID generada se encuentra en Access status y se comunica exclusivamente a Sophos Support mediante el canal de soporte acordado.

Controlar Support access desde Device Console

SFOS 22 también puede activar el canal de soporte en 4. Device Console. Tras una activación correcta, el comando muestra la access ID y la duración del acceso:

set support_access enable

El comando de estado de solo lectura, ejecutado en la misma Device Console, indica si el canal está activo y, en ese caso, muestra la access ID y la duración:

show support_access

La access ID y la duración solo se comunican en el caso de soporte correspondiente. No se copian en documentación general, chats ni almacenes de contraseñas. Después del análisis, el canal se desactiva independientemente del tiempo restante:

set support_access disable

Después se comprueba en Diagnostics > Support access que el acceso ya no está activo. disable no modifica la configuración SSH normal de Device Access ni las Local Service ACL Exception Rules; los permisos temporales de administrador y SSH se eliminan por separado.

Si hay otro router o filtro de salida delante del firewall, debe permitir TCP 22 hacia *.apu.sophos.com. Para ello no se crea ninguna regla WAN entrante en Sophos Firewall. Las sesiones de soporte inactivas se cierran después de 15 minutos; la duración total seleccionada y la posibilidad de desactivar Support access manualmente son independientes de ese tiempo de espera.

Comprobar servicios y puertos salientes de Sophos Firewall ordena los demás destinos del fabricante para updates, licencias, RED, Central, reporting y backups.

Registrar una clave pública para admin

Para el acceso a SSH, la autenticación de clave pública es el método preferido. En Sophos Firewall, la clave pública del usuario admin se puede almacenar en Administration > Device access. El inicio de sesión con contraseña puede ser necesario para emergencias, pero no debería seguir siendo el acceso predeterminado más conveniente.

⚠️ Un inicio de sesión SSH en Sophos Firewall solo es posible con el usuario admin. Otros usuarios de WebAdmin no pueden iniciar sesión a través de SSH.

Importante: Solo el administrador predeterminado puede cambiar la autenticación de clave pública para SSH, es decir, agregar o eliminar claves. Para las operaciones, esto significa: Los cambios clave pertenecen a un proceso de administración documentado y no deben tratarse como un atajo de soporte espontáneo.

El administrador predeterminado no es una cuenta de rol normal que se pueda sustituir sin más. Sophos indica que esta cuenta no se puede cambiar de nombre ni eliminar. Por eso, la contraseña del administrador predeterminado, la información de MFA o recuperación para inicios de sesión administrativos interactivos y las claves públicas SSH almacenadas deben gestionarse juntas en el proceso operativo de administración. Una clave pública no sustituye la gestión adecuada de esta cuenta.

Los administradores con nombre de WebAdmin se gestionan por separado y no pueden iniciar sesión por SSH con su propio nombre de usuario. Gestionar administradores locales y perfiles de Device Access según el principio de privilegios mínimos explica el ciclo de vida y los permisos de estas cuentas.

Antes de registrar la clave pública en el firewall, genere en su propio cliente de administración un par de claves pública y privada correspondientes mediante una herramienta de claves SSH. Puede reutilizar un par de claves existente, adecuado y cuyas claves se correspondan entre sí. Para el tipo y la longitud de la clave, siga las indicaciones de la siguiente sección sobre los tipos de claves SSH compatibles. Guarde y proteja la clave privada exclusivamente en el cliente de administración; nunca la comparta ni la suba al firewall. Para los siguientes pasos, copie solo la clave pública.

La clave pública se agrega en el área Public key authentication for admin:

1. Abra Administration.
2. Seleccione Device access.
3. Desplácese hasta el área Public key authentication for admin.
4. Active Enable authentication.
5. Agregue la clave pública en Authorized keys.
6. Guarde con Apply.

Mantenga abierta la sesión WebAdmin o SSH existente mientras prueba la clave nueva en una segunda sesión SSH. No elimine una clave antigua ni cambie el acceso alternativo por contraseña hasta que aparezca el menú de la consola en esa segunda sesión. Si la prueba falla, conservará el acceso anterior: compruebe el tipo de clave, la clave pública registrada, la clave privada correspondiente y el origen permitido; después elimine solo la entrada nueva incorrecta.

La clave privada siempre permanece en el cliente administrador y no se puede compartir. Sólo la clave pública se almacena en el firewall.

Si varios administradores usan SSH, no se debe compartir la misma clave privada. Es mejor tener clientes de administración separados, claves públicas documentadas y una revisión de qué claves aún son necesarias. Después de cambios de personal o proveedores de servicios, se debe verificar el área Authorized keys.

Tipos de claves SSH compatibles

No todos los tipos de llaves SSH modernos son igualmente adecuados para Sophos Firewall. Antes de implementar, debe verificar si el tipo de clave es compatible.

• RSA: Usar al menos 2048 bits.
• DSA: Al menos 2048 bits, si es necesario por motivos de compatibilidad.
• ECDSA: Compatible; ED25519 no se acepta para este propósito.
• ED25519: Para SSH Public Key Authentication no utilizar en Sophos Firewall.

Para el acceso de administrador nuevo, una clave RSA o ECDSA compatible administrada adecuadamente suele ser más pragmática que un tipo de clave moderna que el firewall o una herramienta SSH más antigua no acepta.

Conectarse desde macOS o Linux

Por lo general, ya hay un cliente SSH presente en macOS y Linux. La conexión se establece en el terminal.

Ejemplo:

ssh admin@192.0.2.1

192.0.2.1 se reemplaza por la dirección IP o nombre DNS de su propio Sophos Firewall.

Cuando se establece la conexión por primera vez, el cliente SSH pregunta si se debe aceptar la huella digital del sistema de destino. Esta huella digital debe verificarse y luego confirmarse. Si aparece una advertencia sobre una clave de host modificada después de una nueva imagen, un reemplazo de hardware o un cambio de IP, la nueva huella digital no debe aceptarse ciegamente. Primero verifique si el mismo firewall realmente ha sido reemplazado, reinstalado o movido a una nueva IP. Sólo entonces se podrá limpiar la entrada anterior en ~/.ssh/known_hosts y aceptar la nueva huella digital.

Dependiendo de la configuración, a continuación se solicita la contraseña del usuario admin o se realiza el inicio de sesión mediante la clave SSH almacenada.

Si se debe utilizar una clave privada específica:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

Para el acceso recurrente, se debe documentar la ruta clave, la IP de origen permitida y el propósito. La entrada known_hosts no debe copiarse en tickets o historiales de chat; Para las advertencias de claves de host, el historial de cambios es más importante que una solución rápida.

Conectarse con PuTTY

En Windows, puede usar Windows Terminal con OpenSSH o usar PuTTY.

Con Windows Terminal, establecer una conexión funciona de manera similar a macOS o Linux:

ssh admin@192.0.2.1

Para PuTTY:

1. Abra PuTTY.
2. Ingrese la dirección IP o el nombre DNS del Sophos Firewall en Host Name.
3. Establezca Port en 22.
4. Establezca Connection type en SSH.
5. Conéctese con Open.
6. Verifique y confirme la huella digital SSH.
7. Inicie sesión como usuario admin y use la contraseña o la clave SSH según la configuración.

Después de iniciar sesión, aparece el menú de la consola Sophos Firewall.

Si se utiliza PuTTY con una clave privada, la clave debe coincidir con la clave pública almacenada en el firewall. Después de un cambio de personal o de proveedor de servicios, no sólo se debe cambiar la contraseña; Las claves públicas antiguas también deben eliminarse de Authorized keys.

Abrir Device Console o Advanced Shell

Después de iniciar sesión correctamente a través de SSH, el firewall muestra un menú de consola. La opción que elijas dependerá de lo que quieras hacer.

Para muchos comandos SFOS utiliza:

4. Device Console

Para tareas más profundas de Linux o sistemas de archivos, utilice Advanced Shell a través de:

5. Device Management
3. Advanced Shell

El Advanced Shell ofrece un acceso muy amplio al sistema. Los comandos sólo deben ejecutarse allí si está claro lo que hacen.

Según Sophos, los cambios de configuración realizados directamente en Advanced Shell, por ejemplo en interfaces, reglas o políticas, no persisten después de reiniciar ni se incluyen en las copias de seguridad. Por tanto, no es una vía normal de configuración. Los archivos de /tmp/ también se eliminan al reiniciar.

• Device Console: ping, dnslookup, traceroute, show, Opciones de enrutamiento u sistema.
• Advanced Shell: información detallada del sistema, bases de datos, servicios del sistema y diagnósticos específicos indicados por Sophos Support.

Para el análisis de registros, nombres de servicios y patrones de error típicos, Solución de problemas Sophos Firewall: Services y registros es un mejor punto de partida que memorizar comandos individuales.

Cerrar la conexión

Cuando se complete el trabajo, la sesión SSH debería cerrarse limpiamente:

exit

Si se encuentra en un submenú, puede que sea necesario volver primero al menú principal y luego finalizar la sesión.

Sophos Firewall cierra las sesiones SSH inactivas después de 15 minutos. Esto no sustituye un cierre de sesión limpio: las sesiones abiertas, los modos de depuración y las reglas de acceso temporales deben cerrarse o retirarse de forma consciente.

Si SSH solo se activó temporalmente para un caso de soporte, la versión debe eliminarse o desactivarse. Esto es especialmente cierto para las excepciones de ACL que provienen de direcciones IP de origen externo o del acceso de un proveedor de servicios.

Después de intervenciones profundas, también se debe comprobar lo siguiente:

• ¿La depuración está deshabilitada nuevamente?
• ¿Se ha eliminado o deshabilitado una regla de excepción de ACL temporal?
• ¿No se dejaron archivos temporales, volcados de soporte o grabaciones innecesarias en el firewall?
• ¿Están documentados los extractos del registro, la hora, el comando y el resultado en el ticket o cambio?
• ¿Se usó la clave SSH solo para acceso programado de administrador o soporte?

Problemas comunes

Se rechaza la conexión

Si se rechaza la conexión, normalmente no se permite SSH en el firewall para la zona o fuente seleccionada. En este caso, se debe marcar Administration > Device access. Además, verifique si una regla de excepción de ACL permite la fuente o si se eliminó deliberadamente una versión más amplia de acceso al dispositivo.

Se agota el tiempo de conexión

Un tiempo de espera a menudo indica que no se puede acceder al firewall a través de la dirección IP seleccionada, que falta una ruta o que un firewall ascendente está bloqueando el acceso.

Si un firewall que todavía no se ha configurado por completo mantiene la contraseña predeterminada de fábrica, SFOS descarta intencionadamente las conexiones SSH desde la zona WAN sin mostrar un mensaje de error. Es una medida de protección. Primero se cambia la contraseña por una vía de administración local autorizada; Device Access o la ACL no se amplían como método alternativo.

No hay acceso de red al firewall

Si no se puede acceder ni a WebAdmin ni a SSH, no conviene abrir rápidamente accesos adicionales desde WAN o desde otras zonas. La vía de respaldo más limpia es el acceso local a la consola del dispositivo, por ejemplo mediante un cable de consola o, en modelos compatibles, mediante micro USB. Esto es especialmente importante cuando Device Access, el enrutamiento o las zonas de interfaz se configuraron incorrectamente.

El inicio de sesión falla

Si el inicio de sesión falla, se debe verificar el usuario admin, la contraseña o la clave SSH y las redes de origen permitidas. Los mensajes típicos como Permission denied (publickey,password) indican una contraseña incorrecta, una clave privada incorrecta o falta una configuración de clave pública.

Si realmente se ha perdido la contraseña del admin predeterminado, Restablecer la contraseña admin de Sophos Firewall explica la recuperación serie para appliances físicos y las limitaciones independientes de los firewalls virtuales y cloud.

Si falla el inicio de sesión con clave pública, verifique además el tipo de clave, la longitud de la clave, la clave privada incorrecta, el formato de clave PuTTY y la entrada en Authorized keys. Un servicio SSH correctamente permitido no ayuda si la clave no coincide con la clave pública almacenada.

Aparece una advertencia de clave de host

Una advertencia de clave de host puede ser inofensiva si se ha reinstalado o reemplazado un firewall. La advertencia también puede indicar un sistema de destino incorrecto o una confusión de direcciones IP. Por lo tanto, primero verifique el firewall, la dirección IP, el DNS y el historial de cambios. Sólo entonces se debe eliminar la antigua entrada known_hosts.

Se abrió una consola incorrecta

Si no se reconoce un comando Sophos CLI documentado, puede que esté abierta la consola equivocada o que la sintaxis esté incompleta. En Device Console, Tab enumera los comandos y argumentos disponibles; ? muestra sus descripciones. No introduzca allí instrucciones de shell Linux ni pruebe comandos no documentados en Advanced Shell.

Lista de verificación operativa

• Permitir únicamente SSH de fuentes administrativas confiables.
• Cambiar la contraseña predeterminada de fábrica antes de utilizar SSH en producción.
• Si es posible, utilice la regla de excepción Local Service ACL en lugar de la liberación de zona amplia.
• Prefiera Public Key Authentication a admin.
• Documentar por separado la contraseña del administrador predeterminado, la información de MFA o recuperación y las claves SSH.
• Documentar el tipo de clave admitido y la longitud de la clave.
• No compartir claves privadas.
• Verifique la huella digital SSH en el primer inicio de sesión.
• Maneje conscientemente las advertencias de la clave del host después de una nueva imagen o reemplazo de hardware.
• No confundir Device Console y Advanced Shell.
• Realizar cambios en el Advanced Shell únicamente con un propósito claro.
• Eliminar accesos SSH temporales después de casos de soporte.
• Eliminar claves públicas antiguas después de cambiar de personal o proveedores de servicios.

Preguntas frecuentes