Configurar as regras de Firewall do Azure

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. As regras estão sendo encerradas, portanto, o processamento de regras é interrompido em uma correspondência.

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.

Portanto, para resumir:

A política pai sempre tem precedência.

1. Os grupos de coleta de regras são processados em ordem de prioridade.
2. As coleções de regras são processadas em ordem de prioridade.
3. Primeiro, as regras de DNAT, depois as regras de rede e, em seguida, as regras de aplicativo são processadas.

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 (300) que contém as coleções de regras: ChNetRC1, ChAppRC1.
ChildRCG2 é uma prioridade de grupo de coleta de regras (650) que contém as coleções de regras: ChNetRC2, ChAppRC2,ChDNATRC3.

De acordo com a tabela a seguir:

Iteração inicial para regras DNAT:

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 300), 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 para regras de REDE:

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. 

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.

Conexões de entrada

Regras DNAT e regras de rede

A conectividade de entrada de Internet ou intranet (versão prévia) pode ser habilitada configurando a DNAT (conversão de endereços de rede de destino) conforme descrito em Filtrar o tráfego de entrada de Internet ou intranet 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

Regra de aplicativo

• Ação: Negar

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

Coleção de regras de rede 2

• Nome: Deny-collection
• Prioridade: 100
• Ação: Negar

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.

Próximas etapas

• Saiba mais sobre os comportamentos da NAT do Firewall do Azure
• Aprenda a implantar e configurar um Firewall do Azure
• Saiba mais sobre segurança de rede do Azure