VPN i Linux I


Security Association (SA)

Jeżeli ma być stosowana kombinacja ESP/AH, partnerzy komunikacji muszą najpierw uzgodnić mechanizmy i algorytmy haszowania, uwierzytelniania i szyfrowania. Ponadto, obie strony muszą dysponować odpowiednimi kluczami i informacjami o ich terminie ważności.

Komputery biorące udział w połączeniu IPsec uzgadniają te parametry każdorazowo podczas nawiązywania połączenia. Dochodzi do zawarcia pewnego rodzaju umowy między stronami - ma ona postać Security Association (SA, RFC 2408 und 2409). Jeżeli wymagany jest najwyższy poziom bezpieczeństwa, strony mogą na nowo uzgadniać klucze również w czasie trwania połączenia. Ponowne uzgodnienie kluczy może następować w określonych odstępach czasu lub po przesłaniu określonej ilości danych.

Dodatkowo, przez indywidualną parametryzację każdego połączenia Security Association umożliwia również kontrolę dostępu na poziomie użytkownika. Poprzez odpowiednie zapisy w SA można przydzielić każdemu z uczestników komunikacji własne klucze, procedury uwierzytelniania i hasła.

IKE - Internet Key Exchange

Internet Key Exchange Protocol (IKE, RFC 2409) definiuje przebieg negocjowania IPsec-SA wraz z odpowiednimi mechanizmami. Procedura ta nazywana jest również Internet Security Association and Key Management Protocol (ISAKMP). Rozwiązuje ona problem budowy poufnego połączenia między dwoma komputerami, które nie mają żadnych informacji o partnerze, nie dysponują zatem również kluczami.

W fazie 1 IKE (main mode) strony uzgadniają najpierw na przemian możliwą konfigurację SA wraz z algorytmami haszowania, uwierzytelniania i szyfrowania. Inicjator połączenia składa stronie przeciwnej (responder) odpowiednią propozycję, która może zawierać wiele wariantów. Responder wybiera spośród propozycji tę, która najbardziej mu odpowiada i przesyła stosowną odpowiedź. Na zakończenie strony uzgadniają na przemian, posługując się algorytmem Diffie-Hellmana, tajny klucz, który posłuży do szyfrowania dalszej komunikacji.

Dotyczy to w szczególności następującej teraz wymiany parametrów identyfikacyjnych (ID), które każdy z nadawców sygnuje swoim kluczem publicznym. Opcjonalnie można również przesłać certyfikat. Jeżeli zostanie przesłany certyfikat, odbiorca ustali na jego podstawie klucz publiczny nadawcy, a na tej podstawie zweryfikuje jednoznacznie podpis i tożsamość nadawcy. W przypadku braku certyfikatu odbiorcy potrzebna jest lokalna lista parametrów identyfikacyjnych (ID) i przynależnych kluczy; na tej podstawie może ustalić odpowiedni klucz publiczny.

W ten sposób zagwarantowana jest prawidłowa tożsamość stron i poufność połączenia. Może teraz rozpocząć się faza 2 IKE, tak zwany quick mode. W tej fazie tworzone jest właściwe połączenie IPsec poprzez uzgodnienie parametrów i mechanizmów ESP i AH. W trakcie trwania jednej sesji IPsec quick mode można powtarzać dowolną ilość razy; pozwala to wygenerować nowe klucze dla obu stron.

Certyfikaty X.509

Jak już wspomniano, najlepsza metoda wymiany kluczy publicznych to certyfikaty X.509 (RFC 2459). Tego rodzaju certyfikat w jednoznaczny sposób przyporządkowuje klucz publiczny do użytkownika. Za wiarygodność certyfikatu odpowiada jego wystawca - urząd certyfikacji (Certification Authority, CA).

Certyfikat zawiera dane na temat zastosowanego algorytmu podpisu, wystawcy, właściciela i terminu ważności. Najważniejszą informacją, jaką zawiera, jest klucz publiczny właściciela. Urząd certyfikacji podpisuje certyfikat w ten sposób, że tworzy wartość hasz ze wszystkich danych i podpisuje ją własnym kluczem publicznym. Aby zatem sprawdzić ważność danego certyfikatu, odbiorca musi odszyfrować podpis kluczem publicznym urzędu i na koniec porównać z wartością hasz.

Kluczową kwestią w tej procedurze jest oczywiście wiarygodność urzędu certyfikacji. Można ją podwyższyć, zlecając podpisanie certyfikatu innemu urzędowi itd. W ten sposób powstaje tak zwany łańcuch zaufania, na którego końcu znajduje się główny urząd certyfikacji (root CA). Ten ostatni sam podpisuje swój certyfikat. Łańcuch certyfikatów jest więc na tyle wiarygodny, na ile wiarygodny jest Root CA.

W przypadku certyfikatów do połączeń VPN nie stanowi to jednak problemu. Administrator przeciwnej sieci sam mianuje się Root CA i certyfikuje zarówno bramę bezpieczeństwa (security gateway), jak i potencjalnego partnera komunikacji.

IPsec i Free S/WAN

Jak opisaliśmy na początku, Free S/WAN to kompletna implementacja IPsec do Linuksa, mniej więcej gotowa do użytku. Większość dystrybucji zawiera ten pakiet, jednak doświadczenie wskazuje, że najlepsze efekty daje instalacja najnowszej wersji Free S/WAN na najnowszym jądrze.

W naszym przykładzie posłużyliśmy się dystrybucją Red Hat Linux 7.2 z jądrem 2.4.18 oraz pakietem Free/WAN w wersji 1.97 (ftp://ftp.xs4all.nl/pub/crypto/freeswan/ ). W razie potrzeby można zainstalować Free S/WAN również na jądrach z serii 2.2. W tym przypadku potrzebny jest jednak co najmniej Linux 2.2.19. Należy poza tym wziąć pod uwagę, że w praktyce stosuje się najczęściej kombinację VPN/brama/firewall. Tu najlepsze wydaje się jądro 2.4. ze względu na zintegrowaną architekturę netfilter.

Jest ponadto niewielka luka w zestawie funkcji Free S/WAN - nie obsługuje on certyfikatów X.509. Pomoc w tym względzie zapewnia łata opracowana przez szwajcarski uniwersytet w Winterthur -http://www.strongsec.com/de/ .

Instalacja

W celu instalacji należy rozpakować pliki źródłowe jądra zwyczajowo do /usr/scr/Linux, zaś Tarball Free S/WAN do /usr/src/freeswan-numerwersji. Na koniec skonfiguruj jądro za pomocą make menuconfig lub make xconfig. Oprócz opcji samego systemu skonfiguruj również ustawienia Free S/WAN w Networking Options / IPsec Options (Free S/WAN). Ustawienia domyślne przewidują instalację wszystkich dostępnych funkcji i tak też należy to pozostawić.

Aby zainstalować łatę X.509, rozpakuj odpowiedni Tarball i skopiuj plik freeswan.diff do katalogu źródłowego Free S/WAN. Polecenie patch -p1 < freeswan.diff spowoduje odpowiednie modyfikacje.

Na koniec skompiluj zmodyfikowane jądro, co najprościej wykonać poleceniem make kinstall w katalogu źródłowym Free S/Wan. Po wpisaniu nowego jądra do bootmanagera i restarcie komputera można naocznie sprawdzić skuteczność wprowadzonych modyfikacji - dmesg w wierszu poleceń powinien spowodować inicjalizację KLIPS i Pluto. Dodatkowo, o ile S/WAN działa poprawnie, polecenie ipsec-version powinno zwracać numer wersji, zaś whack - status - raport statusu Pluto.

Może się jeszcze okazać, że trzeba popracować trochę nad poziomami uruchomieniowymi (runlevell). Ponieważ S/WAN dodaje do interfejsów ethernetowych eth0 i eth1 jeszcze ipsec0, system powinien uruchomić najpierw networking, następnie Free S/WAN, a na koniec iptables. Natomiast nasz Red Hat 7.2 uruchomił najpierw firewalla Free S/WAN i dopiero odpowiednia modyfikacja w /etc/rc/d zmusiła go do poprawnej pracy.