[|P|Nitro]

zombiebob, on 05 March 2012 - 07:02 PM, said:

If anyone can supply IPTABLES code that will help please post it, i am confused about which IPTABLES code to use from this thread....Rambetter...we need you <3 :)

the current iptables I use without problems is this: (please test on your own server as it may be different for you)

note: I only use this for COD2 so you may need to change the port range "--dport 28000:29000"

iptables -I INPUT 1 -i eth1 -p udp -m udp --dport 28000:29000 -m string --algo bm --string "getstatus" -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -I INPUT 2 -i eth1 -p udp -m udp --dport 28000:29000 -m string --algo bm --string "getstatus" -j DROP
iptables -I INPUT 3 -i eth1 -p udp -m udp --dport 28000:29000 -m string --algo bm --string "getinfo" -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -I INPUT 4 -i eth1 -p udp -m udp --dport 28000:29000 -m string --algo bm --string "getinfo" -j DROP

I too also got a notification today from a victim of the attack, looking closely at their logs I see they only recieve a max of 3 packets ever few seconds from me so I believe the patch is still working (as by nature it has to respond to the first few packets before it determines a possible DDOS) like I said before a more advance patch that added the source IP to a blacklist after it was blocked would mean that we only send 3-4 packets at first then complete block responses AFTER we determine a possible DDOS this way our servers are never constantly responding to the same ip all the time with even just low amounts of packets, and a whitelist to prevent bots from being black listed.

This is the log I recieved today

Quote

Sample of captured packets: (Time is GMT+2)
============================================
2012-03-05 10:56:48.908447 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1007
2012-03-05 10:56:48.908795 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1007
2012-03-05 10:56:48.908997 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1007
2012-03-05 10:56:51.350766 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:51.351065 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:51.351517 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:53.793022 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:53.793300 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:53.793756 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:56.235553 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:56.235874 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:56.236115 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:58.676985 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:58.677281 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:56:58.677709 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:01.119265 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:01.119440 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:01.119816 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:03.560484 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:03.560827 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:03.561103 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 1006
2012-03-05 10:57:06.001469 IP 83.142.230.13.27960 > 50.23.212.166.8396: UDP, length 994

This post has been edited by Nitro: 05 March 2012 - 10:54 PM

[CMM|xandaxs]

My clan had to shut down all of the game servers we hosted (7 game servers)...
This is really bad as we need most of the servers online!

We're a competition clan and we play pcws everyday + clan wars..
Isn't there anything we can possibly do?

[[UZF]zombiebob]

xandaxs, on 05 March 2012 - 11:02 PM, said:

Isn't there anything we can possibly do?

write a new fix like Rambetter did?

[Rambetter]

OK guys, here is a little heads up.

In the coming days I'm going to be improving my patch. The improvement will try to limit the amount of bandwidth outgoing even further, by having a "temporary ban list" for offending IP addresses. The reason why I'm deciding to improve the patch further is because I've been contacted by the friendly folks who host my server.

In case you're curious, I'm copying the email I was sent:

Quote

We have received a complaint that the IP address 64.156.193.115 has been sending abusive traffic.

Your bandwidth utilization does not seem to be too high and may be part of a stealthy DDOS. Please investigate and get back to us ASAP.

See the included details at the bottom of the message.

NOTE: Activity of this sort is a violation of our Acceptable Use Policy, or AUP. Continued or repeated violations of the AUP will result in termination of your account, without refund. Our Acceptable Use Policy may be seen at any time at

http://www.m5hosting.com/aup.php


We do not presume that this abusive activity is intentional or malicious on your part. We just need it to stop.

This most likely indicates a security issue with your server. If you are unaware of this activity, then your server has probably been compromised.

We really don't want to have to cut off any customer, ever. But we are forced when presented with active malicious attacks originating from our networks. These can have serious repercussions for other customers who share your IP space.

Thank you,

M5Hosting Security



Here is the detail from the abuse report:



Sample of captured packets: (Time is GMT+2)
============================================
2012-03-05 11:19:44.242773 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:44.243113 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:44.243403 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:46.663036 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:46.663482 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:46.663486 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:49.080503 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:49.080532 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:49.080541 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:53.921370 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:53.921623 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:53.921938 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:56.352891 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:56.353569 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:19:56.354462 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:01.182974 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:01.182980 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:01.182994 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:03.608539 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:06.020678 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:06.020986 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 11:20:08.441453 IP 64.156.193.115.27960 > 159.253.144.13.8396:
UDP, length 975
2012-03-05 10:56:48.938885 IP 64.156.193.115.27960 > 50.23.212.166.8396:
UDP, length 995
2012-03-05 10:56:48.939281 IP 64.156.193.115.27960 > 50.23.212.166.8396:
UDP, length 995
2012-03-05 10:56:48.939656 IP 64.156.193.115.27960 > 50.23.212.166.8396:
UDP, length 995

I then replied with the following:

Quote

Hello Mike. Nice to hear from you. I hope your business is going well.

I am fully aware of these packets being sent. The problem is due to a
flaw in the design of the network protocol in Quake3-based video game
servers (UDP). In particular my server porky is running three
instances of a Quake-based game called Urban Terror. A few months
ago, all Urban Terror servers fell victim to these Distributed
Reflection Denial of Service attacks. The problem was really bad. I
actually wrote the code that fixes this flaw to some extent, and now
most Urban Terror servers are running my patch. So I know a lot about
this problem and I can adjust the patch as needed.

First, some background on this exploit:
http://www.lemuria.o...tion-drdos.html

In a nutshell, Urban Terror servers need to answer a type of UDP
request called "getstatus". These need to be answered as part of
normal functioning of an Urban Terror server. The getstatus UDP
request (incoming traffic) consists of very few bytes, like around 10
or 20. However, the UDP response (outgoing traffic) for this type of
request consists of up to 1000 bytes, or even more. The response is
sent to the "from" address in the UDP request.. Of course now, the
"from" address may be spoofed. That's the nature of UDP. And this is
how the exploit is used. It's a magnification attack where 10 or 20
bytes can trigger data of 1000 bytes or larger.

An unpatched server will answer every getstatus request. Yikes! An
attacker might use a network of computers to simultaneously send
millions of getstatus requests in a short amount of time, where the
getstatus requests are routed to all available Urban Terror servers.
(You can get a list of all Urban Terror servers from something called
the Master Server.) Each of these attacking getstatus requests will
have the same spoofed source address, which is the address that they
want to attack or flood.

A patched server (my code) puts an absolute limit to the number of
getstatus responses that an individual server sends to a count of 48
in a period of 2 seconds. In addition, a maximum of 3 getstatus
responses are sent to a specific IP address in a period of 2 seconds
(actually, an IP address in this case is defined by A.B.C.*, it
ignores the last byte of the IP address in order to try to limit
attacks to networks as well). This is similar to a leaky bucket
algorithm.

So, a person being attacked by a patched server will be receiving
about 3 x 1000 bytes every 2 seconds via UDP packets (and these
packets probably make no sense to them, they're just traffic). This
isn't very much traffic coming from an individual server. In fact
it's 1.5 kilobytes or 12 kilobits per second. That number agrees with
the examples of traffic I see in your email.

Now of course the real problem is that the person being attacked is
receiving traffic from thousands of Quake3-based servers at the same
time. And then you factor in the unpatched servers which make the
problem much worse. So the person being attacked has every right to
be angry.

I can do one of several things to prevent this problem from happening:

1. Shut down all Urban Terror servers on porky.. This would basically
kill my hobby.

2. Do nothing, and tell the person being attacked that 12 kilobits per
second is not an unreasonable amount of traffic coming from porky.
Actually, it's more like 36 kilobits since I have 3 servers running.
Although I haven't seen all 3 servers attacking the same IP address at
once. (I see all IPs being attacked in my logs.)

3. I can actually modify the patch to the server code, making it even
more restrictive. I can limit the number of getstatus responses to a
count of 2 per 3 second period (coming from a specific IP address)
instead of a count of 3 responses per 2 seconds. This would cut the
amount of offending traffic to the party being attacked by about half.

Let me know what you think. By the way this is a huge issue in the
Urban Terror community right now, I think just last night there was a
huge attack somewhere and everyone has been posting on the forums that
their server is in danger of being taken down.

By the way if you haven't noticed my servers are being bombarded by
millions of small UDP getstatus packets, and most of them are being
silently discarded by the code that receives them thanks to the patch.

P.S. Feel free to forward this email to the person who complained.

I then followed up with a further email:

Quote

Edit: I thought of a new algorithm.
I can detect if an address is really being attacked and then block
traffic [completely] to that address for an extended period of time.
This as opposed to still allowing 12 kilobits per second to that
address. This would definitely help the situation.

But do you think based on my previous email, am I causing maliciious
traffic? Maybe the improved patch would benefit all Urban Terror
servers.

[|P|Nitro]

wouldnt it be easier to hard code the ip addresses of known hosts like master.urbanterror.info and master2.urbanterror.info, and then just drop all requests that dont match those that are in whitelist.txt or hardcoded?

that way instead of Allowing unless denied metthod, you would be Deny all unless Allowed.


P.s. if your gonna host a mumble server it would be nice if you graced it with your presence once in a while :P

This post has been edited by Nitro: 06 March 2012 - 09:52 PM

[[UZF]zombiebob]

Rambetter, on 06 March 2012 - 09:17 PM, said:

OK guys, here is a little heads up.

Thanks Rambetter, lets see how this plays out. I feel better now someone who knows what they are doing has posted :)

[Rambetter]

Nitro, a regular UrT client also makes getinfo+getstatus requests. That's how you find out how many players are on the server in your server browser. You find out what map the server is on, etc. You can't possibly whitelist all UrT players' IP addresses.

[|P|Nitro]

Rambetter, on 06 March 2012 - 10:08 PM, said:

Nitro, a regular UrT client also makes getinfo+getstatus requests. That's how you find out how many players are on the server in your server browser. You find out what map the server is on, etc. You can't possibly whitelist all UrT players' IP addresses.

oh yeah, I totally forget about that part lol, well your tempban idea sounds good, how long where you planning the tempban to last? minutes, hours, days?

personally I like the sound on time between 1-2 days to totally discourage victims ip's being used this way. whats your take on it>

[Rambetter]

Nitro, on 07 March 2012 - 12:47 AM, said:

oh yeah, I totally forget about that part lol, well your tempban idea sounds good, how long where you planning the tempban to last? minutes, hours, days?

personally I like the sound on time between 1-2 days to totally discourage victims ip's being used this way. whats your take on it>

The logic I'm planning on is to trigger the temp ban once more than 3 getinfo+getstatus requests are sent in a period of 2 seconds from a single IP address. So if you sent 4 in 2 seconds you're temp banned.

I think the temp ban should last about an hour. This would really cut down on the traffic.

[|P|Nitro]

if you made it so that 4 attempts in less than 2 seconds triggered the temp ban and made the ban last 4hours this would allow a maximum of 6 attempts per day and a total of 24 packets per day averaging out at 1 per hour, surely no one could complain about that.


perhaps the response from the server could be shortened to only produce needed info (I am not sure if this is possible) but reducing the size of the reply could be another way to look at it.

what do you think?

Edit: actually reducing the size wouldnt work since b3 bot and others would not be able to work properly as they use getstatus and other commands to work out team balancing.

This post has been edited by Nitro: 07 March 2012 - 12:40 PM