A desativação do login raiz aumenta a segurança?

Recentemente, encontrei um argumento contra a desativação de um login de usuário root no Linux em http://archives.neohapsis.com/archives/openbsd/2005-03/2878.html

Presumo que, se todo mundo usa uma autenticação de chave pública, não há risco de perder a senha root.

É sempre melhor desativar o login root via ssh?

A resposta curta é que quanto menor o seu perfil de ataque, melhor. Sempre. Se você não precisar dele ou pode usar uma alternativa como sudo ou su, não ative o login root.

Um grande argumento a favor da desativação do root e do uso do sudo / su é que você pode acompanhar quem está fazendo o quê. Um usuário - um login. Nunca compartilhe contas.

O argumento nesse link parece ser específico para o logon local, em vez de ssh.

Segundo ponto de Dennis, mais:

Permitir o login root via SSH também significa que o root é atacável por suposições de senha de força bruta.

Como a raiz está sempre lá e a recompensa é tão alta, é um alvo prioritário. O nome do usuário precisaria ser adivinhado primeiro, o que adiciona algumas ordens de magnitude à dificuldade do problema.

Nunca desative a conta raiz se você não tiver acesso ao console. Se o seu sistema de arquivos ficar cheio e a inicialização falhar enquanto o / etc / nologin é criado, somente a conta root poderá fazer login na máquina.

Dito isso, se você tiver acesso ao console para lidar com essas situações, o fechamento da conta raiz poderá poupar algumas dores de cabeça, pois ninguém poderá acessar a conta raiz usando um ataque de dicionário (minha experiência é que hoje em dia são constantes - alguém está sempre tentando). Outras coisas que você pode pensar em fazer:

• Instale um programa como o fail2ban que feche automaticamente o acesso a um endereço IP se ele falhar na autenticação várias vezes (para proteger ativamente contra ataques de dicionário).
• Use apenas as teclas ssh.
• Se você gerencia muitas máquinas, use cfengine ou outro para gerenciar as chaves públicas que você autoriza a inserir em uma máquina (ou então as desatualiza rapidamente).

Atenciosamente,
João Miguel Neves

É sempre melhor desativar o login raiz via SSH.

Existem sistemas PKI (por exemplo, chaves públicas com SSH) que foram comprometidos. O SSH já tinha falhas de autenticação remota anteriormente que permitiam que um comprometimento raiz ocorresse. As PKIs de software são notoriamente mais fracas que as PKIs baseadas em hardware .... Se o computador host estiver comprometido, o servidor de destino também poderá cair facilmente. Ou pode haver novas falhas encontradas no SSH. Ao limitar o login raiz, você também pode estender o período de tempo que um invasor precisa para executar a escalação de privilégios.

Historicamente, muitos administradores usavam hosts bastiões (basicamente gateways) para entrar em uma rede e depois pular para as caixas posteriormente. O uso de uma distribuição alta e segura (por exemplo, o OpenBSD) como host bastião, em conjunto com diferentes sistemas operacionais, oferece defesa em profundidade e defesa em diversidade (uma vulnerabilidade com menor probabilidade de comprometer toda a rede).

Considere também ter uma conexão fora de banda à sua rede, como um concentrador serial, comutador serial ou outro. Isso fornecerá disponibilidade de backup da sua interface administrativa, se necessário.

Como sou paranóico e em segurança, seria mais provável que eu usasse uma VPN IPSEC ou VPN Tipo 1 e depois executasse o SSH em cima dela, sem exposição à SSH na Internet. Colocar a VPN em seu hardware de rede pode simplificar drasticamente isso na implementação.

Deveríamos examinar esta questão de diferentes pontos.

O Ubuntu desabilita a conta root por padrão, o que significa que você não pode fazer login via SSH com root. Mas ele permite que qualquer pessoa com um CD do Ubuntu possa inicializar e obter acesso root.

Acredito que o melhor compromisso é ativar a conta raiz com acesso SSH desativado. Se você precisar de acesso root com SSH, efetue login com um usuário normal e use sudo. Dessa forma, protege o acesso à caixa, sem comprometer a segurança remota.

Eu diria que sim, o login como root deve ser desabilitado para auditabilidade. Se você é o único administrador do sistema nesta máquina, é trivial determinar quem fez o que com quem, mas se dez pessoas estão autorizadas a administrar a caixa e todas elas sabem a senha raiz, temos um problema.

Quer o root esteja ou não ativado, nem o root nem qualquer outro usuário devem ter permissão para efetuar login remotamente com uma senha. fail2ban não fará nada contra uma botnet de força bruta lenta e nem funciona com o IPv6. (a versão 1 do protocolo ssh e as implementações mais antigas da versão 2 estavam vulneráveis ​​a ataques de adivinhação de senha contra solicitações de senha interativas na sessão ssh, mas isso parece não ser mais o caso de uma implementação ssh suficientemente recente.)