Zrozumienie i bezpieczna konfiguracja profili IPsec Sophos Firewall

Profil IPsec określa, jak bezpiecznie i na jakich warunkach negocjowany jest tunel IPsec. Definiuje wersję IKE, szyfrowanie, integralność, grupę DH, PFS, lifetimes, rekeying i Dead Peer Detection. Jeśli wartości nie pasują do drugiej strony, tunel pozostaje down albo przestaje działać dopiero podczas późniejszego rekeyingu.

Krótka rekomendacja dla nowych połączeń Site-to-Site: używać IKEv2, oferować tylko rzeczywiście potrzebne silne proposals, włączyć PFS i rekeying oraz skonfigurować DPD odpowiednio do roli. Jeśli obie strony obsługują te wartości, AES256GCM16 z DH19 i PFS19 jest nowoczesnym punktem wyjścia. Wymagania dostawcy i drugiej strony zawsze mają jednak pierwszeństwo.

Ten artykuł wyjaśnia profil. Samo połączenie z gateway, identyfikatorami, sieciami, regułami, NAT i routingiem opisano w Konfiguracja VPN IPsec Site-to-Site Sophos Firewall. Jeśli istniejący tunel nie zestawia się lub nie przesyła ruchu, właściwy jest artykuł Sophos Firewall IPsec VPN Troubleshooting.

Czym steruje profil IPsec

Profil zawiera wspólne parametry bezpieczeństwa dla Phase 1 i Phase 2. Jeden profil może być przypisany do wielu połączeń. Właśnie dlatego nie należy spontanicznie zmieniać używanego profilu systemowego lub produkcyjnego: zmiana może wpłynąć na wszystkie powiązane tunele przy następnym zestawieniu lub rekeyingu.

Do profilu nie należą:

publiczny adres peer lub FQDN
Preshared Key, certyfikat lub RSA Key
Local ID i Remote ID
sieci lokalne i zdalne albo Traffic Selectors
reguły firewall, NAT i routing
adres XFRM, SD-WAN Route lub ścieżka failover

Te wartości konfiguruje się w połączeniu IPsec albo powiązanych regułach sieciowych. Zielony status Phase 1 nie potwierdza więc ani poprawności Phase 2, ani prawidłowego routingu i zezwolenia na ruch użytkowy.

Authentication to nie to samo co Authentication type

W profilu IPsec Authentication oznacza algorytm integralności, taki jak SHA2 256. Natomiast w połączeniu IPsec Authentication type określa, czy strony uwierzytelniają się przy użyciu Preshared Key, certyfikatu czy RSA Key.

Pola te mają różne zadania. Poprawne SHA2 256 nie naprawi więc błędnego PSK, a właściwy certyfikat nie zrównoważy niezgodnego Phase 1-proposal.

Zrozumienie Phase 1 i Phase 2

Phase 1 tworzy chronione IKE Security Association. W tym kanale sterującym strony uwierzytelniają się i negocjują kolejne klucze oraz parametry. Zgodne muszą być co najmniej wersja IKE, szyfrowanie, integralność i grupa DH.

Phase 2 tworzy Child lub IPsec Security Associations dla właściwego ruchu użytkowego. Obowiązują tutaj szyfrowanie Phase 2, integralność, PFS i Traffic Selectors. Tunel może zatem pomyślnie zakończyć Phase 1, ale z powodu błędnej wartości PFS lub odmiennej kombinacji Phase 2 nie utworzyć Child SA.

W IKEv2 pierwsze Child SA może powstać już razem z IKE SA. W efekcie problem z PFS lub rekeyingiem może ujawnić się dopiero po kilku godzinach, gdy trzeba odnowić Child SA. Odbiór jest kompletny dopiero po zaobserwowaniu co najmniej jednego rekeyingu bez przerwy.

Uzgodnienie parametrów z drugą stroną

Przed konfiguracją administratorzy obu stron uzgadniają wartości na piśmie. Screenshot często nie wystarcza, ponieważ producenci różnie nazywają tę samą funkcję.

Należy udokumentować co najmniej:

rolę: Initiator, Responder lub zestawianie przez obie strony
wersję IKE, a dla IKEv1 Main lub Aggressive Mode
Phase 1-Encryption, Authentication i grupę DH
Phase 1-Key Life, Re-key Margin i randomizację
Phase 2-Encryption, Authentication, PFS i Key Life
rekeying oparty na czasie oraz stronę, która go rozpoczyna
interwał DPD i działanie po utracie dostępności drugiej strony
znane ograniczenia dostawcy i dozwolone proposals

Nazwa profilu nie musi być identyczna na obu urządzeniach. Liczy się zgodność co najmniej jednej pełnej kombinacji po obu stronach. Większa liczba proposals nie jest automatycznie lepsza: zwiększa powierzchnię ataku i ryzyko błędów, a także może powiększyć pakiety IKE do rozmiaru, przy którym problemem staje się fragmentacja.

Wybór bezpiecznej konfiguracji wyjściowej

Poniższe przykłady są punktami wyjścia Avanet dla nowych połączeń Site-to-Site. Nie zastępują wymagań Azure, AWS, operatora ani firewalla innego dostawcy.

Nowoczesny profil dla kontrolowanych stron

Jeśli obie strony obsługują aktualne mechanizmy:

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 to mechanizm AEAD: szyfruje i chroni integralność w jednym kroku. Dla tej kombinacji nie wybiera się dodatkowego mechanizmu Authentication, takiego jak SHA2. GCM16 oznacza 16-bajtowy Authentication Tag, a nie szyfrowanie 16-bitowe.

W SFOS nie można osobno wybrać Pseudo-Random Function do generowania kluczy IKE. Firewall wyprowadza ją z oferowanych mechanizmów integralności i uzgadnia z drugą stroną.

DH19 używa krzywej eliptycznej i zapewnia dobry kompromis między poziomem bezpieczeństwa, rozmiarem pakietu i obciążeniem obliczeniowym. AES128GCM16 również jest aktualnym mechanizmem i nie jest automatycznie niebezpieczny dla standardowego poziomu bezpieczeństwa 128 bit. O ogólnej sile zawsze decyduje najsłabszy element profilu.

Profil zgodności dla aktualnych urządzeń innych dostawców

Jeśli druga strona nie obsługuje AES-GCM lub grupy ECP, bardziej zgodnym punktem wyjścia jest ta kombinacja:

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

AES działa tutaj w trybie CBC i dlatego wymaga osobnej ochrony integralności SHA2 256. DH14 i PFS14 są wyborem zgodności, a nie preferowanym nowoczesnym wariantem, jeśli oba peers obsługują DH19.

Czego unikać w nowych profilach

W nowych projektach nie należy już używać IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 ani grup DH 1, 2 i 5. Także PFS: None pozostaje wyłącznie udokumentowanym wyjątkiem dla stron, które nie obsługują PFS.

Mimo położenia w polu Phase 2 Encryption mechanizm AES-GMAC nie szyfruje, lecz zapewnia tylko uwierzytelnianie i integralność. W zwykłym poufnym tunelu Site-to-Site stosuje się dlatego AES-GCM albo AES z odpowiednim mechanizmem SHA2.

Odstępstwa legacy należy dokumentować wraz z przyczyną, stroną, której dotyczą, ryzykiem, ownerem i terminem wycofania. Słaba kombinacja nie powinna pozostawać obok silnych proposals tylko dlatego, że tunel również się z nią zestawia. Jako wskazówki techniczne można wykorzystać BSI TR-02102-3 dotyczące IPsec i IKEv2 oraz NIST Guide to IPsec VPNs.

Jeśli środowisko musi spełniać formalne wymagania kryptograficzne, osobna procedura wyjaśnia, jak tryb FIPS 140-3 na Sophos Firewall wpływa na platformy, profile, certyfikaty, backupy i HA. Zgodność z FIPS nie zastępuje świadomego wyboru nowoczesnej wspólnej proposal.

Klonowanie lub tworzenie profilu

Ścieżka menu:

Profiles > IPsec profiles

Dla połączeń Sophos-to-Sophos sparowane profile systemowe stanowią czytelny szablon:

Branch office (IKEv2) dla oddziału inicjującego
Head office (IKEv2) dla odpowiadającej centrali

Odpowiedni profil należy sklonować i jednoznacznie nazwać, na przykład Branch-Zurich-IKEv2. Profil systemowy pozostaje wtedy bez zmian, a podczas rollbacku można ponownie przypisać tunelowi jego poprzedni profil.

General settings

Key exchange: Dla nowych połączeń Site-to-Site IKEv2. IKEv1 tylko dla potwierdzonej strony legacy.
Authentication mode: Występuje tylko w IKEv1. Aggressive Mode nie jest używany, ponieważ informacje uwierzytelniające są przesyłane z mniejszą ochroną.
Key negotiation tries: Sophos zaleca 0. W grupie VPN failover SFOS ustawia jednak efektywną wartość na 3.
Re-key connection: Włączyć, aby przed upływem ważności zostały wynegocjowane nowe klucze Phase 1 i Phase 2. SFOS obsługuje tylko rekeying oparty na czasie.
Use strict profile: Włączyć, jeśli proposals peera są dokładnie znane. SFOS oferuje wtedy wyłącznie skonfigurowane parametry. Dla profili dostawcy najpierw sprawdzić jego zalecenia; oficjalny przykład AWS nie używa tej opcji.
Pass data in compressed format: Zwykle pozostawić wyłączone. Włączać tylko wtedy, gdy korzyść i obsługa po obu stronach są potwierdzone.
SHA2 with 96-bit truncation: Włączać wyłącznie z powodu udokumentowanego wymagania zgodności, a nie jako ogólną poprawę bezpieczeństwa.

Use strict profile ogranicza nieoczekiwane fallbacks i może pomóc przy zbyt dużych IKE-proposals. Nie jest jednak opcją, którą włącza się bez sprawdzenia w każdym profilu dostawcy.

Phase 1

Phase 1 zawiera Key life, Re-key margin, Randomize re-keying margin by, grupę DH oraz do trzech par Encryption i Authentication.

SFOS przyjmuje Key Life od 120 do 86400 sekund, Re-key Margin od 30 do 999 sekund i randomizację od 0 do 100 procent. Formalnie dozwolona wartość nie musi być sensowna: Margin musi pozostać wyraźnie mniejszy od Key Life i pasować do zachowania drugiej strony.

Należy wprowadzić tylko rzeczywiście potrzebne grupy DH i proposals. Znany problem NC-136352 może wystąpić, gdy domyślny profil IKEv2 oferuje tyle grup DH, że pakiet IKE przekracza 1'500 bajtów. Jeśli element pośredni odrzuca fragmenty, Initiator wysyła ponownie, a Responder niczego nie widzi. Dla znanego peera najczystszą konfiguracją jest jedna potwierdzona grupa DH.

Phase 2

Phase 2 zawiera PFS, Key Life oraz Encryption i Authentication dla ruchu użytkowego.

PFS wymusza nową wymianę klucza DH podczas rekeyingu Phase 2. Jeśli długoterminowy klucz zostanie później przejęty, starsze zarejestrowane sesje nie powinny dać się odszyfrować przy użyciu tego samego materiału klucza. Dlatego PFS zostaje włączone i dobrane do drugiej strony. W nowoczesnych profilach grupa PFS często odpowiada grupie DH z Phase 1.

Phase 2-Key Life ustawia się na wartość mniejszą niż Phase 1-Key Life. Dzięki temu klucze ruchu użytkowego są odnawiane częściej niż klucze kanału sterującego IKE.

Dead Peer Detection

DPD wykrywa stronę, która przestała odpowiadać. Nie zastępuje ani Gateway Monitoring, ani rzeczywistego testu aplikacji.

Oddział lub Initiator: Re-initiate, aby po DPD timeout firewall natychmiast spróbował zestawić połączenie ponownie.
Centrala lub Responder: Disconnect, aby zamknąć nieaktualne połączenie. Hold jest świadomą alternatywą, jeśli Traffic Selectors mają pozostać zachowane, a ponowna negocjacja ma nastąpić dopiero po pojawieniu się nowego ruchu.
Check peer after every: interwał kontroli w sekundach.
Wait for response up to: Działa tylko z IKEv1. Dla IKEv2 SFOS używa wewnętrznego IKE retransmission timeout; wpisana wartość nie zmienia tego zachowania.

W grupach failover IPsec SFOS wyłącza DPD dla przypisanych połączeń i ustawia Key negotiation tries na 3. Monitorowanie przejmuje wtedy warunek grupy. Podlinkowany przewodnik wyjaśnia kolejność, Failover condition i Automatic failback; sam widok profilu nie pokazuje całego efektywnego zachowania failover.

Prawidłowa interpretacja lifetimes i rekeyingu

Key life nie jest timeoutem sesji ani bezczynności. Ogranicza czas życia Security Association. Przed jego upływem, w okresie Re-key Margin, rozpoczyna się negocjacja nowych kluczy.

Krótsze lifetimes częściej odnawiają klucze, ale powodują większe obciążenie obliczeniowe i więcej okazji do błędów interoperacyjności lub rekeyingu. Dłuższe lifetimes zmniejszają obciążenie, lecz dłużej wykorzystują ten sam materiał klucza. Ani najkrótsza, ani najdłuższa dozwolona wartość nie jest więc automatycznie najlepsza.

NIST podaje 86400 sekund dla IKE SA i 28800 sekund dla IPsec SA jako często stosowane wartości orientacyjne. Sophos i dostawcy chmurowi używają innych wartości zależnie od roli i platformy. Liczby te nie stanowią zatem uniwersalnego profilu SFOS.

Sophos zaleca, aby uniknąć kolizji rekeyingu:

Key Life urządzenia Initiator jest mniejszy niż urządzenia Responder.
Phase 2-Key Life jest na obu firewallach mniejszy niż Phase 1-Key Life.
Rekeying jest włączony po co najmniej jednej stronie, a na urządzeniach innych dostawców skonfigurowany wyraźnie jako oparty na czasie.

Randomizacja zmienia Re-key Margin, a nie całe Key Life. Przy ośmiu godzinach Key Life, dziesięciu minutach Margin i randomizacji 20 procent rekeying rozpoczyna się według Sophos między 7 godziną 48 minutą a 7 godziną 52 minutą.

Dla dostawców stosuje się ich dokładne wartości. Udokumentowany przykład AWS używa na Sophos Firewall około Phase 1 28000, Re-key Margin 360, randomizacji 50 i Phase 2 3600 sekund. Jest to przykład AWS, a nie ogólny default Avanet.

Przypisanie profilu i bezpieczne testowanie

Nowy profil zostaje w oknie serwisowym przypisany najpierw tylko do przewidzianego połączenia. Wcześniej należy udokumentować nazwę profilu, dotychczasowe wartości i rollback.

Dla Site-to-Site profil przypisuje się w:

Site-to-site VPN > IPsec

Remote Access IPsec również używa profili, ale ma inne ograniczenia: aktualna konfiguracja Sophos Connect akceptuje profile IKEv1 z wyłączonym DPD lub Disconnect. Nowoczesnego profilu Site-to-Site IKEv2 nie należy więc bez sprawdzenia używać ponownie dla Remote Access. Pełną procedurę opisuje Konfiguracja Sophos Connect na Sophos Firewall. Szczególny przypadek OTP/rekeyingu opisano w Sophos Connect rozłącza połączenie po około czterech godzinach.

Po zestawieniu należy w Advanced Shell tylko odczytać status i ostatnie komunikaty IKE:

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

Następnie generuje się rzeczywisty ruch w obu kierunkach. Liczniki bajtów Child SA muszą rosnąć. Test należy powtórzyć po co najmniej jednym rekeyingu Phase 2; dopiero wtedy lifetimes, PFS i zachowanie rekeyingu są rzeczywiście sprawdzone.

Typowe przypisanie błędów:

Tunel pozostaje całkowicie down: sprawdzić wersję IKE, Phase 1-Encryption, Authentication, DH, Strict Profile, ID i uwierzytelnianie peer.
NO_PROPOSAL_CHOSEN przed Phase 1: porównać Phase 1-proposals.
Phase 1 działa, brak Child SA: sprawdzić Phase 2-Encryption, Authentication, PFS i Traffic Selectors.
Rozłączenie po podobnym czasie: porównać Key Life, Re-key Margin, randomizację i wartości Initiator/Responder.
Tunel jest zielony, ale ruch nie przepływa: nie zmieniać najpierw profilu, lecz sprawdzić reguły firewall, NAT, routing, ścieżkę powrotną i liczniki bajtów.

Jeśli zmiana powoduje problemy, do połączenia ponownie przypisuje się udokumentowany poprzedni profil. Przy normalnym rollbacku profilu nie trzeba zmieniać services, baz danych ani konfiguracji Advanced Shell.