Arbitrage des filtres
L’arbitrage de filtre est la logique intégrée à la plateforme de filtrage Windows (PAM) qui est utilisée pour déterminer comment 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 au niveau d’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 au niveau de la même couche. Par exemple, le pare-feu suivi de filtres de système de détection d’intrusion (IDS) ou IPsec suivi de filtres de qualité de service (QoS) peuvent tous examiner le trafic au niveau de la même couche.
Modèle de filtrage
Chaque couche de filtre est divisée en sous-couches classées par priorité (également appelée pondération). Le trafic réseau traverse les sous-couches de la priorité la plus élevée à 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 une fois que toutes les sous-couches ont été évaluées. Cela permet d’obtenir plusieurs fonctionnalités de correspondance.
Dans une sous-couche, l’arbitrage de filtre s’effectue comme suit :
- Calculez la liste des filtres correspondants classés par poids, du plus élevé au plus faible.
- Évaluez les filtres correspondants dans l’ordre jusqu’à ce qu’un « Autoriser » 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 du dernier filtre évalué.
Au sein d’une couche, l’arbitrage de filtre est effectué comme suit :
- Effectuez l’arbitrage des filtres à chaque sous-couche dans l’ordre de priorité la plus élevée à la priorité la plus faible.
- Évaluez toutes les sous-couches même si une sous-couche de priorité plus élevée 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 de contourner un filtre est si un filtre de poids plus élevé a autorisé ou bloqué le trafic au sein de 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 filtre unique qui correspond à l’ensemble du 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écider quelles actions de sous-couche est appliquée 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 faible.
- « Bloquer » remplace « Permit ».
- « Bloquer » est final (ne peut pas être remplacé) 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, Universal Plug-and-Play UPnP). Si l’administrateur a explicitement activé le composant, le pare-feu ne doit pas bloquer silencieusement le trafic.
Pour prendre en charge les scénarios ci-dessus, une décision de filtrage doit être rendue 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 FWPS_RIGHT_ACTION_WRITE et est définie par filtre.
L’algorithme d’évaluation conserve l’action actuelle (« Autoriser » ou « Bloquer ») ainsi que l’indicateur 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 en réinitialisant l’indicateur FWPS_RIGHT_ACTION_WRITE dans la structure FWPS_CLASSIFY_OUT0 , un fournisseur détermine comment les actions peuvent ou ne peuvent pas être remplacées. Si l’indicateur est défini, cela indique que l’action peut être remplacée. Si l’indicateur est absent, l’action ne peut pas être remplacée.
| Action | Autoriser le remplacement (FWPS_RIGHT_ACTION_WRITE est défini) | Description |
|---|---|---|
| Permit | Oui | Le trafic peut être bloqué au niveau d’une autre sous-couche. C’est ce qu’on appelle un permis souple. |
| Permit | Non | Le trafic peut être bloqué au niveau d’une 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é au niveau d’une autre sous-couche. C’est ce qu’on appelle un bloc souple. |
| Bloquer | Non | Le trafic ne peut pas être autorisé au niveau d’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 membre de type 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’une autorisation matérielle est remplacée par un veto comme expliqué plus loin, sinon, il est souple qui peut être remplacé par une action de 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 | Autorisation réversible |
| Autorisation de légende | Autorisation réversible |
| Bloc de filtre | Bloc dur |
| Bloc de légende | Bloc souple |
Un veto est une action « Bloquer » retournée par le filtre lorsque l’indicateur FWPS_RIGHT_ACTION_WRITE a été réinitialisé avant l’appel du filtre. Un droit de veto bloquera le trafic autorisé avec un permis dur.
Lorsqu’un veto est émis, il s’agit d’une indication de 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.
Notes
La notification est reçue par toutes les entités qui s’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é).
Notes
L’interface utilisateur (IU) obligatoire n’est pas instanciée lorsqu’un filtre « Autorisation matérielle » est remplacé. Les notifications du remplacement sont envoyées à n’importe quel fournisseur qui s’est inscrit pour les recevoir, ce qui permet aux pare-feu ou aux applications qui ont créé les filtres « Autoriser », d’afficher l’interface utilisateur demandant une action de l’utilisateur. Il n’y a aucune valeur à 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 en mode silencieux peuvent le faire en s’inscrivant à un autre emplacement dans PAM, ou (moins préféré) gérer toute leur logique dans un pilote d’appel. Les éditeurs de logiciels indépendants qui pensent qu’inviter les utilisateurs est une bonne idée veulent posséder l’expérience utilisateur et 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 remplacé en mode silencieux par un filtre « Bloquer » et couvre le scénario où un port d’administration à distance n’est pas autorisé à être bloqué par le pare-feu. Pour remplacer silencieusement les filtres « Hard Permit », un pare-feu doit ajouter ses filtres au sein d’une sous-couche de priorité supérieure.
Notes
Étant donné qu’il n’y a pas d’arbitrage intercouche, le trafic autorisé avec le « permis en 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 de faible 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).