Protegendo seu Linux de ataques de brute force via ssh

[dt.Sl4cK*]

Um dos grandes problemas para administradores é a segurança, e para ser alvo de grandes redes de ataques via brute force basta você ter um servidor com ip válido para internet rodando o daemon do ssh na porta padrão. Em diversos casos somos obrigados a deixar esta porta aberta e então eis a solução para este tipo de problema, de forma simples e eficiente utilizando o sshguard.

[ Hits: 26.337 ]

Por: Elizandro Pacheco de Almeida em 15/01/2008 | Blog: http://www.pachecotecnologia.net

0 0

Denuncie Favoritos Indicar Impressora

Configuração e a hora do show!

Para que o sshguard funcione, vamos criar um chain no firewall com o seguinte comando:

# iptables -N sshguard

E então vamos dizer agora ao firewall que toda conexão com destino a porta 22 (porta padrão do ssh) deverá passar por esta chain que acabamos de criar. Faremos isso com o comando:

# iptables -A INPUT -p tcp --dport 22 -j sshguard

Prontinho, vamos botar tudo pra funcionar.

Rode o seguinte comando:

# tail -f /var/log/messages | /usr/local/sbin/sshguard &

E agora de outra máquina, faça tentativas de acesso via ssh errando a senha propositalmente. É bom que você faça diversas tentativas consecutivas (no mínimo 4 a cada 5 segundos).

Você será bloqueado pelo sshguard.

Caso queira acompanhar o andamento, você pode fazer isso com o comando:

# tail -f /var/log/messages | grep sshguard

Você verá uma linha semelhante a essa quando o sshguard lhe bloquear:

Jan 4 13:33:24 sentinela sshguard[5583]: Blocking 10.1.1.2: 4 failures over 4 seconds.

Se apareceu esta linha, parabéns! Seu sistema está seguro.

Recomendo adicionar os comandos desta página dentro do seu firewall ou se não possuir um, você pode colocar dentro do arquivo /etc/rc.d/rc.local.

OBS: Existem diversas formas de botar o sshguard a rodar, fazendo o syslog rodar o daemon e outras formas diversas. Mas como esta é uma das mais simples optei por ela. Para maiores informações recomendo que você leia o README que vem junto com o source.

Um forte abraço e até a próxima, espero que seja de utilidade a todos administradores que passam por aqui.

Página anterior

Páginas do artigo

1. Introdução
2. Configuração e a hora do show!

Outros artigos deste autor

Integrando o Mercury e o XMMS

Leitura recomendada

Enjaulamento de usuário no sistema operacional

Utilizando SSH com método de autenticação publickey + ssh-agend + ssh-add

Instalação do Comodo Antivirus para Linux (CAVL) resolvendo o problema de dependências

Segurança no SSH via plugins da PAM

Segurança Física (Parte 1)

Comentários

[1] Comentário enviado por maran em 15/01/2008 - 10:08h

é eu ja tinha visto algo sobre o sshguard ele é basico em qualquer servidor ssh, mais ta ae né.
Belo artigo

Te Mais...

0 0

[2] Comentário enviado por elgio em 15/01/2008 - 11:33h

Muito bom e interessante!

Agora o que eu esperava mesmo é que o próprio ssh tivesse este mecanismo dentro dele! O apache já tem algo parecido. Aguardemos, quem sabe...

0 0

[3] Comentário enviado por mre em 15/01/2008 - 14:13h

Eu já ví em logs alguns ataques de força bruta em alguns servidores, mas todos eram na porta 22, oq me leva a crer que eram automatizados, o ssh guard + mudança de porta default + "log review diário" de forma automatizada + nao permitir login root + protocolo 2 é a chave para a segurança em ssh...

Parabéns pelo artigo.

Murilo R. Esplugues

0 0

[4] Comentário enviado por mondragon em 15/01/2008 - 14:56h

compilou tudo certinho, funcionou tudo...
mas nao aparece nada no messages e tambem nao bloquea

o que sera que pode ser?

0 0

[5] Comentário enviado por fred_m em 15/01/2008 - 15:18h

Elizandro, Como fica a questão de desempenho quando desviamos todo o tráfego ssh pelo sshguard ? Em sistemas que recebem muitas conexões sejam para acesso ao shell ou copiando e enviando arquivos.

Tem opção de envio de emails de alerta ?

Abraços.

Fred

0 0

[6] Comentário enviado por elgio em 15/01/2008 - 15:28h

O trafego NÃO É DESVIADO para o sshguard!

Faltou uma explicação de como ele atua, mas vamos lá.

O sshguard nada mais é que um interpretador de logs. Ele fica lendo o /var/log/messagens observando as mensagens de login que falhou do SSH. Ele cataloga estas mensagens e se ele, através dos logs do ssh, observar que um mesmo ip errou a senha repetidas vezes, o sshguard manda o iptables bloquear aquele IP. Por isto a necessidade da chain sshguard no iptables.

A idéia do sshguard é incrivelmente simples e sua lógica fácil de entender. As coisas simples são, geralmente, as mais belas!!

0 0

[7] Comentário enviado por elgio em 15/01/2008 - 15:35h

Ainda: ele não tem nada a ver com o ssh.

Os problemas de desempenho que posso observar são os seguintes:

a) muitas mensagens no messages aliado a uma máquina com pouco processador podem fazer o sshguard não ter tempo de avaliar todas. Mas como nosso amigo disse, ler o /var/log/messages com o uso de PIPE é a maneira mais simples. Ele não disse, mas eu digo: não é a mais eficiente.

b) toda a conexão porta 22 é desviada para a chain sshguard. Depois de um bom tempo esta chain pode ter, CEUS, até milhares de ips bloqueados. TODO PACOTINHO ssh passaria por todas as milhares de regras da chain. Uma solução MUITO BOA é desviar para esta chain APENAS os pacotes de inicio de conexão (ou testando o flag SYN ou usando a diretiva NEW do state). Conexões estabelecidas não tem porque passar por esta regra pois PESARIA muito o desempenho em caso de muitas. Ficaria assim:

ao inves de iptables -A INPUT -p tcp --dport 22 -j sshguard
colocar iptables -A INPUT -p tcp --syn --dport 22 -j sshguard

Eu achei interessante este sshguard, mas não o usaria.
Não uso porque ele RESOLVE SIM de uma forma simples, mas eu já resolvo este problema de uma maneira muito eficiente, porém artesanal usando a tabela recent do iptables.

0 0

[8] Comentário enviado por fred_m em 15/01/2008 - 15:45h

Elgio,
Você poderia descrever melhor o uso dessa tabela do Iptables ?

0 0

[9] Comentário enviado por [dt.Sl4cK*] em 15/01/2008 - 16:02h

Pessoal,

Na verdade testei um brute force de uma máquina com um link porrada ( gringa ) e bom hardware contra um pentium 133 em uma adsl no brasil e não tive problemas de desempenho, ele bloqueou tranquilamente.

Mas, conforme citaram acima.. quando essa chain ficar gigantesca, claro que terás problema de desempenho ( assim como com qualquer outra chain ). Mas independentemente disso, você pode limpar essa chain de tempos em tempos. Afinal se o invasor tentar denovo ele será bloqueado denovo.

Ainda ressaltando, criei este artigo para ocasiões específicas conforme o anúncio da mesma, e em momento algum citei como "a melhor opção". Apenas quiz expor mais uma ( eficiente ).

Eu particularmente utilizo-a em alguns dos servidores dos provedores que administro, e não tenho problemas.

De qualquer forma.. obrigado a todos!

0 0

[10] Comentário enviado por elgio em 15/01/2008 - 16:40h

Tabela recent:

Eu descobri esta tabela através deste artigo:
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=5551

Olha os COMENTÁRIOS do artigo acima. Em um deles, meu, eu explico minha solução para ssh brute force usando a tabela recent. É a que eu uso com sucesso ainda hoje.

Eu pensei em escrever um artigo sobre isto. Na época faltou-me tempo e agora falta-me motivação.

[]'s

0 0

[11] Comentário enviado por wendelhp em 16/01/2008 - 09:03h

Para que SSH Guard para bloquear o login, se podemos fazer via PAM? Alem do que, se for para usar SSH Guard, prefiro usar DenyHosts, porque alem de gerenciar o SSH, ele gerencia muito outros servicos e tentativas de negacao de servico e etc.

Tks,

0 0

[12] Comentário enviado por fmpfmp em 16/01/2008 - 11:38h

O Fail2ban faz a mesma coisa.

0 0

[13] Comentário enviado por carlosjacon em 06/01/2012 - 10:15h

Uma alternativa rápida, crie um script ou execute no shell as seguintes linhas de comando para o iptables (na mesma ordem):

iptables -I INPUT -p tcp --dport 22 -i eth3 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth3 -m state --state NEW -m recent --update --seconds 600 --hitcount 8 -j DROP

* substitua "eth3" pela placa de rede utilizada no SSH.
* "--hitcount 8" refere-se a quantas vezes a senha/usuário poderão ser digitados errados até o bloqueio; "--seconds 600" refere-se ao tempo que tal IP irá ficar bloqueado.

0 0