Le firewall est stateful

Les réponses aux sessions établies passent d'office. Une règle retour ne se justifie que pour les sessions réellement initiées depuis l'autre côté — et elle ouvre alors une porte qu'il faut restreindre.

Avant d'écrire une règle retour, une seule question : qui ouvre la connexion ?

• Protocoles à canal secondaire (FTP actif, SIP/RTP) : le second flux est négocié dans la session, et c'est le plugin applicatif qui l'ouvre dynamiquement. D'où l'intérêt de ne pas le désactiver à la légère — et le problème inverse avec les SBC opérateur.
• UDP : pas de connexion, un pseudo-état avec expiration. Une réponse tardive redevient une connexion entrante, donc bloquée. C'est la raison d'être des keepalives.
• ICMP : l'echo-reply correspond bien à l'état créé. Mais un message d'erreur ICMP (type 3 code 4, « fragmentation needed ») vient d'un routeur intermédiaire, pas du destinataire. Le filtrer casse la découverte de MTU, avec des symptômes de lenteur plutôt que de coupure franche.

Les règles implicites passent avant le slot

Stormshield crée ses propres règles de filtrage pour les services du boîtier : interface d'administration (443 par défaut, 13443 sur le parc), SSH (22), serveur d'administration (1300), DNS du boîtier, IKE et ESP vers les correspondants IPsec, VPN SSL (TCP 13444 sur le parc), portail d'authentification. Elles sont évaluées avant les règles définies manuellement : une règle explicite qui les contredit n'est jamais atteinte.

Conséquence directe : une règle « postes techniques vers le firewall » ne restreint rien tant que la règle implicite ouvre l'administration à toutes les interfaces protégées. La restriction se fait dans Postes d'administration autorisés, ou en remplaçant l'implicite par une règle explicite.

Sources : Stormshield — règles implicites · ANSSI R30 · Onglet Administration du Firewall

Une seule règle en Any annule toutes les autres

Une règle « pass » vers Internet en port Any rend inopérantes toutes les listes de ports qui la précèdent. Elle se retire par la méthode du § 03, jamais d'un coup.

Les critères de destination se cumulent

Objets réseau, géolocalisation, réputation, services web : le trafic doit satisfaire tous les critères renseignés.

Une plage RPC impose une destination nommée

Tcp_49152-65535 vers un objet serveur précis est acceptable. Vers un VLAN entier, c'est une absence de filtrage déguisée. Même règle pour la plage Veeam Tcp_2500-3300.

Les objets FQDN dépendent du DNS du firewall

Un FQDN qui ne résout pas rend la règle inopérante sans erreur visible — un simple triangle orange. Sans serveur DNS joignable, l'objet ne contient que l'adresse saisie à sa création, et les adresses nouvelles s'apprennent par requêtes espacées de 5 minutes.

Trois contraintes, documentées par Stormshield :

• un objet FQDN ne peut pas être membre d'un groupe ;
• une règle n'accepte qu'un seul objet FQDN, sans autre objet réseau à côté ;
• il ne fonctionne pas en NAT, et le boîtier n'affiche aucun avertissement.

Le joker *.domaine.fr n'est pas accepté par un objet FQDN. Quand une destination compte plusieurs noms, ou un joker : service web personnalisé — un seul joker, en début ou au milieu du nom, et une seule base importée par boîtier. Le catalogue produit le fichier d'import (vue Objets réseau).

Sources : Stormshield — objets de type Nom DNS · Stormshield — services web personnalisés

Une alarme bloquante l'emporte sur la règle

Un flux peut être refusé par un analyseur applicatif alors que le filtrage l'autorise. Cherchez l'alarme dans Monitoring avant de soupçonner la politique.

Ce que change réellement le profil d'inspection

L'analyse a lieu dans les deux derniers cas. La seule différence, c'est ce qui se passe quand l'analyseur n'est pas content. D'où la règle : une bascule en IPS se teste, flux par flux.