Jak działa Network Access Protection

Opublikowano: 6 listopada 2007

Zawartość strony

	Wstęp
	Wymuszanie IPsec
	Niezgodni klienci IPsec
	Wymuszanie 802.1X
	Niezgodni klienci 802.1X
	Wymuszanie VPN
	Niezgodni klienci VPN
	Wymuszanie DHCP
	Niezgodni klienci DHCP

Wstęp

Poniżej opisano sposoby działania komponentów platformy NAP w różnych sytuacjach (komunikacja z użyciem protokołu IPsec, uwierzytelnianie w punktach dostępu IEEE 802.1X, komunikacja przez prywatne sieci wirtualne VPN, przydział adresów IP przez serwery DHCP) pozwalające realizować zadania platformy, tj. raportowanie stanu kondycji klientów NAP, weryfikowanie zgodności tego stanu z wymogami bezpieczeństwa, ograniczanie dostępu do sieci klientom niezgodnym, automatyczne doprowadzanie klientów do stanu zgodności.

Uwaga:

Poniżej opisano konfigurację, gdzie serwer NPS jest zainstalowany na innej maszynie niż serwery NAP, z którymi komunikują się klienci NAP w celu uzyskania certyfikatów zdrowia.

 Do początku strony

Wymuszanie IPsec

Wymuszanie IPsec odcina możliwość komunikowania się za pomocą protokołu IPsec klientom NAP niespełniającym wymogów bezpieczeństwa obowiązujących w danej sieci. Odbywa się to poprzez ignorowanie żądań takiej komunikacji inicjowanej przez klientów bez certyfikatów kondycji. Inaczej niż w przypadku wymuszania 802.1X, VPN czy DHCP, wymuszanie IPsec jest realizowane przez indywidualne komputery, a nie przez punkt czy kanał dostępu do sieci. Modyfikując zasady protokołu IPsec, można zrealizować funkcję wymuszania w stosunku do: wszystkich komputerów domeny, określonych komputerów należących do podsieci, tylko konkretnego komputera, danych portów TCP bądź UDP, czy też nawet tylko określonych portów TCP lub UDP wybranego komputera.

Na potrzeby wymuszania IPsec fizyczna sieć zostaje podzielona na trzy podsieci logiczne. Dany komputer w danym momencie może należeć tylko do jednej z nich. Przydział zależy od tego, czy komputer posiada certyfikat kondycji i czy wymaga uwierzytelniania takim certyfikatem przy próbach nawiązania łączności. Podział na podsieci logiczne pozwala dopuszczać komputery niespełniające wymagań bezpieczeństwa tylko do sieci z ograniczeniami oraz do serwerów zasobów korygujących, a pozostałe (spełniające wymagania bezpieczeństwa) separować, chroniąc w ten sposób przed zagrożeniami stwarzanymi przez komputery niezgodne.

Trzy wspomniane podsieci logiczne obejmują:

W oparciu o definicje powyższych podsieci logicznych można wyodrębnić trzy następujące sposoby nawiązywania łączności:

• Komputery w sieci bezpiecznej mogą nawiązywać łączność z każdym komputerem w dowolnej podsieci logicznej. Nawiązywanie łączności z komputerami w sieci bezpiecznej lub w sieci pogranicza obejmuje uwierzytelnianie IPsec oraz certyfikaty kondycji. Z komputerami w sieci z ograniczeniami komunikacja jest nawiązywana bez uwierzytelniania IPsec.

  Komputery w sieci bezpiecznej będą odpowiadać na próby nawiązania łączności podjęte przez uwierzytelnione komputery w sieci bezpiecznej lub w sieci pogranicza, ale nie będą reagować na próby nawiązania łączności przez nieuwierzytelnione komputery w sieci z ograniczeniami. Na przykład klient pracujący w sieci bezpiecznej może zażądać połączenia się ze stroną z serwera Web pracującego w sieci bezpiecznej, ale nie może tego zrobić klient z sieci z ograniczeniami. Wymagania dotyczące nawiązywania kontaktu można konfigurować osobno dla konkretnych portów TCP bądź UDP, aby ograniczać ruch określonego rodzaju. Na przykład uwierzytelniania IPsec z certyfikatami kondycji można zażądać w przypadku wywołań RPC, a zwolnić z tego wymogu ruch WWW. W takiej sytuacji klienci należący do sieci z ograniczeniami mogą pobierać strony z serwerów WWW, pracujących w sieci bezpiecznej, ale nie mogą łączyć się z takimi serwerami metodą RPC.

• Komputery w sieci pogranicza mogą nawiązywać łączność z każdym komputerem w dowolnej sieci logicznej. Nawiązywanie komunikacji z komputerami w sieci bezpiecznej lub w sieci pogranicza obejmuje uwierzytelnianie IPsec oraz certyfikaty kondycji. Z komputerami w sieci z ograniczeniami łączność jest nawiązywana bez uwierzytelniania IPsec.

  Komputery w sieci pogranicza będą odpowiadać na próby nawiązania łączności podjęte przez uwierzytelnione komputery w sieci bezpiecznej lub w sieci pogranicza, jak również na próby podjęte przez nieuwierzytelnione komputery w sieci z ograniczeniami.

  Typowo do sieci pogranicza będą zaliczane tylko serwery certyfikatów kondycji (HCS) oraz serwery korygujące NAP. Muszą one być dostępne zarówno dla komputerów niespełniających wymogów bezpieczeństwa, (aby te ostatnie mogły skorygować swój stan i uzyskać certyfikat), jak i dla komputerów spełniających wymogi bezpieczeństwa i zaliczanych do sieci bezpiecznej, (aby te ostatnie mogły aktualizować zasoby korygujące, odnawiać certyfikaty i ogólnie zarządzać komputerami w sieci pogranicza).

  Komputer należy do sieci bezpiecznej lub do sieci pogranicza do momentu wygaśnięcia jego certyfikatu kondycji. Przed terminem wygaśnięcia klient IPsec NAP musi skontaktować się z serwerem HCS w celu uzyskania odnowionego certyfikatu. Czas ważności certyfikatów można konfigurować opcjami serwera certyfikatów kondycji.

• Komputery w sieci z ograniczeniami są w stanie nawiązywać łączność z innymi takimi komputerami, bądź z komputerami w sieci pogranicza, ale nie mają możliwości komunikacji z komputerami w sieci bezpiecznej (chyba, że któryś z nich będzie posiadał specyficznie skonfigurowane ustawienia IPsec, dopuszczające taką komunikację).

  Komputery w sieci z ograniczeniami będą odpowiadać na próby nawiązania łączności podjęte przez komputery ze wszystkich trzech podsieci logicznych.

.

Rys. 1. Trzy logiczne podsieci w wymuszaniu IPsec.

Aby uzyskać certyfikat kondycji i zostać członkiem bezpiecznej podsieci IPsec, klient NAP musi przejść następującą procedurę:

1. Bezpośrednio po włączeniu klienta NAP zapora internetowa hosta nie dopuszcza wyjątków, dlatego żaden inny komputer nie może nawiązać z nim łączności. Komputer znajduje się w sieci z ograniczeniami, gdyż nie posiada certyfikatu kondycji. Komputer może komunikować się z innymi komputerami w sieci z ograniczeniami, z komputerami w sieci pogranicza oraz z Internetem, ale nie z komputerami w sieci bezpiecznej.
2. Klient NAP otrzymuje adres IP.
3. Klient wymuszający IPsec NAP EC klienta NAP otwiera bezpieczny kanał komunikacyjny HTTPS z serwerem HCS.
4. Przez otwarty kanał HTTPS komponent IPsec NAP EC wysyła serwerowi HCS swe dane uwierzytelniające oraz listę raportów o kondycji.
5. Serwer HCS umieszcza listę raportów o kondycji w komunikacie RADIUS Access-Request, a następnie przekazuje ją w tej postaci do serwera NPS.
6. Serwer NPS pobiera listę raportów o kondycji z komunikatu RADIUS Access-Request i wysyła ją do komponentu administracyjnego NAP.
7. Komponent administracyjny NAP rozsyła raporty o kondycji do odpowiednich modułów sprawdzania kondycji.
8. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu SoH, po czym generuje odpowiedź SoHR i odsyła ją do komponentu administracyjnego NAP.
9. Serwer administracyjny NAP wysyła listę odpowiedzi SoHR do serwera NPS.
10. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.
11. Serwer NPS generuje i wysyła komunikat RADIUS Access-Accept, zawierający listę odpowiedzi SoHR w postaci specyficznych dla danego dostawcy atrybutów protokołu RADIUS.
12. Serwer HCS przekazuje listę odpowiedzi SoHR z powrotem do klientów wymuszających IPsec NAP EC. Jeśli klient NAP spełnia wymogi bezpieczeństwa, serwer HCS wystawia mu certyfikat kondycji.

Klient NAP dołącza wystawiony certyfikat kondycji do swej składnicy certyfikatów. Klient wymuszający IPsec NAP EC konfiguruje protokół IPsec tak, aby klient dzięki certyfikatowi mógł się uwierzytelnić, a następnie konfiguruje zaporę internetową hosta w taki sposób, aby przepuszczała żądania nawiązania łączności z dowolnego innego komputera uwierzytelniającego się certyfikatem kondycji. Od tego momentu klient NAP staje się członkiem bezpiecznej sieci.

Komponent IPsec NAP EC powtarza kroki 3-12 powyższej procedury za każdym razem, gdy do agenta NAP danego klienta dotrze nowy raport o kondycji lub w momencie zbliżania się terminu wygaśnięcia ważności jego certyfikatu kondycji.

 Do początku strony

Niezgodni klienci IPsec

Klient NAP, który okaże się niezgodny z wymogami bezpieczeństwa, nie otrzyma certyfikatu kondycji i nie będzie mógł nawiązywać łączności z komputerami w bezpiecznej sieci.

Aby stać się członkiem bezpiecznej sieci, niezgodny klient NAP musi wykonać poniższą procedurę korygującą:

1. Klient wymuszający IPsec NAP EC wysyła listę odpowiedzi SoHR do agenta NAP.
2. Agent NAP wysyła odpowiedzi SoHR do odpowiednich agentów kondycji systemu.
3. Poszczególni agenci kondycji systemu analizują otrzymane odpowiedzi SoHR i wykonują zalecane w nich akcje korygujące klienta NAP.
4. Agent kondycji systemu, który wykonał akcję korygującą, wysyła zaktualizowany raport o kondycji do agenta NAP.
5. Agent NAP zbiera zaktualizowane raporty o kondycji od wszystkich tych agentów kondycji systemu, którzy musiałi podjąć akcje korygujące, generuje nową listę raportów o kondycji, a następnie przekazuje ją do komponentu wymuszającego IPsec NAP EC.
6. Komponent IPsec NAP EC nawiązuje nową sesję bezpiecznej łączności HTTPS z serwerem HCS, w trakcie, której przekazuje serwerowi nową listę raportów o kondycji.
7. Serwer HCS umieszcza listę raportów o kondycji w komunikacie RADIUS Access-Request i przekazuje ją do serwera NPS.
8. Serwer NPS pobiera listę raportów o kondycji z otrzymanego komunikatu RADIUS Access-Request i wysyła ją do komponentu administracyjnego NAP.
9. Komponent administracyjny NAP rozsyła raporty o kondycji do danych modułów sprawdzania kondycji (o ile nie zapamiętał w pamięci podręcznej ich wcześniejszych odpowiedzi).
10. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu SoH, po czym generuje odpowiedź SoHR i odsyła ją do komponentu administracyjnego NAP.
11. Komponent administracyjny NAP wysyła listę odpowiedzi SoHR do serwera NPS.
12. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.
13. Serwer NPS generuje i wysyła komunikat RADIUS Access-Accept zawierający listę odpowiedzi SoHR w postaci specyficznych dla danego dostawcy atrybutów protokołu RADIUS.
14. Serwer HCS przekazuje listę odpowiedzi SoHR do klientów wymuszających IPsec NAP EC i wystawia klientowi certyfikat kondycji.

 Do początku strony

Wymuszanie 802.1X

Wymuszanie IEEE 802.1X polega na użyciu przez punkt dostępu 802.1X odpowiedniego profilu ograniczającego, w postaci odpowiedniego zestawu filtrów pakietów IP albo odpowiedniego identyfikatora wirtualnej sieci LAN (VLAN ID) w celu ograniczenia dostępu niezgodnych klientów NAP do zasobów sieci z ograniczeniami. Filtrowanie pakietów IP jest przez punkt dostępu 802.1X stosowane dla całego ruchu IP, generowanego przez klientów punktu; wszystkie pakiety nie odpowiadające skonfigurowanemu filtrowi są ignorowane. W metodzie VLAN ID punkt dostępu 802.1X nadaje takim pakietom identyfikator sieci wirtualnej, której zasięg pokrywa się z zasięgiem sieci z ograniczeniami.

W celu wykazania stanu kondycji klient 802.1X NAP może użyć:

• Listy raportów o kondycji: w takim przypadku klient wymuszający EAPHost NAP EC wysyła listę raportów o kondycji umieszczoną w komunikacie PEAP-TLV w sposób podobny, jak przy połączeniach VPN.

• Certyfikatu kondycji: w przypadku, gdy klient wymuszający EAPHost NAP EC wysyła swój certyfikat kondycji, serwer NPS nie musi sprawdzać listy raportów o kondycji ani weryfikować stanu łączącego się klienta. Ważny certyfikat kondycji oznacza, że klient jest zgodny.

  Stosowanie certyfikatów kondycji jest zalecaną metodą walidowania klientów w połączeniach 802.1X.

Jeśli w celu wykazania swego poziomu kondycji klient NAP 802.1X przedkłada listę raportów o kondycji, procesy przebiegają następująco:

1. Punkt dostępu 802.1X lub klient 802.1X inicjuje uwierzytelnienie 802.1X według protokołu EAPOL (EAP over LAN).

2. Serwer NPS wysyła komunikat EAP-Request/Identity do komponentu wymuszającego EAPHost NAP EC klienta 802.1X.

3. Komponent EAPHost NAP EC odpowiada komunikatem EAP-Response/Identity, zawierającym nazwę użytkownika lub nazwę komputera klienta 802.1X.

4. Serwer NPS wysyła komunikat EAP-Request/Start PEAP do klienta 802.1X.

5. Klient 802.1X i serwer NPS wymieniają serię komunikatów TLS w celu wynegocjowania szyfrowanego kanału TLS.

6. Komunikatem PEAP-TLV serwer NPS żąda od klienta 802.1X przedłożenia listy raportów o kondycji.

7. Komponent EAPHost NAP EC pobiera listę raportów o kondycji z agenta NAP.

8. Komponent EAPHost NAP EC wysyła do serwera NPS komunikat PEAP-TLV z listą raportów o kondycji.

9. Serwer NPS żąda, aby klient 802.1X uwierzytelnił się przedkładając dane swego użytkownika lub komputera poprzez zastosowanie którejś z metod PEAP, np. PEAP-MS-CHAP v2.

10. Klient 802.1X uwierzytelnia się przed serwerem NPS, używając wynegocjowanej metody PEAP.

11. Komponent NPS pobiera listę raportów o kondycji z komunikatu PEAP-TLV wysłanego w kroku 9, przekazując ją następnie do komponentu administracyjnego NAP.

12. Komponent administracyjny NAP rozsyła raporty o kondycji z listy do odpowiednich modułów sprawdzania kondycji.

13. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu SoH, po czym generuje odpowiedź SoHR i odsyła ją do komponentu administracyjnego NAP.

14. Komponent administracyjny NAP wysyła listę odpowiedzi SoHR do serwera NPS.

15. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.

16. Serwer NPS przesyłw do klienta 802.1X komunikat PEAP-TLV, zawierający zbiorczą ocenę kondycji SSoHR (System Statement of Health Response) oraz listę odpowiedzi SoHR.

17. Serwer NPS przesyła do punktu dostępu 802.1X komunikat RADIUS Access-Accept, zawierający zbiorczą ocenę SSoHR.

    1. Jeśli dostęp ma być ograniczony, komunikat RADIUS Access-Accept zawiera m.in. profil dostępu limitujący ruch klienta 802.1X do sieci z ograniczeniami.
    2. Jeśli dostęp ma być nieograniczony, komunikat RADIUS Access-Accept nie zawiera żadnego profilu dostępu i po zakończeniu procedury klient 802.1X NAP otrzyma nielimitowany dostęp do sieci.

18. Klient oraz punkt dostępu kończą procedurę zestawiania połączenia 802.1X.

Jeśli w celu wykazania kondycji klient NAP 802.1X przedkłada swój certyfikat kondycji, procesy przebiegają następująco:

1. Punkt dostępu 802.1X lub klient 802.1X inicjuje uwierzytelnienie 802.1X według protokołu EAPOL.

2. Klient 802.1X (użytkownik lub komputer) uwierzytelnia się przed serwerem NPS, używając ustalonej metody PEAP.

3. Komponent EAPHost NAP EC wysyła do serwera NPS swój certyfikat kondycji umieszczony w komunikacie PEAP-TLV.

4. Serwer NPS nadaje do klienta 802.1X komunikat PEAP-TLV zawierający zbiorczą ocenę SSoHR.

5. Serwer NPS przesyła do punktu dostępu 802.1X komunikat RADIUS Access-Accept zawierający zbiorczą ocenę SSoHR.

   1. Jeśli dostęp ma być ograniczony, komunikat RADIUS Access-Accept mieści w sobie m.in. profil dostępu limitujący ruch klienta 802.1X do sieci z ograniczeniami.
   2. Jeśli dostęp ma być nieograniczony, komunikat RADIUS Access-Accept nie zawiera żadnego profilu dostępu i po zakończeniu procedury klient 802.1X NAP otrzyma nielimitowany dostęp do sieci.

6. Klient i punkt dostępu kończą procedurę zestawiania połączenia 802.1X.

 Do początku strony

Niezgodni klienci 802.1X

Jeśli dany klient 802.1X NAP jest niezgodny, na połączenie 802.1X zostanie narzucony profil dostępu limitujący ruch tego klienta do sieci z ograniczeniami. Procedura korygowania stanu klienta w celu uzyskania nielimitowanego dostępu zależy od tego, czy weryfikacja tego stanu jest oparta o listę raportów o kondycji, czy o certyfikat kondycji.

Jeśli stan kondycji klienta NAP 802.1X jest określany w oparciu o listę raportów o kondycji, procesy korygowania tego stanu w celu uzyskania nielimitowanego dostępu do sieci przebiegają następująco:

1. Komponent wymuszający EAPHost NAP EC pobiera listę odpowiedzi SoHR z komunikatu PEAP-TLV otrzymanego z serwera NPS i przekazuje ją do agenta NAP.
2. Agent NAP rozsyła odpowiedzi SoHR do odpowiednich agentów kondycji systemu.
3. Poszczególni agenci kondycji systemu analizują otrzymane odpowiedzi SoHR i wykonują zalecane w nich akcje korygujące stan kondycji klienta NAP.
4. Agent kondycji systemu, który wykonał akcję korygującą, dostarcza zaktualizowany raport o kondycji do agenta NAP.
5. Agent NAP zbiera zaktualizowane raporty o kondycji od wszystkich agentów kondycji systemu, którzy musieli podjąć akcje korygujące, generuje nową listę raportów o kondycji, a następnie wysyła ją do komponentu wymuszającego EAPHost NAP EC.
6. Komponent wymuszający EAPHost NAP EC restartuje procedurę uwierzytelniania802.1X, w trakcie, której przekazuje serwerowi nową listę raportów o kondycji.
7. Weryfikacja przebiega pomyślnie i klient 802.1X otrzymuje nielimitowany dostęp do sieci.

Jeśli stan kondycji klienta NAP 802.1X jest określany w oparciu o certyfikat kondycji, procesy korygowania tego stanu w celu uzyskania nielimitowanego dostępu do sieci przebiegają następująco:

1. Komponent wymuszający EAPHost NAP EC zgłasza do serwera HCS żądanie wydania certyfikatu kondycji, przedkładając listę raportów o kondycji.
2. Serwer HCS przekazuje listę raportów o kondycji do serwera NPS, który porównuje ją ze skonfigurowanym zestawem wymogów bezpieczeństwa i odsyła do serwera HCS listę odpowiedzi SoHR.
3. Serwer HCS przesyła listę odpowiedzi SoHR z powrotem do komponentu wymuszającego EAPHost NAP EC.
4. Komponent EAPHost NAP EC pobiera listę odpowiedzi SoHR i przekazuje ją do agenta NAP.
5. Agent NAP rozsyła odpowiedzi SoHR do odpowiednich agentów kondycji systemu.
6. Poszczególni agenci kondycji systemu analizują otrzymane odpowiedzi SoHR i wykonują zalecane w nich akcje korygujące klienta NAP.
7. Agent kondycji systemu, który wykonał akcję korygującą, śle zaktualizowany raport o kondycji do agenta NAP.
8. Agent NAP zbiera zaktualizowane raporty o kondycji od wszystkich tych agentów kondycji systemu, którzy musieli podjąć akcje korygujące, generuje nową listę raportów o kondycji i przekazuje ją do komponentu wymuszającego EAPHost NAP EC.
9. Komponent EAPHost NAP EC dostarcza serwerowi HCS nową listę raportów o kondycji.
10. Serwer HCS transmituje listę raportów o kondycji do serwera NPS.
11. Serwer NPS porównuje nową listę ze skonfigurowanym zestawem wymogów bezpieczeństwa i odsyła do serwera HCS odpowiedzi SoHR, zezwalające na nielimitowany dostęp do sieci.
12. Serwer HCS wystawia klientowi 802.1X nowy certyfikat kondycji.
13. Klient uruchamia ponownie procedurę uwierzytelniania 802.1X, w trakcie, której przedkłada nowy certyfikat kondycji.
14. Weryfikacja przebiega tym razem pomyślnie i klient 802.1X otrzymuje nielimitowany dostęp do sieci.

 Do początku strony

Wymuszanie VPN

Wymuszanie VPN polega na użyciu zestawu filtrów pakietów IP limitujących ruch klienta VPN tak, że może on sięgać wyłącznie do zasobów umieszczonych w sieci z ograniczeniami. Wszystkie pakiety nieodpowiadające skonfigurowanemu filtrowi są ignorowane.

Gdy jakiś klient NAP łączy się z serwerem VPN zabezpieczonym mechanizmami NAP, procesy przebiegają następująco:

1. Wykorzystując protokół PPTP lub L2TP/IPsec, klient VPN inicjuje połączenie z serwerem VPN.

2. Serwer wymuszający VPN NAP ES (komponent usług Routing and Remote Access) wysyła komunikat EAP-Request/Identity do klienta wymuszającego VPN NAP EC.

3. Klient wymuszający VPN NAP EC (komponent usług Remote Access Connection Manager) odpowiada komunikatem EAP-Response/Identity, zawierającym nazwę użytkownika klienta VPN.

4. Serwer wymuszający VPN NAP ES przekazuje do serwera NPS treść komunikatu EAP-Response/Identity w postaci komunikatu RADIUS Access-Request. Wszelkie dalsze komunikaty PEAP wymieniane między serwerem NPS a komponentem wymuszającym VPN NAP EC w kliencie VPN, będą przechodziły przez serwer VPN. Serwer VPN i serwer NPS wymieniają komunikaty RADIUS Access-Request, Access-Challenge i Access-Accept.

5. Serwer NPS transmituje komunikat EAP-Request/Start PEAP do klienta VPN.

6. Wymieniając serię komunikatów TLS klient VPN i serwer NPS, uzgadniają szyfrowy kanał TLS.

7. Komunikatem PEAP-TLV serwer NPS żąda od klienta VPN przedłożenia listy raportów o kondycji.

8. Komponent wymuszający VPN NAP EC pobiera listę raportów o kondycji od agenta NAP klienta VPN.

9. W komunikacie PEAP-TLV komponent wymuszający VPN NAP EC przesyła listę raportów o kondycji do serwera NPS.

10. Serwer NPS żąda od klienta VPN, aby ten się uwierzytelnił, stosując którąś z metod PEAP, np. MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2).

11. Klient VPN uwierzytelnia się w serwerze NPS, używając uzgodnionej metody PEAP.

12. Komponent NPS serwera NPS pobiera listę raportów o kondycji z komunikatu PEAP-TLV wysłanego w kroku 9, a następnie przekazuje ją do komponentu administracyjnego NAP.

13. Komponent administracyjny NAP rozsyła raporty o kondycji z listy do odpowiednich modułów sprawdzania kondycji.

14. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu SoH, po czym generuje odpowiedź SoHR i odsyła ją do komponentu administracyjnego NAP.

15. Komponent administracyjny NAP dostarcza listę odpowiedzi SoHR do serwera NPS.

16. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.

17. Serwer NPS przekazuje klientowi VPN komunikat PEAP-TLV, zawierający zbiorczą ocenę SSoHR oraz listę odpowiedzi SoHR.

18. Serwer NPS transmituje do serwera VPN komunikat RADIUS Access-Accept, zawierający zbiorczą ocenę SSoHR.

    1. Jeśli dostęp ma być ograniczony, komunikat RADIUS Access-Accept zawiera m.in. zestaw filtrów limitujących ruch klienta VPN do sieci z ograniczeniami.
    2. Jeśli dostęp ma być nieograniczony, komunikat RADIUS Access-Accept nie zawiera żadnego profilu dostępu i po zakończeniu procedury klient VPN otrzyma nielimitowany dostęp do sieci.

19. Klient i serwer kończą procedurę zestawiania połączenia VPN.

 Do początku strony

Niezgodni klienci VPN

Jeśli klient VPN jest niezgodny, na połączenie VPN zostanie narzucony profil dostępu, limitujący ruch tego klienta do sieci z ograniczeniami. Procedura korygowania stanu klienta w celu uzyskania nielimitowanego dostępu przebiega następująco:

1. Komponent wymuszający VPN NAP EC pobiera listę odpowiedzi SoHR z komunikatu PEAP-TLV otrzymanego z serwera NPS i przekazuje ją agentowi NAP.
2. Agent NAP rozsyła odpowiedzi SoHR do odpowiednich agentów kondycji systemu.
3. Poszczególni agenci kondycji systemu analizują otrzymane odpowiedzi SoHR i wykonują zalecane w nich akcje korygujące stan kondycji klienta NAP.
4. Agent kondycji systemu, który wykonał akcję korygującą, przekazuje zaktualizowany raport o kondycji do agenta NAP.
5. Agent NAP zbiera zaktualizowane raporty o kondycji od wszystkich tych agentów kondycji systemu, którzy musieli podjąć akcje korygujące, generuje nową listę raportów o kondycji i wysyła ją do komponentu wymuszającego VPN NAP EC.
6. Używając komunikatu PEAP-TLV komponent wymuszający VPN NAP EC dostarcza serwerowi NPS nową listę raportów o kondycji.
7. Komponent NPS serwera NPS pobiera listę raportów o kondycji z komunikatu PEAP-TLV i wysyła ją do komponentu administracyjnego NAP.
8. Komponent administracyjny NAP rozsyła raporty o kondycji z listy do odpowiednich modułów sprawdzania kondycji.
9. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu kondycji, po czym generuje odpowiedź SoHR i odsyła ją do komponentu administracyjnego NAP.
10. Komponent administracyjny NAP przekazuje listę odpowiedzi SoHR do serwera NPS.
11. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.
12. Serwer NPS transmituje do klienta VPN (poprzez serwer VPN) komunikat PEAP-TLV, zawierający zbiorczą ocenę SSoHR oraz listę odpowiedzi SoHR.
13. Serwer NPS wysyła do serwera VPN komunikat RADIUS Access-Accept, zawierający zbiorczą ocenę SSoHR, tym razem bez filtrów pakietów IP limitujących dostęp.
14. Serwer VPN zdejmuje filtrację pakietów IP z zestawionego połączenia VPN i tym samym klient VPN uzyskuje nielimitowany dostęp do sieci.

 Do początku strony

Wymuszanie DHCP

Serwer DHCP może ograniczyć dostęp klientów do sieci stosując tabelę routingu IP. W wymuszaniu DHCP wartość opcji DHCP Router jest ustawiona na 0.0.0.0 (nie ma ani jednej domyślnej bramy), a maska podsieci na 255.255.255.255 (nie ma żadnej drogi do dołączonych podsieci). Aby umożliwić dostęp niezgodnych komputerów do serwerów korygujących, serwer DHCP wykorzystuje opcję Classless Static Routes, pozwalającą na routing do komputerów w sieci z ograniczeniami, takich jak serwery DNS i serwery korygujące. Konfiguracja i tabele routingu serwera DHCP, pozwalają na łączność tylko z określonymi adresami sieciowymi. Tak, więc, gdy jakaś aplikacja próbuje wykorzystać któryś z adresów IPv4 spoza tych włączonych opcją Classless Static Routes, protokół TCP/IP generuje błąd routingu.

Uwaga:

Wymuszanie DHCP działa tylko w odniesieniu do klientów posługujących się adresacją IPv4. Dostęp klientów DHCP NAP korzystających z adresacji IPv6 nie będzie nigdy limitowany.

Uwaga:

Ponieważ wymuszanie DHCP opiera się na tabeli routingu IPv4, nie może zapobiec dopuszczeniu do sieci komputerów niezgodnych w przypadku, kiedy złośliwy użytkownik mający uprawnienia lokalnego administratora ręcznie zmieni wpisy w tabeli.

Gdy klient NAP, próbuje uzyskać z serwera DHCP zabezpieczonego mechanizmami NAP adres IPv4, procesy przebiegają następująco:

1. Komponent wymuszający DHCP NAP EC klienta NAP (komponent usługi DHCP Client) żąda od agenta NAP dostarczenia listy raportów o kondycji.
2. Agent NAP, (w którego pamięci podręcznej zgromadzone są raporty o kondycji wystawione przez poszczególnych agentów kondycji systemu) wysyła listę raportów o kondycji żądaną przez komponent DHCP NAP EC.
3. Usługa DHCP Client generuje i wysyła komunikat DHCPDiscover z listą raportów o kondycji w postaci opcji DHCP.
4. Serwer DHCP odbiera komunikat DHCPDiscover. Jeśli jest to serwer obsługujący platformę NAP, jego komponent wymuszający DHCP NAP ES (komponent usługi DHCP Server) pobiera listę raportów o kondycji, a następnie wysyła ją do serwera NPS w postaci (zależnych od konkretnego dostawcy) atrybutów RADIUS w komunikacie RADIUS Access-Request.
5. Serwer NPS pobiera listę raportów o kondycji z atrybutów otrzymanego komunikatu RADIUS Access-Request i przekazuje ją do komponentu administracyjnego NAP.
6. Komponent administracyjny NAP rozsyła raporty o kondycji do odpowiednich modułów sprawdzania kondycji.
7. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu SoH, po czym generuje odpowiedź SoHR i odsyła ją do komponentu administracyjnego NAP.
8. Komponent administracyjny NAP dostarcza listę odpowiedzi SoHR do serwera NPS.
9. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.
10. Serwer NPS generuje, a następnie nadaje do serwera DHCP komunikat RADIUS Access-Accept, zawierający zbiorczą ocenę SSoHR (wskazującą, czy dany klient ma otrzymać dostęp nielimitowany, czy też limitowany) oraz listę odpowiedzi SoHR w postaci atrybutów specyficznych dla danego dostawcy protokołu RADIUS.
11. Serwer DHCP pobiera z otrzymanego komunikatu zbiorczą ocenę SSoHR oraz listę odpowiedzi SoHR, po czym formatuje je, jako opcje DHCP zależne od konkretnego dostawcy.
12. Serwer DHCP wysyła komunikat DHCPOffer, zawierający konfigurację adresu IPv4.
13. Klient DHCP przekazuje komunikat DHCPRequest, żądający przydziału oferowanej konfiguracji adresu.
14. Serwer DHCP wysyła komunikat DHCPAck, zawierający oferowaną konfigurację adresu IPv4, zbiorczą ocenę SsoHR oraz listę odpowiedzi SoHR w postaci opcji DHCP.

Jeśli dany klient NAP jest zgodny, komunikat DHCPAck zawiera opcję Router DHCP ustawioną na poprawną bramę standardową, opcję „maska podsieci”, skierowaną na podsieć tego klienta, ale nie zawiera opcji Classless Static Routes. W tym momencie klient NAP posiada nielimitowany dostęp do sieci.

 Do początku strony

Niezgodni klienci DHCP

Jeśli dany klient NAP nie jest zgodny, komunikat DHCPAck zawiera opcję Router DHCP ustawioną na 0.0.0.0, opcję „maska podsieci” skierowaną na 255.255.255.255 oraz opcję Classless Static Routes, podającą zestaw statycznych tras do zasobów udostępnianych w sieci z ograniczeniami.

Procesy korygowania stanu klienta w celu uzyskania nielimitowanego dostępu do sieci przebiegają następująco:

1. Komponent DHCP NAP EC wysyła listę odpowiedzi SoHR do agenta NAP.
2. Agent NAP rozsyła poszczególne odpowiedzi SoHR do odpowiednich agentów kondycji systemu.
3. Poszczególni agenci kondycji systemu analizują otrzymane odpowiedzi SoHR i wykonują zalecane w nich akcje korygujące stan kondycji klienta NAP.
4. Agent kondycji systemu, który wykonał akcję korygującą, dostarcza zaktualizowany raport o kondycji do agenta NAP.
5. Agent NAP zbiera zaktualizowane raporty o kondycji od wszystkich tych agentów kondycji systemu, które musiały podjąć akcje korygujące, generuje nową listę raportów o kondycji i przekazuje ją do komponentu wymuszającego DHCP NAP EC.
6. Komponent wymuszający DHCP NAP EC wysyła do serwera DHCP komunikat DHCPRequest z nową listą raportów o kondycji.
7. Serwer DHCP odbiera komunikat DHCPRequest. Jeśli jest to serwer obsługujący platformę NAP, jego komponent wymuszający DHCP NAP ES (komponent usługi DHCP Server) pobiera listę raportów o kondycji z komunikatu i transmituje ją do serwera NPS w postaci (zależnych od konkretnego dostawcy) atrybutów RADIUS w komunikacie RADIUS Access-Request.
8. Serwer NPS pobiera listę raportów o kondycji z atrybutów otrzymanego komunikatu RADIUS Access-Request, a następnie wysyła ją do komponentu administracyjnego NAP.
9. Komponent administracyjny NAP rozsyła raporty o kondycji do odpowiednich modułów sprawdzania kondycji (o ile nie zapamiętał w pamięci podręcznej ich wcześniejszych odpowiedzi).
10. Każdy moduł sprawdzania kondycji analizuje treść otrzymanego certyfikatu kondycji, po czym generuje odpowiedź SoHR i zwraca ją do komponentu administracyjnego NAP.
11. Komponent administracyjny NAP przekazuje listę odpowiedzi SoHR do serwera NPS.
12. Serwer NPS porównuje listę odpowiedzi SoHR ze skonfigurowanym zestawem wymogów bezpieczeństwa i podejmuje decyzję o dostępie klienta do sieci: ograniczony/nieograniczony.
13. Serwer NPS generuje i dostarcza do serwera DHCP komunikat RADIUS Access-Accept zawierający zbiorczą ocenę SSoHR (wskazującą, czy dany klient ma otrzymać dostęp nielimitowany, czy też limitowany) oraz listę odpowiedzi SoHR w postaci atrybutów specyficznych dla danego dostawcy protokołu RADIUS.
14. Serwer DHCP pobiera z otrzymanego komunikatu zbiorczą ocenę SSoHR oraz listę odpowiedzi SoHR, po czym formatuje je, jako opcje DHCP zależne od konkretnego dostawcy.
15. Serwer DHCP wysyła komunikat DHCPAck zawierający opcję Router DHCP ustawioną na poprawną bramę standardową, opcję „maska podsieci” skierowaną na podsieć danego klienta, ale nie zawiera opcji Classless Static Routes. W tym momencie klient NAP posiada nielimitowany dostęp do sieci.

Do początku strony