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 Advanced Shell: copia de seguridad, ventana de mantenimiento y un plan claramente definido para revertir los cambios si surgen problemas.

⚠️ 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.
• 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 WebAdmin de Sophos Firewall.
2. Abra Administration.
3. Seleccione Device access.
4. En Local service ACL, compruebe si SSH está permitido para la zona de administración de confianza prevista. Anote el estado actual antes de realizar cambios.
5. Si desea permitir deliberadamente el acceso desde toda esa zona, active SSH solo para esa zona y guarde con Apply. No es necesario volver a modificar los ajustes que ya sean adecuados.

Para una red interna de administración de confianza, LAN puede ser la zona adecuada, por ejemplo. Sin embargo, el permiso de zona no se limita a un único equipo de administración. Para restringir el acceso a una IP de administración o a una red de gestión, utilice en su lugar la Local service ACL exception rule descrita más abajo; permitir el acceso desde toda la zona no es un paso adicional obligatorio. No active SSH de forma general para WAN.

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.

La consola CLI basada en web es una vía de acceso distinta de un cliente SSH: el cliente SSH utiliza TCP 22, mientras que la consola del navegador utiliza el acceso HTTPS a WebAdmin. Para acceder desde el navegador, abra Administration > Device access, compruebe en Local service ACL el permiso HTTPS para la zona de administración de confianza prevista y, si es necesario, actívelo con Apply. A continuación, abra el menú desplegable del administrador situado en la esquina superior derecha de WebAdmin y seleccione Console. Esta vía de acceso desde el navegador no requiere un permiso SSH. Tampoco se debe habilitar HTTPS de forma general para WAN; se mantienen las restricciones de origen existentes.

La elección de la cuenta está sujeta a la limitación documentada para SFOS 22 y 23: las instrucciones de PuTTY exigen expresamente admin y excluyen otros nombres de usuario, incluso para el inicio de sesión con contraseña. Aunque la descripción del perfil concede al perfil Administrator acceso completo a la CLI y permite asignarlo a otros administradores, no especifica ningún método de transporte para ese acceso. Por tanto, un permiso asociado a un rol no garantiza que una cuenta nominativa pueda iniciar sesión mediante SSH a través de la red. Tampoco se confirma aquí un acceso general a la consola desde el navegador para todas las cuentas nominativas. Antes de utilizar una vía de acceso como alternativa de respaldo, compruebe el acceso concreto con la cuenta prevista en la versión de SFOS instalada. Si no aparece Console o se rechaza el acceso, mantenga abiertas las sesiones existentes que funcionen; compruebe la cuenta, el perfil y la vía de acceso y, si es necesario, aclare el caso con Sophos Support en lugar de ampliar los permisos de WAN o ACL. Los siguientes pasos de SSH siguen utilizando admin; la gestión exclusiva de las SSH Public Keys por parte del administrador predeterminado es un permiso independiente.

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 un Access ID único para Sophos Support. Este Access ID sigue siendo válido durante el periodo seleccionado; Support access se puede desactivar en cualquier momento antes de que finalice. Sophos Support puede así acceder a WebAdmin y a la shell sin necesitar las credenciales administrativas habituales. El propio firewall establece las conexiones de soporte salientes tanto para HTTPS como para SSH a través de TCP 22; desde el punto de vista operativo, esto es distinto de permitir SSH entrante desde la WAN.

Antes de cualquier activación, también desde WebAdmin, compruebe primero el canal de soporte existente en 4. Device Console mediante el comando de solo lectura:

show support_access

El comando indica si Support access está activo y, cuando el acceso está activo, muestra también el Access ID y la duración. Documente el estado inicial, así como la duración y el Access ID que se muestren, exclusivamente en el caso de soporte correspondiente y autenticado. La información mostrada por sí sola no demuestra a qué caso pertenece el canal; aclare esa vinculación y el consentimiento para el acceso con el equipo responsable y Sophos Support.

Si ya hay un canal activo para otro caso o no está claro quién es responsable de él, deténgase y coordine los siguientes pasos sin volver a activar, sustituir ni desactivar el canal. Tampoco se vuelve a activar un canal que ya esté activo y autorizado para el mismo caso; su uso posterior y su cierre se coordinan dentro del caso existente. Inicie el procedimiento independiente de activación, análisis y desactivación únicamente si se ha confirmado que el estado inicial es inactivo y se dispone de consentimiento explícito para este caso de soporte. Este requisito se aplica a las dos vías de acceso siguientes.

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 permite activar el canal de soporte en 4. Device Console. Inmediatamente antes de ejecutar el comando de escritura, repita allí la comprobación descrita anteriormente con show support_access. Active el canal únicamente si se ha confirmado que está inactivo y se dispone del consentimiento para este caso:

set support_access enable

Tras una activación correcta, el comando muestra el Access ID y la duración del acceso. Compare la duración que realmente se muestre con el consentimiento otorgado para el caso; la sintaxis documentada de la CLI no contiene ningún parámetro para establecer una duración. Si necesita una duración concreta, utilice la vía de WebAdmin descrita más arriba después de realizar la misma comprobación previa. Comunique el Access ID y la duración únicamente en el caso de soporte correspondiente y autenticado; no los copie en documentación general, chats ni almacenes de contraseñas.

Una vez finalizado el análisis, independientemente del tiempo restante, desactive exclusivamente su propio canal, establecido con consentimiento para este caso. Antes de hacerlo, compruebe con show support_access y el Access ID documentado que sigue siendo el mismo canal. Si ya está inactivo, no ejecute el comando de escritura; si el ID es distinto o no está claro quién es responsable del canal, deténgase y coordine los siguientes pasos en lugar de desactivar un canal que podría pertenecer a otro caso:

set support_access disable

A continuación, compruebe en Diagnostics > Support access o con show support_access que su propio canal ya no esté activo. disable no modifica ni la configuración SSH normal en Device Access ni las Local Service ACL Exception Rules; por tanto, revierta por separado los permisos temporales de administración y SSH al estado anotado previamente, limitándose estrictamente a los cambios que haya realizado.

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.

Support access mediante XML API: aclarar antes de realizar operaciones de escritura

La ayuda de la XML API para SFOS 22 y 23 denomina al objeto SupportAccess, pero contiene dos contradicciones: En el ejemplo XML, la etiqueta de duración se llama GrantAccessFor, mientras que en la tabla de parámetros figura como GrantAccessForr. Para ConfigOption, la tabla indica el valor predeterminado ON, pero solo permite Enable y Disable. De ello no se puede deducir ni que ON sea un valor válido para una solicitud ni que el acceso de soporte esté activo de forma predeterminada. Antes de una operación de escritura, confirmar la grafía válida de la etiqueta para el build instalado en API help o con Sophos Support.

La tabla identifica ambos campos como valores escalares opcionales e indica los periodos 1 day, 2 days, 1 week, 2 weeks, 1 month y 2 months. Esto no aclara qué ocurre realmente al omitir un campo. Por tanto, antes de realizar un cambio automatizado, compruebe la ayuda de la API específica del objeto en la compilación de SFOS instalada y aclare con Sophos Support cualquier duda pendiente sobre la etiqueta, los valores o el comportamiento al omitir campos. Mientras no se resuelva la contradicción, detenga las operaciones de escritura XML; no invente un payload ni pruebe ambas grafías en el sistema de producción. Para un caso de soporte aprobado, la vía de WebAdmin descrita más arriba sigue siendo la alternativa, sin ampliar los permisos de WAN o ACL.

La referencia indica para esta operación 200 con Operation Successful. y 500 con Operation Fail.. Compruebe la respuesta concreta del objeto en lugar de repetir a ciegas una operación de escritura fallida o de resultado incierto. Tras un cambio confirmado, compruebe el estado real de activación y la duración en Diagnostics > Support access o mediante el comando show support_access descrito más arriba. Una vez finalizado el caso de soporte, desactive exclusivamente su propio canal, autorizado para este caso, aplicando las comprobaciones de responsabilidad descritas más arriba, y compruebe que esté inactivo; los permisos temporales de SSH/ACL se siguen revirtiendo por separado.

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 modificar la autenticación de clave pública para SSH, es decir, añadir o eliminar claves SSH. Estos cambios en las claves SSH deben formar parte de un proceso de administración documentado y no utilizarse como un atajo improvisado de soporte.

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 los accesos recurrentes, documente la ruta de la clave privada, la IP de origen permitida y la finalidad. No copie la entrada de known_hosts en tickets ni en historiales de chat. Ante advertencias de clave de host, el historial de cambios es más importante que una solución provisional 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: si aún no dispone del programa, descárguelo primero de la página oficial de descarga de PuTTY y configúrelo en el equipo de administración. Después, establezca la conexión:

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

Tras iniciar sesión correctamente, aparece el Main Menu. La siguiente representación sirve de orientación para seleccionar una opción del menú:

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

En el indicador Select Menu Number [0-7]:, introduzca el número de la opción deseada, por ejemplo, 1 para Network Configuration. Para los comandos de diagnóstico, son especialmente importantes las dos vías siguientes. 7. Shutdown/Reboot Device permite realizar acciones que pueden interrumpir el funcionamiento; esta opción del menú no debe utilizarse para hacer pruebas.

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.

Entender las familias de comandos set y system

En 4. Device Console, set define ajustes y parámetros de diversos componentes del sistema, mientras que system configura parámetros del sistema. Ambas familias pueden modificar la configuración. Para familiarizarse con ellas, utilice solo la ayuda, no un comando de cambio completo. La documentación de SFOS 22 y 23 utiliza estos esquemas generales de sintaxis; no son comandos para copiar:

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set o system es el prefijo literal y se introduce exactamente como aparece.
• Sustituya [command] por el comando documentado que necesite, por ejemplo, advanced-firewall para set o firewall-acceleration para system.
• [option 1|option 2] significa elegir una de las alternativas documentadas. No introduzca los corchetes ni |; aquí no indican que pueda omitir la elección.
• <value> es un marcador de posición para un valor adecuado a la opción seleccionada. Sustitúyalo, incluidos los signos angulares, por el valor necesario. La ayuda del comando concreto determina qué argumentos se requieren realmente; el esquema general no basta.

Solo para explicar la sintaxis; no ejecutar: En el ejemplo del fabricante set advanced-firewall icmp-error-message allow, set es el prefijo, advanced-firewall el comando seleccionado, icmp-error-message la opción y allow el valor concreto que sustituye a <value>. Es un cambio de configuración, no un paso necesario para SSH. El ejemplo system firewall-acceleration enable tampoco es un ejercicio: system es el prefijo, firewall-acceleration el comando seleccionado y enable la opción elegida. Este ejemplo concreto no incluye ningún valor adicional; no añada <value> sin comprobarlo ni active la aceleración para hacer pruebas.

Para explorar de forma segura, escriba solo set en Device Console y pulse Tab tres veces para listar los ajustes disponibles. Tab seguido de ? muestra sus descripciones. Repita el procedimiento con el prefijo system para explorar la otra familia. El resultado esperado es la ayuda, no un ajuste modificado. Después, borre la línea de entrada sin enviar un comando de cambio con Enter. Si no aparece la ayuda esperada, compruebe primero la consola y la documentación de la versión de SFOS instalada, en lugar de probar un comando de ejemplo.

Cerrar la conexión

⚠️ Los antiguos comandos de Device Console enableremote y disableremote no son un método normal para cerrar sesión: para SFOS 22 y 23, Sophos indica que disableremote no solo impide nuevas conexiones SSH en el puerto 22, sino que también termina las sesiones SSH existentes. Por tanto, no los ejecute para cerrar sesión ni para retirar un permiso ACL temporal. Antes de cualquier uso expresamente aprobado de estos comandos, debe haberse probado una vía de acceso de recuperación que funcione y sea independiente del SSH de red: una consola serie local o fuera de banda para los dispositivos físicos, o la consola de plataforma adecuada para los firewalls virtuales o en la nube. Sin este acceso y un plan de recuperación confirmado para la versión instalada, deténgase y aclare el caso con Sophos Support. La descripción de enableremote menciona un puerto Ethernet; de ello no se deduce aquí ni una sintaxis de puerto TCP ni un comando inverso genérico. Para los permisos de acceso temporales, sigue siendo obligatorio el procedimiento de retirada específico descrito más arriba en Administration > Device access; el canal saliente establecido en Diagnostics > Support access es independiente.

En Advanced Shell, utilice el siguiente comando para salir de la shell. No sustituye a la selección de un número en el menú de la consola:

exit

Si se encuentra en un submenú, vuelva primero al Main Menu. Allí, 0. Exit finaliza la sesión de consola: introduzca 0 en el indicador del menú. Por tanto, el comando de shell y el número de menú se utilizan en lugares distintos.

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 el acceso SSH solo se permitió para un caso de soporte, retire después exactamente ese permiso de acceso temporal. Elimine la Local service ACL exception rule creada para ese fin, tal como se describe más arriba; si modificó una casilla de zona, restablezca el estado anotado previamente y guarde con Apply. Mantenga los demás permisos que sigan siendo necesarios. Esto es especialmente importante para las direcciones IP de origen externas o los accesos de proveedores 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, a menudo se debe a que SSH no está permitido para la zona o el origen seleccionados. Por ello, compruebe la configuración de SSH y las entradas existentes de Local service ACL exception rule en Administration > Device access. Compruebe también si se retiró deliberadamente un permiso de acceso más amplio para la zona. No vuelva a habilitar ese acceso sin verificar antes el motivo de la restricción.

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 habilite precipitadamente más accesos desde WAN o desde otras zonas. Para un dispositivo físico, la consola serie local es la vía de respaldo, por ejemplo, si Device Access, el enrutamiento o la asignación de zonas a las interfaces son incorrectos. Utilice el cable de consola RJ45 adecuado o, en los modelos compatibles, micro USB, y configure 38400 baudios en el programa de terminal.

Si micro USB y RJ45 están conectados a la vez, micro USB tiene prioridad y el firewall redirige la salida de la consola a esa conexión. Si el terminal no muestra nada, compruebe primero que el puerto serie y el cable sean los correctos, así como esta prioridad. El valor de 38400 baudios aparece deshabilitado en el BIOS para evitar cambios accidentales; por tanto, no intente ajustarlo allí.

Los pasos concretos para establecer la conexión se encuentran en Abrir una conexión serie. Si conoce la contraseña de admin, utilícela para iniciar sesión una vez establecida la conexión; no necesita restablecer la contraseña. Siga únicamente los pasos de conexión del artículo enlazado, no su procedimiento de restablecimiento. La conexión se ha establecido correctamente cuando aparece el menú de la consola; para los firewalls virtuales o en la nube, debe utilizarse en su lugar el acceso a la consola adecuado para la plataforma correspondiente.

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 SSH solo desde orígenes de administración de confianza.
• Cambiar la contraseña predeterminada de fábrica antes de utilizar SSH en producción.
• Siempre que sea posible, utilizar una Local service ACL exception rule en lugar de permitir el acceso desde toda una zona.
• Preferir la autenticación de clave pública para la cuenta admin al inicio de sesión con contraseña.
• Documentar por separado la contraseña del administrador predeterminado, la información de MFA o recuperación y las claves SSH.
• Utilizar un tipo de clave compatible y documentar su longitud.
• No compartir claves privadas.
• Verificar la huella digital SSH en el primer inicio de sesión.
• Evaluar cuidadosamente las advertencias de clave de host tras reinstalar la imagen o sustituir el hardware.
• No confundir Device Console y Advanced Shell.
• Realizar cambios en Advanced Shell solo con una finalidad clara.
• Retirar los permisos de acceso SSH temporales una vez finalizados los casos de soporte.
• Eliminar las claves públicas antiguas tras cambios de personal o de proveedores de servicios.

Preguntas frecuentes