Pourquoi sudo est-il requis pour démarrer un serveur Web sur un port ip: donné?

J'installe un serveur Web basé sur Python sur ma boîte Debian.

Installer:

• Le système d'exploitation Debian est basé sur une machine virtuelle, mais j'ai fait passer la VirtualBox de NAT à Bridged.
• IP de la configuration VM = 192.168.1.7(selon l'écran d'administration de mon routeur ou ifconfig).
• J'ai réussi à configurer la redirection de port de mon routeur pour ssh et HTTP.
• J'ai réussi à configurer le DNS dynamique de mon routeur à l'aide de dyndns.com.

Quel que soit le serveur Web Python spécifique que j'utilise (Django, CherryPy, bibliothèque standard), je dois démarrer le serveur Web @ 192.168.1.7:80 en utilisant sudo. Sinon, j'obtiens une erreur indiquant que je n'ai pas l'autorisation d'accéder au port. Aucun des didacticiels sur le serveur Web ne mentionne la nécessité d'utiliser sudolors de la spécification d'un port ip :.

Question: pourquoi dois-je utiliser sudopour démarrer ces serveurs Web? Est-ce une indication que je ne devrais pas utiliser 192.168.1.7? Ou que je ne configure pas correctement un fichier de configuration quelque part?

Seuls les processus avec des autorisations root peuvent écouter sur des ports privilégiés. Il s'agit d'une convention de sécurité Unix standard.

C'est un comportement standard que les utilisateurs non privilégiés ne sont pas autorisés à se lier à des ports privilégiés (numéros de port inférieurs à 1024). Par conséquent, une application qui souhaite se lier au port 80 par exemple devra exécuter des privilèges (généralement cela signifie s'exécuter en tant que root) afin de se lier à ce port.

Une approche courante consiste à exécuter un petit processus "d'écoute" avec un utilisateur privilégié qui accepte la connexion, puis génère un processus non privilégié pour gérer la demande. La suppression des privilèges pour le traitement des demandes est effectuée pour des raisons de sécurité. Si quelqu'un est capable d'exploiter le processus qui gère la demande, il permet généralement à un intrus d'exécuter des commandes en utilisant les mêmes privilèges que le processus de traitement. Par conséquent, il serait mauvais de traiter l'ensemble de la demande à l'aide d'un processus privilégié.

Cependant, pour de nombreuses applications, il est courant aujourd'hui de fonctionner en tant que non root; mais de tels processus ne peuvent bien sûr pas se lier à des ports privilégiés alors en configuration standard. Ainsi, des serveurs comme Tomcat ou JBoss se connectaient à des ports élevés comme 8080 à la place, de sorte qu'ils n'ont pas besoin d'un écouteur privilégié.

Bien sûr, si vous exposez un tel processus à Internet, vous fournirez probablement un accès sur le port 80 car chaque navigateur essaiera d'abord de se connecter au port 80 lorsque le protocole HTTP est utilisé. Pour contourner ce problème, il est courant d'utiliser un pare-feu ou un traducteur de port entre l'application et l'Internet public. Ainsi, les demandes atteignent le pare-feu demandant le port 80 mais le pare-feu transmet la demande à un hôte interne sur le port 8080. De cette façon, le vrai serveur Web peut fonctionner sur des ports élevés tout en étant accessible au public sur le port 80.

- (internet request) ----> (port 80)[Firewall] ------> (port 8080)[Webserver]

Parfois, cette redirection se fait simplement en utilisant la iptablesrègle NAT:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Cela permet d'exécuter une application non privilégiée à l'écoute sur le port 8080 tandis que toutes les demandes entrantes pour le port 80 sont simplement redirigées vers le port 8080.

Cependant, en utilisant les noyaux Linux modernes, il existe une autre possibilité: utiliser les capacités.

setcap CAP_NET_BIND_SERVICE=+ep /some/webserver/binary

Cela permettrait binaryde se lier à des ports privilégiés même lorsqu'il est démarré à partir d'un utilisateur non root. Voir man capabilitiespour plus de détails.