Qu’est-ce que le port scanning ?

Les ports jouent un rôle majeur, car ils veillent à ce que les paquets de données par­vien­nent à la des­ti­na­tion souhaitée. Ils font office d‘interface entre les or­di­na­teurs et les services ou pro­grammes système, et sont utilisés par les pro­to­coles réseau TCP et UDP. Grâce à l‘adresse IP, le système d‘ex­ploi­ta­tion peut savoir non seulement à quel or­di­na­teur il envoie le flux de données, mais aussi à quel programme il doit trans­fé­rer les paquets.

Qu’est-ce que le port scanning ?

Les systèmes d’ex­ploi­ta­tion utilisent les ports pour pouvoir trans­mettre les paquets de données entrants et sortants aux bonnes ap­pli­ca­tions. Ainsi, les ports servent d’interface gérée par le système d’ex­ploi­ta­tion entre les pro­grammes en cours et Internet. Pour qu’une ap­pli­ca­tion puisse com­mu­ni­quer via un port, celui-ci doit d’abord être ouvert, c’est-à-dire débloqué. Cela pose toutefois un problème : chaque port ouvert est un accès potentiel pour les pirates si l’ap­pli­ca­tion concernée présente des failles de sécurité. Pour minimiser le risque d’une attaque, vous devriez toujours garder un œil sur les ports ouverts sur votre système et sur les ap­pli­ca­tions qui se cachent derrière.

Le terme port scanning (en français « balayage de ports ») désigne le processus devé­ri­fi­ca­tion des ports ouverts sur un système in­for­ma­tique, à l’aide d‘outils spéciaux. Pour effectuer ce type d’analyse, il n’est pas né­ces­saire d‘être en­re­gis­tré dans le système cible, mais seulement d‘y être connecté, par exemple via un réseau local ou Internet. À l‘aide du balayeur de ports, il est possible de tester l‘envoi de paquets de données précis aux dif­fé­rents ports, et de recevoir des réponses ou des messages d‘erreur que l‘outil analyse et évalue. Selon l‘étendue des fonctions du programme de nu­mé­ri­sa­tion utilisé, on obtient ainsi des in­for­ma­tions sur les ports ouverts ou fermés, mais également sur les services ou ap­pli­ca­tions qui utilisent les ports res­pec­tifs.

Le port scanning constitue un moyen très efficace pour les ad­mi­nis­tra­teurs système de sur­veil­ler le trafic sur un réseau et iden­ti­fier les po­ten­tielles vul­né­ra­bi­li­tés. Dans certains cas, il permet également de résoudre des problèmes de réseau concrets. De plus, ces outils n’ont aucune influence per­cep­tible sur la per­for­mance des systèmes examinés : ils peuvent donc être utilisés sans hé­si­ta­tion.

Le port scanning est également utile sur les or­di­na­teurs per­son­nels : dès que vous utilisez des ap­pli­ca­tions qui né­ces­si­tent une connexion Internet, les ports sont au­to­ma­ti­que­ment ouverts si votre pare-feu ne l’empêche pas. Un balayage de ports vous aide à garder une vue d’ensemble et vous montre les ports qui ne sont plus utilisés et que vous pouvez ensuite fermer afin de minimiser le risque de sécurité.

Comment fonc­tionne le port scanning ?

Les balayeurs de ports offrent dif­fé­rentes méthodes par défaut, dont la plupart sont basées sur le protocole TCP. Il est utile de jeter un coup d‘œil rapide à la con­fi­gu­ra­tion générale du protocole TCP afin de com­prendre les processus de base lors du port scanning.

• Dans le cadre du processus de handshake à trois voies, le client envoie d‘abord un paquet SYN (pour syn­chro­ni­ser) au port cible cor­res­pon­dant.
• S‘il arrive à une ap­pli­ca­tion de cette façon, il récupère un paquet combiné SYN/ACK (syn­chro­nize ack­now­ledge = « confirmer la syn­chro­ni­sa­tion »), qui confirme la connexion.
• À la troisième et dernière étape, le client renvoie un paquet ACK (ack­now­ledge = « confirmer »), qui permet d’établir la connexion et de commencer l‘échange de données.
• Si un port fermé est contacté, le client reçoit un paquet RST (reset = « réi­ni­tia­li­ser ») à la deuxième étape, après laquelle le handshake est annulé.

Dans la mesure où il serait très complexe et coûteux d‘échanger des données avec les dif­fé­rentes ap­pli­ca­tions, le port scanning se limite à de simples ten­ta­tives de connexion, telles que l’il­lustrent les méthodes de balayage communes pré­sen­tées ci-dessous.

Scan TCP SYN

Le scan TCP SYN est souvent appelé « scan semi-ouvert » parce qu‘il ne vise pas à établir une connexion TCP complète. On utilise cette méthode avec le balayeur de ports pour envoyer des paquets SYN communs aux ports in­di­vi­duels en attendant la réponse de l‘hôte cible. S‘il renvoie un paquet SYN/ACK, il signale que le port cor­res­pon­dant est ouvert et qu‘une connexion peut être établie. Si la réponse consiste en un paquet RST, cela signifie que le port est fermé. S’il n’y a pas de réponse, il est probable qu’un filtre de paquets, tel qu‘un pare-feu, soit situé en amont.

Les scans TCP SYN ne sont pas visibles pour les ap­pli­ca­tions analysées, et ne génèrent donc pas de données log, c‘est pourquoi ils sont également appelés « scans furtifs ».

Scan TCP Connect

Pour effectuer une analyse de connexion, il est conseillé d’utiliser son propre balayeur de ports, de ne pas envoyer ou générer soi-même les paquets de données, mais d’utiliser plutôt l‘appel système de connexion. Ceci est dis­po­nible sur la majorité des systèmes d‘ex­ploi­ta­tion. Un éta­blis­se­ment de connexion réussi est considéré comme une con­fir­ma­tion que le port cor­res­pon­dant est ouvert. Si la connexion échoue, le port est marqué comme fermé. Les fichiers journaux des ap­pli­ca­tions res­pec­tives avec ports ouverts montrent que cette méthode d‘analyse a été utilisée lorsque la connexion est com­plè­te­ment établie. Toutefois, il ne fournit aucune in­for­ma­tion sur les pro­grammes de filtrage utilisés. Si vous ne disposez pas des droits pour envoyer des paquets de données brutes, l‘analyse TCP Connect reste une al­ter­na­tive utile à l’analyse SYN.

Les scans TCP-FIN, Xmas et Null

Ces trois méthodes de port scanning per­met­tent également de dis­tin­guer les ports ouverts et fermés. Pour ce faire, on utilise deux principes de TCP qui sont men­tion­nés dans le RFC 793“) cor­res­pon­dant :

• Les paquets entrants qui ne sont pas des paquets RST doivent toujours répondre par un port fermé avec leur propre paquet RST
• Tous les paquets qui ne sont pas marqués comme SYN, RST ou ACK doivent être ignorés par un port ouvert.

Les trois types de scan ex­ploi­tent cette situation lors du port scanning des systèmes conformes au RFC avec leurs paquets in­di­vi­duels :

• Le scan Null n’utilise pas de marquage spé­ci­fique.
• Le FIN Scan permet au balayeur de ports d’envoyer des paquets FIN (finish = « finir »).
• Les scans Xmas reposent sur une com­bi­nai­son de marqueurs FIN, PSH (push = « faire avancer ») et URG (urgent), qui il­lu­mi­nent le scanneur tel un sapin de Noël, d’où son nom. Les trois méthodes d’analyse fonc­tion­nent exac­te­ment de la même manière. Les paquets de test envoyés s’assurent qu’un port fermé réponde par un paquet RST, et qu’un port ouvert ne renvoie pas de réponse, à cause des ré­gle­men­ta­tions RFC. Toutefois, puisque seuls quelques routeurs signalent un message d’erreur lors du filtrage d’un port, l’absence de réponse peut également indiquer qu’il s’agit d’un port filtré. Si les pro­cé­dures sont encore plus discrètes que les scans SYN, elles pré­sen­tent toutefois l‘in­con­vé­nient de ne pas fonc­tion­ner si les systèmes n‘adhèrent pas exac­te­ment à la RFC 793. Windows en est le re­pré­sen­tant principal.

UDP-Scan

Un scan UDP envoie des en-têtes UDP vides, c’est-à-dire ne contenant aucune donnée, à tous les ports cibles. Lorsqu’un service répond à son tour par un paquet UDP, ceci confirme que le port en question est ouvert. Si le balayeur de port reçoit un message d‘erreur “port inac­ces­sible” (type 3, code 3), ceci lui indique que le port est fermé. D‘autres messages d‘erreur peuvent indiquer que le port est bloqué par un filtre de paquets. L’in­con­vé­nient principal du test de port UDP réside dans les durées d’analyse très longues. En effet, pour des raisons de sécurité, les messages d‘erreur peuvent prendre beaucoup de temps sur de nombreux systèmes pour être générés, et les ports ouverts ne répondent que de façon très ir­ré­gu­lière. Par exemple, le noyau Linux limite le nombre de messages à un par seconde, ce qui implique environ 18 heures d‘analyse pour 65 535 ports.

Quels sont les balayeurs de ports dis­po­nibles ?

S’il existe des scanneurs re­la­ti­ve­ment variés, pré­sen­tant des fonc­tion­na­li­tés dif­fé­rentes, la plupart des outils dis­po­nibles sont freeware ou open source. Nombre d’entre eux sont des pro­grammes de ligne de commande clas­siques, dont on peut également se servir via des in­ter­faces uti­li­sa­teur gra­phiques séparées. Par ailleurs, il existe sur le Web de nom­breuses solutions per­met­tant de scanner les ports di­rec­te­ment depuis un na­vi­ga­teur. Ces services sont toutefois limités sur le plan fonc­tion­nel, puisqu’ils ne per­met­tent d’analyser les ports que de façon in­di­vi­duelle. C’est par exemple le cas du balayeur de ports de DNStools. C‘est la raison pour laquelle ils sont plus adaptés à une uti­li­sa­tion oc­ca­sion­nelle, comme des contrôles rapides à domicile.

Netcat, le plus ancien des outils réseau

Netcat (abrégé en NC) a été publié en 1996 par un dé­ve­lop­peur anonyme, sous le pseu­do­nyme « Hobbit ». Écrit à l‘origine pour les pla­te­formes UNIX, il existe main­te­nant diverses options de portage pour d‘autres systèmes comme Windows, et de nombreux dé­ve­lop­pe­ments telles que GNU Netcat, OpenBSD Netcat, Cryptcat ou Netcat6 (com­pa­tible avec IPv6), qui sont im­plé­men­tées par défaut dans de nom­breuses dis­tri­bu­tions Linux. La version de base de l‘outil en ligne de commande est prin­ci­pa­le­ment utilisée pour envoyer ou lire des données via les con­nexions réseau TCP et UDP, mais peut également être utilisée pour le port scanning simples. Par exemple, on peut utiliser une commande simple telle que :

nc -zv localhost 20-30

Ceci permet de vérifier l‘état des ports 20 à 30 sur le système d‘exécution. L’analyse des ports UDP a besoin du paramètre ad­di­tion­nel -u. Il est également possible d’entrer les noms d’hôtes ou les adresses IP de systèmes externes à la place de localhost, si vous les con­nais­sez.

Une analyse réseau illimitée avec Nmap

Network Mapper 1997, mieux connu sous le nom de Nmap, est un outil beaucoup plus puissant, qui convainc prin­ci­pa­le­ment grâce à sa fonction de balayeur de ports. Le programme, développé pour les systèmes unixoid, est publié sous licence GPL. Depuis 2000, il est également dis­po­nible pour les systèmes Windows, avec quelques limites toutefois. Par exemple, l‘analyse TCP Connect dure très longtemps, à cause de l‘API réseau Windows, et il n’est possible d’effectuer une analyse des ports système qu’en passant par des méthodes dé­tour­nées. Par défaut, Nmap peut être exploité depuis la ligne de commande. Toutefois, avec Zenmap, il existe une interface uti­li­sa­teur graphique puissante grâce à laquelle on peut utiliser l‘outil réseau de façon encore plus pratique.

L‘inventeur de Nmap, Gordon Lyon, ainsi que l‘équipe de dé­ve­lop­peurs de Nmap font cons­tam­ment évoluer le programme et ses capacités de port scanning, ce qui explique la grande variété de fonc­tion­na­li­tés. Par exemple, des tech­niques comme l‘iden­ti­fi­ca­tion des em­preintes digitales de l‘OS (la re­con­nais­sance du système d‘ex­ploi­ta­tion d‘un hôte cible en par­ti­cu­lier), et la lecture des services qui sont cachés derrière un port font de Nmap l‘une des solutions de port scanning les plus ap­pré­ciées. Cette diversité se reflète également dans les méthodes d’analyse dis­po­nibles, résumées dans le tableau suivant :

Il est possible de té­lé­char­ger Nmap et l’interface Zenmap pour le moteur de recherche de votre choix, à partir de la page of­fi­cielle. Il y a deux versions dis­po­nibles : la version actuelle (stable) et la version bêta (de­ve­lop­ment), qui est en cours de dé­ve­lop­pe­ment.

Pourquoi le port scanning n’est-il pas toujours légal ?

Un contrôle des ports n‘est pas toujours effectué dans un cadre légal et à des fins honnêtes, et toute tentative d‘ex­ploi­ta­tion ul­té­rieure des résultats est passible de pour­suites ju­di­ciaires. Si l‘on effectue un balayage intensif des ports qui conduit à paralyser un système, la situation juridique est moins claire. En raison du grand nombre de demandes de connexion, la méthode de contrôle impose parfois une charge im­por­tante au système cible, ce qui peut provoquer un crash. Par ailleurs, les res­pon­sables du système cible peuvent s’aper­ce­voir du contrôle en cours avant même le plantage, et l’in­ter­pré­ter comme les premières étapes d‘une cy­be­rat­taque. Dans ce cas, d’éven­tuelles con­sé­quences ju­ri­diques ne peuvent être exclues. Si le système externe est dé­li­bé­ré­ment surchargé, il s‘agit d‘attaques dites DoS ou DDoS qui sont largement passibles de pour­suites pénales.

Par con­sé­quent, il est essentiel de toujours s’assurer que l’on est autorisé à effectuer un scan de port sur le système concerné, et que l’on n’utilise cette tech­no­lo­gie qu‘à des fins de sécurité, et non par seule curiosité ou à des fins mal­veil­lantes. Les dif­fé­rentes manières d‘utiliser le port scanning il­lustrent à quel point il est important de garder un œil sur les ports de son propre or­di­na­teur système ou réseau, ainsi que sur les dif­fé­rents services qui y accèdent.