Configurer l'accès support Avanet sur Sophos Firewall

Pour une demande de support, Avanet peut avoir temporairement besoin d’un accès direct à la console WebAdmin d’une Sophos Firewall. Cet accès n’est sûr que s’il est limité à une source de support connue, au service requis et à une période définie. Les autorisations WAN globales pour HTTPS et SSH restent désactivées ; l’accès passe par une Local service ACL exception rule ciblée.

Dans de nombreux cas, un partage d’écran ou un accès partenaire existant et contrôlé suffit. Un nouvel accès WAN direct n’est pertinent que si Avanet doit analyser le problème ou effectuer des modifications de manière autonome. SSH n’est ajouté que si la Device Console, l’Advanced Shell ou les fichiers journaux sont nécessaires.

Device Access et Local Service ACL sur Sophos Firewall présente les bases techniques. Une sauvegarde Sophos Firewall récente doit également être disponible avant toute modification.

Important : l’accès support est un accès administratif au pare-feu. L’utilisateur, la règle ACL et la clé SSH doivent être désactivés ou supprimés après la clôture du dossier, sauf si un accès permanent a été convenu.

Diagnostics > Support access ne remplace pas cette procédure. Cette fonction génère un identifiant temporaire exclusivement destiné à Sophos Support, qui peut alors accéder à WebAdmin et au shell sans identifiants administrateur. Cet identifiant ne doit pas être transmis à Avanet.

Définir l’accès et sa durée

Avant la configuration, consigner dans le ticket :

• les opérations qu’Avanet est autorisée à effectuer ;
• si WebAdmin suffit ou si SSH est également nécessaire ;
• la date de début et de fin de l’accès ;
• la source de support Avanet utilisée ;
• la personne qui autorise l’accès et contrôle son retrait.

Avanet doit indiquer dans le ticket authentifié l’adresse IP publique de sortie exacte ou un FQDN explicitement prévu à cet effet. Il ne faut ni déduire la source d’un site web ni la deviner. Avant toute modification, ouvrir et tester un accès de secours indépendant par la console, le LAN d’administration, un VPN d’administration ou Sophos Central.

Un accès Avanet ou partenaire existant ne doit pas être complété par un second compte permanent. Il faut plutôt vérifier le profil, la MFA, la restriction de source et l’état du compte existant. Pour une analyse conjointe sans connexion directe, le partage d’écran est souvent l’option la moins risquée.

Configurer l’utilisateur WebAdmin

Configurer les administrateurs et profils Sophos Firewall en toute sécurité présente la procédure générale pour les comptes personnels, les profils, la MFA et l’offboarding. Cette section ajoute le cas propre au support, avec une plage horaire, une source de support et un retrait contrôlé.

Un compte local propre au dossier, par exemple avanet-<ticket>, est exclusivement destiné à WebAdmin. Il facilite l’attribution des modifications dans l’Audit Trail. SFOS enregistre le nom d’utilisateur en minuscules et celui-ci ne peut plus être modifié.

1. Ouvrir Authentication > Users.
2. Sélectionner Add.
3. Saisir le nom d’utilisateur et le nom d’affichage.
4. Régler User type sur Administrator.
5. Choisir un Profile adapté.
6. Saisir une adresse e-mail et un mot de passe fort réservé à cet accès.

Pour Username, utiliser par exemple avanet-<ticket> en remplaçant <ticket> par le numéro interne. Ce guide ne publie volontairement ni mot de passe ni adresse de support. Le profil Administrator donne un accès WebAdmin complet et ne convient que si le mandat l’exige. Sinon, créer sous Profiles > Device access un profil qui commence en Read-only, avec Read-write uniquement pour les menus nécessaires aux modifications autorisées.

Deux restrictions supplémentaires sont disponibles sous Administrator advanced settings :

• Schedule for device access : autorise la connexion à la console WebAdmin uniquement pendant la plage sélectionnée.
• Login restriction for device access : autorise la connexion uniquement depuis certaines adresses IPv4 ou une plage IPv4.

Si l’adresse IP fixe du support est connue, il faut également l’ajouter comme Login restriction for device access. La Local Service ACL limite alors l’accessibilité de la console, tandis que la restriction utilisateur limite en plus la connexion de ce compte. Sélectionner Save.

Tester le mot de passe et la MFA à l’avance

Le mot de passe est transmis par un canal sécurisé convenu et n’est pas placé dans un e-mail ou le ticket. Sous Authentication > Multi-factor authentication, sélectionner Specific users and groups pour l’OTP, ajouter le compte du dossier, puis activer Web admin console sous Require MFA for. Clarifier l’enrôlement et la réinitialisation avant le rendez-vous ; le secret, le QR code et les codes à usage unique ne doivent pas figurer dans le ticket. Si la MFA n’est techniquement pas possible, utiliser un partage d’écran ou un VPN plutôt que de l’omettre. Voir MFA pour les administrateurs.

Limiter la source de support et la Local Service ACL

Créer l’objet source confirmé dans le ticket

Pour une courte fenêtre de maintenance, un hôte IP contenant exactement l’adresse de sortie confirmée offre la surface de confiance la plus faible. Si le ticket désigne explicitement un FQDN de support, la Local Service ACL accepte aussi un hôte FQDN. Le pare-feu fait alors confiance à toutes les adresses résolues jusqu’à l’expiration du TTL DNS ; les FQDN génériques ne sont pas pris en charge.

1. Pour une IP fixe, ouvrir Hosts and services > IP host, sélectionner Add et enregistrer l’adresse confirmée comme hôte IPv4 unique.
2. Uniquement pour un FQDN confirmé, ouvrir Hosts and services > FQDN host et sélectionner Add.
3. Saisir un Name propre au dossier et recopier exactement dans FQDN la valeur du ticket.
4. Sélectionner Save, puis rouvrir l’objet pour le contrôler.

Pour un FQDN, comparer toutes les adresses résolues avec le ticket. Toute adresse inattendue ou non confirmée impose l’arrêt : utiliser l’IP unique confirmée ou demander une clarification à Avanet.

Créer la Local Service ACL exception rule

HTTPS et SSH sont des services locaux du pare-feu. Les règles de pare-feu ordinaires ne contrôlent pas ce trafic. L’accès se configure donc sous Administration > Device access.

1. Ouvrir Administration > Device access.
2. Sous Local service ACL, vérifier que HTTPS et SSH ne sont pas globalement activés pour WAN.
3. Faire défiler jusqu’à Local service ACL exception rule et sélectionner Add.
4. Créer la règle avec les valeurs suivantes.

• Rule name : Avanet-Support
• Rule position : Top
• Description : numéro du ticket, objet et date de fin prévue
• IP version : IPv4
• Source zone : WAN
• Source Network / Host : exactement l’objet IP ou FQDN confirmé
• Destination host : adresse publique du pare-feu, ou Any si plusieurs adresses WAN applicables doivent être joignables
• Services : HTTPS ; SSH uniquement si le besoin est confirmé ; Ping/Ping6 uniquement pour un diagnostic précis
• Action : Accept

Sélectionner Save. La position Top garantit que l’autorisation ciblée est évaluée avant une règle Drop chevauchante. Les autres règles d’exception doivent néanmoins être contrôlées : une règle Accept plus large placée au-dessus ou une zone source incorrecte peut modifier le modèle de sécurité prévu.

À ne pas utiliser : Any ou 0.0.0.0 comme source. Sophos empêche à juste titre un accès WAN global à la console WebAdmin. La case WAN pour HTTPS ou SSH ne doit pas non plus être activée pour cette procédure.

Ajouter SSH uniquement si nécessaire

SSH donne accès à la Device Console et à l’Advanced Shell et va donc bien plus loin qu’un profil WebAdmin restreint. Dans de nombreux cas, Services reste limité à HTTPS.

L’utilisateur avanet ne peut pas être utilisé pour SSH. Sophos Firewall n’accepte que l’utilisateur par défaut admin pour l’accès CLI. La clé publique est donc enregistrée globalement sous Public key authentication for admin, et non sur l’utilisateur avanet.

1. Ouvrir Administration.
2. Sélectionner Device access.
3. Faire défiler jusqu’à Public key authentication for admin.
4. Activer Enable authentication.
5. Coller sous Authorized keys la clé publique confirmée pour le dossier actuel et l’ajouter avec le bouton plus.
6. Sélectionner Apply.

Seul l’administrateur par défaut peut ajouter ou supprimer des clés SSH ; Apply n’apparaît pas pour les administrateurs personnalisés. Sophos prend en charge les clés RSA d’au moins 2048 bits ainsi que certaines clés DSA et ECDSA, mais pas ED25519. Il convient d’utiliser une clé moderne, suffisamment forte et compatible avec le client SSH utilisé.

Une clé publique a par exemple la structure suivante :

ssh-rsa <base64-public-key> avanet-support-<ticket>

La clé privée reste chez le technicien de support et n’est jamais stockée sur le pare-feu. Après la clôture du dossier, supprimer la clé publique propre au dossier et SSH de la règle d’exception, sauf si un accès permanent a été convenu. Se connecter à Sophos Firewall via SSH décrit la connexion pratique.

Tester l’accès et diagnostiquer les erreurs

Une connexion réussie depuis la source autorisée ne suffit pas. Il faut également vérifier que l’accès reste bloqué depuis une autre source Internet.

1. Ouvrir WebAdmin depuis la source de support Avanet convenue avec le port administrateur configuré. Le port par défaut est TCP 4444, mais il peut avoir été modifié sous Administration > Admin and user settings.
2. Se connecter avec avanet et vérifier que le profil choisi donne accès aux menus nécessaires.
3. Tester depuis une seconde source Internet non autorisée. La console WebAdmin ne doit pas y être accessible.
4. Si SSH a été autorisé, tester la connexion avec admin et la clé privée propre au dossier. SSH par mot de passe n’est pas nécessaire pour ce test.
5. Contrôler les événements d’authentification dans Log viewer. Vérifier séparément les modifications de configuration dans l’Audit Trail.
6. Documenter le résultat et l’heure de fin de l’accès dans le ticket.

Si WebAdmin n’est pas accessible

Commencer par la source et progresser vers le pare-feu :

• L’adresse IP de sortie réelle correspond-elle à l’objet source et, pour un FQDN, à sa résolution DNS actuelle ?
• La connexion arrive-t-elle réellement par la zone choisie sous Source zone ?
• L’adresse WAN appelée correspond-elle à Destination host ?
• La règle d’exception est-elle placée sur Top et contient-elle HTTPS ?
• Le bon port WebAdmin est-il utilisé ?
• Un routeur opérateur, un équipement NAT en amont ou une ACL en amont bloque-t-il l’accès ?
• Login restriction for device access autorise-t-elle la connexion TCP mais refuse-t-elle la connexion de l’utilisateur ?

Ne pas activer les autorisations WAN globales pour HTTPS ou SSH pendant le diagnostic. Une règle d’exception correctement configurée n’en a pas besoin pour cet accès ciblé.

Si la connexion échoue

Si la console est accessible mais que la connexion échoue, contrôler l’état de l’utilisateur, le mot de passe, la MFA, le profil, Schedule for device access, Login restriction for device access et les paramètres Block login globaux sous Administration > Admin and user settings. Après plusieurs échecs, Sophos Firewall peut temporairement bloquer l’adresse IP source pour tous les services de connexion.

Retirer l’accès de manière contrôlée

Après le dossier de support, contrôler séparément les modifications convenues et l’accès lui-même :

1. Vérifier dans l’Audit Trail les modifications effectuées avec le compte du dossier et annuler séparément celles qui ne doivent pas subsister.
2. Pour des changements importants du jeu de règles, Sophos Firewall Config Studio peut faciliter la comparaison avant-après.
3. Désactiver ou supprimer d’abord la Local Service ACL exception rule afin de fermer le chemin externe.
4. Vérifier depuis l’ancienne source que WebAdmin et SSH ne sont plus accessibles, tandis que l’accès d’administration indépendant fonctionne encore.
5. Supprimer uniquement la clé SSH du dossier ; ne désactiver Enable authentication que si aucune autre clé n’en dépend.
6. Désactiver ou supprimer le compte du dossier et son jeton MFA, sauf accès permanent explicitement approuvé.
7. Faire comparer par une seconde personne l’ACL, le compte, les clés, l’Audit Trail et le ticket avec l’état initial.

Un accès partenaire volontairement conservé exige toujours une MFA, une source strictement limitée, un responsable et un contrôle régulier. Un ticket inactif ne justifie pas un accès de gestion ouvert en permanence.

Questions fréquentes