Por que o nginx inicia o processo como root?

Eu instalei o servidor nginx. Acabei de verificar as portas de escuta e vi o seguinte:

$ 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 só estou interessado em saber por que existem quatro processos nginx executados como usuário 'www-data' e um como 'usuário raiz'?

O processo que você notou é o processo mestre, o processo que inicia todos os outros processos nginx. Esse processo é iniciado pelo script init que inicia o nginx. A razão pela qual esse processo está sendo executado como root é simplesmente porque você o iniciou como root! Você pode iniciá-lo como outro usuário, mas precisará garantir que todos os recursos necessários ao nginx estejam disponíveis para esse usuário. Isso normalmente seria pelo menos / var / log / nginx e o arquivo pid em / var / run /.

Mais importante; Somente processos raiz podem escutar portas abaixo de 1024. Um servidor da Web geralmente é executado na porta 80 e / ou 443. Isso significa que precisa ser iniciado como raiz.

Em conclusão, o processo mestre sendo executado pela raiz é completamente normal e, na maioria dos casos, necessário para a operação normal.

Editar: Executar qualquer coisa como raiz acarreta um risco implícito de segurança. Normalmente, os desenvolvedores desse tipo de software têm muito conhecimento sobre vetores de ataque e tomam muito cuidado para executar o mínimo possível de raiz. No final, você simplesmente precisa confiar que o software é de boa qualidade.

Se você ainda se sentir desconfortável, existe uma maneira de executar o nginx como outro usuário e ainda usar portas abaixo de 1024. Você pode usar o iptables para redirecionar todo o tráfego de entrada na porta 80 para outra porta, por exemplo 8080, e fazer com que o nginx escute essa porta.

A maioria dos servidores (Apache, Nginx, etc.) possui um processo pai de propriedade do root, que então cria cópias dos nós dos trabalhadores usando um usuário menos credenciado. Nesse caso é www-data.

Exemplo

Se você der uma olhada no nginxarquivo de configuração, /etc/nginx/nginx.confnotará linhas como esta:

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

A maioria dos servidores possui opções semelhantes a esta, que estipulam qual usuário executar os nós escravos e quantos deles.

Segurança

A exposição de serviços que têm acesso root é frequentemente mencionada como uma potencial insegurança. No entanto, muitas vezes você precisa ser root para conectar-se a portas que variam de 1 a 1024; portanto, não há nada que você possa fazer se quiser que um servidor esteja ouvindo, como as portas 80 ou 443.

Além disso, se um serviço é bem escrito e configurado adequadamente, por si só não é necessariamente prejudicial à sua postura de segurança. Os aplicativos executados sobre o Apache & Nginx são realmente as verdadeiras fontes de estouro de buffer ou ataques de injeção do SQL Server, pois os aplicativos são os serviços que estão expondo os pontos de entrada para que dados malformados sejam injetados na pilha do servidor.

O Apache e o Nginx, por si só, geralmente não aceitam nenhuma entrada além dos métodos GET / POST que eles aceitam.

É a maneira como o aplicativo é empacotado. Na maioria dos * nix, a configuração padrão é que um usuário não privilegiado não pode escutar em uma porta <1024 e os servidores da Web usam 80 e 443.

No entanto, o Linux 2.2+, o Solaris 10+ e o FreeBSD permitem que usuários não-root escutem em portas inferiores a 1024, mas não por padrão. A maioria aceitou o uso, rootpor isso permanece em uso.

Além do acesso à ligação à porta privilegiada, você precisa garantir que o usuário que está executando o nginx tenha acesso a todos os arquivos necessários. Você provavelmente não precisa ir tão longe quanto isso, mas apenas defina a permissão correta nos arquivos / diretórios. Você também precisa verificar se os scripts de inicialização não fazem nada sorrateiro como ulimitmudanças (como o mysql sempre parece).

Recursos do Linux

setcape getcappermite alterar ou exibir a cap_net_bind_servicecapacidade de um executável. Isso será válido para quem executar o binário.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

O SELinux fornece a capacidade de configurar e controlar recursos no nível do usuário.

Configurações do sistema Freebsd

As configurações de porta reservada são globais para o sistema

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

Privilégios do Solaris

O Solaris fornece controle refinado de privilégios no nível do usuário. Esses são os privilégios do apache, mas provavelmente também funcionarão para o nginx.

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

Eu gostaria de adicionar às respostas de todos os outros. Embora o nginx seja iniciado como raiz, na verdade não está sendo executado como raiz. O usuário (nginx, www-data, etc) que ele está realmente executando como geralmente é um login restrito / preso (você não pode fazer login com ele, apenas determinados arquivos podem ser acessados). Este é um dos profissionais do uso do Linux para servidores da web, em oposição ao Windows. Esse processo é chamado de fork( você pode encontrar mais detalhes neste artigo da Wikipedia ) e também usa setuide / ou setgid(o que também é explicado em um artigo da Wikipedia)) para alterar o usuário e / ou grupo. Em uma configuração segura, um hacker não poderá acessar o processo pai e utilizar a conta raiz. Isso nem sempre é verdade, pois um hacker pode utilizar algum tipo de exploração para obter acesso root (havia uma vulnerabilidade no nginx 1.4.0 e abaixo da qual os hackers podiam obter acesso root).