Configurare in sicurezza i profili IPsec Sophos Firewall

Un profilo IPsec determina con quale livello di sicurezza e a quali condizioni viene negoziato un tunnel IPsec. Definisce versione IKE, cifratura, integrità, gruppo DH, PFS, durate delle chiavi, rinnovo delle chiavi e Dead Peer Detection. Se questi valori non corrispondono a quelli della controparte, il tunnel non si stabilisce oppure si interrompe durante un rinnovo successivo.

Raccomandazione rapida per le nuove connessioni Site-to-Site: utilizzare IKEv2, proporre solo le combinazioni robuste realmente necessarie, attivare PFS e il rinnovo delle chiavi e configurare DPD in base al ruolo del firewall. Se entrambe le controparti li supportano, AES256GCM16 con il gruppo 19 (ecp256) per DH e PFS è il moderno punto di partenza scelto da Avanet. Non è né un’impostazione predefinita Sophos né una raccomandazione generale del produttore; prevalgono i requisiti della controparte.

Questo articolo spiega il profilo. La connessione vera e propria, con Gateway, ID, reti, regole, NAT e Routing, è descritta in Configurare una VPN IPsec Site-to-Site su Sophos Firewall. Se un tunnel esistente non si attiva o non trasporta traffico, consultare Risoluzione dei problemi IPsec VPN su Sophos Firewall.

Che cosa controlla un profilo IPsec

Il profilo raccoglie i parametri di sicurezza comuni a Phase 1 e Phase 2 e può essere assegnato a più connessioni. Prima di modificarlo, verificare quindi quali connessioni lo utilizzano. Anziché intervenire direttamente su un profilo di sistema o di produzione condiviso, clonarlo e provare inizialmente la copia soltanto sulla connessione prevista.

Non fanno parte del profilo:

indirizzo pubblico o FQDN della controparte
Preshared Key, certificato o RSA Key
Local ID e Remote ID
reti locali e remote o Traffic Selectors
regole firewall, NAT e Routing
indirizzo XFRM, SD-WAN Route o percorso di Failover

Questi valori vengono configurati nella connessione IPsec o nelle regole di rete associate. Uno stato Phase 1 verde non dimostra quindi né che Phase 2 corrisponda, né che il traffico utile sia instradato e consentito correttamente.

Authentication non è uguale ad Authentication type

In un profilo IPsec, Authentication indica l’algoritmo di integrità, ad esempio SHA2 256. Nella connessione IPsec, Authentication type determina invece se le controparti si identificano mediante Preshared Key, certificato o RSA Key.

Questi due campi svolgono compiti diversi. Un SHA2 256 corretto non risolve quindi un PSK errato e un certificato valido non compensa una Proposal Phase 1 incompatibile.

Spiegazione di Phase 1 e Phase 2

Phase 1 crea la IKE Security Association protetta. Attraverso questo canale di controllo, le controparti si autenticano e negoziano le altre chiavi e i parametri. Devono essere compatibili almeno versione IKE, cifratura, integrità e gruppo DH.

Phase 2 crea le Child o IPsec Security Associations per il traffico utile. Qui si applicano cifratura Phase 2, integrità, PFS e Traffic Selectors. Un tunnel può quindi completare correttamente Phase 1 senza creare una Child SA a causa di un valore PFS errato o di una combinazione Phase 2 differente.

Con IKEv2, la prima Child SA può essere creata insieme alla IKE SA. A seconda della controparte, un problema di PFS o di rinnovo può quindi emergere soltanto quando la Child SA viene rinnovata tramite CREATE_CHILD_SA. Avanet raccomanda di osservare almeno un rinnovo di Phase 2 durante il collaudo.

Concordare i parametri con la controparte

Prima della configurazione, i due amministratori concordano e documentano i valori per iscritto. Una schermata spesso non basta, perché i produttori usano nomi diversi per la stessa funzione.

Vanno documentate almeno le seguenti informazioni:

ruolo: Initiator, Responder o collegamento da entrambi i lati
versione IKE e, con IKEv1, Main o Aggressive Mode
Phase 1 Encryption, Authentication e gruppo DH
Phase 1 Key Life, Re-key Margin e randomizzazione
Phase 2 Encryption, Authentication, PFS e Key Life
Rekeying basato sul tempo e lato che lo avvia
intervallo DPD e azione quando la controparte non è raggiungibile
limiti noti del provider e Proposal consentite

Il nome del profilo non deve essere identico sui due dispositivi: conta che almeno una combinazione completa sia compatibile su entrambi i lati. Le proposte superflue complicano l’allineamento e possono aumentare inutilmente le dimensioni dei pacchetti IKE. L’effetto specifico del problema noto NC-136352 in SFOS è descritto più avanti tra i campi di Phase 1.

Scegliere una configurazione iniziale sicura

Gli esempi seguenti sono punti di partenza Avanet per nuove connessioni Site-to-Site. Non sostituiscono i requisiti di Azure, AWS, un operatore o un firewall di terze parti. Mostrano volutamente solo la scelta delle proposte e delle funzioni, non un profilo completo: durate, Re-key Margin, intervallo e azione DPD dipendono dalla controparte e dal ruolo di Initiator o Responder.

Profilo moderno per controparti controllate

Se entrambi i lati supportano algoritmi attuali:

Key exchange: IKEv2
Phase 1: AES256GCM16, 19 (ecp256)
Phase 2: AES256GCM16, 19 (ecp256)
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 è un algoritmo AEAD: esegue cifratura e protezione dell’integrità in un’unica operazione. Per questa combinazione SFOS non seleziona alcun algoritmo Authentication aggiuntivo come SHA2.

La Pseudo-Random Function per la generazione delle chiavi IKE non può essere selezionata separatamente in SFOS. Il firewall la ricava dagli algoritmi di integrità offerti e la concorda con la controparte.

Il gruppo 19 (ecp256) usa una curva ellittica. Per controparti recenti e controllate, Avanet lo preferisce ai gruppi MODP meno recenti. Anche AES128GCM16 è un algoritmo attuale. La combinazione ammessa dipende dai criteri crittografici applicabili e dal componente più debole del profilo.

Profilo di compatibilità senza AES-GCM o ECP

Se la controparte non supporta AES-GCM oppure non supporta un gruppo ECP, Avanet usa questa combinazione, più diffusa, come base di compatibilità:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

A differenza delle voci AES-GCM, in SFOS AES256 viene configurato con l’algoritmo Authentication separato SHA2 256. DH14 e PFS14 sono scelte di compatibilità Avanet, non la variante moderna preferita quando entrambe le controparti supportano il gruppo 19 (ecp256).

Da evitare nei nuovi profili

DES non compare tra gli algoritmi IPsec supportati in SFOS 22. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 e i gruppi DH 1, 2 e 5 restano selezionabili, ma non devono essere usati nei nuovi profili. Anche PFS: None deve restare un’eccezione documentata per le controparti che non supportano PFS.

Nonostante la posizione nel campo Phase 2 Encryption, AES-GMAC non fornisce cifratura, ma soltanto autenticazione e integrità. Un normale tunnel Site-to-Site riservato utilizza quindi AES-GCM oppure AES con un algoritmo SHA2 appropriato.

In SFOS 22 e 23, le opzioni documentate dipendono dalla versione IKE e dalla fase:

AES128GCM16, AES192GCM16 e AES256GCM16: in Phase 1 IKEv2 e in Phase 2 di entrambe le versioni IKE, non in Phase 1 IKEv1.
AES128GMAC, AES192GMAC e AES256GMAC: solo in Phase 2 di entrambe le versioni IKE, non in Phase 1.
TwoFish e Serpent: in Phase 1 e Phase 2 IKEv1, non IKEv2.

Sono algoritmi selezionabili, non combinazioni vincolate a specifici gruppi DH o algoritmi hash, né raccomandazioni per nuovi profili.

Le eccezioni Legacy vengono documentate con motivo, controparte interessata, rischio, Owner e data di sostituzione. Una combinazione debole non deve rimanere insieme alle Proposal robuste soltanto perché consente comunque di attivare il tunnel. La BSI TR-02102-3 relativa a IPsec e IKEv2 e la guida NIST alle VPN IPsec forniscono orientamenti tecnici.

Se un ambiente deve soddisfare requisiti crittografici formali, la procedura dedicata spiega come la modalità FIPS 140-3 su Sophos Firewall influisce su piattaforme, profili, certificati, backup e HA. La conformità FIPS non sostituisce la scelta consapevole di una proposal moderna e comune.

Clonare o creare un profilo

Percorso di menu:

Profiles > IPsec profiles

Per le connessioni Sophos-to-Sophos, i profili di sistema abbinati fungono da modelli comprensibili:

Branch office (IKEv2) per la filiale che avvia la connessione
Head office (IKEv2) per la sede centrale che risponde

Clonare il profilo adatto e assegnargli un nome chiaro, ad esempio Branch-Zurich-IKEv2. In questo modo il profilo di sistema rimane invariato e, durante un Rollback, il tunnel può essere riassegnato al profilo precedente.

General settings

Key exchange: utilizzare IKEv2 per le nuove connessioni Site-to-Site. Utilizzare IKEv1 soltanto per una controparte Legacy documentata.
Authentication mode: esiste soltanto per IKEv1. Non utilizzare Aggressive Mode perché, secondo Sophos, le informazioni di autenticazione vengono trasmesse in chiaro.
Key negotiation tries: Il campo definisce il numero di tentativi di negoziazione dello scambio di chiavi del tunnel prima che il firewall si fermi. Sophos raccomanda 0. Per un VPN Failover Group, SFOS imposta tuttavia il valore effettivo su 3.
Re-key connection: attivare per negoziare nuove chiavi Phase 1 e Phase 2 prima della scadenza. SFOS supporta soltanto il Rekeying basato sul tempo. Disattivando questa opzione, il firewall locale non avvia il rinnovo, ma può ancora rispondere alle richieste di rinnovo della controparte. Deve quindi essere la controparte ad avviarlo; il rinnovo resta attivo su almeno un lato.
Use strict profile: attivare quando le Proposal della controparte sono note con precisione. SFOS offre quindi soltanto i parametri configurati. Per i profili dei provider verificarne prima i requisiti; ad esempio, l’esempio ufficiale AWS non utilizza questa opzione.
Pass data in compressed format: Avanet lascia normalmente disattivata questa opzione. Attivarla solo se la controparte supporta IPComp e il risparmio di banda giustifica la maggiore complessità.
SHA2 with 96-bit truncation: Questa opzione accorcia i valori hash HMAC di autenticazione. attivare soltanto per un requisito di compatibilità documentato, non come miglioramento generale della sicurezza.

Use strict profile esclude dallo scambio IKE i valori predefiniti di sistema non configurati e può essere utile con proposte IKE troppo grandi. Non è tuttavia un’opzione da attivare senza verifiche in ogni profilo del provider.

Phase 1

Phase 1 contiene Key life, Re-key margin, Randomize re-keying margin by, il gruppo DH e fino a tre coppie di algoritmi Encryption e Authentication. Inserire qui Key life e Re-key margin in secondi. In Aggressive Mode si può salvare una sola combinazione Encryption/Authentication per fase; resta valido l’avvertimento contro questo modo.

Non basta scegliere il valore massimo accettato dal campo. La Re-key Margin deve essere nettamente più breve della Key Life e adeguarsi al comportamento della controparte; la randomizzazione modifica soltanto questo margine.

Inserire soltanto i gruppi DH e le Proposal effettivamente necessari. Il problema noto NC-136352 può verificarsi quando un profilo IKEv2 predefinito offre così tanti gruppi DH che il pacchetto IKE supera i 1.500 byte. Se un componente intermedio scarta i frammenti, l’Initiator invia ripetutamente mentre il Responder non vede nulla. Per una controparte nota, un solo gruppo DH confermato costituisce la configurazione più pulita.

Phase 2

Phase 2 contiene PFS, Key Life, Encryption e Authentication per il traffico utile. Anche questa fase consente fino a tre combinazioni Encryption/Authentication. Inserire la sua Key life Phase 2 in secondi. Le impostazioni di rinnovo configurate in Phase 1, inclusi margine e randomizzazione, regolano anche i tempi di rinnovo Phase 2; Phase 2 mantiene comunque la propria Key Life.

PFS impone un nuovo scambio di chiavi DH durante il Rekeying Phase 2. Se una chiave a lungo termine viene compromessa in seguito, si evita così che sessioni precedenti registrate possano essere decifrate con lo stesso materiale crittografico. Per questo si attiva PFS e si sceglie un valore corrispondente alla controparte. Nei profili moderni, il gruppo PFS spesso coincide con il gruppo DH Phase 1.

In Use PFS group, Same as phase 1 utilizza i gruppi DH selezionati in Phase 1 per la negoziazione Phase 2. Scegliere un gruppo esplicito imposta invece direttamente il gruppo DH Phase 2; None disattiva PFS. Ereditare gli stessi gruppi non significa che PFS richieda un numero di gruppo diverso.

Sophos raccomanda di impostare una Key Life Phase 2 più breve della Key Life Phase 1. In questo modo, le chiavi del traffico utile vengono rinnovate più frequentemente rispetto al canale di controllo IKE.

Dead Peer Detection

DPD rileva una controparte che non risponde più. Non sostituisce né Gateway Monitoring né un vero test applicativo. Se il tunnel Phase 2 è rimasto inattivo, DPD verifica la disponibilità della controparte prima di inviare dati.

Filiale o Initiator: Re-initiate, affinché il firewall tenti immediatamente un nuovo collegamento dopo un DPD Timeout. Il numero di tentativi Re-initiate dipende da Key negotiation tries.
Sede centrale o Responder: Disconnect, affinché la connessione obsoleta venga chiusa. Hold è un’alternativa consapevole quando i Traffic Selectors devono rimanere installati e la rinegoziazione deve avvenire solo all’arrivo di nuovo traffico.
Check peer after every: intervallo di controllo in secondi.
Wait for response up to: funziona soltanto con IKEv1. Con IKEv2, SFOS utilizza il proprio IKE Retransmission Timeout interno; il valore inserito non modifica questo comportamento. Con IKEv1, il numero di controlli dipende dal tempo di risposta configurato qui.

Negli IPsec Failover Groups, SFOS disattiva DPD per le connessioni assegnate e imposta Key negotiation tries su 3. La condizione del gruppo assume quindi il monitoraggio. La guida collegata spiega ordine, Failover Condition e Automatic failback; la sola vista del Profile non mostra l’intero comportamento Failover effettivo.

Interpretare correttamente Lifetimes e Rekeying

Key life non è un Session Timeout né un Idle Timeout. Limita la durata di una Security Association. Prima della scadenza, la negoziazione di nuove chiavi inizia all’interno del Re-key Margin.

Lifetimes più brevi rinnovano le chiavi più spesso, ma causano un maggiore carico di calcolo e più occasioni per errori di interoperabilità o Rekeying. Lifetimes più lunghe riducono questo carico, ma utilizzano il materiale crittografico più a lungo. Né il valore minimo né quello massimo consentito rappresentano quindi automaticamente la scelta migliore.

NIST SP 800-77r1 raccomanda 24 ore per la IKE SA e 8 ore per la IPsec SA. Sono raccomandazioni NIST indipendenti dal produttore, non valori predefiniti SFOS. Sophos e i provider cloud adottano valori diversi in base al ruolo e alla piattaforma.

Sophos raccomanda quanto segue per evitare collisioni di Rekeying:

La Key Life dell’Initiator è più breve di quella del Responder.
La Key Life Phase 2 su entrambi i firewall è più breve della Key Life Phase 1.
Il Rekeying è attivo almeno su un lato e utilizza esplicitamente il Rekeying basato sul tempo con i dispositivi di terze parti.

La randomizzazione modifica il Re-key Margin, non l’intera Key Life. Con una Key Life di otto ore, un Margin di dieci minuti e una randomizzazione del 20 per cento, Sophos indica che il Rekeying inizia tra 7 ore e 48 minuti e 7 ore e 52 minuti.

Per i provider si utilizzano i valori esatti da loro indicati. Su Sophos Firewall, l’esempio AWS documentato usa una Key Life Phase 1 di 28000, un Re-key Margin di 360 e una randomizzazione del 50 per cento; per Phase 2 usa 3600 secondi. È un esempio AWS, non un valore Avanet predefinito generale.

Assegnare e testare il profilo in sicurezza

Durante una finestra di manutenzione, assegnare inizialmente il nuovo profilo soltanto alla connessione prevista. Prima della modifica documentare il nome del profilo, i valori precedenti e il Rollback.

Per Site-to-Site, l’assegnazione avviene in:

Site-to-site VPN > IPsec

Anche Remote Access IPsec utilizza profili, ma ha limiti differenti: la configurazione attuale di Sophos Connect accetta profili IKEv1 con DPD disattivato o impostato su Disconnect. Il moderno profilo IKEv2 Site-to-Site non deve quindi essere riutilizzato senza verifica per Remote Access. La procedura completa è descritta in Configurare Sophos Connect su Sophos Firewall. Il caso specifico OTP/Rekeying è descritto in Sophos Connect interrompe la connessione dopo circa quattro ore.

I profili si applicano anche in Remote access VPN > L2TP. L2TP usa Preshared Key o certificato digitale e non supporta IKEv2. Il moderno punto di partenza Site-to-Site non può quindi essere applicato a L2TP.

Dopo il collegamento, Avanet usa nell’Advanced Shell esclusivamente i seguenti comandi di sola lettura per controllare lo stato e gli ultimi messaggi IKE:

ipsec statusall
tail -n 200 /log/strongswan.log

Verificare quindi traffico reale in entrambe le direzioni. I contatori di byte della Child SA devono aumentare. Ripetere il test dopo almeno un rinnovo di Phase 2. Solo questo ulteriore passaggio del collaudo Avanet verifica anche durate, PFS e comportamento durante il rinnovo.

Cause tipiche in base al sintomo:

Il tunnel non si stabilisce affatto: verificare versione IKE, Phase 1 Encryption, Authentication, DH, Strict Profile, ID e autenticazione della controparte.
NO_PROPOSAL_CHOSEN prima di Phase 1: confrontare le Proposal Phase 1.
Phase 1 è attiva, ma manca la Child SA: verificare Phase 2 Encryption, Authentication, PFS e Traffic Selectors.
Disconnessione dopo un intervallo simile: confrontare Key Life, Re-key Margin, randomizzazione e valori di Initiator e Responder.
Il tunnel è verde, ma non passa traffico: non modificare subito il profilo; verificare regole firewall, NAT, Routing, percorso di ritorno e contatori di byte.

Se la modifica causa problemi, riassegnare alla connessione il profilo precedente documentato. Per questo ripristino non occorre apportare modifiche nell’Advanced Shell.