Utiliser correctement les IP hosts, services et groupes de Sophos Firewall
Les IP hosts 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é.
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.
Un FQDN host convient mieux lorsque l’adresse de destination change et qu’un nom DNS stable existe. La résolution, les wildcards et les limites sont expliqués dans Utiliser correctement les FQDN hosts et wildcard FQDNs.
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 IP host étape par étape
L’exemple suivant représente un seul serveur de test :
- Ouvrir
Hosts and services > IP hostet sélectionner Add. - Saisir
host_test_webcomme Name. - Régler IP version sur
IPv4. - Sélectionner
IPcomme Type. - Saisir
192.0.2.10sous 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_branchavec198.51.100.0et/24repré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_adminsde203.0.113.10à203.0.113.20représente une plage continue. - IP list :
list_test_hostspeut par exemple contenir192.0.2.10,198.51.100.20. Cette liste convient à quelques adresses individuelles fixes, pas à des Indicators of Compromise 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 listne 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 > Interfaceset sont modifiés à cet endroit. Zones et interfaces dans Sophos Firewall explique la relation entre connexion, zone et règle. ##WWAN1est géré dynamiquement pour l’interface Cellular WAN.##ALL_SSLVPN_RW,##ALL_SSLVPN_RW6,##ALL_IPSEC_RWet##ALL_RWrepré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 IP host 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.
Créer un service avec le bon Destination Port
Avant de créer un service, il faut vérifier si un service standard adapté comme HTTP, HTTPS, DNS ou NTP 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 > Serviceset sélectionner Add. - Saisir
svc_iperf3_tcpcomme Name. - Régler Type sur
TCP/UDPet Protocol surTCP. - Conserver le Source Port prédéfini
1:65535. - Saisir
5201comme 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 groupet sélectionner Add. - Saisir
grp_iperf3comme Name. - Sélectionner
svc_iperf3_tcpetsvc_iperf3_udp. - Enregistrer avec Save.
La procédure de mesure complète est décrite dans Test de débit iPerf3 à travers Sophos Firewall.
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 stateful autorisée est automatiquement renvoyé. Cette règle n’autorise toutefois pas de nouvelles connexions indépendantes de la DMZ vers le LAN. 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, une véritable tentative de connexion doit être contrôlée dans le Log Viewer. Le Rule ID, la Source IP, la Destination IP et le Destination Port attendus doivent apparaître. Cela permet de distinguer un objet mal défini d’un trafic traité par une autre règle.
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 WAN gateways 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.
É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:65535et 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.
SFOS accepte jusqu’à 16 000 hôtes pour l’ensemble des types. En exploitation, une base d’objets plus petite et compréhensible reste néanmoins plus utile qu’une multitude d’entrées presque identiques. Les objets devenus inutiles doivent être supprimés de manière contrôlée après actualisation et examen de leur Usage.