0

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.

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
Kiwi
  • 33
  • 2
  • 6
  • The biggest question is this: How was the attack harming the server? Was it saturating the CPU? Saturating the inbound bandwidth? Saturating the outbound bandwidth? – David Schwartz Aug 06 '12 at 03:28
  • The CPU usage and RAM resources are ok with normal levels, and about bandwidth the same thing, this attack overload the udp ports. – Kiwi Aug 06 '12 at 04:22
  • 1
    I don't understand the term "overload the udp ports". Please clarify what is the impact (technical or business) – GioMac Aug 06 '12 at 06:36
  • @MatiasBrizuela: If the CPU, RAM, and bandwidth are okay, the attack should not be hurting you. UDP ports are numbers and it's not possible to overload them. I would suggest you put more effort into understanding the problem -- otherwise, any solution is unlikely to actually help. – David Schwartz Aug 06 '12 at 07:56
  • The impact over the server is "bussiness" purpose. We have some game servers in it and this kind of attack to the game servers causes high ping ingame, and with this is very difficult to play in it. Today I have the exactly attack type, is sync_flood over udp port 27015, with length 60, source http (first post updated) – Kiwi Aug 06 '12 at 15:36
  • @MatiasBrizuela: Right, but *why* is it causing a high ping? If it isn't maxing out the CPU and isn't maxing out the bandwidth, why is it hurting you? That's what you need to figure out. – David Schwartz Aug 07 '12 at 06:36

2 Answers2

1

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.

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
  • I block all the traffic, thanks for your tip, this attack sick me! Please i need some help to create a new rule for iptables to has block the hex string from attacker ips. – Kiwi Aug 06 '12 at 15:37
0

you need to figure out why this UDP flood is slowing you down.

if the attack causes higher pings then i would guess that the flood is not causing problems on your server, but that the flood is taking up all of the bandwidth on your internet connection. if that is the case, a firewall rule on the server won't solve this problem. you will need to talk to your upstream internet provider to get them to block that traffic.

longneck
  • 23,082
  • 4
  • 52
  • 86