Uma maneira fácil de proteger seu Mikrotik contra ataques

Quero compartilhar com a comunidade um método simples e eficaz de como proteger sua rede e os serviços expostos por meio do Mikrotik contra ataques externos. Em particular, como organizar um honeypot no Mikrotik com apenas três regras.

Então, vamos imaginar que temos um pequeno escritório, com um IP externo por trás do qual está um servidor RDP, utilizado pelos funcionários para trabalhar remotamente. A primeira regra é, claro, mudar a porta 3389 na interface externa para outra. Mas isso não dura muito; após alguns dias, o log de auditoria do servidor terminal começará a mostrar várias tentativas de autenticação falhadas por segundo, provenientes de clientes desconhecidos.

Outra situação: caso você tenha um Asterisk escondido atrás do Mikrotik, claro que não na porta UDP 5060, e após alguns dias os ataques de força bruta começam a ocorrer também... sim, eu sei, o fail2ban é a solução, mas ainda haverá trabalho a ser feito... por exemplo, recentemente eu o instalei no Ubuntu 18.04 e, para minha surpresa, descobri que a versão padrão do fail2ban não contém as configurações atuais para o Asterisk da mesma distribuição Ubuntu... e encontrar configurações rápidas nos 'receitas' não é mais possível, os números nas versões têm aumentado ao longo dos anos, e os artigos com 'receitas' para versões antigas já não funcionam, enquanto novos quase não aparecem… Mas estou me desviando do assunto...

Então, o que é um honeypot em poucas palavras — é um isco, no nosso caso, uma porta popular no IP externo, qualquer solicitação para essa porta de um cliente externo coloca o endereço de origem na lista negra. É isso.

/ip firewall filter
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" 
    connection-state=new dst-port=22,3389,8291 in-interface=
    ether4-wan protocol=tcp
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment=
    "block honeypot asterisk" connection-state=new dst-port=5060 
    in-interface=ether4-wan protocol=udp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
    "Honeypot Hacker"

A primeira regra em portas TCP populares 22, 3389, 8291 da interface externa ether4-wan envia o IP do 'visitante' para a lista 'Honeypot Hacker' (as portas para ssh, rdp e winbox foram previamente desativadas ou alteradas para outras). A segunda regra faz o mesmo para a popular porta UDP 5060.

A terceira regra, na fase de pré-roteamento, descarta pacotes dos 'visitantes' cujo endereço de origem foi para a lista 'Honeypot Hacker'.

Após duas semanas de funcionamento do meu Mikrotik doméstico, a lista 'Honeypot Hacker' já contava com cerca de mil e quinhentos endereços IP de pessoas que adoram 'testar' meus recursos de rede (em casa tenho minha telefonia, e-mail, Nextcloud, RDP). Os ataques de força bruta cessaram, e chegou a paz.

No trabalho, as coisas não foram tão simples; lá, o servidor RDP continua sendo atacado por meio de tentativas de força bruta.

Parece que o número da porta foi determinado pelo scanner muito antes de ativar o honeypot, e durante a quarentena não é tão fácil reconfigurar mais de 100 usuários, dos quais 20% têm mais de 65 anos. Caso a porta não possa ser alterada, existe uma pequena receita funcional. Já vi algo semelhante na internet, mas aqui temos ajustes e uma configuração fina:

Regras para configurar Port Knocking

 /ip firewall filter
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=15m chain=forward comment=rdp_to_blacklist 
    connection-state=new dst-port=3389 protocol=tcp src-address-list=
    rdp_stage12
add action=add-src-to-address-list address-list=rdp_stage12 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage11
add action=add-src-to-address-list address-list=rdp_stage11 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage10
add action=add-src-to-address-list address-list=rdp_stage10 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage9
add action=add-src-to-address-list address-list=rdp_stage9 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage8
add action=add-src-to-address-list address-list=rdp_stage8 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage7 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage6
add action=add-src-to-address-list address-list=rdp_stage6 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
rdp_blacklist

Em 4 minutos, ao cliente remoto é permitido fazer apenas 12 novos 'pedidos' ao RDP servidor. Uma tentativa de entrada conta como de 1 a 4 'pedidos'. No 12º 'pedido', a conta é bloqueada por 15 minutos. No meu caso, os invasores não pararam de atacar o servidor, ajustaram-se aos temporizadores e agora fazem isso muito lentamente, essa velocidade de tentativa reduz a eficácia do ataque a zero. Os funcionários da empresa praticamente não sentem nenhum desconforto nas operações devido às medidas adotadas.

Mais uma pequena dica
Essa regra é ativada programaticamente à 1 da manhã e desativada às 5, quando pessoas reais estão definitivamente dormindo, enquanto os buscadores automatizados continuam acordados.

/ip firewall filter 
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=1w0d0h0m chain=forward comment=
    "night_rdp_blacklist" connection-state=new disabled=
    yes dst-port=3389 protocol=tcp src-address-list=rdp_stage8

Já na 8ª conexão, o IP do invasor é enviado para a lista negra por uma semana. Maravilha!

E para adicionar ao que foi dito, deixo um link para um artigo da Wiki, com uma configuração funcional de proteção do Mikrotik contra scanners de rede. wiki.mikrotik.com/wiki/Drop_port_scanners

Nos meus dispositivos, essa configuração funciona em conjunto com as regras de honeypot descritas acima, complementando-as bem.

UPD: Como foi sugerido nos comentários, a regra de bloqueio de pacotes foi movida para RAW, para reduzir a carga no roteador.

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster