[Martijn79]

Well I think I got there mostly. I got SSPD attacked by about 6000 routers, so much that iptables couldn't handle it to block everything (look at the list http://mgftw.com/f2b.txt) and although it was already a lot better the server would still show lag spikes. So I added fail2ban and set it to null route instead of block with iptables which is way way faster and any blackholed IP will never reach iptables again.

So for anybody else that gets these attacks, here's (part of) the solution.

Log and drop the packets:

iptables -A INPUT -p udp --dport 27016 -m string --algo kmp --hex-string '|485454502f312e3120323030204f4b|' -j LOG --log-prefix "SSPD-FLOOD: " --log-ip-options
iptables -A INPUT -p udp --dport 27016 -m string --algo kmp --hex-string '|485454502f312e3120323030204f4b|' -j DROP

That hex string says: 'HTTP/1.1 200 OK' which is what each packet starts with.

Next step is install fail2ban and add the filter:

nano -w /etc/fail2ban/filters.d/sspd.conf

Add this:

[Definition]

failregex= SSPD-FLOOD: IN=eth0 OUT= MAC=[a-zA-F0-9:]+ SRC=<HOST> DST=([0-9]{1,3}\.?){4}

nano -w /etc/fail2ban/action.d/route.conf

Add/change these lines to this:

actionban = ip route add unreachable <ip>
actionunban = ip route del unreachable <ip>

nano -w /etc/fail2ban/jail.conf

Add this below:

[sspd]
enabled = true
action   = route
protocol = udp
filter = sspd
logpath = /var/log/messages
bantime = 6000
maxretry = 1

Now this shows during an attack:

tail -f /var/log/fail2ban.log

2014-09-27 14:29:17,707 fail2ban.actions[26849]: INFO    [sspd] 220.160.150.166 already banned
2014-09-27 14:29:46,739 fail2ban.actions[26849]: WARNING [sspd] Ban 223.64.8.125
2014-09-27 14:29:47,742 fail2ban.actions[26849]: INFO    [sspd] 223.64.8.125 already banned
2014-09-27 14:30:59,814 fail2ban.actions[26849]: WARNING [sspd] Ban 118.77.86.241
2014-09-27 14:31:00,817 fail2ban.actions[26849]: INFO    [sspd] 118.77.86.241 already banned
2014-09-27 14:31:01,818 fail2ban.actions[26849]: WARNING [sspd] Ban 202.105.66.169
2014-09-27 14:31:02,822 fail2ban.actions[26849]: INFO    [sspd] 202.105.66.169 already banned
2014-09-27 14:33:06,944 fail2ban.actions[26849]: WARNING [sspd] Ban 99.225.54.223
2014-09-27 14:33:18,959 fail2ban.actions[26849]: WARNING [sspd] Ban 218.68.243.223
2014-09-27 14:33:19,963 fail2ban.actions[26849]: INFO    [sspd] 218.68.243.223 already banned

route -n shows the ban:

bhs01 ~ # route -n | grep 218.68.243.223
218.68.243.223  -               255.255.255.255 !H    0      -        0 -

[Martijn79]

Originally Posted by nikooo777 easy to null as well! by the way your rules there still use bm, i'd suggest you to switch to kmp too ;) also if you know where to look at, then use --from and --to to limit the CPU usage when searching for the match. here is an example i implemented to block source queries on multiple ports (DON'T do that unless you know what it does) iptables -A INPUT -p udp -m udp -m multiport --dports 25015,27025,27035,27045,27055,27065,27075,27085,27095 -m state --state NEW --match string --algo kmp --from 32 --to 48 --hex-string '|54536f7572636520456e67696e652051|' -j DROP 22:45:17.034811 IP (tos 0x24, ttl 111, id 2673, offset 0, flags [none], proto UDP (17), length 53) 85.218.205.237.21908 > XXX.XXX.142.159.27085: [udp sum ok] UDP, length 25 0x0000: 4524 0035 0a71 0000 6f11 6901 55da cded E$.5.q..o.i.U... 0x0010: 25bb 8e9f 5594 69cd 0021 a96e ffff ffff %...U.i..!.n.... 0x0020: 5453 6f75 7263 6520 456e 6769 6e65 2051 TSource.Engine.Q 0x0030: 7565 7279 00 uery. Edit: it's good that you log what happens, but logging an attack is not a good idea. if he sends something like 200Kpps you'll end up filling up your HDD/SSD quickly! (other than waste CPU cycles and HDD IO cycles)

Yep! Switched those to kmp as well. Works perfectly.

I've seen those tsource engine queries as well, isn't that the A2S spam thingy? I run plugins to block that but an iptables rule might be more effective.

And yeah it logs like a mad man but once fail2ban null routes the IPs they stop logging so it seems.

Here's my final ruleset:

# Flush rules
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t raw -F PREROUTING
iptables -t raw -F OUTPUT

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

# Drop invalid UDP packets
iptables -A INPUT -p udp --dport 27016 -m length --length 0:32 -j DROP
iptables -A INPUT -p udp --dport 27016 -m length --length 46 -j DROP
iptables -A INPUT -p udp --dport 27016 -m length --length 1020:1062 -j DROP
iptables -A INPUT -p udp --dport 27016 -m length --length 2521:65535 -j DROP

# Limit HEX 41
iptables -A INPUT -p udp -m udp --dport 27016 -m string --algo kmp --hex-string '|ffffffff41|' -m limit --limit 1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 27016 -m string --algo kmp --hex-string '|ffffffff41|' -j DROP

# Drop HEX 44
iptables -A INPUT -p udp -m udp --dport 27016 -m string --algo kmp --hex-string '|ffffffff44|' -j DROP

# SSPD redirection attack
iptables -A INPUT -p udp --dport 27016 -m string --algo kmp --hex-string '|485454502f312e3120323030204f4b|' -j LOG --log-prefix "SSPD-FLOOD: " --log-ip-options
iptables -A INPUT -p udp --dport 27016 -m string --algo kmp --hex-string '|485454502f312e3120323030204f4b|' -j DROP

# Connection tracking
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow public services
iptables -A INPUT -p tcp -m state --state NEW -m multiport --dports 22 -j ACCEPT

# Accept filtered game server port
iptables -A INPUT -p udp --dport 27016 -j ACCEPT

# Drop anything else not matching above rules
iptables -A INPUT -p udp -j DROP
iptables -A INPUT -p tcp -j DROP
iptables -A INPUT -j DROP

[Martijn79]

Well I guess it's useless, I'm receiving so much packets my machine can't filter it anymore and the server goes down. Something like 8000-9000 routers hit my box now. I guess I need external filtering.

[L33TGaming]

In the end it all coms down to who has a bigger pipe. As I said software side filtering is useless for a large DDOS.

[Martijn79]

Originally Posted by L33TGaming In the end it all coms down to who has a bigger pipe. As I said software side filtering is useless for a large DDOS.

Yeah but the incoming bandwidth is only 7 MB/s tops.

The PPS is enormous though.

[MetalMessiah]

I don't understand why providers who does not filter outgoing packets (to cut UDP spoofed ones) still exists..

[nikooo777]

contact the support, they will tune VAC for you, and the DDoS will pratically be gone

[Martijn79]

Originally Posted by nikooo777 contact the support, they will tune VAC for you, and the DDoS will pratically be gone

You know of all the things I didn't even do that yet, so yeah I'll open up a ticket.

I don't know about OVH's support though, it seems to be good in BHS but sucks in Roubaix.

[nikooo777]

that's pretty much right, they will ask you to contact the team via email.
You provide them with all the possible details and they will tune it for you

[adrianman]

isn't Martijn79 the guy who got banned for hosting nonsteam servers 2 years ago? (Marvel)