¿Por qué nginx comienza a procesarse como root?

He instalado el servidor nginx. Acabo de comprobar los puertos de escucha y vi lo siguiente:

$ sudo lsof -nP -i | grep LISTEN
sshd       614     root    3u  IPv4   7712      0t0  TCP *:22 (LISTEN)
nginx      822     root    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      827 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      828 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      829 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      830 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
.
.
.

Y solo me interesa ¿por qué hay cuatro procesos nginx ejecutados como usuario 'www-data' y uno como 'usuario root'?

El proceso que notó es el proceso maestro, el proceso que inicia todos los demás procesos nginx. Este proceso lo inicia el script de inicio que inicia nginx. ¡La razón por la que este proceso se ejecuta como root es simplemente porque lo inició como root! Puede iniciarlo como otro usuario, pero deberá asegurarse de que todos los recursos que nginx necesita estén disponibles para este usuario. Normalmente sería al menos / var / log / nginx y el archivo pid en / var / run /.

Más importante; Solo los procesos raíz pueden escuchar puertos por debajo de 1024. Un servidor web generalmente se ejecuta en el puerto 80 y / o 443. Eso significa que debe iniciarse como raíz.

En conclusión, el proceso maestro que ejecuta root es completamente normal y, en la mayoría de los casos, necesario para el funcionamiento normal.

Editar: ejecutar cualquier cosa como root conlleva un riesgo de seguridad implícito. Normalmente, los desarrolladores de este tipo de software tienen mucho conocimiento sobre los vectores de ataque y tienen mucho cuidado de ejecutar lo menos posible como root. Al final, simplemente tiene que confiar en que el software es de buena calidad.

Si aún se siente incómodo, hay una manera de ejecutar nginx como otro usuario y aún usar puertos inferiores a 1024. Puede usar iptables para redirigir todo el tráfico entrante en el puerto 80 a otro puerto, por ejemplo 8080, y hacer que nginx escuche en ese puerto.

La mayoría de los servidores (Apache, Nginx, etc.) tienen un proceso padre que es propiedad de root que luego bifurca copias de los nodos de trabajo utilizando un usuario con menos credenciales. En este caso lo es www-data.

Ejemplo

Si echa un vistazo al nginxarchivo de configuración de, /etc/nginx/nginx.confnotará líneas como esta:

user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

La mayoría de los servidores tienen opciones similares a esta que estipulan qué usuario ejecutará los nodos esclavos y cuántos de ellos.

Seguridad

Exponer los servicios que tienen acceso a la raíz a menudo se menciona como una posible inseguridad. Sin embargo, a menudo tiene que ser root para unirse a puertos que van del 1 al 1024, por lo que no hay nada que pueda hacer si desea que un servidor escuche en dichos puertos 80 o 443.

Además, si un servicio está bien escrito y configurado correctamente, en sí mismo no es necesariamente perjudicial para su postura de seguridad. Las aplicaciones que se ejecutan sobre Apache y Nginx son realmente las verdaderas fuentes de desbordamiento del búfer o ataques de inyección del servidor SQL, ya que las aplicaciones son los servicios que exponen los puntos de entrada para que los datos con formato incorrecto se inyecten en la pila del servidor.

Apache y Nginx por sí mismos, generalmente no aceptan ninguna entrada más allá de los métodos GET / POST que aceptan.

Es la forma en que se empaqueta la aplicación. En la mayoría de * nix, la configuración predeterminada es que un usuario no privilegiado no puede escuchar en un puerto <1024 y los servidores web usan 80 y 443.

Sin embargo, Linux 2.2+, Solaris 10+ y FreeBSD permiten a los usuarios no root escuchar en puertos inferiores a 1024, pero no de manera predeterminada. La mayoría ha aceptado el uso de rootmodo que sigue en uso.

Además del acceso para enlazar con el puerto privilegiado, debe asegurarse de que el usuario que ejecuta nginx tenga acceso a todos los archivos que necesita. Probablemente no necesite ir tan lejos como esto, solo configure el permiso correcto en los archivos / directorios. También debe verificar que las secuencias de comandos de inicio no hagan nada astuto como los ulimitcambios (como mysql siempre parece hacer).

Capacidades de Linux

setcapy le getcappermite cambiar o ver la cap_net_bind_servicecapacidad de un ejecutable. Esto será efectivo para cualquiera que ejecute el binario.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux proporciona la capacidad de configurar y controlar capacidades a nivel de usuario.

Configuraciones del sistema Freebsd

La configuración del puerto reservado es global para el sistema

sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0

Privilegios de Solaris

Solaris proporciona un control detallado de los privilegios a nivel de usuario. Estos son los privilegios para apache, pero es probable que también funcionen para nginx.

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx

Me gustaría agregar a todos más respuestas. Aunque nginx se inicia como root, en realidad no se ejecuta como root. El usuario (nginx, www-data, etc.) que realmente se está ejecutando, ya que generalmente es un inicio de sesión restringido / encarcelado (no puede iniciar sesión con él, solo se puede acceder a ciertos archivos). Esta es una de las ventajas de usar Linux para servidores web en lugar de Windows. Este proceso se llama un fork( puede encontrar más detalles en este artículo de Wikipedia ) y también usa setuidy / o setgid( que también se explica en un artículo de Wikipedia) para cambiar el usuario y / o grupo. En una configuración segura, un hacker no podrá acceder al proceso padre y utilizar la cuenta raíz. Esto no siempre es cierto, ya que un hacker podría utilizar algún tipo de explotación para obtener acceso a la raíz (había una vulnerabilidad en nginx 1.4.0 y versiones inferiores que permitía a los hackers obtener acceso a la raíz).