Proteggere il VPN Portal di Sophos Firewall dagli attacchi brute force

Numerosi accessi non riusciti al Sophos Firewall VPN Portal indicano innanzitutto che il portale è raggiungibile da Internet ed è oggetto di attacchi automatizzati. Non dimostrano ancora che si sia verificata un’intrusione. La situazione diventa critica quando vengono individuati nomi utente reali, vengono bloccati account in AD o Microsoft Entra ID oppure tra i tentativi non riusciti compare un accesso riuscito sconosciuto.

Per contenere l’attacco, procedere in questo ordine:

1. Conservare nei log intervallo temporale, utenti, IP di origine e metodo di autenticazione.
2. Controllare gli accessi riusciti e gli eventi di identità nello stesso periodo.
3. Limitare il VPN Portal alle origini o ai Paesi necessari tramite una Local Service ACL.
4. Attivare Block login ed escludere la condivisione della porta tra VPN Portal e SSL VPN.
5. Rimuovere i metodi di autenticazione non necessari e controllare MFA o la protezione Entra.
6. Bloccare inoltre le origini IPv4 dannose note tramite Threat Feeds e monitorare l’effetto.

⚠️ Non disattivare il VPN Portal senza preparazione. Sophos Connect Provisioning e Microsoft Entra ID SSO utilizzano la porta del VPN Portal. Prima di modificare Device Access o le porte, sono necessari un secondo accesso amministrativo testato e un piano per i profili client, le Redirect URIs e il rollback.

Prima di ogni modifica, annotare le impostazioni attuali o salvare un backup della configurazione. Includere l’abilitazione WAN di VPN portal, tutti i campi e l’ordine delle eccezioni Local Service ACL, lo stato e i tre valori di Block login, porte e protocolli di VPN Portal e SSL VPN, nonché selezione e ordine dei server di autenticazione. Per provisioning o Entra SSO registrare anche vpn_portal_port, URL del portale e Redirect URI. Per i Threat Feed modificati conservare URL, tipo di indicatore, action, stato e opzioni personalizzate. Il rollback ripristina questi valori, non presunti default.

Confermare l’attacco in Log Viewer

In Log Viewer, aprire gli eventi di autenticazione e applicare i filtri:

• Log component: VPN Portal Authentication
• Status: Failed

Per ogni risultato sono rilevanti l’ora, Source IP, Source country, Username, Authentication mechanism e Reason. Non tutti compaiono come colonne standard in ogni vista; Detailed view e le colonne aggiuntive mostrano i dettagli disponibili per l’evento. Se manca contesto, controllare anche i log grezzi e quelli dell’Identity Provider. In un SIEM filtrare log_component su VPN Portal Authentication e status su Failed; la sintassi dipende dal SIEM.

Successivamente cercare anche Successful per gli stessi nomi utente e lo stesso intervallo temporale. Un accesso riuscito sconosciuto è più importante del semplice numero di tentativi non riusciti e deve essere trattato come un possibile incidente relativo all’account.

Una singola origine o un attacco distribuito

La distribuzione determina quale protezione sia efficace:

• Molti tentativi da un indirizzo IP: Block login può bloccare temporaneamente l’origine dopo il raggiungimento della soglia.
• Pochi tentativi da molti indirizzi IP: Una botnet distribuita può rimanere sotto la soglia per ogni origine. In questo caso ACL, protezione dell’identità e Threat Feeds diventano più importanti.
• Molti nomi utente dalla stessa origine: Questo comportamento è compatibile con Password Spraying o Credential Stuffing.
• Ripetutamente lo stesso utente reale: Controllare nei log AD, Entra o RADIUS i blocchi degli account e gli accessi riusciti.
• Nomi casuali inesistenti: Spesso si tratta di scansioni automatizzate, che continuano comunque a generare carico e rumore nei log.

Bloccare manualmente soltanto l’IP di origine raramente risolve in modo duraturo un attacco distribuito. Prima si riduce la superficie raggiungibile, poi si aggiungono automaticamente le origini dannose note.

Controllare in modo mirato i log grezzi

Se Log Viewer non fornisce abbastanza contesto, scaricare i file interessati da Diagnostics > Tools > Troubleshooting logs:

• vpnportal.log per l’accesso al portale;
• access_server.log per l’autenticazione e l’autorizzazione degli utenti;
• oauth_sso_vpn.log in aggiunta per Microsoft Entra ID SSO.

sslvpn.log, invece, appartiene al servizio SSL VPN ed è rilevante solo se l’errore si verifica durante la creazione del tunnel anziché durante l’accesso al portale. I log di autenticazione possono contenere nomi utente, indirizzi IP pubblici e altri dati sensibili delle richieste. Gli estratti devono quindi essere limitati nel tempo e nel contenuto, anonimizzati prima della condivisione e non copiati senza controllo in ticket pubblici. Servizi e log di Sophos Firewall associa altri file di log; Salvare i log di Sophos Firewall descrive un archivio di supporto strutturato.

Limitare il VPN Portal alle origini necessarie

Il VPN Portal è un servizio locale del firewall. Le normali regole firewall o DNAT non controllano questo accesso; a tale scopo si utilizza Administration > Device access. I principi completi sono descritti in Device Access e Local Service ACL.

Prima della modifica, aprire e testare realmente un accesso indipendente tramite console, LAN di gestione, VPN amministrativa o Sophos Fusion (in precedenza Sophos Central). Quindi creare per prima l’eccezione restrittiva:

1. In Administration > Device access > Local service ACL exception rule, fare clic su Add.
2. Rule name: ad esempio vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; se è pubblicato IPv6, è necessaria anche una regola IPv6 separata.
5. Source zone: WAN.
6. Source networks and hosts: reti fisse dei partner, un elenco IP aggiornato o un Country Group con i Paesi effettivamente necessari.
7. Destination host: l’interfaccia WAN o l’IP WAN configurato su Sophos Firewall su cui arriva l’accesso. Se è presente un router NAT upstream, non si intende l’indirizzo pubblico di tale router.
8. Services: solo VPN portal.
9. Action: Accept.
10. Salvare la regola.

Dopo il salvataggio, testare prima l’eccezione da un’origine esterna consentita. Tramite il secondo accesso amministrativo verificato, rimuovere l’abilitazione generale WAN di VPN portal nella matrice Device Access e salvare. Le modifiche hanno effetto immediato. L’origine consentita deve continuare a raggiungere il portale, mentre una non consentita non deve più farlo. Se il test positivo fallisce, ripristinare l’abilitazione WAN precedente dal secondo accesso. La guida a Device Access descrive altre varianti.

Una limitazione geografica è utile quando il gruppo di utenti è chiaramente definito. Non è tuttavia un controllo dell’identità: viaggiatori, reti mobili, provider VPN e geolocalizzazioni IP errate possono bloccare utenti legittimi. L’accesso globale richiede quindi una protezione dell’identità particolarmente solida, MFA, logging e un processo di revisione.

Il web proxy configurato sul firewall è un’eccezione importante. SFOS tratta le sue richieste HTTP e HTTPS come interne, non come traffico proveniente da una zona. Gli utenti con accesso al proxy possono quindi raggiungere VPN Portal e altri servizi HTTP del firewall anche se Device Access li disabilita per la loro zona. Se si usa il proxy, eseguire il test negativo una volta direttamente e una volta in modo verificabile tramite proxy esplicito o trasparente. Device Access non può bloccare per zona questo percorso interno; se indesiderato, limitare l’accesso al proxy stesso.

Configurare correttamente Login Security e le porte

In Administration > Admin and user settings > Login security, attivare Block login e compilare i tre campi per numero di tentativi, intervallo e durata del blocco. Cinque tentativi in 60 secondi con blocco di cinque minuti sono solo un esempio, non un default Sophos universale né un valore di produzione da adottare senza pilota. Scegliere i valori in base a utenti, helpdesk e origini NAT condivise. Testare da un IP controllato mantenendo aperto il secondo accesso amministrativo.

Il blocco opera per IP di origine e si applica a tutti i servizi dopo la soglia, tra cui WebAdmin, CLI, VPN Portal e User Portal. Dietro un NAT di ufficio, hotel o provider può coinvolgere contemporaneamente più utenti legittimi e un amministratore. Non eseguire mai il test negativo tramite l’unico accesso amministrativo disponibile.

In caso di attacco distribuito, Block login è soltanto uno strato di protezione. Molti bot possono rimanere singolarmente sotto la soglia. Gli errori CAPTCHA non contano come accessi non riusciti e non attivano il blocco.

Escludere la condivisione della porta

Confrontare questi due valori:

• Administration > Admin and user settings > VPN portal HTTPS port, per impostazione predefinita TCP 443
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, per impostazione predefinita 8443 con TCP o UDP

Se VPN Portal e SSL VPN utilizzano la stessa porta e lo stesso protocollo, le impostazioni di Login Security non hanno effetto. Inoltre il VPN Portal diventa raggiungibile dalle zone consentite per SSL VPN, anche se in Device Access è disattivato per tali zone.

La combinazione deve quindi essere univoca. Spostare semplicemente il servizio su una porta casuale non impedisce un attacco. Se si modifica la porta del VPN Portal, occorre aggiornare l’URL del portale, l’Entra Redirect URI e il valore vpn_portal_port per Sophos Connect Provisioning, quindi ripetere il test con un utente pilota.

Proteggere l’autenticazione e gli account interessati

In Authentication > Services > VPN portal authentication methods, lasciare attivi solo i server necessari. Un percorso locale, AD, LDAP o RADIUS inutilizzato consente tentativi superflui contro un’altra directory. Deve rimanere selezionato almeno un server. VPN Portal non supporta RADIUS con challenge-based MFA, quindi non pianificarlo come MFA del portale.

MFA non impedisce ogni tentativo non riuscito, ma riduce il rischio che sia sufficiente una password nota o indovinata. MFA per VPN Portal e Remote Access descrive la configurazione per gli utenti locali e di directory. Con Microsoft Entra ID SSO, controllare anche Entra MFA, Conditional Access, Sign-in Logs e Risk Events.

Un utente reale con tentativi non riusciti sospetti non deve essere esaminato soltanto sul firewall:

1. Controllare i blocchi degli account e gli accessi riusciti nell’Identity Provider competente.
2. Terminare le sessioni riuscite sconosciute secondo il processo di gestione degli incidenti.
3. Reimpostare la password e i metodi MFA registrati se si sospetta una compromissione.
4. Controllare l’appartenenza ai gruppi e l’autorizzazione Remote Access.
5. Solo successivamente verificare con un accesso pilota documentato che l’accesso legittimo funzioni di nuovo.

Il VPN Portal può essere rimosso da WAN solo se nessun processo necessario ne dipende. Il provisioning .pro si connette tramite vpn_portal_port. Con Entra SSO, l’URL usato per VPN Portal e Remote Access e la Redirect URI registrata devono corrispondere a gateway e porta pubblicati. File .ovpn distribuiti manualmente possono permettere una pubblicazione più restrittiva, ma le modifiche al profilo richiedono distribuzione e test controllati.

Aggiungere Threat Feeds contro le origini note

Sophos Firewall può confrontare IP di origine dannosi noti anche nel traffico verso i propri servizi, tra cui VPN Portal, WebAdmin e VPN. Secondo la guida SFOS 22, il confronto si applica a MDR, NDR Essentials e Third-Party Threat Feeds, ma non a Sophos X-Ops Threat Feeds. Un Third-Party Feed IPv4 aggiornato è quindi uno strato aggiuntivo per origini note.

Configurare i Threat Feeds su Sophos Firewall descrive la configurazione completa, i requisiti di licenza, il pilota Monitor, il funzionamento Block, i False Positives e i feed Cybora testati da Avanet. Per un nuovo feed occorre comunque verificare il recupero e il contenuto IoC, osservare prima l’effetto e solo successivamente attivare il blocco in modo controllato.

Per visualizzare localmente i rilevamenti in Log Viewer, attivare Local reporting per Active threat response in System services > Log settings. XGS 87/87w e 107/107w non supportano il reporting locale; usare Sophos Fusion o un server Syslog.

I Threat Feeds non sostituiscono un’ACL né un’autenticazione solida. Confrontano solo gli indirizzi elencati. I Third-Party Feeds accettano singoli IPv4, non IPv6, intervalli IP o indirizzi di rete; nuovi IP bot restano raggiungibili. Un False Positive può bloccare utenti legittimi. Avviare un feed in Monitor, controllare errori e risultati inattesi, poi passare a Block. Una Threat Exclusion vale per tutti i moduli Active Threat Response: deve essere ristretta, motivata e temporanea. Risultati ed eccezioni devono essere riesaminati regolarmente.

Per il rollback, riportare un feed modificato all’action precedente; disabilitare un nuovo feed, ma non eliminarlo senza verifica. Controllare poi che una fonte colpita da False Positive raggiunga di nuovo il portale e che le altre protezioni funzionino.

Controllare l’effetto e continuare il monitoraggio

Dopo ogni modifica, ripetere lo stesso test definito:

1. Un’origine esterna consentita raggiunge il VPN Portal e un utente pilota riesce ad accedere.
2. Un’origine non consentita non raggiunge più il portale.
3. VPN Portal e SSL VPN utilizzano una combinazione univoca di porta e protocollo.
4. Un tentativo non riuscito controllato compare in Log Viewer con l’IP di origine e il metodo di autenticazione previsti.
5. Sophos Connect Provisioning, Entra SSO e il tunnel VPN vero e proprio continuano a funzionare.
6. I rilevamenti Threat Feed compaiono nella destinazione log configurata, se usata.
7. Nel periodo di osservazione definito non compaiono nuovi blocchi AD o Entra né accessi riusciti sconosciuti.

Se un test fallisce, ripristinare prima solo l’ultima modifica al valore precedente documentato. Può riguardare action del feed, server di autenticazione, Block login, porta e Redirect URI o Device Access. Per Device Access, ripristinare la vecchia abilitazione WAN dal secondo accesso prima di rimuovere l’eccezione ACL. Per la porta, ripristinare insieme porta e protocollo, .pro, URL del portale e Redirect URI, quindi ripetere i test consentito e negato.

Per il rilevamento a lungo termine, inviare i log di autenticazione a un SIEM. Gli avvisi utili non considerano soltanto il numero di errori, ma anche molte origini diverse contro lo stesso utente, molti nomi utente da un’unica origine e accessi riusciti dopo una serie di tentativi non riusciti.

FAQ