Administrator zabezpieczając sieć stara się maksymalnie ograniczyć dostęp do niej z zewnątrz. Zwykle robi to poprzez zastosowanie zapór oraz wykorzystanie stref DMZ, by zapobiec bezpośredniemu kontaktowi z kluczowymi zasobami sieci wewnętrznej. Czasami jednak zachodzi potrzeba zapewnienia wybranym użytkownikom o wiele szerszego dostępu do tejże sieci wewnętrznej poprzez zastosowanie połączeń VPN. I o ile administrator w dużym stopniu może kontrolować konfigurację komputerów znajdujących się w sieci wewnętrznej to konfiguracja komputera użytkownika łączącego się za pośrednictwem VPN zwykle pozostaje dla niego dużą zagadką. By tę sytuację zmienić wymyślono mechanizm kwarantanny.

Kwarantanna jest stanem, w którym następuje weryfikacja komputera pod kątem wymagań konfiguracyjnych narzuconych przez administratora sieci, do której klient nawiązuje połączenie VPN. Daje ona możliwość zweryfikowania podstawowych elementów bezpieczeństwa dotyczących stacji roboczych takich jak na przykład obecności zainstalowanych poprawek systemowych, aktualności bazy wirusów czy też stanu zapory.

Należy tu jednak wyraźnie zaznaczyć, że kwarantanna nie jest panaceum na wszystko. Nie zapobiegnie na przykład nieuprawnionemu dostępowi do sieci wynikającemu z zastosowania słabych haseł w procesie uwierzytelniania. Jej zadaniem jest zapewnienie, by uwierzytelnieni użytkownicy, nieświadomi niepoprawnej konfiguracji swych komputerów nie stanowili dodatkowego zagrożenia dla sieci wewnętrznej. Wypełnia, więc pewną lukę w strukturze bezpieczeństwa sieci związaną z dostępem VPN.

Celem tego artykułu jest zarysowanie pewnej idei działania jak i wdrażania mechanizmu kwarantanny. Zakładam przy tym, że czytelnik dysponuje już pewną podstawową wiedzą pozwalającą mu poprawnie skonfigurować serwer RRAS dla dostępu VPN, a tym samym potrafi tworzyć polisy czy też profil połączenia VPN za pomocą narzędzia CMAK (czyli Connection Manager Administrator Kit). Albowiem na podstawie znajomości tej konfiguracji budowany będzie opisany w artykule mechanizm kwarantanny. Jeżeli jednak byłyby jakieś problemy z tymi wstępnymi ustawieniami to odsyłam do źródeł podanych poniżej tego artykułu a w szczególności do materiału zawartego pod numerem [1], który to krok po kroku, w dużej mierze graficznie, przeprowadza przez cały proces konfiguracji.

Ponieważ w artykule tym nawiązuję również do serwera ISA 2004, który jak wiadomo nie ma polskojęzycznego odpowiednika, tak więc by zachować zgodność językową będę opierać się na anglojęzycznym nazewnictwie, co znajdzie również odzwierciedlenie w zrzutach ekranu pochodzących z angielskiej wersji systemu Windows 2003.

Ostatnia rzecz, na którą pragnę zwrócić uwagę to, iż na dole artykułu są podane źródła, do których będę odwoływać się w treści tegoż artykułu.

Idea działania

W największym uproszczeniu proces kwarantanny, w którym klient VPN bierze udział można opisać następująco:

1. klient wykorzystując wcześniej utworzony profil kwarantanny łączy się z serwerem RRAS
2. gdy pomyślnie przejdzie proces uwierzytelniania przechodzi w stan kwarantanny w którym przebywa maksymalnie przez czas określony poprzez parametr MS-Quarantine-Session-Timeout oraz ma pewien ograniczony dostęp do elementów sieci wewnętrznej określony przez parametr MS-Quarantine-IPFilter
3. na komputerze klienta następuje uruchomienie skryptu kwarantanny, którego zadaniem jest sprawdzenie, czy komputer poddawany kwarantannie spełnia wymogi, by mógł być mu przyznany normalny dostęp VPN; jeżeli tak jest skrypt uruchamia polecenie wywołujące komponent rqc.exe, którego zadaniem jest przesłanie do serwera ciągu znaków określanego jako shared key
4. nasłuchujący na serwerze RRAS komponent rqs.exe odbiera shared key i następuje konfrontacja, czy przesyłany przez klienta shared key zgadza się z tym, który przechowywany jest na serwerze
5. jeżeli shared key na serwerze zgadza się z tym przesłanym od klienta klient wychodzi ze stanu kwarantanny i staje się pełnoprawnym klientem VPN
6. jeżeli natomiast shared key się nie zgadza lub nie zostanie przesłany w określonym przez parametr Quarantine-Session-Timeout czasie połączenie zostaje przerwane

Etapy konfiguracji

Wykorzystanie funkcji kwarantanny po raz pierwszy stało się możliwe w systemie Windows 2003 po zainstalowaniu Windows Server 2003 Resource Kit Tools. Wraz z pojawieniem się Service Packa 1 dla Windows 2003 instalacja ta nie jest już wymagana, gdyż wintegrowano w niego narzędzia kwarantanny. Teraz instalacja elementów kwarantanny na serwerze wymaga tylko doinstalowania poprzez „Add or remove programs” dodatkowego elementu systemu a mianowicie „Remote Access Quarantine Service” dostępnego w grupie komponentów „Network Services”. W celu późniejszego stworzenia profilu połączenia należy również doinstalować element „Connection Manager Administrator Kit” dostępny w grupie komponentów „Management and Monitoring Tools”.

Przeprowadzenie powyższej instalacji skutkuje pojawieniem się nowej usługi systemowej o nazwie „Remote Access Quarantine Agent”. Należy tutaj zwrócić uwagę na jedną bardzo ważną rzecz. Usługa ta domyślnie jest ustawiona jako usługa startowana manualnie. By móc korzystać z kwarantanny należy ją zatem wystartować.

Jeżeli powyższe działania instalacyjne zostały już pomyślnie zrealizowane można przejść do kluczowych elementów implementacji kwarantanny. Odpowiednio do przedstawionego wcześniej schematu działania kwarantanny proces jej konfiguracji składa się z następujących etapów:

1. utworzenie odpowiedniej polisy kwarantanny na serwerze RRAS
2. ustawienie w kluczu rejestru serwera: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet wartości tak zwanego dzielonego klucza (ang. shared key)
3. stworzenie profilu za pomocą Connection Manager Administrator Kit, który potem zostanie rozdystrybuowały pomiędzy klientów VPN

Postaram się teraz bliżej przedstawić każdy z wymienionych powyżej etapów.

Przebieg tworzenia polisy kwarantanny rozpoczyna się tak samo jak tworzenie każdej nowej polisy, czyli poprzez wybór z gałęzi „Remote Access Policies” opcji „New Remote Access Policy”.

Opracowując nową polisę kwarantanny warto jednak zwrócić uwagę na parę elementów specyficznych dla tego rodzaju polisy.

Po pierwsze należy określić, którzy użytkownicy będą podlegać kwarantannie. Bo przecież nie wszyscy podlegać jej muszą – np. sam administrator niekoniecznie . Choć kwarantanna w większości przypadków połączeń jest działaniem zalecanym to czasami warto pozostawić możliwość dostępu wyjętego spod działania kwarantanny. Wszystko to po to by nie odciąć sobie całkowicie zdalnego dostępu do sieci na wypadek nieprzewidzianych okoliczności. Na przykład wyobraźmy sobie sytuację, gdy drugi administrator, nie uprzedziwszy nas o tym zmienił na serwerze shared key. Co gorsza, gdy na skutek nagłej potrzeby dostępu do firmy dzwonimy do niego (o godzinie 1 w nocy ;)) w tej sprawie on nie może sobie przypomnieć jaki klucz ustawił. Skutek? Jeżeli VPN to jedyna nasza forma dostępu do sieci to w tym właśnie momencie zostaliśmy całkowicie odcięci.

Kolejną rzeczą, która wyróżnia polisę kwarantanny jest konieczność ustawienia dwóch atrybutów, którymi są: MS-Quarantine-Session-Timeout i MS-Quarantine-IPFilter. By tego dokonać należy:

1. na polisie kwarantanny wybrać „Edit profile”
   
   
   
2. przejść do zakładki „Advanced"
   
   
   
3. wybierając przycisk „Add” dodać atrybuty: MS-Quarantine-Session-Timeout i MS-Quarantine-IPFilter; pierwszy z nich określa czas w którym klient pozostaje w stanie kwarantanny i by go skonfigurować należy w polu „Attribute value” wpisać liczbę sekund przez którą maksymalnie komputer może przebywać w tym stanie; drugi atrybut natomiast definiuje do jakich elementów sieci wewnętrznej (i z wykorzystaniem jakich protokołów) klient będzie miał dostęp podczas przebywania w kwarantannie (np. można mu tu przyznać dostęp do serwera WWW z którego będzie mógł ściągnąć wymagane poprawki); obowiązkowo należy tu dodać protokół TCP o numerze portu 7250 za pomocą którego klient kwarantanny będzie kontaktował się z serwerem w celu przesłania shared key; by dokonać takiej konfiguracji należy po wybraniu atrybutu MS-Quarantine-IPFilter kliknąć przycisk „Input filters” a następnie dodać protokół opisany następująco:
   
   Protocol: TCP
   Destination port: 7250

Na koniec należy pamiętać o zaznaczeniu opcji „Permit only the packets listed below”.

Jak widać na podstawie ostatniego podpunktu po raz kolejny następuje nawiązanie do wykorzystania shared key. Może, więc warto by wreszcie było bliżej wyjaśnić, czym on jest i czemu ma służyć. Gdy pierwszy raz natknęłam się na to pojęcie skojarzenie, jakie mi się nasunęło było takie, iż jest to coś analogicznego do shared key stosowanego w dostępie bezprzewodowym z wykorzystaniem WEP. Czyli, że jest to tajny, możliwie jak najbardziej skomplikowany ciąg znaków w celu zapewnienia bezpiecznej komunikacji. I od razu wyjaśnię, żeby nie było wątpliwości, tego rodzaju pojmowanie znaczenia shared key jest błędem! Ten klucz nie musi być ani skomplikowany, ani nawet ściśle tajny, bo zupełnie inne jest jego przeznaczenie.

Klucz ten określa po prostu wersję wykorzystywanego właśnie profilu kwarantanny. Profil w miarę potrzeb może się zmieniać, dlatego skojarzony z profilem identyfikator wersji jest niezbędny, by sprawdzić czy klient rzeczywiście korzysta z aktualnego profilu. Jeżeli przesyłany od klienta shared key odpowiada shared key na serwerze oznacza to, więc nie tylko to, że klient spełnia wymogi kwarantanny (takie jak np. zainstalowane poprawki systemowe), ale również wymogi te zostały zweryfikowane na podstawie najbardziej aktualnego profilu kwarantanny.

Na serwerze wersję tą (czyli shared key) określa się poprzez ustawienie wartości następującego klucza rejestru:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet

Natomiast po stronie klienta wersja ta zawarta jest w profilu kwarantanny.

Profil taki tworzony jest za pomocą narzędzia Connection Manager Administrator Kit. Tym, co odróżnia konfigurację profilu na potrzeby kwarantanny od standardowej konfiguracji jest między innymi określenie „Custom actions”, czyli sekwencji działań wykonywanych przed i po nawiązaniu połączenia VPN. Zwykle sprowadza się to do wskazania głównego skryptu kwarantanny wraz z parametrami. Skrypt ten będzie wykonywany po uzyskaniu połączenia jako akcja „post-connect”. Jego zadaniem jest sprawdzenie czy komputer klienta VPN spełnia wymogi, co do konfiguracji, a jeśli tak następuje przesłanie za pośrednictwem komponentu rqc.exe shared key do serwera.

I tutaj właśnie przy określaniu parametrów skryptu możemy wpaść w pewną pułapkę. Wcześniej, na początku tego rozdziału, wspomniałam, iż przed włączeniem opcji kwarantanny do Service Packa 1 była ona dostępna dzięki zainstalowaniu Resorce Kit. Fakt ten wymieniony został nie tyle z powodu jakiegoś szczególnego zamiłowania do historii, co dlatego, iż nieznajomość jego może prowadzić do nieporozumień. Dlaczego? Ponieważ większość dostępnych w Internecie źródeł opisujących konfigurację kwarantanny oparto na wersji rqc.exe zawartej w Resorce Kit. Nawet w nowych materiałach, nie jest wyraźnie zaznaczone, że pomiędzy tymi wersjami istnieją pewne różnice. A są to różnice niemałe, dotyczą albowiem składni polecenia rqc.exe, a ściślej parametrów z którymi jest ono w skrypcie wywoływane. W przypadku korzystania z komponentu zawartego w Resorce Kit jest ona następująca:

rqc <ConnName> <TunnelConnName> <Port> <Domain> <Username> <String>

gdzie:

ConnName – nazwa połączenia RRAS; najczęściej reprezentowana poprzez zmienną %DialRasEntry%
TunnelConnName - nazwa tunelu RRAS; najczęściej reprezentowana poprzez zmienną %TunnelRasEntry%
Port – numer portu z którego korzysta mechanizm kwarantanny
Domain – nazwa domeny
Username – nazwa użytkownika
String – tutaj podajemy shared key

Podczas, gdy w przypadku komponentu rqs.exe dostarczanego z Service Pack 1, a więc wersji najbardziej aktualnej na której też opiera się w dalszej części ten artykuł jest:

rqc.exe /conn ServiceProfileName [/domain DomainName] [/user UserName] [/port Po rtNumber] [/sig Signature] [/log LogFileName] [/?]

gdzie:

/conn – poprzedza nazwę połączenia
/domain – poprzedza nazwę domeny
/user – poprzedza nazwę użytkownika
/port – poprzedza numer portu używanego do połączenia z serwerem
/sig – poprzedza shared key
/log – poprzedza wiadomość wysyłaną do serwera kwarantanny

Stosownie, więc do tej składni w linii „Parametrs” możemy, podać następujące przykładowe wartości parametrów:

%ServiceDir% %ServiceName% "version1" %Domain% %UserName%

by następnie zgodnie z powyżej przedstawioną konwencją składni wywołać je w skrypcie w postaci:

%1\rqc.exe /conn %2 /sig %3 /domain %4 /user %5

Informacja o przedstawionej powyżej różnicy przydatna również będzie w dalszej części konfiguracji profilu, w której to określamy dodatkowe pliki dołączane do profilu. Plikiem, który obowiązkowo należy tu wskazać jest właśnie plik rqc.exe – a ponieważ w artykule zakładamy, iż cała konfiguracja opiera się na pliku rqc.exe zawartym w Service Packu 1, jako lokalizację pliku podajemy katalog c:\Program Files\CMAK\Support. Dodatkowo należy tu dołączyć wszystkie inne pliki, do których odwoływać się będzie skrypt kwarantanny.

Przykładowe skrypty, które mogą zostać wykorzystane w procesie kwarantanny można między innymi znaleźć pod adresem wymienionym w źródle numer [2]. Pliki te mogą posłużyć jako wzorce w celu weryfikacji takich elementów jak np. aktualna baza wirusów, stan firewalla czy też obecność wymaganych poprawek. Co do ostatniego z nich, czyli pliku dotyczącego poprawek o nazwie CheckHotFixes.vbs mam małe zastrzeżenie. Jest w nim niecodzienny „błąd” wynikający według mnie ze zbyt optymistycznego nastawienia autora, co do ilości mogących się pojawić poprawek systemowych. W pliku jest ona ograniczona do liczby 40, co już dzisiaj jest liczbą niewystarczającą. Lecz dość łatwo to naprawić podnosząc wartość obydwu deklaracji znajdujących się w linii:

Dim sInstalledQFE(40), sReqdQFE(40)

Bez tego zabiegu skrypt będzie, jak łatwo się domyślić, wskazywał nieprawidłowy wynik inspekcji.

Jak widać choćby na powyższym przykładzie skrypty te wymagają wcześniejszego przetestowania i wprowadzenia ewentualnych modyfikacji zależnie od potrzeb. Moim zdaniem szkoda, że mechanizm kwarantanny nie jest pod tym względem trochę bardziej zautomatyzowany chociażby w odniesieniu do tak podstawowych zagadnień jak sprawdzanie brakujących poprawek. Ale kto wie może kiedyś tak się stanie?

Poza tym obecny skryptowy model ma jeszcze jeden słaby punkt. Skrypt z którego wywoływane jest polecenie rqc.exe może być przecież przez wystarczająco sprytnego użytkownika zmodyfikowany. Osoba taka może na przykład usunąć z pliku wszystkie warunki sprawdzające konfigurację, pozostawiając wyłącznie linię z poleceniem rqc.exe niezbędną do przesłania shared key. Zapewne użytkowników o tym stopniu rozwoju jest bardzo niewielu, ale trzeba być świadomym, że kwarantanna nie jest zabezpieczeniem doskonałym i chociażby w ten dość prosty sposób można ją ominąć.

Konfiguracja klientów VPN

Mamy już skonfigurowany pod potrzeby kwarantanny serwer, utworzony profil, pozostał już tylko ostatni malutki krok ku wdrożeniu całego rozwiązania – dostarczenie profilu do użytkowników i zainstalowanie go przez nich. Może to się odbywać różnymi drogami, na przykład poprzez e-mail czy też stronę WWW. Bez względu jednak na to jak to zrobimy użytkownik zawsze powinien mieć dostęp do najnowszej wersji profilu. Po to by w razie wprowadzenia zmian do profilu, a co za tym idzie zmiany shared key, miał zawsze możliwość zainstalowania najnowszej wersji. Zresztą potrzeba taka powinna być wyrażona odpowiednią obsługą błędów w skrypcie post-connect, informującą w takiej sytuacji użytkownika, co ma zrobić (czyli, że np. ma wejść pod wskazany adres WWW i ściągnąć nowy profil). W sumie niezbyt to skomplikowane (przede wszystkim z punktu widzenia administratora ;)), ale jeżeli konfiguracja profilu zmienia się często staje się to uciążliwe.

Może, więc ten mechanizm można by było jakoś uprościć, zmniejszyć do minimum konieczność ingerencji ze strony użytkownika w proces aktualizowania profilu. W jaki sposób? Na przykład poprzez zautomatyzowanie aktualizacji tych elementów profilu, które naprawdę często się zmieniają jak chociażby lista aktualnych poprawek. Jak widać na podstawie materiałów wymienionych w źródle [2] lista ta jest osobnym plikiem. Jeżeli przy każdym połączeniu VPN następowałoby jego automatyczne ściągnięcie z serwera www, byłaby ona w ten sposób zawsze aktualna. Przykładowy skrypt mogący posłużyć temu celowi podany jest chociażby w źródle [3]. Jest to dość wygodne rozwiązanie, a jak można zauważyć nie wymaga nawet zmiany shared key.

Jest to tylko jeden z pomysłów, które można tu zastosować. Lecz warto się nad takimi drobnostkami zastanowić, by jak najbardziej uprościć życie użytkownikom a co za tym idzie samemu sobie.

Kwarantanna a ISA Server 2004

Kwarantanna jest narzędziem na tyle uniwersalnym, iż została zintegrowana również z jednym z moich ulubionych produktów – a mianowicie ISA Server 2004. Ogólna zasada działania jest tu taka sama jak w przypadku samodzielnego serwera RRAS. Tak, więc wiele wymienionych wcześniej wskazówek konfiguracyjnych i tu znajduje swoje analogie zastosowania. By jednak wszystko poprawnie współpracowano z serwerem ISA wymagane jest uruchomienie zawartego w Remote Access Quarantine Tool for ISA Server 2004 skryptu ConfigureRQSForISA.vbs, który odpowiednio przygotowuje serwer do współdziałania z kwarantanną (można go ściągnąć spod adresu wymienionego w źródle [4]). Zresztą serwer ISA sam w sobie dostarcza interfejs graficzny pozwalający bardzo prosto określić odpowiednie elementy związane z procesem kwarantanny. Ponieważ jednak artykuł ten nie dotyczy ściśle serwera ISA, by się nie rozpisywać za bardzo wszystkich zainteresowanych taką konfiguracją odsyłam do artykułu wymienionego w źródle [5].

Warto może jeszcze tylko podkreślić prostotę, jaką zapewnia ISA w stosunku do konfiguracji reguł dostępu klientów kwarantanny a także przejrzysty monitoring stanu klienta kwarantanny.

Podsumowanie

Mam nadzieję, że artykuł ten, choć w małym stopniu przysłuży się do przybliżenia procesu kwarantanny a także być może podjęcia decyzji o jego wdrożeniu. Myślę, że warto. Tym bardziej, że ogólna idea działania kwarantanny jest aktualna nie tylko w chwili obecnej, ale jak sądzę posłużyła również jako inspiracja ku tworzonej właśnie technologii Network Access Protection.

Źródła

1. http://www.microsoft.com/downloads/details.aspx?FamilyID=fe902704-52dd-4bbe-8a75-f8fbb76cd28a&DisplayLang=en
2. http://www.microsoft.com/downloads/details.aspx?FamilyID=a290f2ee-0b55-491e-bc4c-8161671b2462&displaylang=en
3. http://cwashington.netreach.net/depo/view.asp?Index=1080&ScriptType=vbscript
4. http://www.microsoft.com/downloads/details.aspx?FamilyID=17897522-AB69-46E0-9860-E2D9EC8CA122&displaylang=en
5. http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/vpnroamingquarantine.mspx

Autor: Barbara Wróbel

Spis treści

• Idea działania
• Etapy konfiguracji
• Konfiguracja klientów VPN
• Kwarantanna a ISA Server 2004
• Podsumowanie

Artykuł autorstwa Czytelnika portalu opublikowany w ramach akcji Popisz się. Nie odpowiadamy za prezentowane treści.