Filtrado de arbitraje
El arbitraje de filtros es la lógica integrada en la Plataforma de filtrado de Windows (PMA) que se usa para determinar cómo interactúan los filtros entre sí al tomar decisiones de filtrado del tráfico de red.
Filtrar comportamientos de arbitraje
Los comportamientos siguientes caracterizan el sistema de arbitraje de filtro:
- Todo el tráfico se puede inspeccionar. Ningún tráfico puede omitir los filtros en una capa determinada.
- El tráfico se puede bloquear mediante un filtro de llamada a través de un Vet incluso si un filtro de prioridad más alta lo ha permitido.
- Varios proveedores pueden inspeccionar el tráfico en la misma capa. Por ejemplo, el firewall seguido de filtros del sistema de detección de intrusiones (IDS) o IPsec seguido de filtros de calidad de servicio (QoS) puede examinar todo el tráfico en la misma capa.
Modelo de filtrado
Cada capa de filtro se divide en subcapas ordenadas por prioridad (también denominada peso). El tráfico de red atraviesa subcapas de la prioridad más alta a la prioridad más baja. Los desarrolladores crean y administran subcapas mediante la API DE PMA.
Dentro de cada subcapa, los filtros se ordenan por peso. El tráfico de red se indica a los filtros coincidentes del peso más alto al peso más bajo.
El algoritmo de arbitraje de filtro se aplica a todas las subcapas de una capa y se toma la decisión final de filtrado después de que se hayan evaluado todas las subcapas. Esto proporciona varias funcionalidades coincidentes.
Dentro de una subcapa, el arbitraje de filtro se realiza de la siguiente manera:
- Calcule la lista de filtros coincidentes ordenados por peso de mayor a menor.
- Evalúe los filtros coincidentes en orden hasta que se devuelva un "Permiso" o un "Bloque" (los filtros también pueden devolver "Continuar") o hasta que se agote la lista.
- Omita los filtros restantes y devuelva la acción del último filtro evaluado.
Dentro de una capa, el arbitraje de filtro se realiza de la siguiente manera:
- Realice el arbitraje de filtro en cada subcapa en orden de la prioridad más alta a la prioridad más baja.
- Evalúe todas las subcapas incluso si una subcapa de prioridad más alta ha decidido bloquear el tráfico.
- Devuelve la acción resultante en función de las reglas de directiva descritas en la sección siguiente.
En el diagrama siguiente se muestra una configuración de subcapa de ejemplo. Los cuadros externos representan capas. Los cuadros internos representan subcapas que contienen filtros. El carácter comodín (*) de un filtro significa que todo el tráfico coincide con el filtro.
La única manera de omitir un filtro es si un filtro de mayor peso ha permitido o bloqueado el tráfico dentro de la misma subcapa. Por el contrario, una forma de asegurarse de que un filtro siempre ve todo el tráfico dentro de una capa es agregar una subcapa que contenga un único filtro que coincida con todo el tráfico.
Directiva de invalidación configurable
Las reglas descritas a continuación rigen las decisiones de arbitraje dentro de una capa. El motor de filtros usa estas reglas para decidir cuál de las acciones de subcapa se aplica al tráfico de red.
La directiva básica es la siguiente.
- Las acciones se evalúan en orden de prioridad de subcapas de mayor prioridad a prioridad más baja.
- "Bloquear" invalida "Permitir".
- "Bloquear" es final (no se puede invalidar) y detiene la evaluación. El paquete se descarta.
La directiva básica no admite el escenario de una excepción no invalidada por un firewall. Los ejemplos típicos de este tipo de escenario son:
- El puerto de administración remota debe abrirse incluso en presencia de un firewall de terceros.
- Componentes que requieren que se abran puertos para funcionar (por ejemplo, Universal Plug and Play UPnP). Si el administrador ha habilitado explícitamente el componente, el firewall no debe bloquear el tráfico de forma silenciosa.
Para admitir los escenarios anteriores, una decisión de filtrado debe ser más difícil de invalidar que otra decisión de filtrado mediante la administración del permiso de invalidación de acción. Este permiso se implementa como la marca FWPS_RIGHT_ACTION_WRITE y se establece por filtro.
El algoritmo de evaluación mantiene la acción actual ("Permitir" o "Bloquear") junto con la marca FWPS_RIGHT_ACTION_WRITE . La marca controla si se permite que una subcapa de prioridad inferior invalide la acción. Al establecer o restablecer la marca FWPS_RIGHT_ACTION_WRITE en la estructura de FWPS_CLASSIFY_OUT0 , un proveedor rige cómo se pueden o no invalidar las acciones. Si se establece la marca, indica que la acción se puede invalidar. Si la marca no está presente, la acción no se puede invalidar.
| Acción | Permitir invalidación (se ha establecido FWPS_RIGHT_ACTION_WRITE) | Descripción |
|---|---|---|
| Permitir | Sí | El tráfico se puede bloquear en otra subcapa. Esto se denomina permiso suave. |
| Permitir | No | El tráfico solo se puede bloquear en otra subcapa mediante una llamada a Vet. Esto se denomina permiso duro. |
| Bloquear | Sí | El tráfico se puede permitir en otra subcapa. Esto se denomina bloque flexible. |
| Bloquear | No | No se puede permitir el tráfico en otra subcapa. Esto se denomina bloque duro. |
La acción de filtro se puede establecer estableciendo el miembro de tipo en la estructura FWPM_ACTION0en FWP_ACTION_BLOCK o FWP_ACTION_PERMIT. Junto con el tipo de acción, un filtro también expone la marca FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. Si esta marca está desactivada, el tipo de acción es duro y no se puede invalidar, excepto cuando un permiso duro se invalida mediante un Vet como se explica más adelante, sino que es suave, lo que se puede invalidar mediante una acción de prioridad alta.
En la tabla siguiente se muestra el comportamiento predeterminado para las acciones de filtro y llamada.
| Acción | Comportamiento predeterminado |
|---|---|
| Permiso de filtro | Permiso suave |
| Permiso de globo | Permiso suave |
| Bloque de filtro | Bloque duro |
| Bloque de llamada | Bloque flexible |
Un Vet es una acción "Bloquear" devuelta por el filtro cuando se restableció la marca FWPS_RIGHT_ACTION_WRITE antes de llamar al filtro. Un Vet bloqueará el tráfico permitido con un permiso estricto.
Cuando se emite un Vet , es una indicación de conflicto en la configuración. Se realizan las siguientes acciones para mitigar el conflicto.
El tráfico está bloqueado.
Se genera un evento de auditoría.
Se genera una notificación.
Nota
Todas las entidades que se han suscrito a ella reciben la notificación. Normalmente, esto incluirá el firewall (para detectar configuraciones incorrectas) o las aplicaciones (para detectar si se invalida su filtro concreto).
Nota
No se crea ninguna instancia de la interfaz de usuario (UI) obligatoria cuando se invalida un filtro "Permiso estricto". Las notificaciones de la invalidación se envían a cualquier proveedor registrado para recibirlas, lo que permite que los firewalls, o las aplicaciones que crearon los filtros "Permitir", muestren la interfaz de usuario que solicita la acción del usuario. No hay ningún valor en tener una notificación de interfaz de usuario de la plataforma para estos eventos de invalidación, ya que los ISV de firewall que no quieren bloquear de forma silenciosa pueden hacerlo mediante el registro en un lugar diferente en EL PMA o (menos preferido) controlan toda su lógica en un controlador de llamada. Los ISV que creen que preguntar a los usuarios es una buena idea que quiera poseer la experiencia del usuario y crear su propia interfaz de usuario.
El comportamiento de mitigación descrito anteriormente garantiza que un filtro "Permiso estricto" no se invalide silenciosamente mediante un filtro "Bloquear" y cubre el escenario en el que el firewall no puede bloquear un puerto de administración remota. Para invalidar silenciosamente los filtros "Permiso estricto", un firewall tiene que agregar sus filtros dentro de una subcapa de prioridad más alta.
Nota
Dado que no hay ningún arbitraje entre capas, el tráfico permitido con "Permiso estricto" puede seguir bloqueado en otra capa. Es responsabilidad del autor de la directiva asegurarse de que el tráfico se permite en cada capa si es necesario.
Las aplicaciones de usuario que solicitan que los puertos se abran agreguen filtros reemplazables a una subcapa de prioridad baja. El firewall puede suscribirse al filtro agregar eventos de notificación y agregar un filtro coincidente después de la validación del usuario (o directiva).