Laboratório Técnico: Configure Azure Firewall Rules
Questões
Questão 1 — Múltipla Escolha
Uma equipe de segurança precisa permitir que VMs internas acessem exclusivamente o endpoint https://updates.contoso.com na porta 443, bloqueando qualquer outro destino HTTPS. O Azure Firewall Standard está implantado como ponto central de saída da VNet.
Qual tipo de regra deve ser criado para atender a esse requisito com o menor escopo de permissão possível?
A) Regra de rede permitindo tráfego na porta 443 com destino ao endereço IP resolvido de updates.contoso.com.
B) Regra de aplicação permitindo o FQDN updates.contoso.com na porta 443 com protocolo Https.
C) Regra de rede permitindo tráfego na porta 443 com destino à tag de serviço Internet.
D) Regra de NAT (DNAT) redirecionando o tráfego de saída na porta 443 para o endereço IP de updates.contoso.com.
Questão 2 — Cenário Técnico
Um administrador configurou a seguinte política no Azure Firewall para permitir que VMs de desenvolvimento acessem repositórios de pacotes do Linux:
Tipo: Regra de Aplicação
Nome: allow-linux-repos
Origem: 10.10.2.0/24
Protocolo: Http:80, Https:443
FQDNs de destino:
- *.ubuntu.com
- *.debian.org
- *.snapcraft.io
Ação: Allow
Após a implantação, as VMs conseguem baixar pacotes via HTTPS, mas falham ao tentar atualizar via HTTP. O firewall está registrando os logs de bloqueio com a regra padrão de negação.
Qual é a causa mais provável do problema?
A) Regras de aplicação no Azure Firewall não suportam múltiplos protocolos na mesma regra; é necessário criar regras separadas para HTTP e HTTPS.
B) O protocolo Http:80 em regras de aplicação exige que o Azure Firewall esteja no tier Premium com inspeção TLS habilitada para funcionar corretamente.
C) As VMs não possuem rota definida pelo usuário (UDR) apontando o tráfego HTTP (porta 80) para o IP privado do Azure Firewall, enquanto o tráfego HTTPS já está sendo roteado corretamente.
D) Regras de aplicação no Azure Firewall processam apenas tráfego que passa pelo proxy de aplicação interno, e conexões HTTP diretas de VMs não são interceptadas sem configuração adicional de proxy transparente.
Questão 3 — Múltipla Escolha
Uma política de Azure Firewall contém as seguintes regras de rede em uma única coleção de regras:
Prioridade da coleção: 200
Ação da coleção: Allow
Regra 1: Origem 10.0.1.0/24 | Destino 10.0.2.0/24 | Porta 443 | Allow
Regra 2: Origem 10.0.1.0/24 | Destino 10.0.2.0/24 | Porta Any | Allow
Regra 3: Origem 10.0.1.0/24 | Destino Any | Porta 443 | Deny
Uma VM em 10.0.1.10 tenta acessar um servidor em 10.0.2.50 na porta 443. Qual será o resultado?
A) A conexão será bloqueada pela Regra 3, pois ela tem destino Any e é mais abrangente que a Regra 1.
B) A conexão será permitida pela Regra 1, pois dentro de uma coleção as regras são avaliadas em ordem e a primeira correspondência é aplicada.
C) A conexão será permitida pela Regra 2, pois ela cobre qualquer porta e tem precedência sobre regras mais específicas dentro da mesma coleção.
D) O Azure Firewall retornará um erro de configuração, pois não é permitido ter regras de Allow e Deny na mesma coleção de regras.
Questão 4 — Verdadeiro ou Falso
Em uma política de Azure Firewall, regras de rede têm precedência sobre regras de aplicação na ordem de processamento, o que significa que, se um tráfego HTTPS for permitido por uma regra de rede, ele não será avaliado pelas regras de aplicação.
Verdadeiro ou Falso?
Questão 5 — Cenário Técnico
Uma empresa expõe um servidor web interno (10.1.0.10:80) para usuários externos através de uma regra DNAT no Azure Firewall. O IP público do firewall é 20.50.100.1. A regra está configurada da seguinte forma:
Tipo: Regra DNAT
Nome: inbound-web
IP público de destino: 20.50.100.1
Porta de destino: 80
IP traduzido: 10.1.0.10
Porta traduzida: 80
Protocolo: TCP
Os usuários externos conseguem acessar o servidor normalmente. No entanto, ao investigar os logs do servidor web, o time de operações percebe que todos os acessos chegam com o IP de origem 20.50.100.x (um IP do Azure Firewall), e não com os IPs reais dos clientes externos.
Qual é a explicação técnica para esse comportamento?
A) O Azure Firewall aplica SNAT automaticamente no tráfego que sofre DNAT, substituindo o IP de origem do cliente pelo IP privado do firewall antes de encaminhar o pacote ao servidor interno.
B) O comportamento indica uma configuração incorreta: a regra DNAT deveria incluir o campo de IP de origem do cliente para preservar o endereço original.
C) O servidor web está recebendo os pacotes com o IP original do cliente, mas o sistema operacional da VM está exibindo o IP do firewall por conta de uma configuração de proxy reverso local.
D) Esse comportamento ocorre apenas quando o Azure Firewall Standard é usado; o Premium preserva o IP de origem do cliente em conexões DNAT por padrão.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Regras de aplicação são o mecanismo correto para controlar acesso a FQDNs específicos no Azure Firewall. Elas permitem especificar o destino como um FQDN com protocolo e porta, e o firewall resolve e rastreia o FQDN dinamicamente, cobrindo mudanças de IP sem necessidade de atualização manual da regra.
A alternativa A cria acoplamento direto a um endereço IP que pode mudar, além de não ser o mecanismo projetado para filtragem por nome de domínio. A alternativa C é excessivamente permissiva, liberando qualquer destino HTTPS na internet. A alternativa D confunde DNAT, que é usado para tradução de endereços de entrada, com controle de tráfego de saída por FQDN.
Gabarito — Questão 2
Resposta: C
O Azure Firewall só inspeciona e aplica regras ao tráfego que é explicitamente roteado para ele via UDR (User Defined Route). Se a tabela de rotas das VMs de desenvolvimento encaminha apenas o tráfego destinado à porta 443 para o IP do firewall, o tráfego na porta 80 seguirá a rota padrão do sistema, não passando pelo firewall. Como resultado, a regra de aplicação nunca é avaliada para esse tráfego e ele pode ser bloqueado ou roteado incorretamente.
A alternativa A está errada: regras de aplicação suportam múltiplos protocolos na mesma regra sem restrição. A alternativa B está errada porque Http:80 em regras de aplicação funciona no Standard sem inspeção TLS, que é relevante apenas para HTTPS. A alternativa D descreve um comportamento que não corresponde ao funcionamento do Azure Firewall, que intercepta o tráfego roteado para ele sem necessidade de configuração de proxy transparente adicional.
Gabarito — Questão 3
Resposta: B
Dentro de uma coleção de regras no Azure Firewall, as regras são avaliadas em ordem sequencial e a primeira correspondência determina o resultado. A Regra 1 corresponde ao tráfego de 10.0.1.10 para 10.0.2.50 na porta 443 antes que a Regra 3 seja avaliada. Portanto, a conexão é permitida.
A alternativa A representa um equívoco comum: a abrangência do destino não determina precedência; a ordem de avaliação dentro da coleção é o fator decisivo. A alternativa C está errada pelo mesmo motivo: regras mais abrangentes não têm precedência sobre regras mais específicas quando aparecem depois na ordem. A alternativa D está errada: uma coleção de regras tem uma única ação (Allow ou Deny) que se aplica a toda a coleção; não é possível ter ações mistas dentro da mesma coleção, o que significa que a Regra 3 com ação Deny em uma coleção de Allow seria inválida ou ignorada, reforçando que a Regra 1 prevalece.
Gabarito — Questão 4
Resposta: Verdadeiro
A ordem de processamento do Azure Firewall é: primeiro as regras DNAT, depois as regras de rede, e por último as regras de aplicação. Se um fluxo de tráfego é correspondido e permitido por uma regra de rede, o processamento encerra ali e as regras de aplicação não são avaliadas para aquele fluxo.
Essa sequência tem implicações práticas importantes: uma regra de rede excessivamente permissiva para tráfego HTTPS pode inadvertidamente contornar regras de aplicação que restringem FQDNs específicos. O design correto para controle granular de saída HTTPS é evitar regras de rede amplas na porta 443 e usar exclusivamente regras de aplicação para esse tráfego.
Gabarito — Questão 5
Resposta: A
Esse é o comportamento esperado e documentado do Azure Firewall. Quando uma regra DNAT é processada, o firewall aplica automaticamente SNAT no tráfego traduzido, substituindo o IP de origem do cliente externo pelo IP privado do próprio firewall antes de encaminhar o pacote ao servidor interno. Isso ocorre porque o servidor interno precisa retornar o tráfego de resposta através do firewall, e o SNAT garante que o retorno seja roteado corretamente.
A consequência prática é que o servidor interno nunca vê o IP real do cliente externo diretamente. Para preservar o IP de origem, a solução arquitetural é usar um HTTP header X-Forwarded-For via proxy ou Application Gateway na frente do servidor. A alternativa B está errada porque não existe campo de preservação de IP de origem em regras DNAT do Azure Firewall. As alternativas C e D descrevem comportamentos que não correspondem à plataforma.