Versão Imprimível
Olá amigos.
Hoje pela manhã peguei um problema na rede,com certa lentidão.Onde no Mikrotik apresentava com algumas regras de agendamentos,redirecionamento e etc.
Segue link onde tirei mais informações.
sysadminpxy mikrotik
http://www.leandrocosta.pro.br/index...s-sysadminpxy/
Peguei um aqui assim também. Alguém sabe qual a vulnerabilidade permite essas alterações?
Aqui, o único serviço habilitado era o SSH e não estava com a porta padrão.
Estranho que não encontrei resultados no Google sobre tal invasão, será este algo novo? Recentemente estou tendo problemas com tentativas de ataques a RBs, mas é o primeiro do tipo que vejo... No log o scheduler foi removido sozinho, não consegui tirar print para estudar o caso. No entanto, encontrei um arquivo html contendo script para "mining" de BTC
Tive esse problema em algumas rbs. Descobri no fórum oficial ontem . O problema começou no começo da noite de anteontem.
https://forum.mikrotik.com/viewtopic.php?t=137217
Atualizei o routeros e o firmware.
Removi os scripts e agendamentos.
Desabilitei o /IP socks que o ataque ativou.
Mudei a senha.
Ainda estamos estudando mais opções de segurança de acesso a RB.
Alguém que usa as regras de bloqueio de Scan de portas e regras de port knock?
Realmente ultimamente estamos percebendo uma grande quantidade de pedidos de autenticação nas nossas RB´s oriundas de link´s com IP fixos, o que fizemos foi atualizar todas as RB´s para a ultima versão, fechar todas as portas, telnet, ssh, ftp, https, http mantivemos apenas a API e a winbox mas mudamos a porta para uma numeração fora do padrão.
Também adicionamos estas regras abaixo:
/ip firewall filter add action=passthrough chain=unused-hs-chain comment=\
"place hotspot rules here" disabled=yes
/ip firewall filter add action=drop chain=input comment="DROP SSH FORCA BRUTA ( BLACK LIST )" \
disabled=no dst-port=22 protocol=tcp src-address-list=ssh_blacklist
/ip firewall filter add action=add-src-to-address-list address-list=ssh_blacklist \
address-list-timeout=4w2d chain=input comment="" connection-state=new \
disabled=no dst-port=22 protocol=tcp src-address-list=ssh_stage3
/ip firewall filter add action=add-src-to-address-list address-list=ssh_stage3 \
address-list-timeout=10m chain=input comment="" connection-state=new \
disabled=no dst-port=22 protocol=tcp src-address-list=ssh_stage2
/ip firewall filter add action=add-src-to-address-list address-list=ssh_stage2 \
address-list-timeout=10m chain=input comment="" connection-state=new \
disabled=no dst-port=22 protocol=tcp src-address-list=ssh_stage1
/ip firewall filter add action=add-src-to-address-list address-list=ssh_stage1 \
address-list-timeout=10m chain=input comment="" connection-state=new \
disabled=no dst-port=22 protocol=tcp
/ip firewall filter add action=drop chain=input comment="BLOQUEIO SSH - PORTA 22-23" disabled=no \
dst-port=22-23 protocol=tcp
com isso sessou o problema.
Talvez esse não seja o método ideal porem no meu caso resolveu, se alguém tiver sugestões são muito bem vindas.
Invadiram uma RB 750 na rede de um cliente e encontrei algumas alterações feitas na RB.
As que eu encontrei sao:
Um novo usuário por nome ftpuser (algo parecido com isso)
E criou um grupo com nome nome hftpgrp (algo parecido com isso).
Encontrei uma regra no NAT direcionando tudo para a porta 8080.
Foi habilitado o web proxy também pela porta 8080.
Pelo que eu vi nos logs da RB, o invasor consegue acesso por FTP (todas as tentativas de acesso que encontrei foram via ftp).
Isso são algumas das coisas que eu encontrei de alterações.
Detalhe adicional: RBs mais fracas (750he no caso da que eu vi) o consumo crava em 100% e não abaixa.
Desativei todos os serviços sem uso, e os que foram necessário manter ativos, especifiquei os ips que podem ter acesso através daquele serviço e bloqueei todos os acessos externos.
Dessa forma a CPU voltou a ficar com consumo entre 6 e 15 %.
Também recomendo trocar todas as senhas de todos os usuários da RB, pois o invasor pode ter visto as senhas.
Espero ter ajudado.
Pelo que vi , foram muitas rbs invadidas . É um tipo novo de ataque ? Alguma ideia de qual o objetivo ? Aqui mudou algumas coisas , não chegou a cair tudo , mais deu zica tbm
Pelo que eu entendi com as configurações que são criadas, aparentemente é para roubo de dados que passam pela RB.
Ele fica coletando todos dados através do redirecionamento para o web proxy... Acho que depois ele baixa os arquivos salvos... Fique atento no log... No meu caso não chegaram a fazer download... Percebi por causa do consumo da RB estourando... Mais aparentemente a intenção é coletar os dados que passam pela RB.
Sofremos o mesmo tipo de ataque mas foi bem simples de resolver só remover as configurações atualizar o RouterOs recomendo a de bugfix e sempre estar olhando os changelogs para ver se não tem nenhuma vulnerabilidade, desativar as portas que voce nao utiliza, e bloquear acesso externo da rede nos servicos que voce deixou
Segue mensagem enviada pela Mikrotik
Olá,
Chegou ao nosso conhecimento que um botnet desonestos está usando uma vulnerabilidade no serviço RouterOS Winbox, que foi corrigida em RouterOS v6.42.1 em 23 de abril de 2018.
Uma vez que todos os dispositivos RouterOS oferecer atualizações gratuitas com apenas dois cliques, recomendamos que você atualize seus dispositivos com o "Check for updates" botão, se você não tiver feito isso.
Medidas a serem tomadas:
- Atualize RouterOS para a última versão
- Alterar a senha após a atualização
- Restaurar sua configuração e inspecioná-lo para as configurações de desconhecidos
- Implementar um bom firewall de acordo com o artigo aqui:
https://wiki.mikrotik.com/wiki/Manua...ng_Your_Router
Todas as versões de 6,29 (data de lançamento: 2015/28/05) para 6,42 (data 2018/04/20 liberação) são vulneráveis. É o dispositivo afetado? Se você tiver acesso Winbox aberto a redes não confiáveis e está executando uma das versões afetadas: sim, você poderia ser afetado. Siga os conselhos acima. Se Winbox não está disponível para a internet, você pode ser seguro, mas atualizar ainda recomendado.
Mais informações sobre o assunto podem ser encontradas aqui: https://blog.mikrotik.com
Cumprimentos,
MikroTik
-
A fim de manter e melhorar nossas relações de negócios, produtos e serviços de abastecimento, percebendo o nosso interesse legítimo (como benefícios comerciais) para processar dados pessoais sem consentimento, desde que ele não está com sobrepeso pelos efeitos negativos sobre os seus direitos e liberdades, MikroTik enviou até agora você informações relacionadas com a nossa actividade, e esperamos que você vai continuar a estar interessado em receber esse tipo de mensagens informativas. Nós enviá-los para informar os nossos clientes e parceiros sobre MikroTik notícias, mudanças e melhorias em produtos e software MikroTik que possam ser relevantes para você para cumprir os requisitos essenciais de vendas de produtos e uso, informações sobre seminários de formação MikroTik e eventos MUM, bem como outra informação.
Cancelar a inscrição nesta lista, por favor siga o link:
https://mikrotik.com/unsubscribe/NL4...Zlcy5jb20uYnI=
Script para remover o virus CoinHive do Mikrotik
https://under-linux.org/showthread.php?t=190156
Pessoal, depois da routerboard invadida tentei atualizar e não esta deixando, ao rebootar ela volta na mesma versão que tava,não aceita downgrade também. alguém mais passa por isso?
Eu já passei por isso, a solução foi utilizar o Netinstall.
Olha o log que o problema é outro, nada a ver com o sysadminproxy. Mas realmente, só via Netinstall pra resolver, já passei por isso.
Citação:
Postado originalmente por avatar52
Então, não apresenta log, mas foi logo após a invasão, pelo menos as que peguei invadidas, depois de reseta-las não atualizam.
Ela dá um erro sim, a primeira linha de log. Isso aí é falta de espaço no disco, só resolvi com Netinstall mesmo.