What is a DRDoS attack?

Post Reply
User avatar
Edge100x
Founder
Founder
Posts: 12945
https://www.youtube.com/channel/UC40BgXanDqOYoVCYFDSTfHA
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

What is a DRDoS attack?

Post by Edge100x »

A DRDoS ("Distributed Reflected Denial of Service") attack is a special type of DDoS (which we describe in general here: http://www.nfoservers.com/forums/viewto ... =25&t=4931). In a DRDoS, the target is not attacked directly; instead, the attacker sends faked (spoofed) traffic to a set of other IPs, which then respond to that traffic to the IP that was spoofed, and in doing so flood the victim offline. By sending packets that elicit a much larger ("amplified") response, the DRDoS initiator can generate a very large attack with a very small amount of traffic.

This type of attack has become very common lately. Here's a more specific example:
  1. The attacker decides to target IP address 127.0.0.1:27015, which is a CS:S server that he has been banned from.
  2. The attacker connects to a machine that he had previously compromised and uses a traffic generator tool to send simple query packets to a large number of other game servers, specifying a (fake) source of 127.0.0.1:27015. Each query packet is less than 50 bytes, so the attacker can send many thousands of these per second without using much bandwidth; even a very low-end machine can do it.
  3. These game servers ("reflectors") respond to 127.0.0.1:27015 with much larger packets, often 500+ bytes long, containing lists of their rules and connected players.
  4. The CS:S server at 127.0.0.1:27015, upon receiving the huge wave of attack traffic from thousands of different IPs, is overwhelmed. It is unable to serve legitimate clients or respond to queries itself, causing a denial of service.
Many ISPs apply filters to their egress traffic, which (for the most part) prevents customers from pretending to be IPs that they are not, also preventing them from being used to launch attacks like this. Unfortunately, not every provider can or does.

Commonly, DRDoS attacks use Quake3, Wolfenstein:ET, CoD* servers, and other old Quake3-engine-based games as the reflectors. These games don't have facilities to limit query response rates and send large response packets, making them ideal for this purpose.

If you were linked to this post because you are being used as a reflector in order to attack an IP here, please understand that we are not actually sending the queries -- we are the victim that is being hit with responses from servers like yours. Your primary course of action should be to block that spoofed traffic from reaching your servers via an ACL. You could also try to find out the true source of this traffic by contacting your upstream and asking them to track down where the spoofed packets are coming from (and having them do the same with that provider). Most ISPs won't do this unless large sums and the FBI are involved, but it doesn't hurt to try.

If you run Q3/ET/CoD*/etc servers (any version) on Windows, this patch is one workaround: http://files.nfoe.net/cod4/CoD4_Getstatus_Flood_Fix.zip

If you run CoD4 servers (1.7) on Linux, the latest beta version of CoD4 is the way to go: http://treefort.icculus.org/cod/cod4-ln ... st.tar.bz2

If you run other Q3-engine games on Linux, and you have the "string", "hashlimit", and "recent" iptables kernel modules available, you can filter the traffic with rules like these:

Code: Select all

# add a host to the banlist and then drop the packet.
iptables -N QUERY-BLOCK
iptables -A QUERY-BLOCK -m recent --reap --seconds 30
iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts -j DROP

# is this a query packet? if so, block commonly attacked ports outright,
# then see if it's a known attacking IP, then see if it is sending at a high
# rate and should be added to the list of known attacking IPs.
iptables -N QUERY-CHECK
iptables -A QUERY-CHECK -p udp -m string ! --string "getstatus" --algo bm --from 32 --to 33 -j RETURN
iptables -A QUERY-CHECK -p udp --sport 0:1025 -j DROP
iptables -A QUERY-CHECK -p udp --sport 3074 -j DROP
iptables -A QUERY-CHECK -p udp --sport 7777 -j DROP
iptables -A QUERY-CHECK -p udp --sport 27015:27100 -j DROP
iptables -A QUERY-CHECK -p udp --sport 25200 -j DROP
iptables -A QUERY-CHECK -p udp --sport 25565 -j DROP
# is it already blocked? continue blocking it and update the counter so it
# gets blocked for at least another 30 seconds.
iptables -A QUERY-CHECK -m recent --update --name blocked-hosts --seconds 30 --hitcount 1 -j DROP
# check to see if it exceeds our rate threshold,
# and add it to the list if it does.
iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip --hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK

# look at all the packets going to q3/cod*/et/etc servers
iptables -A INPUT -p udp --dport 27960:29000 -j QUERY-CHECK
If you were linked to this post because you saw a flood of game query responses, some of which came from our IP addresses, please understand that our servers are not the ones launching an attack. They are simply replying to seemingly-legitimate queries (there's no way for them to tell that they are not legitimate). If you contact us, we can attempt to block traffic specifically to your IP, but this won't do much for you, because your attack is likely being reflected by thousands of other IPs, as well. There are two primary ways that you can address such an attack on your end -- and usually both are needed:

- By calling your upstream and having them apply an ACL to filter some of the source ports for you (a range from 27960-29000 to block common Q3-engine attacks, for instance).
- By using a Linux firewall on your side to block the remaining traffic, through the use of the "string" iptables module. Use a rule like this on the target machine:

Code: Select all

iptables -A INPUT -p udp -m string --string "statusResponse" --algo bm --from 32 --to 33 -j DROP
Since we also have the patches mentioned in the prior section applied to all our servers, attacks reflected through our IPs should be rare.
User avatar
Edge100x
Founder
Founder
Posts: 12945
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

Re: What is a DRDoS attack?

Post by Edge100x »

Some are calling the specific attack described above "devnull", as that is the name of one of the tools used to generate it. Other tools also exist, and it's very easy to develop new ones, due to the nature of the exploit.

We have also been seeing quite a few attacks that use open recursive DNS resolvers as reflectors recently. They usually do this by requesting a large TXT entry from a domain, spoofing the target IP when doing so.
User avatar
Edge100x
Founder
Founder
Posts: 12945
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

Re: What is a DRDoS attack?

Post by Edge100x »

When applied to a DNS server that is being used as a reflector, this similar ruleset would help with a reflected attack using DNS servers. This could be tweaked to work even better by checking for DNS request packets specifically, instead of looking at all traffic to port 53, but in this form, it should still be effective.

Code: Select all

iptables -N QUERY-BLOCK
# clean up very old entries that are no
# longer resulting in blocked traffic -- 
# this is a good place for it because it's
# only called occasionally
iptables -A QUERY-BLOCK -m recent --reap --seconds 30
# add a host to the banlist and then drop the packet.
iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts -j DROP

iptables -N QUERY-CHECK
# is it already blocked? continue blocking it and update the counter so it
# gets blocked for at least another 30 seconds.
iptables -A QUERY-CHECK -m recent --update --name blocked-hosts --seconds 30 --hitcount 1 -j DROP
# otherwise, check to see if it exceeds a rate threshold,
# and add it to the temporary block list if it does.
iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip --hashlimit-name dnsattack --hashlimit-above 10/second -j QUERY-BLOCK

# send all the packets going to the local DNS server to the right chain
iptables -A INPUT -p udp --dport 53 -j QUERY-CHECK
Post Reply