My servers is constantly getting hit by a DDoS using random source ports, and spoofed addresses. The DDoS consist of empty packets, length 60.

The server is hosted with OVH, and their so called "DDoS protection" is proving useless in this matter. The attack is 50 Mbit, and is not even picked up by their systems.

I was hoping that some good old IPTables could sort it for me

If anybody can help me write a firewall that I can put on all my servers, that you will occasionally help me with.
Please contact me in a PM, and we can figure something out. At this point I am willing to pay.

Example 1:
Example 2:
Hope you can help me out, I cannot let the skids win this war!

How would an iptables ruleset prevent an attacker from using a botnet to send vast amounts of traffic in your direction?

There are two things to consider when dealing with these types of (D)DoS attacks:

1. The strategy of the attacker is simply to use up all available bandwidth at your end, thus preventing legitimate requests from reaching your servers
2. The attacker does not care if your servers respond or not

In short, there's nothing you can do at your end to reduce the effectiveness of these attacks. Once the packets arrive at your server, bandwidth has already been consumed. What your servers choose to do with the traffic is of no consequence.

DDoS attacks must be filtered upstream. A relatively simple access list on as router might do the job. You need to speak with your hosting provider (again).

It's only 50 Mbit, I dont want to block the traffic. I wish to block the traffic from reaching the application and thereby crashing it.

It should indeed be possible to block it, like block anything but the port we expect to reach it.

Legit traffic comes by port 27005, the theirs are random. Is there a way to only allow a specific source port to reach the destination port?

I think of this as being a more targeted, probably somewhere in the range of a layer 7 attack.

If it's to the input computer and the source port is 20000

port matching with tcp

EDIT: be cautious when trying to match source ports though. If the user is using a web browser, there's a excellent chance that 20000 is not the source port as web browsers choose random ports on outbound connections.

Its UDP game traffic, and they randomize their ports.

There is currently no attack running but would this only allow UDP traffic with the source port 27005 to reach destination port 27035?

How would I go about blocking the rest of the source ports, I would imagine this being in front of another rule that blocks the random ports they use.

If a 50 Mbps attack still leaves sufficient free bandwidth for the application in question, and the problem is that the attack brings the server and/or application to a standstill then yes, an iptables rule should help.

For both UDP and TCP, random source ports are the norm. Unless the client process is bound to a specific port (and it rarely is), the IP stack will simply pick a free port from withing the "high" (>1023) range whenever a packet needs to be sent (UDP) or a session is to be initiated (TCP). Unless you're absolutely certain that legitimate traffic should come from a specific port, blocking certain source ports is likely to cause problems.

An iptables rule for blocking a specific UDP source port would look like this:Of course, if only one specific source port is ever involved, it would make more sense to allow that single port and filter the rest:Note that I used the "-A" (add) parameter in the examples above. That will add a rule to the bottom of any existing ruleset, something that might not yield the desired results if a rule further up the chain actually allows the traffic in question.

If your ruleset is currently blank, the rules above will work as they stand. If you already have a ruleset, you will need to insert the above rules in the correct place. You could also test the rules by inserting them at the top of the existing ruleset; replace the first "-A" with "-I 1" (insert at position 1) and the second with "-I 2".

(I haven't really looked at your hex dumps, since I'd have to paste the data into a hex editor and then somehow convert that into a capture file. If you could dump the offending traffic to a capture file with tcpdump and either post it here or make it available online, I could have a closer look.)

Yes, that looks fine.

The best way of doing this is setting default policy of INPUT to drop so that anything that you do not explicity match is dropped.

You can set policies with -P. It will accept either DROP or ACCEPT

Something like this:

will only permit udp packets coming from port 27005, heading to port 27035 (from any ip to any ip) to be accepted.

If the OP doesn't currently have an iptables ruleset, the above policy and rule will prevent the server from doing anything other than serving incoming requests on that specific UDP port. Absolutely nothing else will work, including DNS lookups, remote administration, downloading of updates etc. etc.

Yeah, seems like "most" traffic is from a specific source port, however some connections are from random ports..

I sent you a tcpdump in PM.
Edit: I tried to do so.

Alright, new info!

I found out, that the DDoS have an empty payload. Its pure 0's besides the actual header.

How would one block this, its getting really annoying :/

Frame: http://i.imgur.com/ViSesvI.png
They are trying loads of different size of packets, from 60 up to 1000.

Sounds like this might be a job for u32. Assuming a header length of 40 bytes, the following rule should reject any packets where the first 8 bytes of the payload are zero (warning: untested):The filter syntax for u32 is "start_byte&mask_value=result", where & indicates a logical AND operation between the 32-bit word and the 32-bit mask. Multiple filter conditions can be specified with &&.

iptables v1.4.14: unknown option "27035"

Advice?

Another frame: http://i.imgur.com/TMKDzco.png
Those are 60, non like the once above.

Looks like that for some reason, one cannot use both "-p" and "-u32" in the same rule. To match UDP packets to a specific destination port, additional u32 filters must be created.

Try the rule without the "-p udp --dport 27035" part. It'll still only match packets with a 8-byte sequence of zeros at offset 40. I'll get back to you with an updated filter.

Edit: Try this:This first filter checks for IPv4 (there's a surprising amount on link-local IPv6 activity in many networks), the next checks for protocol number 17 (UDP), and the third filter will match destination port 27035.

I've altered the filter to take into account the (very remote) possibility that the IPv4 header may have a non-standard length.

Edit 2: The error message from the command in my previous post was somewhat misleading. As it happens, it was just a syntax error. One can indeed combine u32 with other match mechanisms, so this will also work:

That blocked way too much, it ended up freezing players and making them unable to connect.
Is there any way, that you can be contacted more directly?

You should be able to reach me with a PM.

The challenge here is to find a fingerprint that matches the DDoS packets while at the same time excludes all legitimate traffic. It seems that checking the first 8 bytes of the payload for zeroes wasn't specific enough. I guess you could add a few more checks for consecutive zeroes:...or find a specific byte in a legitimate packet that is guaranteed to always be non-zero (or perhaps even to have a specific value) and check for that specifically.

I think you need to look more closely at the application traffic.