Quantcast

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
  1. JO
    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. PP

      Obrigado pela dica.

      PP

    2. NU
      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. GE
        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. NU
          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. GE
            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. NU
            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. RI
    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. PP

      Quem ainda usa telnet?

      1. RI
        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. NU
          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. RI
          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. RI
        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. GE
        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. RI
          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. PH
          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. NU
            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. GO
        Gonçalo

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

    2. NU
      N’uno

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

      1. RI
        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. NU
          N’uno

          ssh, com chaves simétricas.

          1. RI
            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. HE
    helloooo

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

    1. RI
      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. PE
    Pedro

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

    1. NU
      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. BR
    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. AR
    Arcanjo

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

Deixe um comentário