Configurar as regras do Azure Firewall
Você pode configurar regras NAT, regras de rede e regras de aplicativos no Firewall do Azure usando regras clássicas ou a Política de Firewall. O Azure Firewall nega todo o tráfego por predefinição, até que as regras sejam configuradas manualmente para permitir o tráfego.
Processamento de regras usando regras clássicas
As coleções de regras são processadas de acordo com o tipo de regra em ordem de prioridade, números mais baixos para números mais altos de 100 a 65.000. Um nome de coleção de regras pode ter apenas letras, números, sublinhados, pontos ou hífenes. Deve começar com uma letra ou número e terminar com uma letra, número ou sublinhado. O comprimento máximo do nome é de 80 caracteres.
É melhor inicialmente espaçar os números de prioridade da coleção de regras em 100 incrementos (100, 200, 300 e assim por diante) para que você tenha espaço para adicionar mais coleções de regras, se necessário.
Processamento de regras usando a Política de Firewall
Com a Política de Firewall, as regras são organizadas dentro de Coleções de Regras e Grupos de Coleta de Regras. Os Grupos de Recolha de Regras contêm zero ou mais Coleções de Regras. As Coleções de Regras são do tipo NAT, Rede ou Aplicativos. Você pode definir vários tipos de Coleção de Regras em um único Grupo de Regras. Você pode definir zero ou mais Regras em uma Coleção de Regras. As regras em uma Coleção de Regras devem ser do mesmo tipo (NAT, Rede ou Aplicativo).
As regras são processadas com base na prioridade do Grupo de Recolha de Regras e na prioridade da Recolha de Regras. Prioridade é qualquer número entre 100 (prioridade mais alta) a 65.000 (prioridade mais baixa). Os Grupos de Coleta de Regras de prioridade mais alta são processados primeiro. Dentro de um grupo de coleta de regras, as Coleções de Regras com prioridade mais alta (número mais baixo) são processadas primeiro.
Se uma Política de Firewall for herdada de uma política pai, os Grupos de Recolha de Regras na política principal terão sempre precedência, independentemente da prioridade de uma política subordinada.
Nota
As regras de aplicativo são sempre processadas após as regras de rede, que são processadas após as regras DNAT, independentemente do grupo de coleta de regras ou da prioridade de coleta de regras e herança de políticas.
Aqui está um exemplo de política:
Supondo que BaseRCG1 é uma prioridade de grupo de coleta de regras (200) que contém as coleções de regras: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 é uma prioridade de grupo de coleta de regras (300) que contém as coleções de regras: AppRC2, NetworkRC2.
ChildRCG1 é uma prioridade de grupo de coleta de regras (200) que contém as coleções de regras: ChNetRC1, ChAppRC1.
ChildRCG2 é um grupo de coleta de regras que contém as coleções de regras: ChNetRC2, ChAppRC2,ChDNATRC3.
De acordo com a tabela a seguir:
| Nome | Tipo | Prioridade | Regras | Herdado de |
|---|---|---|---|---|
| BaseRCG1 | Grupo de recolha de regras | 200 | 8 | Política de pais |
| DNATRC1 | Coleção de regras DNAT | 600 | 7 | Política de pais |
| DNATRC3 | Coleção de regras DNAT | 610 | 3 | Política de pais |
| RedeRC1 | Recolha de regras de rede | 800 | 1 | Política de pais |
| BaseRCG2 | Grupo de recolha de regras | 300 | 3 | Política de pais |
| AppRC2 | Coleção de regras de aplicativo | 1200 | 2 | Política de pais |
| RedeRC2 | Recolha de regras de rede | 1300 | 1 | Política de pais |
| CriançaRCG1 | Grupo de recolha de regras | 300 | 5 | - |
| ChNetRC1 | Recolha de regras de rede | 700 | 3 | - |
| ChAppRC1 | Coleção de regras de aplicativo | 900 | 2 | - |
| CriançaRCG2 | Grupo de recolha de regras | 650 | 9 | - |
| ChNetRC2 | Recolha de regras de rede | 1100 | 2 | - |
| ChAppRC2 | Coleção de regras de aplicativo | 2000 | 7 | - |
| ChDNATRC3 | Coleção de regras DNAT | 3000 | 2 | - |
Processamento inicial:
O processo começa examinando o grupo de coleta de regras (RCG) com o número mais baixo, que é BaseRCG1 com uma prioridade de 200. Dentro desse grupo, ele busca por coleções de regras do DNAT e as avalia de acordo com suas prioridades. Neste caso, DNATRC1 (prioridade 600) e DNATRC3 (prioridade 610) são encontradas e processadas em conformidade.
Em seguida, ele passa para o próximo RCG, BaseRCG2 (prioridade 200), mas não encontra nenhuma coleção de regras DNAT.
Em seguida, prossegue para o ChildRCG1 (prioridade 300), também sem uma coleta de regras DNAT.
Finalmente, verifica o ChildRCG2 (prioridade 650) e encontra a coleção de regras ChDNATRC3 (prioridade 3000).
Iteração dentro de grupos de coleta de regras:
Voltando ao BaseRCG1, a iteração continua, desta vez para as regras NETWORK. Apenas NetworkRC1 (prioridade 800) é encontrado.
Em seguida, ele se move para BaseRCG2, onde NetworkRC2 (prioridade 1300) está localizado.
Passando para ChildRCG1, ele descobre ChNetRC1 (prioridade 700) como a regra NETWORK.
Por fim, no ChildRCG2, ele encontra ChNetRC2 (prioridade 1100) como a coleção de regras NETWORK.
Iteração final para regras de APLICAÇÃO:
Voltando ao BaseRCG1, o processo itera para regras APPLICATION, mas nenhuma é encontrada.
Em BaseRCG2, identifica AppRC2 (prioridade 1200) como a regra APPLICATION.
Em ChildRCG1, ChAppRC1 (prioridade 900) é encontrado como a regra APPLICATION.
Finalmente, no ChildRCG2, ele localiza ChAppRC2 (prioridade 2000) como a regra APPLICATION.
Em resumo, a sequência de processamento de regras é a seguinte: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.
Esse processo envolve a análise de grupos de coleta de regras por prioridade e, dentro de cada grupo, ordenando as regras de acordo com suas prioridades para cada tipo de regra (DNAT, NETWORK e APPLICATION).
Assim, primeiro, todas as regras DNAT são processadas a partir de todos os grupos de coleta de regras, analisando os grupos de coleta de regras por ordem de prioridade e ordenando as regras DNAT dentro de cada grupo de coleta de regras por ordem de prioridade. Em seguida, o mesmo processo para regras de rede e, finalmente, para regras de aplicação.
Para obter mais informações sobre conjuntos de regras de Política de Firewall, consulte Conjuntos de regras de Política de Firewall do Azure.
Informações sobre Ameaças
Se você habilitar a filtragem baseada em inteligência de ameaças, essas regras terão prioridade máxima e serão sempre processadas primeiro (antes das regras de rede e aplicativo). A filtragem de inteligência de ameaças pode negar o tráfego antes que quaisquer regras configuradas sejam processadas. Para obter mais informações, consulte Filtragem baseada em inteligência de ameaças do Firewall do Azure.
IDPS
Quando o IDPS é configurado no modo de alerta , o mecanismo IDPS funciona em paralelo à lógica de processamento da regra e gera alertas sobre assinaturas correspondentes para fluxos de entrada e saída. Para uma correspondência de assinatura IDPS, um alerta é registrado nos logs do firewall. No entanto, como o mecanismo IDPS funciona em paralelo ao mecanismo de processamento de regras, o tráfego negado ou permitido pelas regras de aplicativo/rede ainda pode gerar outra entrada de log.
Quando o IDPS é configurado no modo Alerta e Negar , o mecanismo IDPS é embutido e ativado após o mecanismo de processamento de regras. Assim, ambos os mecanismos geram alertas e podem bloquear fluxos correspondentes.
As interrupções de sessão feitas pelo IDPS bloqueiam o fluxo silenciosamente. Portanto, nenhum RST é enviado no nível TCP. Como o IDPS inspeciona o tráfego sempre depois que a regra de Rede/Aplicativo foi correspondida (Permitir/Negar) e marcada em logs, outra mensagem de Drop pode ser registrada onde o IDPS decide negar a sessão devido a uma correspondência de assinatura.
Quando a inspeção TLS está habilitada, o tráfego não criptografado e criptografado é inspecionado.
Conectividade de saída
Regras de rede e regras de aplicações
Se você configurar regras de rede e regras de aplicativo, as regras de rede serão aplicadas em ordem de prioridade antes das regras de aplicativo. As regras estão a terminar. Portanto, se uma correspondência for encontrada em uma regra de rede, nenhuma outra regra será processada. Se configurado, o IDPS é feito em todo o tráfego percorrido e, após a correspondência de assinatura, o IDPS pode alertar e/ou bloquear o tráfego suspeito.
Em seguida, as regras de aplicativo avaliam o pacote em ordem de prioridade se não houver correspondência de regra de rede e se o protocolo for HTTP, HTTPS ou MSSQL.
Para HTTP, o Firewall do Azure procura uma correspondência de regra de aplicativo de acordo com o cabeçalho do Host. Para HTTPS, o Firewall do Azure procura uma correspondência de regra de aplicativo somente de acordo com o SNI.
Em casos HTTPS inspecionados por HTTP e TLS, o firewall ignora o endereço IP de destino do pacote e usa o endereço IP resolvido pelo DNS do cabeçalho do host. O firewall espera obter o número da porta no cabeçalho do host, caso contrário, ele assume a porta padrão 80. Se houver uma incompatibilidade de porta entre a porta TCP real e a porta no cabeçalho do host, o tráfego será descartado. A resolução de DNS é feita pelo DNS do Azure ou por um DNS personalizado, se configurado no firewall.
Nota
Os protocolos HTTP e HTTPS (com inspeção TLS) são sempre preenchidos pelo Firewall do Azure com cabeçalho XFF (X-Forwarded-For) igual ao endereço IP de origem original.
Quando uma regra de aplicativo contém inspeção TLS, o mecanismo de regras de firewall processa SNI, Host Header e também a URL para corresponder à regra.
Se ainda assim nenhuma correspondência for encontrada nas regras do aplicativo, o pacote será avaliado em relação à coleção de regras de infraestrutura. Se ainda não houver correspondência, o pacote será negado por padrão.
Nota
As regras de rede podem ser configuradas para TCP, UDP, ICMP ou qualquer protocolo IP. Qualquer protocolo IP inclui todos os protocolos IP conforme definido no documento Números de Protocolo da Internet Assigned Numbers Authority (IANA). Se uma porta de destino estiver explicitamente configurada, a regra será convertida para uma regra TCP+UDP. Antes de 9 de novembro de 2020, qualquer significava TCP, ou UDP, ou ICMP. Portanto, você pode ter configurado uma regra antes dessa data com Protocol = Any, e destination ports = '*'. Se você não pretende permitir nenhum protocolo IP como definido atualmente, modifique a regra para configurar explicitamente o(s) protocolo(s) desejado(s) (TCP, UDP ou ICMP).
Conectividade de entrada
Regras DNAT e regras de rede
A conectividade de entrada com a Internet pode ser habilitada configurando a Tradução de Endereço de Rede de Destino (DNAT), conforme descrito em Filtrar tráfego de entrada com DNAT do Firewall do Azure usando o portal do Azure. As regras NAT são aplicadas com prioridade antes das regras de rede. Se for encontrada uma correspondência, o tráfego é traduzido de acordo com a regra DNAT e permitido pelo firewall. Assim, o tráfego não está sujeito a qualquer processamento adicional por outras regras de rede. Por razões de segurança, a abordagem recomendada é adicionar uma fonte de Internet específica para permitir o acesso DNAT à rede e evitar o uso de curingas.
As regras de aplicativo não são aplicadas para conexões de entrada. Portanto, se você quiser filtrar o tráfego HTTP/S de entrada, use o Web Application Firewall (WAF). Para obter mais informações, consulte O que é o Firewall de Aplicativo Web do Azure?
Exemplos
Os exemplos a seguir mostram os resultados de algumas dessas combinações de regras.
Exemplo 1
A conexão com google.com é permitida devido a uma regra de rede correspondente.
Regra de rede
- Ação: Permitir
| nome | Protocolo | Source type | Source | Tipo de destino | Endereço de destino | Portas de destino |
|---|---|---|---|---|---|---|
| Permitir-web | TCP | Endereço IP | * | Endereço IP | * | 80,443 |
Regra de aplicação
- Ação: Negar
| nome | Source type | Source | Protocolo:Porta | FQDNs de destino |
|---|---|---|---|---|
| Negar-google | Endereço IP | * | Disponível em:80,https:443 | google.com |
Resultado
A conexão com google.com é permitida porque o pacote corresponde à regra de rede Allow-web . O processamento de regras para neste ponto.
Exemplo 2
O tráfego SSH é negado porque uma prioridade mais alta Negar coleta de regras de rede o bloqueia.
Coleção de regras de rede 1
- Designação: Allow-collection
- Prioridade: 200
- Ação: Permitir
| nome | Protocolo | Source type | Source | Tipo de destino | Endereço de destino | Portas de destino |
|---|---|---|---|---|---|---|
| Permitir-SSH | TCP | Endereço IP | * | Endereço IP | * | 22 |
Coleção de regras de rede 2
- Designação: Deny-collection
- Prioridade: 100
- Ação: Negar
| nome | Protocolo | Source type | Source | Tipo de destino | Endereço de destino | Portas de destino |
|---|---|---|---|---|---|---|
| Negar-SSH | TCP | Endereço IP | * | Endereço IP | * | 22 |
Resultado
As conexões SSH são negadas porque uma coleção de regras de rede de prioridade mais alta a bloqueia. O processamento de regras para neste ponto.
Alterações às regras
Se você alterar uma regra para negar o tráfego permitido anteriormente, todas as sessões existentes relevantes serão descartadas.
Comportamento de aperto de mão de três vias
Como um serviço com monitoração de estado, o Firewall do Azure conclui um handshake TCP de três vias para o tráfego permitido, de uma origem para o destino. Por exemplo, VNet-A para VNet-B.
A criação de uma regra de permissão da VNet-A para a VNet-B não significa que as ligações iniciadas de novo a partir da VNet-B para a VNet-A sejam permitidas.
Como resultado, não há necessidade de criar uma regra de negação explícita de VNet-B para VNet-A. Se você criar essa regra de negação, interromperá o handshake de três vias da regra de permissão inicial de VNet-A para VNet-B.