MK AUTH FAZENDO ATAQUE

Nos últimos meses eu estava usando Link da net em minha RB, do nada a rb começava bater mais de 500 Mbps de upload e começava a derrubar a minha rede, eu comecei a desligar os equipamentos para ver se era algum fazendo isso, quando eu exatamente desliguei o servidor Mk auth a rede voltou ao normal, então eu formatei o Mk auth e liguei ele na RB, agora nesse último mês eu contratei um link dedicado com um IP público, nessa última semana já recebi 3 email da minha operadora dizendo que ta sofrendo ataque DDOS e que a origem era no meu IP, e que o ataque era de 544 Mbps e os tamanhos do pacotes é de 1488, desliguei o Mk auth e já parou os ataques. Alguém sabe me dizer o que eu devo fazer pra resolver esse problema com o Mk auth, já formatei ele 3 vezes e depois de alguns dias ele começa a fazer isso novamente

Para adicionar comentários, você deve ser membro de MK-AUTH.

Join MK-AUTH

Enviar-me um email quando as pessoas responderem –

Respostas

  • Bom dia prezado(a),

    Faz um teste, limitando a banda de upload do sistema, para 10mbps, por exemplo.

    Qualquer dúvida, estamos à disposição.

    Atenciosamente,
    Equipe MK-AUTH

  • Mas isso vai parar os ataques ?



    Integração MK-AUTH disse:

    Bom dia prezado(a),

    Faz um teste, limitando a banda de upload do sistema, para 10mbps, por exemplo.

    Qualquer dúvida, estamos à disposição.

    Atenciosamente,
    Equipe MK-AUTH

  • Aqui ta alguns do email que minha Operadora me enviou

    Um endereço IP (45.177.xxx.xx) sob seu controle parece ter atacado um de nossos clientes como parte de uma botnet DDoS coordenada. Analisamos manualmente as capturas desse ataque e não acreditamos que seu endereço IP tenha sido falsificado, com base no número limitado de hosts distintos que nos atacam, na identidade de muitos endereços IP de ataque com os que vimos no passado e nos distribuição aleatória de endereços IP. É possível que esse host seja um dos seguintes, a partir das respostas que outras pessoas nos enviaram: - Um roteador comprometido, como um D-Link em execução com acesso à WAN ativado; uma China Telecom que ainda permite um nome de usuário e senha de administrador padrão; um Netis, com um backdoor interno acessível à Internet (http://blog.trendmicro.com/trendlabs-security-intelligence/netis-ro...); ou um executando uma versão antiga do AirOS com uma interface administrativa vulnerável e exposta - Um dispositivo IPTV vulnerável a comprometimentos (como HTV), diretamente através do firmware padrão ou através de um aplicativo baixado por cavalos de Tróia - Um host comprometido, como um executando uma versão vulnerável do Drupal (por exemplo, usando a vulnerabilidade discutida em https://groups.drupal.org/security/faq-2018-002), WordPress, phpMyAdmin ou zPanel

    - Um DVR comprometido, como um dispositivo da marca "Hikvision" (ref: http://www.coresecurity.com/advisories/hikvision-ip-cameras-multipl...) - Um dispositivo IPMI comprometido, como o fabricado pela Supermicro (possivelmente porque usa a U / P padrão do ADMIN / ADMIN ou porque sua senha foi encontrada através de uma exploração descrita em http://arstechnica.com/security/2014/06 / pelo menos 32000-server-broadcast-admin-passwords-in-the-clear-Advisory-warns /) - Um dispositivo da marca Xerox comprometido - Algum outro dispositivo independente comprometido - Um servidor com uma senha insegura com força bruta, como por meio de SSH ou RDP - Um servidor executando uma instalação incorreta do Hadoop O ataque geral às redes de bots foi de tamanho Nx10Gbps (com tráfego do host e de outros) e causou perda significativa de pacotes para nossos clientes devido à saturação do link externo. Exigia uma operação emergencial de rota nula do nosso lado para mitigar. Ataques como esse geralmente são feitos muito curtos, intencionalmente, para que não sejam tão perceptíveis e escapem a certos sistemas de mitigação automática. Do seu lado, você seria capaz de observar o ataque como uma explosão de tráfego que provavelmente saturou o adaptador de rede do dispositivo de origem por talvez 30 segundos. Como o dispositivo de origem é membro de uma botnet que está sendo usada para muitos ataques, você também verá muitas outras explosões misteriosas de tráfego de saída. Este é um exemplo de tráfego do endereço IP, interpretado pelo utilitário "tcpdump" e capturado pelo nosso roteador durante o ataque. Os endereços IP, protocolos e portas de origem e destino estão incluídos. Os carimbos de data / hora (à esquerda) são UTC. 2020-03-06 17: 42: 16.320649 IP (tos 0x0, ttl 51, id 3184, deslocamento 0, sinalizadores [DF], proto UDP (17), comprimento 1488) 45.177.xxx.xx.53014> 31.186.250.x.20480: UDP, comprimento 1460 0x0000: 4500 05d0 0c70 4000 3311 69c7 2db1 8416 E .... p @ .3.i.-... 0x0010: 1fba fa64 cf16 5000 05bc 04b4 e8ba 4000 ... d..P ....... @. 0x0020: 0000 0000 20bb 4000 0000 0000 0200 5000 ...... @ ....... P. 0x0030: 1fba fa64 0000 0000 0000 0000 e800 4000 ... d ....

    ================================================================

    OUTRO EMAIL

    Caro Sr / Sra, Detectamos abuso no endereço IP 45.177.xxx.xx, que, de acordo com uma pesquisa whois, está na sua rede. Agradecemos se você investigar e tomar as medidas necessárias. As linhas de log são fornecidas abaixo, mas pergunte se você precisa de mais informações. (Se você não é a pessoa correta para entrar em contato sobre isso, aceite nossas desculpas - seu endereço de email foi extraído do registro whois por um processo automatizado. Esse email foi gerado por Fail2Ban.) Nota: O fuso horário local é +0700 (WIB) 11 de março 16:50:43 mail sshd [15225]: pam_unix (sshd: auth): falha na autenticação; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 45.177.xxx.xx user = root 11 de março 16:50:45 mail sshd [15225]: falha na senha do root na porta 45.177.xxx.xx 45382 ssh2 11 de março 16:50:45 mail sshd [15225]: Desconectada recebida da porta 45.177.xxx.xx 45382: 11: Bye Bye [preauth] 11 de março 16:50:45 mail sshd [15225]: Desconectado da porta 45.177.xxx.xx 45382 [preauth] 11 de março 17:03:14 mail sshd [17059]: pam_unix (sshd: auth): falha na autenticação; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 45.177.xxx.xx user = root 11 de março 17:03:16 mail sshd [17059]: falha na senha do root na porta 45.177.xxx.xx da porta 44452 ssh2 11 de março 17:03:16 mail sshd [17059]: Desconectada recebida da porta 45.177.xxx.xx 44452: 11: Bye Bye [preauth] 11 de março 17:03:16 mail sshd [17059]: Desconectado da porta 45.177.xxx.xx 44452 [preauth] 11 de março 17:07:36 mail sshd [17472]: aipo de usuário inválido da porta 45.177.132.22 53970 11 de março 17:07:36 mail sshd [17472]: pam_unix (sshd: auth): falha na autenticação; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 45.177.xxx.xx

    45.177.xxx.xx (É MEU IP)

  • Esse IP é do Mk auth
  • Bom dia!!

    Amigo como esta seu firewall do roteador de borda? se a sua rede não tiver fechada vc vai ter problemas. A boa pratica é vc liberar os serviços que vc utiliza e bloquear todo o resto.

    O Dns da sua rede está sendo resolvido por onde?

  • Meu firewall tá com o nat normal, as portas que estão abertas para o Mk auth são a 22, 80 e 443, e os dns eu uso da minha operadora
This reply was deleted.