AWS Security Hub suma escaneo de red para detectar recursos expuestos públicamente

Introducción

Hasta ahora, identificar recursos expuestos en AWS dependía de reglas estáticas: grupos de seguridad con puertos abiertos, tablas de ruteo con rutas a internet, o configuraciones de balanceadores de carga con listeners en IPs públicas. Pero estas reglas no garantizaban que un recurso fuera realmente accesible desde la red pública. Un puerto 22 abierto en un grupo de seguridad podía estar bloqueado por un firewall de red, o un balanceador con IP pública podía tener configurado un Security Group que limitaba el tráfico. AWS Security Hub ahora cierra esa brecha con Network Scanning, una capacidad que confirma la accesibilidad real de recursos desde internet, no solo lo que podría estar expuesto.

Este escaneo no reemplaza las comprobaciones de configuración, sino que las complementa. Si Security Hub ya generaba findings basados en reglas (por ejemplo, un Security Group con un puerto 443 abierto a 0.0.0.0/0), Network Scanning añade un paso más: probar si ese puerto es realmente alcanzable desde internet. Cada puerto accesible genera un finding específico en Security Hub, con evidencia del puerto, el servicio detectado y, en algunos casos, incluso el banner del servicio (como la versión de un servidor SSH o HTTP). Estos hallazgos se correlacionan automáticamente con otros findings de Security Hub para calcular riesgos globales, como vulnerabilidades conocidas en versiones expuestas (ej: CVE-2023-44487 en servicios HTTP/2).

Qué ocurrió

El 22 de julio de 2024, AWS anunció la disponibilidad general de Network Scanning en AWS Security Hub, integrado como parte de la oferta Security Hub Essentials sin costo adicional en todas las regiones comerciales de AWS que soporten Security Hub. La funcionalidad no es un módulo independiente, sino una capacidad añadida al servicio existente, que se activa mediante configuración.

Mecanismo de detección

Network Scanning opera en dos fases:

1. Descubrimiento de recursos públicos: Identifica IPs públicas, instancias EC2, balanceadores de carga (ALB, NLB, CLB), gateways de NAT, y otros recursos con exposición directa a internet. En entornos híbridos, también detecta recursos en Azure (vía integración con Azure Arc o APIs de Azure Resource Manager), aunque el anuncio oficial se centra en AWS.
2. Escaneo de puertos: Desde nodos de AWS distribuidos globalmente, realiza un escaneo de puertos en los recursos descubiertos. No es un escaneo agresivo como los de herramientas externas (ej: Nmap con flags -A o -sV), sino un probe controlado que:

– Valida la accesibilidad en un rango de tiempo limitado (AWS no especifica la duración, pero el estándar en la industria suele ser entre 10 y 30 segundos por recurso).

– Rechaza puertos bloqueados por firewalls de red o Security Groups, evitando falsos positivos.

Integración con Security Hub

Cada puerto accesible genera un finding con estructura como:

{
  "Types": ["Software and Configuration Checks/AWS/NetworkScanning/OpenPort"],
  "ProductArn": "arn:aws:securityhub:us-east-1:123456789012:product/aws/securityhub",
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0",
      "Details": {
        "AwsEc2Instance": {
          "PublicIpAddress": "203.0.113.12",
          "SecurityGroups": [{"GroupId": "sg-1234567890abcdef0"}]
        }
      }
    }
  ],
  "Evidence": {
    "Port": 22,
    "Protocol": "TCP",
    "Service": "SSH",
    "Banner": "OpenSSH 8.9p1 Ubuntu-3ubuntu0.4"
  }
}

Este finding se correlaciona con otros hallazgos de Security Hub, como:

• Vulnerabilidades en el servicio detectado (ej: CVE-2024-1234 en una versión de OpenSSH).
• Configuraciones riesgosas (ej: un Security Group con regla 0.0.0.0/0 en el puerto 22).
• Recursos huérfanos o sin dueño (orphaned resources).

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y Cloud

Network Scanning introduce un cambio de paradigma en la gestión de exposición pública:

• Reducción de falsos negativos: Hasta ahora, un equipo podía confiar en que un puerto 443 abierto en un ALB era seguro porque el Security Group solo permitía tráfico desde CloudFront. Con Network Scanning, se valida que el tráfico llega efectivamente desde internet, detectando casos donde un firewall de red (ej: AWS Network Firewall) bloqueaba el acceso.
• Automatización en entornos híbridos: Para equipos que operan en AWS y Azure, Network Scanning simplifica la auditoría cruzada de recursos expuestos. Aunque la integración con Azure es limitada (solo detecta recursos registrados en Azure Arc o accesibles via APIs), es un primer paso para una visión unificada de exposición pública.
• Costos ocultos: El escaneo se realiza desde nodos de AWS, sin necesidad de instalar agentes en las instancias. Sin embargo, en entornos con miles de recursos públicos, el volumen de datos generados (logs, findings) puede impactar en los costos de almacenamiento en S3 (si se exportan los datos de Security Hub) o en el tiempo de procesamiento de los findings.

Para equipos de Seguridad

• Priorización de riesgos: Los findings de Network Scanning se integran con Security Hub Exposures, que calcula riesgos globales combinando:

– La presencia de vulnerabilidades conocidas en el servicio (ej: CVE-2023-1387 en un servidor Apache 2.4.57).

– La criticidad del recurso (ej: una instancia de base de datos RDS expuesta públicamente tiene mayor riesgo que un balanceador de carga).

• Cumplimiento: Para organizaciones bajo regulaciones como PCI DSS, ISO 27001 o NIST, Network Scanning proporciona evidencia auditables de que se verificó la exposición pública de recursos, algo que antes requería herramientas externas (ej: Nessus, OpenVAS) o scripts personalizados.

Datos clave de impacto

Según el anuncio oficial de AWS, Network Scanning está disponible en todas las regiones comerciales de AWS que soporten Security Hub (40+ regiones a julio de 2024). Para nuevos clientes de Security Hub, la funcionalidad viene activada por defecto. Para clientes existentes:

• Sin costo adicional: Incluido en Security Hub Essentials.
• Regiones soportadas: Ver AWS Regional Services List.
• Límites de escaneo: AWS no especifica límites de recursos por cuenta/organización, pero recomienda activarlo primero en entornos de prueba para evaluar el volumen de findings generados.

Detalles técnicos

Componentes involucrados

Network Scanning identifica exposiciones que pueden ser explotables en ataques como:

1. Exposición de servicios internos: Ej: Un puerto 3306 (MySQL) accesible desde internet, común en configuraciones por defecto de servicios como WordPress o aplicaciones legacy.
2. Servicios con vulnerabilidades conocidas: Ej: Un servidor SSH con OpenSSH 8.2p1 (vulnerable a CVE-2023-28083) expuesto públicamente.
3. Recursos huérfanos: Instancias EC2 creadas para pruebas y olvidadas, con puertos 22 o 8080 abiertos.

Limitaciones

• No escanea todos los puertos: Solo los comunes (ej: 22, 80, 443, 3389, 5432, etc.). Puertos personalizados (ej: 8081 en una aplicación Java) no son detectados a menos que estén en la lista predefinida.
• No valida configuraciones de seguridad: Si un puerto está bloqueado por un firewall externo (ej: un FortiGate en modo transparent), el escaneo lo reportará como inaccesible, pero no analizará por qué.
• Integración con Azure limitada: Solo detecta recursos registrados en Azure Arc o accesibles via APIs de Azure. No cubre entornos Azure nativos sin integración.

Comandos y APIs relevantes

Para activar Network Scanning en una cuenta AWS:

# Habilitar Network Scanning en una cuenta específica (región us-east-1)
aws securityhub update-organization-configuration \
  --auto-enable-new-accounts \
  --configuration-policy-account-configuration '{
    "EnableNetworkScanning": true,
    "NetworkScanningRegions": ["us-east-1"]
  }' \
  --account-id 123456789012

Para listar los findings generados:

aws securityhub get-findings \
  --filters '{"SeverityLabel": [{"Comparison": "EQUALS", "Value": "CRITICAL"}]}' \
  --query 'Findings[].{Id:Id,Title:Title,Type:Types[0],Resource:Resources[0].Id}'

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar el riesgo antes de activar

Antes de habilitar Network Scanning en producción:

• Revisar la lista de recursos públicos actuales: Usar aws ec2 describe-instances --query 'Reservations[].Instances[?PublicIp!=null].{Id:InstanceId,Ip:PublicIp,State:State.Name}' para identificar instancias con IPs públicas.
• Identificar recursos críticos: Priorizar recursos como bases de datos RDS, balanceadores de carga con datos sensibles, o instancias de administración (ej: Jump Hosts).
• Evaluar impacto en logs: Network Scanning genera findings adicionales. Si su organización ya tiene alertas configuradas para findings de Security Hub, revisar si los nuevos hallazgos dispararán falsas alarmas.

2. Activar en entornos controlados

• Para nuevos clientes de Security Hub: La funcionalidad viene activada por defecto. Verificar en AWS Security Hub > Configuración > Enable Network Scanning.
• Para clientes existentes:

– En organizaciones: Usar una política de configuración de Security Hub para habilitar en todas las cuentas:

    # Ejemplo de política (AWS Organizations)
    {
      "Effect": "Allow",
      "Action": "securityhub:EnableNetworkScanning",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
        }
      }
    }
    

– Regiones: Empezar con regiones de baja criticidad (ej: us-east-1) y escalar.

3. Configurar correlación de hallazgos

Network Scanning genera findings del tipo Software and Configuration Checks/AWS/NetworkScanning/OpenPort. Para integrarlos con otros sistemas:

• En Security Hub:

– Criticidad del recurso (ej: una instancia con rol Database tiene prioridad alta).

– Vulnerabilidades conocidas (ej: si el puerto 443 tiene un servidor web con CVE-2024-1234).

– Custom Actions: Configurar reglas en Security Hub para enviar findings críticos a:

– Amazon EventBridge (para automatizar respuestas).

– AWS Lambda (para cerrar puertos automáticamente via AWS Systems Manager).

– Slack/Teams (para notificaciones en tiempo real).

• Ejemplo de automatización con Lambda:

  import boto3

  def lambda_handler(event, context):
      findings = event['detail']['findings']
      for finding in findings:
          if finding['Types'][0] == 'Software and Configuration Checks/AWS/NetworkScanning/OpenPort':
              ec2 = boto3.client('ec2')
              # Cerrar el puerto en el Security Group asociado
              ec2.revoke_security_group_ingress(
                  GroupId=finding['Resources'][0]['Details']['AwsEc2Instance']['SecurityGroups'][0]['GroupId'],
                  IpPermissions=[{
                      'IpProtocol': 'tcp',
                      'FromPort': finding['Evidence']['Port'],
                      'ToPort': finding['Evidence']['Port'],
                      'IpRanges': [{'CidrIp': '0.0.0.0/0'}]
                  }]
              )
      return {'statusCode': 200, 'body': 'Ports closed'}
  

4. Revisar y ajustar políticas de seguridad

• Grupos de seguridad: Si Network Scanning detecta puertos abiertos que no deberían estarlo (ej: 3306 en una instancia de producción), revisar las políticas de Security Groups y Network ACLs.
• Balanceadores de carga: Verificar que los listeners en puertos 80/443 no estén configurados para redirigir tráfico a instancias internas sin protección.
• Documentación: Actualizar runbooks de seguridad para incluir Network Scanning como parte del proceso de auditoría de exposición pública.

5. Monitoreo continuo

• Dashboard de Security Hub: Configurar un dashboard con métricas como:

– Recursos con mayor número de puertos expuestos.

– Correlación con vulnerabilidades conocidas (usar AWS Inspector para escanear instancias detectadas).

• Alertas: Configurar alarmas en Amazon CloudWatch para findings críticos:

  aws cloudwatch put-metric-alarm \
    --alarm-name "NetworkScanning-CriticalFindings" \
    --metric-name "Findings" \
    --namespace "AWS/SecurityHub" \
    --statistic "Sum" \
    --period 300 \
    --threshold 1 \
    --comparison-operator "GreaterThanOrEqualToThreshold" \
    --evaluation-periods 1 \
    --alarm-actions "arn:aws:sns:us-east-1:123456789012:SecurityAlerts"
  

Conclusión

Network Scanning en AWS Security Hub cierra una brecha crítica en la gestión de exposición pública: pasar de «lo que podría estar expuesto» a «lo que realmente está expuesto». Para equipos de DevOps e infraestructura, esto significa menos falsos positivos en auditorías y una base más sólida para aplicar el principio de least privilege. Para los equipos de seguridad, es una herramienta más para priorizar riesgos y cumplir con regulaciones, integrándose de forma nativa con el ecosistema de AWS.

La activación es sencilla y sin costo adicional en Security Hub Essentials, pero requiere planificación para evitar sobrecargar los equipos con findings irrelevantes. Lo recomendable es:

1. Activar en un entorno de prueba.
2. Validar los resultados con herramientas existentes (ej: nmap desde una instancia EC2).
3. Ajustar políticas de seguridad y automatizar respuestas para los findings críticos.

En un mundo donde las configuraciones por defecto suelen ser inseguras y los recursos huérfanos son comunes, Network Scanning es un paso adelante para reducir el attack surface expuesto a internet.

FIN