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