Ir al contenido
Avanet

Implementar Sophos NDR en AWS

Sophos NDR

Sophos NDR se ejecuta en AWS como un dispositivo de integración basado en EC2. Recibe una copia del tráfico seleccionado de la VPC mediante VPC Traffic Mirroring, lo analiza de forma pasiva y envía los datos de NDR a Sophos Data Lake. El dispositivo no está en línea ni sustituye a los Security Groups ni a un firewall.

El proceso general fiable consiste en aclarar las licencias y responsabilidades, documentar los datos de la red de AWS, crear el dispositivo en Sophos Fusion, descargar la plantilla de CloudFormation generada, suscribirse a la oferta de Marketplace, crear la pila, añadir exactamente una Mirror Session controlada, restringir el acceso de administración y validar cada capa por separado.

⚠️ Este runbook no incluye deliberadamente un desmantelamiento completo. No se han verificado por completo la secuencia segura ni las consecuencias de eliminar recursos de la pila, el dispositivo, EC2, EBS, ENI, Security Group, Elastic IP, duplicación y Marketplace. Por tanto, una implementación fallida no debe «limpiarse» mediante una secuencia de eliminación improvisada.

Arquitectura y decisiones antes de empezar

CloudFormation crea dos rutas de red separadas lógicamente:

  • La Management Interface se encuentra en una Public Subnet y utiliza una Elastic IP Address asignada. Esta ruta se utiliza para SSH y para acceder a Sophos Appliance Manager.
  • La SPAN interface recibe el tráfico reflejado. El NDR SPAN Target que crea la plantilla sirve como Mirror Target.
  • Una Traffic mirror session conecta una ENI de origen seleccionada con este destino. El NDR Traffic Mirror Filter, que también crea la plantilla, determina qué paquetes se reflejan.
  • El dispositivo procesa las copias y envía los datos de NDR a Sophos. Los flujos originales permanecen en su ruta de datos habitual de AWS.

Por tanto, la decisión de diseño más importante no es «¿qué VPC completa debemos supervisar?», sino qué ENI es una Mirror Source adecuada. Empiece con una única ENI documentada perteneciente a un sistema de prueba. Así se mantienen reducidos el volumen de datos, los costes y el alcance de los posibles errores. Añada más orígenes solo después de la aceptación técnica.

Como mínimo, documente lo siguiente en un plan de implementación antes de comenzar:

  • cuenta de AWS, Region, VPC, Availability Zone y etiquetas de propietario;
  • ID de la VPC e ID de las Management y SPAN Subnet;
  • al menos una Elastic IP asignada en la cuenta de AWS para la Management Interface; es un requisito previo de la cuenta, pero la lista de parámetros documentada no la presenta como una entrada de plantilla que pueda seleccionarse de antemano;
  • tipos de EC2 que Sophos admite actualmente: c5n.2xlarge, c6i.4xlarge o c7i.16xlarge con virtualización Nitro; compruebe el tipo utilizado realmente tanto en la plantilla actual del tenant como en la instancia después de la implementación;
  • nombre del SSH Key Pair existente y ubicación segura del Private Key;
  • un Security Group para SSH y redes de origen fijas de los administradores;
  • la ENI que será la Mirror Source inicial y el equipo de carga de trabajo responsable de ella;
  • el tráfico de prueba normal esperado para esta ENI;
  • centro de costes, alarma de presupuesto y aprobación de los costes de infraestructura de AWS, además de las condiciones de Marketplace que se muestren para esta cuenta.

VPC, Subnets y Elastic IP

Puede utilizar una VPC y Subnets existentes. No base la selección únicamente en sus nombres:

  • Planifique la Management Subnet como una Public Subnet. Compruebe su Route Table y la ruta a Internet prevista antes de seleccionarla.
  • Especifique la SPAN Subnet para la NDR SPAN interface. Registre la Subnet y la Availability Zone junto con la Mirror Source, en vez de deducir después los valores a partir de los nombres de los recursos.
  • La Elastic IP corresponde a la Management Interface, no al lado SPAN. Asegúrese de antemano de que haya al menos una Elastic IP asignada en la cuenta. No afirme que la pila utiliza una dirección existente concreta: después de CREATE_COMPLETE, determine y registre la dirección que se haya creado o utilizado realmente y su asociación con la ENI.
  • La plantilla selecciona automáticamente la AMI y la Region en función de la Region de AWS en la que se carga. No fuerce otra AMI modificando manualmente la plantilla.

Security Groups y SSH Key Pair

Utilice un AWS Key Pair existente cuyo Private Key ya esté almacenado de forma segura. CloudFormation requiere el nombre del Key Pair; el Private Key no se almacena en Sophos Fusion ni en la plantilla. Sin el Private Key, el acceso SSH que Sophos documenta para el dispositivo de AWS no estará disponible más adelante.

Prepare un Security Group que permita SSH solo desde la red de acceso administrativo, por ejemplo, desde una IP fija de salida corporativa como /32 o mediante un Jump Host controlado. No exponga SSH ni TCP 8443 a 0.0.0.0/0.

La plantilla también crea InternalMgmtSG. Después de la implementación, permita allí TCP 8443 solo para los orígenes reales de los administradores. Si el mismo dispositivo también aloja un Log Collector, permita Syslog únicamente con el protocolo y el puerto que requiera el conector correspondiente y solo desde redes de origen internas. VPC Traffic Mirroring no requiere por sí mismo una regla general de Syslog desde Internet.

Validar de antemano la conectividad saliente

Una Public Subnet y una Elastic IP no demuestran por sí solas que exista una ruta saliente operativa. Antes de Submit, el equipo de red responsable debe confirmar que la Management Interface puede comunicarse hacia el exterior a través de la ruta prevista y de un Internet Gateway o del diseño de salida centralizado aprobado. Compruebe la resolución DNS, la Route Table, la Network ACL, la salida del Security Group y las reglas del proxy y del firewall ascendente.

Los destinos y puertos necesarios no se reproducen en este runbook. En su lugar, en el momento del cambio, compare las exclusiones actuales de puertos y dominios para dispositivos Sophos con las reglas de salida. Estas excepciones son relevantes para el arranque, las actualizaciones, el registro y la carga de datos; demostrar la conectividad con un único destino no sustituye la comparación completa.

Requisitos previos, funciones, licencia y costes

La configuración requiere:

  • una cuenta de AWS con una VPC, Subnets y Availability Zones existentes;
  • una cuenta de Sophos Fusion;
  • por lo general, el Sophos Network Detection and Response integration license pack;
  • al menos una instancia EC2 de origen adecuada o su ENI;
  • al menos una Elastic IP Address asignada en la cuenta de AWS;
  • un AWS SSH Key Pair almacenado;
  • una aprobación de cambio vigente para la duplicación de red y los datos que se procesen mediante ella.

Siempre que sea posible, distribuya el trabajo de la siguiente manera, sin inventar nombres de políticas de IAM no confirmados:

  • Un administrador de Sophos Fusion crea la configuración de NDR y descarga la plantilla.
  • Una persona autorizada para realizar adquisiciones acepta las condiciones de Sophos Integration Appliance en AWS Marketplace.
  • Un administrador de AWS con los permisos necesarios para la pila y los recursos de red referenciados crea los recursos de CloudFormation, EC2, VPC Traffic Mirroring, Security Group y Elastic IP.
  • El equipo de red o de carga de trabajo responsable confirma la Mirror Source, el comportamiento del filtro, el periodo de prueba y el tráfico esperado.

Sophos no identifica un rol mínimo de Fusion específico para NDR e independiente para este proceso. Por tanto, si Add Configuration, Download image u Open Appliance Manager no están visibles, no haga suposiciones: un Super Admin debe comprobar los permisos efectivos del tenant y la licencia.

La única excepción que se contempla aquí está definida de forma estricta: para clientes MSP Flex con una licencia XDR, Sophos documenta que Sophos NDR puede integrarse sin un Integration License Pack adicional. Esto no significa que todas las suscripciones XDR o MDR incluyan NDR, ni que la excepción se aplique a las licencias Term. Por tanto, confirme el derecho específico del tenant/SKU en Fusion y, si existe alguna duda, con Sophos o el socio de compras mediante las reglas actuales de licencias de integración de Sophos.

CloudFormation crea recursos de AWS facturables. El dispositivo virtual está incluido en el derecho de Sophos NDR aplicable; de ello no se deduce aquí ningún precio de catálogo público ni ninguna afirmación sobre la oferta de Marketplace concreta de la cuenta. Compruebe las condiciones de Marketplace que se muestren en ese momento antes de pulsar Submit. Calcule por separado las categorías de AWS correspondientes a EC2, almacenamiento, dirección IPv4 pública/Elastic IP, transferencia de datos y VPC Traffic Mirroring. Este runbook no proporciona deliberadamente importes fijos: la Region, el tiempo de ejecución, el volumen de datos y el modelo de precios de AWS modifican el cálculo. Las etiquetas y una alarma de presupuesto deben incluirse en el cambio antes de comenzar la duplicación en producción.

1. Crear el dispositivo y la plantilla de CloudFormation en Sophos Fusion

  1. En Sophos Fusion, abra Threat Analysis Center > Integrations > Marketplace.
  2. Abra Sophos Network Detection and Response (NDR).
  3. En Data Ingest (Security Alerts), haga clic en Add Configuration.
  4. En Step 1, introduzca un nombre y una descripción únicos, por ejemplo ndr-aws-prod-eu1 y NDR Sensor für AWS Produktions-VPC eu1.
  5. En Step 2, bajo Virtual platform, seleccione AWS.
  6. Haga clic en Save. Sophos genera el archivo de CloudFormation aws_ndr_cf_latest.json.
  7. Abra Threat Analysis Center > Integrations > Configured y, a continuación, la pestaña Integration Appliances.
  8. Busque el dispositivo que acaba de crear. En la columna derecha, abra el menú de tres puntos, seleccione Download image y guarde aws_ndr_cf_latest.json en la carpeta protegida del cambio.

El JSON procede de su propio tenant de Fusion y del dispositivo que acaba de crear. No utilice un archivo antiguo de otro tenant o cambio. No modifique manualmente la plantilla para forzar tipos de instancia, AMI o variantes de red no admitidos.

2. Suscribirse a la oferta de Marketplace

  1. Busque Sophos Integration Appliance en AWS Marketplace.
  2. En la página Product Overview, haga clic en Continue to Subscribe.
  3. En Subscribe to this software, revise las condiciones y acéptelas solo con la aprobación de compras prevista. Después, haga clic en Continue to Configuration.
  4. En Configure this software, compruebe la versión y la Region. Deben coincidir con el plan de implementación. Haga clic en Continue to Launch.
  5. En Launch this software, abra primero Usage instructions y documente las instrucciones de acceso mostradas.
  6. Haga clic en Launch. AWS abre Create stack.

La suscripción de Marketplace es un requisito previo para que AWS acepte el software al que hace referencia la plantilla. Por tanto, si una AMI no está disponible o se produce un error de derechos, comience a solucionar el problema por la suscripción, la Region y la versión, en lugar de modificar el JSON.

3. Crear la pila de CloudFormation

Antes de completar el formulario, examine los parámetros de la plantilla generada actualmente desde este tenant. Si ofrece un parámetro documentado para el tipo de instancia EC2, seleccione únicamente un tipo que Sophos admita actualmente y registre el nombre y el valor del parámetro. Si no ofrece dicho parámetro, la plantilla selecciona el tipo; no edite el JSON manualmente. En ambos casos, verifique después de la creación el tipo de EC2 iniciado realmente.

  1. En Create stack, mantenga seleccionada la opción Template is ready.
  2. En Specify template, seleccione Upload a template file.
  3. Haga clic en Choose file, seleccione el archivo aws_ndr_cf_latest.json recién generado y, después, haga clic en Next.
  4. En Specify stack details, introduzca un Stack name único, como sophos-ndr-prod-eu1.
  5. En Network Configuration, introduzca:
    • la VPC existente prevista;
    • la Public Subnet para la NDR Management Interface;
    • la Subnet para la NDR SPAN interface;
    • el Security Group preparado para el acceso SSH administrativo.
  6. En EC2 Instance Configuration, seleccione el SSH Key Pair existente. Vuelva a comprobar que el Private Key puede localizarse y está protegido.
  7. Haga clic en Next. En Configure stack options, revise las etiquetas y las demás opciones de AWS. No acepte los valores predeterminados sin revisarlos; compárelos con el cambio.
  8. Revise el resumen y haga clic en Submit.
  9. Espere a que aparezca CREATE_COMPLETE. Sophos indica que normalmente tarda entre cinco y seis minutos; los eventos de CloudFormation son la referencia, no esta estimación de tiempo.

Antes de crear la Mirror Session, debe poder localizar, como mínimo, el dispositivo Sophos esperado, su tipo de EC2 real, las ENI de Management y SPAN, NDR SPAN Target, NDR Traffic Mirror Filter, InternalMgmtSG, así como la Elastic IP utilizada realmente y su asociación, en la pila o en los recursos de AWS relacionados. Si falta algún elemento o la pila no termina en CREATE_COMPLETE, no cree ninguna Mirror Session.

4. Crear una Traffic Mirror Session

No todas las ENI o topologías de EC2 sirven automáticamente como Mirror Source. Antes de crearla, consulte la documentación actual de AWS para comprobar los tipos de instancia de origen admitidos, los requisitos previos y las limitaciones del Mirror Target y la topología concreta de Source/Target, Region y Availability Zone. Compruebe también Service Quotas y las cuotas de AWS para Traffic Mirroring para confirmar que haya cuota suficiente para orígenes, sesiones, destinos y filtros. Esta revisión de AWS es un punto de aprobación independiente; la lista de Sophos de tipos de dispositivo admitidos no confirma que cualquier ENI de carga de trabajo admita la duplicación.

Abra VPC > Traffic mirror sessions > Create traffic mirror session y complete los campos deliberadamente:

  • Name Tag: un nombre descriptivo, como ndr-prod-app01;
  • Description: finalidad y referencia del cambio, como Mirror app01 ENI to Sophos NDR - CHG-1234;
  • Mirror Source: la ENI del sistema de prueba aprobado, no simplemente una instancia EC2 con un nombre parecido;
  • Mirror Target: el NDR SPAN Target creado por la pila;
  • Session number: un número adecuado para esta Source. AWS lo utiliza para establecer el orden cuando la misma Source tiene varias sesiones. Haga un inventario de las sesiones existentes antes de elegirlo;
  • VNI: 1;
  • Filter: el NDR Traffic Mirror Filter creado por la pila.

Haga clic en Create solo después de que dos personas hayan revisado Source, Target, Session number, VNI y Filter. VNI = 1 y el uso del filtro generado son requisitos del producto. En cambio, Source, nombre, descripción y Session number deben corresponder a su propio entorno de AWS.

No añada más orígenes «por si acaso» durante la prueba inicial. Una Mirror Session adicional aumenta el volumen de datos, los costes y el alcance de la investigación, por lo que requiere su propia aprobación técnica.

5. Configurar el acceso de administración y las credenciales

  1. En la consola de AWS, busque el nombre del dispositivo, seleccione la pestaña EC2 y abra la instancia Sophos Appliance.
  2. En Instance Summary, abra la pestaña Security y, a continuación, InternalMgmtSG.
  3. En Inbound rules, añada TCP 8443 únicamente para los CIDR de administrador aprobados. Documente el Rule ID, el origen y la referencia del cambio.
  4. En Sophos Fusion, abra Threat Analysis Center > Integrations > Configured > Integration Appliances.
  5. Abra el menú de tres puntos del dispositivo y seleccione Open Appliance Manager.
  6. En el cuadro de diálogo de confirmación, haga clic en reset it para establecer la contraseña.
  7. Inicie sesión con el nombre de usuario fijo zadmin y la contraseña que haya establecido.

Trate la contraseña de zadmin como un secreto con privilegios. Guárdela en el almacén de contraseñas aprobado, no en la plantilla de CloudFormation, el ticket ni una captura de pantalla. Todos los administradores utilizan la misma contraseña de Appliance Manager. Si se pierde, restablézcala mediante Open Appliance Manager > reset it.

Validar la implementación y el registro inicial

El estado en ejecución de EC2 no demuestra por sí solo ni la ruta de duplicación ni el registro. Compruebe lo siguiente en este orden:

  1. CloudFormation: La pila muestra CREATE_COMPLETE; están presentes los recursos esperados y no hay eventos omitidos o fallidos.
  2. Asociación de red: La VPC, Management Subnet, SPAN Subnet, Elastic IP, ambas ENI y SSH Key Pair coinciden con el plan de implementación.
  3. Exposición: Solo se puede acceder a SSH y TCP 8443 desde las redes de administrador aprobadas. No existe ninguna regla de administración nueva con 0.0.0.0/0.
  4. Configuración de la duplicación: La sesión apunta exactamente a la Source ENI aprobada, al NDR SPAN Target, a VNI 1 y al NDR Traffic Mirror Filter. Se han documentado el Session number y las sesiones paralelas existentes.
  5. Conexión con Sophos: El dispositivo aparece en Integration Appliances; su estado de NDR en Sophos Fusion está en verde, Open Appliance Manager abre el destino esperado y es posible iniciar sesión como zadmin.
  6. Ruta de datos preliminar: Durante el periodo de prueba aprobado, genere tráfico normal e inocuo en la Mirror Source ENI. En la pestaña NDR de Appliance Manager, compruebe el porcentaje de carga de datos, el porcentaje de captura del puerto SPAN configurado y el gráfico Total flows. Registre la hora y los valores de la medición. No es necesaria una detección para esta prueba de infraestructura.
  7. Control negativo: Un origen de administrador no aprobado no debe poder acceder a TCP 8443. Este control verifica la restricción de administración, no la detección de NDR.

Registre el Stack ID, el nombre del dispositivo, el ID y tipo de instancia, las ENI de Management y SPAN, la asociación EIP real, el Mirror Session ID, la Source ENI, el Target, el Filter, el VNI, los Security Group Rule IDs, las mediciones de NDR y el periodo de aceptación. Los secretos no deben incluirse en este registro. Esta aceptación solo confirma la implementación y el registro inicial. A continuación, valide por completo la ruta de datos reflejada con Configurar y validar Traffic Mirroring para Sophos NDR y realice después una prueba segura de detección de extremo a extremo. Ni un inicio de sesión correcto ni el tráfico de prueba habitual demuestran por sí solos que la cadena de detección funcione.

Solución de problemas por síntoma

La pila no termina en CREATE_COMPLETE

Abra primero la pestaña Events de la pila y avance desde el primer evento fallido, en lugar de retroceder desde el último error derivado.

  • Para errores de derechos de Marketplace o de la AMI: compruebe la suscripción, las condiciones aceptadas, la versión y la Region.
  • Para errores de permisos: solicite al administrador de AWS que compruebe la acción y el recurso que se indican en el evento concreto. No asigne una política general de administrador como solución rápida.
  • Para parámetros de red: compare los ID de la VPC y las Subnet, la Elastic IP asignada o la cuota de EIP disponible, el Security Group y el SSH Key Pair con el plan de implementación.
  • Para errores de capacidad o cuota: compruebe el tipo de instancia admitido seleccionado y el mensaje de error concreto de AWS. No cambie a un tipo que no ofrezca la plantilla.

Mientras la pila esté incompleta, no cree una Mirror Session ni Inbound Rules adicionales.

El dispositivo está en ejecución, pero no recibe tráfico reflejado

Compruebe la cadena en este orden:

  1. ¿Es realmente la Mirror Source la ENI por la que pasa el tráfico de prueba?
  2. ¿Es el Mirror Target el NDR SPAN Target de esta pila y no un destino con un nombre parecido de otro entorno?
  3. ¿Está VNI establecido en 1?
  4. ¿Está seleccionado el NDR Traffic Mirror Filter?
  5. ¿Entra el Session number en conflicto con el orden de evaluación previsto para otras sesiones de la misma Source?
  6. ¿Se generó realmente tráfico a través de esta ENI durante el periodo documentado?

Cambie solo una de estas variables cada vez y repita después la misma prueba. Ampliar la selección del filtro o de la Source no sustituye el análisis de la causa raíz.

No se puede crear la Mirror Session

  • Lea primero el error concreto de la API o de la consola de AWS; no cambie a la vez Source, Target y Filter.
  • Vuelva a comprobar la Source ENI y su tipo de instancia EC2 con los requisitos previos y las limitaciones actuales de AWS para Traffic Mirroring.
  • Compare la topología Source/Target y la selección de Region/Availability Zone con la documentación actual de AWS.
  • Compruebe las cuotas de Traffic Mirroring afectadas en Service Quotas. Solicite un aumento o cambie el diseño mediante el proceso habitual de cambios de AWS, en lugar de eliminar sesiones existentes sin revisarlas.

Falla el registro o la carga de NDR

Compruebe primero la ruta establecida en Validar de antemano la conectividad saliente. En particular, deben concordar el DNS, la Route Table, el Internet Gateway o el diseño de salida aprobado, la Network ACL, la salida del Security Group, el proxy y el firewall ascendente. Vuelva a comparar las reglas con las exclusiones actuales de puertos y dominios de Sophos. Según Sophos, un error de carga relacionado con una URL prefirmada de S3 suele indicar que el proxy o el firewall bloquean el tráfico saliente a Internet. No amplíe la salida de forma indiscriminada; documente el destino concreto bloqueado y permita únicamente la excepción que Sophos requiera en ese momento.

No se puede acceder a Appliance Manager mediante TCP 8443

  • Compruebe si InternalMgmtSG permite la dirección de origen pública actual del administrador.
  • Compruebe la asociación de la Elastic IP con la Management Interface y la Public Subnet seleccionada.
  • Asegúrese de que Open Appliance Manager abre el dispositivo esperado.
  • Si una regla se amplió temporalmente a 0.0.0.0/0, vuelva a cerrarla de inmediato; un acceso amplio no es un paso de diagnóstico.

Investigue un problema de contraseña solo después de que funcione la ruta de red.

Falla el inicio de sesión de zadmin o Appliance Manager está bloqueado

Si se desconoce la contraseña, utilice Open Appliance Manager > reset it en Sophos Fusion. Si el dispositivo muestra explícitamente un mensaje de bloqueo, Sophos documenta la siguiente intervención por SSH para AWS:

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

Ejecute este comando únicamente en la sesión SSH de la instancia EC2 de Sophos NDR afectada, con el Private Key seleccionado durante la implementación. Este runbook no proporciona deliberadamente un nombre de usuario del sistema operativo ni la sintaxis SSH completa porque la página de Sophos revisada no los documenta. Obtenga la identidad de conexión actual de las Usage instructions de la oferta de Marketplace suscrita o confírmela con Sophos Support; no la adivine. Antes de conectarse, compare la dirección de destino, el ID de instancia y la huella del host con el inventario de AWS. El comando cambia el estado de bloqueo, pero no establece una contraseña nueva. Utilícelo solo cuando se muestre explícitamente un bloqueo, no como solución general para el inicio de sesión. Después, pruebe la contraseña existente; si no funciona, restablézcala en Sophos Fusion. Registre el comando y el resultado, sin la contraseña ni el Private Key, en el registro del cambio.

Reversión limitada en lugar de un desmantelamiento no verificado

Antes de modificar manualmente cualquier Security Group, exporte el estado inicial o documéntelo mediante Rule IDs. Si la nueva regla de TCP 8443 o Syslog causa un problema, puede eliminar exactamente esa regla añadida manualmente y verificar el estado inicial documentado. Esta es una reversión limitada de su propio cambio de entrada, no un desmantelamiento del dispositivo NDR.

Aquí no se proporciona deliberadamente una secuencia de eliminación completa para la pila, la suscripción de Marketplace, el objeto del dispositivo, EC2/EBS, las ENI, Elastic IP, Traffic Mirror Session, Target, Filter y Security Groups. Este runbook tampoco afirma que eliminar la pila de CloudFormation resuelva todos los recursos, costes, objetos de Sophos o consecuencias para los datos asociados. Hasta que estas dependencias se hayan verificado con la documentación actual del fabricante y mediante pruebas, elimine los recursos únicamente a través de un cambio de retirada revisado por separado.