Le routage dans la plupart des réseaux s'effectue le plus souvent sans pare-feu internes. Par conséquent, un virus qui parvient à infecter un ordinateur par le e-mail ou par une page Web infectée peut ensuite attaquer tous les autres ordinateurs du réseau de l'entreprise. Il est rare qu'une station de
Utiliser IPSec pour verrouiller l’accès aux ordinateurs par le réseau
travail
doive vraiment accéder à tous les
autres ordinateurs du réseau.
L’utilisation de pare-feu internes et de
segments LAN pour fragmenter le réseau
en zones discrètes de trafic autorisé,
serait trop chère et trop compliquée.
Mais IPSec peut brillamment
ralentir un virus, voire l’empêcher de
se propager dans le réseau. Vous pouvez
utiliser Group Policy pour déployer
les policies IPSec facilement et automatiquement
sur les ordinateurs présents
dans le domaine AD. Ces policies
IPSec peuvent être de simples filtres de paquets qui bloquent l’accès à certains
ports de l’ordinateur d’après l’adresse
IP. Ou bien, vous pouvez formuler des
policies plus sophistiquées utilisant
des attributs d’IPSec : puissante authentification,
contrôle d’intégrité, et
cryptage.
Il ne s’agit pas d’essayer de protéger
des ordinateurs individuels : on essaie
de protéger le réseau et de ralentir
ou limiter la propagation d’un virus.
C’est pourquoi il faut déployer largement
la policy IPSec sur tous les serveurs
et stations de travail dans toute la
forêt AD. Certes, ce serait bien de limiter
chaque ordinateur pour qu’il n’accepte
de paquets que des autres
ordinateurs avec lesquels il doit communiquer.
Mais la compilation et la
maintenance d’une liste de systèmes
autorisés pour chaque ordinateur seraient
hors de prix. Il faut donc fonder
les policies IPSec sur des généralisations
à propos du trafic sur le réseau.
A moins d’utiliser Windows
NetMeeting ou certaines formes d’IM
(Instant Messaging), vos stations de
travail ont peu de raison de communiquer
entre elles. CodeRed et Nimda se
propagent d’une station de travail à
une autre, et pas simplement d’une
station de travail au serveur. Il faut
donc empêcher la communication
entre stations de travail. Le moyen le
plus simple d’imposer une telle règle
consiste à utiliser IPSec en mode AH
(Authenticated Header), afin qu’un
système n’accepte que des paquets
venant vraiment de l’ordinateur qui prétend les avoir envoyés. Les seuls inconvénients
du mode AH sont une petite
dégradation des performances sur
les serveurs – les stations de travail ne
sont généralement pas affectées – et le
fait que les analyseurs de réseaux verront
le trafic comme des paquets en
mode IPSec AH au lieu de paquets TCP
ou UDP ordinaires. Au lieu d’utiliser le
mode AH, vous pouvez configurer
IPSec pour permettre ou bloquer le
trafic d’après l’adresse IP, afin que les
stations de travail rejettent le trafic de
leurs homologues. Mais il faut pour
cela que les serveurs résident sur des
subnets séparés de vos stations de travail,
afin que les filtres de paquets puissent
faire la distinction entre le trafic
des stations de travail et celui des serveurs.
Téléchargez cette ressource
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Redéfinir la confiance à l’ère de l’IA agentique : les entreprises sont-elles prêtes pour le SOC autonome ?
- IA Agentique : la vraie rupture c’est la gouvernance humaine
- Les défaillances des pipelines de données pèsent lourdement sur la performance des grandes entreprises
- Les nouvelles menaces liées à l’IA obligent les entreprises à dépasser la seule stratégie de sauvegarde
Articles les + lus
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
À la une de la chaîne Tech
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
