Des tonnes de vulnérabilités sont trouvées sur le port tcp / 0 à l'aide de scanners de vulnérabilité
Analyse de vulnérabilité effectuée sur les serveurs Linux/Unix par Nessus et des milliers de vulnérabilités sont sorties du port tcp/. Comment un port réservé IANA (tcp/0) pourrait-il gérer le trafic? Ces vulnérabilités sont-elles vraiment dénombrables ou se sont-elles révélées faussement positives? Comment procéder pour le processus de correction des vulnérabilités affichées sous le port tcp/0?
Comment un port réservé IANA (tcp/0) pourrait-il gérer le trafic?
Il peut. Généralement, TCP (ou UDP) le port 0 étant dans un état réservé ne signifie pas qu'il ne peut pas être utilisé dans la pratique. Bien que la façon dont les sockets Berkeley sont conçus ce n'est pas si facile de se lier sur le port zéro, c'est quand même possible de l'utiliser.
Cependant , il est très peu probable que cela se produise qui se produit réellement dans votre cas. Vous utilisez simplement le scanner Nessus qui répertorie les activités qui ne sont pas étroitement liées à un port spécifique sous le port 0/TCP ou 0/UDP (voir: "Vulnerabilities by Host" =). Il s'agit simplement d'une convention (peu pratique?) Pour afficher sans port des avertissements sous le port 0 - ironiquement, pour éviter toute confusion.
Notez que ces a) ne sont pas nécessairement des vulnérabilités, juste des avertissements ou des suggestions (par exemple, ne pas adhérer à les meilleures pratiques Microsoft lors de l'exécution d'un scanner); b) ne sont pas nécessairement de faux positifs. Essayez d'ignorer le port zéro lui-même, lisez attentivement le rapport et agissez en conséquence.
Comment un port réservé IANA (tcp/0) pourrait-il gérer le trafic?
Bien que la réponse acceptée explique comment le port 0 est toujours un vrai port, il peut être utile de comprendre le fonctionnement des ports dans TCP. Ci-dessous se trouve un diagramme de 32 bits du paquet a TCP, à l'échelle. UDP est similaire, bien que beaucoup plus simple (après les ports, il a juste un champ de longueur et un champ de somme de contrôle) avant les données).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + ------------------------------- + ---------------- --------------- + | Port source | Port de destination | + ------------------------------- + --------- ---------------------- + | Numéro de séquence | + ----------------------------------------- ---------------------- + | Numéro d'accusé de réception | + ------- + ----------- + - + - + - + - + - + - + --------- ---------------------- + | Données | | U | A | P | R | S | F | | | Décalage | Réservé | R | C | S | S | Y | I | Fenêtre | | | | G | K | H | T | N | N | | + ------- + ----------- + - + - + - + - + - + - + ----------- -------------------- + | Somme de contrôle | Pointeur urgent | + ------------------------------- + --------- ---------------------- + | Options | Rembourrage | + ------------------------------------------ ----- + --------------- + | | /... Données (facultatif) ... / | | + ------------------------------------------- -------------------- +
Comme vous pouvez le voir, les champs du port source et du port de destination ont une largeur de 16 bits. Cela signifie qu'il peut représenter 65536 états possibles différents, de 0 à 65535. C'est d'ailleurs la raison pour laquelle il n'y a pas de ports négatifs, car la valeur est traitée comme non signée. La seule chose qui empêche tous les ports d'être tous des octets nuls (représentant le port 0) est une norme IANA disant de ne pas faire cela. Il est parfaitement possible qu'un paquet soit envoyé avec n'importe lequel des ports mis à 0. Le but de garder le port 0 réservé est de permettre à "juste me donner n'importe quel port" d'être représenté par un entier de 16 bits. Lorsqu'une tentative est effectuée pour se lier à TCP/0, plutôt que d'écouter les paquets avec le port de destination défini sur tous les zéros, le système est censé se lier à n'importe quel port disponible.