Przejdz do tresci
Avanet

Zrozumienie i bezpieczna konfiguracja profili IPsec Sophos Firewall

Sophos Firewall

Profil IPsec określa, z jakim poziomem zabezpieczeń i na jakich warunkach zestawiany jest tunel IPsec. Definiuje wersję IKE, szyfrowanie, integralność, grupę DH, PFS, czasy ważności kluczy, odnawianie kluczy i Dead Peer Detection. Jeśli wartości nie pasują do drugiej strony, tunel nie zostanie zestawiony albo przestanie działać dopiero podczas późniejszego odnawiania kluczy.

Krótka rekomendacja dla nowych połączeń Site-to-Site: używać IKEv2, oferować tylko rzeczywiście potrzebne, silne zestawy algorytmów, włączyć PFS i odnawianie kluczy oraz dobrać DPD do roli urządzenia. Jeśli obie strony obsługują te ustawienia, nowoczesnym punktem wyjścia Avanet jest AES256GCM16 z grupą 19 (ecp256) dla DH i PFS. Nie jest to ustawienie domyślne Sophos ani ogólne zalecenie producenta; pierwszeństwo mają wymagania drugiej strony.

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 Phase 1 i Phase 2 i może być przypisany do wielu połączeń. Przed każdą zmianą należy więc sprawdzić, które połączenia z niego korzystają. Zamiast bezpośrednio edytować współdzielony profil systemowy lub produkcyjny, należy go sklonować i początkowo przetestować kopię tylko z przewidzianym połączeniem.

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ć razem z IKE SA. Zależnie od drugiej strony problem z PFS lub odnowieniem kluczy może więc ujawnić się dopiero przy odnawianiu Child SA za pomocą CREATE_CHILD_SA. Avanet zaleca, aby podczas odbioru obserwować co najmniej jedno odnowienie Phase 2.

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. Zbędne propozycje utrudniają uzgodnienia i niepotrzebnie powiększają pakiety IKE. Konkretny wpływ znanego problemu NC-136352 na SFOS opisano niżej przy polach Phase 1.

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. Celowo pokazują tylko dobór algorytmów i funkcji, a nie kompletny profil: czasy ważności, Re-key Margin, interwał i działanie DPD zależą od drugiej strony oraz roli Initiator lub Responder.

Nowoczesny profil dla kontrolowanych stron

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

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 to mechanizm AEAD: szyfruje i chroni integralność w jednym kroku. Dla tej kombinacji SFOS nie wybiera dodatkowego algorytmu Authentication, takiego jak SHA2.

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

Grupa 19 (ecp256) korzysta z krzywej eliptycznej. W przypadku nowoczesnych, kontrolowanych urządzeń Avanet preferuje ją zamiast starszych grup MODP. AES128GCM16 również jest współczesnym algorytmem. Dopuszczalną kombinację wyznaczają obowiązujące zasady kryptograficzne i najsłabszy element profilu.

Profil zgodności bez AES-GCM lub ECP

Jeśli druga strona nie obsługuje AES-GCM albo nie obsługuje grupy ECP, Avanet przyjmuje jako punkt wyjścia tę szerzej obsługiwaną kombinację:

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

W odróżnieniu od wpisów AES-GCM, w SFOS AES256 konfiguruje się z osobnym algorytmem Authentication SHA2 256. DH14 i PFS14 są wyborem Avanet zapewniającym zgodność, a nie preferowanym nowoczesnym wariantem, gdy obie strony obsługują grupę 19 (ecp256).

Czego unikać w nowych profilach

DES nie figuruje w SFOS 22 na liście obsługiwanych algorytmów IPsec. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 oraz grupy DH 1, 2 i 5 nadal można wybrać, lecz nie należy ich stosować w nowych profilach. 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.

Udokumentowane opcje w SFOS 22 i 23 zależą od wersji IKE i fazy:

  • AES128GCM16, AES192GCM16 i AES256GCM16: w Phase 1 IKEv2 oraz w Phase 2 obu wersji IKE, ale nie w Phase 1 IKEv1.
  • AES128GMAC, AES192GMAC i AES256GMAC: tylko w Phase 2 obu wersji IKE, nie w Phase 1.
  • TwoFish i Serpent: w Phase 1 i Phase 2 IKEv1, nie IKEv2.

Są to algorytmy do wyboru, a nie kombinacje przypisane do konkretnych grup DH lub algorytmów skrótu ani zalecenia dla nowych profili.

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. Nie należy używać Aggressive Mode, ponieważ według Sophos informacje uwierzytelniające są przesyłane jawnym tekstem.
  • Key negotiation tries: Pole określa liczbę prób negocjacji wymiany kluczy tunelu, po których firewall przestaje próbować. 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. Wyłączenie tej opcji uniemożliwia lokalnemu firewallowi inicjowanie odnowienia, ale nadal może on odpowiadać na żądania odnowienia drugiej strony. Druga strona musi wtedy inicjować odnowienie; rekeying pozostaje włączony po co najmniej jednej stronie.
  • 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: Avanet zwykle pozostawia tę opcję wyłączoną. Należy ją włączać tylko wtedy, gdy druga strona obsługuje IPComp, a oszczędność pasma uzasadnia dodatkową złożoność.
  • SHA2 with 96-bit truncation: Ta opcja skraca wartości skrótu HMAC używane do uwierzytelniania. Włączać wyłącznie z powodu udokumentowanego wymagania zgodności, a nie jako ogólną poprawę bezpieczeństwa.

Use strict profile wyklucza z wymiany IKE nieskonfigurowane wartości domyślne systemu i może pomóc przy zbyt dużych propozycjach IKE. 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. Wartości Key life i Re-key margin wpisuje się tutaj w sekundach. W Aggressive Mode można zapisać tylko jedną kombinację Encryption/Authentication na fazę; ostrzeżenie przed tym trybem nadal obowiązuje.

Nie należy po prostu wybierać największej wartości przyjmowanej przez pole. Re-key Margin musi być wyraźnie krótszy niż Key Life i odpowiadać zachowaniu drugiej strony; randomizacja zmienia tylko ten margines.

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 1500 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. Ta faza również pozwala na maksymalnie trzy kombinacje Encryption/Authentication. Jej własne Key life Phase 2 wpisuje się w sekundach. Ustawienia rekeyingu z Phase 1, w tym margines i randomizacja, sterują również czasem odnowienia Phase 2; Phase 2 zachowuje jednak własne Key Life.

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.

W Use PFS group opcja Same as phase 1 wykorzystuje grupy DH wybrane w Phase 1 do negocjacji Phase 2. Wybranie konkretnej grupy ustawia bezpośrednio grupę DH Phase 2; None wyłącza PFS. Dziedziczenie tych samych grup nie oznacza, że PFS wymaga innego numeru grupy.

Sophos zaleca, aby Phase 2-Key Life był krótszy 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. Jeśli tunel Phase 2 pozostawał bezczynny, DPD sprawdza dostępność drugiej strony przed wysłaniem danych.

  • Oddział lub Initiator: Re-initiate, aby po DPD timeout firewall natychmiast spróbował zestawić połączenie ponownie. Liczba prób Re-initiate zależy od Key negotiation tries.
  • 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. Dla IKEv1 liczba kontroli zależy od ustawionego tutaj czasu odpowiedzi.

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 SP 800-77r1 zaleca 24 godziny dla IKE SA i 8 godzin dla IPsec SA. Są to niezależne od producenta zalecenia NIST, a nie wartości domyślne SFOS. Sophos i dostawcy chmurowi stosują inne wartości zależnie od roli i platformy.

Sophos zaleca, aby uniknąć kolizji rekeyingu:

  1. Key Life urządzenia Initiator jest mniejszy niż urządzenia Responder.
  2. Phase 2-Key Life jest na obu firewallach mniejszy niż Phase 1-Key Life.
  3. 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 dla Phase 1 wartości Key Life 28000, Re-key Margin 360 i randomizacji 50 procent; dla Phase 2 obowiązuje 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.

Profile mają zastosowanie także w Remote access VPN > L2TP. L2TP używa Preshared Key lub certyfikatu cyfrowego i nie obsługuje IKEv2. Nowoczesnej konfiguracji wyjściowej Site-to-Site nie można więc zastosować do L2TP.

Po zestawieniu tunelu Avanet używa w Advanced Shell wyłącznie poniższych poleceń odczytujących 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 odnowieniu Phase 2. Dopiero ten dodatkowy etap odbioru Avanet sprawdza także czasy ważności, PFS i przebieg odnawiania kluczy.

Typowe przypisanie błędów:

  • Tunel w ogóle się nie zestawia: sprawdzić wersję IKE, Phase 1-Encryption, Authentication, DH, Strict Profile, ID i uwierzytelnianie drugiej strony.
  • 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 tym wycofaniu zmiany nie trzeba niczego modyfikować w Advanced Shell.