Estou tentando entender os argumentos técnicos/implicações de segurança entre ssh'ing com root diretamente ou criar um usuário sudo auxiliar no contexto de manutenção de um servidor. Para esclarecer, estamos falando de servidores pertencentes a um único administrador. Para várias pessoas trabalhando na máquina, é óbvio que há o benefício da trilha de auditoria de ter usuários exclusivos para cada pessoa real e permissões refinadas.
Meu pensamento é, se esta é uma estação de desktop, faz sentido e é recomendado usar um usuário não root para coisas diárias, mas em um servidor, você geralmente faz login para mantê-lo e 99% das vezes todas as suas atividades exigem root permissões.
Portanto, há algum benefício de segurança na criação de um usuário "proxy" que você usará sudo para fazer o root de qualquer maneira, em vez de fornecer diretamente acesso ssh ao root?
O único benefício em que posso pensar é a segurança através da obscuridade, ou seja, os bots normalmente tentam sondar o usuário "root". Mas pelo que vejo, se um usuário de sudoers for comprometido, é o mesmo que comprometer o usuário root, então o jogo acabou.
Além disso, a maioria das estruturas de administração remota, sistemas NAS, hipervisores, incentivam o uso de um usuário root para login na web.
Uma coisa a considerar: se estiver usando chaves SSH para autenticação remota, o que acontece se a chave privada for comprometida?
Se root: o acesso root está comprometido. Espero que você não estivesse usando essa chave para acesso root em várias máquinas.
Se usuário: esse usuário está comprometido. No entanto , um invasor pode não conseguir executar o sudo, pois a senha do usuário não está comprometida. Ainda. (Supondo que uma senha seja necessária para usar o sudo)
Ainda uma situação ruim, mas possivelmente melhor. (Também um pouco melhor se você usar senhas para suas chaves SSH)
Os outros usuários já mencionaram pontos muito bons. Quero recapitular os que considero mais importantes...
... por que usar sudo
/etc/ssh/sshd_configou por meio do arquivo SUDOers . (não use outro editor que não sejavisudo!)Defaults targetpw- tanto na minha máquina desktop quanto nos meus servidores. Então, é preciso saber duas senhas diferentes para se tornar root)Para adicionar ao último ponto: eu pessoalmente uso usuários separados para cada tarefa em meus servidores (eu sou o único administrador): por exemplo, um usuário para backups. Ele tem acesso aos arquivos para backup e acesso ssh separado a um servidor externo. Eu tenho um usuário para monitoramento, que tem acesso muito limitado aos arquivos de log e à API de monitoramento. Só para citar alguns exemplos...
Mas para mim, pessoalmente, o ponto mais importante é que todos somos humanos. Você vai cometer erros. Ter que digitar
sudoantes de cada comando, isso pode mudar o comportamento do seu sistema, pelo menos adiciona uma barreira que o anima a pensar demais em seu comando.Então eu recomendo fortemente: use sudo em vez do usuário root
Do ponto de vista técnico: Existem duas maneiras comuns de usar o usuário root. Ou faça login diretamente via ssh como root, ou faça login via ssh e digite
sudo suousu -(...) como primeiro comando. Ambas as maneiras não me fariam sentir confortável.login raiz ssh
LoginGraceTimeeMaxAuthTriespara limitar os ataques do BruteForce.PermitRootLogin)su
sudoantes de cada comando, o que o torna mais propenso a errosPara todos os usos, sugiro fortemente que você não use root; mesmo para desativá-lo, se possível. Rotineiramente tenho o root desabilitado em servidores Linux/UNIX. O usuário root não pode ser protegido, suas ações não são registradas. No mínimo, um comando sudo será registrado, muito útil em caso de manuseio incorreto do administrador. Você também pode refinar as permissões dos usuários, dando apenas alguns privilégios. Claro que com o root desabilitado, nenhum log ssh usando root é possível.
Por experiência, o root é perdido apenas no caso de você precisar inicializar em usuário único ou inicialização de emergência; um cenário raro quando um servidor não pode inicializar corretamente. Mas se for esse o caso, você pode habilitá-lo, alterar sua senha e prosseguir com a recuperação.
Outro caso é para copiar arquivos usando sftp (ou ftp, que deve ser evitado, é claro, a menos que apenas em redes internas) onde você precisa copiar diretamente de/para diretórios apenas com permissões de root. Nesse cenário, você pode usar ACLs para conceder permissões a outro usuário e prosseguir.
Eu gostaria de contestar isso. Existem muitas tarefas de rotina que simplesmente procuram informações que qualquer usuário pode ver. "top", "ps", "df", olhando para logs, etc.
Adquira o hábito de executar apenas os comandos que precisam de root como root. E verifique três vezes esses comandos para que você não tenha digitado nada errado.
Se você executar tudo como root, você ficará desleixado. Acontece com todos.
Quando desleixado, você cometerá erros. Acontece com todos.
Não adquira esse hábito.
(Também concordo com o que vários outros disseram sobre ser o único administrador hoje não significa que você será o único administrador amanhã)
Consultor de segurança aqui.
A melhor prática em todos os aplicativos, sistemas, soluções, sistemas operacionais e qualquer outra coisa que você possa pensar é usar apenas a conta root para configurar as coisas e desativá-la.
De qualquer forma, crie uma conta de usuário individual com privilégios de administrador para gerenciamento diário, mas a conta root, seja ela qual for, deve ser desativada assim que a configuração estiver concluída.
A ofuscação de contas ainda não é uma má idéia, ou seja, não nomeie suas contas de administrador como admin, mas o valor real disso é incrivelmente baixo. A maioria dos "hacks" ocorre ao longo de semanas e meses, em vez de segundos e minutos, como a mídia/filmes/programas de TV gostam de apresentar e qualquer pessoa com a habilidade definida para "hackear", você também terá a habilidade para verificar coisas como o SID do administrador do Windows (é sempre S-1-5-32-544 para o administrador interno do Windows).
Para a maioria das empresas, uma grande preocupação de segurança é que você precisa de uma trilha de auditoria e responsabilidade pessoal.
As contas padrão (administrador) como a
rootconta são, por definição, não pessoais. Deixá-los abertos leva a (o equivalente a) a má prática de segurança de senhas compartilhadas e nenhuma responsabilidade pessoal/individual.Normalmente quando um colega sai da empresa você quer desabilitar a conta dele e sabe que bloqueia o acesso dele.
Você não quer que a saída deles exija a redefinição de senhas (e arquivos ~/.ssh/authorized_keys) de cada root e outras contas compartilhadas às quais os usuários (podem) tiveram acesso. Esse é o trabalho administrativo da PITA que frequentemente não acontece, então você precisa evitar que isso se torne um problema em primeiro lugar.
Portanto, mesmo em um departamento de TI de uma pessoa, configure uma conta pessoal para você como administrador, conceda a si mesmo
sudoprivilégios ou outras funções de administrador e não faça login diretamente como root ou qualquer conta padrão de superusuário/administrador disponível.Assim, quando sua empresa crescer e você se tornar um departamento de TI de duas pessoas ou sempre que sair, não deixará uma bagunça incerta de privilégios excessivos que precisam ser limpos.
Em um novo emprego, você não quer passar seus primeiros dias de trabalho limpando o “acesso da porta dos fundos” deixado por um antecessor, nem precisa, como o desistente, correr o risco de seu acesso que não foi rescindido causando segurança violações.
Como todas as questões de segurança, é uma questão de apetite ao risco. Como outros já afirmaram, fazer SSH como um usuário não root com uma chave e depois elevar para root significa que há um segundo fator em jogo (você TEM a chave, você SABE a senha), que pode limitar o raio de explosão de um comprometimento . Há o aspecto de auditoria também, que outros já mencionaram.
Se você está feliz por não ter essa camada extra de proteção (por menor que seja), faça o que quiser.
A maioria dos guias de segurança recomenda desabilitar o SSH root, principalmente porque isso força você a listar uma permissão de usuário para fazer algo. Há uma ação positiva necessária de você para conceder privilégios sudo a um usuário. Você pode controlar ainda mais quais ações esse usuário pode fazer, para que você possa ter usuários separados para tarefas separadas mesmo. Ou um usuário automatizado que pode executar certos comandos sudo, mas não outros.
De qualquer forma - muitos benchmarks de segurança recomendam desabilitar o SSH e até mesmo desabilitar o root do próprio console. Eu só faço isso sozinho se puder ter certeza do meu backup/reconstrução/infra-ferramenta imutável, caso contrário, não há como voltar ao servidor sem fazer alguns truques de inicialização do live-CD.
Se você estiver usando chaves ssh, geralmente é bastante seguro apenas ssh direto para o root, em vez de confundir os usuários "Proxy".
Esta é puramente uma questão de segurança versus conveniência.
Fazer login como root sempre será mais conveniente, mas significativamente menos seguro. Portanto, se você estiver de acordo com essas advertências, poderá fazer login como root.
No entanto, quanto maior for a sua empresa, mais a sério eles levarão a segurança.
Por exemplo, meu empregador atual é uma empresa com mais de 50.000 funcionários em 5 países. Obter o login ROOT é absolutamente impossível. E obter acesso SUDO também leva cerca de 2 semanas, com a aprovação dos níveis de Diretor.