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.

Outre les Custom IP Hosts, les hôtes par défaut des interfaces, du Cellular WAN et d’internet peuvent aussi appartenir à un groupe. L’appartenance à un groupe est distincte de la possibilité de modifier l’objet hôte : un hôte système qui ne peut pas être modifié directement n’est donc pas automatiquement exclu des groupes. Les hôtes système dynamiques de VPN Remote Access restent toutefois exclus.

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.

Pour créer un petit groupe de test IPv4 contenant host_test_web, créé précédemment :

Ouvrir Hosts and services > IP host group et sélectionner Add.
Saisir grp_test_servers comme Name ; adapter le nom à l’objectif du groupe.
Régler IP version sur IPv4, comme pour l’hôte de test existant.
Avec Add new item, sélectionner host_test_web. Les autres membres doivent avoir le même objectif et la même version IP.
Enregistrer avec Save.

Rouvrir ensuite le groupe et vérifier sa version IP et ses membres. Si un hôte souhaité manque dans la sélection, contrôler d’abord sa version IP et son type ; ne pas contourner l’exclusion d’une IP list ou d’un hôte système VPN Remote Access par un objet de remplacement inutilement large.

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

La liste des hôtes IP affiche les interfaces physiques, y compris les modules FleXi-Port supplémentaires, ainsi que les interfaces virtuelles créées manuellement. Sous Address details figurent l’adresse et le masque réseau provenant de Network > Interfaces. Si une valeur est inattendue, comparer d’abord cette configuration d’interface avec l’affichage ; l’objet hôte géré automatiquement n’est pas l’endroit où modifier une adresse.

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 créé lors de l’activation du Cellular WAN, utilise l’adresse IP de l’interface WWAN et est géré dynamiquement.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW et ##ALL_RW représentent des hôtes Remote Access dynamiques.
##ALL_SSLVPN_RW contient les adresses IP attribuées par le pare-feu aux connexions VPN SSL Remote Access établies avec Sophos Connect. ##ALL_IPSEC_RW contient les adresses attribuées aux connexions IPsec correspondantes. ##ALL_RW réunit les adresses attribuées aux deux types de connexion ; SFOS les ajoute dynamiquement lors de l’établissement des connexions.
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 sert de passerelle pour le trafic de Sophos Firewall, 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.

Contrairement aux hôtes système non modifiables, les hôtes internet par défaut peuvent être modifiés et supprimés. Avant de le faire, actualiser Object Usage comme décrit ci-dessous et vérifier les règles et routes SD-WAN dépendantes. Cette exception concerne les hôtes internet, pas les hôtes système dynamiques VPN/WWAN ; les adresses des interfaces sont toujours modifiées sous Network > Interfaces.

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é.

Exemple : bloquer un flux non web selon sa MAC source

Cet exemple pour SFOS 22/23 bloque un nouveau flux IPv4 TCP iPerf3 depuis un appareil de test LAN directement visible vers un serveur de test WAN contrôlé. Il ne s’agit pas d’une procédure de blocage de tout accès à internet : HTTP/HTTPS et Web Exceptions sont exclus de ce test. Vérifier d’abord avec Packet Capture sur l’interface entrante la véritable MAC source de l’appareil. Si seul un routeur en amont est visible, cette règle ne convient pas ; un port LAN sur un commutateur ne prouve pas à lui seul la visibilité de niveau 2. Avant la modification, vérifier que le serveur WAN et le port TCP 5201 sont accessibles. Le serveur doit réellement exécuter iPerf3, pas un service web.

Sous Hosts and services > MAC host > Add, saisir mac_test_client comme Name, MAC address comme Type et 02:00:00:00:00:10 comme MAC address, puis enregistrer avec Save. Le nom et l’adresse unicast administrée localement sont des exemples ; remplacer l’adresse par la MAC vérifiée de l’appareil.
Ouvrir Rules and policies > Firewall rules, choisir IPv4 et créer drop_mac_test_wan avec Add firewall rule > New firewall rule. Régler Action sur Drop et activer Log firewall traffic.
Régler Source zones sur LAN, Source networks and devices sur mac_test_client et Destination zones sur WAN. Sous Destination networks, choisir l’IP Host du serveur WAN de test, et sous Services, svc_iperf3_tcp ; créer ce service TCP avec Destination Port 5201 comme décrit dans la section suivante. La destination et le service de test non web restent ainsi strictement limités. Any n’est pas nécessaire dans cet exemple.
Régler During scheduled time sur All the time pour un blocage permanent, sinon choisir le calendrier adapté. Placer la règle avant celles qui autoriseraient d’abord le même flux, sans déplacer les exceptions prioritaires intentionnelles. Top n’est pas une exigence universelle. Rule group peut rester sur None ; un groupe ne remplace pas un positionnement correct. Enregistrer avec Save et contrôler l’ordre réel.

Ensuite, lancer depuis l’appareil de test une nouvelle tentative de connexion TCP iPerf3 vers le même serveur WAN sur le port 5201, pas un test UDP ou par navigateur. Dans Log Viewer, Drop et la Rule ID de cette règle de blocage doivent correspondre au flux. Tester le même flux non web depuis un second appareil non bloqué : il doit toujours correspondre à la règle Allow prévue. Utiliser de nouvelles connexions pour les deux tests, pas des sessions existantes. Si la correspondance attendue manque, vérifier la MAC source dans Packet Capture, les zones, la version IP, le calendrier, la portée destination/service et les règles précédentes.

Cette vérification n’établit que les flux testés, pas un blocage général du web ou d’internet. IPv6, les autres zones de destination, destinations et services ne sont pas couverts et nécessitent une configuration et des tests distincts. Pour revenir en arrière, désactiver uniquement la nouvelle règle de blocage et vérifier l’état autorisé précédent avec un nouveau flux TCP iPerf3. Le risque d’usurpation et d’identité décrit plus haut demeure.

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.

Pour un service de type IP sous Hosts and services > Services > Add, attribuer un Name adapté, régler Type sur IP, sélectionner le numéro de protocole requis et enregistrer avec Save. Il s’agit du numéro du protocole IP, pas d’un port de destination TCP/UDP. Rouvrir ensuite le service et comparer le numéro avec les exigences de l’application ; lors du test dans une règle strictement limitée, vérifier dans Packet Capture le protocole réellement observé. Si la correspondance attendue manque, contrôler d’abord le protocole et la portée de la règle plutôt que de recourir à Any.

Sous Hosts and services > Services > Add, un service peut contenir plusieurs entrées du même type sélectionné. Pour ICMP ou ICMPv6, choisir d’abord le couple type/code requis, ajouter d’autres couples avec Add et supprimer les entrées inutiles avec Remove. Vérifier ensuite toutes les entrées et enregistrer avec Save. Plusieurs messages ICMP nécessaires peuvent ainsi être décrits dans un seul service, sans autoriser indistinctement tous les types. Les services TCP/UDP distincts et le Service Group de l’exemple iPerf3 restent une alternative claire lorsque les services doivent être réutilisés individuellement.

Note de version sur la documentation de l’API : Dans la table enregistrée de l’API Sophos « Add Service / Update Service » pour SFOS 22, la colonne Mandatory indique No pour ICMPType et ICMPv6Type ; pour SFOS 23, elle indique Yes dans les deux cas. Il s’agit de mentions dans la documentation de l’API, pas d’une preuve de changement de la GUI ou du comportement à l’exécution. Elles concernent les champs ICMP/ICMPv6 et ne doivent pas être interprétées comme une obligation d’ajouter les deux familles de protocoles aux services TCP/UDP/IP. La page ne définit aucune règle conditionnelle précisant quand ces champs peuvent être omis ; ces mentions ne permettent donc pas d’en déduire des instructions concrètes sur le payload ou la validation.

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.

Trouver les objets existants et les gérer de manière ciblée

Les listes sous Hosts and services > IP host, IP host group, MAC host, Services et Service group permettent de rechercher les objets selon leurs attributs respectifs. Avant de créer un objet, rechercher non seulement le nom souhaité, mais aussi les valeurs d’adresse ou de protocole/port requises, dans la mesure où elles s’appliquent au type d’objet. Cela permet de repérer un objet déjà adapté portant un autre nom. Après l’enregistrement, rechercher à nouveau l’objet et vérifier ses valeurs ou les membres du groupe, selon le cas.

Les Custom IP Hosts et les IP Host Groups peuvent être ajoutés, modifiés et supprimés ; les Service Groups personnalisés peuvent également être modifiés, renommés, complétés par des services ou supprimés. Toujours commencer par actualiser Object Usage. Une modification de groupe affecte toutes les règles qui utilisent ce groupe, pas seulement le cas d’utilisation en cours de traitement. Consigner au préalable les valeurs et les membres existants, puis vérifier les connexions concernées avec de nouvelles sessions. Si la portée est incorrecte, annuler la modification de manière contrôlée et tester à nouveau. Les restrictions décrites plus haut pour les System Hosts, les Service Groups par défaut et les services protégés restent applicables.

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.