Déploiement des règles de firewall avec DynFi Firewall

Dans la section précédente : Préparation au déploiement de règles de firewall sur DynFi Firewall, nous avons introduit une proposition de méthodologie visant à déployer vos règles de firewall efficacement.

Le filtrage pare-feu dans DynFi Firewall s’appuie sur l’implémentation FreeBSD du logiciel ‘packet filter’ ou ‘pf’[1] disponible en ligne de commande depuis DynFi Firewall. Il est toujours intéressant d’approfondir le sujet en comprenant comment ce type de firewall fonctionne.

Note

Le livre “packet filter” de Peter N. M. Hansteen est une excellente référence pour approfondir le sujet. Il est disponible en Français ou en Anglais (édition plus à jour).

Comment les règles sont-elles appliquées ?

La configuration des règles de firewall est un élément essentiel de la configuration de tout firewall. Une bonne configuration permet de bien structurer les communications au sein de votre réseau. Ce n’est pas une condition suffisante, mais nécessaire au fonctionnement harmonieux de vos réseaux et à leur contrôle.

Application des règles au sein du firewall

Votre firewall DynFi applique les règles dans un ordre bien déterminé :

1. les règles définies au niveau du ‘Système’

2. les règles ‘Flottantes’

3. les règles au niveau des ‘Groupes d’interfaces’

4. les règles au niveau des ‘Interfaces’

Le schéma ci-dessous illustre cela de façon claire

Application des règles au sein des interfaces

Dans un premier temps nous vous proposons un schéma (assez basique) qui précise le contexte de la configuration des règles. Il s’agit ici de sécuriser les flux circulant sur votre LAN.

Les règles traitent le traffic qui est généré depuis l’interface sur laquelle la règle est appliquée (ce point est essentiel à comprendre). Ainsi si vous souhaitez contrôler les flux de vos utilisateurs sur le LAN à destination des autres réseaux (WAN, OPT, …), vous devrez créer une règle sur le LAN. De la même façon si vous souhaitez éviter ou autoriser les accès depuis le WAN vers un réseau interne (une DMZ par exemple), vous devrez filtrer ce flux depuis l’interface WAN.

Les règles sont créées au niveau des interfaces de votre firewall, que celles-ci soient des interfaces physiques (type em0, igb0, ix0, …) ou des interfaces “virtuelles” (vlan_10, bridge_100, …). Chaque correspondance autorisée entre un datagramme (paquets de données) et une règle de firewall va créer une entrée dans la table d’état. Les règles qui interdisent le traffic permettent de rejeter les datagrammes correspondant et ainsi améliorent la sécurité de vos réseaux.

Attention : l’ordre des règles est essentiel !

1. les règles sont appliquées une à une

2. du haut de la liste vers le bas

3. le processus de filtrage prend fin à la première correspondance

Analyse des champs constituant les règles de firewall

Les règles de firewalls sont créées en utilisant un certain nombre de champs qui vont permettre de structurer vos règles. Nous allons retrouver ces champs sur toutes les interfaces quel que soit le type de règles.

Note

Si vous hésitez à utiliser un champ ou ne comprenez pas bien sa signification, laissez le à sa valeur par défaut. La plupart du temps les valeurs par défaut sont correctes et vous permettront de parvenir au résultat escompté.

Les champs standards

Ces éléments correspondent aux champs présentés dans le graphique figurant ci-dessous. Les descriptions détaillées de chaque champ sont fournies ci-dessous :

Actions

Ce champ correspond à l’action qui sera prise si la règle correspond au paquet auquel elle est appliquée. Vous disposez de trois choix et il est essentiel de bien les comprendre :

1. Autoriser : le paquet correspondant sera autorisé et le trafic pourra passer

2. Bloquer : le paquet correspondant sera bloqué et aucune information ne sera retournée au client ayant initié la connexion

3. Rejeter : le paquet correspondant sera bloqué et un paquet TCP RST ou ICMP ‘port injoignable’ (pour UDP sera transmis au client.

En règle général, il est conseillé d’utiliser ‘Rejeter’ pour les règles appliquées sur vos interfaces locales (afin de ne pas bloquer vos clients) et d’utiliser ‘Bloquer’ pour toutes les correspondances établies sur vos interfaces WAN. L’utilisation de réponses du type ‘Rejeter’ sur le WAN peut permettre de déterminer l’OS du système adressant sa réponse et offrent ainsi un éléments de diagnostique pouvant être exploité par des éventuels attaquant (>> détermination de l’OS >> identification de failles >> attaque).

Désactivée

Permet de désactiver une règle de façon temporaire ou permanente, sans pour autant la supprimer.

Rapide

Si un paquet correspond à une règle spécifiant ‘quick’, cette règle est considérée comme la dernière règle correspondante et l’action spécifiée est directement appliquée. Lorsqu’une règle n’a pas activé “quick”, c’est la dernière règle correspondante qui l’emporte.

La valeur par défaut de cette option est ‘activée’ et doit généralement être conservée.

Interface

Par défaut l’interface sur laquelle est créée la règle s’affichera ici.

Note

Si vous avez des doutes, Reportez-vous à la section Application des règles au sein des interfaces pour bien comprendre où générer vos règles de firewall.

Direction

La politique par défaut consiste à filtrer le trafic entrant (in), cela consiste à filtrer le trafic sur l’interface qui reçoit initialement le trafic. Cette politique par défaut ne doit qu’exceptionnellement être changée sur les règles de firewall standard (par opposition aux règles de firewalls flottantes).

Version TCP/IP

Permet de sélectionnez la version IP qui s’appliquera à cette règle. Seul le ou les protocoles sélectionnés s’appliqueront (par exemple si un alias contient des IPv4 et IPv6 et que la règle spécifie ‘IPv4’, seules les adresses de cette classe s’appliqueront). .

Protocole

Permet de sélectionner le protocole applicable à la règle. Si vous sélectionnez ‘ICMP’, un champ supplémentaire apparaitra permettant d’affiner votre sélection.

Source / Inverser

Permet d’inverser le sens de la correspondance. Cette option peut être assez utile, par exemple pour n’autoriser qu’une IP unique à accéder à un service : créer une règle d’interdiction pour l’IP en question et cocher la case ‘Inverser’.

Source

Ce champ indique l’adresse IP source, le sous-réseau ou l’alias qui correspondra à cette règle. Les choix proposés sont les suivants :

• la saisie d’un alias préexistant

• un hôte unique ou un réseau (saisie manuelle)

• any

• Ce Pare-feu

• Les adresses des interfaces du firewall

• Les sous-réseaux des interfaces du firewall (attention : le choix de ‘WAN net’ ne correspond pas à l’Internet, mais bien au sous-réseau de votre interface).

Note

Nous vous recommandons de faire une utilisation la plus large possible des alias afin de simplifier la gestion de vos règles. Pour plus de précisions, reportez vous à Constituer une bibliothèque d’objet avec les Alias.

Plage de ports de destination

Ce champ permet de définir les ports de destination avec trois choix possibles :

• la saisie d’un alias préexistant

• any

• la sélection d’un port standard parmi la liste des ports connus

Log

Cette option permet de définir si la règle générera des logs dans le fichier de log du firewall et dans l’interface de DynFi Firewall. Nous vous recommandons d’activer cette option lors de la création des règles (afin de bien vérifier que la règle récupère du trafic) et pour les règles critiques ou vous souhaitez la génération d’une trace à des fins d’analyse ou d’archivage.

Catégorie

Permet de définir un marqueur visuel spécifique pour une meilleure classification de vos règles. N’a pas d’incidence sur le traitement des règles par le firewall.

Description

Texte permettant de synthétiser les actions liées à la règle. Nous vous recommandons d’utiliser un texte synthétique qui résume clairement l’objectif de traitement de cette règle.

Par exemple : ‘Autorise accès serveur Web client XXX sur port 4443, 443, 80 depuis Internet’.

Warning

Bien qu’il ne soit pas obligatoire de saisir de description pour vos règles de firewalls, nous vous recommandons vivement d’en saisir. Si vous êtes plusieurs à travailler sur un firewall, ou si vous devez un jour passer le relais à un autre collaborateur, il n’y a rien de plus désagréable que d’arriver sur un jeu de règles sans aucun commentaire. L’absence de documentation de ces règles peut engendrer un coût très important lié à l’audit et la rétro-investigation des règles.

Fonctionnalités avancées

Les fonctionnalités avancées présentées ci-dessous permettent d’associer la règle de firewall éditée à des opérations avancées. A la différence des Options avancées qui sont rarement utilisées, les fonctionnalités avancées rentrent régulièrement en jeu pour :

• choisir un jeu de règle en fonction d’un Operating System

• désactiver la synchronisation de la règle dans un Cluster

• définir une planification temporaire pour une règle

• définir une passerelle dynamique associé à la règle éditée

OS source

Le pop-up ‘OS source’ permet d’appliquer une règle de firewall en fonction du système d’exploitation (Operating System en Anglais) ayant envoyé la requête. Cette fonctionnalité est basée sur l’analyse des empreintes opéré par ‘p0f’ (« passive OS fingerprinting »).

Warning

Cette technique peut être utilisée afin de permettre un premier niveau de sécurisation associé à une règle. Cependant il est assez simple pour un administrateur système d’un certain niveau de créer un paquet simulant celui d’un autre OS. A utiliser en connaissance de cause.

Pas de Sync XMLRPC

S’applique lorsque la synchronisation des règles de pare-feu est activée dans Système ‣ Haute disponibilité :: Synchroniser les États En cochant cette case vous empêcherez cette règle de se synchroniser avec les autres membres d’un Cluster haute disponibilité via XMLRPC. Ceci est expliqué plus en détail dans la section haute_disponibilite_avec_dynfi_firewall .

Cela n’empêche pas une règle créée sur un nœud secondaire d’être écrasée par le nœud primaire.

Planifier

Ce champ permet de définir une temporalité pour l’application de la règle associée. La temporalité associée à la règle doit préalablement avoir été définie dans Pare-feu ‣ Paramètres ‣ Planifications

Pour ajouter une planification temporaire, veuillez procéder comme suit :

1. rendez-vous dans la section Pare-feu ‣ Paramètres ‣ Planifications du firewall

2. cliquer sur + Àjouter en haut à droite de la fenêtre

3. définir le nom associé à la règle

4. donner une description

5. sélectionnez les jours et mois qui vous conviennent : cliquez sur une date précise pour définir une temporalité précise ou sélectionnez des semaines entières pour permettre de créer une règle définie tout le temps

6. sélectionnez les horaires d’application de la règle (suivant la façon dont la règles est rédigée, cela peut être pris de façon inclusive ou exclusive)

7. donner une description à l’interval de temps défini

8. cliquez sur ‘Ajouter ce créneau’

9. recommencez l’opération autant de fois que vous souhaitez définir de créneau(x)

10. sauvegardez votre règle

Une fois la règle de planification sauvegardée, celle-ci sera disponible dans la section ‘Planifier’ de vos règles et pourra ainsi être utilisée.

Passerelle

Les firewalls basés sur Packet-filter (pf) autorisent la création de règles avancées qui permettent de ne pas utiliser la table de routage par défaut du système, mais de forcer l’utilisation d’une passerelle pour une règle.

Afin utiliser ce type de règle, vous devez disposer de plusieurs passerelles (par exemple plusieurs WAN vers différents opérateurs). Les passerelles qui ne sont pas définies par défaut doivent être ajoutées dans Système ‣ Passerelles ‣ Simple ou Système ‣ Passerelles ‣ Groupe.

Le principe de fonctionnement de ce menu est le suivant :

• vous pouvez forcer le routage des paquets correspondant à une règle en définissant la passerelle de votre choix dans ce menu

• si aucune valeur n’est définie : le routage par défaut sera utilisé

Footnotes

[1]

Vous pouvez vous connecter à votre firewall et faire un “man pfctl”. C’est un bon point de départ pour comprendre la mécanique en dessous du DynFi Firewall.