Protegendo seu Linux de ataques de brute force via ssh

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.336 ]

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


Introdução



Neste artigo irei mostrar como você pode se defender de forma fácil e eficiente contra ataques brute force via ssh, que é uma das maiores dores de cabeça aos administradores que necessitam deixar esta porta aberta e onde algumas regras de firewall já não são suficientes.

Testamos e aprovamos o sshguard, que apesar de pequeno é muito flexível, de fácil utilização e o mais importante: preciso e funcional!

Distribuição utilizada nos testes: Slackware 12.0 (http://www.slackware.com)
Softwares utilizados: sshguard (http://sshguard.sourceforge.net)

Além do iptables, que já vem instalado na maioria das distribuições.

Download e instalação

Primeiramente vamos fazer o download da última versão do sshguard. No momento em que escrevi este artigo, a última versão era a 1.0, mas é sempre bom dar uma visitadinha no site antes de instalar para ver se não há alguma nova versão.

Bom, vamos ao download:

$ wget http://ufpr.dl.sourceforge.net/sourceforge/sshguard/sshguard-1.0.tar.bz2

Feito o download, vamos descompactar o arquivo na pasta em que você desejar:

$ tar xvjf sshguard-1.0.tar.bz2

Vamos então entrar na pasta que foi criada com a descompactação do arquivo:

$ cd sshguard-1.0

E então vamos configurar o nosso código fonte para prepará-lo para a compilação. Nesta etapa é importar prestar atenção nos dois parâmetros que devemos passar para o sistema. São eles:

--with-firewall=iptables que indica que o sshguard deverá utilizar o iptables para bloquear os invasores.

--with-iptables=/usr/sbin/iptables que é o caminho de onde está instalado o nosso iptables. No Slackware o caminho padrão é: /usr/sbin/iptables, mas você pode se certificar do caminho correto com o seguinte comando:

$ whereis iptables

Ele vai retornar o caminho completo que você deverá utilizar no parâmetro.

Bom, vamos então configurar o nosso source com o comando:

$ ./configure --with-firewall=iptables --with-iptables=/usr/sbin/iptables

Feito isso, vamos compilar com o comando:

$ make

E instalar com o comando:

# make install

Pronto! Seu sshguard está instalado e chegou a hora do show, vamos para a próxima parte.

    Próxima página

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

Sudoers 1.8.12 - Parte III - Manual

Técnicas forenses para identificação da invasão e do invasor em sistemas Unix/Linux através do SSH (parte 1)

Vazamento de informações vitais via "HP Operations Manager Perfd"

Knockd (bate, bate, bate na porta do céu)

Rainbow Crack e Rainbow Tables

  
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...

[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...


[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

[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?

[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

[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!!

[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.

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

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

[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!

[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

[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,

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

O Fail2ban faz a mesma coisa.

[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.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts