Por que o sshd permitiria logins de raiz por padrão?

Question

Atualmente estou trabalhando no fortalecimento de meus servidores contra o hacking, entre outras coisas, estou recebendo uma carga de tentativas para fazer logon como root no ssh. Embora eu tenha implementado o fail2ban, estou imaginando por que os logons de raiz seriam permitidos por padrão para começar? Mesmo com distros não baseadas no sudo, eu sempre consigo logar como um usuário normal e alternar - então eu estou imaginando se existe alguma vantagem clara em permitir logons do root no ssh, ou apenas algo que ninguém se incomoda em mudar?

    

Answer 1

There any clear advantage to allowing root logons on ssh

Existem alguns sistemas de backup que precisam de root no sistema remoto para realizar um backup. Não é incomum ver as configurações com a autenticação baseada em chave para executar tarefas de manutenção em sistemas remotos.

Eu desejo que o padrão seja alterado de PermitRootLogin yes para pelo menos PermitRootLogin without-password , isso permitiria apenas a autenticação baseada em chave. A autenticação remota de senha para a conta raiz quase nunca é necessária.

Está se tornando mais comum em sistemas (como o Ubuntu) para o sistema ser configurado com uma conta root com uma senha desativada. Não há muito risco na configuração padrão, pois não há como autenticar diretamente em uma conta com uma senha desativada.

Considere também que uma tentativa de força bruta de fazer login remotamente no root via ssh tem uma chance muito baixa de ser bem-sucedida se você tiver uma conta root com uma senha suficientemente complexa. Desabilitar a conta root fornece uma camada extra de segurança, mas pode não ser necessário se você tiver uma senha strong. Se você combinar uma senha strong com ferramentas reativas, como denyhosts e fail2ban, geralmente não há risco de que uma tentativa de força bruta force a senha do root funcione.

É sempre uma boa prática endurecer o sistema após a instalação ser feita com base no risco e na necessidade da sua rede. Um sistema que não é crítico e não tem dados de usuário, na verdade, não precisa do mesmo nível de endurecimento que o sistema que armazena registros médicos ou bancários.

    

Answer 2

Não tenho certeza, mas eu diria que eles queriam ter certeza de que as pessoas que estavam instalando no exterior pudessem fazer o login. O primeiro login pode precisar ser root, pois ainda não há outros usuários.

No entanto, você deve certificar-se de desativar o login como opção root na configuração do sshd depois de criar o seu usuário e conceder-lhe permissões sudo.

Também recomendo que você altere a porta SSH para algo diferente de 22. Embora não torne sua máquina mais segura, ela interrompe todas as solicitações desnecessárias / irritantes.

    

Answer 3

Considere evitar logins de raiz como uma proteção extra. Alguns anos atrás o bruteforce estava no auge, hoje em dia, eles tendem a procurar por vulnerabilidades através do que eles podem ver pelos deamons (apache, pureftpd, ...). Evitar logins root torna-se uma excelente ideia se amanhã for descoberta uma vulnerabilidade com o SSHD. Enquanto o SSHD é maduro e seguro, você nunca sabe. Ultimamente, as explorações têm sido mais voltadas para o escalonamento de privilégios com o kernel ou o uso de um aplicativo de terceiros com o kernel, impedindo assim que os logins de raiz não mudem nada.

A distro baseada no Debian já fez a mudança enquanto a distro baseada em RedHat a sugere (se você ler seus documentos de melhores práticas)

    

Answer 4

Bem, porque o root é um usuário válido e o sshd funciona permitindo isso. No OpenBSD (mesmo pessoal do OpenSSH), por exemplo, você não é solicitado a criar um usuário durante a instalação, então você precisa usar o root para acessar sua caixa.

Algumas distribuições baseadas em desktop obrigam você a criar usuários adicionais, mas para servidores você realmente não precisa de um.

Além disso, esses argumentos que sudo ou su são mais seguros do que fazer login como root são um grande mito. No Ubuntu, por exemplo, o usuário pode executar qualquer comando usando sudo por padrão, então qualquer invasor que entrar também pode executar qualquer comando como root. Bastante inútil do ponto de vista da segurança.

    

Answer 5

É praticamente específica da distribuição. Alguns permitem, outros não.

Se eu estivesse gerenciando uma distro, configuraria o sistema para ser o mais resistente possível na instalação. É melhor esquecer de ativar algum recurso do que esquecer de desativar algum recurso.