Uma maneira fácil de proteger seu Mikrotik de ataques

Quero compartilhar com a comunidade uma maneira simples e funcional de como usar o Mikrotik para proteger sua rede e os serviços que “espreitam” por trás dela contra ataques externos. Ou seja, apenas três regras para organizar um honeypot no Mikrotik.

Então, vamos imaginar que temos um pequeno escritório, com um IP externo atrás do qual existe um servidor RDP para os funcionários trabalharem remotamente. A primeira regra é, claro, mudar a porta 3389 da interface externa para outra. Mas isso não durará muito; depois de alguns dias, o log de auditoria do servidor de terminal começará a mostrar várias autorizações com falha por segundo de clientes desconhecidos.

Outra situação, você tem um asterisco escondido atrás do Mikrotik, claro que não na porta 5060 udp, e depois de alguns dias a busca por senha também começa... sim, sim, eu sei, fail2ban é tudo para nós, mas ainda temos que trabalhe nisso ... por exemplo, eu instalei recentemente no ubuntu 18.04 e fiquei surpreso ao descobrir que o fail2ban pronto para uso não contém configurações atuais para o asterisk da mesma caixa da mesma distribuição do ubuntu ... e pesquisando configurações rápidas no Google de “receitas” prontas não funciona mais, os números de lançamentos crescem ao longo dos anos, e artigos com “receitas” de versões antigas não funcionam mais, e quase nunca aparecem novos... Mas estou divagando...

Então, em poucas palavras, o que é um honeypot - é um honeypot, no nosso caso, qualquer porta popular em um IP externo, qualquer solicitação de um cliente externo para essa porta envia o endereço src para a lista negra. Todos.

/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 nas portas TCP populares 22, 3389, 8291 da interface externa ether4-wan envia o IP “convidado” para a lista “Honeypot Hacker” (as portas para ssh, rdp e winbox são desabilitadas antecipadamente ou alteradas para outras). O segundo faz o mesmo no popular UDP 5060.

A terceira regra no estágio de pré-roteamento descarta pacotes de “convidados” cujo endereço srs está incluído no “Honeypot Hacker”.

Depois de duas semanas trabalhando com meu Mikrotik doméstico, a lista “Honeypot Hacker” incluía cerca de mil e quinhentos endereços IP de quem gosta de “segurar pelo úbere” meus recursos de rede (em casa tem minha própria telefonia, correio, nextcloud, rdp) Os ataques de força bruta pararam, a felicidade veio.

No trabalho nem tudo acabou sendo tão simples, lá eles continuam quebrando o servidor RDP com força bruta de senhas.

Aparentemente, o número da porta foi determinado pelo scanner muito antes de o honeypot ser ligado 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 de trabalho. Já vi algo semelhante na Internet, mas há algumas adições e ajustes adicionais envolvidos:

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, o cliente remoto pode fazer apenas 12 novas “solicitações” ao servidor RDP. Uma tentativa de login é de 1 a 4 “solicitações”. Na 12ª “solicitação” - bloqueio por 15 minutos. No meu caso, os invasores não pararam de hackear o servidor, ajustaram-se aos temporizadores e agora fazem isso muito lentamente, tal velocidade de seleção reduz a eficácia do ataque a zero. Os funcionários da empresa praticamente não sentem nenhum incômodo no trabalho com as medidas tomadas.

Outro pequeno truque
Essa regra é ativada de acordo com uma programação à 5h e desligada às XNUMXh, quando pessoas reais estão definitivamente dormindo e os selecionadores 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 fica na lista negra por uma semana. Beleza!

Bem, além do acima, adicionarei um link para um artigo do Wiki com uma configuração funcional para proteger o Mikrotik de scanners de rede. wiki.mikrotik.com/wiki/Drop_port_scanners

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

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

Fonte: habr.com

Adicionar um comentário