Instalacja i konfiguracja elementów zdalnego dostępu z wykorzystaniem L2TP/IPsec i PKI, cz. I
Zawartość strony
Wstęp
Celem tego artykułu jest ułatwienie instalacji i konfiguracji elementów niezbędnych lub przynajmniej zalecanych podczas implementacji zdalnego dostępu do zasobów firmy, przy zastosowaniu takich technologii, jak L2TP/IPsec i PKI. Wykorzystanie certyfikatów do zestawiania i zabezpieczania połączeń VPN jest obecnie najsilniejszą formą uwierzytelniania wspieraną przez system Windows Server 2003. Zarówno gdy chodzi o połączenie pojedynczego użytkownika z serwerem, jak i całych sieci.
Środowisko testowe zostało przedstawione na poniższym rysunku (Rys. 1). Podczas testu zainstalujemy CA i IAS na kontrolerze domeny. Jednak w środowisku produkcyjnym, w miarę możliwości, zalecana jest izolacja poszczególnych ról. Mamy więc zdalnego klienta, którego chcemy podłączyć do naszej sieci wykorzystując do tego celu tunel L2TP/IPsec. Dodatkowo uwierzytelnienie i zabezpieczenie tunelu ma być realizowane przy pomocy certyfikatów.
Rys. 1. Środowisko testowe.
Zanim zabierzemy się za instalację i konfigurację poszczególnych elementów, kilka słów na temat technologii z których będziemy korzystać.
Co tak naprawdę kryje się pod określeniem „L2TP over IPSec” ?
L2TP/IPsec, jako alternatywa dla PPTP, oferuje znacznie wyższy i szerszy poziom zabezpieczenia komunikacji w sieciach VPN, włączając w to:
| • | Integralność danych (Integrity). Gwarancja, że dane nie zostały podmienione lub zniekształcone podczas przesyłania; |
| • | Poufność danych (Confidentiality). Szyfrowanie danych przed ich wysłaniem do sieci; |
| • | Niezaprzeczalność (Non-repudiation). Oznacza, że strony połączenia nie mogą zanegować wysłanych przez siebie danych; |
| • | Atak powtórzeniowy (Replay-attack / man-in-the-middle attack). Ochrona przed nieautoryzowaną retransmisją, np. danych uwierzytelniających. |
L2TP, czyli Layer 2 Tunneling Protocol, powstał z połączenia właściowści dwóch innych protokołów wykorzystywanych do tunelowania ramek PPP (Point-to-Point Protocol): Cisco Layer 2 Forwarding (L2F) i Point-to-Point Tunneling Protocol (PPTP). Oprócz PPP może współpracować także z innymi protokołami warstwy drugiej modelu OSI, takimi jak Frame Relay, X.25, Ethernet, czy ATM. L2TP jest obecnie uznanym standardem jeżeli chodzi o kapsułkowanie ramek PPP w sieciach IP. Komunikacja odbywa się na porcie 1701 protokołu UDP (User Datagram Protocol). L2TP wspiera uwierzytelnienie wzajemne (mutual authentication) obu stron tunelu, jednak nie definiuje mechanizmów zabezpieczających ten tunel. Do tego właśnie wykorzystywany jest IPsec.
Rys. 2. Pakiet L2TP.
IPsec, to właściwie cały zestaw protokołów (ISAKMP/IKE, Oakley, IPsec AH, IPsec ESP), który umożliwia uwierzytelnienie i szyfrowanie komunikacji pomiędzy dwoma węzłami na poziomie pakietu.
Zestawienie połączenia przy pomocy IPsec jest dwufazowe. W części pierwszej IKE negocjuje ustawienia bezpiecznego kanału (Security Association - SA). Uwierzytelnia obie strony połączenia (shared secret, certyfikaty X.509) i określa algorytm szyfrowania (DES, 3DES) i mieszania (MD5, SHA). Pomyślne zakończenie tej fazy zaowocuje utworzeniem bezpiecznego kanału ISAKMP SA.
W fazie drugiej określane są protokoły, jakie mają być wykorzystane do ochrony ruchu IP. Mowa o Authentication Headers (AH), Encapsulating Security Payload (ESP) lub kombinacji obu. Również w tej fazie negocjowane są algorytmy szyfrowania i haszowania.
Należy pamiętać o tym, że ze względu na specyfikę działania, AH nie może być wykorzystany jeżeli pakiety w którymś momencie muszą być przesłane przez urządzenie NAT. Dzieje się tak dlatego, że zabezpieczenia AH obejmują cały pakiet, włącznie z nagłówkiem IP i jakakolwiek zmiana w pakiecie jest niedopuszczalna. Poza tym, AH oferuje uwierzytelnianie i integralność pakietów, ale nie zapewnia ich poufności.
W odróżnieniu od AH, ESP dodatkowo (oprócz uwierzytelniania i integralności) szyfruje zawartość pakietu algorytmem DES lub 3DES. Natomiast nagłówek IP nie jest chroniony, dzięki czemu jest możliwe przesyłanie ruchu IPsec zabezpieczonego ESP poprzez urządzenia NAT, przy założeniu obsługi protokołu NAT-T na obu końcówkach tunelu.
Rys. 3. Pakiet L2TP zaszyfrowany IPSec ESP.
Kombinacja technologii oferowanych przez L2TP i IPsec umożliwia nam bezpieczne połączenie ze sobą tak całych sieci, jak i pojedynczych komputerów. Również – a może zwłaszcza – gdy musimy zapewnić bezpieczną wymianę danych wykorzystując publiczne kanały komunikacyjne (Internet).
W przeszłości, barierą dość często ograniczającą wykorzystanie tego duetu, był brak wsparcia dla NAT. Jednak problem ten został rozwiązany przy pomocy nowego protokołu NAT-Traversal (NAT-T), który umożliwił przepływ ruchu IPsec poprzez urządzenia pełniące funkcje NAT. Nie zapominajmy o tym, że Windows 2000 Server nie oferuje wsparcia dla tego protokołu. Krótko mówiąc, jeżeli nasz serwer VPN zostanie skonfigurowany na systemie Windows 2000 Server znajdującym się za NAT-em, to wykorzystanie L2TP/IPSec będzie niemożliwe.
Rys. 4. Pakiet IPsec NAT-T.
Przejdźmy teraz do konfiguracji naszego środowiska.
Kontroler domeny - przygotowanie AD
W naszej domenie tworzymy grupę globalną „VPN Users” (Rys. 5) i dodajemy do niej użytkowników, którzy będą korzystać z dostępu zdalnego.
Rys. 5. Grupa globalna „VPN Users”.
Grupę tę wykorzystamy przy tworzeniu „Remote Access Policy” podczas konfiguracji „Internet Authentication Server”. Dodatkowo upewniamy się, że na zakładce Dial-in we właściwościach kont użytkowników zaznaczona jest opcja „Control Access Through Remote Access Policy” (Rys. 6).
Rys. 6. Opcja „Control Access Through Remote Access Policy”.
W przypadku gdy opcja ta będzie nieaktywna (Rys. 7.), powinniśmy zwrócić uwagę na poziom funkcjonalności domeny, gdyż kontrola dostępu poprzez „Remote Access Policy” nie jest możliwa w sytuacji, gdy AD działa w trybie mixed mode.
Rys. 7. Opcja „Control Access Through Remote Access Policy” nieaktywna.
Więcej informacji na ten temat: Dial-In Options Unavailable with Active Directory in Mixed Mode (j. ang.).
To, w jakim trybie działa nasze AD, możemy sprawdzić klikając w przystawce Active Directory Users and Computers (ADUC) prawym przyciskiem myszy na nazwie naszej domeny i wybierając z menu „Properties” (Rys. 8).
Rys. 8. Tryb działania AD.
Zmianę z „Windows 2000 mixed mode” na „Windows 2000 native” lub „Windows Server 2003”, przeprowadzimy klikając w ADUC prawym na nazwie naszej domeny i wybierając „Raise Domain Functional Level...” (Rys. 9).
Rys. 9. Zmiana trybu działania AD.
Po zakończonej konfiguracji wszystkich elementów opisanych w tym artykule, nadanie nowym użytkownikom prawa do zdalnego logowania (lub pozbawienie go), będzie się sprowadzało jedynie do modyfikacji listy członków grupy „VPN Users”. No i ewentualnie „drobnego szczegółu” pod postacią importu certyfikatów na komputerach nowych klientów VPN.
Internet Information Services (IIS)
Jedną z funkcjonalności CA, z której będziemy za chwilę korzystać, jest Certificate Services Web Enrollment Support. Komponent ten umożliwia generowanie żądań i instalację certyfikatów z poziomu przeglądarki internetowej. Jednak do poprawnego działania wymaga on instalacji na serwerze IIS z włączoną obsługą Active Server Pages (ASP).
Aby zainstalować IIS na naszym DC...
1. | Przechodzimy do Start -> Control Panel -> Add or Remove Programs. |
2. | W Add or Remove Programs klikamy na Add/Remove Windows Components. |
3. | W oknie Windows Components Wizard zaznaczamy komponent Application Server i zatwierdzamy przyciskiem Next. |
Certificate Authority (CA)
Najszybciej, i z pewnością najtaniej, skorzystamy z dobrodziejstw technologii PKI (Public Key Infrastructure), instalując własny Urząd Certyfikacyjny. Mamy do wyboru dwa rodzaje CA: Enterprise i Stand-alone.
Wymagania jakie muszą być spełnione, aby instalacja Enterprise root CA zakończyła się sukcesem:
| • | Domena Active Directory |
| • | Usługa DNS |
| • | Serwer na którym instalujemy CA musi być członkiem domeny |
| • | Użytkownik przeprowadzający instalację musi należeć do grupy „Enterprise Admins” |
Instalacja Certificate Authority
1. | Przechodzimy do Start -> Control Panel -> Add or Remove Programs. |
2. | Następnie klikamy na Add/Remove Windows Components. |
3. | W oknie Windows Components Wizard zaznaczamy Certificate Services. |
4. | Po zaznaczeniu komponentu CA, otrzymamy ostrzeżenie informujące nas o ograniczeniach związanych z ewentualną chęcią zmiany nazwy serwera, bądź domeny do której należy serwer CA. Upewnijmy się więc wcześniej, że posiada on właściwą nazwę i że nie mamy w planach odłączenia go od domeny, lub przeniesienia do innej. Oczywiście akceptujemy ostrzeżenie klikając Yes. |
5. | W następnym oknie określamy typ CA. Zostawiamy zaznaczone: Enterpise root CA. |
6. | Okno CA Identifying Information pozwala nam na wybranie nazwy dla naszego Urzędu Certyfikacyjnego. Wpisujemy wybraną nazwę, np. Firma CA. |
7. | W następnych oknach konfiguracyjnych akceptujemy standardowe ustawienia. |
8. | W trakcie instalacji otrzymamy ostrzeżenie o konieczności chwilowego zatrzymania Internet Information Services (Rys. 10). |
Rys. 10. Ostrzeżenie o konieczności chwilowego zatrzymania Internet Information Services.
Jak i o włączeniu Active Server Pages (ASP) (Rys. 3-2.). Wyrażamy akceptację, w obu przypadkach klikając Yes.
Rys. 11. Ostrzeżenie o włączeniu Active Server Pages (ASP).
Jeżeli nasze „środowisko zdalnego dostępu” będzie wystarczająco „statyczne”, to po wystawieniu certyfikatów niezbędnych do połączeń VPN, możemy podnieść bezpieczeństwo serwera CA, deaktywując obsługę skryptów ASP w IIS. W przypadku gdy jedynym powodem instalacji IIS była funkcjonalność naszego CA, jeszcze lepszym rozwiązaniem będzie całkowite zatrzymanie strony „Default Web Site”.
Po zakończeniu instalacji CA, sprawdzamy dostępność komponentu Certificate Services Web Enrollment Support. W tym celu uruchamiamy przeglądarkę i przechodzimy do http://localhost/certsrv. Na ekranie powinna pojawić się strona naszego świeżo zainstalowanego CA (Rys. 12).
Rys. 12. Strona naszego świeżo zainstalowanego CA.
Teraz dodamy szablon, na podstawie którego wygenerujemy żądanie wydania certyfikatu do zabezpieczania połączeń IPsec. Niestety, możliwość definiowania własnych szablonów i korzystania z nich otrzymujemy dopiero w sytuacji, gdy nasze CA zainstalujemy na Windows Server 2003 Enterprise Edition. Z powodów głównie finansowych, nie zawsze dysponujemy tą wersją systemu, dlatego skorzystamy z tego, co jest dostępne w wersji Standard.
Szablon IPSec (Offline request)
1. | Uruchamiamy przystawkę CA. Start -> Control Panel -> Administrative Tools -> Certification Authority. |
2. | Zaznaczamy Certificate Templates. |
3. | Po kliknięciu prawym na Certificate Templates, wybieramy z menu New -> Certificate Template to Issue. |
4. | Zaznaczamy szablon IPSec (Offline request) (Rys. 13) i zatwierdzamy klikając OK. |
Rys. 13. Szablon IPSec (Offline request).
Przeczytaj pozostałe części tego artykułu
| • | Instalacja i konfiguracja elementów zdalnego dostępu, cz. II |
 | Dariusz Kiszkiel (MCSE+S) |