Sshole mostra que configurar o SSH e esquecer dele é um mau hábito

Quando foi a última vez que você realmente pensou no seu daemon SSH? Se a resposta honesta é "quando instalei o servidor", você está no mesmo barco que a maior parte da internet, e um site direto ao ponto está aqui para cutucar você.

O site é o sshhole.com, também conhecido como sshole, e a mensagem cabe em uma linha: o OpenSSH em Linux com musl deixa entrar em contas sem senha desde 2016. É tudo o que temos. A página que vimos não tem data e não traz nenhuma explicação técnica, então não podemos descrever o mecanismo exato, confirmar a alegação nem dar uma nota de explorabilidade. Trate-a como uma acusação que merece ser levada a sério, não como fato comprovado.

O assustador não é a falha, é o "desde 2016"

Todo software tem bugs. O que faz essa alegação doer é o intervalo de tempo. O OpenSSH tem uma das melhores reputações do código aberto, e a própria página de segurança do projeto cita classes antigas de ataques a que ele nunca foi vulnerável. Essa reputação é merecida. E é também exatamente por isso que as pessoas param de olhar.

Confiança é uma forma de dívida técnica. Quando um componente é tedioso há anos, ninguém audita como ele está configurado, ninguém pergunta o que acontece numa libc incomum e ninguém o coloca num calendário de patches. Achamos que essa acomodação, mais do que qualquer bug isolado, é a verdadeira história. Uma conta sem senha é uma esquisitice menor em muitas máquinas, o tipo de coisa que se ignora. Combinada com um daemon que deixa você entrar mesmo assim (se a alegação se confirmar), deixa de ser esquisitice.

O SSH é um ponto único de falha, e fomos nós que o construímos assim

O SSH é a porta de entrada de servidores, contêineres, roteadores, máquinas de build e daquele Raspberry Pi esquecido num canto. Quando ele falha, não cai um aplicativo: cai aquilo que protege todo o resto. Normalizamos essa concentração de risco porque a ferramenta é boa, mas bom não é o mesmo que infalível.

Também não seria a primeira vez. O rastreador IsItPatched lista 50 CVEs conhecidas do OpenSSH, duas delas críticas (a página não tem data, então considere o número um retrato do momento). O BleepingComputer noticiou atualizações de segurança do OpenSSH que corrigiam uma falha de man-in-the-middle e outra de negação de serviço, sendo que uma delas foi introduzida há mais de uma década. Nossa leitura: código antigo esconde problemas antigos, e eles aparecem no tempo deles.

O que os administradores devem fazer

Primeiro, acompanhe os avisos de segurança da sua distribuição e aplique as atualizações do OpenSSH assim que saírem, principalmente se você usa musl em algum sistema. Não podemos dizer qual versão corrige o que o sshole denuncia, porque a documentação que analisamos não informa. Leia o aviso da sua distribuição em vez de supor que um único comando resolve.

Segundo, verifique se há contas com senhas vazias ou bloqueadas. Não conte com o daemon para recusá-las. Se a alegação do sshole se confirmar, essa rede de proteção é justamente o que falhou.

Terceiro, reduza a exposição. Coloque o SSH atrás de uma VPN ou de uma lista de endereços permitidos, não deixe a porta 22 aberta para o mundo e prefira logins com chave. Nada disso corrige um bug no daemon, mas transforma "qualquer pessoa na internet" em "alguém que já está dentro do seu perímetro", um problema bem melhor de se ter.

Por fim, a mudança cultural: coloque o OpenSSH no mesmo ritmo de atualização do seu navegador. Não estamos culpando os mantenedores. Um projeto tão central merece, na mesma medida, nossa gratidão e nossa atenção.

Nosso veredicto

Não entre em pânico, mas não ignore. Verifique suas contas sem senha, mantenha o OpenSSH atualizado e feche o SSH para o restante da internet sempre que puder. A lição do sshole não é que o OpenSSH seja ruim. É que as ferramentas em que mais confiamos são aquelas que paramos de vigiar.