Configurer et tester les Clientless Users sur Sophos Firewall

Une imprimante, un serveur ou un autre équipement fixe ne peut souvent pas se connecter au pare-feu. Clientless Users donne néanmoins une identité compréhensible à ce trafic : Sophos Firewall associe un nom d’utilisateur configuré à l’IP source visible et peut utiliser cette identité dans les règles, Live Users et les logs.

Il ne s’agit pas d’une authentification. Quiconque reprend l’IP configurée ou apparaît derrière la même adresse NAT peut recevoir la même attribution. Clientless Users ne convient donc qu’aux équipements dont l’adresse est stable et contrôlée. Pour des appareils personnels changeants, des IP partagées ou des accès privilégiés, une véritable méthode de connexion constitue le meilleur choix.

⚠️ Clientless Users n’est pas Clientless SSL VPN. Clientless Users associe en interne une IP à une identité. Clientless SSL VPN publie au contraire des bookmarks RDP, SSH ou de serveurs de fichiers dans le VPN Portal.

Clientless User en huit étapes

1. Définir l’équipement, son responsable, les destinations nécessaires et l’IP source visible par le pare-feu.
2. Configurer l’adresse de manière statique ou la lier sans ambiguïté par une réservation DHCP.
3. Sous Authentication > Groups, créer un petit groupe de type Clientless.
4. Sous Authentication > Clientless users > Add, créer exactement un utilisateur pilote avec cette IP.
5. Créer une règle de pare-feu distincte et journalisée avec la source exacte, Match known users et le groupe clientless.
6. Contrôler l’utilisateur sous Current activities > Live users et le flux réel dans Log Viewer.
7. Passer brièvement l’utilisateur à l’état Inactive et confirmer que la règle d’identité ne correspond plus.
8. Réactiver l’utilisateur, valider de nouveau la règle et documenter l’attribution, le responsable et la date de révision.

Quand Clientless Users convient

Clientless Users est utile lorsqu’une règle de pare-feu ou un rapport nécessite une identité d’équipement stable, mais que celui-ci ne peut pas effectuer de connexion utilisateur. Les imprimantes, appliances de supervision, équipements de laboratoire ou serveurs d’infrastructure fortement limités sont des candidats typiques.

La fonction ne convient que si tous les points suivants sont respectés :

• Le pare-feu voit toujours la même IP source sans ambiguïté pour le trafic.
• L’adresse est statique ou liée par une réservation DHCP contrôlée.
• L’adresse ne représente pas plusieurs équipements derrière un NAT ou un proxy.
• L’identité n’accède qu’aux destinations et services réellement nécessaires à l’équipement.
• Un autre équipement ne peut pas reprendre l’adresse sans être détecté.
• Un test positif et un test négatif sont possibles avec un flux de données réel.

Pour les clients de domaine habituels, STAS est généralement plus adapté. Si l’accès réseau produit déjà du RADIUS Accounting, RADIUS SSO Accounting peut établir dynamiquement l’association utilisateur-IP. Le Captive Portal fournit une connexion interactive.

Clientless Users ne compense pas une segmentation absente. Une imprimante doit toujours se trouver dans une zone appropriée ou un réseau séparé et disposer d’une règle précise. L’identité basée sur l’IP complète ce contrôle, mais ne le remplace pas.

Fonctionnement et limite de sécurité

Sophos Firewall présente un Clientless User actif comme Live User sans connexion interactive. Lorsqu’un paquet correspond à l’IP configurée, le nom d’utilisateur attribué est disponible pour les règles utilisateur et les rapports.

Cela ne fournit aucune preuve cryptographique de l’équipement ou de la personne :

• Il n’y a ni mot de passe ni second facteur.
• L’attribution ne vérifie aucune session personnelle Windows ou Entra.
• Un changement d’IP n’est pas automatiquement interprété comme un changement d’équipement.
• Une IP NAT ou proxy partagée ne permet pas de distinguer les différents endpoints.
• Un Clientless User n’est pas un utilisateur de Remote Access VPN.

Si des règles nominatives sont nécessaires, Clientless Users ne devrait être utilisé que dans des cas exceptionnels bien contrôlés. Pour une personne disposant d’un poste fixe, l’attribution DHCP doit être stable, mais l’identité reste liée à l’IP et non à la personne devant l’écran.

Exemple et valeurs à remplacer

La procédure utilise une imprimante qui ne peut joindre que DNS, NTP et un serveur d’impression interne :

• Username : Printer-Accounting
• adresse IP visible : 192.0.2.50
• groupe clientless : Clientless-Devices
• règle de pare-feu : Printer-Accounting_to_Services
• Source network : objet host Printer-Accounting_192.0.2.50
• destination : service DNS/NTP interne et serveur d’impression prévu
• révision : responsable et prochaine date de contrôle dans la description de la règle

192.0.2.50 appartient à la plage de documentation IPv4 officielle et n’est pas une adresse d’équipement en production. Elle doit être remplacée par l’IP fixe que le pare-feu voit comme source du flux réel. En IPv6, il faut une adresse IPv6 fixe, une règle IPv6 distincte et une validation séparée.

Les noms de l’exemple montrent le but, mais ne constituent pas une spécification du produit. Dans un environnement réel, l’utilisateur, le groupe, l’objet host et la règle devraient suivre une convention de nommage cohérente.

Préparer l’adresse et le groupe

Confirmer l’IP source visible

Avant de configurer l’identité, générer exactement un flux de données contrôlé depuis l’équipement. Dans Log Viewer ou Packet Capture, consigner au minimum Source IP, In interface, la destination, le service et la Firewall Rule ID précédente.

Si la source visible est une adresse NAT, proxy ou de passerelle partagée, arrêter ici. Cette adresse ne doit pas être attribuée à un seul Clientless User. Dans le cas contraire, tous les équipements situés derrière recevraient la même identité.

Avec DHCP, créer une réservation pour cet équipement précis. La simple saisie dans le pare-feu d’une adresse libre du pool ne suffit pas : si le serveur DHCP l’attribue ensuite à un autre client, celui-ci hérite de l’identité et potentiellement des autorisations de la règle.

Créer un groupe clientless

Sous Authentication > Groups > Add, créer un groupe distinct :

1. Saisir Clientless-Devices comme Name.
2. Sélectionner Clientless comme Group type.
3. Définir uniquement les stratégies de groupe nécessaires.
4. Enregistrer avec Save.

Les stratégies propres à l’utilisateur prévalent sur celles du groupe attribué. Le groupe devrait donc avoir un objectif de référence commun et compréhensible. Les écarts pour un utilisateur individuel sont documentés et testés séparément.

Les Clientless Users ne prennent pas en charge Surfing quota, Access time ni Network traffic policy. Si un appareil fixe ne doit communiquer qu’à certaines heures, un Schedule est utilisé dans la règle firewall étroitement délimitée. Access Time pour les utilisateurs et les groupes s’applique en revanche aux utilisateurs ordinaires, aux groupes et aux utilisateurs invités. Surfing Quota et Network Traffic Quota nécessitent elles aussi une attribution utilisateur ou groupe prise en charge.

Gérer correctement les groupes d’utilisateurs et le groupe principal sur Sophos Firewall explique pourquoi les groupes Normal, importés et Clientless représentent des modèles d’identité différents. Cet article reste consacré à la procédure Clientless complète basée sur l’IP.

Ajouter un seul Clientless User

Sous Authentication > Clientless users > Add, configurer les champs comme suit :

1. Username: Printer-Accounting
2. IP address: l’adresse fixe de l’équipement confirmée auparavant
3. Group: Clientless-Devices
4. Name: un nom d’affichage compréhensible pour l’équipement
5. Email: saisir une adresse réelle du responsable uniquement si elle est nécessaire à des fonctions comme Quarantine Digest
6. Quarantine digest: ne l’activer que consciemment ; cette fonction reste généralement désactivée pour une imprimante normale
7. Enregistrer avec Save.

Il est ensuite possible de rouvrir l’utilisateur et d’ajouter les paramètres individuels pris en charge. Une modification n’est considérée comme réussie que lorsque Live Users, la correspondance de la règle et le trafic réel sont de nouveau corrects.

Utiliser Add range uniquement avec une justification claire

Authentication > Clientless users > Add range crée des Clientless Users individuels pour toutes les adresses comprises entre From IP et To IP. Sophos attribue le groupe sélectionné ; chaque utilisateur généré peut ensuite être modifié séparément.

Un pool DHCP normal ne convient pas. Une plage traiterait à l’avance chaque adresse attribuée ultérieurement comme une identité connue. Add range ne convient qu’à un bloc d’adresses entièrement réservé et documenté, avec un usage homogène, une attribution contrôlée et une vérification individuelle ultérieure. Pour le premier déploiement, Add avec une seule IP reste l’option sûre.

Créer une règle de pare-feu précise

Comprendre et configurer les règles Sophos Firewall en toute sécurité explique la mécanique générale. Pour cet exemple, créer une règle distincte au-dessus d’une règle plus générale pour les imprimantes ou le LAN :

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: activé
• Source zone: zone réelle de l’équipement
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: zone des services prévus
• Destination networks: uniquement la destination DNS/NTP et le serveur d’impression
• Services: uniquement les ports nécessaires
• Match known users: activé
• Users or groups: Clientless-Devices ou l’utilisateur pilote individuel

L’IP source et la condition utilisateur peuvent être utilisées ensemble de manière délibérée. L’IP limite l’origine technique, tandis que l’identité rend la règle et les rapports compréhensibles. Une source générale Any ou une destination Any n’est pas nécessaire pour un équipement fixe.

Après l’enregistrement, vérifier qu’aucune règle plus générale placée au-dessus ne correspond en premier. Seule la Firewall Rule ID dans Log Viewer ou Packet Capture montre quelle règle traite le flux réel. Tester une règle Sophos Firewall fournit la procédure guidée.

Test positif et négatif

Contrôler l’identité et le flux autorisé

1. Sous Current activities > Live users, rechercher Printer-Accounting et l’IP attendue.
2. Générer exactement un flux prévu depuis l’équipement.
3. Dans Log Viewer, comparer l’utilisateur, Source IP, Firewall Rule ID, le nom de la règle, le service et l’action.
4. Vérifier que la destination reçoit la requête et que le chemin retour fonctionne.
5. Tester un service ou une destination non prévu et confirmer le drop attendu.

L’affichage dans Live Users ne suffit pas. Il confirme l’attribution active, mais pas la position de la règle, le service autorisé ni le chemin des données.

Utiliser le changement d’état comme test négatif

Un Clientless User ne doit pas être déconnecté avec Disconnect dans Live Users. Sous Authentication > Clientless users, sélectionner l’utilisateur pilote et utiliser Change status pour le passer à Inactive.

Il ne doit alors plus apparaître comme Clientless User dans Live Users. Une nouvelle connexion de test ne doit plus correspondre à la règle pilote basée sur l’utilisateur avec cette identité. Repasser ensuite l’utilisateur à Active et répéter le test positif.

Ce test ne doit pas produire une autorisation inattendue par une règle plus générale. Si la connexion doit rester autorisée après la désactivation, la règle de fallback prévue doit être documentée et également testée.

Dépanner méthodiquement

L’utilisateur n’apparaît pas dans Live Users

• Vérifier que l’état sous Authentication > Clientless users est Active.
• Comparer l’IP configurée avec la source réellement visible dans le paquet.
• Rechercher un Username en double ou une IP déjà utilisée.
• Examiner séparément les trafics IPv4 et IPv6.
• En présence de nombreux objets utilisateur et groupe, vérifier la User ID interne concrète. La limite de User ID ne se diagnostique pas à partir d’un nombre approximatif d’objets.

Selon l’aide SFOS actuelle, les Clientless Users sont visibles dans Live Users immédiatement après leur configuration. Le redémarrage d’un service, une intervention dans la base de données ou des suppressions et recréations répétées ne font pas partie de la procédure normale.

L’utilisateur est visible, mais la mauvaise règle correspond

• Vérifier Match known users, l’utilisateur ou le groupe sélectionné et l’état de la règle.
• Comparer Source zone, Source network, Destination zone, la destination et le service au flux réel.
• Contrôler la position de la règle et toute règle plus générale située au-dessus.
• Dans Log Viewer, ne pas filtrer uniquement sur le nom d’utilisateur ; comparer également Firewall Rule ID et Source IP.
• Créer une nouvelle connexion, car les sessions existantes ne sont pas réévaluées automatiquement.

La règle de pare-feu ne correspond pas fournit la logique de dépannage détaillée.

Le mauvais équipement reçoit l’identité

L’attribution de l’IP n’est pas suffisamment contrôlée. Vérifier le lease DHCP, la réservation, la configuration statique, une IP en double, le NAT et le proxy. Désactiver la règle ou passer le Clientless User à Inactive jusqu’à ce que l’équipement utilisant l’adresse source soit clairement identifié.

Ne pas créer une plage plus large pour rattraper des adresses changeantes. Cela élargit l’hypothèse de confiance incorrecte et complique l’attribution ultérieure.

La QoS ne s’applique pas avec de nombreux Clientless Users

Sophos documente NC-148705 comme corrigé dans SFOS 22.0 MR1 Build 490 : une QoS Policy ne s’appliquait pas lorsqu’il existait plus de 3000 Clientless Users. Les notes de version ne précisent aucune plage de versions affectées.

Si le symptôme correspond exactement, consigner la version et le build du firmware, puis planifier une mise à jour prise en charge au minimum vers MR1 Build 490 ou une version compatible ultérieure. Un problème de QoS avec moins d’utilisateurs ou sur un autre build ne prouve pas NC-148705 ; vérifier normalement l’attribution de la stratégie, la correspondance de la règle et Traffic Shaping.

Interpréter les logs et HA

access_server.log contient les événements d’authentification, d’autorisation et d’accounting. Pour le flux de données, le log du pare-feu, Log Viewer et Packet Capture restent déterminants. Logs de service Sophos Firewall explique l’affectation des logs.

Dans un cluster HA, la configuration et l’exploitation s’effectuent sur le Primary actuel. Sophos ne garantit pas que les états Live Users ou de session des Clientless Users survivent sans interruption à un failover. Après un failover contrôlé, vérifier de nouveau le Clientless User, la correspondance de la règle, le flux réel et les logs locaux du nœud ayant traité l’événement.

Exploitation et rollback

Chaque Clientless User nécessite un responsable, un objectif et une date de révision. En cas de remplacement de l’équipement, de changement de réseau ou d’abandon de la règle, l’attribution ne doit pas rester en place sans contrôle.

Le rollback contrôlé :

1. Documenter la règle, le groupe, les rapports et les dépendances de Traffic Shaping concernés.
2. Passer le Clientless User à Inactive.
3. Effectuer un test négatif de l’état Live Users et du flux de données réel.
4. Adapter la règle ou la condition utilisateur à l’état suivant prévu.
5. Supprimer le Clientless User lorsqu’il n’est plus nécessaire.
6. Supprimer le groupe uniquement lorsqu’aucun autre utilisateur ou aucune stratégie n’en a besoin.
7. Nettoyer séparément la réservation DHCP, l’objet host et la documentation.

Une identité de production ne doit pas être supprimée pendant un incident ouvert avant d’avoir conservé Source IP, Rule ID et les logs. Si l’attribution n’est pas claire, limiter d’abord l’accès et préserver les preuves.

FAQ