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.

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. In un SIEM si utilizzano i campi Syslog log_component con il valore VPN Portal Authentication e status con il valore Failed; la sintassi concreta della query dipende dal SIEM utilizzato.

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 Central. Quindi creare per prima l’eccezione restrittiva:

1. In Administration > Device access > Local service ACL exception rule, fare clic su Add.
2. 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.

Nello stato finale, il VPN Portal non è abilitato in generale per WAN nella matrice Device Access, ma è raggiungibile solo tramite le eccezioni ACL necessarie. Le modifiche a Device Access hanno effetto immediato; per questo il passaggio sicuro con test positivo, test negativo e rollback è descritto nella guida dettagliata a Device Access.

Successivamente testare l’eccezione da un’origine esterna consentita e da una non consentita. Finché rimane attiva un’abilitazione WAN ampia, un test positivo riuscito non dimostra da solo che l’eccezione limiti l’accesso come previsto.

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.

Configurare correttamente Login Security e le porte

In Administration > Admin and user settings > Login security, attivare Block login. Sophos Firewall Health Check utilizza come punto di partenza cinque accessi non riusciti entro 60 secondi e una durata del blocco di cinque minuti. Il valore appropriato per la produzione dipende comunque dal numero di utenti, dal processo di helpdesk e dalle origini NAT condivise.

Il blocco opera per IP di origine e, una volta raggiunta la soglia, non riguarda soltanto il VPN Portal. Da tale origine non si aprono più nemmeno WebAdmin, CLI, VPN Portal e User Portal. Un ufficio, un hotel o un NAT del provider può quindi coinvolgere contemporaneamente più utenti legittimi e un amministratore. Un test negativo non deve mai essere eseguito dall’unico accesso amministrativo disponibile.

In caso di attacco distribuito, Block login è soltanto uno strato di protezione. Molti bot possono rimanere singolarmente sotto la soglia.

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 realmente necessari all’attuale concetto di Remote Access. Un percorso locale, AD, LDAP o RADIUS non più utilizzato non offre alcun vantaggio, ma può esporre ulteriori credenziali a verifiche contro il portale pubblico.

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 completamente da WAN solo se nessun processo necessario dipende da esso. Entra SSO e il provisioning tramite .pro utilizzano la porta del portale. Con file .ovpn distribuiti manualmente può essere possibile un processo di pubblicazione più restrittivo, ma le modifiche ai profili devono essere distribuite e testate in modo controllato.

Aggiungere Threat Feeds contro le origini note

Sophos Firewall può confrontare gli indirizzi IP di origine dannosi noti anche per il traffico diretto al sistema verso servizi come VPN Portal, WebAdmin e VPN. Feed IPv4 aggiornati sono adatti come strato di protezione aggiuntivo.

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.

Affinché i rilevamenti Active Threat Response compaiano in Log Viewer, è necessario attivare Local reporting per Active threat response in System services > Log settings.

I Threat Feeds non sostituiscono un’ACL né una protezione solida dell’identità. Rilevano solo gli indicatori contenuti nei feed, i Third-Party Feeds supportano attualmente IPv4 per gli IoC degli IP di origine e un nuovo IP bot o un indirizzo non elencato rimane raggiungibile. Al contrario, un False Positive può bloccare un utente legittimo; è quindi necessario un processo documentato di eccezione e revisione.

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 nel log Active Threat Response se si utilizza questo strato di protezione.
7. Non si verificano blocchi degli account AD o Entra né accessi riusciti sconosciuti.

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