Filtrar Arbitragem

A arbitragem de filtros é a lógica incorporada na Plataforma de Filtragem do Windows (WFP) que é usada para determinar como os filtros interagem entre si ao tomar decisões de filtragem de tráfego de rede.

Filtrar comportamentos de arbitragem

Os seguintes comportamentos caracterizam o sistema de arbitragem de filtros:

• Todo o tráfego pode ser inspecionado. Nenhum tráfego pode ignorar filtros em uma determinada camada.
• O tráfego pode ser bloqueado por um filtro de texto explicativo por meio de um de Veto mesmo que um filtro de prioridade mais alta o permita.
• Vários provedores podem inspecionar o tráfego na mesma camada. Por exemplo, firewall seguido por filtros de sistema de deteção de intrusão (IDS) ou IPsec seguido por filtros de Qualidade de Serviço (QoS) podem examinar o tráfego na mesma camada.

Modelo de filtragem

Cada camada de filtro é dividida em subcamadas ordenadas por prioridade (também chamada de peso). O tráfego de rede atravessa as subcamadas da prioridade mais alta para a prioridade mais baixa. As subcamadas são criadas e gerenciadas pelos desenvolvedores usando a API do WFP.

Dentro de cada subcamada, os filtros são ordenados por peso. O tráfego de rede é indicado para combinar filtros do maior peso ao menor peso.

O algoritmo de arbitragem de filtro é aplicado a todas as subcamadas dentro de uma camada e a decisão final de filtragem é tomada depois que todas as subcamadas foram avaliadas. Isso fornece vários recursos de correspondência.

Dentro de uma subcamada, a arbitragem de filtro é executada da seguinte maneira:

• Calcule a lista de filtros correspondentes ordenados por peso, do mais alto para o mais baixo.
• Avalie os filtros correspondentes em ordem até que um "Permitir" ou um "Bloco" seja retornado (os filtros também podem retornar "Continuar") ou até que a lista se esgote.
• Ignore os filtros restantes e retorne a ação do último filtro avaliado.

Dentro de uma camada, a arbitragem de filtro é executada da seguinte maneira:

• Execute arbitragem de filtro em cada subcamada, na ordem da prioridade mais alta à prioridade mais baixa.
• Avalie todas as subcamadas, mesmo que uma subcamada de prioridade mais alta tenha decidido bloquear o tráfego.
• Retorne a ação resultante com base nas regras de política descritas na seção a seguir.

O diagrama abaixo ilustra um exemplo de configuração de subcamada. As caixas externas representam camadas. As caixas internas representam subcamadas que contêm filtros. O curinga (*) em um filtro significa que todo o tráfego corresponde ao filtro.

A única maneira de um filtro ser ignorado é se um filtro de maior peso tiver permitido ou bloqueado o tráfego dentro da mesma subcamada. Por outro lado, uma maneira de garantir que um filtro sempre veja todo o tráfego dentro de uma camada é adicionar uma subcamada que contenha um único filtro que corresponda a todo o tráfego.

Política de substituição configurável

As regras abaixo descritas regem as decisões arbitrais dentro de uma camada. Essas regras são usadas pelo mecanismo de filtro para decidir qual das ações da subcamada é aplicada ao tráfego de rede.

A política básica é a seguinte.

• As ações são avaliadas por ordem de prioridade das subcamadas, da prioridade mais alta à prioridade mais baixa.
• "Block" substitui "Permit".
• O "bloqueio" é final (não pode ser anulado) e interrompe a avaliação. O pacote é descartado.

A política básica não suporta o cenário de uma exceção não substituída por um firewall. Exemplos típicos deste tipo de cenário são:

• A porta de administração remota precisa ser aberta mesmo na presença de um firewall de terceiros.
• Componentes que requerem portas abertas para funcionar (por exemplo, Universal Plug and Play UPnP). Se o administrador tiver ativado explicitamente o componente, o firewall não deverá bloquear silenciosamente o tráfego.

Para dar suporte aos cenários acima, uma decisão de filtragem deve ser mais difícil de substituir do que outra decisão de filtragem gerenciando a permissão de substituição de ação. Essa permissão é implementada como o sinalizador FWPS_RIGHT_ACTION_WRITE e é definida por filtro.

O algoritmo de avaliação mantém a ação atual ("Permitir" ou "Bloquear") juntamente com a bandeira FWPS_RIGHT_ACTION_WRITE. O sinalizador controla se uma subcamada de prioridade mais baixa pode substituir a ação. Ao definir ou redefinir o sinalizador FWPS_RIGHT_ACTION_WRITE na estrutura FWPS_CLASSIFY_OUT0, um provedor controla como as ações podem ou não ser substituídas. Se o sinalizador estiver definido, isso indica que a ação pode ser substituída. Se o sinalizador estiver ausente, a ação não poderá ser anulada.

A ação de filtro pode ser definida definindo o tipo membro na estrutura FWPM_ACTION0 como FWP_ACTION_BLOCK ou FWP_ACTION_PERMIT. Junto com o tipo de ação, um filtro também expõe o sinalizador FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. Se este sinalizador for limpo, então o tipo de ação é difícil e não pode ser anulado, exceto quando uma permissão rígida é substituída por um Veto como explicado mais adiante, caso contrário, é suave que pode ser substituído por uma ação de alta prioridade.

A tabela a seguir lista o comportamento padrão para ações de filtro e texto explicativo.

Um de Veto é uma ação "Bloquear" retornada pelo filtro quando o sinalizador de FWPS_RIGHT_ACTION_WRITE foi redefinido antes de chamar o filtro. Um de veto bloqueará o tráfego que foi permitido com uma autorização rígida.

Quando um Veto é emitido, é um indício de conflito na configuração. As seguintes ações são tomadas para mitigar o conflito.

• O trânsito está bloqueado.

• Um evento de auditoria é gerado.

• Uma notificação é gerada.

  Observação

  A notificação é recebida por todas as entidades que a subscreveram. Isso normalmente incluirá o firewall (para detetar configurações incorretas) ou aplicativos (para detetar se seu filtro específico é substituído).

  Observação

  Não há nenhuma interface do usuário (UI) obrigatória instanciada quando um filtro "Hard Permit" é substituído. As notificações da substituição são enviadas para qualquer provedor que se registrou para recebê-las, o que permite que firewalls, ou os aplicativos que criaram os filtros "Permitir", mostrem a interface do usuário pedindo ação do usuário. Não há valor em ter uma notificação da interface do usuário da plataforma para esses eventos de substituição, uma vez que os ISVs de firewall que não desejam bloquear silenciosamente podem fazê-lo registrando-se em um local diferente no WFP ou (menos preferencialmente) lidar com toda a sua lógica em um driver de chamada. Os ISVs que acham que avisar os usuários é uma boa ideia vão querer possuir a experiência do usuário e criar sua própria interface do usuário.

O comportamento de mitigação descrito acima garante que um filtro "Hard Permit" não seja silenciosamente substituído por um filtro "Block" e cobre o cenário em que uma porta de administração remota não pode ser bloqueada pelo firewall. Para substituir silenciosamente os filtros "Hard Permit", um firewall tem que adicionar seus filtros dentro de uma subcamada de prioridade mais alta.

Os aplicativos de usuário que solicitam a abertura de portas adicionam filtros substituíveis a uma subcamada de baixa prioridade. O firewall pode se inscrever no filtro, adicionar eventos de notificação e adicionar um filtro correspondente após a validação do usuário (ou da política).

Tópicos relacionados

Atribuição de peso do filtro