Tremulous Forum
General => General Discussion => Topic started by: rotacak on January 11, 2012, 09:06:45 pm
-
Today was my VPS server with Tremulous servers 1.1 and 1.2 disconnected from internet by my hosting company. They informed me and forwarded me email, from xat.com:
Your IP 46.28.108.190 attacked xat.com with udp packets as part of a
co-ordinated DDOS attack.
If you are running a game server this may be useful:
There is a known exploit with the "quake engine" used by various FPS type
games.
Your server may be being used for a Distributed Reflection Denial of
Service attack. eg:
- Attacker spoofs some packets (with our server ip) and asks gameserver to
send all server information (about 2k of data)
- gameserver sends all server information (500k of data)
- Attacker repeats for thousands of gameservers
If you are running a DNS server it may be being used for a reflection
attack. This may be useful:
http://www.shortestpathfirst.net/2009/11/12/hardening-dns-against-reflection-attacks-and-flooding-attacks/
Please contact me to confirm that you have addressed this matter and that
action will be taken against your customer/compromised machine and this
server will be taken down to prevent a repeat of this illegal activity.
With google is possible to find few similar things:
Your IP 46.182.120.203 attacked wrestlinghub with udp packets as part of a
co-ordinated DDOS attack.
Estimated bandwidth: 426 Mb/s
I need you to contact me to confirm that you have addressed this matter and
that action will be taken against your customer/compromised machine and this
server will be taken down to prevent a repeat of this illegal activity.
I look forward to hearing from you as a matter of urgency.
Richard
xat.com
Your IP 188.138.116.207 attacked xat.com with udp packets as part of a
co-ordinated DDOS attack.
Estimated bandwidth: 4 Mb/s
We got this from another host and it might prove useful:
"After investigation we found out that the attacker exploited a
vulnerability in the Call of Duty 2 server code, which is , as of now still
not patched by Acitivision. We're looking into filtering this specific type
of traffic outgoing
untill the developers come up with a fix
It is even possible? Attack should be from 1.1 server (Lakitu 5.5), but it is weird that anybody from xat.com will be contacting every attacking server and moreover that he will be "investigating" that problem with results "quake engine and call of duty 2 servers have nonpatched exploits". Sending 500KB of data is weird too.
Any ideas what the hell it is this?
-
The best way to mitigate it is to set iptables to rate limit getstatus / getinfo requests.
Something like:
iptables -N limit
iptables -A INPUT -p udp --dport 30720 -m string --from 25 --to 32 --string getstatus --algo bm -J limit
iptables -A INPUT -p udp --dport 30720 -m string --from 25 --to 30 --string getinfo --algo bm -J limit
iptables -A limit -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A limit -j DROP
The 500KB figure is bullshit. 1-2KB is more realistic per packet.
-
DDoSing
Meisseeelliiiiiiiii! >:(
-
iptables -A INPUT -p udp --dport 30720 -m string --from 25 --to 32 --string getstatus --algo bm -J limit
that won't work if someone adds some amount of whitespace in between the OOB bytes and the getstatus text.
The 500KB figure is bullshit. 1-2KB is more realistic per packet.
a 400-byte reply packet (or 500-byte packet on a non-empty server) is realistic for a 13-byte getstatus request packet. this translates to 63KiB (or 79KiB) of attack sp4m for the said 2KiB worth of requests.
-
I misread it as them saying one packet was 500k.
Does it work with leading space? Could change it to limit outbound packets, but I'm not sure if limit can do it on dest address.
-
Does it work with leading space?
and not only that! here's a shiny test:
#!/bin/sh
printf '\377\377\377\377 \t "GEtStATuS' | nc -u 127.0.0.1 30720
-
After reading the docs, what we want is probably:
iptables -N limit
iptables -A OUTPUT -p udp --sport 30720 -m string --from 25 --to 40 --string getstatusResponse --algo bm -J limit
iptables -A OUTPUT -p udp --sport 30720 -m string --from 25 --to 38 --string getinfoResponse --algo bm -J limit
iptables -A limit -m hashlimit --hashlimit 1/s --hashlimit-burst 5 --hashlimit-mode dstip,srcip,srcport --hashlimit-name trem -j RETURN
iptables -A limit -j DROP
-
Two days ago, I brought up this subject on the MG IRC chat. I'm told there is a patch that will limit the number of getstatus responses sent in n-seconds to a client. I hope this makes it by default in tremulous 1.2 and is available soon for 1.1
-
Two days ago, I brought up this subject on the MG IRC chat. I'm told there is a patch that will limit the number of getstatus responses sent in n-seconds to a client. I hope this makes it by default in tremulous 1.2 and is available soon for 1.1
but what to do till 1.2? i mean, we've got another 3-4 years of development to wait out.
-
but what to do till 1.2?
use recent GPP or GPP-based binaries.
-
but what to do till 1.2?
use recent GPP or GPP-based binaries.
do they have the patch included by default?
*hint, hint*
-
use recent GPP or GPP-based binaries.
do they have the patch included by default?
no, but it is not true that
we've got another 3-4 years of development to wait out.
-
i know, was just making a (played out) joke.
but seriously, we might want to get that patch added and update the binaries asap.
-
but seriously, we might want to get that patch added and update the binaries asap.
seriously, we might want
we
:D
-
well, someone. i would patch and compile them myself, but i dont have any development libraries installed on this machine.
so i'll be cheering for the brave soul who takes this task on.
-
I would like to point out that either someone has already solved this problem or never will.
-
ioQuake3/Tremulous already has a packet limiter exactly for the relevant purposes. unfortunately, it is applied only for getstatus requests, but not getinfo requests. here's an example patch to fix that (includes a bit of my limiting preferences):
--- a/src/server/sv_main.c
+++ b/src/server/sv_main.c
@@ -566,6 +566,8 @@ static qboolean SVC_RateLimitAddress( netadr_t from, int burst, int period ) {
return SVC_RateLimit( bucket, burst, period );
}
+static leakyBucket_t outboundLeakyBucket;
+
/*
================
SVC_Status
@@ -584,10 +586,9 @@ static void SVC_Status( netadr_t from ) {
int statusLength;
int playerLength;
char infostring[MAX_INFO_STRING];
- static leakyBucket_t bucket;
// Prevent using getstatus as an amplifier
- if ( SVC_RateLimitAddress( from, 10, 1000 ) ) {
+ if ( SVC_RateLimitAddress( from, 10, 2000 ) ) {
Com_DPrintf( "SVC_Status: rate limit from %s exceeded, dropping request\n",
NET_AdrToString( from ) );
return;
@@ -595,7 +596,7 @@ static void SVC_Status( netadr_t from ) {
// Allow getstatus to be DoSed relatively easily, but prevent
// excess outbound bandwidth usage when being flooded inbound
- if ( SVC_RateLimit( &bucket, 10, 100 ) ) {
+ if ( SVC_RateLimit( &outboundLeakyBucket, 20, 100 ) ) {
Com_DPrintf( "SVC_Status: rate limit exceeded, dropping request\n" );
return;
}
@@ -640,6 +641,20 @@ void SVC_Info( netadr_t from ) {
char *gamedir;
char infostring[MAX_INFO_STRING];
+ // Prevent using getinfo as an amplifier
+ if ( SVC_RateLimitAddress( from, 10, 2000 ) ) {
+ Com_DPrintf( "SVC_Info: rate limit from %s exceeded, dropping request\n",
+ NET_AdrToString( from ) );
+ return;
+ }
+
+ // Allow getinfo to be DoSed relatively easily, but prevent
+ // excess outbound bandwidth usage when being flooded inbound
+ if ( SVC_RateLimit( &outboundLeakyBucket, 20, 100 ) ) {
+ Com_DPrintf( "SVC_Info: rate limit exceeded, dropping request\n" );
+ return;
+ }
+
/*
* Check whether Cmd_Argv(1) has a sane length. This was not done in the original Quake3 version which led
* to the Infostring bug discovered by Luigi Auriemma. See http://aluigi.altervista.org/ for the advisory.