LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 02-22-2015, 06:58 AM   #1
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Rep: Reputation: Disabled
Blocking common ddos attacks with IPTables


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:
Code:
0000   0c c4 7a 0d cb ac 64 ae 0c 40 f0 80 08 00 45 00  ..z...d..@....E.
0010   00 1c 44 50 00 00 ee 11 56 be a2 ea f8 07 b2 21  ..DP....V......!
0020   e4 ae da 4b 69 9b 00 08 00 00 00 00 00 00 00 00  ...Ki...........
0030   00 00 00 00 00 00 00 00 00 00 00 00              ............
Example 2:
Code:
0000   0c c4 7a 0d cb ac 64 ae 0c 40 f0 80 08 00 45 00  ..z...d..@....E.
0010   00 1c 5c ed 00 00 ef 11 09 55 bf a4 0f 1a b2 21  ..\......U.....!
0020   e4 ae 40 b5 69 9b 00 08 00 00 00 00 00 00 00 00  ..@.i...........
0030   00 00 00 00 00 00 00 00 fd 7d aa 11              .........}..
Hope you can help me out, I cannot let the skids win this war!
 
Old 02-22-2015, 09:00 AM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
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
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).
 
Old 02-22-2015, 09:36 AM   #3
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
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.
 
Old 02-22-2015, 09:50 AM   #4
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Rep: Reputation: 106Reputation: 106
Quote:
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?
If it's to the input computer and the source port is 20000

Code:
iptables -A INPUT -p tcp --sport 20000 --dport 27005 -j ACCEPT
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.

Last edited by Miati; 02-22-2015 at 09:58 AM.
 
Old 02-22-2015, 09:55 AM   #5
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Miati View Post
If it's to the input computer and the source port is 20000

Code:
iptables -A INPUT -p tcp --sport 20000 --dport 27005 -j ACCEPT
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.

Code:
iptables -A INPUT -p udp --sport 27005 --dport 27035 -j ACCEPT
 
Old 02-22-2015, 10:02 AM   #6
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
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:
Code:
iptables -t filter -A INPUT -p udp --dport your_application_port --sport port_number -j DROP
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:
Code:
iptables -t filter -A INPUT -p udp --dport your_application_port --sport fixed_source_port -j ACCEPT
iptables -t filter -A INPUT -p udp --dport your_application_port -j DROP
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.)

Last edited by Ser Olmy; 02-22-2015 at 10:03 AM.
 
Old 02-22-2015, 10:03 AM   #7
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Rep: Reputation: 106Reputation: 106
Quote:
Originally Posted by Skidprevention View Post
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.

Code:
iptables -A INPUT -p udp --sport 27005 --dport 27035 -j ACCEPT
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

Code:
iptables -P INPUT DROP
Something like this:

Code:
iptables -P INPUT DROP
iptables -A INPUT -p udp --sport 27005 --dport 27035 -j ACCEPT
will only permit udp packets coming from port 27005, heading to port 27035 (from any ip to any ip) to be accepted.

Last edited by Miati; 02-22-2015 at 10:05 AM.
 
Old 02-22-2015, 10:07 AM   #8
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
Quote:
Originally Posted by Miati View Post
You can set policies with -F. It will accept either DROP or ACCEPT

Code:
iptables -P INPUT DROP
Something like this:

Code:
iptables -F INPUT DROP
iptables -A INPUT -p udp --sport 27005 --dport 27035 -j ACCEPT
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.
 
Old 02-22-2015, 10:11 AM   #9
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
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:
Code:
iptables -t filter -A INPUT -p udp --dport your_application_port --sport port_number -j DROP
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:
Code:
iptables -t filter -A INPUT -p udp --dport your_application_port --sport fixed_source_port -j ACCEPT
iptables -t filter -A INPUT -p udp --dport your_application_port -j DROP
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.)
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.

Last edited by Skidprevention; 02-22-2015 at 10:14 AM.
 
Old 02-22-2015, 10:31 AM   #10
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
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.

Last edited by Skidprevention; 02-22-2015 at 10:42 AM.
 
Old 02-22-2015, 12:16 PM   #11
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
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):
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -u32 --u32 "40&0xffff=0x0 && 44&0xffff=0x0" -j DROP
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 &&.
 
Old 02-22-2015, 12:37 PM   #12
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
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):
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -u32 --u32 "40&0xffff=0x0 && 44&0xffff=0x0" -j DROP
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.

Last edited by Skidprevention; 02-22-2015 at 12:59 PM.
 
Old 02-22-2015, 01:01 PM   #13
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
iptables v1.4.14: unknown option "27035"

Advice?
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:
Code:
iptables -t filter -A INPUT -m u32 --u32 "0&0xf000=0x4000 && 6&0x00ff=17 && 0>>22&0x3C@0&0xFFFF=27035  && 0>>22&0x3C@8&0xffff=0x0 && 0>>22&0x3C@12&0xffff=0x0" -j DROP
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:
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -m u32 --u32 "0>>22&0x3C@8&0xffff=0x0 && 0>>22&0x3C@12&0xffff=0x0" -j DROP

Last edited by Ser Olmy; 02-22-2015 at 01:26 PM.
 
Old 02-22-2015, 01:30 PM   #14
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
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:
Code:
iptables -t filter -A INPUT -m u32 --u32 "0&0xf000=0x4000 && 6&0x00ff=17 && 0>>22&0x3C@0&0xFFFF=27035  && 0>>22&0x3C@8&0xffff=0x0 && 0>>22&0x3C@12&0xffff=0x0" -j DROP
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:
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -m u32 --u32 "0>>22&0x3C@8&0xffff=0x0 && 0>>22&0x3C@12&0xffff=0x0" -j DROP
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?
 
Old 02-22-2015, 01:41 PM   #15
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,679

Rep: Reputation: Disabled
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:
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -m u32 --u32 "0>>22&0x3C@8&0xffff=0x0 && 0>>22&0x3C@12&0xffff=0x0 && 0>>22&0x3C@16&0xffff=0x0 && 0>>22&0x3C@20&0xffff=0x0" -j DROP
...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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
iptables not blocking ssh attacks mfoley Linux - Security 12 04-20-2014 01:58 PM
Hello / DDoS attacks cybernet2u Linux - Security 7 11-21-2009 10:30 PM
iptables not blocking brut force attacks (something simple?) MikeOfAustin Linux - Security 6 11-20-2008 12:51 AM
DDOS attacks Challengers alamlinux Linux - Security 2 03-23-2008 02:12 PM
Concerning DDoS attacks joji_in_changwon Linux - Security 13 11-27-2007 12:12 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 04:31 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration