Configurar as regras de Firewall do Azure

  • Artigo

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 Firewall do Azure nega todo o tráfego por padrã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, de números menores para maiores, de 100 a 65.000. Um nome de coleção de regras pode ter apenas letras, números, sublinhados, pontos ou hifens. Ele precisa começar com uma letra ou um número e terminar com uma letra, um número ou um sublinhado. O tamanho máximo do nome é de 80 caracteres.

É melhor espaçar inicialmente os números de prioridade da coleção de regras em incrementos de 100 (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 coleções de regras. Grupos de coleções de regras contêm zero ou mais coleções de regras. As coleções de regras são do tipo NAT, de Rede ou de Aplicativos. Você pode definir vários tipos de coleção de regras em apenas um grupo de regras. Você pode definir zero ou mais regras em uma coleção de regras. As regras em uma coleção de regras precisam ser do mesmo tipo (NAT, de rede ou de aplicativo).

As regras são processadas com base na prioridade do grupo de coleções de regras e na prioridade da coleção de regras. Prioridade é qualquer número entre 100 (prioridade mais alta) a 65.000 (prioridade mais baixa). Os grupos de coleções de regras de prioridade mais alta são processados primeiro. Dentro de um grupo de coleções 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 coleções de regras na política pai sempre têm precedência, independentemente da prioridade de uma política filho.

Observação

As regras de aplicativo sempre são processadas após as regras de rede, que são processadas após as regras de DNAT, independentemente da herança de política e da prioridade do grupo de coleções de regras ou da coleção de regras.

Este é um exemplo de política:

Supondo que BaseRCG1 seja uma prioridade de grupo de coleta de regras (200) que contenha 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 coleção 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 coleções de regras 200 8 Política pai
DNATRC1 Coleção de regras DNAT 600 7 Política pai
DNATRC3 Coleção de regras DNAT 610 3 Política pai
NetworkRC1 Coleção de regras de rede 800 1 Política pai
BaseRCG2 Grupo de coleções de regras 300 3 Política pai
AppRC2 Coleção de regras de aplicativo 1200 2 Política pai
NetworkRC2 Coleção de regras de rede 1300 1 Política pai
ChildRCG1 Grupo de coleções de regras 300 5 -
ChNetRC1 Coleção de regras de rede 700 3 -
ChAppRC1 Coleção de regras de aplicativo 900 2 -
ChildRCG2 Grupo de coleções de regras 650 9 -
ChNetRC2 Coleção 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 menor número, que é BaseRCG1 com uma prioridade de 200. Dentro desse grupo, ele procura coleções de regras DNAT e as avalia de acordo com suas prioridades. Nesse caso, DNATRC1 (prioridade 600) e DNATRC3 (prioridade 610) são encontrados e processados adequadamente.
Em seguida, ele passa para o próximo RCG, BaseRCG2 (prioridade 200), mas não encontra nenhuma coleção de regras DNAT.
Depois disso, ele segue para ChildRCG1 (prioridade 300), também sem uma coleção de regras DNAT.
Por fim, ele verifica ChildRCG2 (prioridade 650) e localiza a coleção de regras ChDNATRC3 (prioridade 3000).

Iteração dentro de grupos de coleção de regras:

Retornando ao BaseRCG1, a iteração continua, desta vez para as regras de REDE. Somente NetworkRC1 (prioridade 800) é encontrado.
Em seguida, ele passa 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 localiza ChNetRC2 (prioridade 1100) como a coleção de regras NETWORK.

Iteração final para regras de aplicativo:

Retornando ao BaseRCG1, o processo itera para as regras APPLICATION, mas nenhuma foi encontrada.
No BaseRCG2, ele identifica AppRC2 (prioridade 1200) como a regra APPLICATION.
No ChildRCG1, ChAppRC1 (prioridade 900) é encontrado como a regra APPLICATION.
Por fim, 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).

Portanto, primeiro todas as regras DNAT são processadas de todos os grupos de coleção 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, por fim, para regras de APLICATIVO.

Para obter mais informações sobre os conjuntos de regras da Política de Firewall, confira Conjunto de regras da Política de Firewall do Azure.

Inteligência contra ameaças

Se você habilitar a filtragem baseada em inteligência contra ameaças, essas regras terão prioridade mais alta e sempre serão processadas primeiro (antes das regras de rede e de aplicativo). A filtragem de inteligência de ameaças pode negar o tráfego antes que as regras configuradas sejam processadas. Para obter mais informações, confira Filtragem baseada em inteligência contra ameaças do Firewall do Azure.

IDPS

Quando o IDPS está configurado no modo de Alerta, o mecanismo do IDPS trabalha em paralelo à lógica de processamento de regras e gera alertas sobre assinaturas correspondentes para fluxos de entrada e de 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 está configurado no modo de Alerta e negação, o mecanismo do IDPS é embutido e ativado após o mecanismo de processamento de regras. Assim, os dois mecanismos geram alertas e podem bloquear fluxos correspondentes. 

Remoções de sessão feitas por IDPS bloqueiam o fluxo silenciosamente. Assim, nenhum RST é enviado no nível de TCP. Como o IDPS inspeciona o tráfego sempre após a correspondência da regra de rede/aplicativo (permitir/negar) e marcada nos logs, outra mensagem de Remoção pode ser registrada em log, em que IDPS decide negar a sessão devido a uma correspondência de assinatura.

Quando a inspeção TLS é habilitada, tanto o tráfego não criptografado quanto o criptografado são inspecionados. 

Conectividade de saída

Regras de rede e regras de aplicativos

Se você configurar regras de rede e regras de aplicativo, a ordem de prioridade será com as regras de rede sendo aplicadas antes das regras de aplicativo. As regras estão sendo encerradas. Assim, se uma correspondência for encontrada em uma regra de rede, nenhuma outra regra será processada. O IDPS, se configurado, é feito em todo o tráfego atravessado e na correspondência de assinatura e pode alertar ou/e bloquear o tráfego suspeito.

As regras de aplicativo avaliarão o pacote por ordem de prioridade se não houver nenhuma correspondência da regra de rede e se o protocolo for HTTP, HTTPS ou MSSQL.

Para HTTP, o Firewall do Azure procura uma regra de aplicativo correspondente de acordo com o cabeçalho do host. Para HTTPS, o Firewall do Azure procura uma regra de aplicativo correspondente de acordo somente com SNI.

Em casos com HTTPS inspecionado 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 de 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á removido. A resolução DNS é feita pelo DNS do Azure ou por um DNS personalizado, se configurado no firewall. 

Observação

Os protocolos HTTP e HTTPS (com a inspeção TLS) sempre são preenchidos pelo Firewall do Azure com o cabeçalho XFF (X-Forwarded-For) igual ao endereço IP de origem original. 

Quando uma regra de aplicativo contém a inspeção TLS, o SNI do processo de mecanismo de regras de firewall, o cabeçalho do host 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 nenhuma correspondência, o pacote será negado por padrão.

Observação

Regras de rede podem ser configuradas para os protocolos IP TCP, UDP, ICMP ou Any. O protocolo IP Any inclui todos os protocolos IP, conforme definido no documento de números de protocolo da IANA (Internet Assigned Numbers Authority). Se uma porta de destino estiver configurada explicitamente, a regra será convertida em uma regra TCP + UDP. Antes de 9 de novembro de 2020, Anysignificava TCP, 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 segundo a definição atual, modifique a regra para configurar explicitamente os protocolos desejados (TCP, UDP ou ICMP).

Conexões de entrada

Regras DNAT e regras de rede

A conectividade de entrada de Internet pode ser habilitada configurando a DNAT (conversão de endereços de rede de destino) conforme descrito em Filtrar o tráfego de entrada com DNAT de Firewall do Azure usando o portal do Azure. As regras NAT são aplicadas com prioridade que precede a das regras de rede. Se uma correspondência for encontrada, o tráfego será convertido de acordo com a regra DNAT e permitido pelo firewall. Assim o tráfego não está sujeito a nenhum processamento adicional por outras regras de rede. Por motivos de segurança, a abordagem recomendada é adicionar uma fonte específica de Internet para permitir o acesso DNAT à rede e evitar o uso de caracteres curinga.

As regras de aplicativo não são aplicadas a conexões de entrada. Portanto, se você quiser filtrar tráfego HTTP/S de entrada, deverá usar o WAF (Firewall de Aplicativo Web). Para obter mais informações, confira 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 o google.com é permitida devido a uma regra de rede correspondente.

Regra de rede

  • Ação: Permitir
name Protocolo Tipo de origem Fonte Tipo de destino Endereço de destino Portas de destino
Allow-web TCP Endereço IP * Endereço IP * 80.443

Regra de aplicativo

  • Ação: Negar
name Tipo de origem Fonte Protocolo:Porta FQDNs de destino
Deny-google Endereço IP * http:80,https:443 google.com

Resultado

A conexão com google.com é permitida porque o pacote corresponde à regra de rede Allow-web. O processamento da regra é interrompido neste ponto.

Exemplo 2

O tráfego SSH é negado porque uma coleção de regras de rede Negar de prioridade mais alta o bloqueia.

Coleção de regras de rede 1

  • Nome: Allow-collection
  • Prioridade: 200
  • Ação: Permitir
name Protocolo Tipo de origem Fonte Tipo de destino Endereço de destino Portas de destino
Allow-SSH TCP Endereço IP * Endereço IP * 22

Coleção de regras de rede 2

  • Nome: Deny-collection
  • Prioridade: 100
  • Ação: Negar
name Protocolo Tipo de origem Fonte Tipo de destino Endereço de destino Portas de destino
Deny-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 as bloqueia. O processamento da regra é interrompido neste ponto.

Alterações de regra

Se você alterar uma regra para negar tráfego anteriormente permitido, todas as sessões relevantes existentes serão removidas.

Comportamento de handshake de três vias

Como um serviço com 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, da VNet-A para a VNet-B.

A criação de uma regra de permissão da VNet-A para a VNet-B não significa que novas conexões iniciadas da VNet-B para a VNet-A são permitidas.

Como resultado, não há necessidade de criar uma regra de negação explícita da VNet-B para a VNet-A. Ao criar essa regra de negação, você interromperá o handshake de três vias da regra de permissão inicial da VNet-A para a VNet-B.

Próximas etapas