Este artigo possui a finalidade de demonstrar como podemos inspecionar o tráfego com destino aos recursos de Private Endpoint para o Azure Firewall ou NVA.
O que é private Endpoint?
Um private Endpoint fornece um endereço IP privado para uma lista de serviços de plataforma na Azure permitindo a comunicação privada com estes recursos.
Como usar uma solução de firewall para inspecionar o tráfego destinado a um private endpoint?
Um requisito de segurança talvez seja inspecionar ou bloquear o tráfego de clientes para os serviços expostos de forma privada por meio do private Endpoint. Porém para atingir esse objetivo devemos conhecer algumas características referente ao uso do private Endpoint.
As seguintes características se aplicam ao uso do private endpoint:
- O tráfego dos grupos de segurança de rede (NSG) é ignorado nos private endpoints
- O tráfego das rotas definidas pelo usuário (UDR) é ignorado nos private endpoints. As rotas definidas pelo usuário podem ser usadas para substituir o tráfego destinado ao private Endpoint.
- Uma única tabela de rotas pode ser anexada a uma sub-rede
- Uma tabela de rotas dá suporte a até 400 rotas
Ao criar um private Endpoint com o serviço do private link é injetado nas sub-redes uma rota mais especifica /32 contendo o endereçamento ip privado destinado ao private Endpoint, devido a este cenário temos alguns cenários de como inspecionar o tráfego destinado ao private Endpoint para uma solução do Azure Firewall ou NVA (Network Virtual Applicance)
A seguinte documentação Use Azure Firewall to inspect traffic destined to a private endpoint - Azure Private Link | Microsoft Learn relata 4 cenários possíveis para inspeção do private endpoint, porém irei cobrir aqui um novo cenário usando o recurso de Network Policy no qual irá facilitar o nosso objetivo.
A documentação relata quatro opções possíveis para realizar a inspeção do private endpoint para o Azure Firewall.
Cenário 1: Arquitetura Hub e Spoke usando uma rede virtual dedicada para private endpoint.
Neste cenário de arquitetura Hub e Spoke usamos uma rede virtual inteira para o private endpoint.
- Hub Vnet: 10.0.0.0/16
- Spoke VNET: 10.1.0.0/16
- Private vNET: 10.2.0.0/16
Neste cenário é criado uma Route Table da sub-rede da rede virtual Spoke VNET com a seguinte regra para alcançar a rede 10.20.0./16 passando pelo Azure Firewall. Essa configuração reduz a sobrecarga administrativa e impedindo a possibilidade de alcançar o limite de 400 rotas da UDR
Este cenário se aplica nos clientes que possuem uma rede virtual dedicada para o serviço do private endpoint.
Cenário 2: Arquitetura Hub e Spoke usando rede virtual compartilhada entre as máquinas virtuais e private endpoint
Este cenário cobre grande parte das arquiteturas encontradas nos clientes no qual temos uma rede virtual Spoke com sub-rede para as máquinas virtuais e outra sub-rede para o private endpoint. Este cenário é implementado quando não é possível ter uma rede virtual dedicada para os private endpoints.
Neste caso será injetado rotas de sistema nas sub-redes das máquinas /32 apontando para cada private endpoint.
Veja abaixo o exemplo das rotas efetivas de uma máquina virtual
Neste caso para que o tráfego destinado ao private endpoint seja encaminhado para o firewall será necessário adicionar uma rota para cada endereço ip privado dos private endpoints o que aumenta a carga administrativa de manutenção das tabelas de rota e a possibilidade de atingir o limite de 400 rotas.
Cenário 3: Rede virtual única
Neste cenário temos apenas uma única rede virtual e as mesmas considerações do cenário 2 são aplicadas aqui.
Isso acontece devido a injeção das rotas /32 dos private endpoints para as subnets.
Cenário 4: Tráfego on-premises para private endpoints
Neste cenário temos a necessidade de inspecionar no Firewall tráfego vindo do datacenter para os private endpoints. Também temos as mesmas considerações do cenário 2. Para que o tráfego destinado aos private endpoints sejam inspecionados pelo Azure Firewall devemos adicionar na tabela de rota da GatewaySubnet uma rota para cada endereço IP /32 dos private endpoints para o Firewall.
Irei cobri aqui um novo cenário cobrindo os cenários dois e quatro, usando o recurso de Network Policy o que irá auxiliar no controle de rotas.
Cenário 5: Hub e Spoke usando Network Policy
Este cenário seria uma adição do cenário dois e do cenário quatro, porém iremos habilitar o recurso de Network Policy na sub-rede dedicada para private endpoint.
O que é Network Policy?
Por padrão, as políticas de rede são desabilitadas para uma sub-rede em uma rede virtual. Para utilizar políticas de rede como suporte a Rotas Definidas pelo Usuário e Grupos de Segurança de Rede será necessário habilitar este serviço do Network Policy na sub-rede dos private endpoints pois essa configuração é aplicável somente a estes recursos.
Ao habilitar o Network Policy as rotas /32 que são geradas pelos private endpoints e propagadas para todas as sub-redes em sua própria VNet e VNets diretamente emparelhadas serão invalidadas.
Etapa 1: Cenário antes de habilitar o Network Policy
Por padrão o Network Policy não é habilitado nas sub-redes. Com isso ao criar um private endpoint uma rota de sistema /32 com endereço ip privado do private endpoint será automaticamente injetada nas sub-redes da rede virtual.
O diagrama abaixo ilustra este comportamento das rotas efetivas na máquina virtual 10.100.0.4 e percebemos que a rota de sistema foi adicionada automaticamente após a criação do private endpoint para uma conta de armazenamento recebendo o endereçamento privado 10.100.1.4.
Etapa 2: Cenário após habilitar o Network Policy
No nosso laboratório habilitamos o Network Policy na sub-rede 10.100.1.0/25 dedicada para private endpoints.
As rotas injetadas /32 serão invalidadas conforme a imagem abaixo.
O diagrama abaixo ilustra as atividades executadas aqui.
Etapa 3: Adicionado rotas para inspeção passando pelo Azure Firewall
Com isso será possível configurar nas UDRs todo tráfego destinado à sub-rede do private endpoint 10.100.1.0/25 serão encaminhadas para o Firewall sem a necessidade de adicionar cada rota /32 individualmente para casa private endpoint existente dentro do ambiente.
Tabela de rota aplicada na sub-rede da máquina virtual:
Tabela de rota aplicada na SubnetGateway
Podemos adicionar a rota na GatewaySubnet na rede virtual hub, para que o tráfego vindo do on-premises para os serviços de private endpoints também seja encaminhado para o Firewall.
Olhando novamente no nosso desenho do laboratório vemos as respectivas tabelas de rota configuradas e como o uso do Network Policy facilita essa configuração pois não temos a necessidade de adicionar individualmente cada endereço IP /32 na tabela rota.
Ao final temos arquitetura do nosso laboratório como ilustrado na imagem abaixo.
Teste e validações:
Para simular os testes temos uma conta de armazenamento com private endpoint configurado para a sub-rede destinada aos private endpoints 10.100.1.0/25 recebendo o endereçamento privado 10.100.4.4
No Azure Firewall temos uma regra de rede negando as conexões para a sub-rede 10.100.1.0/25 de qualquer origem, porta e protocolo. Relembrando está é a nossa sub-rede dedicada para os private endpoints.
Faremos os testes de resolução DNS e de conexão com a storage Account a partir das máquinas virtuais simulando on-premises e Spoke. A resolução DNS para a conta de armazenamento com private endpoint irá retornar o IP privado, porém a conexão para listar os Blobs dentro da conta de armazenamento usando a CLI irá falhar devido a regra de DENY do Firewall
Comandos utilizados:
- nslookup stalabnonprod01.blob.core.windows.net
- az storage blob list --account-name stalabnonprod01 --container-name teste --account-key <KEY DA CONTA DE ARMAZENAMENTO> --output table
Conexão a partir da máquina On-premises
- VM-Onpremises
- IP: 192.168.10.11
Resolução DNS OK
Tentativa de listar os blobs da conta de armazenamento stalabnonprod01 sem sucesso
Conexão a partir da máquina virtual Spoke
- VM-Spoke:
- IP: 10.100.0.4
Resolução DNS OK
Tentativa de listar os blobs da conta de armazenamento stalabnonprod01 sem sucesso
No Log do Firewall podemos validar a tentativa de conexão através da seguinte query de NetworkRule adicionado apenas ao final da query para trazer as conexões com a ação de “DENY”.
// Network rule log data
// Parses the network rule log data.
AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where OperationName == "AzureFirewallNatRuleLog" or OperationName == "AzureFirewallNetworkRuleLog"
//case 1: for records that look like this:
//PROTO request from IP:PORT to IP:PORT.
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " to " TargetIP ":" TargetPortInt:int *
//case 1a: for regular network rules
| parse kind=regex flags=U msg_s with * ". Action\\: " Action1a "\\."
//case 1b: for NAT rules
//TCP request from IP:PORT to IP:PORT was DNAT'ed to IP:PORT
| parse msg_s with * " was " Action1b:string " to " TranslatedDestination:string ":" TranslatedPort:int *
//Parse rule data if present
| parse msg_s with * ". Policy: " Policy ". Rule Collection Group: " RuleCollectionGroup "." *
| parse msg_s with * " Rule Collection: " RuleCollection ". Rule: " Rule
//case 2: for ICMP records
//ICMP request from 10.0.2.4 to 10.0.3.4. Action: Allow
| parse msg_s with Protocol2 " request from " SourceIP2 " to " TargetIP2 ". Action: " Action2
| extend
SourcePort = tostring(SourcePortInt),
TargetPort = tostring(TargetPortInt)
| extend
Action = case(Action1a == "", case(Action1b == "",Action2,Action1b), split(Action1a,".")[0]),
Protocol = case(Protocol == "", Protocol2, Protocol),
SourceIP = case(SourceIP == "", SourceIP2, SourceIP),
TargetIP = case(TargetIP == "", TargetIP2, TargetIP),
//ICMP records don't have port information
SourcePort = case(SourcePort == "", "N/A", SourcePort),
TargetPort = case(TargetPort == "", "N/A", TargetPort),
//Regular network rules don't have a DNAT destination
TranslatedDestination = case(TranslatedDestination == "", "N/A", TranslatedDestination),
TranslatedPort = case(isnull(TranslatedPort), "N/A", tostring(TranslatedPort)),
//Rule information
Policy = case(Policy == "", "N/A", Policy),
RuleCollectionGroup = case(RuleCollectionGroup == "", "N/A", RuleCollectionGroup ),
RuleCollection = case(RuleCollection == "", "N/A", RuleCollection ),
Rule = case(Rule == "", "N/A", Rule)
| project TimeGenerated, msg_s, Protocol, SourceIP,SourcePort,TargetIP,TargetPort,Action, TranslatedDestination, TranslatedPort, Policy, RuleCollectionGroup, RuleCollection, Rule
| where Action contains "Deny"
Visualizamos que o tráfego originando das máquinas 10.100.0.4 (SpokeVM) e 192.168.10.11 (VM Onpremises) para o destino 10.100.1.4 (endereço ip do private endpoint da conta de armazenamento) foi negado este tráfego pela regra do Azure Firewall “DenyPrivateEndpoint”.
Com isso validamos a inspeção do tráfego destinado para o private endpoint encaminhando esse tráfego para tratamento pelo Azure Firewall.
Para finalizar iremos excluir a regra de Deny no Azure Firewall, e com isso o acesso para a conta de armazenamento será permitida.
Testando novamente:
Acesso permitido a partir da VM Onpremises
Acesso permitido a partir da VM Spoke
Resumo:
- Network Policy habilitado na sub-rede destinado aos private endpoints.
- A injeção da rota de sistema /32 nas sub-redes será invalidada.
- Adicionar a rota com destino a sub-rede do private endpoint com Next Hop o Azure Firewall ou outra solução de NVA de terceiros
- Caso o tráfego de origem vindo do on-premises para o private endpoint também seja encaminhado para o firewall basta adicionar a rota na UDR da SubnetGateway
Links para mais informações:
What is a private endpoint? - Azure Private Link | Microsoft Learn
Manage network policies for private endpoints - Azure Private Link | Microsoft Learn
Manage blob containers using Azure CLI - Azure Storage | Microsoft Learn
Microsoft
