Desplegar y operar Sophos Firewall en AWS

Sophos Firewall 22 funciona en AWS como appliance EC2 virtual inline en una VPC. Primero hay que definir qué tráfico debe inspeccionar. Una firewall standalone puede controlar tráfico entrante y saliente; la plantilla Sophos Auto Scaling es un diseño PAYG especializado en DNAT o WAF entrante.

El recorrido seguro es elegir arquitectura y licencia, registrar el plan IP y de routing, iniciar la plantilla Marketplace adecuada, limitar la administración a una IP de origen fija, validar un flujo de extremo a extremo y solo después publicar otros servicios.

⚠️ AWS Security Groups siguen siendo una segunda capa de firewall. Una regla SFOS permisiva no sirve si una Security Group, NACL o Route Table bloquea el camino. Tampoco debe combinarse un puerto AWS abierto con una regla Sophos amplia. Las Security Groups son stateful y las Network ACL stateless, por lo que una NACL personalizada debe permitir solicitud y retorno.

Elegir standalone o Auto Scaling

AWS no ofrece HA nativo de Sophos Firewall. Auto Scaling y Network Load Balancing son otro diseño cloud, no sincronización HA de SFOS. Un diseño standalone necesita, por tanto, un procedimiento de reconstrucción y una ventana de interrupción aceptada.

Para elegir la instancia se requieren tres comprobaciones: el tipo EC2 debe estar disponible en la plantilla CloudFormation de Marketplace abierta para la región y AMI elegidas; la CPU, la RAM y el rendimiento de red deben ajustarse al throughput y al perfil de conexiones; con BYOL, deben confirmarse los derechos de uso de CPU y las condiciones aplicables a esa licencia concreta.

La asignación de SFOS 22/23 indica, por ejemplo, m5.large con 2 vCPU y 8 GB de RAM para SFv2C4, y m5.xlarge con 4 vCPU y 16 GB de RAM para SFv4C6. Son ejemplos de asignación vinculados a una versión y una oferta, no una garantía para todas las plantillas actuales. Por tanto, el sufijo histórico de RAM de la licencia no constituye un límite máximo fiable para la RAM física de EC2; tampoco implica una garantía general de derechos de uso de RAM ilimitada. Antes de comprar, aclarar y documentar con Sophos o con el proveedor de licencias los derechos de uso de la licencia/oferta concreta; si hay dudas, no desplegar en producción.

Elegir un tamaño ofrecido con margen de capacidad y registrar en el plan el tipo EC2, la AMI/versión de SFOS y las condiciones de licencia confirmadas.

Con PAYG, la facturación del software solo termina cuando se eliminan todas las instancias firewall correspondientes; los recursos AWS que permanezcan por separado pueden seguir generando costes.

Si el tipo previsto no aparece en la plantilla o CloudFormation rechaza la combinación de región, AMI y tamaño, no forzarla modificando manualmente la plantilla. Elegir un tipo ofrecido que cumpla la carga y la licencia o detener el despliegue hasta aclarar la región, la oferta o la licencia.

Aclarar la licencia y el piloto antes de comprar

Si PAYG no está disponible en el país o en la oferta correspondiente, se puede considerar Standalone BYOL con una licencia confirmada; esto no permite usar con BYOL la plantilla Auto Scaling exclusiva de PAYG. A través de Sophos o de un partner también se puede evaluar un Private Offer con precios y condiciones acordados individualmente. BYOL evita el cargo de software de Marketplace, no los costes de EC2 e infraestructura.

Para un piloto, comprobar el derecho real a una prueba, su duración y las condiciones de la oferta seleccionada. Las FAQ históricas de AWS describen una prueba de software PAYG de 30 días; esto no garantiza que se aplique a la oferta elegida actualmente. Una vez finalizada la prueba de esa oferta, el uso posterior del software PAYG pasa automáticamente a ser de pago. EC2, almacenamiento, red y otros componentes de infraestructura pueden generar costes ya durante la prueba. Registrar la fecha de finalización, el responsable de costes, una alarma presupuestaria y una decisión sobre la continuidad del servicio o su retirada a tiempo. Con BYOL, usar una activación de prueba ofrecida durante la configuración inicial o una licencia de prueba aprobada previamente; el registro por sí solo no garantiza una licencia.

Una licencia UTM de producción solo puede convertirse a Sophos Firewall mediante el proceso de conversión previsto, sujeto a los derechos correspondientes. La transferencia de una licencia firewall existente también es posible únicamente en los escenarios permitidos, no mediante la reutilización arbitraria del mismo key. Confirmar ambos puntos con el proveedor de licencias antes de iniciar BYOL. Activar el key de licencia describe la activación posterior.

En el modelo de responsabilidad compartida, las aplicaciones, los datos, la configuración y el mantenimiento siguen siendo responsabilidad propia. IPS, filtro web y WAF complementan SG/NACL únicamente en el recorrido de tráfico que realmente controlan. Synchronized Security requiere licencias Endpoint adecuadas, registro y Heartbeat/policy de firewall; no aísla automáticamente todos los recorridos laterales entre instancias EC2 que eludan los controles. Conexión con Central explica la conexión con la administración centralizada.

Preparar el despliegue standalone

Registrar antes del lanzamiento:

• cuenta AWS, región, Availability Zone y oferta BYOL o PAYG;
• VPC nueva o existente y CIDR públicos y privados sin solapamiento;
• origen administrativo fijo, por ejemplo 198.51.100.27/32, en vez de acceso global;
• Elastic IP, nombres DNS y servicios entrantes necesarios;
• redes privadas de destino, default route y retorno esperado de cada flujo;
• tipo EC2 admitido, límite de licencia, responsable de costes y tags;
• procedimientos de backup, firmware y reconstrucción.

198.51.100.27/32 es una dirección de documentación y debe sustituirse por la IP pública real del administrador. Si cambia con frecuencia, una VPN o un jump host controlado es más seguro que exponer ampliamente TCP 4444.

En una VPC existente no se eligen subredes solo por su nombre: sus Route Tables deben coincidir con la dirección prevista. AWS explica la inserción de appliances en sus ejemplos de middlebox routing. Source/Destination Check debe estar desactivado en las ENI de la firewall porque reenvían tráfico de terceros. Dejar que CloudFormation establezca estos detalles y verificarlos después sin modificarlos a ciegas.

Desplegar standalone con CloudFormation

1. Abrir la oferta Sophos Firewall BYOL o PAYG en AWS Marketplace, elegir View purchase options y aceptar las condiciones.
2. En Continue to Configuration, seleccionar fulfillment, versión de software SFOS actual y región.
3. En Continue to Launch, seleccionar Launch CloudFormation y abrir la plantilla en la consola AWS CloudFormation.
4. Introducir un Stack name único. Para una VPC nueva, comprobar que los rangos no se solapan con VPC, VPN o redes locales existentes.
5. Para una VPC existente, asociar VPC ID, una subred pública, una privada y una Elastic IP nueva o libre. Dejar Network Address Prefix for new VPC sin cambios.
6. Usar solo un tamaño EC2 ofrecido por la plantilla abierta para la región y AMI y, con BYOL, volver a comprobarlo contra el límite de licencia registrado. No guardar secretos en tickets, capturas ni ficheros de parámetros de lectura pública.
7. Revisar los recursos IAM solicitados. Solo entonces confirmar I acknowledge that AWS CloudFormation might create IAM resources y pulsar Submit.
8. Esperar CREATE_COMPLETE. Leer la Elastic IP en Outputs y comprobar los dos status checks y las ENI previstas en EC2.
9. Abrir WebAdmin desde el origen autorizado en https://<EIP>:4444. Omitir el aviso del certificado local inicial solo tras verificar la IP de destino, aceptar las condiciones de uso y completar el registro y la configuración básica. Después, abrir Administration > Licensing y confirmar que la licencia prevista está activa; si difiere, corregir el tamaño de instancia o la asignación de licencia antes de permitir tráfico de producción.

Los parámetros de Marketplace pueden cambiar; antes de cada despliegue de producción, compare los nombres de campo visibles con el template que haya abierto.

Abrir conjuntamente reglas AWS y SFOS

La plantilla standalone de Sophos habilita de forma predeterminada solo el acceso de administración para WebAdmin y SSH. Esta afirmación no se aplica de forma general a Auto Scaling: allí, Public Network CIDR controla el tráfico no administrativo. IPsec, SSL VPN, RED, WAF, User Portal y las aplicaciones publicadas necesitan además reglas AWS Security Group adecuadas. Para SD-RED 20/60, tenga en cuenta TCP 3400 hacia el firewall para el canal de control y UDP 3410 para el túnel de datos; compruebe por separado los requisitos adicionales de provisioning, DNS y NTP, así como otras variantes de RED.

Para cada apertura, documentar una vez protocolo, puerto de destino y origen, pero implementarlos por separado:

1. La Security Group permite solo el origen requerido hacia el puerto de la ENI correcta.
2. Una NACL personalizada permite solicitud y retorno. AWS explica la diferencia en Security Groups y Network ACLs.
3. La Route Table lleva el tráfico por la firewall y ofrece un retorno válido.
4. Las reglas firewall SFOS y, si hace falta, NAT usan zonas, hosts y servicios concretos, registran el tráfico y aplican Security Profiles adecuados.

Nunca exponer preventivamente SSH o WebAdmin a 0.0.0.0/0. Un acceso AWS restringido no sustituye una regla SFOS precisa.

Crear Auto Scaling para tráfico entrante

Auto Scaling requiere una cuenta AWS, la oferta de Marketplace Sophos Cloud Firewall (PAYG) y una cuenta Sophos Fusion con los permisos necesarios para administrar firewalls. En Sophos Fusion (antes Sophos Central), abrir My products > General settings > API credentials management, revisar las condiciones y crear una credencial con nombre, descripción y el rol Service principal firewall. Guardar Client ID y Client secret en un almacén de secretos con acceso restringido, no en un archivo de texto sin protección. La contraseña de la cuenta Sophos ID es un secreto distinto del client secret de la API.

1. En la región AWS deseada, crear un Key Pair adecuado en EC2 > Network & security > Key pairs o reutilizar uno existente. Guardar de forma segura la clave privada y anotar el nombre para SSH KeyPair Name.
2. En Marketplace, abrir View purchase options y Continue to configuration. Elegir Sophos Auto Scaling Firewall for AWS como Fulfillment option, la Software version aprobada y la Region. En Continue to launch, elegir la acción Launch CloudFormation, pulsar Launch y, en CloudFormation, Next.
3. Asignar un Stack name único. Comprobar que AMI ID corresponde a la oferta y versión elegidas y seleccionar en Instance size un tamaño ofrecido con rendimiento suficiente. En AvailabilityZone 1 for deployment y AvailabilityZone 2 for deployment, seleccionar dos AZ distintas.
4. VPC nueva: en Network Address Prefix for new VPC, introducir los dos primeros octetos de un rango planificado sin conflictos; dejar vacíos los campos de VPC existente. VPC existente: dejar el parámetro de prefijo sin cambios e introducir Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 y Existing private subnet ID según el plan. Las subredes públicas deben pertenecer a las AZ elegidas y tener activado Auto-assign public IPv4 address. Comprobar también las rutas y las NACL.
5. Establecer el nombre del firewall, Admin Password para WebAdmin/CLI, Secure Storage Master Key Password y SSH KeyPair Name. Proteger las dos contraseñas del firewall por separado del secreto de la API.
6. Introducir Sophos ID email address y Sophos ID password de la cuenta prevista, Sophos Central client ID, Sophos Central client secret y Sophos Central AS Group name. Los nombres de los campos Central pueden seguir apareciendo en la plantilla pese al cambio de marca a Fusion; el grupo se crea automáticamente en la cuenta correspondiente. No incluir secretos en tickets, capturas de pantalla ni archivos de parámetros públicos.
7. Configurar los siguientes parámetros de red, capacidad y logs. En I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy, tras revisar las condiciones, introducir exactamente yes; respetar las mayúsculas y minúsculas. Elegir de forma consciente una opción para Opt in to the customer experience improvement program.
8. Pulsar Next para abrir las opciones del stack, establecer tags de responsable y costes y revisar los permisos IAM solicitados. Solo entonces confirmar I acknowledge that AWS CloudFormation might create IAM resources, revisar el resumen completo e iniciar con Submit.

Tras CREATE_COMPLETE, comprobar las instancias EC2 y, en My products > Firewall management > Firewalls, el grupo creado automáticamente con todos los workers PAYG esperados y aprobados. Confirmar la sincronización de la policy antes de exponer un servicio. Si falta un worker o falla el registro, no abrir más puertos; revisar Stack Events, el acceso de red y la asociación de cuenta/API sin registrar secretos. Cambiar la capacidad posteriormente en EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit y confirmar con Update. Documentar de forma inequívoca el ID de instancia, la AZ y el nombre del firewall; volver a comprobar cada cambio de capacidad frente a la pertenencia al grupo y Target Health.

DNAT detrás del Network Load Balancer

El requisito previo es un despliegue Auto Scaling operativo y verificado. Para un servicio TCP aprobado, el listener NLB dirige el tráfico a una Target Group de workers firewall, no directamente al backend. El siguiente esquema original muestra un recorrido de ejemplo para HTTPS, no una conexión medida:

Cliente permitido : puerto de origen efímero
                 | TCP puerto de destino 443
          Listener TCP NLB :443
                 |
       Target Group de workers firewall
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT al backend :443
          SNAT = MASQ del worker
                 |
          Servidor de aplicaciones interno :443
                 | Respuesta
          Mismo worker -> NLB -> Cliente

Esquema: dos AZ, un PortB activo por worker y un recorrido de retorno con MASQ. Las flechas describen el recorrido lógico de los datos; el balanceo de carga no garantiza un uso uniforme. Adaptar todos los valores de ejemplo al servicio aprobado.

1. En Fusion, en My products > Firewall management > Firewalls, abrir Manage policy en el conjunto correcto de firewalls Auto Scaling. En Hosts and services > IP host, crear dos rangos IP IPv4 para las subredes WAN reales de ambas AZ y un host IPv4 para el servidor interno. No incluir la primera dirección de cada subred; incluir solo direcciones realmente utilizables por los workers, ninguna dirección reservada por AWS.
2. En Hosts and services > Services, crear un servicio TCP/UDP con Protocol TCP. Para este establecimiento de conexión entrante, el puerto efímero del cliente es el origen y el puerto del servicio publicado es el destino. La siguiente dirección se aplica a la solicitud, no a la respuesta; no se abren adicionalmente 3389 ni 8080.

3. Guardar la regla firewall en Rules and policies > Firewall rules y la regla NAT en Rules and policies > NAT rules dentro de la policy de grupo. Comprobar la sincronización en cada worker en ejecución.
4. En EC2 > Load balancing > Target groups > Create target group, elegir Instances, un nombre único, Protocol TCP, Port 443 y la VPC del despliegue. Adaptar de forma consciente el protocolo, el puerto y, si corresponde, la ruta del health check al servicio verificado. Durante la creación, no seleccionar manualmente ninguna instancia en Available instances, especialmente el servidor backend.
5. En EC2 > Auto scaling > Auto scaling groups, elegir la ASG del firewall y asociar la Target Group en Integrations > Load balancing > Edit; confirmar con Update. Con ello, la ASG registra automáticamente sus workers, incluidos los que se inicien posteriormente.
6. Antes de iniciar el listener, comprobar en Load balancers la asociación de Security Groups del NLB real de la plantilla. Si el NLB se creó sin una Security Group, no se puede añadir ninguna posteriormente. En ese caso, no habilitar un listener público hasta que se haya aprobado un recorrido compatible y restringido por origen; como alternativa, usar VPN/ZTNA. No modificar a ciegas la plantilla administrada ni prometer que se podrá asociar una SG más adelante.
7. Si existe el recorrido restrictivo, configurar en el NLB, en Listeners > Add listener, TCP y el puerto 443, con la Target Group de workers como Default action. Limitar la SG del NLB a los CIDR de clientes permitidos y al puerto del listener; en el worker, permitir por separado los puertos de destino y health check que necesita el NLB. El egress del NLB debe poder alcanzar los health checks. El acceso de un health check no equivale a una apertura pública de la aplicación. Restringir también el acceso directo a los workers y al backend.
8. Antes del uso en producción, comprobar que los workers esperados de ambas AZ y un worker recién iniciado en la ventana de cambio aprobada aparecen automáticamente en la Target Group y superan los health checks previstos. Mediante el nombre DNS del NLB, comprobar el flujo positivo de la aplicación y un intento negativo desde un origen no permitido; Log Viewer debe mostrar la regla esperada y DNAT/MASQ. No confiar únicamente en healthy.

No se recomienda RDP público directo; preferir VPN o ZTNA. Si un target sigue unhealthy, comprobar primero la asociación con la ASG, la policy sincronizada, el puerto/ruta del health check, el egress del NLB, la SG del worker y la NACL. Si el backend o el recorrido de retorno son incorrectos, mantener el listener cerrado y corregir NAT/servicio/ruta. Para interpretar los puertos, seguir la dirección de la solicitud en el recorrido cliente-listener-backend.

Validar un flujo capa por capa

Anotar un flujo inicial, por ejemplo 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. El puerto de origen es solo un ejemplo de puerto cliente efímero. Comprobar en orden:

1. DNS y listener NLB apuntan al destino esperado y Target Group muestra los workers healthy.
2. Security Groups y NACL permiten exactamente solicitud y retorno.
3. Route Tables y ENI envían tráfico por la appliance; Source/Destination Check está desactivado en interfaces de tránsito.
4. SFOS Log Viewer muestra la Rule ID prevista. Para DNAT, destinos original y traducido y retorno son correctos.
5. La prueba autorizada llega a la aplicación y otra desde un origen no autorizado queda bloqueada.

Si no hay log SFOS, revisar DNS, listener, Target Health, Security Group, NACL y route. Ante un drop con Rule ID inesperada, corregir zonas, objetos de red, servicio y orden. Si llega la solicitud sin respuesta, comprobar Route Table, NACL, default gateway del servidor y, con Auto Scaling, MASQ.

Operar y recuperar

Standalone y Auto Scaling requieren runbooks distintos. Para standalone, documentar un backup SFOS y restauración probada, el proceso de firmware, los parámetros CloudFormation y una prueba de reconstrucción. Un snapshot EC2 no sustituye un backup SFOS exportado.

Los workers Auto Scaling son efímeros. Con CloudWatch, los logs aparecen bajo /sophos/xg/; configurar retención, cifrado, acceso y costes. Las instancias EC2 terminadas permanecen en el grupo Fusion y deben eliminarse manualmente. Warm Pool no sustituye comprobar la policy actual en cada worker.

El registro operativo incluye tags de responsable y costes, alertas presupuestarias, licencia, rotación de secretos, retención CloudWatch, limpieza Fusion, aprobación de firmware, pruebas de cambios y recuperación. Repetir las pruebas positiva y negativa tras cada cambio de plantilla, routing o policy.

Detener el cambio y revertirlo de forma selectiva

Antes del cambio, guardar los parámetros del stack y los ID de recursos, la asociación listener/Target Group, SG/NACL/Route Tables, así como la policy de grupo SFOS y el backup. Si el destino es incorrecto, aparece un origen inesperado, falta sincronización de la policy o se interrumpe una conexión existente, cerrar primero el listener recién añadido o la nueva exposición; después, devolver únicamente las reglas y rutas recién introducidas al estado seguro documentado. Volver a comprobar el tráfico existente y el bloqueo de orígenes no permitidos. No eliminar una VPC compartida, subredes, un gateway ni listeners existentes para resolver un problema.

Para la retirada planificada de PAYG no basta con terminar workers individuales: la ASG puede volver a crearlos. Primero, eliminar la nueva exposición, realizar la retirada aprobada mediante el ciclo de vida del stack/ASG y comprobar que ni las acciones de scaling ni las instancias del Warm Pool vuelven a iniciar workers. Eliminar todas las instancias firewall PAYG correspondientes y comprobar el inventario real de recursos. Evaluar individualmente los volúmenes retenidos, EIP, NLB, Log Groups y otros recursos de pago según la lista de recursos, sin eliminarlos de forma indiscriminada; eliminar del grupo Fusion los workers terminados. Comprobar después la facturación y el control de costes. Antes de retirar la instancia, confirmar el inventario de dependencias y una vía de restauración para los servicios necesarios.