Az - Azure Network

Support 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, recursos como máquinas virtuales, aplicaciones y bases de datos pueden ser alojados y gestionados de manera segura. La red en Azure soporta tanto la comunicación dentro de la nube (entre servicios de Azure) como la conexión a redes externas y a internet.

La seguridad es un aspecto crítico de la red de Azure, con varias herramientas y servicios disponibles para proteger datos, gestionar accesos y asegurar el cumplimiento. Estas medidas de seguridad incluyen firewalls, grupos de seguridad de red y capacidades de cifrado, 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, mientras se mantiene 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 una aislación lógica de la nube de Azure dedicada 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 gateways 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 subredes, proporcionando un rango de direcciones IP que los recursos pueden utilizar.

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 Comando 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

Grupos de Seguridad de Red (NSG)

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

Los aspectos clave de NSG incluyen:

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

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

  • Mejora de Seguridad: Al asegurar que solo el tráfico autorizado puede entrar o salir de sus recursos de Azure, los NSG juegan un papel crucial en el fortalecimiento de la postura de seguridad de su 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 de entrada que permite tráfico HTTP (puerto 80) desde cualquier origen a tus servidores web.

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

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 basado en la nube y gestionado 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 en función de FQDN (Nombre de Dominio Totalmente Calificado), 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 un filtrado básico del tráfico entrante y saliente de las interfaces de red (NIC), VMs o subredes.

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

  1. Capacidades:

  • NSG: Proporciona capacidades de filtrado básicas basadas en dirección IP, puerto y protocolo. No admite 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 admite múltiples direcciones IP públicas.

  1. Casos de Uso:

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

  • 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

Dispositivo Virtual de Red (NVA)

Un Dispositivo Virtual de Red (NVA) en Azure es un dispositivo 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. Son esencialmente VMs que ejecutan aplicaciones o servicios de red, como cortafuegos, optimizadores de WAN o equilibradores de carga.

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

Ejemplo

  • Una organización puede desplegar un NVA en Azure para crear una solución de cortafuegos personalizada. Este NVA podría ejecutar un software de cortafuegos 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 de acuerdo con 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

Tablas de Rutas de Azure y Rutas Definidas por el Usuario (UDR)

Las Tablas de Rutas de Azure son una característica dentro de Microsoft Azure que permiten el control del enrutamiento del tráfico de red dentro de las Redes Virtuales de Azure (VNets). Esencialmente, definen cómo se reenviarán los paquetes entre subredes dentro de las VNets, entre VNets o a redes externas. Cada tabla de rutas contiene un conjunto de reglas, conocidas como rutas, que especifican cómo se deben enrutar los paquetes según sus direcciones IP de destino.

Las Rutas Definidas por el Usuario (UDR) en Azure son rutas personalizadas que creas dentro de las Tablas de Rutas de Azure para controlar el flujo del tráfico de red dentro y entre las Redes Virtuales de Azure (VNets), y hacia conexiones externas. Las UDR te brindan 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 dispositivo virtual, hacer cumplir un camino específico para la seguridad o el cumplimiento de políticas, o integrarte con redes locales.

Ejemplo

  • Supongamos que has desplegado un Dispositivo Virtual de Red (NVA) para inspeccionar el tráfico entre subredes dentro de una VNet. Puedes crear una UDR que dirija todo el tráfico de una subred a otra subred a través del NVA. Esta UDR asegura que el NVA inspeccione el tráfico por motivos 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 es un servicio en Azure que permite el acceso privado a los servicios de Azure al garantizar que el tráfico entre su red virtual de Azure (VNet) y el servicio viaje completamente dentro de la red troncal de Microsoft Azure. Efectivamente, lleva el servicio a su VNet. Esta configuración mejora la seguridad al no exponer los datos a Internet público.

Private Link se puede utilizar 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 su propia VNet o incluso desde diferentes suscripciones de Azure.

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

Ejemplo

  • Considere un escenario en el que tiene una base de datos de Azure SQL a la que desea acceder de forma segura desde su VNet. Normalmente, esto podría implicar atravesar Internet público. Con Private Link, puede crear un punto final privado en su VNet que se conecta directamente al servicio de base de datos de Azure SQL. Este punto final hace que la base de datos parezca parte de su 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

Puntos de Conexión de Servicio de Azure

Los Puntos de Conexión de Servicio de Azure extienden el espacio de direcciones privadas de su red virtual y la identidad de su VNet a los servicios de Azure a través de una conexión directa. Al habilitar los puntos de conexión de servicio, los recursos en su 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 de la VNet al 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 punto de conexión de servicio para Azure Storage dentro de su VNet, puede asegurarse de que solo el tráfico de su VNet pueda acceder a la cuenta de almacenamiento. El firewall de la cuenta de almacenamiento puede configurarse para aceptar tráfico solo de su 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 Puntos de Servicio y Enlaces Privados

Microsoft recomienda usar Enlaces Privados en los docs:\

Puntos de Servicio:

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

  • El punto de servicio 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 punto de acceso 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 los Enlaces Privados.

Enlaces Privados:

  • El Enlace Privado mapea los servicios de Azure en tu VNet a través de un punto de acceso privado, que es una interfaz de red con una dirección IP privada dentro de tu VNet.

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

  • Los servicios conectados a través de Enlace Privado 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 los servicios de Azure o a 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 punto de acceso privado en tu VNet, en lugar de un control de acceso más amplio a nivel de subred con puntos de servicio.

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

Azure Front Door (AFD) y AFD WAF

Azure Front Door es un punto de entrada escalable y seguro para la rápida entrega de tus aplicaciones web globales. Combina varios servicios como balanceo de carga global, aceleración de sitios, descarga de SSL y capacidades de Firewall de Aplicaciones Web (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 confiabilidad ó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 backend. Incluye reglas personalizadas y conjuntos de reglas gestionadas para proteger contra amenazas como inyección SQL, scripting entre sitios 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 aloje 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 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 de Capa 7, terminación de 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 según 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 y Peering de VNet

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

Azure Hub y 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 dispositivos 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 utilizando peering de VNet, lo que les permite 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 en 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, Recursos Humanos 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 se encuentran en otra VNet (el hub). Al utilizar el modelo Hub y 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

VPN de Sitio a Sitio

Una VPN de Sitio a Sitio en Azure te permite conectar tu red local a tu Red Virtual (VNet) de Azure, permitiendo que recursos como las VMs dentro de Azure aparezcan como si estuvieran en tu red local. Esta conexión se establece a través de una puerta de enlace VPN 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 alberga sus cargas de trabajo virtualizadas. Al configurar una VPN de Sitio a Sitio, la empresa puede garantizar conectividad cifrada entre los servidores locales y las VMs de Azure, 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 su infraestructura local y los centros de datos de Azure. Esta conexión se realiza a través de un proveedor de conectividad, evitando el internet público y ofreciendo más confiabilidad, velocidades más rápidas, latencias más bajas y mayor seguridad que las conexiones típicas a internet.

Ejemplo

  • Una corporación multinacional requiere una conexión consistente y confiable 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 a HackTricks

Last updated