Arbitrage des filtres
L’arbitrage des filtres est la logique intégrée à la plateforme de filtrage Windows (PAM) utilisée pour déterminer la façon dont les filtres interagissent entre eux lors de la prise de décisions de filtrage du trafic réseau.
Comportements d’arbitrage des filtres
Les comportements suivants caractérisent le système d’arbitrage de filtre :
- Tout le trafic peut être inspecté. Aucun trafic ne peut contourner les filtres à une couche donnée.
- Le trafic peut être bloqué par un filtre de légende via un Veto même si un filtre de priorité plus élevée l’a autorisé.
- Plusieurs fournisseurs peuvent inspecter le trafic à la même couche. Par exemple, le pare-feu suivi de filtres de système de détection d’intrusion (IDS) ou IPsec suivis de filtres QoS (Quality of Service) peut tous examiner le trafic au même niveau de couche.
Modèle de filtrage
Chaque couche de filtre est divisée en sous-couches classées par priorité (également appelée poids). Le trafic réseau traverse les sous-couches de la priorité la plus élevée vers la priorité la plus basse. Les sous-couches sont créées et gérées par les développeurs à l’aide de l’API PAM.
Dans chaque sous-couche, les filtres sont classés par poids. Le trafic réseau est indiqué pour les filtres correspondants du poids le plus élevé au poids le plus faible.
L’algorithme d’arbitrage de filtre est appliqué à toutes les sous-couches d’une couche et la décision finale de filtrage est prise après que toutes les sous-couches ont été évaluées. Cela fournit plusieurs fonctionnalités correspondantes.
Dans une sous-couche, l’arbitrage de filtre est effectué comme suit :
- Calculez la liste des filtres correspondants classés selon le poids le plus élevé au plus bas.
- Évaluez les filtres correspondants dans l’ordre jusqu’à ce qu’un « Permis » ou un « Bloc » soit retourné (les filtres peuvent également renvoyer « Continuer ») ou jusqu’à ce que la liste soit épuisée.
- Ignorez les filtres restants et retournez l’action à partir du dernier filtre évalué.
Dans une couche, l’arbitrage des filtres est effectué comme suit :
- Effectuez un arbitrage de filtre à chaque sous-couche afin de passer de la priorité la plus élevée à la priorité la plus basse.
- Évaluez toutes les sous-couches même si une sous-couche de priorité supérieure a décidé de bloquer le trafic.
- Retourne l’action résultante en fonction des règles de stratégie décrites dans la section suivante.
Le diagramme ci-dessous illustre un exemple de configuration de sous-couche. Les zones externes représentent des couches. Les zones internes représentent des sous-couches qui contiennent des filtres. Le caractère générique (*) dans un filtre signifie que tout le trafic correspond au filtre.
La seule façon pour un filtre d’être contourné est si un filtre de poids plus élevé a autorisé ou bloqué le trafic dans la même sous-couche. À l’inverse, une façon de s’assurer qu’un filtre voit toujours tout le trafic au sein d’une couche consiste à ajouter une sous-couche qui contient un seul filtre qui correspond à tout le trafic.
Stratégie de remplacement configurable
Les règles décrites ci-dessous régissent les décisions d’arbitrage au sein d’une couche. Ces règles sont utilisées par le moteur de filtre pour déterminer l’une des actions de sous-couche appliquées au trafic réseau.
La stratégie de base est la suivante.
- Les actions sont évaluées dans l’ordre de priorité des sous-couches, de la priorité la plus élevée à la priorité la plus basse.
- « Bloquer » remplace « Autoriser ».
- « Bloquer » est final (impossible de remplacer) et arrête l’évaluation. Le paquet est ignoré.
La stratégie de base ne prend pas en charge le scénario d’une exception non remplacée par un pare-feu. Voici des exemples typiques de ce type de scénario :
- Le port d’administration à distance doit être ouvert même en présence d’un pare-feu tiers.
- Composants qui nécessitent l’ouverture de ports pour fonctionner (par exemple, UPnP Universal Plug-and-Play). Si l’administrateur a explicitement activé le composant, le pare-feu ne doit pas bloquer le trafic en mode silencieux.
Pour prendre en charge les scénarios ci-dessus, une décision de filtrage doit être prise plus difficile à substituer qu’une autre décision de filtrage en gérant l’autorisation de remplacement d’action. Cette autorisation est implémentée en tant qu’indicateur de FWPS_RIGHT_ACTION_WRITE et défini sur une base de filtre.
L’algorithme d’évaluation gère l’action actuelle (« Autoriser » ou « Bloquer ») ainsi que l’indicateur de FWPS_RIGHT_ACTION_WRITE. L’indicateur contrôle si une sous-couche de priorité inférieure est autorisée à remplacer l’action. En définissant ou réinitialisant l’indicateur de FWPS_RIGHT_ACTION_WRITE dans la structure FWPS_CLASSIFY_OUT0, un fournisseur régit la façon dont les actions peuvent ou ne peuvent pas être substituées. Si l’indicateur est défini, il indique que l’action peut être remplacée. Si l’indicateur est absent, l’action ne peut pas être remplacée.
| Action | Autoriser la substitution (FWPS_RIGHT_ACTION_WRITE est définie) | Description |
|---|---|---|
| Permettre | Oui | Le trafic peut être bloqué à une autre sous-couche. C’est ce qu’on appelle un permis souple. |
| Permettre | Non | Le trafic peut être bloqué à un autre sous-couche uniquement par une légende Veto. C’est ce qu’on appelle un permis dur. |
| Bloquer | Oui | Le trafic peut être autorisé à une autre sous-couche. C’est ce qu’on appelle un bloc souple. |
| Bloquer | Non | Le trafic ne peut pas être autorisé à une autre sous-couche. C’est ce qu’on appelle un bloc dur. |
L’action de filtre peut être définie en définissant le type membre dans la structure FWPM_ACTION0 sur FWP_ACTION_BLOCK ou FWP_ACTION_PERMIT. En plus du type d’action, un filtre expose également l’indicateur FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. Si cet indicateur est effacé, le type d’action est dur et ne peut pas être remplacé, sauf lorsqu’un permis dur est substitué par un Veto comme expliqué plus loin, sinon il est souple qui peut être substitué par une action à priorité élevée.
Le tableau suivant répertorie le comportement par défaut pour les actions de filtre et de légende.
| Action | Comportement par défaut |
|---|---|
| Autorisation de filtre | Permis souple |
| Autorisation de légende | Permis souple |
| Bloc de filtre | Bloc dur |
| Bloc de légende | Bloc souple |
Une Veto est une action « Bloquer » retournée par le filtre lorsque l’indicateur de FWPS_RIGHT_ACTION_WRITE a été réinitialisé avant d’appeler le filtre. Un veto bloquera le trafic autorisé avec un permis dur.
Lorsqu’un de veto est émis, il s’agit d’une indication du conflit dans la configuration. Les actions suivantes sont prises pour atténuer le conflit.
Le trafic est bloqué.
Un événement d’audit est généré.
Une notification est générée.
Note
La notification est reçue par toutes les entités qui y sont abonnées. Cela inclut généralement le pare-feu (afin de détecter les configurations incorrectes) ou les applications (afin de détecter si leur filtre particulier est remplacé).
Note
Il n’existe aucune interface utilisateur obligatoire instanciée lorsqu’un filtre « Hard Permit » est remplacé. Les notifications du remplacement sont envoyées à tout fournisseur inscrit pour les recevoir, ce qui autorise les pare-feu ou les applications qui ont créé les filtres « Autoriser » pour afficher l’interface utilisateur demandant l’action de l’utilisateur. Il n’existe aucune valeur pour avoir une notification d’interface utilisateur de plateforme pour ces événements de remplacement, car les éditeurs de logiciels indépendants de pare-feu qui ne souhaitent pas bloquer silencieusement peuvent le faire en s’inscrivant à un autre emplacement dans le PAM, ou (moins préféré) gèrent toute leur logique dans un pilote de rappel. Les éditeurs de logiciels indépendants qui pensent que l’invite d’utilisateurs est une bonne idée de vouloir posséder l’expérience utilisateur et de créer leur propre interface utilisateur.
Le comportement d’atténuation décrit ci-dessus garantit qu’un filtre « Autorisation matérielle » n’est pas substitué en mode silencieux par un filtre « Bloquer » et couvre le scénario dans lequel un port d’administration distante n’est pas autorisé à être bloqué par le pare-feu. Pour remplacer silencieusement les filtres « Permis durs », un pare-feu doit ajouter ses filtres dans une sous-couche de priorité supérieure.
Note
Étant donné qu’il n’y a pas d’arbitrage intercouche, le trafic autorisé avec « Permis dur » peut toujours être bloqué à une autre couche. Il incombe à l’auteur de la stratégie de s’assurer que le trafic est autorisé à chaque couche si nécessaire.
Les applications utilisateur demandant l’ouverture de ports ajoutent des filtres substituables à une sous-couche basse priorité. Le pare-feu peut s’abonner au filtre ajouter des événements de notification et ajouter un filtre correspondant après la validation de l’utilisateur (ou de la stratégie).