Por que o SSH tem padrões inseguros?

Question

Por que o SSH vem com uma configuração padrão tão insegura?

para nomear o que considero padrões inseguros:

• login raiz ativado no SSH
• versão 1 do protocolo SSH (vulnerável a ataques MIM) permitida

Também não há mecanismo embutido para lidar com forceat brute

Eu posso entender que interoperabilidade e compatibilidade são importantes para um novo sistema, mas colocar um servidor na web com esses padrões é uma grande preocupação de segurança. Se alguém não soubesse sobre essas opções de configuração, eles poderiam colocar um servidor ativo que é muito vulnerável a ser brutalidade e ignorar o problema por tempo suficiente para que alguém ganhasse acesso.

A ideia de bruteforcing root no SSH existe há muito tempo, e há sempre um 'ruído de fundo' nas tentativas de login do root em qualquer servidor de bots e afins. Faz sentido enviar o SSH com alguns padrões que ajudariam a mitigar essa ameaça.

Qual é o motivo desses padrões inseguros?

    

Answer 1

Em muitos sistemas, seu único ponto de entrada no sistema é via ssh. Em uma nova instalação sem ter criado uma conta de usuário, a única conta que você pode ter é root.
Então, mesmo se você tiver várias contas, e se você estiver usando autenticação externa, e seu sistema de autenticação falhar. Você precisa poder voltar à caixa e corrigi-la.

Você pode definir PermitRootLogin para without-password para que somente as chaves ssh funcionem, mas para isso você precisa fazer o login pelo menos uma vez com uma senha para adicionar a chave ssh.

Além de por que isso pode ser necessário inicialmente, eu diria que é dever do mantenedor de pacotes tornar os padrões razoavelmente seguros, mas ainda assim funcionais. Tornar o mais seguro possível seria como desativar o root, fazer com que ele ouça em uma porta diferente de 22, desabilitar a autenticação de senha, etc. Deixar o root ssh com a senha ativada não é uma falha de segurança por si só. É apenas uma falha de segurança se o root tiver uma senha fraca.
Eu compararia isso a uma política de firewall. A maioria das distribuições é enviada sem nenhuma regra de iptables ativada ou personalização sysctl. Colocar um servidor na internet sem customização dos dois é um risco significativo. Cabe ao proprietário do servidor implementar uma política de segurança que atenda à finalidade do servidor.

    

Answer 2

Sua distribuição é a causa mais provável para esses valores padrão inseguros. Diferentes distribuições enviam configurações padrão diferentes.

Por outro lado, pode ser uma má idéia iniciar um serviço de rede sem configuração prévia. Os administradores tendem a ter suas necessidades especiais e, pelo menos, analisam a configuração após a instalação, se não estiverem enviando seus próprios scripts.

Ataques de força bruta: Existem outros meios para detectar esses ataques. Tais como ipsets e firewalls ou até mesmo sistemas de detecção de intrusão. Não é necessário que o ssh invente sua própria solução.

    

Answer 3

O SSH não possui padrões inseguros (pelo menos não aqueles que você mencionou).

O protocolo 1 foi desativado por padrão desde o OpenBSD 4.7 (lançado em 2010). Mesmo quando o Protocolo 1 ainda estava habilitado por padrão, ele só seria usado se o cliente o solicitasse, e o cliente (como eu acho que todos os clientes que suportam a versão 2 do protocolo) usa a versão 2 do protocolo, a menos que o servidor não o suporte ou o usuário solicitou explicitamente a versão 1 (e desde o OpenBSD 4.7, o cliente OpenSSH não retorna à versão 1 do protocolo explicitamente).

Permitir login root do SSH não é uma preocupação de segurança. Se permitir um caminho de ataque, significa que o administrador do servidor fez um trabalho ruim. Não escolha uma senha de root adivinhada! A desativação dos logins raiz está fortalecendo - é a segurança em profundidade. Aumenta a segurança, adicionando uma camada de proteção, caso o usuário cometa um erro. É uma coisa boa, mas não é necessária.

Se você não escolher senhas estupidamente adivinhadas, a única ameaça que as tentativas de login incessantes representam é preencher sua partição de log.

Acelerar a taxa de tentativas de login é uma faca de dois gumes. Por um lado, reduz o risco de os invasores adivinharem uma senha simples demais e reduz a largura de banda que consomem. Por outro lado, se você precisar fazer login no seu servidor da mesma rede que um invasor e tiver colocado limites rigorosos, você terá DoS'ed por conta própria.

¹ _{Não apenas tentativas de login root , a propósito. Também nomes comuns e nomes de contas comuns do sistema, como admin , webmaster , etc.}