Utiliser correctement les hôtes IP, services et groupes de Sophos Firewall

Les hôtes IP et les services donnent un nom compréhensible aux adresses, réseaux et ports. Une règle de pare-feu indique alors directement quelle source peut communiquer avec quelle destination et quel service.

Le choix essentiel concerne la portée nécessaire : une adresse est créée comme IP, un sous-réseau comme Network, une plage d’adresses continue comme IP range et un petit ensemble d’adresses individuelles comme IP list. Pour TCP et UDP, un service décrit normalement le Destination Port fixe ; le Source Port dynamique reste inchangé.

Pour une nouvelle règle, le chemin le plus court et le plus sûr part du plus petit objet hôte adapté, passe par un service existant ou personnalisé et aboutit à une règle de pare-feu strictement limitée. Les cas particuliers, tels que les System Hosts, MAC Hosts et groupes réutilisables, ne viennent qu’ensuite. Avant toute modification ultérieure, Object Usage indique les règles et Policies qui dépendent de l’objet.

Choisir l’objet hôte adapté

Quatre types sont disponibles sous Hosts and services > IP host :

IP : une seule adresse IPv4 ou IPv6, par exemple un serveur, une imprimante ou un système d’administration.
Network : un sous-réseau complet avec son masque, par exemple 198.51.100.0/24.
IP range : une plage continue, par exemple de 203.0.113.10 à 203.0.113.20.
IP list : plusieurs adresses individuelles non contiguës. Une liste accepte au maximum 800 adresses IP et ne peut pas appartenir à une IP Host Group. L’aide actuelle de SFOS 22 contient la phrase « For IP list, use only class B IP addresses. » Sophos ne donnant aucune autre explication sur cette formulation obsolète fondée sur les classes réseau, il ne faut pas en déduire que des listes IPv4 ou IPv6 quelconques sont prises en charge.

Un hôte FQDN convient mieux lorsque l’adresse de destination change et qu’un nom DNS stable existe. La résolution, les caractères génériques et les limites sont expliqués dans Utiliser correctement les hôtes FQDN et FQDN avec caractères génériques.

La règle générale consiste à utiliser le plus petit objet stable qui décrit entièrement le trafic nécessaire. Un objet de type IP ne couvre qu’une adresse et est trop étroit pour un sous-réseau complet ; un réseau /24 serait inutilement large pour un seul serveur.

Créer un hôte IP étape par étape

L’exemple suivant représente un seul serveur de test :

Ouvrir Hosts and services > IP host et sélectionner Add.
Saisir host_test_web comme Name.
Régler IP version sur IPv4.
Sélectionner IP comme Type.
Saisir 192.0.2.10 sous IP address.
Enregistrer avec Save.

Les adresses suivantes issues de 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 sont réservées aux exemples de documentation. Dans une configuration de production, tous les noms, adresses et tailles de réseau doivent être remplacés par les valeurs du réseau réel.

Network, range et IP list

Les champs changent selon le type sélectionné :

Network : net_test_branch avec 198.51.100.0 et /24 représente l’ensemble du réseau de test. Il faut saisir l’adresse du réseau, et non celle de la passerelle.
IP range : range_test_admins de 203.0.113.10 à 203.0.113.20 représente une plage continue.
IP list : pour list_test_hosts, saisir uniquement des adresses provenant de son propre environnement vérifié, séparées par des virgules. La mention de la classe B dans l’aide actuelle étant ambiguë, créer la liste concrète sur la version de SFOS utilisée et la valider avec une règle de test. Cette liste convient à quelques adresses individuelles fixes, pas à des indicateurs de compromission qui changent continuellement.

Pour des adresses IP, domaines ou URL malveillants maintenus dynamiquement, les Threat Feeds dans Sophos Firewall constituent la fonction adaptée. Une IP list manuelle n’est pas mise à jour automatiquement.

IP Host Groups

Sous Hosts and services > IP host group, les hôtes ayant le même objectif fonctionnel peuvent être regroupés. Un groupe peut par exemple contenir tous les systèmes d’administration autorisés et être ensuite utilisé dans plusieurs règles.

Trois limites importantes s’appliquent :

Les hôtes IPv4 et IPv6 ne peuvent pas appartenir à la même IP Host Group.
Un hôte normal peut appartenir à plusieurs groupes.
Un objet de type IP list ne peut pas être ajouté à une IP Host Group.

Les groupes doivent avoir une signification commune. Un groupe mêlant serveurs, clients et exceptions temporaires peut réduire le nombre de clics, mais il devient ensuite difficile de comprendre pourquoi une règle autorise l’accès.

Comprendre les hôtes système et d’interface

SFOS crée automatiquement plusieurs objets hôte. Ces objets ne doivent pas être recréés comme des Custom Hosts ordinaires ni modifiés au mauvais endroit :

Les Interface Hosts suivent la configuration IP sous Network > Interfaces et sont modifiés à cet endroit. Zones et interfaces dans Sophos Firewall explique la relation entre connexion, zone et règle.
Si la conception du réseau et les exigences du fournisseur imposent de lier localement une adresse supplémentaire à une interface physique, la configurer comme adresse IP alias à l’interface physique. Si un champ NAT ne propose pas l’Interface Host correspondant, créer en plus un Custom IP Host portant un nom explicite et cette adresse. Lui donner le même nom est une convention utile, pas une exigence technique.
##WWAN1 est géré dynamiquement pour l’interface Cellular WAN.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW et ##ALL_RW représentent des hôtes Remote Access dynamiques.
Les autres System Hosts ne peuvent pas être modifiés ou supprimés comme des objets personnalisés.

Les hôtes Remote Access dynamiques ne peuvent pas être ajoutés à une autre IP Host Group. Les Physical Interface Hosts ne sont pas disponibles dans certains champs NAT, notamment Translated source et Translated destination. Dans ce cas, un hôte IP distinct avec la même adresse peut être nécessaire. Son nom doit montrer clairement son lien avec l’interface afin qu’il ne paraisse pas être une adresse indépendante.

Pour les hôtes internes du sous-réseau d’alias, SFOS doit être la passerelle par défaut. Si un équipement en amont utilise le pare-feu comme passerelle, il lui faut une adresse IP dans chaque sous-réseau d’alias concerné. Après le remplacement d’un pare-feu, des entrées ARP obsolètes sur les équipements en amont peuvent rendre temporairement l’adresse IP alias inaccessible. Il faut alors d’abord contrôler et actualiser leur cache ARP, plutôt que d’élargir inutilement la règle NAT.

Pour les routes SD-WAN sortantes vers internet, Sophos recommande également de choisir Internet IPv4 group ou les hôtes par défaut qu’il contient comme destination plutôt que Any. La route reste ainsi limitée aux destinations IPv4 publiques et n’attire pas du trafic interne dans le même chemin uniquement parce que l’objet de destination est trop large.

Utiliser des hôtes MAC pour les appareils directement visibles

Un hôte MAC décrit un appareil au niveau 2 et peut contenir une adresse unique ou une liste. Il ne convient que lorsque le pare-feu voit l’adresse MAC source réelle. Derrière un routeur, un VPN ou un NAT, il voit généralement l’adresse MAC du prochain saut et non celle du client d’origine. Pour les règles routées, un hôte IP ou un réseau est donc habituellement plus stable.

Sous Hosts and services > MAC host > Add, attribuer à l’objet un nom explicite et choisir MAC address ou MAC list. L’adresse peut être écrite avec des deux-points, comme 00:16:76:49:33:CE, ou des tirets, comme 00-16-76-49-33-CE ; plusieurs entrées sont séparées par des virgules. Une MAC list prend en charge au maximum 1 000 adresses MAC.

Un hôte MAC n’est pas une identité d’appareil. Une adresse MAC peut être copiée ou usurpée et peut changer avec une station d’accueil, une machine virtuelle ou une adresse Wi-Fi privée. L’objet convient comme critère de correspondance restrictif dans un segment contrôlé, mais pas comme unique authentification ou frontière de sécurité.

Créer un service avec le bon Destination Port

Avant de créer un service, il faut vérifier si un service standard adapté existe déjà. Un Custom Service est utile lorsqu’une application nécessite un autre port ou une combinaison particulière de protocoles.

L’exemple suivant crée le service TCP pour iPerf3 :

Ouvrir Hosts and services > Services et sélectionner Add.
Saisir svc_iperf3_tcp comme Name.
Régler Type sur TCP/UDP et Protocol sur TCP.
Conserver le Source Port prédéfini 1:65535.
Saisir 5201 comme Destination Port.
Enregistrer avec Save.

Le client choisit normalement son Source Port de manière dynamique. Si le service le limitait également à 5201, une connexion normale ne correspondrait plus. Le port fixe du serveur doit donc être saisi sous Destination Port. Un Source Port restreint n’est correct que lorsque le protocole l’exige explicitement et que le trafic réel confirme ce comportement.

Pour un test UDP iPerf3, il faut également créer svc_iperf3_udp avec le protocole UDP et le Destination Port 5201. Comme iPerf3 continue d’utiliser une connexion de contrôle TCP pour le test UDP, les deux services sont regroupés :

Ouvrir Hosts and services > Service group et sélectionner Add.
Saisir grp_iperf3 comme Name.
Sélectionner svc_iperf3_tcp et svc_iperf3_udp.
Enregistrer avec Save.

La procédure de mesure complète est décrite dans Test de débit iPerf3 à travers Sophos Firewall.

Un Service Group peut combiner des services par défaut et personnalisés, et un service peut appartenir à plusieurs groupes. Les Services et Service Groups ne font pas de distinction entre IPv4 et IPv6 ; la version IP est déterminée par les objets hôtes et le contexte de la règle. Les Service Groups par défaut ne peuvent pas être modifiés ni supprimés ; une combinaison propre nécessite donc un nouveau groupe.

Les services prédéfinis, ainsi que ceux déjà utilisés dans des Security Policies, ne peuvent pas non plus être modifiés ou supprimés. Plutôt que de contourner une dépendance, créer le Custom Service requis, remplacer méthodiquement l’ancien objet dans les Policies concernées, puis vérifier l’affichage Usage actualisé.

IP, ICMP et ICMPv6

Outre TCP et UDP, un Custom Service peut décrire un numéro de protocole IP ou des types et codes ICMP/ICMPv6. Ces types sont destinés aux protocoles qui n’utilisent pas de port TCP ou UDP. Les valeurs doivent provenir de la documentation technique de l’application et non être devinées après un seul test infructueux.

Utiliser les objets dans une règle de pare-feu

Un objet hôte ou service n’autorise aucun trafic à lui seul. Il devient actif uniquement lorsqu’il est utilisé comme critère de correspondance dans une règle. Un exemple restrictif pourrait être le suivant :

Source zones: LAN
Source networks and devices: net_test_branch
Destination zones: DMZ
Destination networks: host_test_web
Services: HTTPS
Log firewall traffic: activé

Les zones, adresses et le service doivent être adaptés au réseau réel. Le trafic de réponse d’une connexion avec suivi d’état autorisée est automatiquement renvoyé. Cette règle n’autorise toutefois pas de nouvelles connexions indépendantes de la DMZ vers le LAN. Une règle NAT seule n’accorde pas non plus d’autorisation : une règle de pare-feu correspondante reste nécessaire.

SFOS examine les règles de pare-feu de haut en bas et s’arrête à la première correspondance. La nouvelle règle spécifique doit donc précéder toute règle plus large qui traiterait sinon le même flux en premier. Comprendre et configurer les règles Sophos Firewall en sécurité explique l’ordre, les fonctions de protection et les tests.

Après l’enregistrement, contrôler une véritable tentative de connexion dans le Log Viewer. Des filtres sur l’adresse de test, le port et la règle permettent d’isoler le bon flux, puis de vérifier Rule ID, Source, Destination et Service dans la vue détaillée. Cela permet de distinguer un objet mal défini d’un trafic traité par une autre règle. Si une connexion s’interrompt sans événement Destroy reconnu par le pare-feu, son entrée de session finale peut manquer ; Packet Capture et Live Connections offrent alors une meilleure contre-vérification.

Actualiser Object Usage avant toute modification

Un objet peut être utilisé dans des règles de pare-feu et NAT, des VPN, des routes SD-WAN ou d’autres configurations. Avant de le modifier ou de le supprimer, il faut donc contrôler ses dépendances.

La colonne Usage de la liste des objets indique le nombre connu de références. Ce compteur n’est actualisé automatiquement qu’une fois par jour. Avant une modification :

Sélectionner Refresh à côté de Usage.
Ouvrir le compteur actualisé de l’objet concerné.
Développer les catégories et examiner chaque règle ou Policy dépendante.
Décider ensuite seulement si l’objet peut être modifié, remplacé ou supprimé.

Toutes les dépendances ne peuvent pas être modifiées directement depuis la vue Usage. Certaines, notamment les passerelles WAN et les configurations CLI, doivent être ouvertes séparément à l’emplacement de configuration indiqué. Un compteur égal à zéro n’est une base fiable qu’après un Refresh manuel.

Exploiter les objets en toute sécurité

Éviter les erreurs courantes

Host au lieu de Network : une adresse IP individuelle ne couvre pas automatiquement le sous-réseau associé.
Adresse réseau ou masque incorrect : pour un objet Network, l’adresse réseau et le préfixe doivent correspondre à la segmentation réelle.
Source Port restreint : pour les connexions client-serveur normales, conserver 1:65535 et limiter le Destination Port.
Trop de Any : un objet hôte précis perd son intérêt en matière de sécurité si la source ou le service reste inutilement large.
Objet système dupliqué : SFOS gère les hôtes d’interface et Remote Access ; ils ne doivent donc pas être copiés sans raison concrète.
IP list utilisée comme Threat Feed : une IP list reste statique et ne remplace pas des indicateurs de menace mis à jour automatiquement.
Dépendances non actualisées : toujours sélectionner Refresh dans Object Usage avant de modifier ou de supprimer un objet.

Des préfixes explicites comme host_, net_, range_, svc_ et grp_ ne sont pas une exigence technique, mais facilitent la recherche et la révision. Plus que le schéma exact, l’essentiel est d’utiliser de façon cohérente les noms, objectifs et portées dans l’ensemble des règles.

Conserver un inventaire réduit et compréhensible

SFOS accepte jusqu’à 16 000 hôtes pour l’ensemble des types. Il s’agit d’une limite de plateforme, pas d’un objectif de planification. En exploitation, une base d’objets réduite et compréhensible est plus utile qu’une multitude d’entrées difficiles à distinguer. Les objets devenus inutiles ne doivent être remplacés ou supprimés de manière contrôlée qu’après actualisation et examen de leur Usage.