Compartilhar via


Filtrar registo de auditoria de origem

Ao investigar eventos de remoção de pacotes, pode utilizar o campo Filter Run-Time ID a partir de auditorias 5157 da Plataforma de Filtragem do Windows (WFP) ou 5152.

Propriedades do evento.

O ID do filtro identifica exclusivamente o filtro que causou a remoção do pacote. O ID do filtro pode ser pesquisado na saída de informação de falha de sistema do estado do WFP para rastrear a regra de Firewall de onde o filtro teve origem. No entanto, o ID do filtro não é uma origem fiável para rastrear o filtro ou a regra, uma vez que o ID do filtro pode ser alterado por vários motivos, apesar de a regra não ter sido alterada. A alteração no ID torna o processo de diagnóstico propenso a erros e difícil.

Para depurar eventos de remoção de pacotes de forma correta e eficiente, precisa de mais contexto sobre o filtro de bloqueio, como a sua origem. Os filtros de bloqueio podem ser categorizados nas seguintes origens de filtro:

  1. Regras de firewall
  2. Filtros de bloqueio predefinidos da firewall
    1. Loopback do AppContainer
    2. Predefinição do tempo de arranque
    3. Predefinição de quarentena
    4. Predefinição do utilizador da consulta
    5. Furtivo
    6. Plataforma Universal do Windows (UWP) predefinido
    7. Proteção do Serviço Windows (WSH) predefinida

A secção seguinte descreve as melhorias efetuadas às auditorias 5157 e 5152 no Windows 11 e Windows Server 2022 e como as origens de filtro são utilizadas nestes eventos.

Auditoria de firewall melhorada

A partir de Windows 11 e Windows Server 2022, dois novos campos adicionados à auditoria 5157 e 5152 eventos são Filter Origin e Interface Index:

  • O campo Origem do Filtro ajuda a identificar a causa da queda. As remoção de pacotes da firewall são explicitamente removidas pelos filtros de bloco predefinidos criados pelo serviço Firewall do Windows ou por uma regra de firewall que pode ser criada por utilizadores, políticas, serviços, aplicações, etc. Filtrar Origem especifica o ID da regra (um identificador exclusivo de uma regra de Firewall) ou o nome de um dos filtros de bloco predefinidos
  • O campo Índice de Interface especifica a interface de rede na qual o pacote foi removido. Este campo ajuda a identificar que interface foi colocada em quarentena, se a Origem do Filtro for uma Predefinição de Quarentena

Para ativar um evento de auditoria específico, execute o comando correspondente numa linha de comandos de administrador:

Auditoria # Comando Ativar Link
5157 Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable 5157(F): A Plataforma de Filtragem do Windows bloqueou uma ligação.
5152 Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable 5152(F): a Plataforma de Filtragem do Windows bloqueou um pacote.

Fluxo de exemplo de remoção de pacotes de depuração com origem do filtro

À medida que a auditoria apresenta o Filter Origin and Interface Index, o administrador de rede pode determinar a causa da remoção do pacote de rede e a interface em que ocorreu.

Auditoria de eventos.

As secções seguintes são divididas pelo tipo Origem do Filtro , o valor é um nome de regra ou o nome de um dos filtros de bloco predefinidos. Se a origem do filtro for um dos filtros de bloco predefinidos, avance para a secção Filtros de bloqueio predefinidos da firewall.

Regras de firewall

Execute o seguinte comando do PowerShell para gerar as informações da regra com Filter Origin.

Get-NetFirewallRule -Name "<Filter Origin>"
Get-NetFirewallRule -Name " {A549B7CF-0542-4B67-93F9-EEBCDD584377} "

Regra de firewall.

Depois de identificar a regra que causou a remoção, o administrador de rede pode modificar ou desativar a regra para permitir o tráfego pretendido através de uma das ferramentas disponíveis. O administrador de rede pode encontrar a regra na IU com o DisplayName da regra.

Observação

As regras de firewall do arquivo de Gerenciamento de Dispositivos Móvel (MDM) não podem ser pesquisadas com a IU da Firewall do Windows. Além disso, o método acima não funciona quando a Origem do Filtro é um dos filtros de bloco predefinidos, uma vez que não correspondem a nenhuma regra de firewall.

Filtros de bloqueio predefinidos da firewall

Loopback do AppContainer

Os eventos de remoção de rede da origem do filtro de bloqueio de loopback AppContainer ocorrem quando o loopback localhost não está ativado corretamente para a aplicação Plataforma Universal do Windows (UWP):

Predefinição do tempo de arranque

Os eventos de remoção de rede da origem do filtro de bloqueio predefinido do tempo de arranque ocorrem quando o computador está a arrancar e o serviço de firewall ainda não está em execução. Os serviços precisam de criar um filtro de tempo de arranque para permitir o tráfego. Tenha em atenção que não é possível adicionar filtros de tempo de arranque através de regras de firewall.

Predefinição de quarentena

As falhas de rede do filtro de bloco predefinido de quarentena ocorrem quando a interface é temporariamente colocada em quarentena pelo serviço firewall. O serviço de firewall coloca uma interface em quarentena quando deteta uma alteração na rede e, com base em vários outros fatores, o serviço de firewall pode colocar a interface em quarentena como uma salvaguarda. Quando uma interface está em quarentena, o filtro de bloco predefinido de quarentena bloqueia quaisquer novas ligações de entrada não loopback.

Execute o seguinte comando do PowerShell para gerar mais informações sobre a interface:

Get-NetIPInterface -InterfaceIndex <Interface Index>

Para saber mais sobre a funcionalidade de quarentena, veja Comportamento da quarentena.

Observação

Muitas vezes, as remoção de pacotes relacionadas com a quarentena são transitórias e não significam nada mais do que uma alteração de rede na interface.

Predefinição do utilizador da consulta

Os pacotes de rede removidos dos filtros de bloqueio predefinidos do utilizador da consulta ocorrem quando não existe nenhuma regra explícita criada para permitir uma ligação de entrada para o pacote. Quando uma aplicação se vincula a um socket, mas não tem uma regra de entrada correspondente para permitir pacotes nessa porta, o Windows gera um pop-up para o utilizador permitir ou negar que a aplicação receba pacotes nas categorias de rede disponíveis. Se o utilizador optar por negar a ligação no pop-up, os pacotes de entrada subsequentes para a aplicação serão removidos. Para resolve as gotas:

  1. Crie uma regra de firewall de entrada para permitir o pacote para esta aplicação. A regra permite que o pacote ignore todos os filtros de bloqueio predefinidos do utilizador da consulta
  2. Eliminar quaisquer regras de utilizador de consulta de blocos que possam ter sido geradas automaticamente pelo serviço de firewall

Para gerar uma lista de todas as regras de bloqueio do utilizador da consulta, pode executar o seguinte comando do PowerShell:

Get-NetFirewallRule | Where {$_.Name -like "*Query User*"}

A funcionalidade de pop-up de utilizador de consulta está ativada por predefinição. Para desativar o pop-up do utilizador da consulta, pode executar o seguinte comando na linha de comandos administrativa:

Netsh set allprofiles inboundusernotification disable

Ou no PowerShell:

Set-NetFirewallProfile -NotifyOnListen False

Furtivo

Normalmente, as falhas de rede dos filtros furtivos são efetuadas para impedir a análise de portas.

Para desativar o modo furtivo, consulte Desativar o modo furtivo no Windows.

Predefinição do UWP

As falhas de rede dos filtros de blocos de entrada/saída predefinidos do Plataforma Universal do Windows (UWP) são frequentemente causadas pela aplicação UWP não estar a ser configurada corretamente (ou seja, a aplicação UWP não tem os tokens de capacidade corretos ou o loopback não está ativado) ou o intervalo privado está configurado incorretamente.

Para obter mais informações sobre como depurar as falhas causadas pelos filtros de bloco predefinidos do UWP, veja Resolver Problemas de Conectividade da Aplicação UWP.

Predefinição WSH

As falhas de rede dos filtros predefinidos do Windows Service Hardening (WSH) indicam que não havia uma regra de proteção explícita do Serviço Windows para permitir o tráfego de rede para o serviço protegido. O proprietário do serviço tem de configurar as regras de permissão para o serviço, se o bloco não for esperado.