0

I need some help, my game server has been under fire with DoS attacks for 2 days now. Bandwidth attacks are no problem since I host with OVH and they are filtered out but my game server ports are being attacked which times out the servers and disconnects all players.

So at first it was easy, he attacked with packets from all the same length, 1062.

444 0.017859    159.208.182.160 192.95.55.2 UDP 1062    Source port: 53407  Destination     port: 27016
445 0.017902    14.87.205.89    192.95.55.2 UDP 1062    Source port: 22286  Destination    port: 27016
446 0.017907    68.191.26.190   192.95.55.2 UDP 1062    Source port: 48964  Destination port: 27016
447 0.017992    201.50.53.136   192.95.55.2 UDP 1062    Source port: 13001  Destination port: 27016
448 0.017993    58.15.28.176    192.95.55.2 UDP 1062    Source port: senip  Destination port: 27016

So I just did a:

iptables -A INPUT -p udp --dport 27016 -m length --length 1062 -j DROP

Which worked, my servers suddenly came back to life again. This was like 1000 - 4000 KB/s of traffic.

Next thing you know, he starts sending 12 MB/s traffic, which I should be able to handle since I'm on gigabit and which I did, because only the attacked server went down (there are 4 servers running on 4 different IP addresses on the same server and the others were fine).

I ran tcpdump again, and ame thing. All attacks with length 1062 which I blocked earlier? So I'm kinda stuck here and don't know what to do.

Can someone please take a look at my tcpdump file and tell me what I'm doing wrong and how I can block off this attack (or can't)? I would really appriciate it!

I have a hard time reading it with wireshark, I've been trying to block packets with length, hex code etc but all not successful.

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

Thanks!

Oh one more thing, during the attack my dmesg outputs this:

[35126.217197] nf_conntrack: table full, dropping packet
[35144.702662] nf_conntrack: table full, dropping packet
[35147.513124] nf_conntrack: table full, dropping packet

I already tried stuff like sysctl -w net.netfilter.nf_conntrack_max=524280 but that didn't seem to make any difference.

Thanks.

Martijn Kools
  • 9
  • 3

1 Answers1

1

If you are not going to apply NAT or filtering based on stateful inspection, then you are better off not using connection tracking. You can disable connection tracking on a per packet basis by using the NOTRACK target in the raw table. That should avoid the table full messages you are seeing.

Suitable rules could look like this:

-A PREROUTING -p udp --dport 27016 -j NOTRACK
-A OUTPUT -p udp --sport 27016 -j NOTRACK
kasperd
  • 30,455
  • 17
  • 76
  • 124
  • Thanks for your reply. I've been working on a new script the entire day. Do you think this script is any good? http://pastebin.com/Zj7gXfFE I've been checking my /proc/net/nf_conntrack and all I can see in there are SQL connections, I don't think I don't need them to not track right? It's only a few. I still have my doubts about the last lines though, blocking of the bad UDP packets in prerouting, is there a better way doing this? Any other comments are welcome as well! Thanks! – Martijn Kools Aug 06 '14 at 16:50
  • Holy crap, got a new attack 240 mbit/sec and this script solved it, no more server going down!! In the end it was just connection tracking that couldn't keep up I guess. – Martijn Kools Aug 06 '14 at 17:13