Fail2Ban: Proteja já o seu Raspberry PI
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).
Este artigo tem mais de um ano
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
Obrigado pela dica.
PP
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.
“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
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.
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”.
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.
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.
Quem ainda usa telnet?
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.
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.
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.
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.
“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
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.
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…
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.
Quem ainda usa telnet? todos os clientes de email porta 110 e 25 quando nao ha SSL e/ou TLS…
Telnet nem numa rede interna! 🙂 Mas a dica do CSF é muito interessante. Obrigado!
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.
ssh, com chaves simétricas.
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.
telnet é na porta 23. A porta 21 é de FTP
FTP 20 e 21
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…
Boa tarde
Alguem pode partilhar como podemos ativar os alertas por email em caso de tentiva de acesso SSH falhada ?
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.
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.
A china e russia estão criando sua propria internet, seria bom eles sumirem do planeta tambem