Devemos desabilitar o usuário root?

Question

Devemos remover a senha do root, desativar o login remoto e basicamente exigir que os administradores usem o sudo para realizar ações administrativas?

    

Answer 1

Todos os meus servidores têm a conta raiz desativada ( sp_pwdp definido como * ). Isso é requerer sudo para todos os acessos raiz. [1] O objetivo disso é ter todas as atividades do superusuário auditadas, para que as pessoas possam ver o que foi feito no sistema.

Para uma opção mais hardcore, você pode fazer sudo gravar em um arquivo de log (ao contrário de syslog ) e tornar o arquivo somente anexado (usando chattr no Linux ou chflags no BSD ). Desta forma, ninguém pode editar a auditoria depois.

[1] Eu também tenho uma política de não executar um shell de root ou fazer escapes de shell de um processo raiz. (Não há problema em usar sudo sh -c '...' para fazer pipelines ou redirecionamentos, no entanto.)

    

Answer 2

Eu enfaticamente recomendo contra a desativação do usuário root. Desabilite ou restrinja logins de root (via securetty e via sshd_config e via PAM e pelo que você tem) Se seu sistema permitir, limite os privilégios de root ou dividir a função raiz (semelhante a como RSBAC o faz.) Mas, por favor, por favor , não desative a conta root removendo a senha, caso contrário, será impossível efetuar login no sistema via sulogin . sulogin é usado por todos os initscripts que eu conheço no caso de erros graves relatados pelo fsck - e isso significa que você será bloqueado do sistema se o sistema de arquivos raiz for corrompido.

Para esclarecer: "Desativando a conta root, removendo a senha", quero dizer os vários mecanismos que acabam com um! ou * no campo de senha de / etc / shadow ou similar. Não quero dizer "altere o mecanismo de login raiz para que você não seja solicitado a fornecer uma senha".

    

Answer 3

Eu tenho a conta root ativada em todos os meus servidores. Todos os administradores têm seu próprio usuário e precisam fazer login por meio dele. De lá eles mudam para root. (root ssh está desabilitado)

Mantenha a contagem do administrador baixa. Somente as pessoas que realmente precisam de acesso root nesse servidor possuem a senha.

Eu não sou fã de sudo. É muito fácil fazer apenas 'sudo bash' para um shell de root. Estou ciente de que isso pode ser desativado, mas por que se incomodar? Apenas limite os usuários que podem executar tarefas do administrador e conversar entre si. Nós temos uma política para não permitir que os terminais raiz sejam abertos sem supervisão. Então é logar, su, fazer o trabalho, sair.

Nota: Eu trabalho em uma empresa relativamente pequena (funcionários de 50 e poucos anos) e nos locomovemos com apenas dois administradores de meio período (1 windows / 1 linux). Essa maneira de fazer as coisas pode não ser a melhor quando você tem ordens de magnitude a mais usuários. Eu pessoalmente ainda não usaria o sudo. Existem outras maneiras de registrar a atividade da raiz.

    

Answer 4

Desativar a senha do root é uma "boa ideia" falsa. No dia em que você precisar, você precisará realmente . (de acordo com a sua configuração, você pode precisar dele para entrar no modo de usuário único, por exemplo)

Desabilitar o login remoto root pode ser relevante, mas somente se você conseguir fazer logon localmente.

E sim, o sudo deve ser instalado em todos os seus servidores. É útil e fácil de configurar. Por que você gostaria de não usá-lo?

    

Answer 5

Eu apenas desabilito o acesso SSH para o root e exijo que os usuários (geralmente são apenas desenvolvedores) usem as chaves ssh. Há muitos ataques de dicionário e a alteração da porta SSH não é uma opção para nós.

Dessa forma, você não precisa confiar na capacidade de alguém escrever uma boa senha. Uma vez dentro, apenas os administradores têm permissões para o sudo.

    

Answer 6

Eu sei que esse segmento é realmente antigo, mas há algumas falhas importantes na lógica de artigos vinculados e estou me sentindo "rant'ie" - O sudo permite tanto listas de permissões quanto listas negras. Não apenas preto como eles especificam no artigo vinculado - Isso pula a ideia de AAA (Autenticação, Autorização e Auditoria) - su & o sudo permite autenticação e responsabilidade classificadas.

Cenário 1 Um administrador acidentalmente introduz algum código não autorizado em um sistema, logado como root, o código tem acesso completo e o administrador pode nunca saber o que aconteceu. Pelo menos com logins classificados (por exemplo, su / sudo) o administrador seria solicitado a autenticar se o código não autorizado tentasse usar direitos elevados ... Se ele não elevar, ele estará limitado aos direitos dos usuários, o que deve resultar em danos mínimos.

Cenário 2 Um administrador desonesto quer obter informações / fazer uma alteração. Eles se conectam ao console (acesso ao console físico, HP iLo / similar ou acesso ao console vGuest), fazem login como root e fazem o que quiserem. A menos que haja uma conta nomeada / cartão de acesso usado para obter acesso ao console, provavelmente não há muito de uma trilha de auditoria.

1. Certifique-se de que eles realmente sejam quem eles dizem ser. O roubo de identidade não é o problema, a verificação de identidade é.
2. Verifique sua autorização, apenas forneça o que eles precisam no momento. A autorização gradual permite que eles elevem quando precisam.
3. Audite tudo, tenha um registro para saber quem, o que, quando e onde. De preferência porque também

Answer 7

Você deve exigir que todos usem o sudo para cada comando root como uma política. Nunca há uma razão para executar "sudo bash" ou algo parecido, é apenas por conveniência, devido à ignorância, ou para cobrir os próprios rastros.

Se você desabilitar os logins diretamente na conta raiz, você prejudicará sua capacidade de corrigir o sistema quando houver problemas graves.

Se você não conseguir convencer seus administradores a fazer login como eles próprios e executar o sudo para cada comando executado como root, e para não sair dele em um shell, você terá sérios problemas para os quais não há solução técnica. / p>     

Answer 8

Os autores da distribuição segura Owl (e o designer Solar) têm um ponto de vista oposto cuidadosamente justificado; veja, por exemplo, a resposta link para uma apresentação das suas reivindicações. O problema de auditar as ações do superusuário (que a pessoa fez o quê) também é abordado em seu ponto de vista (basicamente, a solução é ter vários usuários root com nomes diferentes).