Em 04/03/2021 eu decidi migrar o SparklyPower para a ReliableSite. Antes eu estava usando um GAME-1 da OVH, mas queria migrar porque...

  • O dedicado estava ficando sem memória disponível, já que servidores de Minecraft usam bastante memória.
  • A ReliableSite tem dedicados com specs melhores que o GAME-1 da OVH que eu tinha.
  • A ReliableSite tem datacenters em Miami com uma latência para o Brasil bem melhor que a OVH.

Eu já tinha usado a ReliableSite no passado e eu não tive nenhum problema com ela, tanto que o único motivo de eu ter saido de lá e ter migrado para a SoYouStart foi porque a Loritta usava muita banda de rede (já que ela tinha sistema de música e streaming usa muita banda!) e a ReliableSite tem limite de banda (uns 150TBs, depois disso eles diminuem a velocidade da sua rede).

Então eu comprei um dedicado na ReliableSite no datacenter em Miami, e tudo chegou direitinho!

...mas se tudo tivesse dado certo eu não estaria escrevendo este post, né?

O primeiro problema que eu tive foi instalar o Proxmox, eu já instalei o Proxmox em máquinas virtuais antes e o processo é super fácil, eu pensei que seria também fácil instalar o Proxmox no dedicado da ReliableSite!

...mas toda hora que eu tentava logar no controle do dedicado via IPMI falava que as credenciais estavam incorretas, mas como pode estar incorreto se eu estou usando as mesmas credenciais que estão no painel da ReliableSite?

Resolveram isso após eu criar um ticket na ReliableSite, uma vantagem da ReliableSite é que o suporte deles é excepcional e respondem os tickets rapidamente.

E agora é hora de instalar o Proxmox! ...ah, não tenho acesso ao KVM over IP...

E lá vai outro pedido de suporte para resolverem o problema, que felizmente arrumaram, yay!

E agora é finalmente a hora de instalar o Proxmox! ...ah, não dá para fazer upload da ISO do Proxmox pois ele sempre trava em ~1050Kb enviados. Eu fui fazer engenharia reversa para ver como funciona o upload da ISO e eles usam um WebSocket para enviar a ISO, o que para mim é muito estranho já que HTTP suporta upload de arquivos.

Eu pensava que isso poderia ser problema da minha rede, mas não, eu tentei enviar a ISO diretamente de um dos meus dedicados que estão na OVH e deu o mesmo problema.

Eu não colocaria a culpa na ReliableSite desse problema porque o KVM over IP da Supermicro é usado por várias outras empresas, provavelmente é apenas culpa da Supermicro e não da ReliableSite. Mas mesmo assim eu preciso instalar o Proxmox na máquina para começar a usar ela!

Eles resolveram instalar o Proxmox para mim já que eu não estava conseguindo (eu apenas tinha pedido para montar a ISO na máquina para eu mesmo instalar, mas eles decidiram instalar eles mesmo), e depois de muito tempo, tudo deu certo, yay!

Mas logo no primeiro dia deu um problema que, por alguns segundos, o servidor estava offline e todos que estavam conectados no SparklyPower cairam do servidor também. Eu relevei isso pois achei que era apenas algum erro raro de rede que aconteceu...

...mas aí aconteceu de novo, e de novo, e de novo...

Aí eu decidi investigar e deixei duas máquinas (o meu PC e um dos meus dedicados na OVH) sempre pingando a máquina da ReliableSite para mostrar o problema. E foi o que aconteceu, do nada o ping mostrava que deu timeout e todos que estavam conectados no SparklyPower cairam e qualquer coisa hospedada na máquina não conseguia conectar para coisas hospedadas fora da máquina. E aí eu abri um ticket na ReliableSite falando sobre isso.

E aí falaram que era um Ataque DDoS.

Tá... hmmm, okay. Um Ataque DDoS. Vivemos em 2021, eu sei que ataques DDoS acontecem sempre devido a script kiddies querendo chamar atenção. Mas não era para o Anti-DDoS da ReliableSite mitigar ataques DDoS? Até nesse ponto o único Anti-DDoS que eu já usei foi o da OVH/SoYouStart que, enquanto as vezes causava instabilidades na Loritta fazendo requests ao Discord darem timeout, nunca foi ao ponto de tudo do dedicado ficar inacessível, até conexões SSH.

Eles recomendaram que eu bloqueasse o tráfego malicioso usando firewall na máquina (no meu caso, o bom e velho iptables).

Se você entende de redes você já deve ter parado para pensar: Como iptables vai bloquear um Ataque DDoS? Sim, iptables pode ajudar a bloquear um Ataque DDoS Layer 7, por exemplo: Se o seu servidor de Minecraft está caindo pois alguém está fazendo um Bot Attack no seu BungeeCord fazendo todos cairem do servidor, isso é um ataque Layer 7. Ataques Layer 7 normalmente não afetam toda a rede da máquina e sim apenas aplicações específicas no seu dedicado. E aí iptables pode ajudar fazendo throttle de packets ou até mesmo você colocando para que esses IPs maliciosos sejam apenas ignorados.

Mas mesmo assim fui seguir o conselho da equipe de suporte da ReliableSite, afinal, já estou no fundo do poço mesmo então nada melhor que seguir a sugestão. Eles sugeriram para eu colocar todas as regras que eles recomendam no meu iptables... até você perceber que várias das regras que eles sugerem são inúteis ou não ajudam.

  • Tem regras que bloqueiam vários pacotes mal formados ou pacotes inválidos, mas o kernel do Linux já faz isso!
  • Recomendam bloquear ICMP ping, ou seja, se você gosta de ficar dando ping no seu servidor para ver a latência, diga adeus para isso!
  • Recomendam limitar o número máximos de conexões por IP, isso realmente ajuda para evitar ataques Layer 7.
  • E outras regras não tão relevantes que servem mais para coisas específicas, como evitar brute-force de SSH e port scanning.

Mas aí que está, nada disso resolve um Ataque DDoS que não seja Layer 7! Não iria resolver nada para mim as sugestões deles, mas mesmo assim eu fiz. Vai se eles sabem de algo que eu não sei...

...e é claro, isso não resolveu.

Eu acabei percebendo que o Anti-DDoS da ReliableSite também acabava filtrando tráfegos legítimos da rede, tinha vezes que o Anti-DDoS da ReliableSite ativava ele bloqueava pacotes da minha rede VXLAN (que usa UDP), então se alguma coisa de outro dedicado meu precisava acessar algo que estava no meu dedicado da ReliableSite durante um ataque... bem, não funcionava. E não tem nenhum jeito de poder indicar "olha, qualquer pacote indo para a porta XYZ usando o protocolo UDP é tráfego legítimo, ok?" na ReliableSite. Até a SoYouStart (que é o ramo de dedicados baratos da OVH) tem isso na rama de dedicados para servidores de jogos deles!

Eles pediram para eu fazer um pcap pelo tcpdump para poderem analisar qual é o problema, então depois de muitas tentativas (tive que conectar via KVM over IP para fazer o dump, já que toda hora que atacavam a minha conexão SSH caia) eu consegui fazer um pcap dump e enviei para eles...

...e aí eles reclamaram que o arquivo do pcap era muito grande (era uns 20GBs).

Bem, é claro que é grande, é um ataque DDoS então é óbvio que vai ter vários pacotes sendo recebidos!

Mas eu entendo, eles querem um arquivo menor para que seja mais fácil de analisarem o que é relacionado ao ataque, então eu fiz um pcap menor, pegando um tempo menor de apenas 5 segundos para poderem analisarem... e aí eles conseguiram analisar e recomendaram colocar essa regra no iptables

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Fiquei aliviado! Achei que finalmente iria resolver o problema de Ataques DDoS no meu dedicado, finalmente poderia voltar a fazer coisas para o SparklyPower sem me preocupar que um ataque poderia derrubar o servidor!

...e eu estava errado, isso não resolveu em nada e os ataques se tornaram algo rotineiro no servidor.

Eu pedi suporte mais uma vez, mostrei logs do tcpdump mostrando que era um ataque usando ICMP... Lembra que sugeriram bloquear pacotes ICMP para evitar Ataques DDoS? Então né, acho que não resolveu em nada.

E o pior de tudo: Esses ataques não estão nem sendo detectados pelo Anti-DDoS da ReliableSite! Antes pelo ou menos estava sendo detectado (mesmo que resolvesse em quase nada) mas agora nem isso o Anti-DDoS está fazendo!

23:00:04.413331 IP 63.225.126.70 > 103.195.102.131: ICMP net 216.160.133.111 unreachable, length 36
23:00:04.414979 IP 181.40.119.145 > 103.195.102.131: ICMP time exceeded in-transit, length 36
23:00:04.420950 IP 204.10.64.130 > 103.195.102.131: ICMP host 208.77.54.84 unreachable, length 68
23:00:04.421037 IP 210.236.41.115 > 103.195.102.131: ICMP host 210.236.41.115 unreachable - admin prohibited, length 52
23:00:04.422965 IP 119.46.11.2 > 103.195.102.131: ICMP time exceeded in-transit, length 36
23:00:04.423670 IP 183.47.2.157 > 103.195.102.131: ICMP 183.47.2.157 tcp port 27518 unreachable, length 68
23:00:04.424894 IP 217.81.21.208 > 103.195.102.131: ICMP host 217.81.21.208 unreachable - admin prohibited filter, length 36
23:00:04.425418 IP 176.98.115.2 > 103.195.102.131: ICMP time exceeded in-transit, length 36
23:00:04.426123 IP 46.219.80.156 > 103.195.102.131: ICMP host 46.219.80.156 unreachable - admin prohibited filter, length 36
23:00:04.431082 IP 96.247.198.104 > 103.195.102.131: ICMP host 96.247.198.104 unreachable - admin prohibited filter, length 36
23:00:04.431602 IP 98.198.133.52 > 103.195.102.131: ICMP 98.198.133.52 tcp port 30946 unreachable, length 36
23:00:04.432507 IP 199.127.60.62.17500 > 255.255.255.255.17500: UDP, length 132
23:00:04.433678 IP 158.165.7.160 > 103.195.102.131: ICMP net 158.165.179.37 unreachable, length 52
23:00:04.436938 IP 38.122.101.130 > 103.195.102.131: ICMP host 64.90.100.121 unreachable, length 68

E vários outros logs similares durante o ataque. Pensei que talvez poderiam mexer no Anti-DDoS deles para conseguir resolver o problema, já que parece que era apenas um ataque usando ICMP.

Enquanto isso eu fui perguntar no Bot Managers (servidor super secreto para quem tem um bot grande) e no PaperMC (servidor de suporte do Paper, mesmo que não seja muito relevante) se alguém tinha alguma alternativa (como o TCPShield) para eu conseguir resolver o problema, e o que me impressionou é que outras pessoas também tiveram problemas com o Anti-DDoS da ReliableSite e até mesmo com a rede da ReliableSite!

E aí você já fica com aquele pensamento na cabeça "será que eu deveria voltar para a OVH, mesmo que tenha specs piores e latência maior?"...

Eu poderia tentar colocar o TCPShield para filtrar o tráfego, mas e a latência? Não vai ser vantajoso se aumentar a latência porque, se aumentar, vai ficar com a mesma latência que eu tenho com dedicados na OVH em BHS!

Mas não se preocupem, o suporte da ReliableSite respondeu o ticket! Hora de dar adeus a dor de cabeça pois eles vão saber como arrumar isso!

Bem... se eles desistiram, quem sou eu para ficar tentando então? Back to OVH we go bois. Eu iria comprar um dedicado nos novos datacenters da OVH (Virginia) mas fui com o bom e velho datacenter de Beauharnois pois eles tinham dedicados com 128GBs de RAM e 2TB HDD.

A ReliableSite pode ser tentadora para quem mora no Brasil, já que eles tem datacenters em Miami (o que dá uma latência bem baixa para quem mora no Brasil!), specs boas, um preço acessível, são ativos no SpigotMC e um suporte que te ajuda bastante...

...mas se você vai hospedar algo público, não use. Você terá muita dor de cabeça com Ataques DDoS que serão impossíveis de resolver.

Meme humor e piadas feito pelo ZumZumZum após eu ter explicado porque o SparklyPower vivia caindo