Configurer Surfing et Network Traffic Quota sur Sophos Firewall

Une Surfing quota limite le temps Internet utilisable par un utilisateur authentifié. Une Network traffic quota limite en revanche le volume de données transféré. Les deux stratégies sont attribuées à un utilisateur ou à un groupe et conviennent, par exemple, à des salles de formation, des invités ou des forfaits d’utilisation clairement définis.

Pour les invités temporaires, la création du compte, la validité, le Captive Portal et la purge sont planifiés séparément. Le cycle de vie complet est décrit dans Créer et exploiter en toute sécurité des utilisateurs invités sur Sophos Firewall ; cet article se concentre sur les quotas.

La procédure courte pour un déploiement contrôlé est la suivante :

1. Déterminer s’il faut limiter la consommation de temps, le volume de données ou les deux.
2. Créer une nouvelle stratégie pilote sous Profiles > Surfing quota ou Profiles > Network traffic quota.
3. Attribuer la stratégie à un petit groupe pilote sous Authentication > Groups ou à un utilisateur de test sous Authentication > Users.
4. Authentifier à nouveau l’utilisateur et vérifier l’identité reconnue sous Current activities > Live users.
5. Utiliser pour le test une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic.
6. Ouvrir l’utilisateur sous Authentication > Users et contrôler la consommation avec View usage.
7. Tester la limite, le cycle suivant et le rollback avant d’ajouter d’autres utilisateurs.

⚠️ Reset user accounting réinitialise à la fois le temps de navigation consommé et les compteurs de trafic réseau. Il s’agit d’un changement d’état et non d’un bouton de diagnostic général. Avant toute réinitialisation, documenter l’utilisateur, les valeurs actuelles, l’heure et le motif. Un quota de production partagé n’est pas non plus modifié directement ; une stratégie pilote distincte est utilisée pour les tests.

Choisir la fonction adaptée au besoin

Quatre fonctions aux noms proches répondent à des besoins différents :

• Access Time autorise ou bloque les utilisateurs pendant des plages horaires fixes. Il ne comptabilise aucune consommation.
• Surfing quota accorde à un utilisateur un crédit de temps consommable pour l’accès à Internet.
• Network traffic quota accorde à un utilisateur un crédit de données consommable.
• Traffic Shaping limite ou priorise la bande passante. Un faible débit n’est pas un quota de données.

Une Web Policy propose également l’action Quota pour un accès limité dans le temps à certaines catégories web. Cette Policy Quota appartient à la logique du proxy web et n’est pas la même fonction que la Surfing Quota basée sur l’utilisateur décrite ici.

Un quota ne crée ni règle de pare-feu ni identité utilisateur. Le pare-feu doit reconnaître l’utilisateur, le chemin réseau doit être autorisé et le trafic de test doit correspondre à la règle attendue. Ce n’est qu’alors que le quota peut être vérifié de manière pertinente.

Planifier l’exemple et les prérequis

L’exemple continu utilise un petit groupe pilote avec deux stratégies distinctes :

• Groupe : Quota_Pilot
• Utilisateur de test : quota-pilot
• Surfing Quota : Students_InternetTime
• Cycle type : Cyclic (repeat access)
• Cycle hours : 24
• Maximum access time : 02:00
• Network Traffic Quota : Students_DataVolume
• Restriction : Total network traffic
• Cycle type : Cyclic
• Cycle period : Day
• Quota per cycle : 5000 MB
• Maximum quota : Unlimited

Ces valeurs sont volontairement de petits exemples de documentation : chaque cycle de 24 heures fournit deux heures d’accès Internet et chaque jour 5000 MB de volume de données. Les noms, la durée, le volume, le cycle et la limite globale sont adaptés à l’accord d’utilisation réel. De petites limites de test ne doivent pas être reprises dans une stratégie de production sans en vérifier l’impact.

Avant la configuration, vérifier les points suivants :

1. L’utilisateur pilote peut se connecter avec la méthode d’authentification prévue.
2. Le nom d’utilisateur et l’adresse source apparaissent sous Current activities > Live users.
3. Pour les utilisateurs AD, le champ Group sous Authentication > Users est correct.
4. Une règle de pare-feu appropriée basée sur l’utilisateur autorise le trafic de test et active Log firewall traffic.
5. Les attributions existantes de Surfing quota, Network traffic, Access time et Traffic shaping sont documentées.
6. L’état précédent et un autre utilisateur de test sont connus.

Si l’utilisateur n’apparaît pas comme Live User, corriger d’abord l’authentification. Un quota ne peut pas attribuer de manière fiable un trafic inconnu ou traité uniquement par IP à un crédit utilisateur normal.

Créer une Surfing Quota

Une Surfing Quota comptabilise le temps Internet consommé. Dans l’aide de SFOS 22, le même objet est documenté sous Profiles > Surfing quota et sous Web > Surfing quotas. Utiliser l’entrée affichée dans WebAdmin sur le build déployé.

Choisir Cyclic ou Non-cyclic

• Cyclic (repeat access) : Le crédit de temps est de nouveau mis à disposition selon des cycles récurrents. Le temps inutilisé n’est pas reporté au cycle suivant.
• Non-cyclic (one-time access) : Le crédit de temps n’est fourni qu’une seule fois. L’utilisateur est déconnecté après l’avoir consommé.

En complément, Validity period limite le nombre de jours pendant lesquels la stratégie reste valide. Maximum access time définit le temps utilisable. Lorsque le maximum est atteint, l’utilisateur est déconnecté même si la période de validité du quota n’est pas encore expirée.

Pour l’exemple pilote :

1. Ouvrir Profiles > Surfing quota > Add. Si le build affiche la fonction sous Web > Surfing quotas, y sélectionner Add.
2. Définir Name sur Students_InternetTime.
3. Saisir par exemple Pilot: 2h per 24h, Owner IT dans Description.
4. Définir Cycle type sur Cyclic (repeat access).
5. Définir Cycle hours sur 24.
6. Définir explicitement la Validity period pour le pilote, ou sélectionner Unlimited uniquement si aucune limite d’expiration n’est nécessaire.
7. Définir Maximum access time sur 02:00.
8. Enregistrer avec Save.

La stratégie enregistrée n’a pas encore d’effet. Seule son attribution à un utilisateur ou à un groupe associe le crédit de temps à une identité.

Créer une Network Traffic Quota

Une Network Traffic Quota comptabilise le volume de données transféré. Elle ne limite pas le débit. Un utilisateur peut donc consommer son crédit rapidement ou lentement ; lorsqu’une limite de bande passante est requise, une stratégie de Traffic Shaping adaptée est planifiée en plus.

Limiter le trafic total ou séparer l’envoi et le téléchargement

• Total network traffic : Un crédit commun comptabilise ensemble l’envoi et le téléchargement.
• Individual network traffic (Upload & download) : L’envoi et le téléchargement reçoivent des limites distinctes. Ce choix ne convient que si le besoin traite réellement les deux directions séparément.

Deux modèles de cycle sont également disponibles :

• Cyclic : Le crédit s’applique à chaque cycle sélectionné. Les périodes disponibles sont Day, Week, Month et Year. Le volume inutilisé n’est pas reporté.
• Non-cyclic : Le crédit s’applique à une seule période de cycle.

Quota per cycle définit le crédit de chaque cycle. Un Maximum quota facultatif ajoute une limite globale et doit être supérieur au quota du cycle. Lorsque la limite du cycle ou la limite globale est épuisée, le pare-feu déconnecte l’utilisateur. Reset user accounting est nécessaire pour le reconnecter avant la réinitialisation normale.

Pour l’exemple pilote :

1. Ouvrir Profiles > Network traffic quota > Add.
2. Définir Name sur Students_DataVolume.
3. Saisir par exemple Pilot: 5000 MB per day, Owner IT dans Description.
4. Définir Restriction sur Total network traffic.
5. Définir Cycle type sur Cyclic.
6. Définir Cycle period sur Day.
7. Définir Quota per cycle sur 5000 MB.
8. Laisser Maximum quota sur Unlimited pour cet exemple récurrent. Si une limite globale est nécessaire, elle doit être supérieure au quota du cycle.
9. Enregistrer avec Save.

Dans cet exemple, 5000 MB correspondent à 5 GB. Dans une stratégie réelle, la valeur est dérivée du crédit approuvé et saisie dans l’unité attendue par WebAdmin. Une stratégie séparant l’envoi et le téléchargement reçoit plutôt des valeurs propres et justifiées pour chaque direction.

Attribuer les quotas à un groupe ou à un utilisateur

Utiliser un groupe comme méthode d’exploitation normale

Pour des utilisateurs ayant le même crédit, une stratégie de groupe est plus facile à exploiter qu’un grand nombre de valeurs individuelles :

1. Ouvrir Authentication > Groups.
2. Créer le groupe Quota_Pilot ou modifier un groupe pilote clairement délimité.
3. Sélectionner Students_InternetTime pour Surfing quota.
4. Sélectionner Students_DataVolume pour Network traffic.
5. Ne pas modifier au passage d’autres valeurs d’Access Time, de Traffic Shaping, de Remote Access ou de portail.
6. Enregistrer.
7. Authentifier à nouveau l’utilisateur pilote et vérifier le groupe réellement utilisé.

Gérer les groupes d’utilisateurs Sophos Firewall en sécurité explique l’interaction entre les groupes locaux et importés, le groupe principal et les exceptions utilisateur. L’importation AD proprement dite reste décrite dans Connecter Active Directory à Sophos Firewall.

Une dérogation utilisateur est prioritaire

Sous Authentication > Users, Surfing quota et Network traffic peuvent être définis différemment pour un utilisateur individuel. Ces valeurs utilisateur sont prioritaires sur la stratégie de groupe.

Si une modification de groupe n’agit pas sur un utilisateur, contrôler d’abord son objet utilisateur. Une dérogation convient à une exception documentée ou à un pilote, mais peut créer avec le temps des cas particuliers cachés. Pour revenir à la stratégie de groupe, rétablir de manière contrôlée l’état d’héritage précédent de l’utilisateur.

Seule la Main Group compte dans Active Directory

Pour les utilisateurs AD, Surfing Quota et Network Traffic n’utilisent pas les Other group memberships. La valeur applicable provient de la Main Group affichée dans le champ Group sous Authentication > Users, ou d’une stratégie explicite attribuée à l’utilisateur.

L’ordre sous Authentication > Groups > Reorder peut modifier la Main Group et donc affecter plusieurs stratégies en même temps. Il ne doit pas être changé comme correctif rapide d’un quota. Après une modification planifiée de groupe, authentifier à nouveau l’utilisateur et vérifier de nouveau la Main Group.

Les Clientless Users sont exclus

Les Clientless Users ne prennent en charge ni Surfing Quota ni Network Traffic. Pour un appareil fixe sans connexion utilisateur, le chemin réseau, le planning et, si nécessaire, le Traffic Shaping sont planifiés dans une règle de pare-feu étroite. Les quotas utilisateur ne servent pas de substitut basé sur l’IP.

Contrôler la consommation et valider la limite

View usage dans WebAdmin

Pour afficher la consommation, Sophos exige une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic activé. Ensuite :

1. Authentifier à nouveau l’utilisateur pilote.
2. Vérifier le nom d’utilisateur et l’adresse source sous Current activities > Live users.
3. Ouvrir Authentication > Users et sélectionner l’utilisateur pilote.
4. Ouvrir View usage.
5. Pour Surfing Quota, contrôler le temps attribué, l’expiration et le temps Internet consommé.
6. Pour Network Traffic, contrôler Cycle renewal, l’envoi, le téléchargement et le quota attribué.
7. Générer un petit transfert de test autorisé et contrôler de nouveau l’évolution.
8. Dans Log Viewer, corréler l’utilisateur, Source, Destination, Service, Firewall Rule ID, Action et l’horodatage.

La vue mensuelle affiche également l’IP source, le début, la fin, la durée, l’envoi et le téléchargement. Une valeur de consommation seule ne prouve toutefois pas que le chemin prévu et la bonne règle ont été utilisés. Il faut donc combiner View usage, Log Viewer et un flux de test réel. Tester proprement une règle Sophos Firewall explique la validation des règles.

Contrôle par l’utilisateur dans User Portal

Dans User Portal, sous Internet usage, un utilisateur peut contrôler, selon le type de compte et la stratégie, le temps de navigation attribué et consommé, le renouvellement du cycle ainsi que l’envoi, le téléchargement et le crédit restant. Cette visibilité réduit les demandes, mais ne remplace pas la validation administrative de l’attribution, de la Main Group, de la règle et des logs.

Tester la limite de consommation de manière contrôlée

Pour un test de limite, utiliser une stratégie pilote distincte avec un crédit volontairement faible mais suffisant. Le test ne doit toucher aucun groupe de production.

1. Documenter les valeurs initiales dans View usage.
2. Démarrer un flux de test HTTP ou HTTPS clairement limité.
3. Observer la consommation et Log Viewer pendant le test.
4. Confirmer que l’atteinte de la limite provoque la déconnexion attendue.
5. Ne pas supposer une transition à la seconde près ; le pare-feu vérifie périodiquement les autorisations.
6. Tester le cycle normal suivant ou une réinitialisation explicitement approuvée.
7. Rétablir ensuite la stratégie pilote et l’attribution précédente.

Utiliser Reset user accounting en sécurité

Reset user accounting réinitialise le temps de navigation et la consommation de trafic réseau de l’utilisateur. Lorsqu’une Network Traffic Quota est épuisée, cette réinitialisation est nécessaire si l’utilisateur doit se reconnecter avant le cycle normal suivant.

Une réinitialisation contrôlée se déroule ainsi :

1. Documenter l’utilisateur, le ticket, le motif, les valeurs actuelles des quotas et l’heure.
2. Vérifier s’il est possible d’attendre le changement de cycle normal.
3. S’assurer que le bon utilisateur est sélectionné.
4. Ouvrir l’utilisateur sous Authentication > Users.
5. Ouvrir View usage et conserver les valeurs initiales.
6. Déclencher Reset user accounting uniquement avec l’autorisation prévue.
7. Authentifier à nouveau l’utilisateur et contrôler les nouveaux compteurs.
8. Vérifier un petit flux de test, la Firewall Rule ID et les logs.

La réinitialisation ne corrige ni une Main Group incorrecte, ni une reconnaissance utilisateur absente, ni une stratégie de pare-feu ou web bloquante. Si ces causes ne sont pas clarifiées au préalable, le problème réapparaît malgré la remise à zéro des compteurs.

Délimiter les erreurs systématiquement

Le quota ne semble pas être comptabilisé

Vérifier d’abord sous Current activities > Live users si l’identité et l’adresse source attendues sont visibles. Contrôler ensuite que le trafic correspond à une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic. Si la journalisation manque ou si le flux utilise une autre règle, View usage peut rester incomplet.

Comparer ensuite la stratégie de groupe, la dérogation utilisateur et, pour AD, la Main Group. Le quota n’est pas réduit précipitamment dans le seul but de produire un effet visible.

Le quota de groupe n’agit que sur certains utilisateurs

Une stratégie explicite sur l’utilisateur est prioritaire. Sous Authentication > Users, vérifier les deux champs de quota et la Main Group. Pour AD, les Other group memberships ne sont pas évalués. Authentifier à nouveau l’utilisateur après une modification de groupe.

L’utilisateur est déconnecté de manière inattendue

Sous View usage, vérifier si Cycle quota, Maximum quota ou Maximum access time a été atteint. Contrôler ensuite séparément Access Time, Web Policy, la règle de pare-feu et l’authentification. Captive Portal peut également apparaître en raison d’identifiants incorrects ou d’autres problèmes d’authentification ; le quota n’en est pas automatiquement la cause. Configurer et tester Captive Portal sur Sophos Firewall explique le parcours de connexion complet.

La consommation ne correspond pas aux attentes

Vérifier si Total network traffic ou des limites distinctes d’envoi et de téléchargement sont configurées. Comparer ensuite les détails mensuels, l’IP source, la Firewall Rule ID et le transfert de test réel. Une Network Traffic Quota comptabilise le volume de données, pas seulement les téléchargements visibles dans le navigateur ; le trafic en arrière-plan de l’utilisateur authentifié peut aussi contribuer à la consommation.

La réinitialisation n’aide que brièvement

Si l’utilisateur est de nouveau déconnecté peu après la réinitialisation, contrôler les valeurs de la stratégie, le cycle, le maximum, la dérogation utilisateur et la consommation réelle. Le compteur n’est pas réinitialisé à plusieurs reprises avant que la cause soit comprise.

Rollback et exploitation

Un rollback contrôlé rétablit de manière traçable l’état d’héritage et les compteurs précédents :

1. Rétablir les attributions Surfing et Network Traffic précédentes pour l’utilisateur ou le groupe pilote.
2. Pour AD, authentifier à nouveau l’utilisateur et vérifier la Main Group.
3. Documenter View usage et la consommation actuelle.
4. Réinitialiser l’accounting de manière contrôlée uniquement si cela a été convenu pour le test.
5. Exécuter un petit flux de test et vérifier la Firewall Rule ID et les logs.
6. Supprimer les stratégies pilotes uniquement lorsqu’aucune dépendance d’utilisateur ou de groupe ne subsiste.
7. Mettre à jour le ticket, l’owner, les limites et le résultat du test.

En exploitation, chaque quota partagé a besoin d’un nom compréhensible, d’une Description, d’un owner et d’une justification documentée pour le cycle, le crédit et la limite globale. Les modifications sont validées avec un utilisateur pilote, un test positif de consommation et un test négatif de limite.

Liste de contrôle opérationnelle

• La consommation de temps et la consommation de données ont été planifiées séparément.
• Surfing Quota et Network Traffic Quota ont des noms et des owners compréhensibles.
• Cycle, Validity, Quota per cycle et Maximum sont justifiés.
• Les stratégies sont attribuées au bon groupe ou au bon utilisateur.
• Les dérogations utilisateur ont été contrôlées.
• Pour AD, la Main Group est correcte ; les Other group memberships ne sont pas supposés.
• Les Clientless Users ne sont pas planifiés avec des quotas utilisateur.
• L’utilisateur pilote apparaît comme Live User.
• La règle de pare-feu basée sur l’utilisateur journalise le trafic de test.
• View usage, User Portal, Firewall Rule ID et la consommation réelle concordent.
• Reset user accounting est utilisé uniquement avec documentation et autorisation.
• L’état précédent et le rollback sont documentés.

Questions fréquentes