Quake 3 is one of those games that has hung around for a very long time. Not only that but its engine has been used as the basis of a ton games since the early 2000s. Id software later released the engine under the GPL and this has made it an even more popular choice for developers. Long story short, this engine isn't going anywhere anytime soon.

Given its popularity, age, and simplicity it wasn't too surprising that folks are finding was to use it in a amplification attacks. It's happened to a few ioQuake3 servers I manage. At first I thought someone was trying to take my machine offline (I've had that happen too) but after some analysis I figured out what was going on. The attacks seem to come and go almost on a seasonal basis and have started cropping up again lately. In light of that I'd thought I'd share the resources I've been using to combat the problem.

Amplification attacks gained popularity in the DNS world. It's a very simple concept. The attacker spoofs their source IP address, makes a request to an unsuspecting server, and the server responds to the spoofed address. The attacker can quickly roll through a bunch of servers and redirect data to the target machine via the spoofed address. This is why it's called an amplification attack, because the attacker can gain much more throughput by combining traffic from several different sources than they could on their own connection.

Every now and again I see people using Quake 3 servers in these attacks. This includes Quake 3 Arena, ioQuake3, older COD games, etc. Anything based off the Quake 3 really. The attack is easy spot because you'll notice a disproportionate amount of traffic outbound on 27960 (or whatever port you're running the server on) compared to what's coming in. It'll jump out like a sore thumb in tcpdump, Wireshark or any other number of traffic monitoring tools. Attackers like using these games because they usually run on a standard port and are easily listed in game browsers. This allows them to dodge the suspicion that a port scan would bring them from their own ISP. In my experience it seems the attackers like to use the getstatus command as it returns a fairly large chunk of data, including a list of the connected clients. Generally in amplification attacks the attacking party will go with whatever will fire out the most data.

A quick diagram of a amplification attack ...

Right now it seems like the best you can do is mitigate these attacks. The ioQuake3 folks have added some code into their version of the engine that can help. However it doesn't completely prevent your server from being used in an amplification attack. If your server is running on Linux there's a solution over at RawShark's blog via iptables.

# Intial fitlering. Do a little limiting on getstatus requests directly in the input chain.
iptables -A INPUT -p UDP -m length --length 42 -m recent --set --name getstatus_game
iptables -A INPUT -p UDP -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_game -j DROP

# Quake 3 DDoS mitigaton table.
iptables -N quake3_ddos

# accept real client/player traffic
iptables -A quake3_ddos -m u32 ! --u32 "0x1c=0xffffffff" -j ACCEPT

# match "getstatus" queries and remember their address
iptables -A quake3_ddos -m u32 --u32 "0x20=0x67657473&&0x24=0x74617475&&0x25&0xff=0x73" -m recent --name getstatus --set

# drop packet if "hits" per "seconds" is reached
# NOTE: if you run multiple servers on a single host, you will need to higher these limits
# as otherwise you will block regular server queries, like Spider or QConnect
# e.g. they will query all of your servers within a second to update the list
iptables -A quake3_ddos -m recent --update --name getstatus --hitcount 5 --seconds 2 -j DROP

# accept otherwise
iptables -A quake3_ddos -j ACCEPT

# finally insert the chain as the top most input filter
iptables -I INPUT 1 -p udp --dport 27960 -j quake3_ddos

If you're running multiple servers on the same host replace the last line with the following:

iptables -I INPUT 1 -p udp --dports 27960,27961,27962 -j quake3_ddos

Again thanks to RawShark for that.

These rules will prevent your server from responding to these spoofed request. They do this by matching the request with the address it claims to be coming from and then dropping the traffic if it gets more than five hitcounts in two seconds. The initial filtering will look for a slightly different behavior directly in your input chain. With this in place your server will still get those bad requests but it won't respond to them. Usually the parties running the attack will give up in a matter of hours or a day if they don't get the desired response from your machine.

It can also be helpful to run your server on a non-standard port. While this often will just provide some security through obscurity it does seem to thwart the laziest folks in this type of scenario, which fortunately seems to be a lot of them. This has the disadvantage of having you server not show up in game browsers and a lot of public directories so it may be a no-go for some folks.

As an administrator of a Quake 3 server these attacks can range from annoying to serious business. If enough people are using your machine as an amplification point it can get you blacklisted by a number of service providers. In my experience the likely hood of it affecting your server directly is relatively low. However this is one of those "good internet citizen" things that is generally nice to keep an eye on so you aren't knocking your neighbor offline. Please be aware this doesn't "harden" your server or make things more s