Sophos Firewall: ¿Hardware, virtual o en la nube?

Sophos Firewall puede funcionar como una XGS Appliance, dispositivo virtual, Software Appliance o Cloud Deployment. Técnicamente, en todas partes se ejecuta el sistema operativo Sophos Firewall, pero el modelo operativo no es el mismo. La decisión afecta al rendimiento, el soporte, el diseño de los puertos de red, HA, la recuperación, las licencias, el monitoreo y la distribución de responsabilidades sobre cada plataforma en caso de una interrupción.

En proyectos nuevos, no basta con preguntar qué variante es más barata. Lo importante es cuál se adapta a la sede, la plataforma de virtualización, la arquitectura de la nube y el equipo de operaciones. La guía de dimensionamiento de Sophos Firewall también es importante para dimensionar la capacidad y el rendimiento.

La plataforma también determina las funciones de cumplimiento: El modo FIPS 140-3 está disponible en XGS Appliances, plataformas virtuales compatibles, AWS y Azure, pero no en Software Appliances ni en hardware XG o SG.

Elegir el modelo operativo

Decisión rápida

• XGS Appliance: Suele ser adecuada cuando una sede necesita un firewall dedicado, con puertos físicos y un marco de soporte claramente definido.
• Dispositivo virtual: Más adecuado si hay disponible una plataforma de virtualización estable y las zonas de red se pueden separar limpiamente de forma virtual.
• Software Appliance: Generalmente adecuado si su propio hardware va a ser operado y soportado deliberadamente como plataforma de firewall.
• Cloud Deployment: Suele ser adecuado para proteger cargas de trabajo en AWS o Azure o conectarlas a redes locales.

La regla más importante: un firewall virtual o en la nube no permite descuidar la planificación. CPU, RAM, almacenamiento, conmutadores virtuales, enrutamiento, HA, copia de seguridad y supervisión deben planificarse con el mismo cuidado que con el hardware.

Cuándo conviene extremar las precauciones

La decisión no debería basarse únicamente en lo que es técnicamente posible. Algunos entornos parecen flexibles sobre el papel, pero crean riesgos innecesarios en la operación.

• El hipervisor ya está muy cargado: IPS, TLS Inspection, VPN y el registro necesitan reservas previsibles de CPU y E/S.
• WAN, LAN, DMZ y la gestión se ejecutan a través del mismo cuello de botella físico: Una separación lógicamente limpia es de poca ayuda si la ruta de datos real está sobrecargada o segmentada incorrectamente.
• Ningún equipo se siente corresponsable del hipervisor y el firewall: Los incidentes persisten entre los equipos de plataforma, red y firewall.
• HA solo se planeó como una casilla de verificación: Sin pruebas de host, almacenamiento, red y restauración, no se demuestra la alta disponibilidad.
• El enrutamiento en la nube no está completamente documentado: El firewall solo protege el tráfico que realmente se enruta a través de él.
• Nunca se practicó la restauración: Una copia de seguridad solo es confiable si la restauración se ha probado de manera realista o al menos se ha planificado adecuadamente.

En tales casos, una XGS Appliance a menudo no es menos moderna, sino simplemente la decisión operativa más sólida. Por el contrario, un firewall virtual o en la nube puede resultar muy útil si se aclaran claramente la plataforma, el diseño de la red, el seguimiento y las responsabilidades.

Comparar las plataformas

XGS Appliance

Una XGS Appliance suele ser la opción que permite planificar con mayor previsibilidad en sedes tradicionales. El hardware, los puertos de red, el soporte, el RMA, el ciclo de vida y el sistema operativo del firewall forman un sistema coordinado.

La gama de hardware físico de Sophos cubre distintas necesidades, desde usuarios domésticos y pequeñas empresas hasta grandes organizaciones. La XGS Appliance adecuada depende del tráfico, las funciones de protección, los puertos y los requisitos de HA. Si necesita ayuda, pida al equipo comercial de Sophos o a un partner que revise la elección según esos requisitos. Que un equipo sea adecuado para una red doméstica no significa automáticamente que pueda utilizarse con la licencia Home gratuita.

Ventajas:

• hardware de firewall dedicado,
• configuración fija de puertos de red y opciones de expansión,
• asignación clara de WAN, LAN, DMZ, enlace HA y administración,
• fácil proceso de soporte y reemplazo de hardware,
• no depender de los recursos del hipervisor,
• Muy adecuado para sucursales, oficinas centrales y firewalls perimetrales. La mayor ventaja está en el funcionamiento: si hay un problema, no es necesario aclarar primero si la causa es el hipervisor, el vSwitch, el almacenamiento, el enrutamiento de la nube o el propio firewall. Para muchas PYME, esto es más importante que la máxima flexibilidad.

Dispositivo virtual

Un Sophos Firewall virtual tiene sentido si ya existe una plataforma de virtualización limpia y el firewall se va a integrar en un centro de datos, un entorno multiinquilino o un diseño de segmentación interna.

Ofrece en formato virtualizado funciones de seguridad de SFOS disponibles en las appliances de hardware, incluida la seguridad basada en la identidad. Así, las decisiones de seguridad tienen en cuenta la identidad del usuario, no solo su dirección de red. Las organizaciones y los proveedores de servicios de seguridad gestionados (MSSP) pueden concentrar la protección de red de centros de datos virtuales u oficinas en un firewall virtual. Las funciones disponibles dependen de la licencia y de la plataforma compatible; esto no implica una aceleración de hardware idéntica ni el mismo rendimiento que una XGS Appliance.

Los despliegues virtuales y en la nube con SFOS también pueden incorporar el estado de salud de los endpoints gestionados a las decisiones de acceso mediante Sophos Endpoint Security Heartbeat. Para ello se requieren los derechos de licencia adecuados para los endpoints y el firewall, el registro en la misma organización correcta y una respuesta configurada explícitamente. La seguridad basada en la identidad no es un mecanismo equivalente para evaluar el estado de salud de los endpoints; el registro por sí solo no demuestra ni el aislamiento ni el bloqueo de todas las rutas de tráfico. Los requisitos previos, las vías de respuesta y las comprobaciones de sus efectos se explican en la guía de Security Heartbeat y Synchronized Security.

Sophos también ofrece administración centralizada de los dispositivos Sophos Firewall. El resumen de plataformas de SFOS 22 utiliza el nombre Sophos Fusion (previously Sophos Central), mientras que el de SFOS 23 utiliza Sophos Central. Esta diferencia de nombres no demuestra que la administración centralizada se introdujera con SFOS 23. Al planificar el despliegue, compruebe el servicio utilizado en su portal de administración y los requisitos para incorporar el firewall; el análisis centralizado de registros no equivale por sí solo a la administración centralizada de dispositivos.

Las plataformas virtuales relevantes incluyen VMware, Microsoft Hyper-V, KVM, Nutanix Prism y Citrix Hypervisor. Antes del despliegue, hay que contrastar la versión concreta de la plataforma con la información vigente de compatibilidad de Sophos. Sophos indica como mínimo una vCPU, 4 GB de RAM, dos vNIC, un disco principal de 32 GB y un disco de informes de 80 GB. Son requisitos mínimos de instalación, no una recomendación de dimensionamiento para tráfico de inspección en producción.

La comprobación no debe limitarse a la familia del producto. Para Nutanix, por ejemplo, Sophos exige AOS 6.5.x o una versión LTS posterior, la versión AHV incluida, una versión compatible de Prism Central y un clúster AHV registrado en Prism Central. KVM requiere un host x86 con un kernel Linux reciente y compatibilidad con Intel VT o AMD-V habilitada. Si se aumentan las vCPU y la RAM para soportar más carga, también debe planificarse un disco de informes mayor para el volumen de logs adicional.

Preguntas operativas importantes:

• ¿Los recursos de CPU están garantizados o existe una sobreasignación importante?
• ¿La RAM y el almacenamiento están suficientemente dimensionados?
• ¿Están claramente separados los NIC virtuales y los grupos de puertos?
• ¿Existen rutas de red dedicadas para WAN, LAN, DMZ, HA y administración?
• ¿Se requiere modo promiscuo, enlace troncal VLAN o SR-IOV?
• ¿Existe un plan bien definido de copia de seguridad y restauración?
• ¿Está claro quién soluciona los problemas del hipervisor, el almacenamiento y el firewall juntos?

Un firewall virtual puede funcionar muy bien. Sin embargo, las cosas rápidamente se vuelven problemáticas cuando se ejecuta en un host sobrecargado o cuando WAN, LAN y la administración solo parecen lógicamente limpios, pero físicamente atraviesan los mismos cuellos de botella.

⚠️ Las instantáneas del hipervisor y las copias de seguridad del proveedor de virtualización no son un sustituto admitido de la copia de seguridad integrada de Sophos. Para una restauración compatible con el soporte, guarde la configuración en Backup & Firmware > Backup & Restore. Las copias de seguridad de la plataforma pueden utilizarse como complemento, pero no deben ser la única vía de recuperación.

Software Appliance

Un Software Appliance se instala en hardware x86-64 dedicado. Puede ser útil para laboratorios, entornos especiales o diseños muy específicos. En producción debe elegirse conscientemente, porque el hardware, los controladores, los repuestos, el monitoreo y el soporte son en gran medida responsabilidad del operador.

SFOS en hardware físico adecuado ofrece reglas y políticas de firewall, respuesta a amenazas y enrutamiento estático, SD-WAN y dinámico, según las licencias correspondientes y el dimensionamiento de la plataforma. Los nombres de fabricantes como Dell o HP son ejemplos, no una lista de compatibilidad verificada modelo por modelo.

La instalación reformatea y vuelve a particionar el disco, eliminando el sistema operativo existente y todos los archivos. Para un Software Appliance con SFOS 22, Sophos requiere Legacy BIOS, al menos 4 GB de RAM, dos interfaces de red y al menos 32 GB de almacenamiento; recomienda 64 GB. Si no se cumplen los requisitos mínimos, el firewall puede entrar en modo fail-safe.

Discrepancia en el almacenamiento: Los resúmenes de plataformas de SFOS 22 y 23 indican un mínimo de 10 GB para hardware propio. En cambio, los requisitos específicos de instalación de Software Appliance para SFOS 22 exigen al menos 32 GB y recomiendan 64 GB. Esta guía sigue deliberadamente el requisito más específico y conservador para la instalación: al menos 32 GB, con 64 GB recomendados. No planifique una instalación con 10 GB; compruebe también los requisitos de la versión de SFOS elegida antes de instalar.

Si una appliance ya se inicia en modo Failsafe, antes de cambiar los recursos hay que guardar la causa detectada por SFOS con el runbook Comprobar una Sophos Firewall en modo Failsafe.

Comprobar:

• ¿El hardware es adecuado para un funcionamiento continuo?
• ¿Son adecuadas las tarjetas de red, el almacenamiento y la configuración BIOS/UEFI?
• ¿Hay hardware de repuesto?
• ¿Está documentado el proceso de instalación y recuperación?
• ¿Quién es responsable de los errores de hardware?

Para ubicaciones estándar, una XGS Appliance suele ser más fácil. Para casos técnicos especiales, un Software Appliance aún puede ser adecuado si el equipo de operaciones tiene un buen dominio de la plataforma.

Cloud Deployment

Las implementaciones en la nube son particularmente útiles cuando es necesario proteger cargas de trabajo en AWS o Azure o cuando las redes en la nube están conectadas a ubicaciones locales. En la nube son diferentes las cuestiones importantes que en la ubicación tradicional.

Planificar:

• Diseño de VPC/VNet,
• tablas de enrutamiento,
• Zonas de disponibilidad,
• IP elásticas o IP públicas,
• VPN de sitio a sitio o SD-WAN,
• registro y análisis centralizado,
• costos de la nube correspondientes a la instancia, el almacenamiento, el tráfico y el diseño HA,
• Responsabilidad operativa entre el equipo de nube y el equipo de firewall.

Un firewall en la nube no reemplaza el diseño limpio de la red en la nube. Sólo están protegidas las rutas que realmente pasan a través del firewall. Las decisiones de despliegue y enrutamiento se explican en las guías de Sophos Firewall en AWS y Sophos Firewall en Azure.

Instalar un appliance virtual o de software

Descargue la imagen directamente desde la página de Sophos Firewall Installers. En Virtual Installers, elija el paquete OVF correspondiente para Citrix o VMware, el paquete VHD para Hyper-V o el paquete QCOW2 para KVM, Proxmox o Nutanix. Para hardware propio, utilice en su lugar la ISO de Software Installers.

Antes de importar, compruebe que abrió mediante HTTPS la página de descarga enlazada arriba, que obtuvo el paquete sin recurrir a un sitio espejo de terceros y que extrajo el archivo comprimido por completo y sin errores. En un paquete OVF, mantenga juntos el manifiesto, el OVF y ambos archivos VMDK. Si la importación notifica una discrepancia del manifiesto o de la suma de comprobación, deténgase y vuelva a descargar el paquete directamente de Sophos. Para una transferencia interna, también puede registrar un valor SHA-256 inmediatamente después de la descarga y compararlo de nuevo en el sistema de destino. Esto detecta errores de transferencia, pero no sustituye una firma del fabricante.

Antes de importar, los requisitos mínimos son 1 vCPU, 4 GB de RAM, dos vNIC, un disco primario de 32 GB y un disco de informes de 80 GB. La insuficiencia de recursos activa el modo fail-safe. Compruebe los derechos de uso de CPU y recursos de la licencia adquirida antes de modificar las asignaciones; estos mínimos no constituyen un dimensionamiento para producción. Aumente la capacidad del disco de informes cuando los recursos adicionales de CPU y RAM permitan generar más registros. Las instantáneas del hipervisor y las herramientas de copia de seguridad del proveedor no son copias de seguridad de firewall admitidas; utilice la función de copia de seguridad de SFOS.

Los siguientes procedimientos de instalación deben comprobarse para la combinación concreta de plataforma y SFOS; una instalación correcta no confirma todavía una vía de producción o recuperación que funcione. Compruebe primero la compatibilidad vigente de la plataforma, el sistema operativo, las herramientas de administración y la imagen. Valide la instalación en una VM nueva y aislada antes de enrutar tráfico de producción. Mantenga sin cambios el firewall existente y las rutas de producción hasta completar la aceptación.

Los resúmenes de plataformas de SFOS 22 y 23 también mencionan, para la familia Citrix, XCP-ng-Center como herramienta de administración alternativa a XenCenter y, para VMware, VMware Workstation como alternativa al procedimiento de ESXi/vSphere descrito aquí. Estas opciones enumeradas en dichos resúmenes no constituyen una confirmación de soporte vigente ni una aprobación general de todas las versiones de XCP-ng. Antes de elegir una de las alternativas, debe confirmarse el soporte para las versiones exactas del host, de la plataforma y de la herramienta de administración. Si el soporte sigue sin estar claro, debe detenerse el despliegue y utilizarse una vía cuyo soporte esté demostrado. Los pasos siguientes de XenCenter y ESXi/vSphere no son una guía de instalación para estas alternativas; en particular, no debe trasladarse el procedimiento de ESXi a Workstation como si fuera una receta de instalación.

Citrix Hypervisor y XenCenter

Requisitos previos: Citrix Hypervisor ya está instalado en un host accesible y XenCenter está instalado en el equipo de administración. Compruebe las versiones compatibles del host, el sistema operativo y las herramientas, y guarde el paquete OVF de Citrix extraído donde XenCenter pueda leer todos sus archivos.

1. En XenCenter, haga clic con el botón derecho en el recurso de destino y seleccione Import > Browse. Seleccione el OVF, haga clic en Open y después en Next.
2. En Import VM(s) to, seleccione el destino o especifique un Home Server y pulse Next. Seleccione el repositorio de almacenamiento para ambos discos.
3. Asigne las interfaces de red de forma deliberada: PortA a la red aislada de administración/LAN y el adaptador orientado a WAN a la red WAN/de prueba independiente prevista. No exponga WebAdmin con su configuración de fábrica a Internet.
4. Verify manifest content es opcional en el asistente de importación; conserve el manifiesto e investigue cualquier discrepancia en lugar de omitirla. Continúe con Next. En OS Fixup Settings, mantenga seleccionada la opción Don’t use Operating System Fixup.
5. Revise el resumen y pulse Finish. Confirme que la importación finalizó correctamente, que están presentes ambos discos y que las dos NIC tienen las asignaciones previstas antes de hacer clic con el botón derecho en esta VM nueva y seleccionar Start. Abra su consola y siga el procedimiento común de primer acceso indicado más adelante.

VMware ESXi y vSphere Client

Requisitos previos: el servidor ya ejecuta una versión de ESXi con soporte vigente y el administrador dispone de una sesión de administración funcional de vSphere Client con acceso al servidor por red. Extraiga el paquete de VMware en el equipo de administración. Las etiquetas antiguas de versión de hardware virtual no demuestran que ESXi 4 o 5 tengan soporte vigente.

Seleccione la plantilla OVF de forma deliberada:

• sf_virtual y sf_virtual_vm7: versión de hardware heredada 7, PCNet32 (Vlance), descriptor de enlace virtual de 10 Mbps, semidúplex, fijo.
• sf_virtual_vm8: versión de hardware 8, E1000E, 1000 Mbps, dúplex completo, negociación automática On.
• sf_virtual_vm8_paravirtual: versión de hardware 8, VMXNET 3, 10000 Mbps, dúplex completo, negociación automática Off. Utilice E1000E como alternativa documentada si el controlador VMXNET 3 falla en su despliegue.
• sf_virtual_virtualbox no es una plantilla de VMware. Los descriptores de enlace anteriores son características del adaptador virtual, no garantías de rendimiento del firewall.

1. En vSphere Client, haga clic con el botón derecho en la ubicación de despliegue y seleccione Deploy OVF Template > Local file > Choose files. Seleccione el OVF elegido junto con sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk y sf_virtual.mf; pulse Open > Next.
2. Introduzca el nombre y la ubicación, seleccione el recurso de cómputo y revise los detalles, avanzando con Next.
3. Seleccione el almacén de datos y el formato del disco virtual. Thick Provision Lazy Zeroed asigna espacio al crear el disco y pone a cero los bloques en su primera escritura. Thick Provision Eager Zeroed asigna y pone a cero el espacio al crear el disco, lo que puede llevar más tiempo. Thin Provision asigna espacio según sea necesario para ahorrar capacidad; supervise la capacidad real del almacén de datos. Ni la descripción del formato de disco ni este procedimiento demuestran compatibilidad de Sophos con Fault Tolerance ni una restricción universal de conversión de discos.
4. Asigne ambas redes de origen de forma deliberada, con PortA en la red aislada de administración. Revise toda la configuración y pulse Finish. Espere a que el despliegue termine correctamente; compruebe los tamaños de ambos discos y las asignaciones de las NIC conectadas.
5. Seleccione Actions > Power > Power on, abra la consola y siga el procedimiento común de primer acceso.

Hyper-V Manager

Requisitos previos: un host Hyper-V compatible y Hyper-V Manager en un equipo de administración con acceso al host por red. Extraiga el paquete de Hyper-V y coloque ambos archivos VHD en almacenamiento accesible para el host; una ruta visible únicamente en el PC del administrador no es suficiente para un host remoto.

1. Abra Action > Connect to Server y después Action > New > Virtual Machine. En el asistente, elija el nombre y la ubicación, Generation 1 y una Startup memory de al menos 4096 MB.
2. Elija el conmutador virtual aislado de administración para el primer adaptador. Seleccione Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Revise la configuración y pulse Finish; no inicie la VM todavía.
3. Haga clic con el botón derecho en la VM nueva, abra Settings y, en Hardware, seleccione Network Adapter > Add. Asigne este segundo adaptador a la red independiente prevista y pulse Apply.
4. Seleccione SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, seleccione AUXILIARY-DISK.vhd y pulse Open > OK. Compruebe el disco primario de arranque, el disco auxiliar SCSI, ambos conmutadores y los tamaños de los discos.
5. Haga clic con el botón derecho en la VM y seleccione Connect; iníciela desde la consola. Siga el procedimiento común de primer acceso.

KVM y Virtual Machine Manager

Requisitos previos: un host Linux x86 con un kernel reciente e Intel VT o AMD-V habilitado, además de Virtual Machine Manager instalado y accesible, o herramientas de administración de KVM adecuadas y compatibles. Ejecute estas comprobaciones de solo lectura en el host Linux, no en la consola de SFOS:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Deben aparecer indicadores vmx para Intel o svm para AMD, no necesariamente ambos. Si la comprobación correspondiente no devuelve coincidencias, deténgase y compruebe la capacidad de la CPU, los ajustes de virtualización del firmware y, en un host anidado, la exposición de estas funciones. La presencia de los indicadores no demuestra por sí sola que la virtualización esté habilitada en el firmware ni que KVM funcione correctamente. #!sh en instrucciones antiguas es un marcador de formato, no un prefijo de comando.

1. Extraiga el archivo comprimido de KVM. Abra File > New Virtual Machine > Import existing disk image > Browse, elija PRIMARY-DISK.qcow2 mediante Choose volume y pulse Forward.
2. Establezca Memory (RAM) en al menos 4096 MB y CPU en al menos 1, respetando los derechos de la licencia y el dimensionamiento. Seleccione Customize configuration before install > Finish. Introduzca un nombre y pulse Apply.
3. Seleccione la red aislada de administración como Network source de la primera NIC. El ejemplo conservado utiliza Device model > Hypervisor default; compruebe que el adaptador resultante sea compatible y pulse Apply. No elija un puente compartido de WAN/LAN sin segmentación.
4. Seleccione el disco primario, que inicialmente aparece como IDE Disk 1, y después Advanced options > Disk bus > VirtIO > Apply.
5. Seleccione Add Hardware > Network, elija la red independiente prevista y seleccione Device model > virtio > Finish.
6. Seleccione Add Hardware > Storage > Select or create custom storage > Manage. Elija AUXILIARY-DISK.qcow2 mediante Choose volume, establezca Disk bus > VirtIO y pulse Finish.
7. Compruebe ambos discos, sus buses y tamaños y las asignaciones de las NIC antes de pulsar Begin Installation. Seleccione el firewall y abra su consola mediante Open; siga el procedimiento común de primer acceso.

Proxmox VE: procedimiento para almacenamiento de tipo directorio

Este procedimiento basado en rutas se aplica a almacenamiento de tipo directorio adecuado, no a cualquier backend LVM, ZFS o Ceph. Examine primero /etc/pve/storage.cfg para identificar el ID de almacenamiento, el backend y la ruta reales. Si su backend no puede utilizar estas rutas de archivos QCOW2, deténgase y obtenga el procedimiento de importación compatible correspondiente; no pegue en él los ejemplos de almacenamiento de tipo directorio.

1. Seleccione el servidor y Create VM. Introduzca Name, seleccione Do not use any media, elija ajustes de System, Hard Disk y CPU apropiados para el entorno y establezca Memory (MB) en al menos 4096. Los valores predeterminados de Machine, SCSI Controller y Cache dependen del ejemplo; no son requisitos universales.
2. Seleccione el Bridge aislado de administración. Deje Start after created sin marcar, revise la configuración y pulse Finish. Anote el VMID y confirme que se trata de la VM de prueba nueva y sin uso.
3. Abra >_ Shell del host con los privilegios adecuados. Mantenga detenida únicamente esta VM nueva, conserve una copia de /etc/pve/qemu-server/<vmid>.conf y anote su asignación de discos existente. Nunca elimine ni sustituya un disco de producción. /var/lib/vz/images/108/ es solo un directorio de ejemplo para el VMID 108; utilice la ruta correspondiente al almacenamiento y al VMID que haya confirmado.
4. Transfiera a ese directorio el archivo comprimido de KVM que realmente haya descargado y extráigalo, por ejemplo con unzip ACTUAL_DOWNLOADED_ARCHIVE.zip, después de sustituir el marcador por el nombre real del archivo. Deben aparecer PRIMARY-DISK.qcow2 y AUXILIARY-DISK.qcow2; el nombre de archivo de una compilación histórica no es una instrucción de descarga vigente.
5. Abra /etc/pve/qemu-server/<vmid>.conf en un editor de texto. Solo en esta VM desechable y detenida, sustituya su asignación inicial scsi0 y añada la asignación auxiliar. La sintaxis del ejemplo conservado es:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Sustituya vmdisk por el ID confirmado del almacenamiento de tipo directorio y <vmid> por el VMID real; no son valores literales listos para usar. Las etiquetas size no redimensionan una imagen demasiado pequeña. Compruebe que las imágenes reales cumplen los tamaños mínimos y que no se sobrescribe ninguna asignación scsi1 existente.

6. En Hardware, compruebe ambas posiciones de disco, sus tamaños y el disco primario de arranque. Utilice Add > Network device para añadir la segunda NIC en el Bridge independiente elegido deliberadamente. En Options, mantenga QEMU Guest Agent desactivado. Vuelva a comprobar las asignaciones antes de pulsar Start y abrir la consola.
7. Si la edición es incorrecta, mantenga apagada la VM nueva y restaure su configuración guardada después de volver a comprobar la identidad del VMID y del almacenamiento. No elimine el archivo del disco original como parte de esta reversión. Validar esta reversión local antes de la puesta en producción; no utilizarla como procedimiento de recuperación de un entorno productivo. Siga el procedimiento común de primer acceso solo cuando las comprobaciones del hardware corregido sean satisfactorias.

Nutanix Prism Central

Requisitos previos: AOS 6.5.x o una versión LTS posterior, su AHV incluido, una versión compatible de Prism Central (PC) y el clúster AHV registrado en PC. Las instrucciones de la plataforma especifican la última versión GA (LTS) de la appliance virtual del proveedor asociado: GA significa General Availability, o disponibilidad general, y LTS significa Long-Term Support, o soporte a largo plazo. Compruebe la versión de la appliance del proveedor asociado y la combinación de plataforma realmente compatibles; una página de ayuda de SFOS 23 no identifica por sí sola la última versión GA. Confirme los recursos de CPU autorizados por la licencia, al menos 4 GB de RAM, dos NIC y discos de 32 GB/80 GB.

1. Extraiga PRIMARY-DISK.qcow2 y AUXILIARY-DISK.qcow2 del paquete Virtual Installers: Firewall OS for KVM en el equipo de administración.
2. En PC, abra Virtual Infrastructure > Images > Add Image > Add File. Añada cada archivo con Image Type > Disk. Pulse Next, seleccione Placement Method y Select Clusters para su destino y después Save. Actualice la vista tras la carga y compruebe que ambas imágenes estén disponibles.
3. Abra Infrastructure > VMs > Create VM. En General Configuration, establezca el nombre y la zona horaria; en Compute Details, configure la CPU autorizada por la licencia y suficiente RAM. En Disks, elimine el CD-ROM predeterminado únicamente de esta VM nueva.
4. Seleccione Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Repita el procedimiento para AUXILIARY-DISK.qcow2 como disco de registros; el ejemplo auxiliar conservado también utiliza SCSI. No traslade aquí las instrucciones del bus VirtIO de KVM.
5. En Network Adapters (NIC) > Add New NIC > VLAN Name, seleccione la VLAN aislada de administración y pulse Add. Repita el procedimiento para la segunda red independiente prevista. La opción de conectividad DHCP de las instrucciones de origen es opcional; planifique después un direccionamiento estable de las interfaces. Seleccionar una VLAN no equivale a asignar una dirección IP.
6. En VM Host Affinity > Set Affinity, seleccione un host aprobado y pulse Save; después guarde la VM. Debe aparecer un mensaje de éxito; compruebe ambos discos, sus buses y tamaños y las asignaciones de las NIC antes del encendido.
7. Encienda la VM nueva y seleccione Launch console. Siga el procedimiento común de primer acceso.

Primer acceso, validación y reversión segura

Antes del primer encendido, compruebe las asignaciones de PortA y PortB a las redes de administración, LAN y WAN. Si están invertidas, WebAdmin podría quedar expuesto directamente a Internet. Solo en el entorno inicial aislado, la cuenta y contraseña de administrador de fábrica documentadas son admin / admin; la consola solicita la contraseña de administrador admin. Abra https://172.16.16.16:4444 desde el cliente aislado de administración, por ejemplo con la dirección 172.16.16.2/24. Revise y acepte los términos de uso para usuarios finales de Sophos y pulse Start setup para realizar el registro y la configuración básica. Sustituya las credenciales de fábrica durante la configuración, antes de cualquier exposición, y siga después la guía de primeros pasos.

No cambie la contraseña predeterminada en la CLI antes de ejecutar el asistente: este no se iniciará después. Si ya lo hizo, complete manualmente la configuración básica; no restablezca un firewall configurado simplemente para recuperar el asistente. El restablecimiento de fábrica destruye la configuración y solo debe considerarse de forma deliberada para una VM nueva, protegida y desechable, sin configuración que conservar.

Antes de pasar a producción, compruebe la licencia y el número de serie, el arranque normal en la consola, ambos discos y la generación de informes, las interfaces y zonas, la copia de seguridad admitida de SFOS y que una prueba de acceso a WebAdmin desde una red no autorizada sea rechazada. El operador debe completar estas comprobaciones antes de aprobar el cambio.

Si WebAdmin no está accesible, no reinstale de inmediato. Compruebe que el cliente esté directamente en la red de PortA, que la vNIC esté conectada y que el grupo de puertos o el puente corresponda realmente a la red aislada de administración. Confirme en la consola que el arranque haya terminado y descarte un conflicto de direcciones con 172.16.16.16. PortA no debe estar en la WAN pública. Si faltan informes o se activa el modo fail-safe, compruebe la asignación del disco de informes, su bus y tamaño, CPU, RAM y ambas vNIC; registre la causa detectada con el runbook de modo fail-safe antes de modificar los recursos.

Si decide retirar el nuevo despliegue antes de la puesta en producción y todavía no se enruta tráfico de producción por la VM nueva, apáguela, deshaga las rutas de prueba y las puertas de enlace temporales y continúe utilizando el firewall existente sin cambios. Estos pasos se aplican solo a la reversión, no a una puesta en producción validada correctamente. Después de la puesta en producción, la recuperación requiere una copia de seguridad SFOS actualizada y una reconstrucción documentada, no una instantánea del hipervisor; utilice el procedimiento de copia de seguridad y restauración.

Software Appliance en hardware propio

El equipo de destino requiere x86-64, Legacy BIOS, al menos 4 GB de RAM, dos NIC y un HDD/SSD de 32 GB (64 GB recomendados). El USB necesita al menos 1 GB. Windows/macOS es el sistema de la estación de trabajo utilizada para escribir el medio, no un sistema operativo que se conserve junto con SFOS. Utilice la descarga Software Installers: Firewall OS Software ISO for Intel Hardware, extraiga el archivo comprimido y compruebe la ISO SW y la integridad de la transferencia como se indicó anteriormente. No utilice una imagen HW/XGS ni un paquete de discos virtuales.

⚠️ La escritura del medio borra por completo el dispositivo USB seleccionado. Después, la instalación formatea y vuelve a particionar el disco del servidor de destino, eliminando su sistema operativo anterior y todos los datos. Antes de cualquiera de estas acciones, identifique el dispositivo exacto por su capacidad e identidad, guarde los datos externamente y verifique una vía de restauración independiente. Deténgase si el destino no está claramente identificado. No hay una reversión automática tras la instalación; la recuperación requiere medios y datos del sistema original guardados por separado, o una copia de seguridad SFOS compatible con su contraseña y la SSMK asociada.

Windows: Win32 Disk Imager

1. Inserte el USB e identifique su letra de unidad, capacidad e identidad en la administración de discos de Windows; desconecte otras unidades extraíbles cuando sea viable. Obtenga e inicie Win32 Disk Imager en la estación de trabajo.
2. Su selector de archivos normalmente filtra archivos IMG. Cambie el filtro a *.* y seleccione el archivo .ISO SW de Sophos extraído.
3. Seleccione el USB de destino confirmado, no un disco del sistema o de datos. Vuelva a comprobar el archivo y la unidad seleccionados frente a la identidad que anotó; después pulse Write y confirme la advertencia de borrado. Espere a que la escritura termine correctamente y expulse el USB de forma segura. Copiar la ISO como un archivo normal no crea un medio arrancable.

macOS: alternativa nativa para escribir el medio

1. Utilice Disk Utility para identificar el USB externo por su capacidad e identidad. Las instrucciones antiguas muestran Partitions > Volume scheme: 1 partition > Format: Free Space > Apply; estos controles dependen de la versión y pueden no existir en su versión de macOS. No invente una equivalencia ni formatee otro disco para reproducir esa interfaz antigua. El procedimiento de escritura de medios de la guía de reinstalación es una alternativa; aquí debe utilizarse la ISO SW en lugar de la imagen de hardware de esa guía.
2. En Terminal, vaya al directorio de la ISO. Sustituya SOPHOS_ISO por el nombre real del archivo descargado antes de ejecutar:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Debe obtener el archivo convertido sf.img.dmg. Ejecute diskutil list, identifique de nuevo el disco USB externo completo y desmonte sus volúmenes antes de la escritura directa (en Disk Utility, Unmount, no expulsar). Deténgase si no puede identificar o desmontar el dispositivo previsto.
4. Lo siguiente es una plantilla, no un comando listo para pegar y ejecutar. Sustituya PATH_TO_USB por la ruta confirmada del dispositivo completo, nunca por una partición ni por un número de disco supuesto. Borra todo ese dispositivo:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Utilice sudo solo si los permisos del dispositivo lo requieren, después de volver a comprobar el destino. Una ruta de acceso directo añade r al nombre confirmado del dispositivo (/dev/diskN pasa a ser /dev/rdiskN); N es un marcador de posición, no un número de disco que deba copiar. El acceso directo puede ser más rápido, pero no hace que la operación sea más segura. Espere a que reaparezca el indicador de comandos y a que la operación termine correctamente; vacíe las escrituras pendientes con sync y expulse el USB de forma segura antes de retirarlo. Si aparece un error, deténgase en lugar de instalar desde un medio cuya escritura no se haya verificado.

Instalar y comprobar el servidor físico

1. Programe una interrupción del servicio, conserve la ruta del firewall existente y las copias de seguridad externas, y compruebe Legacy BIOS, el arranque desde USB y el disco exacto de instalación. Desconecte los discos de datos ajenos a la instalación cuando sea viable. Conecte un monitor y un teclado locales y, si es necesario, una consola serie adecuada.
2. Arranque desde el USB preparado. Antes de escribir y y pulsar Enter en la confirmación del instalador, vuelva a comprobar la identidad del servidor y del disco y confirme que se puede perder todo el sistema operativo anterior y sus datos. Si el destino del instalador no está claro, deténgase. Siga las indicaciones hasta finalizar, retire el USB y reinicie; el primer arranque puede tardar unos minutos. No aplique instrucciones sobre los LED de XGS a este servidor genérico.
3. Compruebe las NIC detectadas e identifique la interfaz de administración antes de conectar el cliente aislado de administración con la dirección 172.16.16.2/24. Confirme el arranque normal y utilice https://172.16.16.16:4444, los términos de uso y Start setup como se indicó anteriormente. Refuerce las credenciales, complete el registro y la activación de licencias y guarde una copia de seguridad SFOS externa antes de pasar a producción.
4. Si el USB no arranca, compruebe que se escribió como imagen en lugar de copiarse como archivo, la identidad de la imagen SW y la selección de Legacy BIOS y arranque desde USB. Si faltan NIC o se activa el modo fail-safe, registre la causa indicada en la consola y compruebe los requisitos mínimos y la compatibilidad de los controladores antes de reinstalar. Si WebAdmin no está accesible, compruebe la identidad de la NIC de administración, el enlace, la dirección del cliente, la finalización del arranque y los conflictos de direcciones; nunca conecte la administración de fábrica a la WAN pública como atajo. Utilice la guía interna de modo fail-safe, la guía de primeros pasos y la guía de copia de seguridad y restauración para decidir el siguiente paso.

Planificar la operación y la recuperación

Rendimiento y dimensionamiento

En cuanto al hardware, el rendimiento depende del modelo que elijas. Para implementaciones virtuales, de software y en la nube, el rendimiento depende más de la plataforma.

Particularmente relevante:

• rendimiento de la CPU y reserva de recursos de CPU,
• RAM,
• latencia de almacenamiento,
• NIC virtuales,
• hipervisor o ruta de red en la nube,
• número de sesiones,
• TLS Inspection,
• IPS,
• rendimiento de VPN,
• registro y generación de informes.

Por lo tanto, los valores de la ficha técnica siempre deben leerse en contexto. El rendimiento del firewall sin inspección de seguridad no equivale al de la protección contra amenazas, TLS Inspection o IPsec VPN bajo carga real. La guía para interpretar los datos de rendimiento de Sophos Firewall explica estas diferencias.

HA y recuperación

La alta disponibilidad difiere significativamente según la plataforma.

Cuando se trata de hardware, HA suele ser más fácil de entender: dos dispositivos, enlace HA, interfaces definidas, dispositivo de reemplazo claro. Surgen preguntas adicionales para implementaciones virtuales y en la nube:

• ¿Los nodos HA se ejecutan en diferentes hosts?
• ¿Son realmente redundantes el almacenamiento, la red y el hipervisor?
• ¿Son compatibles las direcciones MAC virtuales y las reglas de vSwitch?
• ¿Existe alguna dependencia del enrutamiento de la nube o del equilibrio de carga?
• ¿Las copias de seguridad y las restauraciones funcionan en una instancia nueva?
• ¿Se ha probado la falla de un host o de una zona de disponibilidad?

Los conceptos básicos de las variantes HA se explican en la guía de configuración de alta disponibilidad (HA) de Sophos Firewall. Para la recuperación, es imprescindible consultar la guía para crear o restaurar una copia de seguridad de Sophos Firewall.

Licencias y soporte

Las licencias deben comprobarse antes del despliegue o de modificar los recursos. Las instrucciones antiguas de instalación en plataformas limitan tanto las vCPU como la vRAM a lo autorizado por la licencia adquirida; el artículo enlazado más abajo describe un cambio comercial para las modalidades virtual, de software y cloud BYOL, vigente desde el 1 de marzo de 2025, hacia licencias por núcleos de CPU sin el anterior límite de RAM. Esa descripción no demuestra que todos los SKU, derechos de uso heredados o licencias Home tengan las mismas condiciones. Antes de asignar recursos, confirme en el portal de licencias el SKU adquirido, los núcleos autorizados, el número de serie, la suscripción y el soporte, y el estado real de la licencia de la instancia. Si los derechos de uso no están claros, deténgase y aclárelos con el proveedor de licencias. No aplique el cambio comercial a licencias Home ni deduzca de este artículo que los recursos son ilimitados. El mínimo de instalación de 4 GB y el dimensionamiento de RAM, almacenamiento y NIC para producción siguen siendo requisitos técnicos, con independencia de cualquier límite de licencia aplicable.

Para los conceptos básicos, consulte Sophos Firewall: licencia base. El cambio comercial descrito se explica en Sophos Firewall VM y SW: licencias por CPU sin el anterior límite de RAM, con las salvedades indicadas anteriormente.

Aspectos importantes para la operación:

• Documentar el estado de las licencias y del soporte.
• Registrar claramente el número de serie y el estado de registro.
• Comprobar las licencias HA antes de crear el clúster.
• Comprobar los derechos de actualización de firmware y la cobertura de soporte antes de actualizar.
• Conocer el proceso RMA o de recuperación de la plataforma elegida.

Antes de actualizaciones importantes, también debe consultarse la guía de comprobación previa a la actualización a SFOS 22 de Sophos Firewall, porque la compatibilidad de la plataforma, el espacio de almacenamiento, la copia de seguridad, HA y las configuraciones VPN antiguas pueden influir en la actualización.

Para HA active-passive en appliances virtuales o de software, solo el nodo Primary necesita todas las licencias requeridas, incluida la Base Firewall License. En active-active, cada nodo necesita su propia Base Firewall License y las mismas licencias de protección adicionales; las fechas de vencimiento pueden ser diferentes. Esto debe resolverse antes de crear el clúster, no durante el análisis del primer failover.

Matriz de decisión

• Sede tradicional con WAN, LAN y DMZ: Principalmente hardware. Virtual solo con una buena estrategia de virtualización.
• Centro de datos con equipo de hipervisor existente: El hardware es posible, lo virtual a menudo tiene sentido.
• Cargas de trabajo en la nube en AWS o Azure: Más virtual o en la nube, no hardware clásico.
• Soporte sencillo y RMA importante: Más hardware. Ya sea virtual o en la nube, mucho depende del equipo de la plataforma.
• Se requieren muchos puertos físicos: Más hardware. Solo virtual con diseño limpio de NIC y vSwitch.
• Escalado dinámico y Infrastructure as Code: Más virtual o en la nube.
• Equipo de TI pequeño sin conocimientos especializados en hipervisores: Principalmente hardware; los firewalls virtuales requieren una planificación cuidadosa.
• Diseño multiinquilino o de segmentación en el centro de datos: El hardware es posible; la opción virtual suele tener sentido.

Errores comunes

• Ejecutar un firewall virtual en un host con recursos sobreasignados.
• No separar claramente WAN, LAN y administración en el hipervisor.
• Elegir hardware por su precio en lugar de dimensionarlo según la capacidad necesaria.
• Desplegar un firewall en la nube sin completar el diseño de enrutamiento.
• Planificar HA sin probar fallas del host, del almacenamiento o de la nube.
• Crear copias de seguridad sin practicar la restauración.
• Comprobar el estado de las licencias y del soporte únicamente durante una actualización.
• Añadir TLS Inspection o IPS sin reservas de rendimiento.
• Involucrar a los responsables de plataforma, red y firewall solo después de un incidente.

Lista de verificación

• Entorno de despliegue claramente definido: sede física, centro de datos o nube.
• Tráfico, ancho de banda y características de seguridad registradas para dimensionamiento.
• Variantes de hardware, virtuales, software o nube elegidas deliberadamente.
• Responsabilidad del firewall, hipervisor, nube y red documentada.
• Diseño de HA y recuperación comprobado.
• Proceso de copia de seguridad y restauración probado o planificado.
• Licencia, soporte y registro aclarados.
• Monitoreo de firewall y plataforma subyacente disponible.
• Se comprobó la capacidad de actualización y el soporte de la plataforma.
• Responsable de plataforma, red, firewall, respaldo y restauración nombrado.

Preguntas frecuentes