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

En IPsec-profil bestämmer med vilken säkerhetsnivå och under vilka villkor en IPsec-tunnel förhandlas fram. Den anger IKE-version, kryptering, integritet, DH-grupp, PFS, nyckellivslängder, nyckelförnyelse och Dead Peer Detection. Om värdena inte stämmer överens med motparten upprättas tunneln inte eller slutar fungera först vid en senare nyckelförnyelse.

Kort rekommendation för nya Site-to-Site-anslutningar: använd IKEv2, erbjud endast de starka algoritmkombinationer som verkligen behövs, aktivera PFS och nyckelförnyelse och anpassa DPD efter enhetens roll. Om båda parter stöder inställningarna är AES256GCM16 med grupp 19 (ecp256) för DH och PFS Avanets moderna utgångspunkt. Det är varken en standardinställning från Sophos eller en allmän tillverkarrekommendation; motpartens krav har 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 och kan vara tilldelad flera anslutningar. Kontrollera därför vilka anslutningar som använder profilen före varje ändring. Ändra inte en delad system- eller produktionsprofil direkt, utan klona den och testa först kopian endast med den avsedda anslutningen.

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. Beroende på motparten kan ett PFS- eller förnyelseproblem därför visa sig först när Child SA förnyas med CREATE_CHILD_SA. Avanet rekommenderar att minst en Phase 2-förnyelse observeras under acceptanstestet.

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. Onödiga förslag försvårar samordningen och kan göra IKE-paketen onödigt stora. Den specifika SFOS-effekten av det kända problemet NC-136352 förklaras nedan vid fälten för Phase 1.

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. De visar avsiktligt bara valen av algoritmer och funktioner, inte en fullständig profil: livslängder, Re-key Margin, DPD-intervall och DPD-åtgärd beror på motparten och rollen som Initiator eller Responder.

Modern profil för kontrollerade motparter

Om båda sidor stöder aktuella metoder:

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 är en AEAD-metod: den krypterar och skyddar integriteten i ett enda steg. För den här kombinationen väljer SFOS ingen ytterligare Authentication-algoritm som SHA2.

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.

Grupp 19 (ecp256) använder en elliptisk kurva. För moderna motparter under egen kontroll föredrar Avanet den framför de äldre MODP-grupperna. AES128GCM16 är också en aktuell metod. Gällande kryptokrav och profilens svagaste komponent avgör vilken kombination som är tillåten.

Kompatibilitetsprofil utan AES-GCM eller ECP

Om motparten inte stöder AES-GCM eller inte stöder en ECP-grupp använder Avanet denna mer allmänt stödda kombination som kompatibilitetsgrund:

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

Till skillnad från AES-GCM-posterna konfigureras AES256 i SFOS med den separata Authentication-algoritmen SHA2 256. DH14 och PFS14 är Avanets kompatibilitetsval, inte det moderna förstahandsvalet när båda parter stöder grupp 19 (ecp256).

Undvik i nya profiler

DES finns inte med som en IPsec-algoritm som stöds i SFOS 22. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 och DH-grupperna 1, 2 och 5 går fortfarande att välja, men bör inte användas i nya profiler. 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.

De dokumenterade valen i SFOS 22 och 23 beror på IKE-version och fas:

AES128GCM16, AES192GCM16 och AES256GCM16: i IKEv2 Phase 1 och i Phase 2 för båda IKE-versionerna, inte i IKEv1 Phase 1.
AES128GMAC, AES192GMAC och AES256GMAC: endast i Phase 2 för båda IKE-versionerna, inte i Phase 1.
TwoFish och Serpent: i Phase 1 och Phase 2 för IKEv1, inte för IKEv2.

Detta är valbara algoritmer, inte kombinationer som är bundna till särskilda DH-grupper eller hashalgoritmer, och inte rekommendationer för nya profiler.

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.

Begränsningar i den äldre API-dokumentationen för VPNProfile

Vid automatisering av profiler ska den äldre XML-dokumentationen för Add VPN Policy / Edit VPN Policy (VPNProfile) inte behandlas som en direkt översättning av den här UI-guiden. Under KeyingMethod skiljer den mellan Automatic och Manual. Den manuella grenen med LocalSPI, RemoteSPI och inkommande/utgående krypterings- och autentiseringsnycklar är en separat äldre variant av nyckelhantering: dessa nycklar är inte PSK-fält i IPsec-anslutningen eller ett alternativt recept för det moderna IKEv2-exemplet. Det gamla DES/MD5-exemplet och algoritmlistan styrker varken aktuellt stöd eller godkännande för nya profiler.

API-beskrivningen för SFOS 22 och 23 innehåller också motsägelser som måste klarläggas för den specifika builden före automatisering:

PerfectForwardSecrecy anger Enable som standardvärde, men listan över tillåtna värden tillåter endast y/n, och fältet saknas i XML-exemplet. Detta fastställer ingen tillförlitlig serialisering; omvandla inte bara Enable till y.
PFSGroup visar SameAsPhase1 i exemplet, men SameasPhase-I i listan över tillåtna värden. Härled ingen stavning från UI-etiketten och behandla inte de två literalerna som utbytbara.
AuthenticationAlgorithm1 är markerat som obligatoriskt för båda faserna trots att Encryption-listan innehåller GCM. Det klargör inte AEAD-fallet i API:t: tvinga inte fram en extra hash med GCM enbart för att fylla i det obligatoriska fältet.
KeyLife definieras som ett heltal i sekunder, medan exemplet innehåller 3600 seconds. Serialisera inte textsuffixet som en del av API-värdet.

Tills dessa API-detaljer har klarlagts för den installerade builden är det stödda UI-flödet under Profiles > IPsec profiles fortfarande den säkra vägen. De starka förslagen, kloning före ändringar, kontroll efter en nyckelförnyelse och återställning till den dokumenterade föregående profilen gäller fortfarande. Ingen körbar XML-payload för de motsägelsefulla fälten anges här.

Ta bort en profil: kontrollera namnet och känn till gränserna

Den äldre API-översikten listar Delete VPN Policy utöver Add/Edit. Uppgiften gäller IPsec-profilen med det angivna namnet, inte att koppla från en VPN-anslutning. Delete-beskrivningen för SFOS 22 och 23 kräver Name som obligatorisk parameter av typen SCALAR med datatypen STRING; ord i namnet kan skiljas åt med blanksteg. Det är namnet på profilen som ska tas bort, inte motpartens adress eller anslutningens namn.

Kontrollera profilens exakta namn och alla tilldelningar före borttagning, även för Site-to-Site, Remote Access och L2TP. Dokumentera de befintliga profilvärdena och tilldelningarna så att en återställning kan planeras. Ta inte bort profilen om den fortfarande används eller om tilldelningarna är oklara; klarlägg först den planerade övergången för berörda anslutningar. Ta inte bort en profil enbart för att koppla från en tunnel eller ångra en misslyckad profiländring: återgången till den tidigare profilen som beskrivs ovan gäller fortfarande.

Den kortfattade Delete-dokumentationen ger ingen fullständig körbar XML-begäran och förklarar inte hur brandväggen hanterar profiler som fortfarande används eller hur borttagning påverkar aktiva anslutningar. Den listar 200 och 500, men den tillgängliga texten saknar meddelandetexter. Därifrån härleds varken specifika svar eller regler för framgång, fel eller beroenden. Automatisk borttagning förblir därför pausad tills begärans format och beteendet har klarlagts för den installerade builden; ingen Delete-payload anges här.

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. Använd inte Aggressive Mode eftersom autentiseringsinformationen enligt Sophos överförs i klartext.
Key negotiation tries: Fältet anger antalet försök att förhandla tunnelns nyckelutbyte innan brandväggen slutar försöka. 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. Om alternativet stängs av startar den lokala brandväggen ingen nyckelförnyelse, men kan fortfarande svara på motpartens rekeyförfrågningar. Motparten måste då starta förnyelsen; rekeying förblir aktiverat på minst en sida.
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: Avanet låter normalt alternativet vara avstängt. Aktivera det endast om motparten stöder IPComp och bandbreddsbesparingen motiverar den extra komplexiteten.
SHA2 with 96-bit truncation: Alternativet förkortar HMAC-hashvärdena för autentisering. Aktivera endast vid ett dokumenterat kompatibilitetskrav, inte som en allmän säkerhetsförbättring.

Use strict profile utesluter okonfigurerade systemstandardvärden från IKE-utbytet och kan hjälpa när IKE-förslagen ä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. Ange Key life och Re-key margin här i sekunder. I Aggressive Mode går det bara att spara en Encryption/Authentication-kombination per fas; varningen mot detta läge gäller fortfarande.

Välj inte utan vidare det högsta värde som ett inmatningsfält godtar. Re-key Margin måste vara betydligt kortare än Key Life och passa motpartens beteende; randomiseringen ändrar endast denna marginal.

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. Även denna fas tillåter upp till tre Encryption/Authentication-kombinationer. Ange dess egen Phase 2-Key life i sekunder. Rekeyinställningarna i Phase 1, inklusive marginal och randomisering, styr också tidpunkten för Phase 2-rekeying; Phase 2 behåller dock sin egen Key Life.

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.

Under Use PFS group använder Same as phase 1 de DH-grupper som valts i Phase 1 för Phase 2-förhandlingen. Ett uttryckligt gruppval anger i stället Phase 2-DH-gruppen direkt; None stänger av PFS. Att ärva samma grupper betyder inte att PFS kräver ett annat numeriskt gruppvärde.

Sophos rekommenderar att Phase 2-Key Life väljs kortare ä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. Om Phase 2-tunneln har varit inaktiv kontrollerar DPD motpartens tillgänglighet innan data skickas.

Filial eller Initiator: Re-initiate, så att brandväggen omedelbart försöker etablera en ny anslutning efter en DPD-timeout. Antalet Re-initiate-försök beror på Key negotiation tries.
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 IKEv1 beror antalet kontroller på den svarstid som ställts in här.

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 SP 800-77r1 rekommenderar 24 timmar för IKE SA och 8 timmar för IPsec SA. Det är tillverkaroberoende NIST-rekommendationer, inte standardvärden i SFOS. Sophos och molnleverantörer använder andra värden beroende på roll och plattform.

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 Key Life 28000, Re-key Margin 360 och 50 procents randomisering för Phase 1; för Phase 2 används 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.

Profiler gäller även under Remote access VPN > L2TP. L2TP använder Preshared Key eller digitalt certifikat och stöder inte IKEv2. Den moderna Site-to-Site-grundkonfigurationen kan därför inte tillämpas på L2TP.

Efter etableringen använder Avanet endast följande skrivskyddade kommandon i Advanced Shell för att kontrollera status och de senaste IKE-meddelandena:

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-förnyelse. Endast detta extra steg i Avanets acceptanstest kontrollerar även livslängder, PFS och förnyelsebeteende.

Typisk felindelning:

Tunneln upprättas inte alls: 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. Denna återställning kräver inga ändringar i Advanced Shell.