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.

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.

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

L’utilisateur local avanet est exclusivement destiné à la console WebAdmin. Un utilisateur dédié permet de mieux attribuer les modifications dans l’Audit Trail que l’utilisation partagée du compte administrateur par défaut.

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.

Les valeurs habituelles sont Username avanet, Name Avanet et Email support@avanet.local. Le profil Administrator donne un accès complet aux fonctions WebAdmin et CLI. Il ne doit être utilisé que si le dossier exige réellement ces droits. Pour une tâche clairement limitée, il est préférable de créer sous Profiles > Device access un profil personnalisé avec les droits Read-only ou Read-write nécessaires.

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 ne reste pas durablement dans un e-mail ou le texte du ticket. Si la MFA pour les administrateurs est utilisée, l’enrôlement du jeton, sa transmission et la responsabilité de sa réinitialisation sont clarifiés avant le rendez-vous. Un bref test de connexion évite que des problèmes de mot de passe, de rôle ou de MFA ne consomment la fenêtre de maintenance.

Limiter la source de support et la Local Service ACL

Ajouter un hôte FQDN pour support.avanet.com

La Local Service ACL accepte les hôtes FQDN comme sources. Une modification contrôlée de l’adresse IP de sortie d’Avanet n’exige donc pas une adaptation manuelle de chaque pare-feu. Le pare-feu utilise les adresses résolues par DNS jusqu’à l’expiration du TTL DNS. Les FQDN avec caractères génériques ne sont pas pris en charge dans les Local Service ACL exception rules.

1. Ouvrir Hosts and services > FQDN host.
2. Sélectionner Add.
3. Régler Name et FQDN sur support.avanet.com.
4. Sélectionner Save.

Avant de poursuivre, vérifier que support.avanet.com correspond à l’adresse IP publique du support indiquée dans le ticket. Si l’adresse IP de sortie réelle ne correspond pas au résultat DNS, l’ACL refusera correctement l’accès.

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 : objet FQDN support.avanet.com
• 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 :

• support.avanet.com correspond-il à l’adresse IP publique de sortie réelle ?
• 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 de configuration effectuées avec avanet.
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 l’utilisateur avanet si aucun accès partenaire permanent n’a été convenu.
4. Désactiver ou supprimer la Local Service ACL exception rule.
5. Supprimer la clé publique SSH propre au dossier.
6. Vérifier depuis l’ancienne source de support que WebAdmin et SSH ne sont plus accessibles.

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