LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
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-23-2015, 11:23 AM   #16
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by Ser Olmy View Post
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.
Sorry for the late response, had to wait for the ddos to start again.

The rule did not prevent anything, however I was able to connect and move around so its getting there.

Here is a legit packet, the once that contain pure 0's are basically junk.
http://i.imgur.com/U71BeAC.png
 
Old 02-23-2015, 11:42 AM   #17
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
Sorry for the late response, had to wait for the ddos to start again.

The rule did not prevent anything, however I was able to connect and move around so its getting there.
When you say the rule "did not prevent anything", do you mean the server still slowed down due to the DDoS attack?

As it happens, there's an error in the rule. Instead of matching a number of consecutive zeros, it only tests the lower 16 bits in every 32-bit word. [Note to self: 0xffff is not a 32-bit number.] Here's a revised version that actually does what it's supposed to do:
Code:
iptables -t filter -A INPUT -p udp --dport 27035 -m u32 --u32 "0>>22&0x3C@8&0xffffffff=0x0 && 0>>22&0x3C@12&0xffffffff=0x0 && 0>>22&0x3C@16&0xffffffff=0x0 && 0>>22&0x3C@20&0xffffffff=0x0" -j DROP
You could try that and see if it makes any difference. Make sure you stick it at or very near the top of the rule chain.
Quote:
Originally Posted by Skidprevention View Post
Here is a legit packet, the once that contain pure 0's are basically junk.
http://i.imgur.com/U71BeAC.png
I can't tell just from looking at a hex dump of a single packet what would constitute a legitimate packet. At the very least, I'd need a relatively large sample of (legitimate) network traffic.

The optimal solution, however, would be to read the specifications for the application protocol in question. Does such documentation exist, or is this a closed, proprietary protocol?
 
Old 02-23-2015, 12:02 PM   #18
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Still letting it come through unfortunetly. I did mean, that it let the empty packets interfear slowing down the servers performance.

Here is a capture of normal and traffic under attack. I really hope you can help me!

Let me know when, or if you download it.

Last edited by Skidprevention; 02-23-2015 at 12:30 PM.
 
Old 02-23-2015, 12:20 PM   #19
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
I've downloaded your capture files and will have a look at them shortly.

Do you know with certainty that the slowdown is caused by the application process, and not the kernel or the packet queue in a local or upstream router? Have you looked at whether the statistics reported by top are (still) affected by the attack?

As I said earlier, no matter what you do with iptables, the DDoS packets will still arrive at the network interface of the server. If the rule is at the very top of the rulechain and filters traffic in an efficient manner, the effect on the server should be negligible. The incoming data stream may still cause various side-effects on routers along the path, typically some (if not all) external users could experience slight delays or even packet loss if the attack causes congestion on a certain connection or link.
 
Old 02-23-2015, 01:08 PM   #20
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
I've downloaded your capture files and will have a look at them shortly.

Do you know with certainty that the slowdown is caused by the application process, and not the kernel or the packet queue in a local or upstream router? Have you looked at whether the statistics reported by top are (still) affected by the attack?

As I said earlier, no matter what you do with iptables, the DDoS packets will still arrive at the network interface of the server. If the rule is at the very top of the rulechain and filters traffic in an efficient manner, the effect on the server should be negligible. The incoming data stream may still cause various side-effects on routers along the path, typically some (if not all) external users could experience slight delays or even packet loss if the attack causes congestion on a certain connection or link.
Sorry for the long response time, I setup a separate gameserver to see if it was effected. The DDoS luckily had no effect on other services, so must only be the application.
 
Old 02-23-2015, 02:04 PM   #21
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
The DDoS luckily had no effect on other services, so must only be the application.
I'm not so sure. You need to check performance statistics during an attack and compare them against a normal baseline. As I said, a quick look at top should tell you a lot about CPU usage, and you can press shift + m to sort the list by memory consumption instead.

If the filter works, then none of the packets sent by the attackers will have to be processed by the application. If the system is still slow, then there are only three possibilities:
  1. The filter isn't doing its job properly, and the server process is still wasting time trying to process invalid packets
  2. The filter is inefficient in that the filtering process itself consumes too much CPU resources, enough that it has a noticable effect on the server
  3. The filter is good and the kernel drops the offending packets without breaking a sweat, but the DDoS attack is causing some other issue somewhere else
Did you try the latest, revised rule? And did you put it at the very top of the chain? I'd recommend using "-I INPUT 1" instead of "-A INPUT", just to be sure.

I'll go and have a look at those capture files now.
 
Old 02-23-2015, 02:22 PM   #22
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
I believe the lag and eventually also the crashes, is because the application is trying to process the empty packets.

I tried the new rule, and it did not seem to block the attack. I am currently running the server with no IPTables firewall setup at all besides one blocking access to 22. I am looking to find a firewall that can block the more common attacks, and of course also those we have gotten lately. If you believe that you could write one that I could distribute to my over 20 servers, I would love to pay you for this service.

As for now, the rules you sent me did not work as the server was still taking the empty packets resulting in a very laggy server experience. I am currently keeping an eye on the application and kernel's CPU and RAM use. Will keep you posted.

Last edited by Skidprevention; 02-23-2015 at 02:29 PM.
 
Old 02-23-2015, 02:46 PM   #23
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
I believe I may have discovered something that could be of interest. I will send you a PM shortly.

Edit: It seems you have disabled that function. I will try the e-mail link instead.

Last edited by Ser Olmy; 02-23-2015 at 02:47 PM.
 
Old 02-23-2015, 02:56 PM   #24
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
I believe I may have discovered something that could be of interest. I will send you a PM shortly.

Edit: It seems you have disabled that function. I will try the e-mail link instead.
I believe I enabled PM's now.
 
Old 02-23-2015, 03:03 PM   #25
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
I believe I enabled PM's now.
Nope. But an e-mail should be on its way.
 
Old 02-23-2015, 03:11 PM   #26
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Nope. But an e-mail should be on its way.
I just read your email, and I must say it does indeed make perfect sense. Seeing as the attack is "only" 50 Mb, it could very well be from a single host.

I will cooperate with my Datacenter, to see if we can find our way to the hijacked box!

I am testing out the rule now, I wanted to ask if this needs to be in place BEFORE an attack happens or will it get blocked if added in the middle of one?
I ask because I want to make sure that an attack is actually happening before attempting to apply the new rule.
 
Old 02-23-2015, 03:15 PM   #27
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
Quote:
Originally Posted by Skidprevention View Post
I am testing out the rule now, I wanted to ask if this needs to be in place BEFORE an attack happens or will it get blocked if added in the middle of one?
Since a) the UDP packets aren't part of an existing session, and b) the rule can be placed at the very top of the chain anyway, it doesn't matter if you insert the rule now or wait until an actual attack is taking place.

One last question: You're using this rule on an actual server running the process in question, right? Not on, say, a load balancer or a forwarding router?
 
Old 02-23-2015, 03:18 PM   #28
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Since a) the UDP packets aren't part of an existing session, and b) the rule can be placed at the very top of the chain anyway, it doesn't matter if you insert the rule now or wait until an actual attack is taking place.

One last question: You're using this rule on an actual server running the process in question, right? Not on, say, a load balancer or a forwarding router?
This is placed on the box running the application yes, I hope to find a mix of rules that I can use on my entire network. This is the main reason I need more professional help, and that I am willing to pay for such services.

My infrastructure is like my baby, and a professional written firewall could be the vaccine.
 
Old 02-23-2015, 03:33 PM   #29
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,676

Rep: Reputation: Disabled
I was asking because packets being forwarded by a load balancer will hit the FORWARD chain, not the INPUT chain. The latter is only for packets destined for a local socket. In this case, the INPUT chain is indeed the right chain to use.

DDoS attacks with spoofed source IP addresses, masquerading as legitimate traffic, are quite difficult to deal with. The fact that the service is UDP based makes matters even worse; at least for TCP traffic we have SYNcookies to keep the IP stack from running out of resources.

If only ISPs would do more aggressive egress filtering ... but they don't, so we're left with trying to differentiate between an attack and packets from legitimate clients. An IDS would probably detect an attack, and a really good IPS might be able to devise a firewall rule to block it, but I wouldn't bet on it.

The ultimate solution would be a dynamic firewall integrated with the application itself: Only IP addressess belonging to authenticated (or at least connected) clients would be allowed, and if the initial logon/connection/signup service was TCP based, you'd be pretty much immune.

Until some script kiddie with access to a botnet managed to generate enough traffic to clog your lines completely, that is.

Last edited by Ser Olmy; 02-23-2015 at 03:45 PM.
 
Old 02-23-2015, 03:40 PM   #30
Skidprevention
LQ Newbie
 
Registered: Feb 2015
Posts: 20

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
I was asking because packets being forwarded by a load balancer will hit the FORWARD chain, not the INPUT chain. The latter is only for packets destined for a local socket. In this case, the INPUT chain is indeed the right chain to use.

DDoS attacks with spoofed source IP addresses, masquerading as legitimate traffic, are quite difficult to deal with. The fact that the service is UDP based makes matters even worse; at least for TCP traffic we have SYNcookies to keep the IP stack from running out of resources.

If only ISPs would do more aggressive egress filtering ... but they don't, so we're left with trying to differentiate between an attack and packets from legitimate clients. An IDS would probably detect an attack, and a really good IPS [i]might[/b] be able to devise a firewall rule to block it, but I wouldn't bet on it.

The ultimate solution would be a dynamic firewall integrated with the application itself: Only IP addressess belonging to authenticated (or at least connected) clients would be allowed, and if the initial logon/connection/signup service was TCP based, you'd be pretty much immune.

Until some script kiddie with access to a botnet managed to generate enough traffic to clog your lines completely, that is.
Well the server has a very powerful firewall that takes care of the large scale attacks, its mainly these more targeted smaller once that acts kinda like legit traffic but is a pain to deal with. I did ask my Datacenter to have a look at it, but they sent an email to a mailing list and I sent in a question to that list a few months ago. Still no reply.
 
  


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 06:21 PM.

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