Förstå och konfigurera IPsec-profiler säkert i Sophos Firewall

En IPsec-profil bestämmer hur säkert och under vilka villkor en IPsec-tunnel förhandlas. Den anger IKE-version, kryptering, integritet, DH-grupp, PFS, lifetimes, rekeying och Dead Peer Detection. Om värdena inte stämmer överens med motparten förblir tunneln down eller slutar fungera först vid en senare rekey.

Kort rekommendation för nya Site-to-Site-anslutningar: använd IKEv2, erbjud endast de starka proposals som verkligen behövs, aktivera PFS och rekeying och konfigurera DPD utifrån respektive roll. Om båda motparter stöder värdena är AES256GCM16 med DH19 och PFS19 en modern utgångspunkt. Leverantörens och motpartens krav har dock alltid företräde.

Den här artikeln förklarar profilen. Själva anslutningen med gateway, ID:n, nätverk, regler, NAT och routing beskrivs i Konfigurera Sophos Firewall Site-to-Site IPsec VPN. Om en befintlig tunnel inte etableras eller inte överför trafik finns hjälp i Felsökning av IPsec VPN i Sophos Firewall.

Vad en IPsec-profil styr

Profilen innehåller de gemensamma säkerhetsparametrarna för Phase 1 och Phase 2. En profil kan tilldelas flera anslutningar. Just därför bör en system- eller produktionsprofil som används inte ändras utan planering: ändringen kan påverka alla anslutna tunnlar vid nästa etablering eller rekey.

Följande ingår inte i profilen:

motpartens offentliga adress eller FQDN
Preshared Key, certifikat eller RSA Key
Local ID och Remote ID
lokala och fjärranslutna nätverk eller Traffic Selectors
brandväggsregler, NAT och routing
XFRM-adress, SD-WAN Route eller failoverväg

Dessa värden konfigureras i IPsec-anslutningen eller i tillhörande nätverksregler. En grön Phase 1-status bevisar därför varken att Phase 2 stämmer eller att nyttotrafiken routas och tillåts korrekt.

Authentication är inte samma sak som Authentication type

I en IPsec-profil avser Authentication integritetsalgoritmen, exempelvis SHA2 256. I IPsec-anslutningen avgör Authentication type däremot om motparterna autentiserar sig med Preshared Key, certifikat eller RSA Key.

De båda fälten har olika uppgifter. Ett korrekt SHA2 256 åtgärdar därför inte en felaktig PSK, och ett passande certifikat kompenserar inte för en inkompatibel Phase 1-proposal.

Förstå Phase 1 och Phase 2

Phase 1 bygger upp den skyddade IKE Security Association. Via den här styrkanalen autentiserar sig motparterna och förhandlar fram ytterligare nycklar och parametrar. Minst IKE-version, kryptering, integritet och DH-grupp måste vara kompatibla.

Phase 2 skapar Child eller IPsec Security Associations för den egentliga nyttotrafiken. Här tillämpas Phase 2-kryptering, integritet, PFS och Traffic Selectors. En tunnel kan därför slutföra Phase 1, men ändå sakna en Child SA på grund av ett felaktigt PFS-värde eller en avvikande Phase 2-kombination.

Med IKEv2 kan den första Child SA skapas samtidigt som IKE SA. Ett PFS- eller rekeyproblem kan därför visa sig först efter flera timmar när Child SA måste förnyas. Ett godkännandetest är inte fullständigt förrän minst en rekey har observerats utan avbrott.

Stäm av parametrarna med motparten

Före konfigurationen bör administratörerna på båda sidor stämma av värdena skriftligt. En skärmbild räcker ofta inte, eftersom tillverkare använder olika namn för samma funktion.

Dokumentera minst följande:

roll: Initiator, Responder eller etablering från båda sidor
IKE-version och, för IKEv1, Main eller Aggressive Mode
Phase 1-Encryption, Authentication och DH-grupp
Phase 1-Key Life, Re-key Margin och randomisering
Phase 2-Encryption, Authentication, PFS och Key Life
tidsbaserad rekeying och vilken sida som startar den
DPD-intervall och åtgärd när motparten inte kan nås
kända leverantörsbegränsningar och tillåtna proposals

Profilnamnet behöver inte vara identiskt på båda enheterna. Det avgörande är att minst en fullständig kombination är kompatibel på båda sidor. Fler proposals är inte automatiskt bättre: de ökar attack- och felytan och kan göra IKE-paketen så stora att fragmentering blir ett problem.

Välj en säker grundkonfiguration

Följande exempel är Avanets utgångspunkter för nya Site-to-Site-anslutningar. De ersätter inte krav från Azure, AWS, en operatör eller en brandvägg från en annan tillverkare.

Modern profil för kontrollerade motparter

Om båda sidor stöder aktuella metoder:

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 är en AEAD-metod: den krypterar och skyddar integriteten i ett enda steg. För den här kombinationen väljs ingen ytterligare Authentication-metod som SHA2. GCM16 avser en Authentication Tag på 16 byte, inte 16-bitars kryptering.

Pseudo-Random Function för generering av IKE-nycklar kan inte väljas separat i SFOS. Brandväggen härleder den från de integritetsmetoder som erbjuds och stämmer av den med motparten.

DH19 använder en elliptisk kurva och ger en bra balans mellan säkerhetsnivå, paketstorlek och beräkningsbelastning. AES128GCM16 är också en aktuell metod och inte automatiskt osäker för en normal säkerhetsnivå på 128 bitar. Den totala styrkan bestäms alltid av profilens svagaste komponent.

Kompatibilitetsprofil för aktuella tredjepartssystem

Om motparten inte stöder AES-GCM eller en ECP-grupp är denna kombination en mer kompatibel utgångspunkt:

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

Här arbetar AES i CBC-läge och behöver därför det separata integritetsskyddet SHA2 256. DH14 och PFS14 är kompatibilitetsval, inte den moderna standardvarianten när båda peers stöder DH19.

Undvik i nya profiler

I nya lösningar bör IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 och DH-grupperna 1, 2 och 5 inte längre användas. PFS: None bör också endast vara ett dokumenterat undantag för motparter som inte stöder PFS.

Trots sin placering i Phase 2-fältet Encryption är AES-GMAC ingen kryptering, utan ger endast autentisering och integritet. För en vanlig konfidentiell Site-to-Site-tunnel används därför AES-GCM eller AES med en passande SHA2-metod.

Legacy-avvikelser ska dokumenteras med orsak, berörd motpart, risk, owner och sista användningsdatum. En svag kombination bör inte lämnas kvar bredvid starka proposals bara för att tunneln också etableras med den. Som teknisk vägledning kan BSI TR-02102-3 om IPsec och IKEv2 och NIST Guide to IPsec VPNs användas.

Om en miljö måste uppfylla formella kryptografiska krav förklarar den separata processen hur FIPS 140-3-läget på Sophos Firewall påverkar plattformar, profiler, certifikat, backuper och HA. FIPS-efterlevnad ersätter inte det medvetna valet av en modern gemensam proposal.

Klona eller skapa en profil

Menysökväg:

Profiles > IPsec profiles

För Sophos-till-Sophos-anslutningar fungerar de parade systemprofilerna som tydliga mallar:

Branch office (IKEv2) för det initierande filialkontoret
Head office (IKEv2) för det svarande huvudkontoret

Den passande profilen klonas och får ett tydligt namn, exempelvis Branch-Zurich-IKEv2. Då förblir systemprofilen oförändrad och vid en rollback kan tunneln åter tilldelas sin tidigare profil.

General settings

Key exchange: För nya Site-to-Site-anslutningar, IKEv2. IKEv1 endast för en dokumenterad legacy-motpart.
Authentication mode: Finns endast med IKEv1. Aggressive Mode används inte, eftersom autentiseringsinformation överförs med sämre skydd.
Key negotiation tries: Sophos rekommenderar 0. I en VPN-failovergrupp sätter SFOS dock det effektiva värdet till 3.
Re-key connection: Aktivera så att nya Phase 1- och Phase 2-nycklar förhandlas innan de befintliga löper ut. SFOS stöder endast tidsbaserad rekeying.
Use strict profile: Aktivera när motpartens proposals är exakt kända. SFOS erbjuder då endast de konfigurerade parametrarna. Kontrollera först leverantörens krav för leverantörsprofiler; i det officiella AWS-exemplet används alternativet till exempel inte.
Pass data in compressed format: Låt normalt vara avstängt. Aktivera endast när nyttan och stödet på båda sidor är bekräftade.
SHA2 with 96-bit truncation: Aktivera endast vid ett dokumenterat kompatibilitetskrav, inte som en allmän säkerhetsförbättring.

Use strict profile minskar oväntade fallbacks och kan hjälpa när IKE-proposals är för stora. Det är dock inget alternativ som ska aktiveras utan kontroll i varje leverantörsprofil.

Phase 1

Phase 1 innehåller Key life, Re-key margin, Randomize re-keying margin by, DH-grupp och upp till tre par med Encryption och Authentication.

SFOS accepterar 120 till 86400 sekunder för Key Life, 30 till 999 sekunder för Re-key Margin och 0 till 100 procent för randomisering. Ett formellt tillåtet värde är inte automatiskt lämpligt: Margin måste vara tydligt lägre än Key Life och passa motpartens beteende.

Ange endast de DH-grupper och proposals som verkligen behövs. Det kända problemet NC-136352 kan uppstå när en standardprofil för IKEv2 erbjuder så många DH-grupper att IKE-paketet blir större än 1'500 byte. Om en mellanliggande komponent kasserar fragment fortsätter Initiator att skicka medan Responder inte ser något. För en känd peer är en enda bekräftad DH-grupp den tydligaste konfigurationen.

Phase 2

Phase 2 innehåller PFS, Key Life samt Encryption och Authentication för nyttotrafiken.

PFS framtvingar ett nytt DH-nyckelutbyte vid en Phase 2-rekey. Om en långtidsnyckel senare komprometteras ska äldre inspelade sessioner därmed inte kunna dekrypteras med samma nyckelmaterial. Därför aktiveras PFS och väljs så att det passar motparten. I moderna profiler motsvarar PFS-gruppen ofta DH-gruppen i Phase 1.

Phase 2-Key Life väljs lägre än Phase 1-Key Life. Det gör att nycklarna för nyttotrafiken förnyas oftare än nycklarna för IKE-styrkanalen.

Dead Peer Detection

DPD upptäcker en motpart som inte längre svarar. Det ersätter varken Gateway Monitoring eller ett riktigt applikationstest.

Filial eller Initiator: Re-initiate, så att brandväggen omedelbart försöker etablera en ny anslutning efter en DPD-timeout.
Huvudkontor eller Responder: Disconnect, så att den inaktuella anslutningen stängs. Hold är ett medvetet alternativ när Traffic Selectors ska behållas och inte förhandlas på nytt förrän ny trafik uppstår.
Check peer after every: kontrollintervall i sekunder.
Wait for response up to: Fungerar endast med IKEv1. Med IKEv2 använder SFOS sin interna IKE-retransmission-timeout; det angivna värdet ändrar inte beteendet.

För IPsec-failovergrupper inaktiverar SFOS DPD för de tilldelade anslutningarna och sätter Key negotiation tries till 3. Gruppvillkoret tar då över övervakningen. Den länkade guiden förklarar ordning, Failover condition och Automatic failback; profilvyn visar inte i sig hela det effektiva failoverbeteendet.

Tolka lifetimes och rekeying korrekt

Key life är ingen sessions- eller inaktivitetstimeout. Den begränsar livslängden för en Security Association. Innan den löper ut påbörjas förhandlingen av nya nycklar inom Re-key Margin.

Kortare lifetimes förnyar nycklar oftare, men ger högre beräkningsbelastning och fler tillfällen för kompatibilitets- eller rekeyfel. Längre lifetimes minskar belastningen, men använder nyckelmaterialet längre. Därför är varken det kortaste eller det längsta tillåtna värdet automatiskt det bästa valet.

NIST anger 86400 sekunder för IKE SA och 28800 sekunder för IPsec SA som vanliga riktvärden. Sophos och molnleverantörer använder andra värden beroende på roll och plattform. Siffrorna utgör därför inte en universell SFOS-profil.

Sophos rekommenderar följande för att undvika rekeykollisioner:

Initiators Key Life är lägre än Responders.
Phase 2-Key Life är lägre än Phase 1-Key Life på båda brandväggarna.
Rekeying är aktiverat på minst en sida och uttryckligen tidsbaserat för tredjepartssystem.

Randomiseringen ändrar Re-key Margin, inte hela Key Life. Med åtta timmars Key Life, tio minuters Margin och 20 procents randomisering börjar rekey enligt Sophos mellan 7 timmar och 48 minuter och 7 timmar och 52 minuter.

För leverantörer används deras exakta värden. Det dokumenterade AWS-exemplet använder på Sophos Firewall ungefär Phase 1 28000, Re-key Margin 360, randomisering 50 och Phase 2 3600 sekunder. Det är ett AWS-exempel och inte ett generellt Avanet-standardvärde.

Tilldela profilen och testa säkert

Under ett underhållsfönster tilldelas den nya profilen först endast till den avsedda anslutningen. Dokumentera profilnamn, tidigare värden och rollback i förväg.

För Site-to-Site görs tilldelningen under:

Site-to-site VPN > IPsec

Remote Access IPsec använder också profiler, men har andra begränsningar: den aktuella Sophos Connect-konfigurationen accepterar IKEv1-profiler med inaktiverad DPD eller Disconnect. Den moderna IKEv2-profilen för Site-to-Site ska därför inte återanvändas för Remote Access utan kontroll. Hela processen beskrivs i Konfigurera Sophos Connect i Sophos Firewall. Det särskilda OTP-/rekeyfallet beskrivs i Sophos Connect kopplas från efter cirka fyra timmar.

Efter etableringen kontrolleras status och de senaste IKE-meddelandena skrivskyddat i Advanced Shell:

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

Skapa därefter riktig trafik i båda riktningarna. Byte-räknarna för Child SA måste öka. Testet upprepas efter minst en Phase 2-rekey; först då är lifetimes, PFS och rekeybeteendet faktiskt verifierade.

Typisk felindelning:

Tunneln förblir helt down: kontrollera IKE-version, Phase 1-Encryption, Authentication, DH, Strict Profile, ID och peerautentisering.
NO_PROPOSAL_CHOSEN före Phase 1: jämför Phase 1-proposals.
Phase 1 är aktiv, men Child SA saknas: kontrollera Phase 2-Encryption, Authentication, PFS och Traffic Selectors.
Avbrott efter ungefär samma tid: jämför Key Life, Re-key Margin, randomisering och värdena för Initiator/Responder.
Tunneln är grön, men ingen trafik går igenom: ändra inte profilen först, utan kontrollera brandväggsregler, NAT, routing, returväg och byte-räknare.

Om ändringen orsakar problem återställs anslutningen till den dokumenterade föregående profilen. Services, databaser eller Advanced Shell-konfigurationer behöver inte ändras vid en normal återställning av profilen.