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.

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. Använd inte Aggressive Mode eftersom autentiseringsinformationen enligt Sophos överförs i klartext.
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: 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: 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.

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.

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.

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.

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

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.