§ 3.1 · INFRA-PORT-01-A
Crítico
Resolutor DNS recursivo abierto en ambos controladores de dominio.
Estado. Escalado de Alto en la v1 (evidencia pasiva del puerto 53 abierto) a Crítico (confirmación activa del comportamiento de resolución recursiva).
Evidencia activa — DCSvr-001 (203.0.113.11)
$ dig +time=5 +tries=1 google.com A @203.0.113.11
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16318
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
google.com. 86 IN A 172.253.122.101
google.com. 86 IN A 172.253.122.113
google.com. 86 IN A 172.253.122.100
google.com. 86 IN A 172.253.122.139
google.com. 86 IN A 172.253.122.102
google.com. 86 IN A 172.253.122.138
;; Query time: 23 msec
Evidencia activa — DCSvr-002 (203.0.113.12)
$ dig +time=5 +tries=1 google.com A @203.0.113.12
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
google.com. 120 IN A 172.253.62.138 ... (5 more rows)
;; Query time: 28 msec
Prueba de recursión — subdominio aleatorio
Demuestra que el DC está recursando, no solo devolviendo una entrada en caché.
$ dig +time=5 +tries=1 a3f9b1c2d0e4f5a8.example.com A @203.0.113.11
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5635
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; Query time: 35 msec
Un servidor no recursivo habría devuelto REFUSED. Este servidor devolvió NOERROR con una sección AUTHORITY que apunta a la zona padre — lo que demuestra que recorrió la jerarquía DNS en nuestro nombre.
Por qué es crítico
Este es el patrón de manual del "resolutor recursivo abierto". Las IP serán detectadas por:
- Open Resolver Project (openresolverproject.org) — lista pública, rastreada por atacantes.
- Shadowserver — reportes diarios distribuidos a los propietarios de redes y a los CSIRT.
- Spamhaus DROP / EDROP — si las IP se utilizan en amplificación, terminan aquí, y cualquier servidor de correo que use Spamhaus rechazará su correo saliente.
- Botnets de amplificación de DNS — una vez en las listas, los atacantes dirigen a su IP consultas con IP de origen falsificada (UDP) que generan respuestas ANY de gran tamaño. Desde la perspectiva de la víctima, su IP es el origen del ataque; usted asume el consumo de ancho de banda.
Guía de remediación
-
Primero, cree un snapshot.
az snapshot create --resource-group <rg> --name DCSvr-001-pre-fix-$(date +%Y%m%d) --source <osdisk-id>
az snapshot create --resource-group <rg> --name DCSvr-002-pre-fix-$(date +%Y%m%d) --source <osdisk-id>
-
Identifique y reemplace las reglas NSG infractoras.
En Azure Portal: cada VM de DC → Networking → Inbound port rules → busque cualquier regla con puerto de destino 53 y origen * / Internet / 0.0.0.0/0. Reemplácela por una regla que permita solo sus CIDR de confianza (oficina on-premises, pool de clientes VPN, VNet interna), y luego añada un Deny explícito sobre Internet→53 debajo de ella.
$nsg = Get-AzNetworkSecurityGroup -ResourceGroupName <rg> -Name <nsg-of-DCSvr-001>
$nsg | Set-AzNetworkSecurityRuleConfig -Name "Allow-DNS-Internal" -Access Allow `
-Protocol "*" -Direction Inbound -Priority 100 `
-SourceAddressPrefix @("10.0.0.0/8","172.16.0.0/12","<on-prem-CIDR>","<VPN-pool>") `
-SourcePortRange "*" -DestinationAddressPrefix "*" -DestinationPortRange "53"
$nsg | Set-AzNetworkSecurityRuleConfig -Name "Deny-DNS-Internet" -Access Deny `
-Protocol "*" -Direction Inbound -Priority 110 `
-SourceAddressPrefix "Internet" -SourcePortRange "*" `
-DestinationAddressPrefix "*" -DestinationPortRange "53"
$nsg | Set-AzNetworkSecurityGroup
# Repetir para DCSvr-002
-
Desactive la recursión para clientes no confiables en el propio DC (vía Bastion).
# Opción drástica — desactiva la recursión por completo (úsela si ningún cliente hacia internet la necesita)
Set-DnsServerRecursion -Enable $false
# Opción moderada — mantiene la recursión pero solo para el ámbito confiable
Set-DnsServerRecursionScope -Name "." -EnableRecursion $false
Add-DnsServerRecursionScope -Name "InternalOnly" -EnableRecursion $true
Set-DnsServerQueryResolutionPolicy -Name "InternalRecursion" `
-Action ALLOW -ServerInterfaceIP "EQ,<DC-internal-IP>" `
-ApplyOnRecursion -RecursionScope "InternalOnly"
# Active siempre la lista global de bloqueo de consultas
Set-DnsServerGlobalQueryBlockList -Enable $true -List "wpad","isatap"
-
Verificación de parches.
Get-HotFix | Where-Object { $_.HotFixID -eq 'KB4569509' } # SIGRed
Get-HotFix | Sort-Object InstalledOn -Descending | Select -First 5
-
Verifique externamente.
Vuelva a ejecutar desde cualquier host conectado a internet (o solicítelo al evaluador):
dig +time=5 +tries=1 google.com A @203.0.113.11
dig +time=5 +tries=1 google.com A @203.0.113.12
Nuevo comportamiento esperado: conexión agotada por tiempo o REFUSED. Si el flag qr rd ra sigue apareciendo con filas de respuesta, el cambio no surtió efecto.
Opción arquitectónica
a largo plazo
Migre el DNS interno a Azure DNS Private Resolver. Los DCs pierden por completo su necesidad de IP públicas, cerrando esta clase de hallazgo de forma permanente.
§ 3.2 · INFRA-PORT-01-B
Crítico
La PIP1 del VPN Gateway expone un stack de servicios Windows Communication Foundation en seis puertos.
Estado. Escalado de Medio en la v1 (un puerto de diagnóstico observado vía Shodan) a Crítico (seis puertos de superficie de servicios WCF / .NET confirmados mediante sondeo activo).
Evidencia activa — AzureVPN-PIP1 (203.0.113.21)
PORT STATE SERVICE NOTES
7999/tcp open http (Microsoft-HTTPAPI/2.0) WCF default page, "Endpoint not found"
8081/tcp open https (XML response, 1565 bytes) WCF service template (HTTP 200)
8443/tcp open https (Microsoft-HTTPAPI/2.0) Valid TLS cert, ALPN h2/http1.1
Subject: 3a4b5c6d-4444-4d55-af66-3007b882cd10.gwt.cloudapp.net
Issuer: CN=CCME G1 TLS RSA 2048 SHA256 2049 CUS CA 01
Valid: 2026-02-27 → 2027-02-23
Body: "Windows® Communication Foundation service.
Metadata publishing for this service is currently disabled."
10001/tcp open https (HTTP 200, 6437 bytes) Same WCF body
10002/tcp open https (HTTP 200, 6437 bytes) Same WCF body
20000/tcp open https (HTTP 200, 6437 bytes) Same WCF body
Para comparar — PIP2 (203.0.113.22) muestra un puerto
PORT STATE SERVICE
8083/tcp open us-srv (closes connection on direct request, no banner)
La asimetría es la prueba concluyente
Ambas PIP están asociadas al mismo recurso de Azure VPN Gateway (3a4b5c6d-4444-4d55-af66-3007b882cd10). En un despliegue activo-activo de VPN Gateway, ambas PIP deberían ser funcionalmente equivalentes — misma superficie de servicios, mismo NSG, misma imagen de gateway. El hecho de que PIP1 exponga seis puertos de gestión/.NET y PIP2 exponga uno significa que ocurre alguna de estas situaciones:
- la imagen de gateway de Microsoft está configurada de forma asimétrica — una PIP es la de "gestión primaria" y la otra la de "tráfico de cliente", en contra de la documentación de Azure que dice que activo-activo significa equivalente.
- un NSG (suyo o de Microsoft) está filtrando PIP2 pero no PIP1.
- un evento de failover dejó a PIP1 en un estado diferente al de PIP2 — posiblemente atascada a mitad de una reconfiguración.
Cualquiera de estos escenarios es un caso de soporte con Microsoft.
Por qué es crítico
Seis puertos de superficie de servicios WCF en una IP pública de cara al cliente con Microsoft-HTTPAPI/2.0 en modo kernel (http.sys) por debajo:
- Clase de CVE de http.sys. MS15-034 (CVE-2015-1635) es un RCE remoto previo a la autenticación en
http.sys que afectó a todos los servidores Windows con un listener HTTP en modo kernel. Han aparecido CVE posteriores en la misma ruta de código (CVE-2021-31166, CVE-2022-21907). Seis listeners de http.sys expuestos son seis superficies de ataque.
- CVE de deserialización de WCF. WCF tiene un largo historial de deserialización insegura (CVE-2020-0646
NetDataContractSerializer, entre varios otros). El cuerpo "Metadata publishing is currently disabled" es el valor predeterminado de WCF — no significa que los endpoints SOAP/REST subyacentes estén ausentes; significa que el intercambio de metadatos (el WSDL) está oculto. El servicio sigue escuchando.
- Usted no puede aplicar el parche desde su lado. Se trata de la imagen del sistema operativo del appliance del gateway. Microsoft controla la cadencia de parches.
- Posible configuración incorrecta gestionada por el cliente. Incluso si la intención de Microsoft es exponer solo los puertos documentados de IKE / IPsec, la asimetría entre PIP1 y PIP2 sugiere que algo de su lado o del de ellos difiere entre ambas — y le conviene investigar esa diferencia.
Guía de remediación
-
Documente la asimetría en un caso de soporte de Azure.
Título sugerido:
Azure VPN Gateway PIPs 203.0.113.21 and 203.0.113.22 show asymmetric port exposure — PIP1 exposes ports 7999, 8081, 8443, 10001, 10002, 20000 (Microsoft-HTTPAPI/2.0 + WCF “Endpoint not found”); PIP2 exposes only 8083. Both are bound to the same gateway resource 3a4b5c6d-4444-4d55-af66-3007b882cd10. Please confirm: (a) is this asymmetry intended? (b) is the WCF management plane on PIP1 reachable from public internet by design or by misconfiguration? (c) confirm patch level of http.sys against MS15-034 / CVE-2021-31166 / CVE-2022-21907; (d) if not intended, how do we suppress?
Adjunte: la salida de nmap, los detalles del certificado TLS del 8443, el cuerpo HTML devuelto por 7999 / 8081 / 10001 / 10002 / 20000 y el ID de este informe.
Severidad en el esquema de clasificación de casos de Microsoft: B (Moderada) como mínimo; súbala a A (Crítica) si Microsoft se resiste o no responde de forma sustancial — la desalineación activo-activo también puede afectar el failover de la VPN, lo que constituye un riesgo de producción.
-
Confirme el SKU del gateway y la antigüedad de la imagen.
az network vnet-gateway show --resource-group <rg> --name <vpn-gw-name> \
--query "{sku:sku, generation:vpnGatewayGeneration, type:gatewayType, vpnType:vpnType, activeActive:activeActive, enableBgp:enableBgp}"
Aceptable: VpnGw1 en adelante, vpnGatewayGeneration: Generation2.
No aceptable: Basic, Generation1. Si está en Basic, planifique una migración a VpnGw1AZ o superior (con redundancia de zona) — la migración provocará una breve regeneración de la imagen del gateway que también puede limpiar el estado asimétrico.
-
Confirme el certificado.
El certificado TLS del 8443 tiene fecha 2026-02-27 → 2027-02-23 y encadena a CCME G1 TLS RSA 2048 SHA256 2049 CUS CA 01 (Microsoft Cloud-Managed Endpoint). Es consistente con un gateway al que se le renovaron las claves recientemente. Si el certificado es anterior a un evento de mantenimiento conocido del Azure VPN Gateway de Microsoft, ese evento pudo haber reintroducido la exposición asimétrica — anote la fecha en el ticket de soporte.
-
Control compensatorio.
Su NSG de cliente no puede cerrar directamente los listeners del lado del gateway, pero puede documentar la exposición y vigilar los flow logs del NSG en la subred del gateway ante cualquier intento real de conexión a esos puertos. Si algo distinto de IP conocidas de Microsoft alcanza 7999 / 8081 / 8443 / 10001 / 10002 / 20000, escale.
§ 3.3 · INFRA-IP-01
Medio
Reciclaje de IP — dos IP del cliente fueron usadas previamente por otros clientes de Microsoft.
Dos de las IP públicas del cliente fueron usadas previamente por otros clientes de Microsoft Azure, según Mnemonic PassiveDNS:
- 203.0.113.31 (actualmente etiquetada ACC-001) — históricamente pgflexserver0748291630551207.postgres.database.azure.com (vista por última vez 2023-08-20) y azuregateway-1a2b3c4d-0a0a-4bcc-85dd-966d1ee82d76-b7788c99d0e1.vpn.azure.com (vista por última vez 2020-10-15).
- 203.0.113.22 (actualmente etiquetada AzureVPN-PIP2) — históricamente ext.quietmeadow-2b7c1d09.eastus.azurecontainerapps.io, scm.quietmeadow-2b7c1d09…, internal.quietmeadow-2b7c1d09… (vista por última vez 2024-10-25).
Por qué esto importa
Azure recicla las IP públicas entre distintos tenants. Cualquier lista de permitidos, URI de redirección OAuth, sonda de monitoreo, URL de callback o aplicación cliente con HSTS fijado que los tenants anteriores hayan configurado para apuntar a estas IP ahora está enviando tráfico a sus servidores. El riesgo es bidireccional: el tráfico entrante obsoleto de los socios de los tenants anteriores puede aparecer como falsos positivos en su monitoreo y, cuando eventualmente libere estas IP, el siguiente tenant recibirá el tráfico que estaba destinado a usted.
Confirmación parcial del escaneo activo
La superficie histórica de Postgres en 203.0.113.31 está cerrada (el puerto 5432 devolvió filtrado); la superficie HTTP histórica de ACA en 203.0.113.22 tampoco responde ya en 80 / 443. Así que los servicios de los tenants reciclados no son actualmente accesibles a través de las IP del cliente — pero las referencias de DNS / listas de permitidos de firewall en terceros aún pueden estar activas.
Guía de remediación
-
Audite el comportamiento actual en las IP recicladas.
Desde una VM dentro de la misma VNet (no toca la IP pública):
Test-NetConnection -ComputerName <internal-ip-of-ACC-001> -Port 5432
Test-NetConnection -ComputerName <internal-ip-of-AzureVPN-PIP2-VM> -Port 80
Test-NetConnection -ComputerName <internal-ip-of-AzureVPN-PIP2-VM> -Port 443
Cada uno debería dar TimedOut o reportar Blocked, salvo que esos servicios formen parte intencionalmente de su entorno.
-
Use Azure Public IP Prefix para las IP que necesitan estabilidad.
Cuando una IP realmente necesita sobrevivir a una sola VM (p. ej., para listas de permitidos de socios), asígnela desde un recurso Microsoft.Network/publicIPPrefixes para que el prefijo quede reservado a su suscripción y rotar la VM detrás de él no cambie la IP.
az network public-ip prefix create \
--resource-group <rg> --name contoso-stable-ips \
--length 28 --location <region>
az network public-ip create --resource-group <rg> --name contoso-app-pip1 \
--public-ip-prefix contoso-stable-ips
-
Documente el patrón de reciclaje en el runbook de DR.
Al investigar cualquier tráfico inusual en estas IP, el ingeniero de guardia debe saber que primero tiene que revisar los datos históricos de Mnemonic PassiveDNS para descartar "tráfico obsoleto de un tenant anterior".