Linux – IPTABLES for block sync flood over udp

floodingiptableslinuxSecurity

I'm a victim of a sync flood attack over UDP port. This came from a lot of different IPs. The machine, a dedicated server, is an hlds game server, and the attacker overload the UDP ports, this cause a big trouble in the game, with packet loss and high ping for every user in the game.

The server is under Linux, with iptables activated, and for now, with some rules to stop this attack, but nothing happend for my lucky.

TCPDUMP LOG (not all)

No.     Time        Source                Destination           Protocol Length Info    1012 6.134039    111.90.151.22         MYIP      UDP      60     Source port: ezmeeting-2  Destination port: 27024

Src: 111.90.151.22 (111.90.151.22), Dst: x.x.x.x (x.x.x.x)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 33
    Identification: 0x117f (4479)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 242
    Protocol: UDP (17)
    Header checksum: 0x4154 [correct]
    Source: 111.90.151.22 (111.90.151.22)
    Destination: x.x.x.x (x.x.x.x)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown] User Datagram Protocol, Src Port: ezmeeting-2 (10101), Dst Port: 27024  (27024) Data (5 bytes)


    Data: ffffffff56
    [Length: 5]

IPTABLES

iptables -A INPUT -p udp -d X.X.X.X --dport 27024 -m length --length 60 -m recent --set --name GameSynF
iptables -A INPUT -p udp -d X.X.X.X --dport 27024 -m string --algo kmp --hex-string "|ff ff ff ff 56|" -m recent --set --name GameSynF -j DROP

How to perform that iptable to drop any packet with the hex string "ffffffff56" and length 60.

Best Answer

If your firewall isn't already configured this way, default deny is the safer way to operate. This means that anything that isn't explicitly allowed is denied. For iptables, this means:

 iptables -P INPUT DROP

You can do this for the OUTPUT and FORWARD chains as well but OUTPUT in particular requires a little more discipline in managing what your server is allowed to connect to.

After disallowing everything, you allow what you want. Does your game listen for UDP traffic on ports 27015 and 27018? If so, add rules that allow that traffic in. Does the client always use a small range of source ports or even a single source port? If so, restrict the allowed packets to just those source ports. The first example you gave where the source port is 80 would be automatically blocked in that case. The other one might be depending on what source ports your client uses.

How are you determining that the firewall rules are not working? tcpdump attaches outside the firewall and hence will see packets that are destined to be dropped (or in the outbound direction, that have already passed the firewall). You can use a -j LOG rule to monitor specific parts of your chains or use in-application logging.

I'm not quite sure what you mean by "overload the udp ports". Does your application need to use a separate UDP port for each connecting IP address? Is there some shared resource that is acting as a bottleneck? Is all this UDP traffic just filling the networking hardware's buffers, causing the kind of latency associated with bufferbloat? If this last one is true, blocking using iptables won't even solve your problem.

Related Topic