Dlaczego Nginx zaczyna proces jako root?

Zainstalowałem serwer Nginx. Właśnie sprawdziłem porty nasłuchiwania i zobaczyłem, co następuje:

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

I jestem tylko zainteresowany, dlaczego istnieją cztery procesy nginx uruchamiane jako użytkownik „www-data”, a jeden jako „użytkownik root”?

Proces, który zauważyłeś, jest procesem głównym, który rozpoczyna wszystkie inne procesy nginx. Proces ten rozpoczyna się od skryptu inicjującego, który uruchamia nginx. Powodem, dla którego ten proces działa jako root, jest po prostu to, że uruchomiłeś go jako root! Możesz uruchomić go jako inny użytkownik, ale musisz upewnić się, że wszystkie zasoby, których potrzebuje nginx, są dostępne dla tego użytkownika. Zwykle będzie to co najmniej / var / log / nginx i plik pid w katalogu / var / run /.

Najważniejsze; Tylko procesy root mogą nasłuchiwać portów poniżej 1024. Serwer WWW zazwyczaj działa na porcie 80 i / lub 443. Oznacza to, że należy go uruchomić jako root.

Podsumowując, proces główny uruchamiany przez root jest całkowicie normalny iw większości przypadków niezbędny do normalnego działania.

Edycja: Uruchamianie czegokolwiek, ponieważ root wiąże się z niejawnym zagrożeniem bezpieczeństwa. Zwykle programiści tego rodzaju oprogramowania mają dużą wiedzę na temat wektorów ataków i bardzo ostrożnie wykonują tak mało, jak to możliwe, jak root. W końcu musisz po prostu zaufać, że oprogramowanie jest dobrej jakości.

Jeśli nadal czujesz się nieswojo, istnieje sposób, aby uruchomić nginx jako inny użytkownik i nadal używać portów poniżej 1024. Możesz użyć iptables do przekierowania całego ruchu przychodzącego przez port 80 na inny port, na przykład 8080, i nginx nasłuchuje na tym porcie.

Większość serwerów (Apache, Nginx itp.) Ma proces nadrzędny, którego właścicielem jest root, który następnie forsuje kopie węzłów roboczych przy użyciu mniej wiarygodnego użytkownika. W tym przypadku jest www-data.

Przykład

Jeśli spojrzysz na nginxplik konfiguracyjny, /etc/nginx/nginx.confzauważysz takie wiersze:

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

Większość serwerów ma opcje podobne do tych, które określają, który użytkownik ma uruchamiać węzły podrzędne jako i ile z nich.

Bezpieczeństwo

Udostępnianie usług z dostępem do konta root jest często wymieniane jako potencjalna niepewność. Jednak często musisz być rootem, aby połączyć się z portami w zakresie od 1-1024, więc tak naprawdę nic nie możesz zrobić, jeśli chcesz, aby serwer nasłuchiwał na przykład na portach 80 lub 443.

Również, jeśli usługa jest dobrze napisana i odpowiednio skonfigurowana, sama w sobie niekoniecznie ma szkodliwy wpływ na twoją postawę bezpieczeństwa. Aplikacje działające na serwerach Apache i Nginx są naprawdę prawdziwymi źródłami przepełnienia bufora lub ataków polegających na wstrzykiwaniu serwera SQL, ponieważ aplikacje te ujawniają punkty wejścia dla zniekształconych danych, które mają zostać wstrzyknięte do stosu serwerów.

Apache i Nginx same w sobie zazwyczaj nie akceptują żadnych danych wejściowych poza metodami GET / POST, które akceptują.

Jest to sposób pakowania aplikacji. W większości * nix domyślną konfiguracją jest użytkownik nieuprzywilejowany, który nie może nasłuchiwać na porcie <1024, a serwery WWW używają 80 i 443.

Linux 2.2+, Solaris 10+ i FreeBSD pozwalają użytkownikom innym niż root słuchać na portach niższych niż 1024, ale domyślnie nie. Większość zaakceptowała użycie, rootwięc pozostaje w użyciu.

Oprócz dostępu do powiązania z uprzywilejowanym portem musisz upewnić się, że użytkownik uruchamiający nginx ma dostęp do wszystkich potrzebnych plików. Prawdopodobnie nie musisz iść tak daleko, ale po prostu ustaw prawidłowe uprawnienia do plików / katalogów. Musisz także sprawdzić, czy skrypty startowe nie robią niczego podstępnego jak ulimitzmiany (jak zawsze wydaje się, że mysql).

Możliwości systemu Linux

setcapi getcappozwala zmienić lub wyświetlić cap_net_bind_servicemożliwości pliku wykonywalnego. Będzie to obowiązywać dla każdego, kto wykonuje plik binarny.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux zapewnia możliwość konfigurowania i kontrolowania możliwości na poziomie użytkownika.

Ustawienia systemu Freebsd

Zarezerwowane ustawienia portów są globalne dla systemu

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

Uprawnienia Solaris

Solaris zapewnia precyzyjną kontrolę uprawnień na poziomie użytkownika. Są to przywileje związane z apache, ale prawdopodobnie będą działać również dla nginx.

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

Chciałbym dodać do wszystkich odpowiedzi. Chociaż nginx jest uruchamiany jako root, tak naprawdę nie działa jako root. Użytkownik (nginx, www-data itp.), Który faktycznie działa, jest zwykle logowaniem ograniczonym / w więzieniu (nie można się z nim zalogować, można uzyskać dostęp tylko do niektórych plików). Jest to jedna z zalet używania Linuksa do serwerów WWW w przeciwieństwie do Windows. Ten proces nazywa się fork( więcej szczegółów można znaleźć w tym artykule w Wikipedii ), a także wykorzystuje setuidi / lub setgid( co jest również wyjaśnione w artykule w Wikipedii), aby zmienić użytkownika i / lub grupę. W bezpiecznej konfiguracji haker nie miałby dostępu do procesu nadrzędnego i korzystania z konta root. Nie zawsze jest to prawdą, ponieważ haker może wykorzystać jakiś exploit w celu uzyskania dostępu do roota (istniała luka w Nginx 1.4.0 i poniżej, która pozwalała hakerom uzyskać dostęp do roota).