OVH DDoS Protection Block TS3 Attack

[Leon]

Hello,
i have a 128GB (2x 64GB) Dedicated Server from ovh.com.
All attacks will be blocked very good, and very fast.
But there is one attack that will not be blocked, traffic flood for TS3.
Can someone give me iptables to block wrong TS3 Traffic?
Or can someone help me to install rules dierctly on my ESXi host?
I can pay some money (PayPal) if somone will help me very good.

Thanks.

 

[ikfes]

Provide tcpdump(.pcap file) of the attack here and we can instantly say how to block it.

 

[Leon]

Provide tcpdump(.pcap file) of the attack here and we can instantly say how to block it.

k thanks, i will do in the evening

 

[Leon]

Provide tcpdump(.pcap file) of the attack here and we can instantly say how to block it.

Here tcpdump: *REMOVED*

 

[ikfes]

That's normal traffic between the server and the users.

After that starts the obvious pattern which lasts till end.

The length of this invalid UDP packet is 34
Counting up the header:

The total length would be 62

What you can do is drop UDP packets by length.

 

[ikfes]

Or you can filter by hex since all packets seem to have this same data.

545333494e495431006500008802fd66d30

So basically like this if you decide to drop by packet length:
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 34 -j DROP
or
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 62 -j DROP

or both

iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 34 -j DROP
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 62 -j DROP

Or if you wish to use hex instead to drop those said packets:

iptables -A PREROUTING -t raw -p udp --dport 9987 -m string --hex-string '|545333494e4954310|' --algo kmp -j DROP

A complete iptables with logging but not tracking would be:
You can find the blocked packets log in /var/log/messages if you are using Debian and see if it's blocking.

 

[ikfes]

Had to make 2 post since Cloudflare protection on R4P3.net wouldn't let me post that in one.

 

[Leon]

Or you can filter by hex since all packets seem to have this same data.

545333494e495431006500008802fd66d30

So basically like this if you decide to drop by packet length:
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 34 -j DROP
or
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 62 -j DROP

or both

iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 34 -j DROP
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 62 -j DROP

Or if you wish to use hex instead to drop those said packets:

iptables -A PREROUTING -t raw -p udp --dport 9987 -m string --hex-string '|545333494e4954310|' --algo kmp -j DROP

A complete iptables with logging but not tracking would be:
You can find the blocked packets log in /var/log/messages if you are using Debian and see if it's blocking.

Its Working now, teamspeak dont gets traffic in. But after 1 minute it laggs 10%.
Server has incomming 30mbit ( not ts3) and cpu is 10%

 

[ikfes]

Incoming 30Megabits/s is quite large for a TS3 server.. It should be mostly outgoing traffic even if TS3 is counted in.

Basically OVH Anti-DDoS leaks 30Mbps DDoS traffic in.

Not sure how to fix that 10% packet loss right now.. It would need even more investigation and not gonna do that for free lol.

 

[ikfes]

What you can try is remove these:

iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 34 -j DROP
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 62 -j DROP

And only use

iptables -A PREROUTING -t raw -p udp --dport 9987 -m string --hex-string '|545333494e4954310|' --algo kmp -j DROP

It might be some legit traffic getting randomly 34 or 62 bits of length and not belonging to the DDoS attack, which causes the 10% packet loss as those packets are dropped based on their length.

Where as the hex-string search drops the packets based on their payload. Note that this is more CPU heavy as it has to search for the hex value.

 

[Leon]

What you can try is remove these:

iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 34 -j DROP
iptables -A PREROUTING -t raw -p udp --dport 9987 -m length --length 62 -j DROP

And only use

iptables -A PREROUTING -t raw -p udp --dport 9987 -m string --hex-string '|545333494e4954310|' --algo kmp -j DROP

It might be some legit traffic getting randomly 34 or 62 bits of length and not belonging to the DDoS attack, which causes the 10% packet loss as those packets are dropped based on their length.

Where as the hex-string search drops the packets based on their payload. Note that this is more CPU heavy as it has to search for the hex value.

it gives me this:
iptables v1.6.0: Invalid hex block
Try `iptables -h' or 'iptables --help' for more information.

 

[ikfes]

it gives me this:
iptables v1.6.0: Invalid hex block
Try `iptables -h' or 'iptables --help' for more information.

Well, it works for me. Im running Debian 7 with basic iptables.

Maybe the string is too long for your system.. idk? delete couple of digits from the end.

 

[ikfes]

You could do:

Install iptables persistent:
sudo apt-get install iptables-persistent

Create iptables.sh file which you can load and reload:
sudo nano /root/iptables.sh

make it executebale:
chmod +x /root/iptables.sh

Edit it
sudo nano /root/iptables.sh

Paste your rules inside.

Execute it:
sudo /root/iptables.sh

Now you have enabled the rules you typed in there.. And if you do any edits, just save and re-run the script to get them active.

Finally you could do:
iptables -L -n -t raw
to see if it works

Depending on your rules, the output should be something like this:

root@vps299042:~# iptables -L -n -t raw
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
CT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 NOTRACK
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 length 0:32
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 length 2521:65535
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 STRING match "|fa163eb402096ac8|" ALGO name kmp TO 65535
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
CT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:9987 NOTRACK

 

[Leon]

You could do:

Install iptables persistent:
sudo apt-get install iptables-persistent

Create iptables.sh file which you can load and reload:
sudo nano /root/iptables.sh

make it executebale:
chmod +x /root/iptables.sh

Edit it
sudo nano /root/iptables.sh

Paste your rules inside.

Execute it:
sudo /root/iptables.sh

Now you have enabled the rules you typed in there.. And if you do any edits, just save and re-run the script to get them active.

Finally you could do:
iptables -L -n -t raw
to see if it works

Depending on your rules, the output should be something like this:

root@vps299042:~# iptables -L -n -t raw
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
CT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 NOTRACK
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 length 0:32
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 length 2521:65535
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:9987 STRING match "|fa163eb402096ac8|" ALGO name kmp TO 65535
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
CT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:9987 NOTRACK

if i execute the command, i cant connect to the ts server anymore, if i delete it, all is working