Por que o login root via SSH é tão ruim que todo mundo aconselha a desativá-lo?

83

Todos na Internet aconselham a desativar o login raiz via SSH , pois é uma prática ruim e uma brecha de segurança no sistema, mas ninguém explica por que isso acontece.

O que é tão perigoso na ativação do login root (especialmente no login com senha desativada)?

E qual é a diferença entre o nome de usuário do símbolo X e a senha do símbolo Y ou o nome de usuário raiz e a senha do símbolo X + Y do ponto de vista de segurança, caso a autenticação por senha seja permitida?

ssh security root

— pressa
fonte

2

Ter um usuário root na maioria dos sistemas é ruim por si só, deixe em branco permitindo um login SSH para esse usuário!

— Suman 11/07

1

O login raiz via ssh é necessário para ehealth-aussie.blogspot.com/2012/01/… . Tudo é um compromisso.

— Emory

2

Umm ... devemos mudar esta questão para a segurança? Como o tópico se inclina mais para a segurança, os sistemas * nix.

— Braiam 12/07/2013

1

Há um motivo administrativo para desativar a raiz. Em servidores comerciais, você sempre deseja controlar o acesso por pessoa. raiz nunca é uma pessoa. Mesmo se você permitir que alguns usuários tenham acesso root, você deve forçá-los a entrar através de seu próprio usuário e, em seguida, su -ou sudo -ipara que o login real pode ser gravado. Isso torna a revogação de todo acesso a um indivíduo muito mais simples, de modo que, mesmo que eles tenham a senha root, não possam fazer nada com ela.

— Philip Couling

62

Por que root sobre SSH é ruim

Existem muitos bots por aí que tentam fazer login no seu computador através do SSH. Esses bots funcionam da seguinte maneira.

Eles executam algo como ssh root@$IPe, em seguida, tentam senhas padrão como "root" ou "password123". Eles fazem isso o máximo que podem, até encontrar a senha correta. Em um servidor acessível em todo o mundo, você pode ver muitas entradas de log em seus arquivos de log. Eu posso subir até 20 por minuto ou mais.

Quando os invasores têm sorte (ou tempo suficiente) e encontram uma senha, eles têm acesso root e isso significa que você está com problemas.

Mas quando você não permite que o root efetue login no SSH, o bot precisa primeiro adivinhar um nome de usuário e depois a senha correspondente. Então, digamos que a lista de senhas plausíveis tenha Nentradas e a lista de usuários plausíveis seja Mgrande. O bot possui um conjunto de N*Mentradas a serem testadas, o que torna um pouco mais difícil para o bot em comparação com o caso raiz, onde ele é apenas um conjunto de tamanho N.

Algumas pessoas dirão que esse adicional Mnão é um ganho real em segurança e eu concordo que é apenas um pequeno aprimoramento de segurança. Mas penso nisso mais como esses pequenos cadeados que, por si só, não são seguros, mas impedem muitas pessoas de facilitar o acesso. Obviamente, isso só é válido se sua máquina não tiver outros nomes de usuário padrão, como tor ou apache.

A melhor razão para não permitir root é que o root pode causar muito mais danos à máquina do que um usuário padrão. Portanto, se por acaso encontrarem sua senha, todo o sistema será perdido enquanto com uma conta de usuário padrão, você só poderá manipular os arquivos desse usuário (o que ainda é muito ruim).

Nos comentários, foi mencionado que um usuário normal poderia ter o direito de usar sudoe, se a senha desse usuário for adivinhada, o sistema também estará totalmente perdido.

Em resumo, eu diria que não importa qual senha de usuário um invasor recebe. Quando eles adivinham uma senha, você não pode mais confiar no sistema. Um invasor pode usar os direitos desse usuário para executar comandos sudo, o invasor também pode explorar uma fraqueza no seu sistema e obter privilégios de root. Se um invasor tiver acesso ao seu sistema, você não poderá mais confiar nele.

É importante lembrar que todos os usuários do seu sistema que têm permissão para efetuar login via SSH são uma fraqueza adicional. Ao desativar o root, você remove uma fraqueza óbvia.

Por que senhas sobre SSH são ruins

O motivo para desativar as senhas é realmente simples.

Os usuários escolhem senhas ruins!

Toda a idéia de tentar senhas funciona apenas quando as senhas são possíveis de serem adivinhadas. Portanto, quando um usuário tem a senha "pw123", seu sistema fica inseguro. Outro problema com as senhas escolhidas pelas pessoas é que suas senhas nunca são verdadeiramente aleatórias, porque seria difícil lembrar.

Além disso, os usuários tendem a reutilizar suas senhas, usando-as para fazer login no Facebook ou em suas contas do Gmail e no seu servidor. Portanto, quando um hacker obtém a senha da conta do Facebook desse usuário, ele pode entrar no seu servidor. O usuário pode perdê-lo facilmente através de phishing ou o servidor do Facebook pode ser invadido.

Mas quando você usa um certificado para efetuar login, o usuário não escolhe sua senha. O certificado é baseado em uma sequência aleatória que é muito longa, de 1024 bits a 4096 bits (senha de ~ 128 - 512 caracteres). Além disso, este certificado existe apenas para efetuar login no servidor e não é usado com nenhum serviço externo.

Ligações

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

Este artigo vem dos comentários e eu queria dar uma posição um pouco mais proeminente, já que ele se aprofundou um pouco mais na questão de botnets que tentam efetuar login via SSH, como eles fazem isso, como os arquivos de log se parecem e o que se pode fazer para detê-los. Foi escrito por Peter Hansteen.

— Raphael Ahrens
fonte

10

Bom resumo. Mas as chaves privadas ssh também podem ser roubadas.

— Faheem Mitha

16

@ Faaem Mitha Sim, mas roubado é diferente de adivinhado, o que os bots fazem. Além disso, sua chave privada está apenas nas suas mãos (ou no disco rígido) e não nas mãos de terceiros, como o Stack Exchange ou o Google.

— Raphael Ahrens

2

+1. Esta resposta pode realmente se resumir a simplesmente N*M > N. Como a maioria dos hosts * nix possui um rootusuário, se você permitir que o root efetue login diretamente de um host remoto, o tamanho da matriz de teste é o número de senhas a serem tentadas; não permitindo logins raiz diretos, o número de combinações possíveis se multiplica pelo número de nomes de usuários que você deseja testar (e ainda não há garantia de que você estará testando nomes de usuário válidos!).

— um CVn

3

@ MichaelKjörling Gostaria de acrescentar que não é difícil obter o nome de usuário, pois normalmente o nome de usuário não é segredo e eu provavelmente poderia pedir a alguém para acessá-lo. Mas ajuda contra Bots e tentativas simples.

— Raphael Ahrens

2

@Todo mundo, se o nome de usuário tiver símbolos X e a senha Y, existem # of X length words* # of Y length wordscombinações possíveis para tentar. Quando o nome de usuário é fixo (por exemplo, root), mas a senha possui símbolos X + Y, existem # of X+Y length wordspossíveis senhas. E # of X+Y length words=# of X length words * # of Y length words

— skarap

10

Essas podem ser algumas das razões pelas quais o login raiz direto não deve ser permitido.

Tentativas do Bruteforce. O login raiz direto pode resultar em mais danos em um ataque de força bruta bem-sucedido.
Uma configuração incorreta nas chaves SSH "sem senha" (erro humano acontece) pode expor sua máquina à Internet

Mas isso é apenas a dica do iceberg. Você precisa definir outras restrições e configurações como:

Mude a porta padrão (22)
Senhas fortes e senha
Desativar autenticação baseada em host
Crie uma lista de usuários permitidos
Configurar tempo limite inativo
Forçar protocolo SSHv2
Desativar senhas vazias
Use fail2ban como uma medida contra força bruta
Registrar tudo
Configure Chaves SSH e confie apenas nas chaves públicas em .ssh / allowed_keys

5

"O login raiz direto pode resultar em mais danos em um ataque bem-sucedido de força bruta." Na verdade não, se comparado com uma sudoconfiguração padrão . O verdadeiro assassino é o efeito multiplicador quando você não tem um nome de usuário único com o qual possa contar como válido em qualquer host.

— a CVn

@ MichaelKjörling - Sim, com certeza que sudo confuso poderia ser tão harmfull como PermitRoot;)

Veja unix.stackexchange.com/a/2944/9454

— Restabelecer Monica - M. Schröder

1

Alterar a porta é realmente prejudicial em muitos cenários por si só. E não passa de segurança pela obscuridade também.

— 0xC0000022L

+1 por mencionar fail2ban, pois os ataques de força bruta não são apenas uma preocupação do SSH, mas de qualquer outra coisa na máquina. Você não precisa obter permissões de raiz ou do sistema para "assumir" uma máquina para fins práticos (acessar dados particulares, usar como despejo de arquivos, usar para phishing etc.).

— Eric Grange

8

Você está certo de que o nome de usuário raiz e a senha do símbolo X + Y são criptograficamente pelo menos tão seguros quanto um nome de usuário do símbolo X + senha do símbolo Y. Na verdade, é ainda mais seguro, porque os nomes das pessoas são fáceis de adivinhar (os bots podem apenas tentar john, mike, bill, etc ... e btw: é isso que muitos deles fazem em vez de tentar fazer root). E você está especialmente sem sorte se for um ataque direcionado, porque se alguém quiser quebrar o servidor de uma empresa, não seria um problema descobrir o nome (nick) do administrador de sistemas.

E assim que o invasor tiver acesso à conta que o sysadmin usa para logins ssh (e depois usa suou sudoexecuta suas tarefas), ele pode infectar a sessão desse usuário com um programa que enviará a senha root do invasor quando o sysadmin digitar o seguinte Tempo.

É qualquer tipo de logins raiz que são (ou deveriam ser) considerados más práticas do ponto de vista da segurança. O login do usuário "normal" -> su / sudo chain adiciona uma trilha de auditoria. Em inglês simples: permite descobrir quem fez o quê.

Um caso especial pode ser o caso em que apenas uma pessoa tem acesso root. Nesse caso, o uso do usuário "normal" adicional não agregará muito valor (pelo menos nunca pude ver esse valor). Mas de qualquer maneira - você deveria ter um usuário simples no sistema de qualquer maneira (para tarefas não administrativas, executando o wget, etc ;-)).

— skarap
fonte

4

O que é tão perigoso na ativação do login raiz (especialmente com o login com senha desativada)?

O invasor (bot / botnet / hacker) só precisa adivinhar a senha e tem controle total sobre o seu sistema, se você estiver aberto na Internet. Além disso, nenhuma das contas do sistema (www-data, proxy, etc.) deve poder efetuar login via SSH, pelos mesmos motivos.

Se você desativou o login de senha (usando chave pública, por exemplo), leve em consideração que quem se apossar da chave privada terá controle total sobre o seu sistema. Veja por que usar a chave pública com um usuário é melhor abaixo.

E qual é a diferença entre o nome de usuário do símbolo X e a senha do símbolo Y ou o nome de usuário raiz e a senha do símbolo X + Y do ponto de vista de segurança, caso a autenticação por senha seja permitida?

O nome de usuário extra pode adicionar uma camada de segurança, pois: a) o invasor deve saber o par, o nome de usuário e a senha; b) caso o invasor viole seu sistema, ele não terá acesso imediato a uma conta privilegiada, adicionando um pouco de nuance ao invasor.

Nesse caso, a chave pública também é uma vantagem, pois:

O invasor precisa da sua chave pública
O invasor precisa da senha (ou método de autenticação) para obter privilégios elevados

— Braiam
fonte

1

Muito poucas das senhas que utilizo têm menos de 20 caracteres alfanuméricos aleatórios (defina [A-Za-z0-9] mais alguns caracteres especiais). 20 desses caracteres (portanto, o comprimento 20 de um conjunto de caracteres de 40) fornece uma ordem de 10 ^ 32 combinações. 128 bits de entropia são da ordem de 10 ^ 38. Não é uma diferença enorme, considerando todas as coisas, e o servidor SSH é livre para implementar qualquer tipo de limitação de taxa de que gosta, por isso não é como se você estivesse fazendo um ataque offline de força bruta nesse caso. Não há nada errado com as senhas, se você pode conviver com elas sendo tão difíceis de lembrar quanto uma chave de 128 bits.

— um CVn

@michael shh ... não dê alcance, agora os hackers sabem que devem usar tabelas arco-íris da ordem de 20 caracteres de comprimento ...?

— Braiam 11/07/2013

6

As tabelas @Braiam Rainbow são úteis apenas se o invasor tiver acesso aos hashes para fazer uma pesquisa offline. No caso aqui, o invasor tem apenas a resposta do servidor para verificar, o que provavelmente está limitado a apenas tantas tentativas - e muito mais lento.

— Peter

@ Peter, eu estraguei tanto o dicionário quanto os hashes, mas, em qualquer caso, o OP perguntou por que ele não deveria usar senhas fracas ou vazias, o que é ridículo, por isso vim com situações ridículas porque ele não deveria. Lamento não ter sido interpretado dessa maneira e sido considerado FUD.

— Braiam 12/07/2013

2

Se você quiser experimentar algumas senhas de 1,8 * 10 ^ 35 (e isso é apenas para o intervalo de 18 a 22 caracteres aleatórios em um conjunto de 40, e você não sabe quais caracteres fora do conjunto [A-Za-z0- 9] Eu uso), eu quase disse, divirta-se. Isso equivale a 117,1 bits de equivalente a entropia (2 ^ 117,1 ~ 1,78 * 10 ^ 35) e, como @Peter apontou, você provavelmente precisará executar um ataque online . Armazenar todas essas senhas (sem recorrer à compactação) parece precisar de aproximadamente 3,6 * 10 ^ 36 bytes ou 3 * 10 ^ 24 TiB (e se esse número estiver errado por algumas ordens de magnitude, quem se importa? ). Palavra-chave aleatória .

— a CVn 12/07/2013

1

Não é exatamente ruim, desde que você tome precauções de segurança. Como exemplo, você pode instalar o CSF (Configure Server Firewall) e definir o número de tentativas de falha permitidas; portanto, se alguém tentar, digamos mais de 5 tentativas de falha ?, elas serão automaticamente bloqueadas. Portanto, toda a primeira parte do melhor respondedor não será um problema. Isso aconteceu comigo muitas vezes e, felizmente, todos os apresentadores foram bloqueados permanentemente. Eu acho que para um servidor não é um grande problema se você é a única pessoa que gerencia o servidor, mas é claro que se há muitos administradores de sistema ou se você está trabalhando em uma organização, obviamente não use raiz. Também para um PC de mesa, acho que usar outra conta é melhor, pois há um risco à segurança, pois você usa muito software, mas em um servidor, você não Não opte por softwares aleatórios nos quais não confia, mantenha-os o mais baixo possível. Portanto, a conclusão é: Não, não é realmente prejudicial se você souber gerenciar um servidor corretamente.

— Don Dilanga
fonte