Filtrage des ports

du port TCP 443 pour la
sécurité SSL (Secure Sockets Layer), du
port TCP/UDP 53 pour DNS, du port
TCP 25 pour SMTP et peut-être
d’autres ports en fonction de vos besoins. N’autorisez des communications
que pour les services dont vous
avez besoin et n’exposez jamais les
ports réseau Microsoft (ports
TCP/UDP 137, 138, 139 et 445) à  un réseau
non sécurisé. Les ports réseau, en
particulier, et les services connexes qui
les utilisent, offrent autant d’angles
d’attaque. Quand vous configurez IIS,
je vous conseille de commencer par le
port 80 avec la ferme intention de
n’ouvrir aucun autre port sauf s’il y a
une bonne raison de le faire. Certes, de
nombreux sites comptent sur les parefeu
pour le filtrage des ports. Pour ma
part, je préfère configurer les serveurs
IIS dans la DMZ (demilitarized zone)
comme si un pirate avait pénétré le
pare-feu. La défense basée sur l’hôte,
comme on l’appelle parfois, constitue
une couche importante dans un dispositif
de sécurité approfondi.
Pour le filtrage de ports, mon outil
favori est l’utilitaire IPSec (IP Security).
Il fonctionne bien, il est gratuit, et on
peut l’exécuter à  partir d’une ligne de
commande. Le principal objectif
d’IPSec n’est pas le filtrage des ports
mais plutôt la création de connexions
point à  point mutuellement authentifiées
et cryptées. Supposons que vous
créiez une connexion IPSec entre IIS et
un pare-feu Server 2000 ISA (Internet
Security and Acceleration) et que vous
créiez une autre connexion allant du
pare-feu ISA Server 2000 à  un système
Microsoft SQL Server. Vous pouvez
configurer ces connexions pour
qu’elles s’authentifient mutuellement
à  l’aide de certificats et pour crypter
tout le trafic. Si un pirate accède à  un
ordinateur dans la DMZ, il sera incapable
de contacter la machine SQL
Server puisque celle-ci demande qu’un
certificat stocké sur le serveur IIS soit
défini vers la machine SQL Server à 
partir de l’adresse IP du serveur IIS et il
ne pourra pas renifler le trafic crypté.
Je vous conseille de bien analyser la
protection d’IPSec car elle est très
puissante.
IPSec peut aussi appliquer un filtrage
de ports tenant compte de l’état.
Ainsi, si votre adresse de serveur IIS est
1.1.1.1 et si ce serveur se connecte à 
votre machine SQL Server sur 1.1.1.2,
vous pouvez configurer 1.1.1.1 pour
qu’il ne converse qu’avec un 1.1.1.2 et
n’utiliser que le port 1433 – pour plus
de détails, voir l’article Microsoft « INF:
TCP Ports Needed for Communication
to SQL Server Through a Firewall »
(http://support.microsoft.com/?kbid=
287932). De la même manière, vous
pouvez configurer l’adresse IP publique
IIS pour qu’elle n’utilise que le
port 80 et n’importe quel autre des
ports requis. IPSec est suffisamment
fûté pour autoriser les connexions sortantes
en réponse aux requêtes sur le
port 80. IPSec permet aussi de bloquer
le trafic sortant du port 80 afin que
vous ne puissiez pas utiliser Microsoft
IE (Internet Explorer) pour naviguer à 
partir du serveur IIS, une précaution
de sécurité courante.
Bien que l’interface utilisateur
IPSec demande d’être étudiée, l’article
Microsoft « Building and Configuring
More Secure Web Sites » (http://
msdn.microsoft.com/library/en-us/dnnetsec/
html/openhack.asp) la décrit en
détail. De leur côté, Joel Scambray et
Stuart McClure fournissent aussi une
bonne explication de l’intérêt d’utiliser
IPSec avec IIS dans leur ouvrage
Hacking Exposed Windows 2000
(McGraw-Hill Osborne, 2001).
Pour créer des règles IPSec pour
Win2K, vous pouvez vous servir de
l’utilitaire ligne de commande
Ipsecpol, disponible chez Microsoft à 
http://www.microsoft.com/windows
2000/techinfo/reskit/tools/existing/ip
secpol-o.asp. Ainsi, pour créer une
règle qui n’autorise que le trafic entrant
sur le port 80, vous taperiez

Ipsecpol \\servername -x -w REG -p
« Port80only » -r « BlockEverything » -n
BLOCK -f 0+*
Ipsecpol \\servername -x -w REG -p
« Port80only » -r « Allow80 » -n PASS
0:80+*::TCP

Si vous utilisez le filtrage de ports
IPSec, vous devez lire l’article
Microsoft « IPSec Default Exemptions
Can Be Used to Bypass IPSec
Protection in Some Scenarios »
(http://support.microsoft.com/?kbid=
811832) pour voir si vous devez ajouter
le paramètre de registre NoDefaultExempt
sur votre serveur. Si vous
n’ajoutez pas ce paramètre et si IPSec
voit du trafic allant et venant du port
88, le serveur ignorera vos filtres. Ce
comportement d’exemption est conçu
pour que Kerberos puisse continuer à 
travailler même si vous bloquez spécifiquement
les ports Kerberos. Le paramètre
du registre, quand il est présent
et de valeur 1, lève cette exemption.
J’ai découvert récemment que le fait
d’appliquer Win2K Service Pack 4
(SP4) installe ce paramètre de registre.
Pour plus d’informations sur les ports
utilisés couramment dans Win2K, voir
la table intitulée Default Port Assignments
for Common Services à  http://
www.microsoft.com/Windows2000/techinfo/
reskit/sample chapters/cncf/
cncf_por_simw.asp.