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.

Los tipos EC2 admitidos actualmente figuran en la descripción de Sophos AWS. Con BYOL no basta con elegir la instancia más grande: los recursos deben corresponder a la licencia virtual adquirida. Con PAYG, Sophos indica que los cargos de software cesan solo al eliminar todas las instancias firewall aplicables de la cuenta AWS.

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 como indica Sophos.
6. Comparar AMI y tamaño EC2 con la lista Sophos y, para BYOL, con la licencia. 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 y completar registro y basic setup.

Sophos mantiene la secuencia completa en Deploy Sophos Firewall on AWS. Los parámetros Marketplace pueden cambiar; comparar siempre los campos con esa página y la plantilla realmente abierta.

Abrir conjuntamente reglas AWS y SFOS

La plantilla activa inicialmente solo WebAdmin y SSH. IPsec, SSL VPN, RED, WAF, User Portal y aplicaciones publicadas necesitan reglas AWS correspondientes. RED usa, por ejemplo, TCP 3410.

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 Sophos Cloud Firewall (PAYG) y credenciales API de Sophos Central. En Central, abrir My products > General settings > API credentials management y crear una credencial con el rol Service principal firewall. Tratar Client ID y Client secret como una contraseña.

Elegir Sophos Auto Scaling Firewall for AWS como fulfillment. La plantilla requiere dos Availability Zones distintas. Para una VPC existente se indican dos subredes públicas y una privada; Sophos exige Auto-assign public IPv4 address en ambas subredes públicas.

Revisar especialmente:

• Trusted Network CIDR: IP pública administrativa como /32, nunca 0.0.0.0/0;
• Public Network CIDR: el ejemplo Sophos empieza con 0.0.0.0/0, abriendo a Internet los puertos no administrativos. Avanet recomienda indicar los orígenes conocidos o restringir el valor inmediatamente;
• Minimum capacity: número mínimo de workers disponibles;
• Starting capacity: workers iniciales. En su ejemplo, Sophos recomienda Maximum capacity para registrarlos juntos en el grupo Central;
• Maximum capacity: límite máximo de workers y costes;
• Warm Pool Refresh Period: intervalo para iniciar instancias detenidas y sincronizar la policy Central; el valor predeterminado documentado es cinco días;
• Use CloudWatch: envía logs de firewall a CloudWatch Logs.

Tras CREATE_COMPLETE, en My products > Firewall management > Firewalls comprobar el grupo automático y todos los workers PAYG esperados y aprobados. Solo después cambiar capacity o scaling policy. Los parámetros actuales están en Sophos Firewall with AWS Auto Scaling.

DNAT detrás del Network Load Balancer

Para un servicio publicado, un listener TCP del NLB reenvía a una Target Group de workers. En la policy de grupo Central se crean los rangos de las subredes WAN de ambas zonas, el host interno y el servicio del puerto publicado. No incluir la primera dirección IP de cada subred AWS.

En este diseño single-arm, la regla firewall coincide WAN-WAN para rangos y servicio exacto. DNAT traduce al servidor interno y usa MASQ como translated source para que el retorno atraviese el mismo worker. Después se asocian Target Group, Auto Scaling Group y listener NLB. Sophos muestra la secuencia en el DNAT use case.

El ejemplo oficial usa RDP, pero publicarlo directamente no es una recomendación. Preferir VPN o ZTNA. Si DNAT es imprescindible, limitar orígenes en NLB, AWS y SFOS, activar IPS y logging y realizar una prueba negativa.

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, parámetros CloudFormation y una 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. Según Sophos, las instancias EC2 terminadas permanecen en el grupo Central 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 Central, aprobación de firmware, pruebas de cambios y recuperación. Repetir las pruebas positiva y negativa tras cada cambio de plantilla, routing o policy.