Configurare l'accesso al supporto Avanet su Sophos Firewall

Per un intervento di supporto, Avanet può avere temporaneamente bisogno di accedere direttamente alla console WebAdmin di Sophos Firewall. Questo accesso è sicuro solo se viene limitato a una sorgente di supporto nota, al servizio necessario e a un periodo ben definito. Le autorizzazioni globali WAN per HTTPS e SSH rimangono disattivate; l’accesso viene consentito tramite una Local service ACL exception rule specifica.

In molti casi sono sufficienti la condivisione dello schermo o un accesso partner esistente e controllato. Un nuovo accesso diretto dalla WAN è opportuno solo se Avanet deve eseguire autonomamente analisi o modifiche. SSH viene aggiunto soltanto quando sono necessari Device Console, Advanced Shell o file di log.

Le basi tecniche sono illustrate in Device Access e Local Service ACL su Sophos Firewall. Prima di apportare modifiche deve inoltre essere disponibile un backup aggiornato di Sophos Firewall.

Importante: l’accesso al supporto è un accesso amministrativo al firewall. Utente, regola ACL e chiave SSH devono essere disattivati o rimossi al termine dell’intervento, salvo che sia stato concordato un accesso permanente.

Diagnostics > Support access non sostituisce questa procedura: genera un Access ID temporaneo esclusivamente per Sophos Support, che può accedere a WebAdmin e alla shell senza credenziali amministrative. Non condividere questo ID con Avanet.

Definire accesso e periodo

Prima della configurazione, nel ticket vengono registrati:

• le attività che Avanet è autorizzata a svolgere,
• se WebAdmin è sufficiente o se serve anche SSH,
• l’ora di inizio e di fine dell’accesso,
• la sorgente di supporto Avanet utilizzata,
• chi approva l’accesso e chi verifica la rimozione.

Avanet deve indicare nel ticket autenticato l’IP pubblico di uscita esatto o un FQDN esplicitamente destinato al supporto. La sorgente non va dedotta da un sito né indovinata. Prima della modifica, aprire e testare un accesso indipendente tramite console, LAN di gestione, VPN amministrativa o Sophos Central.

Un accesso Avanet o partner già esistente non dovrebbe essere affiancato da un secondo account permanente. In questo caso si verificano profilo, MFA, limitazione della sorgente e stato dell’account esistente. Per un’analisi congiunta senza login diretto, la condivisione dello schermo è spesso la soluzione meno rischiosa.

Configurare l’utente WebAdmin

Configurare in sicurezza amministratori e profili Sophos Firewall descrive la procedura generale per account personali, profili, MFA e offboarding. Questa sezione aggiunge il caso specifico del supporto, con intervallo temporale, sorgente di supporto e rimozione controllata.

Un account locale relativo al caso, per esempio avanet-<ticket>, è destinato esclusivamente a WebAdmin e rende le modifiche più attribuibili nell’Audit Trail. SFOS salva il nome utente in minuscolo e non permette di cambiarlo in seguito.

1. Aprire Authentication > Users.
2. Selezionare Add.
3. Inserire nome utente e nome visualizzato.
4. Impostare User type su Administrator.
5. Selezionare un Profile appropriato.
6. Inserire un indirizzo e-mail e una password robusta, utilizzata soltanto per questo accesso.

Come Username si può usare avanet-<ticket>, sostituendo <ticket> con il numero interno. La guida non pubblica intenzionalmente password o indirizzi di supporto. Il profilo Administrator concede accesso WebAdmin completo e va usato solo se necessario. Altrimenti, in Profiles > Device access, partire da Read-only e concedere Read-write soltanto ai menu richiesti dalle modifiche autorizzate.

In Administrator advanced settings sono disponibili due ulteriori limitazioni:

• Schedule for device access: consente il login alla console WebAdmin soltanto durante la pianificazione selezionata.
• Login restriction for device access: consente il login soltanto dagli indirizzi IPv4 o dall’intervallo IPv4 selezionati.

Se l’IP fisso del supporto è noto, dovrebbe essere inserito anche in Login restriction for device access. La Local Service ACL limita così la raggiungibilità della console, mentre la restrizione dell’utente limita ulteriormente il login dell’account. Salvare con Save.

Verificare in anticipo password e MFA

La password viene trasmessa tramite un canale sicuro e non viene inserita in e-mail o ticket. In Authentication > Multi-factor authentication, selezionare Specific users and groups per OTP, aggiungere l’account del caso e attivare Web admin console in Require MFA for. Seed, QR code e codici monouso non vanno nel ticket. Se MFA non è tecnicamente disponibile, usare condivisione schermo o VPN invece di ometterla. Vedere MFA per gli amministratori.

Limitare la sorgente di supporto e la Local Service ACL

Creare l’oggetto sorgente confermato nel ticket

Per una finestra breve, un host IP con il solo indirizzo pubblico confermato riduce al minimo la fiducia. Se il ticket indica esplicitamente un FQDN, la Local Service ACL supporta anche un host FQDN e considera attendibili tutti gli indirizzi risolti fino alla scadenza del TTL DNS. I wildcard FQDN non sono supportati.

1. Per un IP fisso, aprire Hosts and services > IP host, selezionare Add e salvare l’indirizzo confermato come singolo host IPv4.
2. Solo per un FQDN confermato, aprire Hosts and services > FQDN host e selezionare Add.
3. Inserire un Name relativo al caso e copiare in FQDN il valore esatto del ticket.
4. Salvare con Save, quindi riaprire l’oggetto e verificarlo.

Per un FQDN, confrontare tutti gli indirizzi risolti con il ticket. Un indirizzo inatteso o non confermato impone di fermarsi: usare il singolo IP confermato o chiedere chiarimenti ad Avanet.

Creare la Local Service ACL Exception Rule

HTTPS e SSH sono servizi locali del firewall. Il loro traffico non è controllato dalle normali regole firewall. L’autorizzazione viene quindi configurata in Administration > Device access.

1. Aprire Administration > Device access.
2. Nella sezione Local service ACL, verificare che HTTPS e SSH non siano attivati globalmente per WAN.
3. Scorrere fino alla sezione Local service ACL exception rule e selezionare Add.
4. Creare la regola con i valori seguenti.

• Rule name: Avanet-Support
• Rule position: Top
• Description: numero del ticket, scopo e data di fine prevista
• IP version: IPv4
• Source zone: WAN
• Source Network / Host: esattamente l’oggetto IP o FQDN confermato
• Destination host: indirizzo pubblico del firewall oppure Any, se il firewall deve essere raggiungibile tramite più indirizzi WAN appropriati
• Services: HTTPS; SSH solo se la necessità è confermata; Ping/Ping6 solo per una diagnosi specifica
• Action: Accept

Salvare con Save. La posizione Top garantisce che l’autorizzazione specifica venga verificata prima di una regola Drop sovrapposta. Occorre comunque controllare le Exception Rules esistenti: una regola Accept più ampia collocata sopra oppure una zona sorgente errata possono modificare il modello di sicurezza previsto.

Non utilizzare: Any o 0.0.0.0 come Source. Sophos impedisce per una buona ragione l’autorizzazione globale dalla WAN alla console WebAdmin. Anche la casella WAN per HTTPS o SSH deve rimanere disattivata in questa procedura.

Aggiungere SSH solo se necessario

SSH consente l’accesso a Device Console e Advanced Shell ed è quindi molto più esteso rispetto a un profilo WebAdmin limitato. In molti interventi di supporto, Services rimane pertanto limitato a HTTPS.

L’utente avanet non può essere utilizzato per SSH. Sophos Firewall accetta per la CLI soltanto l’utente predefinito admin. La chiave pubblica non viene quindi associata all’utente avanet, ma configurata globalmente in 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.
5. Incollare in Authorized keys la chiave pubblica confermata per l’intervento corrente e aggiungerla con il simbolo più.
6. Selezionare Apply.

Soltanto l’amministratore predefinito può aggiungere o eliminare chiavi SSH; per un amministratore personalizzato, Apply non viene visualizzato. Sophos supporta chiavi RSA da almeno 2048 bit e determinate chiavi DSA ed ECDSA, ma non ED25519. Per una nuova chiave di supporto deve essere utilizzata una chiave moderna, sufficientemente robusta e supportata dal client SSH impiegato.

Una chiave pubblica presenta, ad esempio, la struttura seguente:

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

La chiave privata rimane presso il tecnico del supporto e non viene mai memorizzata sul firewall. Al termine dell’intervento, la chiave pubblica relativa al caso viene rimossa e SSH viene eliminato dalla Exception Rule, salvo che sia stato concordato un accesso permanente. La procedura pratica di login è descritta in Collegarsi a Sophos Firewall tramite SSH.

Verificare l’accesso e individuare gli errori

Un login riuscito dalla sorgente autorizzata non è sufficiente per considerare conclusa la verifica. Occorre controllare anche che l’accesso rimanga bloccato da un’altra sorgente Internet.

1. Aprire WebAdmin tramite la sorgente di supporto Avanet concordata e la porta amministrativa configurata. La porta predefinita è TCP 4444, ma può essere stata modificata in Administration > Admin and user settings.
2. Effettuare il login come avanet e verificare che il profilo selezionato consenta l’accesso ai menu necessari.
3. Utilizzare una seconda sorgente Internet non autorizzata. La console WebAdmin non deve essere raggiungibile da questa sorgente.
4. Se SSH è stato autorizzato, verificare il login come admin con la chiave privata relativa al caso. Per questo test non è necessaria l’autenticazione SSH tramite password.
5. Controllare gli eventi di autenticazione nel Log viewer. Le modifiche alla configurazione vengono verificate anche nell’Audit Trail.
6. Documentare nel ticket il risultato del test e l’ora di fine dell’accesso.

Se WebAdmin non è raggiungibile

La verifica parte dalla sorgente e procede fino al firewall:

• L’IP di uscita effettivo corrisponde all’oggetto sorgente e, per un FQDN, alla risoluzione DNS attuale?
• L’accesso proviene davvero dalla zona selezionata in Source zone?
• L’indirizzo WAN utilizzato corrisponde a Destination host?
• La Exception Rule è in posizione Top e contiene HTTPS?
• Viene utilizzata la porta WebAdmin corretta?
• Un router del provider, un dispositivo NAT a monte o un’ACL upstream blocca l’accesso?
• Login restriction for device access consente la connessione TCP, ma impedisce il login dell’utente?

Per la risoluzione dei problemi non si attivano le caselle WAN globali per HTTPS o SSH. Se la Exception Rule è corretta, non sono necessarie per questo accesso specifico.

Se il login non riesce

Se la console è raggiungibile ma il login non riesce, si controllano stato dell’utente, password, MFA, profilo, Schedule for device access, Login restriction for device access e le impostazioni di blocco del login a livello di sistema in Administration > Admin and user settings. Dopo diversi tentativi non riusciti, Sophos Firewall può bloccare temporaneamente l’IP sorgente per tutti i servizi di login.

Rimuovere l’accesso in modo controllato

Al termine dell’intervento di supporto, le modifiche concordate e l’accesso stesso vengono verificati separatamente:

1. Controllare nell’Audit Trail quali modifiche alla configurazione sono state eseguite con avanet.
2. In caso di modifiche importanti alle regole, Sophos Firewall Config Studio può aiutare a confrontare la configurazione precedente e quella successiva.
3. Disattivare o eliminare prima la Local Service ACL Exception Rule, chiudendo il percorso esterno.
4. Dalla precedente sorgente verificare che WebAdmin e SSH non siano raggiungibili e che l’accesso di gestione indipendente funzioni ancora.
5. Rimuovere solo la chiave SSH del caso; disattivare Enable authentication soltanto se nessun’altra chiave ne dipende.
6. Disattivare o eliminare l’account del caso e il relativo token MFA, salvo accesso permanente approvato esplicitamente.
7. Far confrontare a una seconda persona ACL, account, chiavi, Audit Trail e ticket con lo stato iniziale.

Un accesso partner mantenuto intenzionalmente richiede comunque MFA, una sorgente strettamente limitata, una persona responsabile e verifiche periodiche. Un ticket inattivo non giustifica un accesso amministrativo permanentemente aperto.

Domande frequenti