Perché nginx avvia il processo come root?

Ho installato il server nginx. Ho appena controllato le porte di ascolto e ho visto quanto segue:

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

E mi interessa solo perché ci sono quattro processi nginx eseguiti come utente "www-data" e uno come "utente root"?

Il processo che hai notato è il processo principale, il processo che avvia tutti gli altri processi nginx. Questo processo viene avviato dallo script init che avvia nginx. Il motivo per cui questo processo è in esecuzione come root è semplicemente perché l'hai avviato come root! Puoi avviarlo come un altro utente, ma dovrai assicurarti che tutte le risorse necessarie a nginx siano disponibili per questo utente. In genere sarebbe / var / log / nginx e il file pid in / var / run /.

Più importante; Solo i processi di root possono ascoltare le porte inferiori a 1024. Un server Web in genere viene eseguito sulla porta 80 e / o 443. Ciò significa che deve essere avviato come root.

In conclusione, il processo principale eseguito da root è completamente normale e nella maggior parte dei casi è necessario per il normale funzionamento.

Modifica: l'esecuzione di qualsiasi cosa come root comporta un rischio di sicurezza implicito. Normalmente gli sviluppatori di questo tipo di software hanno molta conoscenza dei vettori di attacco e si preoccupano di eseguire il meno possibile il root. Alla fine devi semplicemente fidarti che il software è di buona qualità.

Se ti senti ancora a disagio, c'è un modo per eseguire nginx come un altro utente e usare ancora porte inferiori a 1024. Puoi usare iptables per reindirizzare tutto il traffico in ingresso sulla porta 80 su un'altra porta, ad esempio 8080, e avere nginx in ascolto su quella porta.

La maggior parte dei server (Apache, Nginx, ecc.) Hanno un processo genitore di proprietà di root che procede quindi all'invio di copie dei nodi di lavoro utilizzando un utente con meno credenziali. In questo caso lo è www-data.

Esempio

Se dai un'occhiata al nginxfile di configurazione, /etc/nginx/nginx.confnoterai linee come questa:

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

La maggior parte dei server ha opzioni simili a questa che stabiliscono quale utente deve eseguire i nodi slave e quanti di essi.

Sicurezza

I servizi esposti che hanno accesso come root sono spesso indicati come una potenziale insicurezza. Tuttavia, spesso devi essere root per collegarti alle porte che vanno da 1-1024, quindi non c'è davvero nulla che puoi fare se vuoi che un server ascolti su porte 80 o 443.

Inoltre, se un servizio è ben scritto e configurato correttamente, di per sé non è necessariamente dannoso per la tua posizione di sicurezza. Le applicazioni eseguite su Apache e Nginx sono in realtà le vere fonti di overflow del buffer o attacchi di iniezione del server SQL poiché le applicazioni sono i servizi che espongono i punti di ingresso per i dati non validi da iniettare nello stack del server.

Apache e Nginx da soli, generalmente non accettano alcun input oltre ai metodi GET / POST che accettano.

È il modo in cui l'applicazione è impacchettata. Sulla maggior parte * nix l'impostazione predefinita è un utente non privilegiato che non può ascoltare su una porta <1024 e i server Web utilizzano 80 e 443.

Linux 2.2+, Solaris 10+ e FreeBSD consentono comunque agli utenti non root di ascoltare su porte inferiori a 1024, ma non per impostazione predefinita. La maggior parte ha accettato l'uso di rootcosì rimane in uso.

Oltre all'accesso per il binding alla porta privilegiata, è necessario assicurarsi che l'utente che esegue nginx abbia accesso a tutti i file necessari. Probabilmente non è necessario spingersi fino a questo punto, ma è sufficiente impostare le autorizzazioni corrette per file / directory. Devi anche controllare che gli script di avvio non facciano nulla di subdolo come i ulimitcambiamenti (come sembra sempre mysql).

Funzionalità Linux

setcape getcapti consente di modificare o visualizzare la cap_net_bind_servicecapacità di un eseguibile. Questo sarà valido per chiunque esegua il binario.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux offre la possibilità di configurare e controllare le capacità a livello di utente.

Impostazioni di sistema di Freebsd

Le impostazioni della porta riservata sono globali per il sistema

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

Privilegi Solaris

Solaris offre un controllo accurato dei privilegi a livello di utente. Questi sono i privilegi di Apache ma probabilmente funzioneranno anche per nginx.

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

Vorrei aggiungere a tutti le risposte altrui. Sebbene nginx sia avviato come root, in realtà non è in esecuzione come root. L'utente (nginx, www-data, ecc.) Che sta effettivamente eseguendo come di solito è un accesso limitato / imprigionato (non è possibile accedere con esso, è possibile accedere solo a determinati file). Questo è uno dei vantaggi dell'utilizzo di Linux per server Web rispetto a Windows. Questo processo è chiamato a fork( puoi trovare maggiori dettagli in questo articolo di Wikipedia ) e usa setuide / o setgid( che è anche spiegato in un articolo di Wikipedia) per modificare l'utente e / o il gruppo. In una configurazione sicura, un hacker non sarebbe in grado di accedere al processo padre e utilizzare l'account di root. Ciò non è sempre vero in quanto un hacker potrebbe utilizzare un qualche tipo di exploit per ottenere l'accesso root (c'era una vulnerabilità in nginx 1.4.0 e precedenti che permetteva agli hacker di ottenere l'accesso root).