Configurer l'accès support Avanet sur Sophos Firewall

Pour les cas de support, les changements planifiés ou une analyse d’erreur conjointe, il peut être judicieux de donner temporairement accès à une Sophos Firewall à Avanet. Cet accès ne doit cependant pas être accordé en rendant WebAdmin ou SSH accessibles depuis Internet. Il est préférable d’avoir un accès support clairement défini avec un utilisateur administrateur dédié, une source définie et une documentation du retrait.

Ce guide décrit une procédure typique pour l’accès via HTTPS/WebAdmin et éventuellement SSH. Pour les bases générales des services locaux de la firewall, consultez également Device Access et Local Service ACL sur Sophos Firewall. Si SSH est utilisé, il est également important de connaître Connecter Sophos Firewall via SSH.

⚠️ Un accès support est un accès administratif à la firewall. Il ne doit être actif que pour la durée nécessaire, être aussi limité que possible à la source de support, et être vérifié ou retiré après la fin du cas.

Clarifier avant la configuration

Avant de donner l’accès, il est important de savoir quel accès est réellement nécessaire. Pour de nombreuses tâches, HTTPS/WebAdmin suffit. SSH ne doit être activé que si les fichiers journaux, CLI ou Advanced Shell sont vraiment nécessaires. De plus, il doit être clair de quelle source l’accès sera autorisé, quand l’accès sera retiré et si une sauvegarde actuelle est disponible avant les modifications majeures.

Si un compte administrateur ou partenaire général existe déjà, il ne faut pas simplement créer un autre compte permanent. Dans de tels cas, il est généralement préférable de vérifier l’accès existant, de contrôler MFA et les rôles, et de n’autoriser temporairement que la source.

Modèle de sécurité pour l’accès support

Un accès support ne doit pas être traité comme un compte permanent normal. C’est un accès opérationnel qui doit être clair, limité et facile à supprimer après le cas de support.

Variantes possibles :

• Utilisateur temporaire avanet : utile lorsqu’un rendez-vous support est prévu et que l’accès doit être supprimé ensuite.
• Admin support dédié : utile si le support est régulier, mais uniquement avec mot de passe fort, MFA et sources d’accès limitées.
• Activation temporaire de SSH ou WebAdmin : utile pour une fenêtre de troubleshooting précise, mais doit ensuite être désactivée ou restreinte.
• Accès via Sophos Central ou session distante : utile lorsqu’aucun accès management entrant direct ne doit être ouvert.

L’essentiel est que l’accès, la méthode d’authentification, la restriction des sources et le retour arrière soient définis avant le rendez-vous. Pour les changements sur des firewalls productifs, il faut aussi savoir qui approuve la modification et où elle est documentée. Pour les traces d’audit, les configuration audit logs et, pour les changements plus importants, Config Studio sont des sujets utiles.

Définir mot de passe, MFA et canal de remise

L’accès technique n’est qu’une partie de la préparation du support. La remise des identifiants et la protection de l’accès sont tout aussi importantes.

• Utiliser un mot de passe unique uniquement pour cette firewall et cet accès support.
• Ne pas envoyer le mot de passe avec tous les détails d’accès dans le même canal.
• Activer MFA si le compte reste actif plus longtemps ou permet l’accès WebAdmin.
• Documenter si l’accès est temporaire ou permanent.
• Définir qui désactive ou supprime le compte après le cas de support.
• Si SSH est nécessaire, préférer l’authentification par public key lorsque possible.

Pour les comptes admin, MFA pour Sophos Firewall est l’article complémentaire. Pour SSH, la méthode par public key est préférable lorsqu’elle convient au workflow support.

Ajouter l’utilisateur avanet

L’utilisateur avanet est destiné à l’accès WebAdmin. Cela permet de mieux retracer dans l’Audit Trail qu’une modification a été effectuée dans le cadre d’un cas de support. L’utilisateur doit recevoir un mot de passe fort et ne rester actif que le temps nécessaire.

1. Ouvrez Authentication dans la navigation de gauche.
2. Sélectionnez Users.
3. Cliquez sur Add.

Valeurs typiques :

• Username : avanet
• Full name : Avanet
• Profile : Administrator, si Avanet doit examiner ou modifier complètement la firewall
• Password : mot de passe fort unique ou de support provenant d’un gestionnaire de mots de passe
• Email : par exemple service@avanet.com

Ensuite, enregistrez avec Save ou Add.

Si seules des tâches très limitées sont prévues, un profil administrateur plus restreint peut être plus approprié. Pour de nombreux cas de support, Avanet a cependant besoin temporairement de droits complets, car la cause, les journaux, les règles, NAT, VPN, le routage et l’état du système doivent souvent être examinés ensemble.

Créer un hôte FQDN pour support.avanet.com

Pour que la règle ACL ne s’applique pas à des sources Internet quelconques, un objet hôte pour la source de support Avanet est d’abord créé.

1. Ouvrez Hosts and services.
2. Sélectionnez FQDN hosts.

Ensuite, ajoutez un nouvel objet FQDN :

• Name : support.avanet.com
• FQDN : support.avanet.com
• Description : Accès support Avanet

Enregistrez avec Save. La firewall résout le FQDN via DNS et utilise ensuite l’objet comme source dans la règle ACL locale.

Configurer une règle d’exception ACL de service local

Les accès à WebAdmin et SSH sont des services locaux de la firewall. Ils ne sont pas gérés par des règles de firewall normales, mais par Administration > Device access et Local service ACL exception rule.

1. Ouvrez Administration.
2. Sélectionnez Device access.
3. Faites défiler jusqu’à la section Local service ACL exception rule.
4. Cliquez sur Add.

La règle doit être aussi restreinte que possible :

• Rule name: Avanet Support
• Rule position: adapté à la structure ACL existante, souvent Bottom
• IP version: IPv4, ou IPv6 en plus, si explicitement nécessaire
• Source zone: Zone d’où provient l’accès support, souvent WAN
• Source Network / Host: Objet FQDN support.avanet.com
• Destination host: Any ou spécifiquement l’adresse de la firewall, selon l’environnement
• Services: HTTPS; SSH uniquement si vraiment nécessaire
• Action: Accept

Ensuite, enregistrez et vérifiez la position de la règle. Si une règle de rejet ou d’exception plus large se trouve au-dessus, la nouvelle règle peut être inefficace.

⚠️ Any comme source n’est pas une bonne autorisation de support pour WebAdmin ou SSH. Si la source n’est pas définie, il faut d’abord clarifier avec Avanet quelle source de support sera utilisée. Une autorisation large augmente immédiatement la surface d’attaque de la firewall.

Optionnel : Enregistrer la clé publique SSH

SSH n’est nécessaire que si une analyse via Device Console, fichiers journaux ou Advanced Shell est nécessaire. Pour de nombreux cas de support, WebAdmin suffit.

Il est important de faire la distinction : l’utilisateur avanet précédemment créé est un utilisateur WebAdmin. L’accès SSH à Sophos Firewall se fait généralement avec l’utilisateur admin. La clé publique SSH est donc enregistrée dans la section Public key authentication for admin.

1. Ouvrez Administration.
2. Sélectionnez Device access.
3. Faites défiler jusqu’à la section Public key authentication for admin.
4. Activez Enable authentication si l’authentification par clé publique n’est pas encore active.
5. Ajoutez la clé publique fournie par Avanet sous Authorized keys.
6. Enregistrez.

Exemple de clé publique Avanet :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCktco/uC29KdU+Hf7GjcYXFumGJvt11MPxhdpnYA2XVEbnsI9r/XrW9J9K2ugvVGNoOD4IlN/bWZ1z3W6UqFKGgHUYkQu2h+0PFzP5I12Pu9I/3qIWwOhdA2j523FzneGQFptNCHHLQwma/zYJJwcVqsiJo/mg6W8jUbS30jFP6zDJvGRzbA2ATC7XzGNfa/CYr/AKoqdvm87RThOT7uh86w39x9VQTZH7d217K2UVuUrSppvnRaw5NCwukamWDDs8EtsVIFNkkxMl/SdJTC1SOSfO6mw8erXm1RhmNT5+wN/87f+DQioQPuWSrC3EHkgqw9BjoU3aLtYUw9AAItf6jJeUnZBfBCeJ1fJAzYpR8STdbaI8RXP1QMOr4omtmCakfnEH8kZ1BAYXxVzrJBXQ+sDVLZtWNDPqg8jIpdJ6bRNk/m7B+LAwsofHVLH1VSxoOEYdJGQvPfwonqo2JR+vosYhoHG89eh5EL/X9z5amvfVCShf6icstYwmaUmT/9lUTd8tkJZeTxNoezyspHhMryfB93653vb6wPS/n0ITkfu6rSfSrE1A1Y1dD5QtsFF6oEZxPqo8qQajtGhI3vZdHZSx53PqFqInra75xFHc+EjEsoLjt2wQdHr+ttEKvfrjfQmyXaWzqqE6bxmbbcMPtqY+pzMf83nEGwepJka0uw==

La clé privée n’est pas stockée sur la firewall et ne doit jamais être transmise par e-mail ou chat. Sur la firewall, seule la clé publique doit être placée dans le champ des clés autorisées.

Tester l’accès

Après l’enregistrement, l’accès ne doit pas être considéré comme terminé sans test. Un court test de fonctionnalité est judicieux :

1. Testez l’accès WebAdmin via la source de support Avanet convenue.
2. Vérifiez la connexion avec l’utilisateur avanet.
3. Si SSH est nécessaire : testez la connexion avec admin et la clé publique.
4. Dans le Log viewer et éventuellement dans l’Audit Trail, vérifiez si la connexion et les modifications ultérieures sont traçables.
5. Documentez quand l’accès sera désactivé ou retiré.

Si l’accès ne fonctionne pas, vérifiez d’abord la source et la règle ACL. Ensuite, contrôlez la résolution DNS de l’objet FQDN, la position de la règle, Device Access, les appareils NAT en amont et le routage.

Retirer l’accès après le cas de support

Après la fin du cas de support, l’accès ne doit pas rester inchangé de manière permanente. Selon l’accord, il existe trois options propres :

• Désactiver l’utilisateur: Si un support ultérieur est prévu, mais qu’aucun accès n’est actuellement nécessaire.
• Désactiver la règle ACL: Si le compte doit rester, mais qu’aucun accès externe ne doit être possible.
• Supprimer l’utilisateur et la règle ACL: Si l’accès n’était nécessaire qu’une seule fois.

Il convient également de vérifier si une clé publique SSH peut être retirée. Si des modifications ont été apportées à la firewall, Backup et Restore sur Sophos Firewall, Audit Trail Logs et en cas de modifications des règles Config Studio sont appropriés pour un contrôle ultérieur.

Liste de contrôle

• Utilisateur avanet créé avec un mot de passe fort.
• Profil administrateur choisi et documenté consciemment.
• Hôte FQDN support.avanet.com créé.
• Règle d’exception ACL de service local limitée à la source de support Avanet.
• Seuls les services nécessaires autorisés : HTTPS, SSH uniquement si besoin.
• Clé publique SSH enregistrée uniquement dans la section Public key authentication for admin.
• Accès testé et documenté dans le ticket.
• Retrait ou désactivation planifié après la fin.

Questions fréquentes