Pourquoi nginx commence le processus en tant que root?

J'ai installé le serveur Nginx. Je viens de vérifier les ports d'écoute et j'ai vu ce qui suit:

$ 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)
.
.
.

Et je suis simplement intéressé par la raison pour laquelle quatre processus nginx sont exécutés en tant qu’utilisateur «www-data» et un en tant qu’utilisateur «root»?

Le processus que vous avez remarqué est le processus maître, le processus qui lance tous les autres processus nginx. Ce processus est lancé par le script init qui lance nginx. La raison pour laquelle ce processus est exécuté en tant que root est simplement parce que vous l'avez démarré en tant que root! Vous pouvez le démarrer en tant qu'utilisateur différent, mais vous devrez vous assurer que toutes les ressources nécessaires à nginx sont disponibles pour cet utilisateur. Ce serait généralement au moins / var / log / nginx et le fichier pid sous / var / run /.

Le plus important; Seuls les processus racine peuvent écouter les ports inférieurs à 1024. Un serveur Web s'exécute généralement sur les ports 80 et / ou 443. Cela signifie qu'il doit être démarré en tant que root.

En conclusion, le processus maître exécuté par root est tout à fait normal et, dans la plupart des cas, nécessaire au fonctionnement normal.

Edit: exécuter quelque chose en tant que root comporte un risque de sécurité implicite. Normalement, les développeurs de ce type de logiciel ont beaucoup de connaissances sur les vecteurs d'attaque et veillent à exécuter le moins possible en tant que root. En fin de compte, vous devez simplement avoir confiance que le logiciel est de bonne qualité.

Si vous vous sentez toujours mal à l'aise, il existe un moyen d'exécuter nginx en tant qu'autre utilisateur tout en utilisant les ports inférieurs à 1024. Vous pouvez utiliser iptables pour rediriger tout le trafic entrant sur le port 80 vers un autre port, par exemple 8080, et laisser nginx écouter sur ce port.

La plupart des serveurs (Apache, Nginx, etc.) ont un processus parent appartenant à root, qui demande ensuite des copies des noeuds de travail en utilisant un utilisateur moins accrédité. Dans ce cas c'est www-data.

Exemple

Si vous regardez nginxle fichier de configuration de /etc/nginx/nginx.conf, vous remarquerez des lignes comme celle-ci:

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

La plupart des serveurs ont des options similaires à celles-ci qui stipulent sous quel utilisateur exécuter les nœuds esclaves et combien d'entre eux.

Sécurité

L'exposition de services ayant un accès root est souvent mentionnée comme une insécurité potentielle. Cependant, vous devez souvent être root pour lier des ports compris entre 1 et 1024; vous ne pouvez donc rien faire si vous voulez qu'un serveur écoute les ports 80 ou 443.

De plus, si un service est bien écrit et configuré correctement, il n’est en soi pas préjudiciable à votre sécurité. Les applications qui s'exécutent sur Apache & Nginx constituent en réalité les véritables sources d'attaques par débordement de tampon ou d'injection de serveur SQL, car ce sont les services qui exposent les points d'entrée des données mal formées à injecter dans votre pile de serveurs.

Apache et Nginx en eux-mêmes n'acceptent généralement aucune entrée autre que les méthodes GET / POST qu'ils acceptent.

C'est la façon dont l'application est packagée. Sur la plupart des * nix, la configuration par défaut est qu'un utilisateur non privilégié ne peut pas écouter sur un port <1024 et les serveurs Web utilisent 80 et 443.

Linux 2.2+, Solaris 10+ et FreeBSD permettent tous aux utilisateurs non root d'écouter sur des ports inférieurs à 1024, mais pas par défaut. La plupart ont accepté l'utilisation de, de rootsorte qu'il reste en usage.

Outre l'accès pour vous connecter au port privilégié, vous devez vous assurer que l'utilisateur qui exécute nginx a accès à tous les fichiers dont il a besoin. Vous n'avez probablement pas besoin d'aller aussi loin que cela, mais simplement de définir les permissions appropriées sur les fichiers / répertoires. Vous devez également vérifier que les scripts de démarrage ne font rien de sournois comme des ulimitmodifications (comme semble toujours le faire mysql).

Capacités Linux

setcapet getcapvous permettent de modifier ou d’afficher la cap_net_bind_servicecapacité d’un exécutable. Ce sera en vigueur pour toute personne qui exécute le binaire.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux offre la possibilité de configurer et de contrôler les capacités au niveau de l'utilisateur.

Paramètres système Freebsd

Les paramètres du port réservé sont globaux pour le système

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

Privilèges Solaris

Solaris permet un contrôle détaillé des privilèges au niveau de l'utilisateur. Ce sont les privilèges accordés à Apache, mais ils sont également susceptibles de fonctionner pour nginx.

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

J'aimerais ajouter à tout le monde des réponses autres. Bien que nginx soit lancé en tant que root, il ne s’exécute pas en tant que root. L'utilisateur (nginx, www-data, etc.) qu'il est en train d'exécuter est généralement un identifiant de connexion restreint / jailed (vous ne pouvez pas vous connecter avec, seuls certains fichiers sont accessibles). C'est l'un des avantages de l'utilisation de Linux pour les serveurs Web, par opposition à Windows. Ce processus s'appelle un fork( vous trouverez plus de détails dans cet article de Wikipédia ) et il utilise également setuidet / ou setgid( ce qui est également expliqué dans un article de Wikipedia) pour changer d'utilisateur et / ou de groupe. Dans une configuration sécurisée, un pirate informatique ne pourrait pas accéder au processus parent et utiliser le compte root. Ce n'est pas toujours vrai, car un pirate informatique pourrait utiliser une sorte d'exploit pour obtenir un accès root (il y avait une vulnérabilité dans nginx 1.4.0 et antérieure qui permettait aux pirates d'accéder à la racine).