Opublikowany na:

Wstęp do Network Access Protection w Windows Server 2008

Jednym z najbardziej pracochłonnych i ciężkich problemów administratora jest  zadbanie by klienci łączący się z siecią prywatną nie stanowili zagrożenia. Wiele problemów i zagrożeń jest powodowanych poprzez działanie w sieci komputerów klienckich niespełniających norm bezpieczeństwa. Komputer, którego system operacyjny nie jest zaktualizowany, nie posiada oprogramowania antywirusowego z aktualną bazą sygnatur lub posiada wyłączonego firewalla, może stać się przyczyną dużych kłopotów w całej sieci. W wielu organizacjach proces aktualizacji ochrony stacji roboczych użytkowników jest prowadzony ręcznie, bez użycia mechanizmów automatyzacji tych zadań, nie mówiąc już o monitorowaniu stanu komputerów przyłączających się do sieci. Równie często można spotkać gdy sytuację, w której osoby pracujące zdalnie łączą się z różnymi niezaufanymi sieciami, a następnie łączą się z siecią macierzystą organizacji. Zdarza się również, że do sieci wewnętrznej muszą zostać podłączone komputery gości lub komputery prywatne pracowników, których stanu zabezpieczeń nie można stwierdzić. Te wszystkie sytuacje stanowią zagrożenie dla zasobów przedsiębiorstw . Oczywiście można próbować ograniczyć takie zagrożenia tworząc różne podsieci i ograniczać ich powiązania, lecz jest to pracochłonna, nie zawsze skuteczna metoda. Windows Server 2008 rozwiązuje te problemy dostarczając mechanizm Network Access Protection, poniekąd znany już w Windows Server 2003 jako Network Access Quarantine.

Network Access Protection (NAP) należy rozumieć jako mechanizm zarówno kontroli stanu systemów jak i w konfiguracji, pomagający administratorowi sieci w zapewnieniu przestrzegania założeń polityki zabezpieczeń dla komputerów klienckich. Z wykorzystaniem NAP można stworzyć bezpieczne, zautomatyzowane środowisko, w którym każdy komputer na bieżąco podlega kontroli bezpieczeństwa. Największą zaletą NAP jest natychmiastowa reakcja na zmianę stanu zabezpieczeń. W odróżnieniu od mechanizmów firm trzecich, które w większości sprawdzają stan klienta tylko podczas uzyskiwania połączenia, NAP nie przestaje monitorować systemu.

Mówiąc o Network Access Protection w Windows Server 2008 należy zdać sobie sprawę z trzech podstawowych aspektów związanych z tym mechanizmem. Określenie stanu zdrowia, odbywa się podczas połączenia się komputera z siecią. Stan ten jest określany poprzez sprawdzenie zgodności ustawień zabezpieczeń z politykami określonymi przez administratora. Dodatkowo można określić działania, które zostaną podjęte w zależności od zdiagnozowanego stanu zdrowia. Przykładowo komputery, które uzyskają certyfikat zdrowia otrzymują pełny dostęp do zasobów sieci, a pozostałe są podłączane do sieci z ograniczeniami, które pozwalają tylko na poprawę ich stanu zdrowia (np. aktualizację definicji programu antywirusowego), ale zabronią dostępu do zasobów sieci. Zgodność z politykami zdrowia, jest ustalana na podstawie porównania aktualnego stanu zabezpieczeń z określonymi przez administratora wymogami. W przypadku niespełnienia wymogów zdrowia, można wdrożyć mechanizmy automatycznej naprawy np. z użyciem Microsoft Systems Management Server 2003 lub System Center Configuration Manager 2007. Ograniczony dostęp, uzyskują komputery nie spełniające wymogów, może być on realizowany poprzez czasowe ograniczenie dostępu lub określenie zasobów, do jakich będzie miał dostęp komputer bez certyfikatu zdrowia. Dobrym rozwiązaniem jest wyodrębnienie w sieci „czyśćca” (strefy kwarantanny), w którym udostępnione będą zasoby konieczne do poprawy stanu zdrowia niebezpiecznych klientów. Można to zrealizować za pomocą serwerów korekcyjnych lub w mniej  zaawansowanej konfiguracji poprzez udostępnienie zasobów zawierających aktualizacje, bazy sygnatur etc.

Zrozumieć NAP

Komponentami NAP odpowiadającymi za śledzenie zmian stanu zdrowia oraz sprawdzenie jest zgodności z politykami są System Health Agent (SHA) oraz System Health Validator (SHV). W systemach Windows Vista oraz Windows XP z Service Pack 3 znajduje się wbudowany komponent Windows Security Health Validator SHA, który odpowiedzialny jest za monitorowanie Centrum Zabezpieczeń i w ten sposób sprawdzający stan zdrowia komputerów. Windows Server 2008 posiada podobny komponent: Windows Security Health Validator SHV. Za ograniczenie dostępu i wymuszenie zachowania zgodnego z polityką są Komponenty Wymuszające, wśród których można wyróżnić Enforcement Client (EC) oraz Enforcement Server (ES).

Komputery z systemami Windows XP z Service Pack 3, Windows Vista oraz Windows Server 2008 posiadają wsparcie dla NAP dla różnych rodzajów dostępu do sieci i komunikacji: ruch z użyciem IPSec, autentykacja IEEE 802.1x, połączenia zdalnego dostępu VPN oraz przydzielanie adresów za pośrednictwem DHCP. W przypadku Windows Vista i Windows Server 2008 dostępna jest także współpraca NAP z Terminal Server Gateway. Wymienione wcześniej mechanizmy można wykorzystać do ograniczenia dostępu lub komunikacji dla komputerów, które nie uzyskały certyfikatu zdrowia. Istotnym faktem jest możliwość użycia wszystkich lub tylko wybranych mechanizmów, które dalej nazywane będą metodami wymuszenia. Określenie polityk odbywa się za pośrednictwem Network Policy Server (NPS), następcy Internet Authentication Service (IAS) w Windows Server 2003.

Przykładowe zastosowanie Mechanizmów NAP w oparciu o wymuszenie IPSec można przedstawić następująco (Rysunek1).

1. Komputer żąda dostępu do sieci, następnie przedstawia swój stan zdrowia, wraz z prośbą o certyfikat.
2. HRA komunikuje się z Network Policy Server w celu sprawdzenia zgodności stanu zdrowia klienta z politykami.
3. W przypadku, gdy stan zdrowia nie jest zgodny z politykami NPS przesyła odpowiedź do HRA, że klient wymaga uaktualnienia.
4. HRA nie przydziela certyfikatu klientowi i pozostawiając go w strefie kwarantanny odsyła by pobrał poprawki.
5. Klient komunikuje się z serwerem korygującym tzw. Remediation Server w celu pobrania poprawek.
6. Serwer korygujący (Remediation Server) przesyła potrzebne poprawki.
7. Komputer żąda dostępu oraz przedstawia swój stan zdrowia, wraz z prośbą o certyfikat.
8. HRA komunikuje się z Network Policy Server w celu sprawdzenia zgodności stanu zdrowia klienta z politykami.
9. NPS potwierdza zgodność z politykami i zezwala na przyznanie certyfikatu zdrowia.
10. Komputer otrzymuje certyfikat zdrowia.
11. Następuje zezwolenie na dostęp do strefy chronionej.

Rysunek 1 –Proces uzyskiwania certyfikatu zdrowia.

Krótko o architekturze

Ponieważ o architekturze NAP można znaleźć wiele artykułów szczegółowo opisujących jej składniki, w tej części artykułu przedstawione zostaną najważniejsze założenia i komponenty potrzebne do zrozumienia działania tego mechanizmu.

Architekturę platformy NAP po stronie klienta można podzielić na pięć warstw (Rysunek 2):

• Warstwa klientów wymuszania ochrony dostępu do sieci (NAP EC)
• Warstwa agentów kondycji systemu (SHA)
• Agent NAP
• Interfejs programistyczny NAP SHA API
• Interfejs programistyczny NAP EC API

Klienci NAP EC (Network Access Protection Enforcement Client) odpowiedzialni są za obsługę poszczególnych rodzajów komunikacji oraz sposoby uzyskiwania dostępu do sieci. Dla każdego z tych rodzajów może zostać użyty oddzielny NAP EC. Przykładowo podczas wykorzystywania wymuszenia VPN i DHCP użyte będą dwa moduły NAP EC.

Agenci SHA (System Health Agent) odpowiedzialni są za sprawdzenie kondycji poszczególnych elementów systemu np. sygnatur antywirusowych. Każdy z nich może być przypisany do serwera korygującego (Remediation Server).

Agent NAP monitoruje kondycję klienta NAP oraz uławia komunikację pomiędzy klientami wymuszenia, a agentami kondycji systemu i jest ponadto odpowiedzialny za:

• Odbieranie raportów kondycji od agentów kondycji systemu oraz ich przechowywanie
• Dostarczanie bieżącej listy raportów kondycji
• Przekazanie informacji o zmianach statusu dostępu klienta do sieci agentom kondycji systemu
• Przekazywanie odpowiedzi SoHR z serwera do agentów kondycji systemu

SHA API umożliwia:

• Rejestrację agentów systemu w Agencie NAP klienta
• Sygnalizowanie kondycji klienta
• Odpowiadanie na zadawane pytania o kondycję systemu
• Przekazywanie przez agentów NAP instrukcji serwerów korygujących do SHA

NAP EC API odpowiada za:

• Rejestrację klientów NAP EC w Agencie NAP klienta
• Wysyłanie pytań o kondycję klienta
• Przesyłanie instrukcji z serwerów korygujących do agentów NAP

Uwaga: Zarówno agenci kondycji systemu jaki i klienci wymuszania ochrony dostępu do sieci mogą być także dostarczani przez firmy trzecie.

Rysunek 2 – Architektura platformy NAP po stronie klienta.

Proces określenia stanu kondycji klienta rozpoczyna się od stworzenia raportu o kondycji (Statement of Health – SoH) przez agentów kondycji systemu, który jest przekazywany do Agenta NAP. Każda zmiana kondycji skutkuje stworzeniem nowego raportu SoH. Agent NAP ustala kondycję systemu poprzez analizę wszystkich raportów o kondycji poszczególnych elementów systemu.

Architekturę platformy NAP po stronie serwerów można podzielić na cztery podstawowe warstwy (Rysunek 3):

• Warstwa komponentów sprawdzania kondycji (SHV)
• Interfejs programistyczny API modułów sprawdzania kondycji (SHV API)
• Komponent administracyjny NAP
• NPS (Network Protection Server)

SHV, czyli warstwa modułów sprawdzania kondycji (System Health Validator), w której każdy moduł sprawdzania kondycji zajmuje się innymi wymogami oraz może komunikować się z przypisanym serwerem NPS.

SHV, API umożliwia:

• Rejestrację modułów kondycji w komponencie administracyjnym NAP
  
• Odbieranie raportów o kondycji z serwera
  
• Przekazywanie informacji z serwerów korygujących do odpowiednich agentów NAP
  

Komponent Administracyjny NAP odpowiada za komunikację pomiędzy serwerem NPS a modułami sprawdzania kondycji.

NPS odbiera komunikaty RADIUS Access-Request o kondycji poszczególnych komputerów i przekazuje je do komponentu administracyjnego NAP.

Uwaga: zalecaną konfiguracją jest stosowanie kilku serwerów NAP, z których każdy obsługuje inny sposób uzyskiwania dostępu do sieci lub metodę komunikacji w sieci oraz serwery NPS odpowiedzialne za weryfikację i korekcję kondycji klientów.

Rysunek 3 – Architektura platformy NAP po stronie serwerów.

Dokładny opis procesu komunikacji poszczególnych komponentów architektury platformy NAP można znaleźć w artykule „Komunikacja między klienckimi a serwerowymi komponentami platformy NAP” pod adresem:

http://www.microsoft.com/poland/technet/bazawiedzy/centrumrozwiazan/cr196_01.mspx

Instalacja NAP

Network Access Protection jest jedną z roli Windows Server 2008, a jej instalacja nie różni się znacząco do innych. Przed rozpoczęciem instalacji należy rozważyć zagadnienia związane z budowaniem środowiska NAP: czy wszystkie zadania będzie wykonywał jeden serwer, czy istnieje już w środowisku Urząd Certyfikacji itp. Do instalacji roli NAP oraz innych składników można użyć konsoli Server Manager oraz kreatora Add Roles Wizard (Przykład1).

Przykład 1 – Instalacja NAP z wykorzystaniem Ad Roles Wizard.

Podczas instalacji roli istnieje możliwość wyboru 3 składników wykorzystywanych przez NAP (Przykład 2). Network Policy Server odpowiedzialny między innymi za sprawdzanie zgodności stanu zdrowia komputera z politykami NAP, Health Registration Authority, czyli podstawowa rola NAP oraz Host Credential Authorization Protocol umożliwiający współpracę NAP z mechanizmem Network Access Control (sprzętowe rozwiązanie NAP firmy Cisco).

Przykład 2 – Składniki instalacji.

Network Access Protection do wydawania certyfikatów zdrowia wykorzystuje Urząd Certyfikacji (Przykład 3). Jeśli w środowisku nie istnieje jeszcze żaden CA można wykonać instalację tej roli, w innym przypadku konieczne jest zdefiniowanie CA (można to także uczynić po instalacji w konsoli konfiguracyjnej).

Przykład 3 – Określenie Urzędu Certyfikacji dla NAP.

Network Access Protection może pracować poza domena. W tym kroku instalacji możliwe jest określenie, na jakich warunkach komputery kliencie mogą komunikować się z Health Registration Authority – czy muszą być uwierzytelnione w domenie (Przykład 4). Wykorzystanie opcji zezwalającej na dostęp anonimowy jest dobrym rozwiązaniem, gdy istnieje konieczność obsługi komputerów gości.

Przykład 4 – Określenie wymogu autoryzacji do komunikacji z HRA.

Ostatni etap konfiguracji NAP i jego składników podczas instalacji to wybór rodzaju certyfikatu dla połączeń SSL oraz podjęcie decyzji, czy mają być używane przez HRA i HCAP do komunikacji z klientami (Przykład 5).

Przykład 5 – Wybór rodzaju połączeń do komunikacji HRA i HCAP z klientami.

Możliwości konfiguracji Network Access Protection

Wybierając rolę Network Policy and Access Services z konsoli Server Manager można zapoznać się z listą zdarzeń w usługach, zatrzymać lub wykonać ponowny rozruch określonych usług systemowych oraz doinstalować dodatkowe składniki tej roli (Przykład 6). Osoby mające styczność z NAP po raz pierwszy powinny być zainteresowane modułem Zasobów i Wsparcia.

Przykład 6 – Podstawowe opcje roli Network Policy and Access Protection.

Dla poprawnego funkcjonowania NAP konieczne jest wykonanie podstawowej konfiguracji. Z poziomu NPS (Network Policy Server) można wybrać rodzaj konfiguracji: standardowy pozwalający na określenie rodzaju komunikacji i uzyskiwania dostępu do sieci, który będzie wykorzystany przez NAP oraz zaawansowany zezwalający chociażby na konfigurację współpracy z serwerem RADIUS (Przykład 7).

Przykład 7 – Konfiguracja Network Policy Server.

Wspomniana wcześniej konfiguracja standardowa jest miejscem, w którym określane są sposoby uzyskiwania dostępu do sieci oraz metody komunikacji w sieci z użyciem, których pracować będzie NAP. Do wyboru istnieje sześć opcji: DHCP, IPsec, IEEE 802.1X (dla sieci przewodowych jak i bezprzewodowych), VPN oraz TS Gateway. Opis dokładnej konfiguracji dla każdej z tych metod można w przewodniku Step-by-Step na stronach Microsoft (Przykład 8).

Przykład 8 – Wybór metody komunikacji lub uzyskiwania dostępu w sieci, którą wykorzystywać ma NAP.

Przykładowa konfiguracja, w której zostanie wykorzystany protokół DHCP (Dynamic Host Configuration Protocol) została zaprezentowana w przykładzie 9.

Przykład 9 – Konfiguracja metody połączenia oraz nazwy polityki.

Serwery NPS wykorzystują do komunikacji z serwerami NAP protokół RADIUS, dzieje się tak tylko w przypadku rozdzielenia ról. Konfigurację tą można pominąć, jeśli jeden serwer będzie odpowiedzialny za działanie wszystkich składników NAP, włącznie z obsługą protokołu wymuszającego (Przykład 10).

Przykład 10 – Konfiguracja serwerów zdalnych.

Kolejny etap konfiguracji zależny jest od wyboru rodzaju wymuszenia. W przypadku wykorzystania DHCP należy określić specyficzne ustawienia z nim związane (Przykład 11).

Przykład 11 – Konfiguracja specyficznych ustawień protokołu.

Następny etap konfiguracji umożliwia wybór konkretnych komputerów lub użytkowników, który nie będą mogli korzystać z tworzonej polityki. Możliwa jest jednoczesna konfiguracja komputerów oraz użytkowników (Przykład 12).

Przykład 12 – Konfiguracja wykluczeń.

Aby umożliwić komputerom niespełniającym założeń polityki poprawę swojego stany zdrowia należy wykorzystać serwery korygujące – należy określić grupę serwerów pełniących taką rolę. Jak wiadomo użytkownik końcowy nie musi posiadać dużej wiedzy tajemnej – można ułatwić im zrozumienie, dlaczego nie mogą korzystać z sieci oraz wyjaśnić co mają zrobić by spełnić warunki za pomocą strony WWW, na której adres także jest odpowiednie pole Aby ułatwić użytkownikom końcowym zrozumienie powodów dla których ich dostęp został ograniczony można stworzyć specjalną stronę intranetową opisującą powody niezgodności z politykami oraz sposoby na poprawę tego stanu. (Przykład 13).

Przykład 13 – Wybór serwerów korygujących.

Ostatnim etapem konfiguracji jest określenie takich parametrów jak SHV (System Health Validators) współpracujących z tą polityką, określenie automatycznej korekty, oraz określenie restrykcji dostępu dla klientów nie spełniających warunków (Przykład 14).

Przykład 14 – Końcowa konfiguracja polityki NAP.

Po zakończonej konfiguracji pozostaje już zapoznać się z podsumowaniem oraz zatwierdzić ustawienia (Przykład 15).

Przykład 15 – Podsumowanie konfiguracji.

wcześniej konfigurację można w przyszłości rozszerzyć i tak przykładowo dla serwerów zdalnych i połączeń RADIUS można skonfigurować zaawansowane ustawienia (Przykład 16). Istnieje tutaj możliwość konfiguracji zarówno klientów RADIUS jak i zdalnych grup serwerów RADIUS.

Przykład 16 – Zaawansowana konfiguracja RADIUS.

W przypadku polityk także istnieje możliwość zaawansowanej konfiguracji (Przykład 17). Rodzaje polityk można podzielić na:

• polityki żądania połączenia
  
• polityki sieciowe
  
• polityki zdrowia

Przykład 17 – Zaawansowana konfiguracja polityk.

Podobnie jak w poprzednich dwóch sytuacjach istnieje możliwość zaawansowanej konfiguracji samego mechanizmu Network Access Protection. Możliwe jest określenie szczegółowych zasad weryfikacji klienta z wykorzystaniem SHV oraz definiowanie grup serwerów korygujących (Przykład 18).

Przykład 18 – Zaawansowana konfiguracja NAP.

Bardzo istotne jest określenie wymogów dla komputerów klienckich. Konfiguracja polityki zawierającej wymagania odnośnie konfiguracji systemu i komponentów bezpieczeństwa odbywa się z poziomu System Health Validators (Przykład 19). W pierwszym oknie właściwości SHV określić można rodzaj zwracanego błędu w przypadku niespełnienia wymagań oraz wykonanie dodatkowej konfiguracji określającej szczegółowe wymagania wobec konfiguracji klientów, poprzez przycisk Configure.

Przykład 19 – Konfiguracja SHV.

Konfiguracja systemów klienckich zarówno dla Windows Vista jak i Windows XP nie różni się znacząco od siebie. W zależności od tego, jak restrykcyjne wymogi mają zostać narzucone klientom możliwe jest wymaganie:

• Zawsze włączonego firewalla dla wszystkich połączeń
  
• Programu antywirusowego (oraz posiadania aktualnych baz sygnatur)
  
• Programy anti-spyware (oraz posiadania aktualnych baz sygnatur)
  
• Włączonego mechanizmu aktualizacji automatycznych
  
• Posiadanie zainstalowanych aktualizacji systemu
  
  • Określenie poziomu ważności wymaganych aktualizacji
    
  • Wyznaczenie maksymalnej liczby dni, od których nie były sprawdzane aktualizacje
    
  • Wybór źródła aktualizacji (WSUS / Windows Update)
    

Odpowiedni wybór tych ustawień będzie mieć kluczowe znaczenie do prawidłowego funkcjonowania mechanizmów Network Access Protection (Przykład 20).

Przykład 20 – Określenie wymogów dla uzyskania certyfikatu zdrowia.

Accounting jest opcją pozwalającą na zdefiniowanie miejsca przechowywania logów o zdarzeniach w rozwiązaniu Network Access Protection. Możliwe jest zapisywanie logów lokalnie (domyślnie: C:\Windows\System32\LogFiles) oraz wybór serwera SQL) (Przykład 21).

Przykład 21 – Konfiguracja miejsca przechowywania logów.

W części Health Registration Authority możliwe jest określenie serwera CA (Urzędu Certyfikacji), który będzie wydawał certyfikaty zdrowia przy współpracy z HRA. Jeśli agenci muszą wykorzystywać określony protokół do komunikacji z HRA w politykach szyfrowania oraz transportu możliwe jest dokładne określenie wymogów dla agentów (Przykład 22).

Przykład 22 – Konfiguracja Health Registration Authority.

Konfiguracja klienta do współpracy z NAP

Znając możliwości konfiguracji strony serwerowej mechanizmu NAP dobrze jest poznać także stronę kliencką. Aby uruchomić konsolę NAP Client Configuration należy wykonać polecenie napclcfg.msc. Konfiguracja strony klienckiej umożliwia określenie rodzaju wymuszenia, konfigurację interfejsu oraz zdefiniowanie zaufanych serwerów Przykład 23).

Przykład 23 – Podstawowa konfiguracja klienta NAP.

Jak łatwo zauważyć lista klientów wymuszeń jest praktycznie identyczna jak w przypadku strony serwerowej – czasem występują małe różnice w nazewnictwie (Przykład 24).

Przykład 24 – Klienci wymuszeń w kliencie NAP.

NAP w praktyce

Użytkownik końcowy jest dokładnie informowany o stanie zdrowia swojego komputera. Przykład 25 przedstawia komunikat w przypadku nie spełnienia przez komputer założeń polityki. Można także zauważyć, iż status połączenia sieciowego wskazuje na ograniczoną komunikację.

Przykład 25 – Komunikat NAP – komputer nie spełnia wymogów polityki.

Dodatkowo możliwy jest podgląd szczegółów związanych ze zdrowiem komputera oraz przydzieleniem certyfikatu zdrowia. W części Remediation Results: można znaleźć przyczynę niezgodności z politykami (Przykład 26).

Przykład 26 – Informacje szczegółowe o stanie zdrowia, gdy klient nie spełnia założeń polityki.

Klient NAP zachowa się podobnie w przypadku spełniania przez komputer założeń polityki. Także wyświetli odpowiedni komunikat (Przykład 27) oraz zaktualizuje widok szczegółów agenta NAP (Przykład 28).

Przykład 27 – Komunikat NAP – komputer spełnia wymogi polityki.

Przykład 28 – Informacje szczegółowe o stanie zdrowia, gdy klient spełnia założenia polityki.

Bardzo przydatną funkcją jest wspominana wcześniej możliwość automatycznej poprawy stanu zdrowia. Przykład 29 prezentuje jego działanie w przypadku stosowania zapory ogniowej. Mechanizm NAP został skonfigurowany w celu automatycznego włączenia Windows Firewall by komputer spełniał wymogi polityk.

Przykład 29 – Mechanizm automatycznej poprawy konfiguracji systemu.

Podsumowanie

Dla wielu administratorów problem bezpieczeństwa stacji roboczych, które bardzo często sprawiały kłopoty (także w stosunku do pozostałej części infrastruktury) jest trudny do rozwiązania. Mechanizm Network Access Protection stanowi duży krok w kierunku poprawy bezpieczeństwa środowiska oraz jego automatyzacji. Jest to przyszłościowe rozwiązanie mające zastosowanie dla środowisk informatycznych przedsiębiorstw – niezależnie od wielkości. Warto zainteresować się tę technologią, nie tylko ze względu na fakt „nowości”, ale także dlatego, że w NAP zostało wbudowane wiele dodatkowych mechanizmów, które usprawnią zarządzanie bezpieczeństwem sieci.