Configurar regras do 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 Azure Firewall nega todo o tráfego por predefinição, até que as regras sejam configuradas manualmente para permitir o tráfego. As regras estão terminando, portanto, o processamento de regras para em uma partida.

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 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 Coleção 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 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 superior, os grupos de regras na política superior terão sempre precedência, independentemente da prioridade de uma política subordinada.

Assim, resumindo:

A política de pais 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. Regras DNAT, regras de rede e, em seguida, regras de aplicativo são processadas.

Aqui está um exemplo de política:

Supondo que BaseRCG1 é uma prioridade do grupo de coleções 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 é um grupo de coleções de regras prioritário (300) que contém as seguintes coleções de regras: ChNetRC1, ChAppRC1.
ChildRCG2 é um grupo de conjunto de regras prioritário (650) que contém os conjuntos 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 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 300), mas não encontra nenhuma coleção de regras DNAT.
Em seguida, prossegue para o ChildRCG1 (prioridade 300), também sem uma coleção de regras DNAT.
Finalmente, verifica o ChildRCG2 (prioridade 650) e encontra a coleção de regras ChDNATRC3 (prioridade 3000).

Iteração para regras de rede:

Voltando ao BaseRCG1, a iteração continua, desta vez para as regras de rede. 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 de APLICAÇÃO, mas nenhuma é encontrada.
Em BaseRCG2, identifica AppRC2 (prioridade 1200) como a regra de APLICAÇÃO.
Em ChildRCG1, ChAppRC1 (prioridade 900) é encontrado como regra APPLICATION.
Finalmente, no ChildRCG2, ele localiza ChAppRC2 (prioridade 2000) como a regra APLICAÇÃO.

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.

Inteligência de 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 bloquear o tráfego antes que todas as regras configuradas sejam processadas. Para obter mais informações, consulte Filtragem baseada em inteligência de ameaças do Firewall do Azure.

Deslocados internos

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 quedas 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 após a regra de Rede/Aplicação ser correspondida (Permitir/Negar) e registada nos logs, pode ser registada outra mensagem de Cancelar quando 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 numa regra de rede, nenhuma outra regra será processada. Se configurado, o IDPS ocorre em todo o tráfego percorrido e, após a correspondência com a assinatura, o IDPS pode alertar 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 regra de aplicação que corresponda ao 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 de inspeção tanto de HTTP quanto de HTTPS por TLS, o firewall ignora o endereço IP de destino do pacote e utiliza o endereço IP resolvido pelo DNS a partir do cabeçalho 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. 

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 predefinição.

Recolha de regras de infraestrutura

O Azure Firewall inclui uma coleção de regras incorporadas para os FQDNs de infraestrutura que são permitidos por predefinição. Estes FQDNs são específicos da plataforma e não podem ser utilizados para outros fins. A recolha das regras de infraestrutura é processada após as regras de aplicação e antes da regra final de negação total.

Os seguintes serviços estão incluídos na coleção de regras de infraestrutura incorporada:

• Calcular o acesso ao Repositório de Imagens da Plataforma (PIR)
• Acesso ao armazenamento de estado dos discos geridos
• Azure Diagnostics and Logging (MDS)

Sobrepor a recolha de regras de infraestrutura

Pode sobrescrever esta coleção de regras de infraestrutura incorporada criando uma coleção de regras de negação de todas as aplicações que é processada por último. Será sempre processado antes da recolha das regras de infraestrutura. Tudo o que não está no conjunto de regras de infraestruturas é negado por defeito.

Conectividade de entrada

Regras DNAT e regras de rede

A conectividade de entrada com a Internet ou intranet pode ser habilitada configurando a Tradução de Endereço de Rede de Destino (DNAT), conforme descrito em Filtrar tráfego de entrada da Internet ou da intranet com o 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 autorizado 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 caracteres universais.

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

Regra de aplicação

• Ação: Negar

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 coleção de regras de rede de Negar de maior prioridade o bloqueia.

Coleção de regras de rede 1

• Designação: Allow-collection
• Prioridade: 200
• Ação: Permitir

Coleção de regras de rede 2

• Designação: 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 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 estado, o Azure Firewall conclui um handshake TCP de três vias para o tráfego permitido, da origem até o destino. Por exemplo, VNet-A para VNet-B.

Criar uma regra de permissão de VNet-A para VNet-B não significa que novas conexões iniciadas de VNet-B para 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.

Próximos passos

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