Por que o sshd permite logins raiz por padrão?


7

Atualmente, estou trabalhando para proteger meus servidores contra hackers - entre outras coisas, estou recebendo várias tentativas para fazer logon como root no ssh. Enquanto eu implementei o fail2ban, eu me pergunto, por que logons de raiz seriam permitidos por padrão para começar? Mesmo com distros não baseados em sudo, eu sempre posso fazer logon como usuário normal e alternar - então, estou me perguntando se existe alguma vantagem clara em permitir logons raiz no ssh ou apenas algo que ninguém se incomoda em mudar?

Respostas:


8

Existe alguma vantagem clara em permitir logons raiz no ssh

Existem alguns sistemas de backup que precisam de raiz no sistema remoto para realmente executar um backup. Não é incomum ver coisas configuradas com autenticação baseada em chave para executar tarefas de manutenção em sistemas remotos.

Eu desejo fortemente que o padrão seja alterado de PermitRootLogin yespara pelo menos PermitRootLogin without-password, isso permitiria apenas autenticação baseada em chave. A autenticação remota de senha na 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 desabilitada. Não há muito risco na configuração padrão, pois não há como se autenticar diretamente em uma conta com uma senha desabilitada.

Considere também que uma tentativa bruta de efetuar login remotamente no root via ssh tem uma chance muito baixa de obter êxito 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ária se você tiver uma senha forte. Se você combinar uma senha forte com ferramentas reativas, como denyhosts e fail2ban, geralmente não haverá risco de que uma tentativa de força bruta a senha root funcione.

É sempre uma boa prática proteger o sistema após a instalação, com base no risco e nos requisitos da sua rede. Um sistema que não é crítico e não possui dados do usuário não precisa realmente do mesmo nível de proteção que o sistema que armazena registros médicos ou bancários.


2

Não tenho certeza, mas eu suporia que eles queriam garantir que as pessoas que fazem instalações estrangeiras pudessem entrar. O primeiro logon pode precisar ser root, pois ainda não há outros usuários.

No entanto, você deve desabilitar a opção de login como root na configuração do sshd depois de criar seu usuário e conceder a ele permissões de sudo.

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


Eu realmente discordo da mudança de portas padrão. Use filtragem de pacotes.
Warner

Mesmo? O que há de ruim nisso? Eu só comecei a fazê-lo porque eu vi respeitados administradores fazendo isso ...
Xeoncross

É algo que as pessoas adotaram na execução de servidores co-localizados sem filtragem ou segregação de rede.
Warner

@ Warner, mas, não entendo, mudar de portas padrão não seria uma maneira bastante simples para a maioria das pessoas se defender da maioria das tentativas?
Camilo Martin

2

Considere impedir logins raiz como uma proteção extra. Há alguns anos, o bruteforce estava no auge, hoje em dia, eles tendem a procurar vulnerabilidades através do que podem ver pelos daveons (apache, pureftpd, ...). Evitar logins raiz se tornará uma excelente idéia se amanhã for encontrada uma exploração com o SSHD. Enquanto o SSHD é maduro e seguro, você nunca sabe. Ultimamente, as explorações têm sido mais direcionadas à escalação de privilégios com o kernel ou ao uso de um aplicativo de terceiros com o kernel, para impedir que os logins raiz não tenham mudado nada.

A distribuição baseada no Debian já fez a troca, enquanto a distribuição baseada no RedHat o sugere (se você ler os documentos de práticas recomendadas)


1

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

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

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


por outro lado, um invasor precisaria adivinhar o nome de usuário e a senha - em vez de apenas forçar brutalmente a senha. Eu também nota sudo é restrita a pessoas no arquivo sudoers - por isso é apenas o primeiro usuário na maioria dos casos
Journeyman Geek

0

É basicamente uma distribuição específica. Alguns permitem, outros não.

Se eu estivesse gerenciando uma distribuição, configuraria o sistema para ser o mais rígido possível na instalação. É melhor esquecer de ativar alguns recursos do que esquecer de desativar algumas características.


O sistema de proteção, tanto quanto possível, se torna um desafio se você também está tentando usar o sistema na área de trabalho por muitos usuários finais. Você precisa comprometer e proteger o sistema apenas o suficiente para proteger os usuários no caso padrão, mas permitir que usuários avançados modifiquem o sistema para atender às suas necessidades.
precisa
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.