Filtrar Arbitragem
A arbitragem de filtro é a lógica incorporada à Plataforma de Filtragem do Windows (WFP) 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 filtro:
- 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 Veto , mesmo que um filtro de prioridade mais alta o tenha permitido.
- Vários provedores podem inspecionar o tráfego na mesma camada. Por exemplo, o firewall seguido por filtros IDS (sistema de detecção de intrusão) ou IPsec seguido por filtros QoS (Qualidade de Serviço) pode 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 subcaminhos da prioridade mais alta para a prioridade mais baixa. As subcaminhos 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 a correspondência de filtros de maior peso para 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 são avaliadas. Isso fornece vários recursos de correspondência.
Em uma subcamada, a arbitragem de filtro é executada da seguinte maneira:
- Compute a lista de filtros correspondentes ordenados por peso do mais alto para o mais baixo.
- Avalie os filtros correspondentes na ordem até que uma "Permissão" ou um "Bloco" seja retornado (os filtros também podem retornar "Continuar") ou até que a lista esteja esgotada.
- Ignore os filtros restantes e retorne a ação do último filtro avaliado.
Em uma camada, a arbitragem de filtro é executada da seguinte maneira:
- Execute a arbitragem de filtro em cada subcaminho em ordem da prioridade mais alta para a prioridade mais baixa.
- Avalie todas as subcaminhos mesmo que uma subcaminha 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 a seguir ilustra uma configuração de subcaminho de exemplo. As caixas externas representam camadas. As caixas internas representam subcaminhos 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 peso mais alto 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 subcaminho que contenha um único filtro que corresponda a todo o tráfego.
Política de Substituição Configurável
As regras descritas abaixo regem as decisões de arbitragem dentro de uma camada. Essas regras são usadas pelo mecanismo de filtro para decidir qual das ações de subcamadas é aplicada ao tráfego de rede.
A política básica é a seguinte.
- As ações são avaliadas em ordem prioritária de subcamadas da prioridade mais alta para a prioridade mais baixa.
- "Bloquear" substitui "Permitir".
- "Block" é final (não pode ser substituído) e interrompe a avaliação. O pacote é descartado.
A política básica não dá suporte ao cenário de uma exceção não substituída por um firewall. Exemplos típicos desse tipo de cenário são:
- A porta de administração remota deve ser aberta mesmo na presença de um firewall de terceiros.
- Componentes que exigem que as portas sejam abertas para funcionar (por exemplo, UPnP de Plug and Play Universal). Se o administrador habilitou explicitamente o componente, o firewall não deve 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 da 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 o sinalizador FWPS_RIGHT_ACTION_WRITE . O sinalizador controla se uma subcaminho de prioridade mais baixa tem permissão para substituir a ação. Ao definir ou redefinir o sinalizador de 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, ele indicará que a ação pode ser substituída. Se o sinalizador estiver ausente, a ação não poderá ser substituída.
| Ação | Permitir substituição (FWPS_RIGHT_ACTION_WRITE está definido) | Descrição |
|---|---|---|
| Permitir | Sim | O tráfego pode ser bloqueado em outra subcamada. Isso é chamado de permissão temporária. |
| Permitir | Não | O tráfego pode ser bloqueado em outra subcamada somente por um veto explicativo. Isso é chamado de permissão dura. |
| Bloquear | Sim | O tráfego pode ser permitido em outra subcamada. Isso é chamado de bloco flexível. |
| Bloquear | Não | O tráfego não pode ser permitido em outra subcamada. Isso é chamado de bloco rígido. |
A ação de filtro pode ser definida definindo o membro do tipo 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 esse sinalizador for limpo, o tipo de ação será rígido e não poderá ser substituído, exceto quando uma permissão rígida for substituída por um Veto , conforme explicado posteriormente, caso contrário, será flexível, o que pode ser substituído por ação de alta prioridade.
A tabela a seguir lista o comportamento padrão para ações de filtro e texto explicativo.
| Ação | Comportamento padrão |
|---|---|
| Permissão de filtro | Permissão temporária |
| Permissão de texto explicativo | Permissão temporária |
| Bloco de filtro | Bloco rígido |
| Bloco de texto explicativo | Bloco flexível |
Um Veto é uma ação "Bloquear" retornada pelo filtro quando o sinalizador FWPS_RIGHT_ACTION_WRITE foi redefinido antes de chamar o filtro. Um veto bloqueará o tráfego que foi permitido com uma licença rígida.
Quando um Veto é emitido, é uma indicação de conflito na configuração. As ações a seguir são tomadas para atenuar o conflito.
O tráfego está bloqueado.
Um evento de auditoria é gerado.
Uma notificação é gerada.
Observação
A notificação é recebida por todas as entidades que a assinaram. Isso normalmente incluirá o firewall (para detectar configurações incorretas) ou aplicativos (para detectar se o filtro específico é substituído).
Observação
Não há uma interface do usuário (interface do usuário) obrigatória instanciada quando um filtro "Hard Permit" é substituído. As notificações da substituição são enviadas a qualquer provedor registrado para recebê-las, o que permite que os firewalls ou os aplicativos que criaram os filtros "Permitir", mostrem a interface do usuário solicitando a ação do usuário. Não há valor em ter uma notificação de interface do usuário de plataforma para esses eventos de substituição, pois os ISVs de firewall que não desejam bloquear silenciosamente podem fazer isso registrando-se em um local diferente no WFP ou (menos preferenciais) lidar com toda a lógica em um driver de chamada. Os ISVs que acham que solicitar aos usuários é uma boa ideia desejarão 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 substituído silenciosamente por um filtro "Bloquear" e abrange o cenário em que uma porta de administração remota não tem permissão para ser bloqueada pelo firewall. Para substituir silenciosamente os filtros "Hard Permit", um firewall precisa adicionar seus filtros em uma subcamada de prioridade mais alta.
Observação
Como não há arbitragem entre camadas, o tráfego permitido com "Hard Permit" ainda pode ser bloqueado em outra camada. É responsabilidade do autor da política garantir que o tráfego seja permitido em cada camada, se necessário.
Os aplicativos de usuário que solicitam que as portas sejam abertas adicionam filtros substituíveis a uma subcamada de baixa prioridade. O firewall pode assinar o filtro adicionar eventos de notificação e adicionar um filtro correspondente após a validação do usuário (ou da política).