Ports IP ouverts sous Windows 2000

Sous IP, deux catégories de ports, en environnement Windows, sont réputés pour donner accès aux fonctionnalités des machines ou pour provoquer des montées de lignes intempestives sur des routeurs mal configurés. Ce sont le port de "localisation de service" (traduction personnelle de la chose) et les ports NetBios. Je leur ai consacré une autre page plus spécifique que vous pourrez trouver ici. Mais si nous nous intéressons à la sécurité globale de la machine, on ne peut se contenter d'examiner les seuls ports NetBios et RPC. Il est toujours intéressant de savoir quelles portes sont ouvertes sur sa machine.


Quels ports sont ouverts (usage de netstat) ?

La commande netstat permet de lister les ports actifs ou simplement ouverts sur sa machine. Sans argument, elle liste les ports actifs seulement.

Machine Windows 2000 pro "au repos"

La commande netstat -na permet de lister les ports actifs et ceux simplement ouverts (à l'écoute) sur une machine, sous forme numérique. Ci-dessous, c'est ce que j'ai obtenu à l'instant t sur ma machine. Vous n'aurez pas forcément exactement les mêmes. (voir plus bas)

Proto  Adresse locale         Adresse distante       Etat
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
TCP    0.0.0.0:1033           0.0.0.0:0              LISTENING
TCP    0.0.0.0:1035           0.0.0.0:0              LISTENING
TCP    192.168.0.101:139      0.0.0.0:0              LISTENING
UDP    0.0.0.0:135            *:*
UDP    0.0.0.0:445            *:*
UDP    0.0.0.0:1034           *:*
UDP    0.0.0.0:1384           *:*
UDP    0.0.0.0:1434           *:*
UDP    0.0.0.0:1558           *:*
UDP    127.0.0.1:1043         *:*
UDP    127.0.0.1:1555         *:*
UDP    192.168.0.101:137      *:*
UDP    192.168.0.101:138      *:*
UDP    192.168.0.101:500      *:*

On apprend déjà que nous sommes en attente de connexion sur un certain nombre de ports TCP (LISTENING) et en attente de datagramme sur un certains nombre de ports UDP.

Dans le cas de TCP, le 0.0.0.0:0, pour l'adresse distante, signifie que la connexion sera acceptée en provenance de toute adresse IP utilisant n'importe quel port source. Dans le cas d'UDP, cette même notion se retrouve avec la représentation *:*.

Dans le cas où le port local correspondant TCP, le 0.0.0.0:nnn (où nnn est un numéro de port différent de 0) cela signifie que le port est en écoute de toute adresse IP réclamant une ouverture de connexion TCP sur ce port, sauf dans certains cas.

En effet, du fait de l'implémentation de l'API Winsock sur TCP/IP utilisée, netstat ne peut distinguer certaines "ouvertures internes à la machine" des ouvertures réelles vers l'extérieur (dit vite fait ; pour une explication magistrale sur le sujet voir l'article suivant de HSC). Par exemple, quand une connexion sortante TCP est établie (état ESTABLISHED) depuis un port local, par exemple, ce port va apparaître aussi dans la liste des ports en écoute (état LISTENING) depuis toute adresse (0.0.0.0) sur le même port. Il paraît que ça devrait être corrigé dans Windows 2003 (nous sommes le 25/03/2003).

Exemple : soit l'extrait ci-dessous.

Proto  Adresse locale         Adresse distante       Etat
TCP    0.0.0.0:4446           0.0.0.0:0              LISTENING
TCP    10.100.1.17:4446       10.100.1.103:445       ESTABLISHED

Le port 4446 apparaît LISTENING, mais en réalité il est totalement invisible de l'extérieur, comme le montrerait un scan de port lancé au même moment.

Pour avoir une première idée de ce que cela représente, vous pouvez utiliser à la place netstat -a tout court. Vous aurez alors, pour les ports standards (well known ports) une dénomination abrégée qui permet d'avoir une idée de l'utilisation du port. Cependant cela sert surtout aux utilisateurs déjà bien informés. Ce ne sont pas les noms très courts ci-dessous qui sont très parlants pour le néophyte. Si le lecteur est impatient et déjà au fait de toutes ces choses, il peut sauter directement au tableau explicatif.

Proto  Adresse locale         Adresse distante       Etat
TCP    POSTE01:epmap         POSTE01.at.home:0       LISTENING
TCP    POSTE01:microsoft-ds  POSTE01.at.home:0       LISTENING
TCP    POSTE01:1033          POSTE01.at.home:0       LISTENING
TCP    POSTE01:1035          POSTE01.at.home:0       LISTENING
TCP    POSTE01:netbios-ssn   POSTE01.at.home:0       LISTENING
UDP    POSTE01:epmap         *:*
UDP    POSTE01:microsoft-ds  *:*
UDP    POSTE01:1034          *:*
UDP    POSTE01:1384          *:*
UDP    POSTE01:ms-sql-m      *:*
UDP    POSTE01:1558          *:*
UDP    POSTE01:1043          *:*
UDP    POSTE01:1555          *:*
UDP    POSTE01:netbios-ns    *:*
UDP    POSTE01:netbios-dgm   *:*
UDP    POSTE01:isakmp        *:*

Les lignes ci-dessus apparaissent dans le même ordre qu'avec l'option -na, ce qui permet de retrouver à quoi correspond chaque port numérique standard (du moins ceux que la commande netstat de windows est capable de reconnaître).

Machine en action relevant le courrier et autres divertissements

Avec un peu de chance et de dextérité, ou encore un peu d'astuce, vous pouvez voir dans cette même liste des ports en activité. Ruse possible : vous tentez de relever le courrier avec une mauvaise adresse de serveur pop ou en débranchant le câble réseau momentanément.

Vous verrez alors apparaître de nouvelles lignes telles que celles ci-dessous.

Proto  Adresse locale         Adresse distante       Etat
TCP    POSTE01:2132           pop3b.creteil.fr:pop3  SYN_SENT

... indiquant une tentative de connexion en attente de synchronisation (SYN_SENT), comme c'est le cas si le serveur de destination est inaccessible,

ou bien encore

Proto  Adresse locale         Adresse distante       Etat
TCP    POSTE01:2133           pop3-2.free.fr:pop3    TIME_WAIT

... indiquant une connexion récemment active (TIME_WAIT). Le relevé de courrier est fini depuis une fraction de seconde. Comment je vais bien pouvoir coincer la communication assez longtemps pour voir ce qui se passe "pendant". Une technique simple : se connecter au serveur de courrier par l'outil ligne de commande telnet en spécifiant le port 110 qui est celui du serveur pop3 en standard. La commande sous Windows 2000 serait :

telnet pop3-2.free.fr 110
Vous recevrez une bannière d'accueil du serveur pop3, comme ceci, par exemple :
+OK <20170.1011989661@pop3-2.free.fr>

Faites vos tests netstat dans une autre fenêtre puis revenez à celle-ci et tapez quit pour terminer la session pop3. Le netstat donnera quelque chose comme ceci :

TCP    POSTE101:2595          pop3-2.free.fr:pop3    ESTABLISHED

Là, la connexion est bien établie (ESTABLISHED).

Ci-dessous, un poste pris en flagrant délit de connexion http non demandée par moi. J'espère qu'il s'agit du mécanisme de windows critical update... sinon y a un espion dans la baraque (bon... je tape l'adresse dans mon browser et comme par hasard je tombe sur le site Windows update. C'est donc bien cela).

TCP    POSTE101:2522          207.68.131.27:http     ESTABLISHED

Ci-dessous, encore en pleine en action (fragment de fenêtre d'Active Ports). L'adresse IP Microsoft a changé mais je suppose qu'ils ont des centaines de serveurs possibles, pour ce service.

... et là en train de tenter de récupérer la liste des ressources du serveur toto, sur le réseau local.

TCP    POSTE101:2516          toto:netbios-ssn       ESTABLISHED

... manque de pot il n'était pas autorisé, mais ça l'analyse de port ne le dit pas ;-)

Mais quel est donc le programme qui m'a fait ça ?!!

Savoir quels ports sont ouverts c'est bien. Mais quand on ne comprend pas d'où sort cette avalanche de portes ouvertes c'est bien triste. Il y a donc deux choses à faire : se documenter et/ou mener ses propres investigations. Je ne prétend pas vous apprendre quoi que ce soit sur la première méthode puisque vous êtes en train de lire ceci . Petit rappel quand même : vous pouvez trouver la liste des ports officiellement enregistrés auprès de l'IANA. Attention, cependant, au fait que certains ports enregistrés peuvent être utilisés à d'autres fins sur un serveur ou une station donnée. Donc restons prudents, surtout pour les valeur supérieures à 1023.

Par contre je me suis longtemps cassé le nez sur la recherche d'un outil adéquat qui pourrait me dire quel processus a ouvert un port donné. Et là j'ai trouvé une perle ; il s'agit d'Active Ports de SmartLine.

Evidemment, pour certains ports vous serez déçu, parce qu'on vous dira que le processus utilisateur c'est le système (exemple des ports 137, 138, 139, 445 et 1035). Pour d'autres ça vous fera une belle jambe de connaître le nom de l'exécutable si vous ne savez pas d'où il sort (135 -> svchost.exe). Ceci dit, en cherchant sur vos disques durs ça pourra vous donner une idée.

C'est ainsi que je découvre un jour que l'un des ports de la liste (dans ce cas le 4692) ne m'est pas connu et qu'il a l'air diablement stable et bien installé. Damned ! Je lance Active Port et bon sang de bonsoir l'exécutable aussi m'est inconnu (brad32.exe). Ca y est, me dis-je, avec un nom pareil il va brader tous mes fichiers sur internet. Et en plus il est situé dans un sous-répertoire de system32. Calamitas ! Heureusement, la fouille dudit répertoire finit par me faire comprendre qu'il s'agit de l'agent de mise à jour automatique de mon anti-virus. Ouf !

Exemple d'écran :

Tableau des ports ouverts pas Windows 2000 et usage

Voici quelques éclaircissements concernant certains ports listés plus haut. J'ai pris ici une approche par port et protocole. Voir ici un lien vers une page qui a préféré une approche par fonctionnalité.

Port Proto Nom court Nom usuel Usage

Standards NetBios (page plus détaillée sur le sujet)

135
137
138
139
TCP/UDP
TCP/UDP
UDP
TCP
  Localisation de services et  NetBios Voir la page plus détaillée sur le sujet.
Install Windows 2000 pro (port standards)
445 TCP/UDP microsoft-ds SMB over IP D'habitude, exécuter le protocole SMB (partage de fichiers et d'imprimantes) en environnement IP nécessite une couche de transport supplémentaire nommée NetBT. Sous Windows 2000 ce n'est pas une obligation SMB over IP est disponible via le port 445.
500 UDP isakmp Internet Security Association and Key Management Protocol Pour l'authentification sécurisée par échange de clés. Ouvert par lsass.exe. L'explication de ce service telle qu'elle apparaît dans le gestionnaire des services : "stocke les informations de sécurité pour les comptes d'utilisateurs locaux".

Install Windows 2000 pro (ports dynamiques - peuvent être différents une autre fois1)

1033 TCP     Gestionnaire de tâches Windows 2000, installé aussi dans les autres versions de Windows avec l'arrivée de je ne sais plus quelle version d'Internet Explorer. Ne pas confondre avec le service planning programmé par la commande AT.
1034 UDP     ouvert par services.exe
1035 TCP     ouvert par le système
1036 TCP     ouvert par les services internet
3456 UDP     ouvert par les services internet
Il semble inutile de se renseigner sur les ports dynamiques ci-dessus puisqu'ils peuvent ne pas avoir la même signification d'une fois sur l'autre. Cmme je les retrouvais à chaque fois à la même place, je m'interrogeais quand même, au début... En plus je trouvais que le système avait été chercher bien loin le 3456... Et puis quelques mois plus tard, j'ai refait un test et, évidemment, les ports n'étaient plus les mêmes.
Autres
25 TCP smtp Simple Mail Transport Protocol Ca c'est parce que j'utilise Mailroam, un truc vachement utile quand on a un ordinateur portable et qu'on veut pas se faire suer avec la configuration du serveur smtp pour le courrier sortant. Allez voir chez Philippe Young pour une explication détaillée de Mailroam.
80 TCP http Hyper Text Transport Protocol Je ne me rapelle plus s'il est installé par défaut sur une station Windows 2000 pro mais ça c'est le serveur web de Microsoft (IIS). Une version un peu allégée par rapport à la version pour serveur mais assez puissante quand même.
443 TCP https le même que ci-dessus mais sécurisé Ca c'est aussi le serveur web mais la partie serveur https. 
4692 UDP     Exécutable brad32.exe. C'est l'agent de télédistribution macafee lorsqu'on installe le logiciel à travers le réseau par le biais d'une console de "management". C'est parce qu'il est à l'écoute de ce port que viruscan reçoit instantanément l'ordre de se mettre à jour venu de la console d'administration.

Vous pourrez trouver ici une page contenant un tableau dans lequel vous aurez une approche par fonctionnalité. Pour chacune des fonctionnalités Windows sont listés le ou les ports TCP et/ou UDP nécessaires. C'est également une approche intéressante. Surtout quand on cherche à comprendre pourquoi quelque chose ne marche pas.

Que se passe-t-il avec plusieurs cartes réseau ou plusieurs adresse IP ?

Deux cartes réseau

Je n'ai qu'une carte, allez-vous me dire. Je ne peux pas essayer. Ben si, vous pouvez ! Il suffit d'installer la "Carte de bouclage Microsoft" grâce à l'applet ajout/suppression de matériel du panneau de configuration. Très commode pour tester des fonctionnalités réseau quand on n'a pas de carte réseau ou bien des fonctionnalités à deux cartes quand on en a qu'une. En plus, vous pouvez l'activer et la désactiver à loisir ; inutile de la désinstaller à chaque fois.

Si j'active ma carte d'accès distant, je vois instantanément certaines lignes se dédoubler. Ce sont les suivantes.

TCP    192.168.0.101:139      0.0.0.0:0              LISTENING
TCP    192.168.2.1:139        0.0.0.0:0              LISTENING
UDP    192.168.0.101:137      *:*
UDP    192.168.0.101:138      *:*
UDP    192.168.0.101:500      *:*
UDP    192.168.2.1:137        *:*
UDP    192.168.2.1:138        *:*
UDP    192.168.2.1:500        *:*

L'adresse 192.168.0.101 est celle de ma carte réseau (la vraie) et 192.168.2.1 celle de la carte de bouclage. ON voit donc que :

Si je vais dans la configuration IP de la seconde carte (carte de bouclage) et que je choisis de désactiver NetBios avec TCP/IP, j'obtiens ceci.

TCP    192.168.0.101:139      0.0.0.0:0              LISTENING
UDP    192.168.0.101:137      *:*
UDP    192.168.0.101:138      *:*
UDP    192.168.0.101:500      *:*
UDP    192.168.2.1:500        *:*

Les ports 137, 138 et 139 ont disparus du paysage de la seconde carte.

Plusieurs adresses IP

J'ai une adresse IP (192.168.0.101) sur la première carte et 4 sur la seconde. Cela donne ceci :

TCP    192.168.0.101:139      0.0.0.0:0              LISTENING
TCP    192.168.2.1:139        0.0.0.0:0              LISTENING
UDP    192.168.0.101:137      *:*
UDP    192.168.0.101:138      *:*
UDP    192.168.0.101:500      *:*
UDP    192.168.2.1:137        *:*
UDP    192.168.2.1:138        *:*
UDP    192.168.2.1:500        *:*
UDP    192.168.2.2:500        *:*
UDP    192.168.2.3:500        *:*
UDP    192.168.2.4:500        *:*

Il y a autant de fois 137, 138 et 139 que d'adaptateurs réseaux lié à IP avec support de NetBios et autant de fois le port 500 UDP (lsass.exe) que d'adresses IP. Normal. Que se passerait-il si les ports NetBios étaient ouvert plus d'une fois sur le même adaptateur réseau ? Eh bien la machine annoncerait son nom NetBios une première fois sur le réseau via la première adresse IP, puis une seconde fois via la deuxième adresse IP et là la première adresse IP réagirait en disant "halte là ! Il y a déjà une machine avec ce nom sur le réseau". Ce serait la catastrophe. Donc fort prudemment Windows n'ouvre les ports NetBios :

La preuve ? Supprimons la première adresse IP de la carte puis remettons-là. Elle se retrouve en 4e position maintenant. Et le résultat attendu est bien là. Elle n'ouvre plus que le port 500 :

TCP    192.168.0.101:139      0.0.0.0:0              LISTENING
TCP    192.168.2.2:139        0.0.0.0:0              LISTENING
UDP    192.168.0.101:137      *:*
UDP    192.168.0.101:138      *:*
UDP    192.168.0.101:500      *:*
UDP    192.168.2.1:500        *:*
UDP    192.168.2.2:137        *:*
UDP    192.168.2.2:138        *:*
UDP    192.168.2.2:500        *:*
UDP    192.168.2.3:500        *:*
UDP    192.168.2.4:500        *:*

C'est l'adresse 192.168.2.2 qui supporte NetBios maintenant. C'est donc bien toujours la première adresse de la liste qui supporte NetBios. Important à savoir quand on met plusieurs adresses IP sur une carte.


Notes détaillées

1. Mécanisme détaillé des RPC dynamiques

Un service RPC se configure lui-même dans le registre avec un identifiant universel unique (UUID) qui est réservé à ce service et commun quel que soit la plate-forme. Quand un service RPC démarre, il réclame au système un port libre au-dessus de 1023 et "mappe" ce port sur le UUID. Certains services utilisent des numéros de ports aléatoires tandis que d'autres essaient toujours d'avoir le même s'il est libre. Ce port restera alors inchangé pour toute la durée d'exécution du service.

Quand un client veut communiquer avec un service RPC particulier, comme il ne connaît pas à coup sûr le port sur lequel il s'exécute, il se connecte d'abord au fameux service portmapper (port 135 TCP ou UDP) et demande à communiquer avec le service dont il donne l'UUID (qui, je rappelle, est connu de tous). Le portmapper retourne le numéro de port correspondant à l'UUID fourni par le client et ferme la connexion le concernant. Ce dernier peut enfin se connecter au service voulu en établissant une nouvelle connexion avec le port que lui a fourni le portmapper. Astucieux non ?!

A noter : le service portmapper (port 135 TCP ou UDP) est en réalité accessible sur deux autres "protocoles de transport" que TCP et UDP, il est aussi accessible sur canaux nommés ("named pipes" en anglais) par le canal \pipe\epmapper et dans certaines conditions sur HTTP par le port 593 (on est alors au niveau de la couche réseau application -couche 7-, c'est pourquoi j'ai mis "protocoles de transport" entre guillemets).

Finalement on peut dire que ça marche un peu comme les vecteurs d'interruption dans un PC.

Problème dans un environnement où l'on a des machines de part et d'autre d'un firewall : il faudrait ouvrir une palanquée de ports au-dessus de 1023 si l'on veut être certain que tout baigne dans l'huile avec cette assignation dynamique. Evidemment il y a un moyen de contourner cette difficulté mais c'est beaucoup plus cher en temps de configuration des serveurs. Par contre ça évite de transformer son firewall en passoire. Cela fera l'objet d'une autre page, un jour... peut-être.


mailto:etienne.durup@free.fr

Dernière mise à jour : 11.04.2003