DoS attack lagging my game server

mkools · 08-08-2014, 09:19 AM

I have DoS attacks lagging my game servers. The attacker is very creative and mixes it up, he's using different type of attack methods varying his source port range, using spoofed IPs and varying packet lengths so I have to adjust the firewall every time he does a new trick.

My game servers used to go down entirely before, but since I've disabled connection tracking and switch to stateless IP tables it now just lags so it's really improved.

There is just one attack I can't seem to be able to block, it's UDP packets with a 1062 length. The attack is very small but still lags my server.

Here's a screenshot from the Wireshark. He's using port 10 - 65535 and a lot of probably spoofed IPs but the packet length is all the same:

http://s14.postimg.org/g2ystmjap/screenie.png

Here's the full tcpdump during the attack in case u need it:

http://www.mediafire.com/download/8x...x/ddos2.tar.gz

So here's my firewall script, I figured I could block it just by adding:

iptables -A PREROUTING -t raw -p udp --dport 27016 -m length --length 1062 -j DROP

I also tried to block it using the first hex codes of the udp packet which is always the same as well but both options didn't work.

I would really appreciate it if someone could look at my settings or the tcpdump and give me advice. I'm not so advanced on iptables I'm sure there's people here that know a lot better than me. Thanks in advance!!

Code:

# List policies first
iptables -P INPUT DROP; iptables -P FORWARD DROP; iptables -P OUTPUT ACCEPT;

# Disable connection tracking
iptables -t raw -A PREROUTING -j NOTRACK
iptables -t raw -A OUTPUT -j NOTRACK

# Allow TCP outbound
iptables -A INPUT -p tcp -m multiport --sports 22,80,443,3306,27014:27050,30500 -j ACCEPT

# Allow TCP inbound
iptables -A INPUT -p tcp -m multiport --dports 22 -j ACCEPT

# Allow UDP outbound
iptables -A INPUT -p udp -m multiport --sports 53,4380,27000:27030,27500,27600,27700,51840 -j ACCEPT

# Allow UDP inbound
iptables -A INPUT -p udp -m multiport --dports 27016,27020 -j ACCEPT

# Anti DoS
iptables -A PREROUTING -t raw -p udp --dport 27016 -m length --length 0:32 -j DROP
iptables -A PREROUTING -t raw -p udp --dport 27016 -m length --length 1062 -j DROP
iptables -A PREROUTING -t raw -p udp --dport 27016 -m length --length 2521:65535 -j DROP

# Save state
/usr/libexec/iptables/iptables.init save

# Restart service
systemctl restart iptables

unSpawn · 08-09-2014, 12:45 PM

I'm interested: do check your email.

zer0python · 08-09-2014, 02:33 PM

I've not used iptables directly in a long time; (I switched to using firehol for personal stuff) I had to google around to refresh my memory first.

I'm not sure the `raw' table is the correct table to use. (See this link). But basically, `raw' seems to deal with the connection tracking stuff.

I'm not sure the PREROUTING chain is the correct chain either, since this deals mostly in "routing" packets and not necessarily the packets designated for this machine. (Or at least if memory serves me correctly.)

Since the connection is coming into the box, I'd imagine you could use the INPUT chain (packets designated for this machine) to filter out the badness.
as far as which table to use, I would try just doing this first:

Code:

iptables -A INPUT -p udp --dport ... -j DROP
...

If that doesn't work, maybe try using the `mangle' or `nat' table. (with PREROUTING)

--
Sorry that this comes a day late.
Good Luck!

mkools · 08-11-2014, 10:43 AM

Quote:

Originally Posted by zer0python

I've not used iptables directly in a long time; (I switched to using firehol for personal stuff) I had to google around to refresh my memory first.

I'm not sure the `raw' table is the correct table to use. (See this link). But basically, `raw' seems to deal with the connection tracking stuff.

I'm not sure the PREROUTING chain is the correct chain either, since this deals mostly in "routing" packets and not necessarily the packets designated for this machine. (Or at least if memory serves me correctly.)

Since the connection is coming into the box, I'd imagine you could use the INPUT chain (packets designated for this machine) to filter out the badness.
as far as which table to use, I would try just doing this first:

Code:

iptables -A INPUT -p udp --dport ... -j DROP
...

If that doesn't work, maybe try using the `mangle' or `nat' table. (with PREROUTING)

--
Sorry that this comes a day late.
Good Luck!

Thanks for your response np better late then never

I did try to put it in the INPUT chain, but then it starts connection tracking again that's why I've put them in prerouting. Afai understood from using Google you can only disable connection tracking in the prerouting and output chain, is that correct? I also tried the input chain during the attack, but it didn't seem to make any difference.

I would love to hear from someone that's fully into iptables, because I just basically Google'd and common sense'd these rules together so I'm sure they can be improved.

Thanks!

mkools · 08-12-2014, 03:15 AM

Well, I guess no response is good it means I didn't screw up entirley and did most part good

eikemoraes · 08-12-2014, 02:30 PM

Ok man use any software for stop attack up,and try filter mac for blocking ip !

Smokey_justme · 08-12-2014, 03:37 PM

Filtering in prerouting doesn't really work as far as I know.. You need something like

Code:

iptables -A INPUT -p udp -m multiport --dports 10:65535 -m length --length 1062 -j DROP

Don't worry about tracking since these packets are untracked (by the state machine, that is)

You should also stop tracking just udp packets, since the whole attack happens with those anyway... and rewrite the rest of your firewall to something more sane (and statefull)

mkools · 08-12-2014, 03:52 PM

Quote:

Originally Posted by Smokey_justme

Filtering in prerouting doesn't really work as far as I know.. You need something like

Code:

iptables -A INPUT -p udp -m multiport --dports 10:65535 -m length --length 1062 -j DROP

Don't worry about tracking since these packets are untracked (by the state machine, that is)

You should also stop tracking just udp packets, since the whole attack happens with those anyway... and rewrite the rest of your firewall to something more sane (and statefull)

Why would I need -m multiport --dports 10:65535, if I just remove that it goes for all ports right?
And I'm sure preroute filtering works, it worked with other attacks just not with this one.

And why statefull? Statefull killed my machine, thats why people recommended me stateless.

Smokey_justme · 08-12-2014, 04:05 PM

In your example you had just one port specified for the rule.. I just changed that to what you we're describing...

As for statefull, don't loose focus and handle just this attack... Since this attack is just on udp, marking just those packets as untrackable should still not kill your machine..
However, on the tcp side, your firewall should still provide the minimum expected security (which is statefull)... Maybe use limit on new syn packages just to be preemtive of a syn-flood...