Pourquoi les ports inférieurs à 1024 privilégié? [fermé]
j'ai entendu dire que c'était censé être un dispositif de sécurité, mais ça ressemble souvent à un problème de sécurité. Si je veux écrire un serveur qui utilise un port privilégié, non seulement je dois m'inquiéter de la sécurité de mon code, mais je dois surtout m'inquiéter de savoir si j'utilise setuid right et si je laisse tomber les privilèges.
2 réponses
vrai. Mais cela signifie aussi que quiconque vous parle sait que vous devez avoir les privilèges root pour exécuter ce serveur. Lorsque vous vous connectez à un serveur sur le port 22 (disons), vous savez que vous parlez à un processus qui a été exécuté par root (les problèmes de sécurité mis à part), donc vous lui faites confiance avec votre mot de passe pour ce système, ou d'autres informations que vous pourriez ne pas faire confiance à quiconque ayant un compte d'utilisateur sur ce système.
référence: http://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html .
Éditer pour développer le raisonnement: beaucoup des services réseau les plus importants - telnet (oui, il est encore utilisé - étonnamment souvent), SSH, de nombreux services HTTP, FTP, etc. etc. - implique l'envoi de données importantes comme des mots de passe sur le fil. Dans une configuration sécurisée, une sorte de cryptage, inhérent au protocole (SSH) ou enveloppé (stunnel, IPSec), protège les données d'être fouillé sur le fil, mais toutes ces protections se terminent au serveur.
afin de protéger vos données correctement, vous devez être sûr que vous parlez de la "vraie" server. Aujourd'hui, les certificats sécurisés sont la façon la plus importante de le faire sur le web (et ailleurs): vous supposez que seul le serveur "réel" a accès au certificat, donc si vous vérifiez que le serveur à qui vous parlez a ce certificat, vous lui faites confiance.
travail dans les ports privilégiés de manière très similaire: seul root a accès aux ports privilégiés, donc si vous parlez à un port privilégié, vous savez que vous parlez à root. Ce n'est pas très utile sur le web moderne: ce qui importe est le identité du serveur, pas son IP. Dans d'autres types de réseaux, ce n'est pas le cas: dans un réseau universitaire, par exemple, les serveurs sont souvent contrôlés physiquement par un personnel de confiance dans des salles sécurisées, mais les étudiants et le personnel ont un accès tout à fait libre en tant qu'utilisateurs. Dans ce situation il est souvent sûr de supposer que vous pouvez toujours faire confiance à root, de sorte que vous pouvez vous connecter et envoyer des données privées à un port privilégié en toute sécurité. Si les utilisateurs ordinaires pouvaient écouter sur tous les ports, vous auriez besoin d'une couche supplémentaire entière pour vérifier qu'un programme particulier était fiable avec certaines données.
vous ne dites pas quelle plate-forme vous utilisez, mais sur Linux au moins vous pouvez utiliser des capacités (spécifiquement CAP_NET_BIND_SERVICE) pour permettre à un processus non-root d'écouter sur un port inférieur à 1024. Voir, par exemple, . Existe-t-il un moyen pour les processus non-root de se lier aux ports" privilégiés " de Linux?
une autre alternative est de mettre en place des règles iptables pour transférer le trafic du port privilégié vers le port non privilégié (j'ai utilisé ceci dans de production, et il est assez simple et fonctionne bien). Il est également décrit dans le lien ci-dessus.