Fail2Ban: Proteja já o seu Raspberry PI

29 Comentários

A ferramenta Fail2Ban pode ser considerada como um agente que monitoriza regularmente os logs dos mais diversos serviços do seu sistema Linux. No caso de encontrar tentativas de acesso indevidas a um determinado serviço (ex. ssh, pam, xinetd, apache, vsftpd, proftpd, wuftpd, postfix, named, etc), o Fail2Ban adiciona dinamicamente uma regra na firewall do sistema que bloqueia de imediato as sessões/comunicações do suposto atacante.

Aprenda da instalar e configurar o Fail2Ban no seu Raspberry PI.



Com instalar o Fail2Ban no  Raspberry PI?

Este tutorial tem como base o sistema operativo PiPplware, no entanto deverá funcionar em outras distribuições que têm como base o Ubuntu.

A instalação do Fail2Ban é bastante simples. Para tal basta executar o seguinte comando:

sudo apt-get update && sudo apt-get install fail2ban

Em seguida vamos ao ficheiro de configuração (/etc/fail2ban/jail.conf) e adaptamos de acordo com o que pretendemos. Vamos por exemplo considerar o serviço SSH.

nano -w /etc/fail2ban/jail.local

Próximo passo é ir à secção [Default] onde podemos fazer algumas configurações. Para este exemplo vamos considerar que devem ser ignorados os endereços IP da gama 192.168.0.0/16, que o número de segundos que uma máquina deve ficar banida deve ser de 15 minutos (900 segundos) e que o Fail2Ban apenas atua após 3 tentativas falhadas de autenticação.

# SSH
# 3 tentativas falhadas: Ban por 15 minutos
[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
logpath = /var/log/auth.log
maxretry = 3
bantime = 900
ignoreip = 192.168.0.0/16

Feita a configuração geral, vamos agora indicar o serviço. O Fail2Ban tem já alguns filtros pré-definidos para vários serviços. Assim basta fazer algumas adaptações.

Aqui vai um exemplo:

[ssh-ddos]
enabled = true
port = ssh
filter = sshd-ddos
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 10
ignoreip = 192.168.0.0/16

Nota: Não se esqueçam de indicar o caminho correto do log do SSH do vosso sistema.

Por fim reiniciem o serviço Fail2Ban usando o seguinte comando:

sudo /etc/init.d/fail2ban restart

Verifique se o Fail2Ban está a funcionar acedendo ao ficheiro de log.

sudo tail -f /var/log/fail2ban.log

Já conhece a nossa promoção do Raspberry PI? Vejam aqui a nossa promoção (agora com o PiPplware 6).

Comentários

29

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

  1. Avatar de joao
    joao

    O fail2ban é essencial para qualquer servidor. Recentemente com o aumento the ataques “brute force” o melhor ainda é bloquear países como china, india, vietnam,etc, usando o framework IPSET

    1. Avatar de Pedro Pinto

      Obrigado pela dica.

      PP

    2. Avatar de N'uno
      N’uno

      Boa observação! Para além disso, configurar os serviços com um segundo factor de autenticação, ou com chaves simétricas, é igualmente recomendável.

      1. Avatar de Gekko
        Gekko

        “configurar os serviços com um segundo factor de autenticação”, pode servir para dificultar, mas 2FA, não é infalível.

        Já há pessoal a piratear contas que usam segundo factor de autenticação:
        http://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html

        1. Avatar de N'uno
          N’uno

          Nada é 100% infalível, é certo, mas ainda existem bons 2FA. O exemplo que referes é específico das OTPs enviadas por SMS, algo a que nunca atribuí grande robustez em termos de segurança. Há soluções muito mais fiáveis, baseadas em hardware específico (tipo yubikeys) ou, em menor grau, em TOTPs (authenticators como o da google, por exemplo).
          A utilização de chaves simétricas também é bastante fiável.

          1. Avatar de Gekko
            Gekko

            Concordo com tudo o que dizes. Excepto com a parte do google. Mas tenho uma posição de principio contra a google e o seu modelo de negocios. Por muito bom que seja o software deles tecnicamente, evito-o sempre que possível.

            TOTPs não conheço bem. Chaves digitais existiam muito antes da expressão “2FA”.

          2. Avatar de N'uno
            N’uno

            O Google authenticator implementa um protocolo de segurança standard, público. O lastpass tem um, a yubico idem, e todos eles são naturalmente compatíveis.

  2. Avatar de Ricardo
    Ricardo

    A maioria dos ataques serão feitos por bots, mudem a porta de telnet para outra que não a 21, basta pesquisarem no google, é essencial que mudem aliás.

    Só aqui já evitam 99% dos ataques, batem na parede.

    Podem usar simplesmente o CSF e até países inteiros podem bloquear, facilmente escolhem as portas que usam, e apenas essas. Firewall básica.

    1. Avatar de Pedro Pinto

      Quem ainda usa telnet?

      1. Avatar de Ricardo
        Ricardo

        Boa!
        Quem diz telnet diz qualquer porta comum a serviços de login.
        Tirando as que não podemos alterar, por conflitos. Telnet ainda deve ser o mais comum método de entrada, digo eu.

        Já agora fica a sugestão para um artigo acerca dos métodos para esquivarmos o nosso servidor dos bots e bot-nets.

        1. Avatar de N'uno
          N’uno

          Subscrevo essa sugestão. Um bom artigo sobre hardening é cada vez mais relevante.
          A alteração dos portos standard dos serviços é também uma boa recomendação. Aliado a uma ferramenta como o CSF, que detecta e bloqueia varrimentos de portos, completa mais um layer de defesa interessante.

        2. Avatar de Ricardo
          Ricardo

          Qualquer serviço conhecido de comunicação é vulnerável se usarmos a porta com que está catalogado ele funcionar.
          Onde quero chegar com isto é que qualquer que seja o serviço que usem, mudem sempre a porta standard que é suposto usar. Os bots são configurados com a lista de portas comuns, logo se as mudarem o sistema fica completamente inutilizável.

      2. Avatar de Ricardo
        Ricardo

        Além disso, a maioria pode nem usar telnet e nem sabe, daí o sucesso das botnets mas basta que o serviço esteja activo na instalação, convém referir isso.

      3. Avatar de Gekko
        Gekko

        “Quem ainda usa telnet?” Os ISP e os seus routers.

        É paralelo ao artigo em causa, mas se estamos a falar de proteger Raspberry’s PI por os “termos ligados” à net com port forward e no-ip.

        Poderia ser interessante pensar num artigo sobre como reforçar a segurança de um router aplicado a casos destes.

        Raspberrys e serviços ligados à net a partir de casa

        1. Avatar de Ricardo
          Ricardo

          Porta SSH também deve ser mudada, eu quando falei telnet falei SSH e todas as que são já comuns a software conhecido e usado.

        2. Avatar de Pedro H.
          Pedro H.

          A questão é que para segurar um router, é necessário mudar passwords por defeito do ISP ( um dos passos ). Mas se a mudamos, torna-se impossível a assistência técnica…

          1. Avatar de N'uno
            N’uno

            Isso é muito complicado, pois os ISPs têm normalmente contas superadmin escondidas. A única hipótese é não confiar de todo no router do ISP, até porque não sabemos quem por lá entra com super-poderes, e usar, por exemplo, um segundo router, interno, para os nossos equipamentos. Esta solução pode aproveitar um router antigo e usar DD-WRT ou Openwrt, com várias vantagens.

      4. Avatar de Gonçalo
        Gonçalo

        Quem ainda usa telnet? todos os clientes de email porta 110 e 25 quando nao ha SSL e/ou TLS…

    2. Avatar de N'uno
      N’uno

      Telnet nem numa rede interna! 🙂 Mas a dica do CSF é muito interessante. Obrigado!

      1. Avatar de Ricardo
        Ricardo

        O que usas para controlar remotamente por linhas de comandos?

        O telnet por si só é seguro, mudar a porta torna-o algo completamente diferente porque não está no sitio habitual. Telnet associamos à porta 21 comum, não tem de morar lá para ser telnet.

        1. Avatar de N'uno
          N’uno

          ssh, com chaves simétricas.

          1. Avatar de Ricardo
            Ricardo

            Porta SSH também deve ser mudada, eu quando falei telnet falei SSH e todas as que são já comuns a software conhecido e usado.

  3. Avatar de helloooo
    helloooo

    telnet é na porta 23. A porta 21 é de FTP

    1. Avatar de Ricardo
      Ricardo

      Certo, seja qual for a porta, SSH, Telnet, devem mudar do número de porta nativo.

      Os bots são configurados para bruteforce aquelas portas conhecidas, nem sequer fazem port scan…

  4. Avatar de Pedro
    Pedro

    Boa tarde
    Alguem pode partilhar como podemos ativar os alertas por email em caso de tentiva de acesso SSH falhada ?

    1. Avatar de N'uno
      N’uno

      A configuração deste artigo já envia alertas por email, mas para isso é necessário que alteres os defaults (na /etc/fail2ban/jail.local, caso a tenhas criado, por exemplo):

      [DEFAULT ]
      destemail = root@localhost
      sendername = Fail2Ban
      mta = sendmail

      O email deve ser alterado para o que pretendes, o sendername idem, e deves ter o sendmail instalado, caso contrário também deverás alterar para o que tiveres instalado, ou instalar o sendmail.

  5. Avatar de bruno
    bruno

    Grande Fail2Ban, aproveitei a dica do Pplware, há quase dois anos atrás e hoje coloco em vários clientes, com resultados muito satisfatórios.
    Aproveito para deixar a minha experiência, tivemos imensos ataques e acabei bloquear os IPs. Como “ingénuo”, enviei para o ISP / email associado ao IP, indicando o ataque sofrido.
    Tive algumas respostas, todas com vírus e/ou pishing, com hyperlinks falsos.
    É incrível como tantos hosts da China estão consecutivamente a scanar a rede àprocura de portas abertas para iniciar o ataque de brute force.

  6. Avatar de Arcanjo
    Arcanjo

    A china e russia estão criando sua propria internet, seria bom eles sumirem do planeta tambem