Bloqueio de repetidas tentativas de login ao seu Linux

jmhenrique

Esse artigo mostra como implementar um sistema de segurança para bloqueio de ataques brute-force em seu servidor SSH. Ao mesmo tempo também mostra como criar um esquema para permitir acesso remoto (para manutenção) a partir de qualquer IP da internet.

[ Hits: 107.045 ]

Por: julio henrique maschio em 10/11/2005

1 0

Denuncie Favoritos Indicar Impressora

Afinando o seu sistema....

1. hosts.deny, hosts.allow

Algumas pessoas em listas da internet recomendam que nos arquivos /etc/hosts.deny e /etc/hosts.allow fossem bloqueados domínios como cz, cn, net.cn, cn.com, ar, cl...

Mas depois de 1 mês analisando os logs, não achei nenhuma tentativa de acesso destes domínios.

Também achei referências dos acessos ao sshd via endereçamento ipv6 não serem bloqueados via tcpwrappers.

Para fazer com que o SSH somente seja acessível pelo ipv4, edite o seu /etc/ssh/sshd_config e na opção "ListenAddress", somente deixe o endereçamento no estilo ipv4:

ListenAddress 0.0.0.0

A menos que você seja um feliz usuário do ipv6!

se porventura a linha abaixo estiver descomentada, comente-a!

#ListenAddress ::

Isso vai impedir o sshd responda a endereços ipv6.

Bem, como o seguro morreu de velho, eu restringi o acesso ao daemon sshd apenas aos domínios .com e .br (imagino que nenhum de nós irá acessar da Finlândia por exemplo).

Ficou assim a minha configuração nos arquivos /etc/hosts.deny:

sshd: PARANOID ALL EXCEPT .com .br UNKNOWN

/etc/hosts.allow:

sshd: 172.24.12. 127.0.0.1 .com .br UNKNOWN : spawn (echo | /usr/bin/mail -s "[ SSH ] - %c - %u %h %s" root) &

Explicações a respeito do PARANOID e do UNKNOWN:

PARANOID faz uma verificação para saber se provavelmente o acesso está sendo spoofado... por exemplo, um host que diz ter um IP, mas o reverso não bate... ou seja, altamente suspeito.
UNKNOWN faz referência aos IPs que não possuem reverso definido... como por exemplo os acessos vindos de dial-ups do IG (a grande maioria dos nossos acessos são feitos a partir de provedores que não se preocupam minimamente com o reverso... fazer o quê, não é?).

Então, quer dizer que eu vou ignorar todos os acessos que a origem seja:

Diferente do Brasil e .com;
Com reverso incorreto.

e vou aceitar todos os acessos que:

A origem seja no Brasil ou .com;
Sem reverso (provedores brasileiros, eca).

e vou mandar email para cada tentativa de acesso que seja feita. Essa é uma boa maneira de testar na hora se a sua instalação está sendo alvo de um ataque. Especialmente porque não temos tanto tempo assim para ficar vendo telas de logs dinâmicos, mas o email a gente sempre dá uma lida!

Alguém tinha me sugerido que fosse colocado no hosts.allow por faixa de IPs... mas é impraticável, as universidades públicas de SP usam a faixa 143.10x, a maioria dos provedores usam a faixa 200.x e agora estou vendo provedores usando a 201.x... ou seja, o risco de "esquecermos" alguém fica enorme e a chance de bloquearmos nós mesmos usando um provedor com IPs diferentes aumenta e muito.

Por fim, uma ótima prática de segurança consiste em editar o arquivo /etc/ssh/sshd_config e na tag "AllowUsers" colocar os usuários que possam realizar acesso via SSH.

Com a prática e a análise dos logs, é possível uma personalização maior com um aumento das regras de faixas de IPs bloqueados. Mas isso cabe a cada administrador pesar na sua balança.

Não se esqueçam que este é um artigo escrito para quem precisa acessar o sistema remotamente dentro de um dado perímetro geográfico e geralmente em um estado de nervos que beira ao desespero!!! rs

Página anterior Próxima página

Páginas do artigo

   1. O problema
   2. Bloqueio de repetidas tentativas por regras de iptables
   3. Considerações sobre fail2ban
   4. Instalação do fail2ban - Debian like
   5. Configurando o fail2ban
   6. fail2ban.conf - comentários
   7. Afinando o seu sistema....
   8. Considerações finais

Outros artigos deste autor

Acelere o seu Squid com squid-prefetch - baixe as páginas antes dos seus usuários!

Leitura recomendada

TinyOS

Varredura bruta com NMAP

Servidores Proxy - Segurança da Informação

Bloqueio de usuários com o chroot

Festa com SQL injection

Comentários

[1] Comentário enviado por fernoliv em 10/11/2005 - 01:53h

Caro Julio, parabéns pelo artigo!

Eu gostaria de citar outros dois softwares que utilizo para bloquear IP´s de atacantes em meu servidor:

APF Firewall
http://www.rfxnetworks.com/apf.php
Descrição: Firewall baseado em IPTables de fácil configuração e muito eficiente. A configuração é feita através de um .conf simples onde são informadas as portas a serem liberadas/bloqueadas, além de outras funcionalidades tanto para portas tcp como udp, além de bloquear ataques via ICMP (Denial of Service por exemplo) pois possui embutido um "anti-DOS". Utiliza a lista negras de IP´s que é atualizada frequentemente através do site www.dshiel.org (Distributed Intrusion Detection System), onde constam os IP´s utilizados com maior frequência para fins ilícitos.
-------------------------------------------
BFD - Brute Force Detect
http://www.rfxnetworks.com/bfd.php
Descrição: Em conjunto com o APF Firewall, detecta tentativas de acesso não autorizada a serviços como SSH, Apache, EXIM, FTP, etc. Após 5 tentativas de acesso sem sucesso, o IP de origem é "dropado" no IpTables e o administrador do servidor pode ser avisado por e-mail.

Ambos são desenvolvidos pelo RFX Networks e são free e de uso irrestrito. Não é preciso manjar de IpTables, basta saber quais portais você quer liberar/fechar e eles fazem o trabalho.

É isso ai!

Abraço, Fernando.

0 0

[2] Comentário enviado por jmhenrique em 10/11/2005 - 08:37h

Apenas em tempo! desde quando escrevi o artigo, já sairam importantes modificações nas configurações com relação a failregex do ssh. No caso, a versão anterior apenas fazia um 'match case' simples, mas agora está muito mais sofisticada, e tende a ficar cada vez mais.
Caso você tenha seguido os passos e desabilitado a listagem do ssh na interface ipv6, você terá que editar também a failregex e retirar o bloco (?:::f{4,6}:)? dela, pois senão ele não irá casar a regra. Ficaria então algo como:

failregex = : (?:(?:Authentication failure|Failed [-/\w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii (?:llegal|nvalid) user).* from (?P<host>\S*)

0 0

[3] Comentário enviado por technomancer em 10/11/2005 - 09:31h

Muito obrigado! Eu tenho um servidor aqui na empresa que disponibiliza acesso via ssh e estou tendo logs cheios também.

Dam kidos!

0 0

[4] Comentário enviado por lennon.jesus em 10/11/2005 - 09:34h

Grande dica! As configurações de segurança dessa ferramenta são fundamentais para qualquer Sistema que precise ser acessado remotamente.

Parabéns pelo artigo!
XD

0 0

[5] Comentário enviado por technomancer em 10/11/2005 - 10:02h

Voltando a comentar... hoje fui dar uma checada no log, e me deparei com o registro de um possivel ataque de dicionario via ssh.

Quero agradecer novamente. Mais um ponto contra os kidos!

0 0

[6] Comentário enviado por jmhenrique em 10/11/2005 - 10:52h

technomancer, se você quer dar uma aliviada no fail2ban fazendo ele bloquear somente as coisas NECESSÁRIAS, eu incrementei as regras do hosts.allow e do hosts.deny...
segue abaixo:
1 - Imagino que você só irá acessar da rede brasileira, fiz um script que até o presente momento funciona a contento. Ele analisa via whois o ip da pessoa que está tentando acessar, e dependendo da resposta, automaticamente atualiza o hosts.allow ;-)
2 - edite o arquivo /etc/hosts.allow e coloque somente o seguinte:
#exemplo da sua rede:
sshd: 172.22.34.
#linha de comando que irá enviar o email, rodar
#o script que verifica se o ip pertence ao
#Brasil e se for o caso, re-escrever o hosts.allow sozinho.

sshd: ALL : spawn (echo | /usr/bin/mail -s "[ SSH ] - %c - %u %h %s" root ; /usr/local/bin/verifica_ip %a )

salve e coloque este script em /usr/local/bin/

--corte-----
#!/bin/sh
#Script de Dominio Público criado por
#Julio Henrique Maschio -
#Dominio Publico - a única e verdadeira LIBERDADE
#verifica_ip - verifica se o ip pertence ao brasil

IP_EXTERNO=$1
if [ "$IP_EXTERNO" == "" ] ; then

echo Uso: $0 xxx.www.yyy.zzz
echo
exit 1
fi

#SE O IP PERTENCE AO BRASIL, $VERIFICA_BRASIL DEVERÁ SER
#UMA STRING VAZIA
VERIFICA=`whois $IP_EXTERNO | grep -i \\.br`
if [ $? != 0 ] ; then
#o ip nao é do brasil, pode ser bloqueado tranquilamente.
#iremos bloquear logo a rede inteira...
REDE=`echo $IP_EXTERNO | cut -d\. -f1,2,3`
REDE="$REDE."
echo "sshd: $REDE" : DENY >>/tmp/$$listagem$$
cat /etc/hosts.allow >>/tmp/$$listagem$$
cat /tmp/$$listagem$$ >/etc/hosts.allow
rm -f /tmp/$$listagem$$

else
echo "nada a fazer"
fi

---corta---

este script verifica se o ip é do Brasil, se não for, adiciona ele no hosts.allow com uma instrução de DENY.
Ou seja, voc vai ver ele somente uma vez nos logs...hehehe
(não se esqueça de dar um chmod 755 nele, né?)

pronto, mais uma camada de segurança ao seu linux. :-D

0 0

[7] Comentário enviado por Herr_Filip em 11/11/2005 - 08:29h

show o artigo!
parabens!!

0 0

[8] Comentário enviado por removido em 11/11/2005 - 20:39h

parabéns.. Muito bom o artigo
!!!

0 0

[9] Comentário enviado por Century_Child em 15/11/2005 - 19:52h

Interessante. Tem alguém que fica "poluindo" minha conexão (que já não é lá essas maravilhas) com tentativas de login via SSH.

0 0

[10] Comentário enviado por diogofsr em 10/06/2006 - 06:58h

Belíssimo artigo meu amigo.
Me ajudou horrores.
Valeu mesmo.

0 0

[11] Comentário enviado por cold_feelings em 14/09/2006 - 07:57h

Vlw ae pelo artigo, era disso q eu tava precisando .. :)

0 0

[12] Comentário enviado por pontejunior em 16/03/2009 - 20:05h

Gostei...Muito interessante...São poucos que merecem entrar nos favoritos e este é um deles.

0 0

[13] Comentário enviado por perucio em 12/09/2012 - 09:23h

no meu jail.conf não funcionou a função de e-mail, se mando e-mail via console ele vai normalmente, quando restarto o serviço ele da mensagem de erro!

[MAIL]
enabled = true
host = localhost
port = 25
from = root
to = MEU_EMAIL@EMPRESA.COM.BR
subject = [Fail2Ban] Bloqueio <ip>
message = Hi,<br>
The IP <ip> has just been banned by Fail2Ban after
<failures> attempts.<br>
Regards,<br>
Root

0 0