Règles de firewall : les options avancées

Autoriser les options

Par défaut, le pare-feu bloque les paquets IPv4 avec options IP ou les paquets IPv6 avec des en-têtes d’extension de routage définis. Si vous avez une application qui nécessite de tels paquets (comme la multidiffusion / multicast ou IGMP), vous pouvez activer cette option.

Désactiver le “reply-to”

Le pare-feu ajoute par défaut le mot-clé “reply-to” aux règles sur les interfaces de type WAN pour garantir que le trafic qui entre par une interface WAN sortira par cette même interface.

Dans certains cas, ce comportement n’est pas souhaitable : par exemple lorsqu’une partie du trafic est acheminée par un pare-feu / routeur distinct sur l’interface WAN. Dans ce cas, cochez cette option pour désactiver la réponse pour le trafic correspondant à cette règle.

Définir la priorité

Le protocole 802.1p ou Priority Code Point, est un moyen de faire correspondre et de marquer les paquets avec une priorité de qualité de service spécifique. Le 802.1p fonctionne au niveau de la couche 2 avec les VLAN, c’est une composante des entêtes des trames 802.1Q.

Pour être utile, le routeur en amont doit lui aussi supporter le 802.1p. Les valeurs sont classées par ordre de priorité :

• 1 (Arrière-plan (le plus bas)),

• 0 (Meilleur effort (par défaut)),

• 2 Excellent effort),

• 3 (Applications critiques),

• 4 (Vidéo, latence < 100ms),

• 5 (Vidéo, latence < 10ms),

• 6 (Contrôle de l’Internet),

• 7 (Contrôle du réseau (le plus élevé)).

Les paquets correspondant à cette règle se verront attribuer par les routeurs en amont un traitement spécifique fonction du marquage qu’ils auront reçus.

Si les paquets sont transmis sur une interface de type VLAN, la priorité de mise en file d’attente sera écrite en tant qu’entête 802.1p dans les trames VLAN 802.1Q.

Il est possible de définir la priorité pour l’ensemble des paquets ou pour les paquets de confirmation (acknowledgement) de façon distincte.

Correspondance de priorité

Permet d’appliquer la règle de firewall créée aux seuls paquets disposant du tag 802.1p sélectionné.

Définir une balise locale

Permet de définir une balise spécifique et restreinte au firewall pour un traitement ultérieur des paquets correspondant. Les balises locales sont conservées, même si la règle n’est pas la dernière règle de correspondance. D’autres règles de correspondance permettront de remplacer ce tag.

Une paquet ne peut recevoir qu’un seul et unique tag.

Correspondance de la balise locale

C’est la réciproque du champ précédent qui permet de définir une règle qui récupérera les paquets répondant à la balise spécifiée.

Limite de connexion

Nous pouvons ici créer des règles spécifiques qui permettront de limiter le nombre de connexion.

Nombre maximum d’états

Limite le nombre d’états concurrents que la règle peut créer. Lorsque cette limite est atteinte, les paquets supplémentaires continuent à être traités par les autres règles du jeu de règles de l’interface. Si une nouvelle correspondance est obtenue, le paquet subira le traitement de cette autre règle. Sans correspondance, le paquet atteint la règle de refus par défaut.

Une fois que le trafic retombe en dessous de la limite fixée, la règle est de nouveau appliquée.

Nombre maximum d’hôtes sources uniques

Cette option précise le nombre total d’adresses IP sources pouvant être connectées simultanément pour cette règle.

Chaque adresse IP source est autorisée à un nombre illimité de connexions, mais le nombre total d’adresses IP sources distinctes autorisées est limité à cette valeur.

Nombre maximal d’état de connexion établis

Utilisez ce paramètre pour limiter l’accès en fonction des connexions par hôte.

Cette valeur peut limiter votre règle à un nombre spécifique de connexions par hôte source.

Cette option contrôle le nombre de connexions établies (handshake complet) autorisées par hôte qui correspondent à la règle. Cette option n’est disponible que pour les connexions TCP.

Nombre maximale d’état de connexion conservé

Ce paramètre fonctionne de la même manière que le décompte établi ci-dessus, mais il vérifie uniquement les entrées d’état plutôt que de suivre si une connexion a été établie avec succès.

Nombre Maximum de nouvelles connexions

Permet de limiter le nombre de nouvelles connexions sur un intervalle de temps donné. Le taux de connexion est une approximation calculée comme une moyenne mobile. (nombre de connexions / secondes).

Ce paramètre s’applique uniquement aux connexions TCP

Dépassement du temps pour l’État

Durée maximale d’établissement d’une connexion TCP.

Drapeaux TCP

Permet d’appliquer une règle en fonction de drapeau(x) TCP spécifiques définis ici.

Type d’état / Pas de pfsync

Permet d’éviter que les états généré par ce firewall ne soient synchronisés avec pfsync (dans le cas d’un Cluster).

Type d’état

Ce paramètre important permet de jouer sur les mécanismes d’identification des états créés au sein du firewall DynFi. Il existe quatre paramètres qui sont détaillés ci-dessous :

1. Keep state : lorsqu’il est choisi, le pare-feu crée et maintient une entrée de table d’état pour le trafic autorisé. C’est la valeur par défaut, et le meilleur choix dans la plupart des situations.

2. Sloppy state : défini un moyen moins strict de maintenir l’état qui est destiné aux scénarios avec un routage asymétrique. Lorsque le pare-feu ne peut voir que la moitié du trafic d’une connexion, les contrôles de validité du maintien de l’état par défaut échouent et le trafic est bloqué. Les mécanismes de protection contre certains types d’attaques n’interviendront pas lors d’un contrôle d’état de type ‘Sloppy’.

3. Synproxy state : Ce réglage permet de se prémunir d’attaques par déni de service de type ‘inondation SYN’ (SYN flood). Les connexions TCP sont ainsi proxyfiées, DynFi Firewall assurant le rôle d’intermédiaire dans les étapes de handshake initiales. On ne défini ce type d’état que sur des interfaces de type WAN (exposées sur Internet). L’utilisation de ce mécanisme entraine des baisses importantes de performances. Les attaques par de type ‘SYN flood’ sont aujourd’hui mieux gérées par les OS standards modernes. Tout de même utile pour protéger des systèmes plus anciens ou la performance n’est pas une donnée critique.

4. Aucun : A éviter, paramètre qui supprime toute gestion d’état

Note

Le réglage Aucun ici n’affecte que le trafic dans le sens entrant, il n’est donc pas très utile en soi puisqu’un état sera tout de même créé dans le sens sortant. Il doit être associé à une règle flottante dans le sens sortant, qui a également la même option que celle choisie.