Warum startet Nginx den Prozess als root?

Ich habe Nginx Server installiert. Ich habe gerade die Abhörports überprüft und Folgendes gesehen:

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

Und mich interessiert nur, warum es vier Nginx-Prozesse gibt, die als 'www-data'-Benutzer und einer als' root-Benutzer 'ausgeführt werden.

Der Prozess, den Sie bemerkt haben, ist der Master-Prozess, der alle anderen Nginx-Prozesse startet. Dieser Prozess wird durch das Init-Skript gestartet, das nginx startet. Der Grund, warum dieser Prozess als root ausgeführt wird, ist einfach, dass Sie ihn als root gestartet haben! Sie können es als ein anderer Benutzer starten, aber Sie müssen sicherstellen, dass alle Ressourcen, die nginx benötigt, für diesen Benutzer verfügbar sind. Das wäre normalerweise mindestens / var / log / nginx und die PID-Datei unter / var / run /.

Am wichtigsten; Nur Root-Prozesse können Ports unter 1024 überwachen. Ein Webserver wird normalerweise auf Port 80 und / oder 443 ausgeführt. Dies bedeutet, dass er als Root gestartet werden muss.

Zusammenfassend ist der von root ausgeführte Master-Prozess völlig normal und in den meisten Fällen für den normalen Betrieb erforderlich.

Bearbeiten: Alles als root auszuführen birgt ein implizites Sicherheitsrisiko. Normalerweise haben Entwickler dieser Art von Software viel Wissen über Angriffsvektoren und achten sehr darauf, so wenig wie möglich als root auszuführen. Am Ende muss man einfach darauf vertrauen, dass die Software von guter Qualität ist.

Wenn Sie sich weiterhin unwohl fühlen, können Sie nginx als anderen Benutzer ausführen und weiterhin Ports unter 1024 verwenden. Sie können iptables verwenden, um den gesamten eingehenden Datenverkehr auf Port 80 auf einen anderen Port umzuleiten, z. B. 8080, und nginx diesen Port überwachen lassen.

Die meisten Server (Apache, Nginx usw.) haben einen übergeordneten Prozess, dessen Eigentümer root ist, der dann Kopien von Arbeitsknoten mit einem Benutzer mit weniger Anmeldeinformationen abfragt. In diesem Fall ist es www-data.

Beispiel

Wenn Sie sich die nginxKonfigurationsdatei von anschauen /etc/nginx/nginx.conf, werden Sie folgende Zeilen bemerken:

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

Die meisten Server verfügen über ähnliche Optionen, die festlegen, welcher Benutzer die Slave-Knoten wie oft ausführen soll.

Sicherheit

Das Offenlegen von Diensten mit Root-Zugriff wird häufig als potenzielle Unsicherheit bezeichnet. Sie müssen jedoch häufig als Root angemeldet sein, um Verbindungen zu Ports zwischen 1 und 1024 herstellen zu können. Sie können also wirklich nichts tun, wenn ein Server beispielsweise die Ports 80 oder 443 abhören soll.

Auch wenn ein Dienst gut geschrieben und ordnungsgemäß konfiguriert ist, ist er für sich genommen nicht unbedingt schädlich für Ihre Sicherheitslage. Die Anwendungen, die auf Apache & Nginx ausgeführt werden, sind die eigentlichen Quellen für Pufferüberlauf- oder SQL Server-Injection-Angriffe, da die Anwendungen die Dienste sind, die die Einstiegspunkte für fehlerhafte Daten darstellen, die in Ihren Server-Stack injiziert werden sollen.

Apache & Nginx selbst akzeptieren im Allgemeinen keine Eingaben, die über die von ihnen akzeptierten GET / POST-Methoden hinausgehen.

So ist die Anwendung verpackt. Unter den meisten * nix-Betriebssystemen ist das Standardsetup ein nicht privilegierter Benutzer, der einen Port <1024 nicht überwachen kann und Webserver verwenden 80 und 443.

Linux 2.2+, Solaris 10+ und FreeBSD erlauben es Nicht-Root-Benutzern jedoch, auf Ports unter 1024 zu lauschen, nur nicht standardmäßig. Die meisten haben die Verwendung von akzeptiert, rootso bleibt es in Gebrauch.

Neben dem Zugriff auf den privilegierten Port müssen Sie sicherstellen, dass der Benutzer, auf dem nginx ausgeführt wird, Zugriff auf alle benötigten Dateien hat. Sie müssen wahrscheinlich nicht so weit gehen, sondern nur die richtigen Berechtigungen für Dateien / Verzeichnisse festlegen. Sie müssen auch sicherstellen, dass Startskripte keine hinterhältigen ulimitÄnderungen vornehmen (wie es bei MySQL immer der Fall ist).

Linux-Fähigkeiten

setcapund getcaplassen Sie die cap_net_bind_serviceFähigkeit für eine ausführbare Datei ändern oder anzeigen . Dies gilt für alle, die die Binärdatei ausführen.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux bietet die Möglichkeit, Funktionen auf Benutzerebene zu konfigurieren und zu steuern.

Freebsd Systemeinstellungen

Die reservierten Porteinstellungen gelten global für das System

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

Solaris-Berechtigungen

Solaris bietet eine differenzierte Steuerung der Berechtigungen auf Benutzerebene. Dies sind die Privilegien für Apache, aber sie funktionieren wahrscheinlich auch für Nginx.

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

Ich möchte allen anderen Antworten hinzufügen. Obwohl nginx als root gestartet wird, läuft es eigentlich nicht als root. Der Benutzer (nginx, www-data usw.), auf den er tatsächlich ausgeführt wird, ist normalerweise eine eingeschränkte / gesperrte Anmeldung (Sie können sich nicht damit anmelden, es kann nur auf bestimmte Dateien zugegriffen werden). Dies ist einer der Vorteile der Verwendung von Linux für Webserver im Gegensatz zu Windows. Dieser Vorgang wird als fork( weitere Details finden Sie in diesem Wikipedia-Artikel ) bezeichnet und verwendet setuidund / oder setgid( wird auch in einem Wikipedia-Artikel erläutert)), um den Benutzer und / oder die Gruppe zu ändern. In einem sicheren Setup kann ein Hacker nicht auf den übergeordneten Prozess zugreifen und das Root-Konto verwenden. Dies ist nicht immer der Fall, da ein Hacker eine Art Exploit verwenden könnte, um Root-Zugriff zu erhalten (es gab eine Sicherheitslücke in Nginx 1.4.0 und darunter, durch die Hacker Root-Zugriff erhalten konnten).