Proponha uma correção, faça uma sugestão
DenyHosts – Proteja o seu servidor de ataques via SSH
…baseados em dicionários e de força bruta
Como já tive oportunidade de referir em vários artigos, sou um “viciado” em SSH para acesso remoto as minhas máquinas a partir de qualquer lugar/dispositivo. O SSH (Secure Shell), também conhecido como Secure Socket Shell, é um protocolo/aplicação que permite de forma segura aceder remotamente a uma máquina Linux.
No entanto, ao activarmos o SSH numa máquina Linux no porto 22 e estando esta exposta para o exterior (Internet), é frequente começarmos a receber milhares de tentativa de acesso provenientes de todo o mundo. Como resolver esta situação?
Para quem não sabe, os ataques baseados em força bruta recorrem normalmente a dicionários e vão testando milhares de utilizadores e passwords até que se consiga ganhar acesso. Para quem é administrador de sistemas linux e caso tenha o SSH a correr no sistema, pode visualizar facilmente essa informação nos logs do sistema (no caso do CentOS, essa informação está em /var/log/secure).
O que é o DenyHosts?
O DenyHosts é um script desenvolvido para sistemas Linux que permite “ajudar” no controlo de ataques indevidos via SSH. Na prática, este script avalia constantemente as tentativas de acesso via SSH e no caso de serem considerados como ataques de força bruta, é criada uma entrada no ficheiro /etc/hosts.deny que bloqueia o acesso da máquina remota (que supostamente está a tentar aceder indevidamente).
Este script permite:
- Processar todas as tentativas de acesso (com e sem sucesso) que são registadas no ficheiro /var/log/secure
- Definir um número de tentativas falhadas no acesso
- Adicionar manualmente máquinas à lista negra (adicionando essa informação no ficheiro /etc/hosts.deny)
- Adicionar manualmente máquinas à lista de máquinas permitidas (adicionando essa informação no ficheiro /etc/hosts.allow)
- Envio de e-mail para administrador da máquina com informações sobre as máquinas bloequadas
- Resolução de IPs para hostnames
- ..entre muitas outras funcionalidades (ver aqui)
Como instalar o DenyHosts no CentOS?
Para este tutorial, recorremos ao CentOS 6.0.
Para instalar o DenyHosts via repositório, vamos adicionar à nossa máquina o repositório EPEL
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm yum install yum-priorities |
Em seguida instalamos o script DenyHosts
yum install denyhosts |
Definimos que o denyhosts deverá arrancar ao automaticamente com o sistema
chkconfig denyhosts on |
e em seguida, arrancamos o serviço
service denyhosts start |
E está feito. Caso pretendam realizar alguma configuração no denyhosts devem fazê-la em /etc/denyhosts.conf
Para verificarem quais as máquinas que o denyhosts coloca na blacklist, basta aceder ao ficheiro /etc/hosts.deny, utilizado para isso, por exemplo, o comando:
tail -f /etc/hosts.deny |
Dica: Para verificarem o denyhosts experimentem, a partir de uma máquina remota, ligaram-se ao vosso servidor com SSH e experimentarem 5 autenticações falhadas.
Este artigo tem mais de um ano
Loading ...
Útil… 🙂 Obrigado.
Aconselho a dar uma olhada no Fail2Ban. Muito bom!
http://www.fail2ban.org/wiki/index.php/Main_Page
Concordo
Segurança acima de tudo. Tenho utilizadores que me solicitam a possibilidade alterarem as suas senhas mas umas mais “memorizaveis”, mas devido á segurança que imponho aos meus servidores isso será impossível de acontecer.
Boa recomendação Pedro. Ataques (ou tentativas) de tipo bruteforce em SSHd estam sempre a acontecer.
Boas,
Aproveito o tópico para colocar uma questão:
Tenho DD-WRT (não me recordo agora da v específica, se não for a última há.de ser das + recentes pq é de meados do mês passado) num Asus RT-N13U rev B1.
Tenho disabled todas as hipóteses de acesso a partir da WAN tipo telnet, ssh, admin etc e tal, contudo ao correr o GRC Shields Up tenho sempre a porta 80 visível (as restantes “common ports” estão stealth).
Não percebendo puto de comandos, apenas contando já com alguns anos de experiência empírica a configurar routers, que fazer para ter td stealth?
Toda e qualquer sugestão é mt bem-vinda!
Portal 80 é a porta utilizada pelo browser para veres os sites de internet com ela fechada não irias conseguir nem sequer ver este site, e stealth n internet é coisa que nao existe tens de ter uma boa firewall e um antivirus sempre atualizado.
Tenha em atenção que para se poder ter acesso à WAN, o porto 80 é aberto para fora. Só os servidores WEB é que tem (devem ter) o porto 80 aberto para dentro. De qualquer forma, o porto 80 está a ser visto, porque o router respondeu com o protocolo ICMP. Consulte aqui a informação
http://nmap.org/man/pt_PT/man-port-scanning-techniques.html
e aqui
http://www.normes-internet.com/normes.php?rfc=rfc792&lang=pt
pode por no iptables qualquer coisa semelhante a
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP
Para fazer face ao problema descrito, pode inserir estas instruções no iptables. A vantagem é que a porta é fechada durante um certo tempo. Depois, a porta volta a ser aberta automaticamente. Na pratica, ajuda a que não se seja vitima de DOS, pois, passado o tempo estipulado, a porta é aberta. Isto é o que se chama, o inferno dum cracker, pois, não consegue entrar, nem consegue fazer um ataque DOS.
# Bloqueia crackers a tentar penetrar no sistema
/sbin/iptables -N SSH
/sbin/iptables -N SSH_ABL
/sbin/iptables -A SSH -m recent –name SSH_ABL –update –seconds 3600 -j REJECT
/sbin/iptables -A SSH -m recent –name SSH –rcheck –seconds 60 –hitcount 5 -j SSH_ABL
/sbin/iptables -A SSH_ABL -m recent –name SSH_ABL –set -j LOG –log-level warn –log-prefix “ABL: +SSH: ”
/sbin/iptables -A SSH_ABL -j REJECT
/sbin/iptables -A SSH -m recent –name SSH –rcheck –seconds 2 -j LOG –log-level warn –log-prefix “RATE: ”
/sbin/iptables -A SSH -m recent –name SSH –update –seconds 2 -j REJECT
/sbin/iptables -A SSH -m recent –name SSH_ABL –remove -j LOG –log-level warn –log-prefix “ABL: -SSH: ”
/sbin/iptables -A SSH -m recent –name SSH –set -j ACCEPT
/sbin/iptables -A INPUT -m state –state NEW -p tcp -m tcp –dport 22 -j SSH
# Protecao contra Ataques DoS
/sbin/iptables -A INPUT -m state –state INVALID -j DROP
/sbin/iptables -A OUTPUT -p tcp ! –tcp-flags SYN,RST,ACK SYN -m state –state NEW -j DROP
Uma dúvida: por defeito não é instalado não é verdade?
E no caso de ser instalado, como se desactiva ou elimina?
obrigado
interessante o aplicativo mas para administradores de sistemas não é mais fácil redireccionar um porto xxxx para o porto 22?
Exactamente! mais simples, rápido e eficaz.
Ou isso ou port knocking 😀
Muito útil, logo agora que estou a aprender a trabalhar com servidores por ssh 😀
iptables? nao?
http://lmgtfy.com/?q=iptables+deny+ssh
Ainda bem que não percebo nada disso… mas com chaves públicas RSA (com 4096 bits de preferência) ou EC de 521 bits, isso não era mais seguro? Além de confirmar que estão se a ligar ao servidor correcto.
E claro mudar o porto de ligação.. óbviamente.
Ponhamos as coisas neste pé. Você não quer que nenhum “indesejável” entre na sua casa. Portanto, para resolver e prevenir esse problema, compra a tal fechadura toda xpto e monta-a na porta da rua. No entanto, você continua a deixar as janelas da sua casa escancaradas. E diz, “bem … o problema está resolvido”. O tal “indesejável”, sabe que você é um homem precavido, pois, homem prevenido, vale por dois. O tal “indesejável”, que por sinal não é estúpido, põe-se logo a magicar uma maneira de entrar na sua casa. E pensa com os botões dele, “diacho, como é que vou conseguir entrar ?” Então ele repara nas janelas abertas e entra a sua casa, sem ser convidado. Como vê, é o eterno jogo, uns a querer proteger os seus bens e outros a tentar arranjar maneira de lhe deitar a mão. E olhe, que tempo e imaginação, não falta a estes indivíduos.
Obrigado pela dica Pedro Pinto.
Já agora, deixo o meu parecer relativamente a autenticação baseada em password: Por si só é uma falha de segurança. Autenticação com chaves privadas e publicas sempre dificulta ainda mais a vida de utilizadores mal intencionados, espreitem aqui http://www.debian-administration.org/articles/530