Dos Flood do UDP do Firewall / DDoS

Question

Recentemente, tenho sofrido o que parece ser um ataque de inundação de consulta UDP. Eu estou procurando uma maneira de bloquear o ataque usando um firewall de software como iptables, isso deve ser possível, como explicado abaixo. O alvo do ataque é um servidor GTA San Andreas Multiplayer (SA-MP) rodando na porta 7777. Ao inundar o servidor com consultas (que seriam usadas para determinar quantos jogadores o servidor tem on-line, etc.), os atacantes podem causar uma negação de serviço para os usuários genuínos do servidor.

Estou hospedando este servidor em um Servidor Dedicado OVH que inclui a proteção "Anti-DDoS Game". Eles não detectam esse ataque em particular. Dado que este é um ataque de baixa largura de banda que tem como alvo uma falha no software do servidor SA-MP, acredito que seja possível bloquear o ataque usando um firewall de software como o iptables.

Meu servidor está executando no Ubuntu 14.04 x64.

O ataque não tem impacto sobre a rede ou a disponibilidade de outros serviços na máquina host, apenas afeta a disponibilidade do servidor SA-MP. O uso da CPU do servidor SA-MP não é afetado pelo ataque.

Por favor, note que o endereço de destino nos seguintes arquivos pcap foi alterado para 50.0.0.0. Suponha que o servidor SA-MP esteja executando em 50.0.0.0:7777. Os arquivos mostram apenas o tráfego destinado a 50.0.0.0:7777.

O seguinte arquivo pcap foi criado durante um ataque: link

Correspondência de logs iptables anônimos:

Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.236.34.109 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=37535 PROTO=UDP SPT=10365 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.228.244.109 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=56141 PROTO=UDP SPT=26757 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.9.122.145 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=28986 PROTO=UDP SPT=34861 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.12.137.119 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=112 ID=48843 PROTO=UDP SPT=26837 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.41.70.162 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=45760 PROTO=UDP SPT=51292 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.12.97.62 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=33629 PROTO=UDP SPT=16468 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.245.87.139 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=61928 PROTO=UDP SPT=41088 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.203.14.22 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=27207 PROTO=UDP SPT=57344 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.225.52.188 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=111 ID=13336 PROTO=UDP SPT=43057 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.82.59.154 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=106 ID=56663 PROTO=UDP SPT=59536 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.40.3.89 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=106 ID=51704 PROTO=UDP SPT=57477 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.104.10.111 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=46872 PROTO=UDP SPT=51380 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.4.49.184 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=30226 PROTO=UDP SPT=16636 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.38.178.54 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=4646 PROTO=UDP SPT=35017 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.139.77.54 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=23920 PROTO=UDP SPT=57421 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.104.123.34 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=52328 PROTO=UDP SPT=34833 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.179.166.24 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=112 ID=12342 PROTO=UDP SPT=10357 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.75.214.181 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=51967 PROTO=UDP SPT=8220 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.99.5.153 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=32396 PROTO=UDP SPT=51236 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.95.125.95 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=106 ID=23852 PROTO=UDP SPT=16509 DPT=7777 LEN=19
Sep  6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.138.137.71 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=64385 PROTO=UDP SPT=43176 DPT=7777 LEN=19

O arquivo pcap a seguir mostra o tráfego normal: link

Observações

• Os pacotes UDP mal-intencionados têm comprimento 19 e contêm a string "SAMP3"
• Os pacotes normais podem ter tamanho 19, mas não contêm "SAMP3"
• Todos os pacotes maliciosos são originários de 177.0.0.0/8

Eu tenho null roteado 177.0.0.0/8 sem sucesso. Essa solução seria inviável em qualquer caso, já que potencialmente negaria o acesso a usuários reais.

A seguinte tentativa de limitar o número de pacotes aceitos foi mal-sucedida . As regras não funcionam ou resultam em uma negação de serviço.

#!/bin/bash

iptables -F
iptables -A INPUT -p udp -d 50.0.0.0 --destination-port 7777 -m string --string 'SAMP3' --algo bm -m limit --limit 100/s -j ACCEPT
iptables -A INPUT -p udp -d 50.0.0.0 --destination-port 7777 -m string --string 'SAMP3' --algo bm -j DROP

exit 0

Também sem sucesso:

#!/bin/bash

iptables -F
iptables -A INPUT -p udp -d 50.0.0.0 -s 177.0.0.0/8 --destination-port 7777 -j DROP

exit 0

50.0.0.0 seria substituído pelo endereço IPv4 da WAN do servidor.

Se você pudesse fornecer informações sobre como o tráfego poderia ser descartado, isso seria muito apreciado. Eu tenho uma experiência muito limitada com análise de tráfego. Eu estaria disposto a usar outro software além do iptables, se recomendado.

Não é possível implementar uma solução de camada de aplicativo, pois o código-fonte do servidor não está disponível.

Obrigado antecipadamente.

    

Answer 1

Você está lidando com a sobrecarga da consulta SA-MP, esse é um problema conhecido na comunidade SA-MP e praticamente não há métodos para parar isso, houve uma atualização que tenho certeza de que você está familiarizado já. No entanto, houve ataques recentes com base no mesmo método de flood, mas com endereços de origem falsificados, que ainda precisam ser resolvidos pelos desenvolvedores. Há uma correção para isso feita por um usuário, mas ele não libera o código-fonte.

    

Answer 2

A primeira coisa a entender sobre o ataque DDoS é que, se chegar ao seu servidor, é tarde demais para fazer qualquer coisa. Certifique-se de ler este post como lhe dará uma idéia melhor do que você.

Como uma recomendação prática, sugiro verificar os serviços oferecidos por CloudFlare e Incapsula . Dependendo do seu tráfego, você pode se qualificar para o nível gratuito e, se não, é um bom ponto de partida.

UPDATE: Desculpe eu perdi parte que este não é um site, mas um aplicativo que usa UDP. Em primeiro lugar, de acordo com os últimos relatórios, os sites de jogos online são hoje em dia os principais alvos de ataques DDoS. O objetivo é resgatar, então se seu aplicativo gera alguma receita, então você provavelmente precisará falar com grandes caras como Akamai, Verisign, F5, etc. Eles têm pacotes especificamente projetados para proteger sites de jogos, mas eles não são baratos.