Devemos desativar o usuário root?

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

Todos os meus servidores têm a conta raiz desativada ( sp_pwdpdefinida como *). Isso é necessário sudopara todo acesso root. [1] O objetivo disso é ter todas as atividades de superusuário auditadas, para que as pessoas possam ver o que foi feito no sistema.

Para uma opção mais explícita, você pode sudogravar em um arquivo de log (ao contrário de syslog) e torná-lo apenas como anexo (usando chattrno Linux ou chflagsno BSD). Dessa forma, ninguém pode editar a auditoria posteriormente.

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

Eu recomendo enfaticamente contra a desativação do usuário root. Desabilite ou restrinja logins raiz (via securetty e sshd_config e via PAM e via o que você possui) Se o seu sistema permitir, limite os privilégios de root ou divida a função raiz (semelhante à maneira como o RSBAC faz isso). Mas, por favor , faça não desabilite a conta root removendo a senha, caso contrário, será impossível fazer login no sistema via sulogin. suloginé usado por todos os initscripts que eu conheço em caso de erros graves relatados pelo fsck - e isso significa que você será bloqueado para fora 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 terminam com a! ou um * no campo de senha de / etc / shadow ou similar. Não quero dizer "altere o mecanismo de login raiz para não ser solicitada uma senha".

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 através dele. De lá, eles mudam para a raiz. (o ssh raiz está desativado)

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

Eu não sou fã de sudo. É muito fácil fazer 'sudo bash' para um shell raiz. Estou ciente de que isso pode ser desativado, mas por que se preocupar? Apenas limite os usuários que podem executar tarefas de administrador e conversar entre si. Nós temos uma política para não deixar os terminais raiz abrirem sem supervisão. Então é log in, su, faça o trabalho, logout.

Nota: Eu trabalho em uma empresa relativamente pequena (funcionários com 50 e poucos anos) e contamos com apenas 2 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 em mais usuários. Eu pessoalmente ainda não usaria o sudo. Existem outras maneiras de registrar a atividade raiz.

Desabilitar a senha do root é uma "boa idéia" falsa. No dia em que você precisar, você realmente precisará. (de acordo com a sua configuração, pode ser necessário fazer login no modo de usuário único, por exemplo)

Desativar o login remoto raiz pode ser relevante, mas apenas se você puder 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?

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

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

Eu sei que esse tópico é realmente antigo, mas existem algumas falhas importantes na lógica dos artigos vinculados e estou me sentindo "rant'ie" - o sudo permite a lista de permissões e a lista negra. Não apenas preto, como eles especificam no artigo vinculado - Isso ignora a idéia de AAA (Autenticação, Autorização e Auditoria) - su & sudo permite autenticação e prestação de contas graduadas.

Cenário 1 Um administrador introduz acidentalmente algum código não autorizado em um sistema, conectado 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 será solicitado a se autenticar se o código não autorizado tentar usar direitos elevados ... Se ele não elevar, ficará restrito aos direitos dos usuários, o que resultará em danos mínimos.

Cenário 2 Um administrador não autorizado deseja obter informações / fazer uma alteração. Eles se conectam ao console (acesso físico ao console, acesso ao console HP iLo / similar ou vGuest), efetuam login como root e fazem o que desejam. A menos que exista um cartão de acesso / conta nomeado usado para obter acesso ao console, provavelmente não há muita trilha de auditoria.

1. Certifique-se de que eles realmente são quem eles dizem que são. O roubo de identidade não é o problema, é a verificação de identidade.
2. Verifique sua autorização, apenas dê a eles o que eles precisam naquele momento. A autorização graduada permite elevar quando eles precisam.
3. Faça uma auditoria de tudo, tenha um registro para saber quem, fez o que, quando e onde. De preferência por que também

Você deve exigir que todos usem o sudo para todos os comandos raiz como uma política. Nunca há uma razão para executar o "sudo bash" ou algo semelhante, é apenas por conveniência, devido à ignorância ou para cobrir as faixas.

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

Se você não conseguir convencer seus administradores a fazer login como eles mesmos e executar o sudo para todos os comandos executados como root, e não quebrá-lo em um shell, você terá sérios problemas para os quais não há solução técnica.

Os autores da distribuição segura do Owl (e designer Solar) têm um ponto de vista cuidadosamente justificado oposto; consulte, por exemplo, a resposta /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 para uma apresentação de suas reivindicações. O problema de auditar as ações do superusuário (qual pessoa fez o que) também é abordado em seu ponto de vista (basicamente, a solução é ter vários usuários raiz com nomes diferentes).