> Tech > Mettre en oeuvre la sécurité des domaines et des ordinateurs locaux

Mettre en oeuvre la sécurité des domaines et des ordinateurs locaux

Tech - Par iTPro - Publié le 24 juin 2010
email

Grâce aux opérations précédentes, votre serveur est étroitement verrouillé contre des attaques en provenance d'Internet : votre serveur VPN ne devrait répondre qu'au trafic de type IPSec. Vous pouvez en avoir la preuve en effectuant un balayage de ports tel que Nmap de Insecure.org. Vous êtes presque prêt à  connecter

votre serveur VPN à  Internet. Mais,
avant cela, prêtez attention à  certaines
mesures de sécurité concernant les domaines
et les ordinateurs locaux.
Heureusement, les paramètres de
sécurité par défaut de Windows 2003
sont beaucoup plus forts que ceux de
Win2K. Mais cela ne doit pas vous empêcher
de renforcer l’ensemble du serveur
VPN. Validez l’audit et configurez
votre sécurité afin de pouvoir suivre les
événements de sécurité. Assurez-vous
que les comptes utilisateur locaux
n’ont pas d’accès commuté RAS. Par
ailleurs, instaurez une rigoureuse stratégie
d’éviction de comptes. Utilisez
un mot de passe puissant pour le
compte Administrator local et désactivez
le compte Guest et tout autre
compte local superflu. Désactivez aussi
tout service superflu. Je vous conseille
d’utiliser un GPO plutôt qu’une configuration
directe pour procéder à  ces
modifications, afin que les paramètres
persistent, même si vous remplacez le
serveur ou déployez plus de serveurs
dans l’éventualité où votre VPN continuerait
à  croître.
Au niveau domaine, ne validez l’accès
commuté RAS que pour les utilisateurs
appropriés qui ont besoin de l’accès
distant et soyez très exigeants pour
leurs mots de passe. Comme un utilisateur
à  distance s’authentifie auprès
du serveur VPN avec le même compte
qu’il utilise pour se connecter localement
au bureau, les assaillants peuvent
utiliser des attaques par déni de service
(DoS) pour tenir à  l’écart un ou
plusieurs comptes au moyen de tentatives
de connexion infructueuses au
serveur VPN. Avec Windows, vous pouvez
traiter les lockouts aux comptes
d’accès distants séparément, afin que
les assaillants externes ne puissent pas
évincer des comptes de domaine pour
utilisation sur le LAN local, mais qu’ils
soient plutôt écartés du serveur VPN.
Vous pouvez valider ce traitement spécial
des lockouts d’accès à  distance en
configurant le paramétrage du registre
HKEY_LOCAL_MACHINE\SYSTEM\Cu
rrentControlSet\Services\RemoteAcce
ss\Parameters\AccountLockout. (Pour
plus de détails sur la configuration de
ce paramètre, voir la documentation
Windows à  http://www.microsoft.
com/technet/treeview/default.asp?url
=/technet/prodtechnol/windowsserver2003/
proddocs/datacenter/sag_rras
-ch1_74.asp.)
Après avoir connecté votre serveur
VPN, vous pouvez essayer de connecter
à  partir de divers clients. Je vous
conseille de commencer par connecter
à  partir d’un client qui appelle directement
un ISP, afin de ne pas croiser un
dispositif NAT. N’oubliez pas de mettre
à  jour vos clients avec soit le client VPN
Microsoft L2TP/IPSec sur les ordinateurs
pré-Win2K, soit la mise à  jour
IPSec NAT-T sur Win2K et ordinateurs
ultérieurs. Par ailleurs, assurez-vous
que votre client a un certificat d’ordinateur
installé et que le certificat du CA
est dans son dossier Trusted Root
Certification Authorities. Ensuite, ouvrez
Network Connections et utilisez le
New Connection Wizard pour créer
une connexion vers votre serveur VPN.
Configurez la connexion pour utiliser
L2TP et essayez-la en utilisant un
compte de domaine que vous avez validé
pour l’accès dial-in. Si vous parvenez
à  vous connecter, essayez ensuite
de le faire à  partir de derrière un dispositif
NAT (un pare-feu de réseau domestique,
l’emplacement d’un partenaire,
par exemple).

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010