Fail2Ban: Proteja já o seu Raspberry PI


Destaques PPLWARE

28 Respostas

  1. joao says:

    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

    • Pedro Pinto says:

      Obrigado pela dica.

      PP

    • N'uno says:

      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.

      • Gekko says:

        “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

        • N'uno says:

          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.

          • Gekko says:

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

          • N'uno says:

            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. Ricardo says:

    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.

    • Pedro Pinto says:

      Quem ainda usa telnet?

      • Ricardo says:

        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.

        • N'uno says:

          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.

        • Ricardo says:

          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.

      • Ricardo says:

        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.

      • Gekko says:

        “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

        • Ricardo says:

          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.

        • Pedro H. says:

          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…

          • N'uno says:

            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.

      • Gonçalo says:

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

    • N'uno says:

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

      • Ricardo says:

        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.

  3. helloooo says:

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

  4. Pedro says:

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

    • N'uno says:

      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. bruno says:

    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.

Responder a Pedro Pinto Cancelar Resposta

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

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.