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 el rendimiento, el soporte, el diseño del puerto, HA, la recuperación, las licencias, el monitoreo y la cuestión de quién es responsable de qué plataforma en caso de una interrupción.

Para proyectos nuevos, no deberías preguntar simplemente qué variante es más barata. Lo que importa es qué variante se adapta a la ubicación, la plataforma de virtualización, la arquitectura de la nube y el equipo de operaciones. La Sophos Firewall Guía de tallas también es importante para el tallaje de 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: Principalmente adecuada cuando una ubicación necesita un firewall dedicado y claramente compatible con puertos físicos.
• 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 es un pase gratuito para una menor 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.

Cuando tener cuidado

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 se utiliza mucho: IPS, TLS Inspection, VPN y el registro necesitan CPU predecible y reserva de 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 variante más planificable para ubicaciones clásicas. El hardware, los puertos, el soporte, el RMA, el ciclo de vida y el sistema operativo del firewall forman un sistema coordinado.

Ventajas:

• hardware de firewall dedicado,
• equipos de puerto fijo y opciones de expansión,
• asignación clara de enlace y gestión WAN, LAN, DMZ, HA,
• 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.

Las plataformas virtuales relevantes incluyen VMware, Microsoft Hyper-V, KVM, Nutanix Prism y Citrix Hypervisor. Antes del deployment, hay que comprobar la versión concreta de la plataforma con la información actual 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 CPU están garantizados o tienen un exceso de suscripción?
• ¿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 concepto limpio 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.

⚠️ Los snapshots del hipervisor o los backups del proveedor de virtualización no sustituyen de forma soportada al backup integrado de Sophos. Para un restore soportable, hay que guardar la configuración en Backup & Firmware > Backup & Restore. Los backups de plataforma pueden existir adicionalmente, pero no deben ser el único camino 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.

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.

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.

Controlar:

• ¿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,
• Sitio a sitio VPN o SD-WAN,
• Registro y evaluación central,
• Costos de la nube, por ejemplo, almacenamiento, tráfico y 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 deployment 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 no obtuvo el paquete de un mirror de terceros y que el archivo se extrajo por completo 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 justo después de la descarga y volver a compararlo en el sistema de destino. Esto detecta errores de transferencia, pero no sustituye una firma del fabricante.

Antes de importar se aplican los mínimos de 1 vCPU, 4 GB de RAM, dos vNIC, un disco primario de 32 GB y un disco de informes de 80 GB. Los recursos insuficientes activan el modo fail-safe. Los snapshots y las copias del hipervisor no son backups de firewall compatibles; se utiliza la función de backup de SFOS.

Antes del primer arranque, comprobar PortA y PortB frente a las redes de administración, LAN y WAN. Una asignación invertida puede exponer WebAdmin a Internet. El primer acceso se realiza desde una red administrativa aislada en https://172.16.16.16:4444, por ejemplo con 172.16.16.2/24 en el cliente. No cambiar la contraseña predeterminada en CLI antes del asistente, ya que después no se inicia. Tras el wizard, verificar licencia, ambos discos, interfaces, informes, backup y un acceso negativo desde una red no autorizada.

Validar la instalación y revertirla de forma segura

Si https://172.16.16.16:4444 no está accesible, no reinstale de inmediato. Compruebe primero que el cliente de administración esté directamente en la red de PortA, que la vNIC correspondiente esté conectada y que su grupo de puertos o bridge esté realmente asignado a la red administrativa aislada. Después, use la consola de la VM para confirmar que el firewall haya arrancado por completo y descarte un conflicto de direcciones con 172.16.16.16. Durante esta prueba, PortA no debe estar conectada por error a la WAN pública.

Si faltan informes después del setup o el appliance arranca en modo fail-safe, compare la asignación, el bus y el tamaño mínimo del disco auxiliar/de informes, además de CPU, RAM y ambas vNIC, con los requisitos de Sophos específicos de la plataforma. Antes de cambiar recursos, registre la causa detectada con el runbook de modo fail-safe.

Mientras el firewall no enrute tráfico de producción, la reversión es sencilla: apague la VM, deshaga las rutas de prueba o el gateway predeterminado temporal y siga utilizando el firewall existente sin modificarlo. Después de la puesta en producción, la recuperación debe basarse en un backup SFOS actualizado y una reconstrucción documentada de la VM, no en un snapshot del hipervisor.

Instalar en hardware propio

El software appliance sustituye por completo el sistema operativo. Requiere x86-64, Legacy BIOS, al menos 4 GB de RAM, dos NIC y un HDD o SSD de 32 GB; se recomiendan 64 GB. El USB necesita al menos 1 GB. Windows o macOS solo sirve para escribir la ISO. El servidor arranca desde USB y, tras confirmar, se formatea y reparticiona por completo. Antes deben asegurarse los datos, el modo de arranque, la detección de NIC y una vía de recuperación independiente.

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:

• CPU rendimiento y CPU reserva,
• RAM,
• latencia de almacenamiento,
• NIC virtuales,
• hipervisor o ruta de red en la nube,
• número de sesiones,
• TLS Inspection,
• IPS,
• VPN rendimiento,
• Registro y presentación de informes. Por lo tanto, los valores de la hoja de datos siempre deben leerse en contexto. El rendimiento del firewall sin inspección de seguridad no es lo mismo que la protección contra amenazas, TLS Inspection o IPsec VPN bajo carga real. Las diferencias explicadas Sophos Firewall Interpretar correctamente los datos de rendimiento.

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 pueden encontrar en Sophos Firewall Configuración de alta disponibilidad (HA). Para la recuperación, se requiere lectura Sophos Firewall Crear o restaurar copia de seguridad.

Licencias y soporte

Las licencias deben comprobarse pronto porque los firewalls de hardware, virtuales y de software se tratan de forma distinta. Desde marzo de 2025, las licencias virtuales, de software y cloud BYOL están limitadas por núcleos CPU; el límite anterior de RAM ya no se aplica. Esto no significa que una cantidad ilimitada de RAM compense un mal dimensionamiento de CPU, almacenamiento o NIC. El número de serie, la licencia de núcleos, el soporte y la suscripción deben seguir correspondiendo a la instancia. Para los conceptos básicos de la licencia base, Sophos Firewall - Licencia base es adecuado. El cambio en las licencias virtuales y de software, en las que la RAM ya no es el foco del límite de licencia, se enumera en la publicación del blog Sophos Firewall VM y SW - Solo cuenta CPU - No más límite de RAM.

Lo que es importante en funcionamiento:

• Documento de licencia y estado de soporte.
• Registre claramente el número de serie y el estado de registro.
• Verifique la licencia HA antes de construir.
• Verifique la elegibilidad del firmware y soporte antes de las actualizaciones.
• Conocer el RMA o proceso de recuperación de la plataforma elegida.

Antes de actualizaciones importantes, también se debe utilizar Sophos Firewall antes de SFOS 22 Comprobar actualización porque el soporte de plataforma, el espacio de almacenamiento, la copia de seguridad, HA y las configuraciones antiguas VPN pueden ser relevantes para 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

• Ubicación clásica con WAN, LAN y DMZ: Principalmente hardware. Virtual sólo 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.
• Pequeño equipo de TI sin conocimientos especializados en hipervisor: Principalmente hardware; Planifique los cortafuegos virtuales con cuidado.
• Diseño de inquilinos o segmentación en el centro de datos: El hardware es posible, lo virtual muchas veces tiene sentido.

Errores comunes

• Ejecute un firewall virtual en un host con overbooking.
• No separe claramente WAN, LAN y la administración en el hipervisor.
• Seleccione hardware únicamente según el precio en lugar del tamaño.
• Implementar un firewall en la nube, pero no pensar completamente en las tablas de enrutamiento.
• Planifique HA pero no pruebe fallas de host, almacenamiento o nube.
• Cree una copia de seguridad, pero nunca practique la restauración.
• Verifique el estado de la licencia y el soporte solo durante la actualización del firmware.
• Active funciones de seguridad como TLS Inspection o IPS más tarde, sin reservas de rendimiento.
• Reúna al equipo de la plataforma, al equipo de la red y a los administradores del firewall únicamente en caso de una interrupción.

Lista de verificación

• Ubicación claramente definida: ubicación, 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.
• HA y diseño de recuperación comprobados.
• 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