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.