¿Por qué se requiere sudo para iniciar un servidor web en un puerto ip: dado?

Estoy configurando un servidor web basado en Python en mi caja de Debian.

Preparar:

• El sistema operativo Debian está basado en VM, pero he cambiado VirtualBox de NAT a Bridged.
• IP de la configuración de VM = 192.168.1.7(según la pantalla de administración de mi enrutador o ifconfig).
• He configurado con éxito el reenvío de puertos de mi enrutador para ssh y HTTP.
• He configurado con éxito el dns dinámico de mi enrutador usando dyndns.com.

Independientemente del servidor web Python específico que estoy usando (Django, CherryPy, biblioteca estándar), tengo que iniciar el servidor web @ 192.168.1.7:80 usando sudo. De lo contrario, recibo un error acerca de no tener permiso para acceder al puerto. Ninguno de los tutoriales del servidor web menciona la necesidad de usar sudocuando se especifica un ip: port.

Pregunta: ¿por qué debo usar sudopara iniciar estos servidores web? ¿Es una indicación de que no debería estar usando 192.168.1.7? ¿O que no estoy configurando un archivo de configuración correctamente en alguna parte?

Solo los procesos con permisos de root pueden escuchar en puertos privilegiados. Esta es una convención de seguridad estándar de Unix.

Es un comportamiento estándar que los usuarios no privilegiados no pueden vincularse a puertos privilegiados (números de puerto inferiores a 1024). Por lo tanto, una aplicación que quisiera vincularse al puerto 80, por ejemplo, tendrá que ejecutarse con privilegios (generalmente esto significa ejecutarse como root) para vincularse a este puerto.

Un enfoque común es ejecutar un pequeño proceso de "escucha" con un usuario con privilegios que acepta la conexión y luego genera un proceso sin privilegios para manejar la solicitud. La eliminación de privilegios para el procesamiento de solicitudes se realiza por razones de seguridad. Si alguien puede explotar el proceso que maneja la solicitud, entonces generalmente permite que un intruso ejecute comandos usando los mismos privilegios que el proceso de procesamiento. Por lo tanto, sería malo manejar toda la solicitud utilizando un proceso privilegiado.

Sin embargo, para muchas aplicaciones es común hoy en día ejecutarse como no root; pero tales procesos, por supuesto, no pueden unirse a puertos privilegiados en una configuración estándar. Por lo tanto, los servidores como Tomcat o JBoss solían vincularse a puertos altos como 8080, por lo que no necesitan un oyente privilegiado.

Por supuesto, si expone este proceso a Internet, es probable que proporcione acceso en el puerto 80, ya que cada navegador primero intentará conectarse al puerto 80 cuando se utiliza el protocolo HTTP. Una solución común para proporcionar esto es usar un firewall o un traductor de puertos entre la aplicación y el Internet público. Entonces, las solicitudes llegan al firewall que solicita el puerto 80, pero el firewall envía la solicitud a algún host interno en el puerto 8080. De esta manera, el servidor web real puede operar en puertos altos mientras está disponible públicamente en el puerto 80.

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

A veces, esta redirección se realiza simplemente usando la iptablesregla NAT

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

Esto permite ejecutar una aplicación no privilegiada que escucha en el puerto 8080 mientras que todas las solicitudes entrantes para el puerto 80 se redirigen al puerto 8080.

Sin embargo, usando los núcleos modernos de Linux hay otra posibilidad: usar capacidades.

setcap CAP_NET_BIND_SERVICE=+ep /some/webserver/binary

Esto permitiría binaryenlazar a puertos privilegiados incluso cuando se inicie desde un usuario no root. Ver man capabilitiespara más detalles.