Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Azure Network

Apoya a HackTricks

Información Básica

Las redes dentro de Azure funcionan como una parte integral de su plataforma de computación en la nube, permitiendo la conexión y comunicación entre varios servicios y recursos de Azure. La arquitectura de red en Azure está diseñada para ser altamente escalable, segura y personalizable.

En su núcleo, Azure proporciona una red virtual (VNet) que permite a los usuarios crear redes aisladas dentro de la nube de Azure. Dentro de estas VNets, se pueden alojar y gestionar de manera segura recursos como máquinas virtuales, aplicaciones y bases de datos. La red en Azure soporta tanto la comunicación dentro de la nube (entre servicios de Azure) como la conexión a redes externas e internet.

La seguridad es un aspecto crítico de la red en Azure, con varias herramientas y servicios disponibles para proteger datos, gestionar el acceso y asegurar el cumplimiento. Estas medidas de seguridad incluyen firewalls, grupos de seguridad de red y capacidades de encriptación, permitiendo un alto nivel de control sobre el tráfico y el acceso.

En general, las capacidades de red de Azure están diseñadas para ofrecer flexibilidad, permitiendo a los usuarios crear un entorno de red que se adapte a sus necesidades específicas de aplicación y carga de trabajo, manteniendo un fuerte énfasis en la seguridad y la fiabilidad.

Red Virtual (VNET) y Subredes

Una VNet en Azure es esencialmente una representación de tu propia red en la nube. Es un aislamiento lógico de la nube de Azure dedicado a tu suscripción. Una VNet te permite aprovisionar y gestionar redes privadas virtuales (VPNs) en Azure y puede ser utilizada para alojar y gestionar múltiples tipos de recursos de Azure, como Máquinas Virtuales (VMs), bases de datos y servicios de aplicaciones.

Las VNets te proporcionan control total sobre la configuración de tu red, incluyendo rangos de direcciones IP, creación de subredes, tablas de rutas y puertas de enlace de red.

Una subred es un rango de direcciones IP en tu VNet. Puedes dividir una VNet en múltiples subredes para organización y seguridad. Cada subred en una VNet puede ser utilizada para aislar y agrupar recursos de acuerdo a tu arquitectura de red y aplicación.

Además, las subredes te permiten segmentar tu VNet en una o más sub-redes, proporcionando un rango de direcciones IP que los recursos pueden usar.

Ejemplo

  • Supongamos que tienes una VNet llamada MyVNet con un rango de direcciones IP de 10.0.0.0/16. Puedes crear una subred dentro de esta VNet, digamos Subnet-1, con un rango de direcciones IP de 10.0.0.0/24 para alojar tus servidores web. Otra subred, Subnet-2 con un rango de 10.0.1.0/24, podría ser utilizada para tus servidores de bases de datos. Esta segmentación permite una gestión eficiente y controles de seguridad dentro de la red.

Enumeración

Para listar todas las VNets y subredes en una cuenta de Azure, puedes usar la Interfaz de Línea de Comandos de Azure (CLI). Aquí están los pasos:

# List VNets
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List subnets of a VNet
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, addressPrefix:addressPrefix}" -o table

Network Security Groups (NSG)

En Azure, un Network Security Group (NSG) tiene la función principal de filtrar el tráfico de red tanto hacia como desde los recursos de Azure dentro de una Azure Virtual Network (VNet). Contiene un conjunto de reglas de seguridad que dictan meticulosamente el flujo del tráfico de red.

Aspectos clave de NSG incluyen:

  • Control de Tráfico: Cada NSG contiene reglas que son fundamentales para permitir o bloquear el tráfico de red entrante y saliente asociado con varios recursos de Azure.

  • Componentes de las Reglas: Las reglas dentro de un NSG son altamente específicas, filtrando el tráfico basado en criterios como la dirección IP de origen/destino, puerto y protocolo. Esta especificidad permite una gestión granular del tráfico de red.

  • Mejora de la Seguridad: Al asegurar que solo el tráfico autorizado pueda entrar o salir de tus recursos de Azure, los NSG juegan un papel crucial en fortalecer la postura de seguridad de tu infraestructura de red.

Ejemplo

  • Imagina que tienes un NSG llamado MyNSG aplicado a una subred o a una máquina virtual específica dentro de tu VNet. Puedes crear reglas como:

  • Una regla entrante que permita el tráfico HTTP (puerto 80) desde cualquier origen a tus servidores web.

  • Una regla saliente que permita solo el tráfico SQL (puerto 1433) a un rango específico de direcciones IP de destino.

Enumeración

# List NSGs
az network nsg list --query "[].{name:name, location:location}" -o table

# Get NSG rules
az network nsg rule list --nsg-name <NSGName> --resource-group <ResourceGroupName> --query "[].{name:name, priority:priority, direction:direction, access:access, protocol:protocol, sourceAddressPrefix:sourceAddressPrefix, destinationAddressPrefix:destinationAddressPrefix, sourcePortRange:sourcePortRange, destinationPortRange:destinationPortRange}" -o table

Azure Firewall

Azure Firewall es un servicio de seguridad de red gestionado y basado en la nube que protege tus recursos de Azure Virtual Network. Es un firewall completamente con estado como servicio con características integradas de alta disponibilidad y escalabilidad.

Azure Firewall proporciona características más avanzadas que NSGs, incluyendo filtrado a nivel de aplicación, filtrado a nivel de red, filtrado basado en inteligencia de amenazas e integración con Azure Monitor para registro y análisis. Puede filtrar tráfico saliente, entrante, de spoke a spoke, VPN y ExpressRoute. Las reglas del firewall se pueden crear basadas en FQDN (Fully Qualified Domain Name), direcciones IP y puertos.

Diferencias entre Azure Firewall y NSGs

  1. Alcance:

  • NSG: Funciona a nivel de subred o interfaz de red. Está destinado a proporcionar filtrado básico del tráfico entrante y saliente desde interfaces de red (NIC), VMs o subredes.

  • Azure Firewall: Opera a nivel de VNet, proporcionando un alcance de protección más amplio. Está diseñado para asegurar tus recursos de red virtual y gestionar el tráfico que fluye dentro y fuera de la VNet.

  1. Capacidades:

  • NSG: Proporciona capacidades de filtrado básicas basadas en dirección IP, puerto y protocolo. No soporta características avanzadas como inspección a nivel de aplicación o inteligencia de amenazas.

  • Azure Firewall: Ofrece características avanzadas como filtrado de tráfico a nivel de aplicación (Capa 7), filtrado basado en inteligencia de amenazas, filtrado de tráfico de red y más. También soporta múltiples direcciones IP públicas.

  1. Casos de Uso:

  • NSG: Ideal para filtrado de tráfico a nivel de red básico.

  • Azure Firewall: Adecuado para escenarios de filtrado más complejos donde se necesita control a nivel de aplicación, registro e inteligencia de amenazas.

  1. Gestión y Monitoreo:

  • NSG: Ofrece registro básico e integración con Azure Monitor.

  • Azure Firewall: Proporciona capacidades avanzadas de registro y análisis a través de Azure Monitor, lo cual es esencial para entender la naturaleza y el patrón del tráfico.

Enumeración

# List Azure Firewalls
az network firewall list --query "[].{name:name, location:location, subnet:subnet, publicIp:publicIp}" -o table

# Get network rules of a firewall
az network firewall network-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get application rules of a firewall
az network firewall application-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

# Get nat rules of a firewall
az network firewall nat-rule collection list --firewall-name <FirewallName> --resource-group <ResourceGroupName> --query "[].{name:name, rules:rules}" -o table

Network Virtual Appliance (NVA)

Un Network Virtual Appliance (NVA) en Azure es un appliance virtual que realiza funciones de red dentro de una red virtual. Los NVAs se utilizan típicamente para funciones de red que no están disponibles de forma nativa en Azure o cuando se requiere más personalización. Esencialmente son VMs que ejecutan aplicaciones o servicios de red, como firewalls, optimizadores WAN o balanceadores de carga.

Los NVAs se utilizan para tareas complejas de enrutamiento, seguridad y gestión del tráfico de red. Pueden ser desplegados desde Azure Marketplace, donde muchos proveedores de terceros ofrecen sus appliances listos para integrarse en entornos de Azure.

Ejemplo

  • Una organización puede desplegar un NVA en Azure para crear una solución de firewall personalizada. Este NVA podría ejecutar un software de firewall de terceros, proporcionando características avanzadas como detección de intrusiones, inspección de paquetes o conectividad VPN. El NVA puede ser configurado para inspeccionar y filtrar el tráfico que pasa a través de él, asegurando que se implementen medidas de seguridad mejoradas según las políticas de la organización.

Enumeración

# Usually NVAs are named or tagged in a way to distinguish them from other VMs
az vm list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# For a specific VM identified as an NVA, list its network interfaces
az vm nic list --vm-name <VMName> --resource-group <ResourceGroupName> --query "[].{id:id}" -o table

Azure Route Tables & User Defined Routes (UDR)

Azure Route Tables son una característica dentro de Microsoft Azure que permite el control del enrutamiento del tráfico de red dentro de Azure Virtual Networks (VNets). Esencialmente, definen cómo se reenvían los paquetes entre subredes dentro de VNets, entre VNets o hacia redes externas. Cada tabla de rutas contiene un conjunto de reglas, conocidas como rutas, que especifican cómo deben ser enrutados los paquetes basándose en sus direcciones IP de destino.

User Defined Routes (UDR) en Azure son rutas personalizadas que creas dentro de Azure Route Tables para controlar el flujo del tráfico de red dentro y entre Azure Virtual Networks (VNets), y hacia conexiones externas. Los UDR te dan la flexibilidad de dirigir el tráfico de red según tus requisitos específicos, anulando las decisiones de enrutamiento predeterminadas de Azure.

Estas rutas son particularmente útiles para escenarios donde necesitas enrutar el tráfico a través de un appliance virtual, imponer un camino específico por razones de seguridad o cumplimiento de políticas, o integrarte con redes locales.

Ejemplo

  • Supongamos que has desplegado un Network Virtual Appliance (NVA) para inspeccionar el tráfico entre subredes dentro de un VNet. Puedes crear un UDR que dirija todo el tráfico de una subred a otra subred a través del NVA. Este UDR asegura que el NVA inspeccione el tráfico por razones de seguridad antes de que llegue a su destino.

Enumeración

# List Route Tables
az network route-table list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List UDRs for a table
az network route-table route list --route-table-name <RouteTableName> --resource-group <ResourceGroupName> --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIpAddress:nextHopIpAddress}" -o table

Azure Private Link

Azure Private Link es un servicio en Azure que habilita el acceso privado a servicios de Azure asegurando que el tráfico entre tu red virtual de Azure (VNet) y el servicio viaje completamente dentro de la red backbone de Azure de Microsoft. Efectivamente, trae el servicio a tu VNet. Esta configuración mejora la seguridad al no exponer los datos a internet público.

Private Link se puede usar con varios servicios de Azure, como Azure Storage, Azure SQL Database y servicios personalizados compartidos a través de Private Link. Proporciona una forma segura de consumir servicios desde dentro de tu propia VNet o incluso desde diferentes suscripciones de Azure.

NSGs no se aplican a endpoints privados, lo que claramente significa que asociar un NSG con una subred que contiene el Private Link no tendrá efecto.

Ejemplo

  • Considera un escenario donde tienes una Azure SQL Database a la que quieres acceder de manera segura desde tu VNet. Normalmente, esto podría implicar atravesar internet público. Con Private Link, puedes crear un endpoint privado en tu VNet que se conecta directamente al servicio de Azure SQL Database. Este endpoint hace que la base de datos parezca como si fuera parte de tu propia VNet, accesible a través de una dirección IP privada, asegurando así un acceso seguro y privado.

Enumeración

# List Private Link Services
z network private-link-service list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List Private Endpoints
az network private-endpoint list --query "[].{name:name, location:location, resourceGroup:resourceGroup, privateLinkServiceConnections:privateLinkServiceConnections}" -o table

Azure Service Endpoints

Azure Service Endpoints extienden el espacio de direcciones privadas de tu red virtual y la identidad de tu VNet a los servicios de Azure a través de una conexión directa. Al habilitar los service endpoints, los recursos en tu VNet pueden conectarse de manera segura a los servicios de Azure, como Azure Storage y Azure SQL Database, utilizando la red troncal de Azure. Esto asegura que el tráfico desde la VNet hacia el servicio de Azure permanezca dentro de la red de Azure, proporcionando un camino más seguro y confiable.

Ejemplo

  • Por ejemplo, una cuenta de Azure Storage por defecto es accesible a través de internet público. Al habilitar un service endpoint para Azure Storage dentro de tu VNet, puedes asegurar que solo el tráfico desde tu VNet pueda acceder a la cuenta de almacenamiento. El firewall de la cuenta de almacenamiento puede entonces configurarse para aceptar tráfico solo desde tu VNet.

Enumeración

# List Virtual Networks with Service Endpoints
az network vnet list --query "[].{name:name, location:location, serviceEndpoints:serviceEndpoints}" -o table

# List Subnets with Service Endpoints
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, serviceEndpoints:serviceEndpoints}" -o table

Diferencias Entre Service Endpoints y Private Links

Microsoft recomienda usar Private Links en los docs:\

Service Endpoints:

  • El tráfico desde tu VNet al servicio de Azure viaja a través de la red backbone de Microsoft Azure, evitando el internet público.

  • El endpoint es una conexión directa al servicio de Azure y no proporciona una IP privada para el servicio dentro de la VNet.

  • El servicio en sí sigue siendo accesible a través de su endpoint público desde fuera de tu VNet a menos que configures el firewall del servicio para bloquear dicho tráfico.

  • Es una relación uno a uno entre la subred y el servicio de Azure.

  • Menos costoso que Private Links.

Private Links:

  • Private Link mapea servicios de Azure en tu VNet a través de un endpoint privado, que es una interfaz de red con una dirección IP privada dentro de tu VNet.

  • El servicio de Azure se accede usando esta dirección IP privada, haciendo que parezca como si fuera parte de tu red.

  • Los servicios conectados a través de Private Link solo pueden ser accedidos desde tu VNet o redes conectadas; no hay acceso a internet público al servicio.

  • Permite una conexión segura a servicios de Azure o tus propios servicios alojados en Azure, así como una conexión a servicios compartidos por otros.

  • Proporciona un control de acceso más granular a través de un endpoint privado en tu VNet, en contraste con el control de acceso más amplio a nivel de subred con service endpoints.

En resumen, aunque tanto Service Endpoints como Private Links proporcionan conectividad segura a servicios de Azure, Private Links ofrecen un mayor nivel de aislamiento y seguridad al asegurar que los servicios se accedan de manera privada sin exponerlos al internet público. Service Endpoints, por otro lado, son más fáciles de configurar para casos generales donde se requiere un acceso seguro y simple a servicios de Azure sin la necesidad de una IP privada en la VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door es un punto de entrada escalable y seguro para la entrega rápida de tus aplicaciones web globales. Combina varios servicios como balanceo de carga global, aceleración de sitios, descarga de SSL y capacidades de Web Application Firewall (WAF) en un solo servicio. Azure Front Door proporciona enrutamiento inteligente basado en la ubicación de borde más cercana al usuario, asegurando un rendimiento y fiabilidad óptimos. Además, ofrece enrutamiento basado en URL, alojamiento de múltiples sitios, afinidad de sesión y seguridad a nivel de aplicación.

Azure Front Door WAF está diseñado para proteger aplicaciones web de ataques basados en la web sin modificar el código de back-end. Incluye reglas personalizadas y conjuntos de reglas gestionadas para proteger contra amenazas como inyección SQL, cross-site scripting y otros ataques comunes.

Ejemplo

  • Imagina que tienes una aplicación distribuida globalmente con usuarios en todo el mundo. Puedes usar Azure Front Door para enrutar las solicitudes de los usuarios al centro de datos regional más cercano que aloja tu aplicación, reduciendo así la latencia, mejorando la experiencia del usuario y defendiéndola de ataques web con las capacidades de WAF. Si una región en particular experimenta tiempo de inactividad, Azure Front Door puede redirigir automáticamente el tráfico a la siguiente mejor ubicación, asegurando alta disponibilidad.

Enumeración

# List Azure Front Door Instances
az network front-door list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

# List Front Door WAF Policies
az network front-door waf-policy list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table

Azure Application Gateway y Azure Application Gateway WAF

Azure Application Gateway es un balanceador de carga de tráfico web que te permite gestionar el tráfico hacia tus aplicaciones web. Ofrece balanceo de carga en la Capa 7, terminación SSL y capacidades de firewall de aplicaciones web (WAF) en el Controlador de Entrega de Aplicaciones (ADC) como servicio. Las características clave incluyen enrutamiento basado en URL, afinidad de sesión basada en cookies y descarga de capa de sockets seguros (SSL), que son cruciales para aplicaciones que requieren capacidades de balanceo de carga complejas como enrutamiento global y enrutamiento basado en rutas.

Ejemplo

  • Considera un escenario donde tienes un sitio web de comercio electrónico que incluye múltiples subdominios para diferentes funciones, como cuentas de usuario y procesamiento de pagos. Azure Application Gateway puede enrutar el tráfico a los servidores web apropiados basado en la ruta de la URL. Por ejemplo, el tráfico a example.com/accounts podría ser dirigido al servicio de cuentas de usuario, y el tráfico a example.com/pay podría ser dirigido al servicio de procesamiento de pagos. Y proteger tu sitio web de ataques utilizando las capacidades de WAF.

Enumeración

# List the Web Application Firewall configurations for your Application Gateways
az network application-gateway waf-config list --gateway-name <AppGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, firewallMode:firewallMode, ruleSetType:ruleSetType, ruleSetVersion:ruleSetVersion}" -o table

Azure Hub, Spoke & VNet Peering

VNet Peering es una característica de red en Azure que permite que diferentes Redes Virtuales (VNets) se conecten directamente y sin problemas. A través de VNet peering, los recursos en una VNet pueden comunicarse con recursos en otra VNet usando direcciones IP privadas, como si estuvieran en la misma red. VNet Peering también se puede usar con redes locales configurando una VPN de sitio a sitio o Azure ExpressRoute.

Azure Hub and Spoke es una topología de red utilizada en Azure para gestionar y organizar el tráfico de red. El "hub" es un punto central que controla y enruta el tráfico entre diferentes "spokes". El hub típicamente contiene servicios compartidos como appliances virtuales de red (NVAs), Azure VPN Gateway, Azure Firewall o Azure Bastion. Los "spokes" son VNets que alojan cargas de trabajo y se conectan al hub usando VNet peering, permitiéndoles aprovechar los servicios compartidos dentro del hub. Este modelo promueve un diseño de red limpio, reduciendo la complejidad al centralizar servicios comunes que múltiples cargas de trabajo a través de diferentes VNets pueden usar.

El emparejamiento de VNET no es transitivo en Azure, lo que significa que si el spoke 1 está conectado al spoke 2 y el spoke 2 está conectado al spoke 3, entonces el spoke 1 no puede comunicarse directamente con el spoke 3.

Ejemplos

  • Imagina una empresa con departamentos separados como Ventas, RRHH y Desarrollo, cada uno con su propia VNet (los spokes). Estas VNets requieren acceso a recursos compartidos como una base de datos central, un firewall y una puerta de enlace a internet, que están todos ubicados en otra VNet (el hub). Usando el modelo Hub and Spoke, cada departamento puede conectarse de manera segura a los recursos compartidos a través de la VNet del hub sin exponer esos recursos a internet público o crear una estructura de red compleja con numerosas conexiones.

Enumeración

# List all VNets in your subscription
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table

# List VNet peering connections for a given VNet
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, peeringState:peeringState, remoteVnetId:remoteVnetId}" -o table

# List Shared Resources (e.g., Azure Firewall) in the Hub
az network firewall list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

Site-to-Site VPN

Un Site-to-Site VPN en Azure te permite conectar tu red local a tu Azure Virtual Network (VNet), permitiendo que recursos como VMs dentro de Azure aparezcan como si estuvieran en tu red local. Esta conexión se establece a través de un VPN gateway que cifra el tráfico entre las dos redes.

Ejemplo

  • Una empresa con su oficina principal ubicada en Nueva York tiene un centro de datos local que necesita conectarse de manera segura a su VNet en Azure, que aloja sus cargas de trabajo virtualizadas. Al configurar un Site-to-Site VPN, la empresa puede asegurar la conectividad cifrada entre los servidores locales y las Azure VMs, permitiendo que los recursos sean accesibles de manera segura en ambos entornos como si estuvieran en la misma red local.

Enumeración

# List VPN Gateways
az network vnet-gateway list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table

# List VPN Connections
az network vpn-connection list --gateway-name <VpnGatewayName> --resource-group <ResourceGroupName> --query "[].{name:name, connectionType:connectionType, connectionStatus:connectionStatus}" -o table

Azure ExpressRoute

Azure ExpressRoute es un servicio que proporciona una conexión privada, dedicada y de alta velocidad entre tu infraestructura local y los centros de datos de Azure. Esta conexión se realiza a través de un proveedor de conectividad, evitando la internet pública y ofreciendo más fiabilidad, mayores velocidades, menores latencias y mayor seguridad que las conexiones típicas de internet.

Ejemplo

  • Una corporación multinacional requiere una conexión consistente y fiable a sus servicios de Azure debido al alto volumen de datos y la necesidad de un alto rendimiento. La empresa opta por Azure ExpressRoute para conectar directamente su centro de datos local a Azure, facilitando transferencias de datos a gran escala, como copias de seguridad diarias y análisis de datos en tiempo real, con mayor privacidad y velocidad.

Enumeración

# List ExpressRoute Circuits
az network express-route list --query "[].{name:name, location:location, resourceGroup:resourceGroup, serviceProviderName:serviceProviderName, peeringLocation:peeringLocation}" -o table
Apoya HackTricks
PreviousAz - Virtual Machines & NetworkNextAz - Permissions for a Pentest

Last updated