Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Azure Network

Support HackTricks

Informações Básicas

As redes dentro do Azure funcionam como uma parte integral de sua plataforma de computação em nuvem, permitindo a conexão e comunicação entre vários serviços e recursos do Azure. A arquitetura de rede no Azure é projetada para ser altamente escalável, segura e personalizável.

No seu núcleo, o Azure fornece uma rede virtual (VNet) que permite aos usuários criar redes isoladas dentro da nuvem Azure. Dentro dessas VNets, recursos como máquinas virtuais, aplicativos e bancos de dados podem ser hospedados e gerenciados com segurança. A rede no Azure suporta tanto a comunicação dentro da nuvem (entre serviços do Azure) quanto a conexão com redes externas e a internet.

Segurança é um aspecto crítico da rede do Azure, com várias ferramentas e serviços disponíveis para proteger dados, gerenciar acesso e garantir conformidade. Essas medidas de segurança incluem firewalls, grupos de segurança de rede e capacidades de criptografia, permitindo um alto nível de controle sobre o tráfego e o acesso.

No geral, as capacidades de rede do Azure são projetadas para oferecer flexibilidade, permitindo que os usuários criem um ambiente de rede que atenda às suas necessidades específicas de aplicação e carga de trabalho, mantendo um forte ênfase na segurança e confiabilidade.

Rede Virtual (VNET) & Sub-redes

Uma VNet no Azure é essencialmente uma representação da sua própria rede na nuvem. É um isolamento lógico da nuvem Azure dedicado à sua assinatura. Uma VNet permite que você provisionar e gerenciar redes privadas virtuais (VPNs) no Azure e pode ser usada para hospedar e gerenciar vários tipos de recursos do Azure, como Máquinas Virtuais (VMs), bancos de dados e serviços de aplicativos.

As VNets fornecem a você controle total sobre suas configurações de rede, incluindo intervalos de endereços IP, criação de sub-redes, tabelas de rotas e gateways de rede.

Uma sub-rede é um intervalo de endereços IP na sua VNet. Você pode dividir uma VNet em várias sub-redes para organização e segurança. Cada sub-rede em uma VNet pode ser usada para isolar e agrupar recursos de acordo com sua arquitetura de rede e aplicação.

Além disso, as sub-redes permitem que você segmente sua VNet em uma ou mais sub-redes, fornecendo um intervalo de endereços IP que os recursos podem usar.

Exemplo

  • Suponha que você tenha uma VNet chamada MyVNet com um intervalo de endereços IP de 10.0.0.0/16. Você pode criar uma sub-rede dentro dessa VNet, digamos Subnet-1, com um intervalo de endereços IP de 10.0.0.0/24 para hospedar seus servidores web. Outra sub-rede, Subnet-2 com um intervalo de 10.0.1.0/24, poderia ser usada para seus servidores de banco de dados. Essa segmentação permite um gerenciamento eficiente e controles de segurança dentro da rede.

Enumeração

Para listar todas as VNets e sub-redes em uma conta Azure, você pode usar a Interface de Linha de Comando (CLI) do Azure. Aqui estão os passos:

# 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)

No Azure, um Network Security Group (NSG) tem a função principal de filtrar o tráfego de rede tanto para os recursos do Azure quanto a partir deles dentro de uma Azure Virtual Network (VNet). Ele contém um conjunto de regras de segurança que ditam meticulosamente o fluxo do tráfego de rede.

Aspectos chave do NSG incluem:

  • Controle de Tráfego: Cada NSG contém regras que são instrumentais em permitir ou obstruir o tráfego de rede de entrada e saída associado a vários recursos do Azure.

  • Componentes da Regra: As regras dentro de um NSG são altamente específicas, filtrando o tráfego com base em critérios como endereço IP de origem/destino, porta e protocolo. Essa especificidade permite uma gestão granular do tráfego de rede.

  • Aprimoramento de Segurança: Ao garantir que apenas o tráfego autorizado possa entrar ou sair dos seus recursos do Azure, os NSGs desempenham um papel crucial no fortalecimento da postura de segurança da sua infraestrutura de rede.

Exemplo

  • Imagine que você tem um NSG chamado MyNSG aplicado a uma sub-rede ou a uma máquina virtual específica dentro da sua VNet. Você pode criar regras como:

  • Uma regra de entrada permitindo tráfego HTTP (porta 80) de qualquer origem para seus servidores web.

  • Uma regra de saída permitindo apenas tráfego SQL (porta 1433) para um intervalo específico de endereços IP de destino.

Enumeração

# 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 é um serviço de segurança de rede gerenciado e baseado em nuvem que protege seus recursos do Azure Virtual Network. É um firewall totalmente stateful como serviço com recursos integrados de alta disponibilidade e escalabilidade.

Azure Firewall fornece recursos mais avançados do que NSGs, incluindo filtragem em nível de aplicação, filtragem em nível de rede, filtragem baseada em inteligência contra ameaças e integração com Azure Monitor para registro e análise. Ele pode filtrar tráfego de saída, entrada, spoke-to-spoke, VPN e ExpressRoute. Regras de firewall podem ser criadas com base em FQDN (Fully Qualified Domain Name), endereços IP e portas.

Diferenças entre Azure Firewall e NSGs

  1. Escopo:

  • NSG: Funciona no nível de sub-rede ou interface de rede. Destina-se a fornecer filtragem básica de tráfego de entrada e saída de interfaces de rede (NIC), VMs ou sub-redes.

  • Azure Firewall: Opera no nível do VNet, proporcionando um escopo mais amplo de proteção. É projetado para proteger seus recursos de rede virtual e gerenciar o tráfego que entra e sai do VNet.

  1. Capacidades:

  • NSG: Fornece capacidades básicas de filtragem com base em endereço IP, porta e protocolo. Não suporta recursos avançados como inspeção em nível de aplicação ou inteligência contra ameaças.

  • Azure Firewall: Oferece recursos avançados como filtragem de tráfego em nível de aplicação (Camada 7), filtragem baseada em inteligência contra ameaças, filtragem de tráfego de rede e mais. Também suporta múltiplos endereços IP públicos.

  1. Casos de Uso:

  • NSG: Ideal para filtragem básica de tráfego em nível de rede.

  • Azure Firewall: Adequado para cenários de filtragem mais complexos onde controle em nível de aplicação, registro e inteligência contra ameaças são necessários.

  1. Gerenciamento e Monitoramento:

  • NSG: Oferece registro básico e integração com Azure Monitor.

  • Azure Firewall: Fornece capacidades avançadas de registro e análise através do Azure Monitor, o que é essencial para entender a natureza e o padrão do tráfego.

Enumeração

# 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)

Um Network Virtual Appliance (NVA) no Azure é um appliance virtual que executa funções de rede dentro de uma rede virtual. NVAs são tipicamente usados para funções de rede que não estão disponíveis nativamente no Azure ou quando é necessária mais personalização. Eles são essencialmente VMs que executam aplicativos ou serviços de rede, como firewalls, otimizadores de WAN ou balanceadores de carga.

NVAs são usados para tarefas complexas de roteamento, segurança e gerenciamento de tráfego de rede. Eles podem ser implantados a partir do Marketplace do Azure, onde muitos fornecedores terceiros oferecem seus appliances prontos para integração em ambientes Azure.

Exemplo

  • Uma organização pode implantar um NVA no Azure para criar uma solução de firewall personalizada. Este NVA poderia executar um software de firewall de terceiros, fornecendo recursos avançados como detecção de intrusão, inspeção de pacotes ou conectividade VPN. O NVA pode ser configurado para inspecionar e filtrar o tráfego que passa por ele, garantindo que medidas de segurança aprimoradas estejam em vigor conforme as políticas da organização.

Enumeração

# 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 são um recurso dentro do Microsoft Azure que permite o controle do roteamento de tráfego de rede dentro das Azure Virtual Networks (VNets). Essencialmente, elas definem como os pacotes são encaminhados entre sub-redes dentro das VNets, entre VNets, ou para redes externas. Cada tabela de rotas contém um conjunto de regras, conhecidas como rotas, que especificam como os pacotes devem ser roteados com base em seus endereços IP de destino.

User Defined Routes (UDR) no Azure são rotas personalizadas que você cria dentro das Azure Route Tables para controlar o fluxo de tráfego de rede dentro e entre as Azure Virtual Networks (VNets), e para conexões externas. UDRs dão a você a flexibilidade de direcionar o tráfego de rede conforme suas necessidades específicas, substituindo as decisões de roteamento padrão do Azure.

Essas rotas são particularmente úteis para cenários onde você precisa rotear o tráfego através de um appliance virtual, impor um caminho específico para conformidade de segurança ou política, ou integrar com redes on-premises.

Exemplo

  • Suponha que você tenha implantado um Network Virtual Appliance (NVA) para inspecionar o tráfego entre sub-redes dentro de uma VNet. Você pode criar um UDR que direciona todo o tráfego de uma sub-rede para outra sub-rede passando pelo NVA. Este UDR garante que o NVA inspecione o tráfego para fins de segurança antes que ele chegue ao seu destino.

Enumeração

# 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 é um serviço no Azure que permite acesso privado a serviços do Azure garantindo que o tráfego entre sua rede virtual (VNet) do Azure e o serviço viaje inteiramente dentro da rede backbone do Azure da Microsoft. Ele efetivamente traz o serviço para dentro da sua VNet. Esta configuração aumenta a segurança ao não expor os dados à internet pública.

Private Link pode ser usado com vários serviços do Azure, como Azure Storage, Azure SQL Database e serviços personalizados compartilhados via Private Link. Ele fornece uma maneira segura de consumir serviços de dentro da sua própria VNet ou até mesmo de diferentes assinaturas do Azure.

NSGs não se aplicam a endpoints privados, o que claramente significa que associar um NSG a uma sub-rede que contém o Private Link não terá efeito.

Exemplo

  • Considere um cenário onde você tem um Azure SQL Database que deseja acessar de forma segura a partir da sua VNet. Normalmente, isso pode envolver atravessar a internet pública. Com o Private Link, você pode criar um endpoint privado na sua VNet que se conecta diretamente ao serviço Azure SQL Database. Este endpoint faz com que o banco de dados pareça como se fosse parte da sua própria VNet, acessível via um endereço IP privado, garantindo assim um acesso seguro e privado.

Enumeração

# 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 estendem o espaço de endereço privado da sua rede virtual e a identidade do seu VNet para serviços Azure através de uma conexão direta. Ao habilitar endpoints de serviço, recursos no seu VNet podem se conectar com segurança aos serviços Azure, como Azure Storage e Azure SQL Database, usando a rede backbone do Azure. Isso garante que o tráfego do VNet para o serviço Azure permaneça dentro da rede Azure, proporcionando um caminho mais seguro e confiável.

Exemplo

  • Por exemplo, uma conta de Azure Storage por padrão é acessível pela internet pública. Ao habilitar um endpoint de serviço para Azure Storage dentro do seu VNet, você pode garantir que apenas o tráfego do seu VNet possa acessar a conta de armazenamento. O firewall da conta de armazenamento pode então ser configurado para aceitar tráfego apenas do seu VNet.

Enumeração

# 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

Diferenças Entre Service Endpoints e Private Links

A Microsoft recomenda o uso de Private Links na documentação:\

Service Endpoints:

  • O tráfego do seu VNet para o serviço Azure viaja pela rede backbone da Microsoft Azure, ignorando a internet pública.

  • O endpoint é uma conexão direta com o serviço Azure e não fornece um IP privado para o serviço dentro do VNet.

  • O serviço em si ainda é acessível via seu endpoint público de fora do seu VNet, a menos que você configure o firewall do serviço para bloquear tal tráfego.

  • É uma relação um-para-um entre a sub-rede e o serviço Azure.

  • Menos caro do que Private Links.

Private Links:

  • Private Link mapeia serviços Azure no seu VNet via um endpoint privado, que é uma interface de rede com um endereço IP privado dentro do seu VNet.

  • O serviço Azure é acessado usando este endereço IP privado, fazendo parecer que faz parte da sua rede.

  • Serviços conectados via Private Link podem ser acessados apenas do seu VNet ou redes conectadas; não há acesso à internet pública para o serviço.

  • Permite uma conexão segura com serviços Azure ou seus próprios serviços hospedados no Azure, bem como uma conexão com serviços compartilhados por outros.

  • Fornece controle de acesso mais granular via um endpoint privado no seu VNet, em oposição ao controle de acesso mais amplo no nível da sub-rede com service endpoints.

Em resumo, enquanto ambos Service Endpoints e Private Links fornecem conectividade segura para serviços Azure, Private Links oferecem um nível mais alto de isolamento e segurança ao garantir que os serviços sejam acessados de forma privada sem expô-los à internet pública. Service Endpoints, por outro lado, são mais fáceis de configurar para casos gerais onde é necessário acesso simples e seguro aos serviços Azure sem a necessidade de um IP privado no VNet.

Azure Front Door (AFD) & AFD WAF

Azure Front Door é um ponto de entrada escalável e seguro para entrega rápida de suas aplicações web globais. Ele combina vários serviços como balanceamento de carga global, aceleração de site, descarregamento de SSL e capacidades de Web Application Firewall (WAF) em um único serviço. Azure Front Door fornece roteamento inteligente baseado na localização de borda mais próxima do usuário, garantindo desempenho e confiabilidade ótimos. Além disso, oferece roteamento baseado em URL, hospedagem de múltiplos sites, afinidade de sessão e segurança na camada de aplicação.

Azure Front Door WAF é projetado para proteger aplicações web contra ataques baseados na web sem modificação no código de back-end. Inclui regras personalizadas e conjuntos de regras gerenciadas para proteger contra ameaças como injeção de SQL, cross-site scripting e outros ataques comuns.

Exemplo

  • Imagine que você tem uma aplicação distribuída globalmente com usuários ao redor do mundo. Você pode usar Azure Front Door para rotear solicitações de usuários para o data center regional mais próximo que hospeda sua aplicação, reduzindo assim a latência, melhorando a experiência do usuário e defendendo-a de ataques web com as capacidades do WAF. Se uma determinada região experimentar tempo de inatividade, Azure Front Door pode automaticamente redirecionar o tráfego para a próxima melhor localização, garantindo alta disponibilidade.

Enumeração

# 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 e Azure Application Gateway WAF

Azure Application Gateway é um balanceador de carga de tráfego web que permite gerenciar o tráfego para suas aplicações web. Ele oferece balanceamento de carga na Camada 7, terminação SSL e capacidades de firewall de aplicação web (WAF) no Application Delivery Controller (ADC) como um serviço. As principais características incluem roteamento baseado em URL, afinidade de sessão baseada em cookies e descarregamento de camada de soquetes seguros (SSL), que são cruciais para aplicações que requerem capacidades complexas de balanceamento de carga, como roteamento global e roteamento baseado em caminho.

Exemplo

  • Considere um cenário onde você tem um site de e-commerce que inclui múltiplos subdomínios para diferentes funções, como contas de usuário e processamento de pagamentos. Azure Application Gateway pode rotear o tráfego para os servidores web apropriados com base no caminho do URL. Por exemplo, o tráfego para example.com/accounts poderia ser direcionado para o serviço de contas de usuário, e o tráfego para example.com/pay poderia ser direcionado para o serviço de processamento de pagamentos. E proteger seu site contra ataques usando as capacidades do WAF.

Enumeração

# 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 é um recurso de rede no Azure que permite que diferentes Redes Virtuais (VNets) sejam conectadas diretamente e de forma transparente. Através do VNet peering, recursos em uma VNet podem se comunicar com recursos em outra VNet usando endereços IP privados, como se estivessem na mesma rede. O VNet Peering também pode ser usado com redes on-prem configurando uma VPN site-to-site ou Azure ExpressRoute.

Azure Hub and Spoke é uma topologia de rede usada no Azure para gerenciar e organizar o tráfego de rede. O "hub" é um ponto central que controla e roteia o tráfego entre diferentes "spokes". O hub normalmente contém serviços compartilhados, como appliances virtuais de rede (NVAs), Azure VPN Gateway, Azure Firewall ou Azure Bastion. Os "spokes" são VNets que hospedam cargas de trabalho e se conectam ao hub usando VNet peering, permitindo que aproveitem os serviços compartilhados dentro do hub. Este modelo promove um layout de rede limpo, reduzindo a complexidade ao centralizar serviços comuns que várias cargas de trabalho em diferentes VNets podem usar.

O VNET pairing não é transitivo no Azure, o que significa que se o spoke 1 está conectado ao spoke 2 e o spoke 2 está conectado ao spoke 3, então o spoke 1 não pode se comunicar diretamente com o spoke 3.

Exemplos

  • Imagine uma empresa com departamentos separados como Vendas, RH e Desenvolvimento, cada um com sua própria VNet (os spokes). Essas VNets necessitam de acesso a recursos compartilhados como um banco de dados central, um firewall e um gateway de internet, que estão todos localizados em outra VNet (o hub). Usando o modelo Hub and Spoke, cada departamento pode se conectar de forma segura aos recursos compartilhados através da VNet do hub sem expor esses recursos à internet pública ou criar uma estrutura de rede complexa com inúmeras conexões.

Enumeração

# 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

Um Site-to-Site VPN no Azure permite que você conecte sua rede local à sua Azure Virtual Network (VNet), possibilitando que recursos como VMs dentro do Azure apareçam como se estivessem na sua rede local. Esta conexão é estabelecida através de um gateway VPN que criptografa o tráfego entre as duas redes.

Exemplo

  • Uma empresa com seu escritório principal localizado em Nova York possui um data center local que precisa se conectar de forma segura à sua VNet no Azure, que hospeda suas cargas de trabalho virtualizadas. Ao configurar um Site-to-Site VPN, a empresa pode garantir conectividade criptografada entre os servidores locais e as VMs do Azure, permitindo que os recursos sejam acessados de forma segura em ambos os ambientes como se estivessem na mesma rede local.

Enumeração

# 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 é um serviço que fornece uma conexão privada, dedicada e de alta velocidade entre sua infraestrutura local e os data centers do Azure. Esta conexão é feita através de um provedor de conectividade, contornando a internet pública e oferecendo mais confiabilidade, velocidades mais rápidas, latências mais baixas e maior segurança do que as conexões típicas da internet.

Exemplo

  • Uma corporação multinacional requer uma conexão consistente e confiável com seus serviços Azure devido ao alto volume de dados e à necessidade de alta taxa de transferência. A empresa opta pelo Azure ExpressRoute para conectar diretamente seu data center local ao Azure, facilitando transferências de dados em grande escala, como backups diários e análises de dados em tempo real, com maior privacidade e velocidade.

Enumeração

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

Last updated