Les Quarantine Enforcement Servers

style= »text-align: justify; « >
Le serveur DHCP peut contrôler l’accès en définissant les routes et les paramètres IP du client DHCP. Les équipements 802.1x peuvent contrôler les ports et faire une quarantaine par mise en place de filtres IP ou par affectation à un VLAN défini. Les serveurs VPN peuvent euxaussi contrôler l’accès en appliquant des filtres IP mais nécessitent une authentification basée sur PEAP.

Enfin, si IPSec est déjà utilisé pour l’isolation de domaine ou de serveurs, NAP peut s’appuyer sur ce qui est déjà en place pour isoler les machines non conformes. Au niveau de l’enforcement DHCP, on peut bien sûr paramétrer quelles sont les plages concernées. En plus des options DHCP classiques, on utilise une nouvelle classe, « Quarantine User ». Le service RADIUS doit cependant être installé sur tous les serveurs DHCP (au moins en mode proxy).

Le serveur DHCP va pouvoir contrôler les accès en définissant les routes, comme par exemple une passerelle par défaut en 0.0.0.0 (donc pas de passerelle par défaut sur le client) et un masque en 255.255.255.255 (donc pas de route pour le sous-réseau), ou encore une classless static route pour que le client ne puisse joindre par exemple que les serveurs de mise à jour, le DHCP et le DNS, d’où la possibilité de n’accéder qu’à certaines adresses spécifiques.

L’avantage de ce type d’enforcement, c’est qu’il supporte à la fois IPv4 et IPv6. En revanche, dans la mesure où la quarantaine DHCP repose sur des entrées dans la table de routage, il est impossible d’empêcher un administrateur local malveillant de changer manuellement la table de routage pour obtenir un accès complet au réseau, et le mécanisme DHCP ne permet pas d’authentifier les postes. Pour l’enforcement VPN, il faut paramétrer le service Routing and Remote Access Server (RRAS), afin de sélectionner le mode d’authentification EAP : NAP utilise PEAP.

Pour configurer RRAS pour la stratégie NAP, il y a la stratégie locale pour les stratégies d’accès distants, le client RADIUS étant quant à lui dans l’onglet Sécurité des propriétés du serveur RRAS. Attention, si DHCP est utilisé par RRAS, il faut utiliser une plage spécifique et y désactiver la quarantaine. L’enforcement VPN support PPTP et L2TP/IPSec, IPv4 comme IPv6 et prend en charge la renégociation PPP sans déconnexion.

La quarantaine est assurée par la mise en place de filtres IP. L’enforcement IPSec est le seul mécanisme à fonctionner au niveau hôte. Ainsi, il ne peut pas être contourné en utilisant un hub ou des machines virtuelles. Si IPSec est déjà utilisé pour l’isolation de domaine ou de serveurs, NAP peut s’appuyer sur ce qui est déjà en place pour isoler les machines non conformes. La politique IPSec nécessite des lettres de créance, comme un certificat de santé.

Par exemple, tous les pairs doivent présenter un certificat de santé, ou encore, tous les pairs doivent présenter un certificat de santé sauf s’ils se connectent au port 80. L’enforcement IPsec fonctionne en complément des technologies de protection niveau 2 : c’est une défense en profondeur des segments où les switches et routeurs ont été mis à niveau, et on peut isoler de manière spécifique des ports UDP/TCP et des applications.

Cela fonctionne avec les serveurs et l’infrastructure existante, sans nécessiter de remplacement ou de mise à jour des serveurs DHCP ou VPN, et cela protège les segments où les switches et routeurs ont été mis à niveau. Enfin, cela offre une isolation flexible, car les systèmes en bonne santé peuvent accéder aux systèmes en quarantaine, sans que l’inverse ne soit vrai, et le modèle d’isolation est défini par la stratégie. L’IPSec Enforcement Client, disponible en standard, fournit son état de santé au Health Certificate Server et définit et met en oeuvre automatiquement les stratégies du client IPSec.

La Health Registration Authority émet elle des certificats pour les clients en bonne santé.