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, Lifetimes, Rekeying e Dead Peer Detection. Se questi valori non corrispondono a quelli della controparte, il tunnel rimane down o si interrompe in seguito durante il Rekeying.

Raccomandazione rapida per le nuove connessioni Site-to-Site: utilizzare IKEv2, offrire soltanto le Proposal robuste effettivamente necessarie, attivare PFS e Rekeying e configurare DPD in base al ruolo del firewall. Se entrambe le controparti supportano questi valori, AES256GCM16 con DH19 e PFS19 è un punto di partenza moderno. I requisiti del provider e della controparte hanno tuttavia sempre la precedenza.

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 contiene i parametri di sicurezza condivisi per Phase 1 e Phase 2. Un profilo può essere assegnato a più connessioni. Proprio per questo non si dovrebbe modificare spontaneamente un profilo di sistema o di produzione in uso: la modifica può interessare tutti i tunnel associati al successivo collegamento o Rekeying.

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. Di conseguenza, un problema PFS o di Rekeying potrebbe manifestarsi soltanto ore più tardi, quando la Child SA deve essere rinnovata. Il collaudo è completo solo dopo aver osservato almeno un Rekeying senza interruzioni.

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. È importante che almeno una combinazione completa sia compatibile su entrambi i lati. Un numero maggiore di Proposal non è automaticamente migliore: amplia la superficie di attacco e di errore e può ingrandire i pacchetti IKE al punto da rendere problematica la frammentazione.

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 carrier o un firewall di terze parti.

Profilo moderno per controparti controllate

Se entrambi i lati supportano algoritmi attuali:

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
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 non si seleziona alcun algoritmo Authentication aggiuntivo come SHA2. GCM16 indica l’Authentication Tag di 16 byte, non una cifratura a 16 bit.

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.

DH19 utilizza una curva ellittica e offre un buon equilibrio tra livello di sicurezza, dimensioni dei pacchetti e carico di elaborazione. Anche AES128GCM16 è un algoritmo attuale e non è automaticamente insicuro per un normale livello di sicurezza a 128 bit. La robustezza complessiva dipende sempre dal componente più debole del profilo.

Profilo di compatibilità per controparti moderne di terze parti

Se la controparte non supporta AES-GCM o un gruppo ECP, questa combinazione è un punto di partenza maggiormente compatibile:

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

Qui AES opera in modalità CBC e richiede quindi la protezione di integrità separata SHA2 256. DH14 e PFS14 sono scelte di compatibilità, non la variante moderna preferita quando entrambe le controparti supportano DH19.

Da evitare nei nuovi profili

Nei nuovi design evitare IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 e i gruppi DH 1, 2 e 5. 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.

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é le informazioni di autenticazione vengono trasmesse con una protezione inferiore.
• Key negotiation tries: 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.
• 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: lasciare disattivato in condizioni normali. Attivare soltanto quando l’utilità e il supporto su entrambi i lati sono confermati.
• SHA2 with 96-bit truncation: attivare soltanto per un requisito di compatibilità documentato, non come miglioramento generale della sicurezza.

Use strict profile riduce i Fallback inattesi e può aiutare quando Proposal IKE troppo grandi causano problemi. 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.

SFOS accetta da 120 a 86400 secondi per Key Life, da 30 a 999 secondi per Re-key Margin e da 0 a 100 per cento per la randomizzazione. Un valore formalmente accettato non è automaticamente appropriato: il Margin deve rimanere nettamente inferiore alla Key Life e corrispondere al comportamento della controparte.

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.

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.

Scegliere 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.

• Filiale o Initiator: Re-initiate, affinché il firewall tenti immediatamente un nuovo collegamento dopo un DPD Timeout.
• 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.

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 indica 86400 secondi per la IKE SA e 28800 secondi per la IPsec SA come orientamenti comuni. Sophos e i provider Cloud utilizzano valori diversi a seconda del ruolo e della piattaforma. Questi numeri non costituiscono quindi un profilo SFOS universale.

Sophos raccomanda quanto segue per evitare collisioni di Rekeying:

1. La Key Life dell’Initiator è più breve di quella del Responder.
2. La Key Life Phase 2 su entrambi i firewall è più breve della Key Life Phase 1.
3. 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. L’esempio AWS documentato usa circa 28000 per Phase 1, un Re-key Margin di 360, una randomizzazione di 50 e 3600 secondi per Phase 2 su Sophos Firewall. È 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.

Dopo il collegamento, controllare in sola lettura lo stato e gli ultimi messaggi IKE nell’Advanced Shell:

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 Rekeying Phase 2; soltanto a quel punto Lifetimes, PFS e comportamento del Rekeying sono stati realmente collaudati.

Cause tipiche in base al sintomo:

• Il tunnel rimane completamente down: 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 un normale Rollback del profilo non è necessario modificare servizi, database o configurazioni Advanced Shell.