OpenSSH no Alpine: verifique as contas e o processo após o patch
Usar chaves SSH exige conferir também os caminhos de autenticação que o servidor aceita. A falha SSHole torna necessário relacionar contas, configuração efetiva, pacote e processo em execução.
Read in EnglishNeste artigo
- Comece pelo serviço que realmente recebe conexões
- Verifique as condições por conta e por contexto
- Use a configuração efetiva para decidir a mudança
- Associe o pacote corrigido ao processo em execução
- Trate os indícios anteriores e as lacunas de cobertura
- Perguntas frequentes
- Leia também
- Fontes e referências
Por Pentesty
Comece pelo serviço que realmente recebe conexões
As notas do OpenSSH 10.6p2, publicado em 5 de novembro de 2026, descrevem uma proteção contra bypass de autenticação em determinados sistemas Linux com musl e PAM desabilitado. O registro CVE atribui gravidade alta e CVSS 8,1. Notícias publicadas em 7 de novembro motivaram esta análise, cuja data editorial é distinta da divulgação técnica.
A Previdian registra tentativas de exploração em seus sensores e explica que essas observações, isoladamente, não comprovam sucesso. Esse recorte orienta a priorização de serviços acessíveis. A empresa deve localizar seus próprios pontos de administração, responsáveis e horários de exposição antes de concluir o alcance de um possível incidente.
Verifique as condições por conta e por contexto
O advisory do Alpine exige condições combinadas. O servidor usa musl sem PAM, aceita autenticação por senha, tem uma conta elegível com o campo de senha representado por * e pelo menos outra conta local com hash $5$ ou $6$. Identifique também quem consegue alcançar o serviço. A simples presença de uma imagem Alpine no inventário requer essa apuração.
O Alpine informa que PermitRootLogin prohibit-password protege o login direto de root por esse caminho. O impacto depende da conta alcançável e de suas permissões, inclusive eventuais direitos por doas. Peça ao administrador que classifique localmente as condições relevantes e registre o resultado. O relatório pode guardar identificadores e conclusões sem transportar hashes de senha ou o conteúdo integral dos arquivos de contas.
Use a configuração efetiva para decidir a mudança
O manual do daemon sshd documenta a consulta da configuração efetiva com -T e a aplicação de regras Match com parâmetros de conexão em -C. Use a documentação correspondente ao pacote instalado e considere os usuários e caminhos administrativos representativos. Uma linha revisada no arquivo principal precisa ser relacionada ao contexto atendido pelo serviço.
Para ambientes que ainda aguardam atualização, o Alpine recomenda desabilitar PasswordAuthentication e reiniciar o daemon. Planeje a mudança com operações, confirme previamente um acesso legítimo por chave e mantenha uma forma aprovada de recuperação. Registre quem executa a alteração, a janela e o critério para verificar o resultado em uma nova conexão autorizada.
Associe o pacote corrigido ao processo em execução
A distribuição disponibiliza correções em ramos estáveis. Por exemplo, lista 10.3_p1-r2 para Alpine 3.24, 10.2_p1-r1 para 3.23 e 10.0_p1-r11 para 3.22. Compare o ramo e a revisão completa do pacote com a tabela oficial atual. Um número upstream isolado pode deixar de reconhecer um backport legítimo.
O Alpine exige reiniciar sshd após atualizar o pacote. Anexe evidências da versão instalada, da mudança do processo e da configuração resultante, além de um teste legítimo de administração acordado com o responsável. A validação de patches do kernel Linux apresenta outra situação em que a entrega do pacote precisa ser ligada ao componente efetivamente utilizado.
Trate os indícios anteriores e as lacunas de cobertura
O advisory orienta investigar entradas Accepted password for para contas que deveriam usar somente chaves, além de uso de doas e alterações em usuários, arquivos e chaves autorizadas. Se um login indevido não puder ser descartado, a orientação do Alpine é tratar a máquina como comprometida. Preserve registros disponíveis e encaminhe a investigação ao responsável por resposta a incidentes.
Feche a avaliação por ativo e conta, com origem da evidência, momento da coleta, decisão, responsável e pendências. Máquinas sem resposta continuam aguardando confirmação. Reaplique a verificação às imagens de implantação e às instâncias já existentes, quando estiverem no escopo. Uma correção aceita hoje precisa continuar sendo observável após mudanças de configuração ou substituição de imagens.
Separe a tentativa observada do resultado comprovado
Atualização editorial: 9 de novembro de 2026
Em relatório publicado em 8 de novembro de 2026, o SANS Internet Storm Center acrescentou uma amostra independente de tentativas contra SSH. Seus sensores Cowrie registraram 232 entradas com senhas longas em 5 de novembro e 713 no dia seguinte. Esses números descrevem requisições, não máquinas comprometidas ou atacantes únicos. O pesquisador identificou tentativas características de SSHole a partir do dia 5, mas apresentou o sucesso dos acessos como expectativa ainda sujeita a análise. Há outro limite importante: a coleta conserva apenas os primeiros 255 caracteres da senha, restringindo a interpretação de entradas maiores.
Para a empresa, essa limitação merece um campo na evidência de investigação. Identifique qual sensor produziu o evento, o período coberto, o que ele registra e onde ocorre truncamento. Relacione tentativas suspeitas às decisões de autenticação e às sessões que o servidor efetivamente registrou, respeitando a configuração e o alcance de cada fonte. Em um laboratório autorizado, use eventos sintéticos aprovados e valores fictícios para verificar se o caminho de coleta preserva horário, identidade de teste e resultado esperado. Registre se o comprimento está observado, inferido ou indisponível, sem guardar senhas reais. A aceitação deve separar pacote e daemon corrigidos, cobertura da telemetria e conclusão sobre acessos anteriores; uma lacuna em qualquer desses pontos continua explícita.
Relacione a observação do sensor ao resultado no servidor
Atualização editorial: 10 de novembro de 2026
A GreyNoise, no retrato atualizado em 10 de novembro de 2026 às 16h40 UTC, registrava 23 cadeias de pós-exploração em seus próprios pontos de observação vulneráveis. Sua definição exige execução de comandos pelo servidor SSH e agrupa sessões no mesmo ponto sem intervalo superior a 30 minutos. São observações dessa infraestrutura, não uma contagem de empresas comprometidas. A CISA adicionou CVE-2026-123158 ao KEV em 9 de novembro; o registro classifica como desconhecido o uso em campanhas de ransomware. A inclusão não cria, por si só, um prazo legal uniforme para todas as empresas.
Essa evidência é diferente de uma tentativa registrada ou de uma conexão à porta SSH. Na investigação autorizada do seu ambiente, relacione o identificador do ativo, a decisão de autenticação e a execução observada, quando disponíveis. Preserve a origem e o horário de cada registro e declare as lacunas, inclusive quando um sensor externo não demonstra o resultado no host. Em laboratório, eventos sintéticos aprovados podem conferir essa associação sem reproduzir o exploit nem usar credenciais reais. A avaliação de exposição anterior permanece separada do aceite do pacote corrigido e do daemon em execução.
Perguntas frequentes
Um contêiner Alpine está automaticamente exposto?
O Alpine exclui desse cenário contêineres que não executam sshd. Nos demais, verifique as condições de autenticação, contas e acesso ao serviço.
Uma versão inferior a 10.6p2 indica falha sem correção?
Confira o pacote completo e o ramo da distribuição. O Alpine publicou backports em versões com numeração upstream anterior.
O uso habitual de chaves basta para encerrar a avaliação?
Confira os métodos que o servidor efetivamente aceita para as contas e conexões avaliadas. O método escolhido pelo administrador em uma sessão não descreve todas as regras aplicáveis.
Quando a implantação pode ser aceita?
Quando o responsável demonstra o pacote ou a medida aplicável, o estado do daemon, a configuração efetiva e a continuidade do acesso legítimo, com as lacunas registradas.
Fontes e referências
- Cyber Security Brazil: referência editorial da notícia
- CySecurity, segunda referência editorial sobre o mesmo evento
- OpenSSH, notas oficiais da versão 10.6p2
- Alpine Linux, condições de exposição e pacotes corrigidos
- Programa CVE, registro da CVE-2026-123158
- Previdian, observações de tentativas e limites da telemetria
- OpenSSH, consulta da configuração efetiva do daemon
- Pesquisador, análise original e condições de autenticação
Análise original da Pentesty, publicada em 7 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.