Linux

DenyHosts – Proteja o seu servidor de ataques via SSH

3 Mai 2012

17 Comentários

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

Autor: Pedro Pinto

Partilhar:

Tags:

Artigo anterior

Elenco português de Sorcery™ já é conhecido!

Próximo artigo

Mozilla apresenta planos para novas interfaces do Firefox

Também pode gostar

PUB

Comentários

Responder a José Maria Oliveira Simões Cancelar resposta

Cagamelo Voador

3 de Maio de 2012

Útil… 🙂 Obrigado.

Responder
Duarte Mechas

3 de Maio de 2012

Aconselho a dar uma olhada no Fail2Ban. Muito bom!
http://www.fail2ban.org/wiki/index.php/Main_Page

Responder
1. João Ildefonso
  
  3 de Maio de 2012
  
  Concordo
  
  Responder
Rui Costa

3 de Maio de 2012

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.

Responder
Nuno Mendes

3 de Maio de 2012

Boa recomendação Pedro. Ataques (ou tentativas) de tipo bruteforce em SSHd estam sempre a acontecer.

Responder
bintoito

3 de Maio de 2012

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!

Responder
1. q
  
  4 de Maio de 2012
  
  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.
  
  Responder
  1. José Maria Oliveira Simões
    
    4 de Maio de 2012
    
    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
    
    Responder
José Maria Oliveira Simões

3 de Maio de 2012

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

Responder
Nelson N

3 de Maio de 2012

Uma dúvida: por defeito não é instalado não é verdade?
E no caso de ser instalado, como se desactiva ou elimina?
obrigado

Responder
brucetuga

3 de Maio de 2012

interessante o aplicativo mas para administradores de sistemas não é mais fácil redireccionar um porto xxxx para o porto 22?

Responder
1. Filipe YaBa Polido
  
  3 de Maio de 2012
  
  Exactamente! mais simples, rápido e eficaz.
  Ou isso ou port knocking 😀
  
  Responder
Deus

3 de Maio de 2012

Muito útil, logo agora que estou a aprender a trabalhar com servidores por ssh 😀

Responder
lol

3 de Maio de 2012

iptables? nao?

http://lmgtfy.com/?q=iptables+deny+ssh

Responder
Roy

3 de Maio de 2012

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.

Responder
1. José Maria Oliveira Simões
  
  4 de Maio de 2012
  
  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.
  
  Responder
Tiago Carvalho

7 de Maio de 2012

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

Responder

Aviso:

Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.