Configurare l'accesso di supporto Avanet su Sophos Firewall

Per casi di supporto, modifiche pianificate o un’analisi congiunta dei problemi, può essere utile concedere temporaneamente ad Avanet l’accesso a una Sophos Firewall. Tuttavia, questo accesso non dovrebbe essere ottenuto rendendo WebAdmin o SSH generalmente accessibili da Internet. È preferibile un accesso di supporto chiaramente limitato con un proprio utente amministratore, una fonte definita e una documentazione della rimozione.

Questa guida descrive un tipico processo per l’accesso tramite HTTPS/WebAdmin e, facoltativamente, SSH. Per le basi generali sui servizi firewall locali, si può fare riferimento anche a Device Access e Local Service ACL su Sophos Firewall. Se si utilizza SSH, è utile conoscere anche Collegarsi a Sophos Firewall tramite SSH.

⚠️ Un accesso di supporto è un accesso amministrativo al firewall. Dovrebbe essere attivo solo per il periodo necessario, limitato il più possibile alla fonte di supporto e, una volta concluso il caso, dovrebbe essere verificato o rimosso.

Chiarire prima della configurazione

Prima di concedere l’accesso, è importante chiarire brevemente quale accesso è realmente necessario. Per molte attività è sufficiente HTTPS/WebAdmin. SSH dovrebbe essere attivato solo se sono realmente necessari file di log, CLI o Advanced Shell. Inoltre, dovrebbe essere chiaro da quale fonte è consentito l’accesso, quando l’accesso verrà rimosso e se è disponibile un backup aggiornato prima di apportare modifiche significative.

Se esiste già un account amministratore o partner generale, non dovrebbe semplicemente essere creato un altro account permanente. In tali casi, è spesso meglio verificare l’accesso esistente, controllare MFA e ruoli e consentire temporaneamente solo la fonte.

Modello di sicurezza per l’accesso di supporto

Un accesso di supporto non dovrebbe essere trattato come un normale account permanente. È un accesso operativo che deve essere chiaro, limitato e facile da rimuovere dopo il caso di supporto.

Varianti possibili:

• Utente temporaneo avanet: utile quando è pianificato un appuntamento di supporto e l’accesso deve essere rimosso dopo.
• Admin di supporto dedicato: utile quando il supporto è regolare, ma solo con password forte, MFA e sorgenti di accesso limitate.
• Attivazione temporanea di SSH o WebAdmin: utile per una finestra di troubleshooting specifica, ma poi va disattivata o limitata di nuovo.
• Accesso tramite Sophos Central o sessione remota: utile quando non si vuole aprire un accesso management inbound diretto.

È importante definire prima dell’appuntamento accesso, metodo di autenticazione, restrizione delle sorgenti e rollback. Per modifiche su firewall produttivi deve essere chiaro anche chi approva la modifica e dove viene documentata. Per audit trail sono utili i configuration audit logs e, per modifiche più ampie, Config Studio.

Definire password, MFA e canale di consegna

L’accesso tecnico è solo una parte della preparazione al supporto. Altrettanto importante è come vengono consegnate le credenziali e come viene protetto l’accesso.

• Usare una password unica solo per questo firewall e questo accesso di supporto.
• Non inviare password e tutti i dettagli di accesso nello stesso canale.
• Attivare MFA se l’account rimane attivo più a lungo o permette accesso WebAdmin.
• Documentare se l’accesso è temporaneo o permanente.
• Definire chi disattiva o elimina l’account dopo il caso di supporto.
• Se serve SSH, preferire l’autenticazione con public key quando possibile.

Per gli account admin, MFA per Sophos Firewall è l’articolo di approfondimento più adatto. Per SSH, il metodo con public key è preferibile se si adatta al workflow di supporto.

Aggiungere l’utente avanet

L’utente avanet è destinato all’accesso WebAdmin. Ciò consente di tracciare meglio nel Audit Trail che una modifica è avvenuta nell’ambito di un caso di supporto. L’utente dovrebbe ricevere una password forte e rimanere attivo solo per il tempo necessario.

1. Aprire Authentication nella navigazione a sinistra.
2. Selezionare Users.
3. Fare clic su Add.

Valori tipici:

• Username: avanet
• Full name: Avanet
• Profile: Administrator, se Avanet deve esaminare o modificare completamente il firewall
• Password: password forte una tantum o di supporto da un gestore di password
• Email: ad esempio service@avanet.com

Quindi salvare con Save o Add.

Se sono pianificate solo attività molto limitate, un profilo amministrativo più ristretto può essere più appropriato. Tuttavia, per molti casi di supporto, Avanet ha bisogno temporaneamente di diritti completi, poiché causa, log, regole, NAT, VPN, routing e stato del sistema devono spesso essere esaminati insieme.

Creare un host FQDN per support.avanet.com

Per evitare che la regola ACL si applichi a fonti Internet generiche, viene prima creato un oggetto host per la fonte di supporto Avanet.

1. Aprire Hosts and services.
2. Selezionare FQDN hosts.

Quindi aggiungere un nuovo oggetto FQDN:

• Name: support.avanet.com
• FQDN: support.avanet.com
• Description: Accesso di supporto Avanet

Salvare con Save. Il firewall risolve il FQDN tramite DNS e utilizza l’oggetto come fonte nella regola ACL locale.

Configurare la regola di eccezione Local Service ACL

Gli accessi a WebAdmin e SSH sono servizi locali del firewall. Non sono gestiti da regole firewall normali, ma da Administration > Device access e Local service ACL exception rule.

1. Aprire Administration.
2. Selezionare Device access.
3. Scorrere fino alla sezione Local service ACL exception rule.
4. Fare clic su Add.

La regola dovrebbe essere impostata il più strettamente possibile:

• Rule name: Avanet Support
• Rule position: adatta alla struttura ACL esistente, spesso Bottom
• IP version: IPv4, o anche IPv6 se espressamente necessario
• Source zone: Zona da cui proviene l’accesso di supporto, spesso WAN
• Source Network / Host: Oggetto FQDN support.avanet.com
• Destination host: Any o specificamente l’indirizzo del firewall, a seconda dell’ambiente
• Services: HTTPS; SSH solo se realmente necessario
• Action: Accept

Quindi salvare e verificare la posizione della regola. Se sopra c’è una regola di rifiuto o eccezione più ampia, la nuova regola potrebbe essere inefficace.

⚠️ Any come fonte non è una buona autorizzazione di supporto per WebAdmin o SSH. Se la fonte non è chiara, è meglio chiarire prima con Avanet quale fonte di supporto verrà utilizzata. Un’autorizzazione ampia aumenta immediatamente la superficie di attacco del firewall.

Opzionale: Memorizzare la chiave pubblica SSH

SSH è necessario solo se è richiesta un’analisi tramite Device Console, file di log o Advanced Shell. Per molti casi di supporto, WebAdmin è sufficiente.

È importante la distinzione: l’utente avanet creato in precedenza è un utente WebAdmin. L’accesso SSH a Sophos Firewall avviene solitamente con l’utente admin. La chiave pubblica SSH viene quindi memorizzata nella sezione Public key authentication for admin.

1. Aprire Administration.
2. Selezionare Device access.
3. Scorrere fino alla sezione Public key authentication for admin.
4. Attivare Enable authentication, se l’autenticazione con chiave pubblica non è ancora attiva.
5. Aggiungere la chiave pubblica fornita da Avanet sotto Authorized keys.
6. Salvare.

Esempio di chiave pubblica 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 chiave privata non viene memorizzata sul firewall e non dovrebbe mai essere condivisa tramite e-mail o chat. Sul firewall, solo la chiave pubblica deve essere inserita nel campo per le chiavi autorizzate.

Testare l’accesso

Dopo aver salvato, l’accesso non dovrebbe essere considerato completato senza un test. È utile un breve test di funzionalità:

1. Testare l’accesso WebAdmin tramite la fonte di supporto Avanet concordata.
2. Verificare l’accesso con l’utente avanet.
3. Se è necessario SSH: testare la connessione con admin e chiave pubblica.
4. Nel Log viewer e, se necessario, nel Audit Trail verificare se l’accesso e le modifiche successive sono tracciabili.
5. Documentare quando l’accesso verrà disattivato o rimosso.

Se l’accesso non funziona, controllare prima la fonte e la regola ACL. Quindi verificare la risoluzione DNS dell’oggetto FQDN, la posizione della regola, Device Access, dispositivi NAT a monte e routing.

Rimuovere l’accesso dopo il caso di supporto

Dopo la conclusione del caso di supporto, l’accesso non dovrebbe rimanere invariato in modo permanente. A seconda dell’accordo, ci sono tre opzioni pulite:

• Disattivare l’utente: Se è previsto ulteriore supporto in futuro, ma attualmente non è necessario alcun accesso.
• Disattivare la regola ACL: Se l’account deve rimanere, ma non deve essere possibile alcun accesso esterno.
• Rimuovere utente e regola ACL: Se l’accesso è stato necessario solo una volta.

Inoltre, dovrebbe essere verificato se una chiave pubblica SSH può essere rimossa. Se sono state apportate modifiche al firewall, Backup e Restore su Sophos Firewall, Audit Trail Logs e, in caso di modifiche alle regole, Config Studio sono utili per il controllo successivo.

Lista di controllo

• Creato utente avanet con password forte.
• Profilo amministrativo scelto e documentato consapevolmente.
• Creato host FQDN support.avanet.com.
• Regola di eccezione Local Service ACL limitata alla fonte di supporto Avanet.
• Consentiti solo i servizi necessari: HTTPS, SSH solo se necessario.
• Chiave pubblica SSH memorizzata solo nella sezione Public key authentication for admin.
• Accesso testato e documentato nel ticket.
• Pianificata la rimozione o disattivazione dopo la conclusione.

Domande frequenti