1

Recently I have been suffering from what appears to be a UDP query flood attack. I am looking for a way to block the attack using a software firewall such as iptables, this should be possible, as explained below. The target of the attack is a GTA San Andreas Multiplayer (SA-MP) server running on port 7777. By flooding the server with queries (that would be used to determine how many players the server has online etc), the attackers are able to cause a denial of service for the server's genuine users.

I am hosting this server on an OVH Dedicated Server that includes their "Anti-DDoS Game" protection. They do not detect this particular attack. Given that this is a low bandwidth attack which targets a flaw in the SA-MP server software, I believe that it should be possible to block the attack using a software firewall such as iptables.

My server is running on Ubuntu 14.04 x64.

The attack has no impact upon the network or the availability of other services on the host machine, it only effects the availability of the SA-MP server. The SA-MP server's CPU usage is not effected by the attack.

Please note that the destination address in the following pcap files has been changed to 50.0.0.0. Assume that the SA-MP server is running on 50.0.0.0:7777. The files only show traffic destined for 50.0.0.0:7777.

The following pcap file was created during an attack: https://www.dropbox.com/s/5729k6vonqop7vh/attack.pcap

Corresponding anonymized iptables logs:

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

The following pcap file shows normal traffic: https://www.dropbox.com/s/dc05y54sru0c57u/normal.pcap

Observations

  • The malicious UDP packets are of length 19 and contain the string "SAMP3"
  • Normal packets can be of length 19 however they do not contain "SAMP3"
  • The malicious packets all originate from 177.0.0.0/8

I have null routed 177.0.0.0/8 without success. This solution would be unfeasible in any case, as it would potentially deny access to real users.

The following attempt at limiting the number of accepted packets was unsuccessful. The rules either do not work or result in a denial of service.

#!/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

Also unsuccessful:

#!/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 would be replaced by the server's IPv4 WAN address.

If you could provide any insight into how the traffic could possibly be dropped, that would be greatly appreciated. I have very limited experience with traffic analysis. I would be willing to use software other than iptables if recommended.

It is not possible to implement an application layer solution as the server's source code is not available.

Thanks in advance.

Bill Boverhaven
  • 11
  • 1
  • 2
  • If it is all from the same /8, but blocking all traffic from there did not relieve the DoS, something else is going on you haven't mentioned or noticed. Check what traffic is going after you block this. – Falcon Momot Sep 07 '15 at 00:20
  • @FalconMomot Thanks for your reply. Interestingly enough, "ip route add blackhole 177.0.0.0/8" and "iptables -A INPUT -p udp -s 177.0.0.0/8 -d *dest ip* --destination-port 7777 -j DROP" do not appear to block the attack. Blocking all UDP traffic destined for *dest ip* using OVH's firewall does work. This completely prevents the traffic from reaching the dedicated server. I am aware that the packets will still be shown in tcpdump when dropping them using iptables however it is strange that they still reach the SA-MP server process. I use iptables v1.4.21 on Ubuntu 14.04. – Bill Boverhaven Sep 07 '15 at 01:27

2 Answers2

1

You're dealing with SA-MP query flood, this is a known problem in the SA-MP community and there are pretty much no methods to stop this, there has been an update I'm sure you're familiar with it already. However there's been recent attacks based on the same flood method but with spoofed source addresses, which has yet to be addressed by the developers. There is a fix for this made by a user but they will not release the source code.

peterh
  • 4,914
  • 13
  • 29
  • 44
sa-mp user
  • 11
  • 1
-1

The first thing to understand about DDoS attack is that if it reachs your server it is too late to do anything. Please make sure you read this post as it will give you a better idea what you up against.

As a practical recommendation I would suggest checking services offered by CloudFlare and Incapsula. Depending on your traffic you may qualify for free tier and if not it is a good starting point.

UPDATE: Sorry I missed part that this is not a web site but an application that uses UDP. First of all according to latest reports online gaming sites are nowadays are the primary target for DDoS attacks. The purpose is ransom, so if your application generates any revenue then you will likely need to talk to big guys like Akamai, Verisign, F5, etc. They have packages specifically designed for protecting gaming sites, but they ain't cheap.

Community
  • 1
dtoubelis
  • 4,579
  • 1
  • 28
  • 31
  • You are right, I missed the UDP part. I'm updating my answer. – dtoubelis Sep 06 '15 at 23:16
  • If the attach is small, then another alternative could be just to beef up your server if necessary and ignore it. – dtoubelis Sep 06 '15 at 23:30
  • Hello, thank you for your replies. As this attack does not involve a significant amount of bandwidth, but instead targets a flaw in the SA-MP server software, I believe that it should be possible to drop the malicious traffic at the firewall layer. I have used services such as CloudFlare for my websites, however they do not offer protection against attacks such as this. Please note that the dedicated server is protected by OVH's "Anti-DDoS Game" which is very effective at mitigating high bandwidth attacks. This particular attack however, reaches our dedicated server. – Bill Boverhaven Sep 06 '15 at 23:30