Que usuários devem ter acesso ao sudo? (nó, php, ftp…)

Question

Antes de começar, sinta-se à vontade para sugerir um título melhor para essa pergunta.

Inscrevi-me na Digitalocean e instalei uma pilha LEMP. Esta é a primeira vez que configuro um servidor do zero. Mesmo que eu tenha escolhido a opção LEMP, também quero hospedar aplicativos de nós.

A minha principal preocupação é, não tenho certeza do que os usuários devem criar, e quais deles devem ter privilégios de administrador. Além disso, quero confiar nas chaves SSH sempre que for possível.

• Para upload / download de arquivos, estou usando o Filezilla. Quando instalei a pilha LEMP, perguntaram se eu queria gerar uma senha para root ou usar chaves SSH. Eu escolhi a última opção. No momento, posso ssh [email protected] e usar minha senha SSH. O ProFTPd instalado e o habilitaram o SFTP . /etc/proftpd/authorized_keys/root contém as chaves SSH que eu uso para conectar via ssh ou Filezilla ao servidor. Nem ssh nem Filezilla solicitam a senha de root .

  Como sou o único que acessa via SFTP, acho que posso me safar com esse método. Se eu precisar de outra pessoa, criarei um usuário para ele, associe suas chaves SSH e conceda a ele acesso a determinadas pastas.

  Isso não está me causando problemas, mas imaginei que deveria mencioná-lo e ver se alguém acredita que essa é uma prática ruim.

• Eu quero poder executar aplicativos do Node. Como root , instalei node, npm e pm2 para manter meus apps vivos a qualquer momento. Todos esses são encontrados em /usr/local/bin de root:root . Eu criei um usuário chamado www e como eu armazeno meus aplicativos em /var/www , chown -R www:www /var/www . Eu realmente preciso criar www ou eu poderia usar www-data , que é o que o Nginx usa?

  Até agora, eu realmente não preciso adicionar www aos sudoers, até que eu queira usar pm2 startup e npm install :

  • PM2 requer pm2 startup (que gera os scripts para executar o PM2 após cada sistema boot) para ser usado pelo usuário que vai executar pm2 start (que inicia o aplicativo do nó e o monitora). Isso só precisa ser feito uma vez. Ele fornece um comando que precisa ser executado com sudo . Então usermod -aG www sudo e execute o comando. Tudo bem.

  • npm install também requer sudo . A coisa sobre isso é que, eu não quero ser solicitado uma senha . Eu estou tentando usar um gancho pós-recebimento Git, então sempre que eu empurrar para o servidor eu quero que isso seja executado ( /var/repo/nodeapp.git/hooks/post-receive ):

    #!/bin/sh
    git --work-tree=/var/www/nodeapp --git-dir=/var/repo/nodeapp.git checkout -f && cd /var/www/nodeapp && sudo npm install
    

    Se eu git push do meu terminal, eu não teria um problema em receber uma senha quando tentar sudo npm install , mas às vezes eu uso o Github para Windows / Mac e não há como eu fornecer essa senha. Deixe-me observar que, eu configuraria as chaves SSH para se conectar como www via terminal ou aplicativo Github.

  Primeiro, pensei em definir www user como proprietário de npm e pm2 , porque achei que não seria necessário executar o comando com sudo . Eu estava errado (espero que você não esteja rindo). Em seguida, pensei, como www é um sudoer, eu poderia disponibilizar alguns comandos para serem usados com o sudo. Então, eu visudo 'd e eu tenho isso no meio do arquivo:

  # User privilege specification
  root    ALL=(ALL:ALL) ALL
  www     ALL=(ALL:ALL) NOPASSWD:/usr/local/bin/npm
  

  O que estou tentando alcançar é "deixar o usuário www usar sudo npm install sem receber uma senha". Esse é o caminho a percorrer? Existe uma maneira de dizer "não deixe este usuário usar o sudo com qualquer outro comando, mesmo que ele forneça a senha correta". Digamos que eu possua sudo rm file.txt as www e arquivo.txt seja de outro usuário: posso desabilitar isso? Eu só quero que www (ou qualquer outro usuário que eu crie) consiga usar o sudo com npm .

  Até agora, não funciona para mim. Além disso, existe uma maneira de alcançar tudo isso sem adicionar www aos sudoers?

• Tanto quanto eu entendo, não devo deixar o usuário root conectar-se por meio de ssh . Isso é uma coisa vital? O Digitalocean não fornece nenhuma interface gráfica para configurar o servidor, então ssh ing como root é a minha única maneira de configurar coisas como as configurações do Nginx.

• O Nginx é executado por root para que possa ouvir a porta 80, mas depois serve os sites como outro usuário ( www-data , acredito). Devo configurar algo aqui? Eu não sei nada sobre esse usuário: permissões, senha, chaves autorizadas .. Devo definir user www; em /etc/nginx/nginx.conf ?

  O que acontece quando eu configuro um site usando PHP e um visitante acessa o site? Qual usuário está realmente executando as coisas, www-data por padrão?

• Devo ter um usuário para meus sites PHP e outro responsável por executar coisas como node index.js ?

• Se eu definir AllowUsers someusername anotherusername em /etc/ssh/sshd_config , isso se aplica apenas ao tentar acessar via o comando ssh ou também quando estou tentando enviar alterações usando o Github para Windows / Mac? / p>

• Se eu definir PasswordAuthentication no em /etc/ssh/sshd_config , qual senha devo introduzir quando solicitado por um comando com sudo?

Answer 1

Apenas as contas interativas nas quais você pretende fazer login devem ter direitos sudo ou root. O número de cenários em que um serviço poderia justificadamente ter privilégios sudo ou root é extremamente limitado: backups, antivírus, prevenção contra invasões de host.

Não recomendo usar sudoers para conceder direitos de administrador restritos às contas de serviço. É muito difícil conter o conjunto de ações permitidas. Sudoers funciona bem com colegas razoavelmente sensatos que não querem prejudicar intencionalmente o seu sistema. Um servidor da Web comprometido não é um detentor competente de tais privilégios e você deseja limitar os danos que podem causar.

O risco de segurança de permitir a instalação do root npm é bastante significativo. A instalação do npm não requer direitos de root. Dito isso, permitir que seu aplicativo da web se auto-modifique em resposta a solicitações de usuários é bastante arriscado, a menos que seja feito com muito cuidado.

Se você quiser atualizar seu aplicativo da Web, use um trabalho ou serviço cron separado que faça isso e, em seguida, reconfigure e reinicie o Apache. Esse serviço pode ter os direitos de executar git e npm install e isso deve ser limitado ao npm install em nível de usuário, em vez de ao nível do sistema. É muito provável que privilégios suficientes sejam apenas do sistema de arquivos e possam ser limitados às pastas do aplicativo, de modo que o usuário do atualizador possa alterar as coisas, enquanto o www-data não pode.

As coisas mais vitais para fazer quando o harding nginx está desabilitando os módulos que você não está usando e fazendo com que os server_tokens mostrem informações de versão menos detalhadas. Muito mais endurecimento de nginx é possível dependendo da sensibilidade do sistema ou serviço.

Não permita o login root por SSH. Entre na sua instância como seu usuário não-root e use sudo para executar comandos ou sudo su -l para se tornar root e fazer isso.

Você deve ter usuários e privilégios separados para coisas separadas? Idealmente sim. Quanto mais compartimentalização de componentes você puder ter praticamente dessa maneira, mais seguro ficará seu sistema. Também torna mais fácil adicionar ou remover permissões, porque cada usuário tem uma função definida de maneira muito restrita no sistema com acesso a privilégios mínimos.