Exploração de dia zero do servidor SSH - sugestões para nos proteger

13

De acordo com o Internet Storm Center , parece haver uma exploração de dia zero do SSH por aí.

Há alguma prova de código de conceito aqui e algumas referências:

Esse parece ser um problema sério, portanto, todo administrador de sistema Linux / Unix deve ter cuidado.

Como nos protegemos se esse problema não for corrigido no prazo? Ou como você lida com explorações de dia zero em geral?

* Vou postar minha sugestão nas respostas.

— sucuri
fonte

Quão real é isso? Um pouco de googletrolling apareceu seclists.org/fulldisclosure/2009/Jul/0028.html como a fonte mais original desse boato. Alguém tem verificação independente disso?

— chris

Muitos comentários bons sobre o Hacker News sobre esse problema: news.ycombinator.com/item?id=692036

— sucuri

6

Comentário de Damien Miller (desenvolvedor do OpenSSH): http://lwn.net/Articles/340483/

Em particular, passei algum tempo analisando um rastreamento de pacote que ele forneceu, mas parece consistir em simples ataques de força bruta.

Portanto, não sou persuadido de que existe um dia 0. A única evidência até agora são alguns rumores anônimos e transcrições de intrusões não verificáveis.

— x-way
fonte

Acho que podemos levar sua palavra para agora ...

— sucuri

11

Minha sugestão é bloquear o acesso SSH no firewall para todos os outros além do seu ip. No iptables:

/sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

— sucuri
fonte

5

De acordo com a publicação do SANS, essa exploração does not work against current versions of SSHe, portanto, não é realmente um dia útil. Patch seus servidores, e você deve ficar bem.

— Dentrasi
fonte

2

tecnicamente, é uma exploração de 0 dias (não publicada e desconhecida), mas que funciona apenas em versões mais antigas do SSH. No entanto, a versão padrão no RHEL, Fedora, é vulnerável (de acordo com o segundo post). Portanto, é um grande problema se não houver nenhum patch da sua distribuição (a menos que você use ssh a partir da fonte que não é comum) ...

— sucuri

1

Eles estão especulando isso com base nos logs de ataque. Ninguém sabe ao certo ... Mesmo a versão mais recente pode ser vulnerável

— sucuri

3

Reclame com seus fornecedores

Dessa forma, todos recebem a versão mais recente.

— Brad Gilbert
fonte

3

Para sua informação, a fonte original da história: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Há também duas histórias semelhantes (hackear astalavista.com e outro site): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Parece que alguém tem uma agenda: romeo.copyandpaste.info/ ("Mantenha 0 dias privados")

— x-way
fonte

Acordado. O grupo por trás dos logs originais que iniciaram isso tem uma declaração de missão para mexer com "o setor de segurança" - e que melhor maneira de fazer isso do que deixar todo mundo alvoroçado com "omg! Openssh 0day ?! como faço para parar / parar / hackear com isso? "

— CJI

Não seria a primeira vez que esses rumores e hype também eram falsos.

— 22811 Dan Carley

2

Eu compilo o SSH para usar tcprules e tenho um pequeno número de regras de permissão, negando todas as outras.

Isso também garante que as tentativas de senha sejam quase eliminadas e que, quando eu receber relatórios sobre tentativas de invasão, eu possa levá-las a sério.

— Ernie
fonte

2

Não executo ssh na porta 22. Como muitas vezes faço login em máquinas diferentes, não gosto de impedir o acesso via iptables .

Essa é uma boa proteção contra ataques de dia zero - o que certamente ocorrerá após a configuração padrão. É menos eficaz contra alguém que está tentando comprometer apenas meu servidor. Uma varredura de porta mostrará em qual porta estou executando o ssh, mas um script atacando portas SSH aleatórias ignorará meus hosts.

Para alterar sua porta, basta adicionar / modificar a porta no seu arquivo / etc / ssh / sshd_config .

— brianegge
fonte

A execução do SSH em uma porta não padrão parece reduzir a quantidade de ataques de força bruta a que está sujeita e provavelmente o protegerá da maioria dos worms. Não é uma defesa contra alguém digitalização manualmente coisas embora, e um verme podem no futuro apenas porto varredura de cada porta à procura de ssh (o que é fácil, basta demorado)

— MarkR

@ MarkR: Pode não parar um determinado 'cracker / kiddie / hacker', mas manterá os bots afastados até que uma correção seja lançada. Isso é imho mais importante.

— 9789 Andrioid

2

Eu firewall e esperaria. Meu instinto é uma das duas coisas:

A> Hoax. Pela pouca e falta de informação dada até agora, é isso ..

ou...

B> Esta é uma tentativa de "fumaça e engano", para causar preocupação acima de 4.3. Por quê? E se você, alguma organização hacker, encontrar uma exploração muito legal de dia zero no sshd 5.2.

Pena que apenas os lançamentos de ponta (Fedora) incorporam esta versão. Nenhuma entidade substancial usa isso na produção. Muitos usam RHEL / CentOS. Grandes alvos. É sabido que o RHEL / CentOS suporta todas as correções de segurança para manter algum tipo de controle básico de versão. As equipes por trás disso não devem ser espirradas. O RHEL postou (eu li, teria que desenterrar o link) que eles esgotaram todas as tentativas de encontrar qualquer falha no 4.3. Palavras a não serem tomadas de ânimo leve.

Então, voltando à ideia. Um hacker decide causar alguma agitação em torno de 4,3, causando histeria em massa de UG para 5,2p1. Eu pergunto: quantos de vocês já têm?

Para criar alguma "prova" para a direção incorreta, tudo o que "esse grupo" teria que fazer agora é assumir algum sistema anteriormente comprometido ( WHMCS ? SSH anterior?), Criar alguns logs com algumas meias-verdades (ataque-ee verificado "algo" aconteceu, mas algumas coisas não podem ser verificadas pelo alvo) esperando que alguém "morda". Basta uma entidade maior para fazer algo drástico (... HostGator ...) para torná-lo um pouco mais sério, em meio à crescente ansiedade e confusão.

Muitas entidades grandes podem ter backport, mas algumas podem apenas atualizar. Aqueles que atualizam, agora estão abertos ao ataque real de dia zero, sem divulgação até o momento.

Eu vi coisas mais estranhas acontecerem. Tipo, um monte de celebridades morrendo todas seguidas ...

— Peter Mortensen
fonte

0

Mudar para Telnet? :)

Brincadeiras à parte, se você tiver seu firewall configurado corretamente, ele já estará permitindo apenas o acesso SSH a alguns hosts. Então você está seguro.

Uma solução rápida pode ser instalar o SSH a partir da fonte (baixando-o do openssh.org), em vez de usar versões antigas que estão presentes nas distribuições mais recentes do Linux.

— sucuri
fonte

O telnet querberizado é realmente razoavelmente seguro. O bom do kerberos é que você pode revogar centralmente uma chave, se desejar, ao contrário do ssh, onde você deve visitar cada host e remover uma chave de cada arquivo autorizado_chave.

— chris