Por que remover o acesso ao Shell para o usuário do Apache / Nginx?

Question

É uma má ideia conceder acesso shell à conta do usuário destinada a executar o Apache / Nginx?

Eu pergunto porque, o Guvnr, em sua série bíblica VPS, configura um novo usuário com visudo

guvnr  ALL=(ALL) ALL

privilégios e, em seguida, configura um servidor Nginx com esse usuário.

Considerando que os autores do Nginx HTTP Server recomendam que você não conceda acesso ao shell ao usuário que está executando o Nginx.

Você sempre pode remover o acesso ao shell do guvnr, mas, então, como você administraria seus sites?

edit: @Bart Silverstrim - Veja como o guvnr instala o Nginx:

• (logado como usuário guvnr)
• sudo instala dependências nginx
• arquivos de origem do usuário wget nginx
• usuário ./configure --sbin-path = /usr/local/sbin --with-http_ssl_module
• usuário make
• sudo make install

Então, talvez o Nginx esteja sendo instalado para raiz aqui?

Esta é uma boa prática se o login root estiver desabilitado em / etc / ssh / sshd_config?

    

Answer 1

Geralmente, é uma má idéia dar acesso shell a qualquer conta criada apenas para que um daemon / serviço tenha acesso a funções específicas do sistema que não requerem acesso ao shell. Dessa forma, isso impedirá que alguém interrompa um serviço (voltado para a Internet) e ganhe mais privilégios do que o necessário.

Basicamente, por que aumentar sua superfície de ataque se você não precisa?

No flipside, ao reler a pergunta, não está claro se o nginx tem uma conta shell. O nginx foi configurado pela conta do guvnr ou recebeu uma conta real própria? Cada aplicativo é configurado por um usuário, geralmente com algum acesso administrativo. Isso não significa que ele está rodando como aquele usuário sempre (isto é, só porque o cat foi instalado pelo root não significa que o jdoe executando o cat está rodando o cat como root.) Somente se o nginx estivesse rodando com privilégios de conta do guvnr ou como guvnr ele tem acesso ao shell; ele pode muito bem estar descartando privilégios assim que ele forfega ou pode ter sua própria conta nginx ou ser executado como uma conta de usuário da web que tenha pouco ou nenhum privilégio. Você pode querer fazer mais escavações na configuração e ver exatamente como o servidor está rodando.

    

Answer 2

Por causa da segurança. Se o usuário não puder obter um shell interativo real, é uma coisa a menos para se preocupar ao proteger seu servidor.

Se o usuário pode usar sudo ou não, não tem nada a ver com o usuário poder abrir um shell.

    

Answer 3

Geralmente, você deseja conceder aos usuários privilégios mínimos necessários para realizar o trabalho. Os serviços não precisam de shell, então você geralmente não daria acesso shell a contas dedicadas a executar um daemon.

Especialmente, se um serviço acessível da rede for executado como um usuário específico, é recomendável não conceder acesso ao shell desse usuário. O raciocínio é que, se o serviço for comprometido, o invasor não terá acesso ao shell no sistema.

Se esse usuário tiver um acesso ao shell, o invasor terá potencialmente menos um obstáculo a superar para assumir o controle do sistema. Se esse usuário tiver privilégios equivalentes a root (via sudo ), se um invasor conseguir enganar o sistema para executar algum comando, ele poderá fazê-lo com root authority.

Embora ter um servidor da Web executado em um uid com acesso shell seja algo que você possa raciocinar, sua configuração está muito próxima de executar o serviço como root . Má idéia do IMO.

Como você administra? Seja "à mão" ou encontre uma ferramenta que não exija que você comprometa a segurança de seus sistemas.