Help - Search - Members - Calendar
Full Version: FloodGuard and much connections from single IP
The Planet Forums > Security > DoS & D-DoS Mitigation
AlexAT
Does FloodGuard protect from much connection from single IP?
klaude
If they're legitimate connection attempts (like HTTP requests) then no. If it's an IP throwing traffic your way like a SYN flood then Floodguard will help you out. icon_smile.gif Floodguard protects you against "flood" types of attacks, not technical attacks like a SQL injection or HTTP spamming.
Serhat
QUOTE (klaude)
If they're legitimate connection attempts (like HTTP requests) then no.

But in that case, if someone were to do continuous GET requests from a couple hundred bots, wouldn't that be able to flood the bandwidth with legitimate connection attempts and thus result in a successful DDoS?
HomePCIT
QUOTE (Serhat)
QUOTE (klaude)
If they're legitimate connection attempts (like HTTP requests) then no.

But in that case, if someone were to do continuous GET requests from a couple hundred bots, wouldn't that be able to flood the bandwidth with legitimate connection attempts and thus result in a successful DDoS?


Yes I suppose it would, but that's not what FloodGuard protects against. It would defeat the purpose if it affected legitimate traffic. How would it determine DoS attacks from legitimate traffic if they are properly formed http/mysql requests for instance?

FloodGuard primarily caters for specific types of DoS/DDoS attacks.

You could always look at the NetZentry site for further info, although the NetZentry site does not contain as much information as it used to.[/url]
Serhat
QUOTE (HomePCIT)
How would it determine DoS attacks from legitimate traffic if they are properly formed http/mysql requests for instance?

True, but shouldn't it be marked as suspicious at least when a client makes e.g. 100k instantly dropped connections when no other client normaly does that?
eddy2099
Floodguard like any other protection can only help so far without alienating legitimate traffic.

Sending multiple 'get' or 'put' request may in your case be a sign of an attack. However if you are running a search engine of sorts then the multiple requests may be a normal daily affair since people may come and search multipe contents or submitting them.

From what I understand, Floodguard does not use a complicated rule set and cannot determine intent of the user when determining to let the request through or not.
HomePCIT
QUOTE (Serhat)
QUOTE (HomePCIT)
How would it determine DoS attacks from legitimate traffic if they are properly formed http/mysql requests for instance?

True, but shouldn't it be marked as suspicious at least when a client makes e.g. 100k instantly dropped connections when no other client normaly does that?


Unless I'm mistaken I don't believe that FG sees dropped connections. I believe 3 devices act as passive network devices that monitor ingress data (inbound data). It is not a device that monitors what actually happens at the point of reaching your server. It monitors for particular types of packets that make up DoS attacks and when notices them on the network determines where they are from and applies a modified ACL to the routers to block the traffic before hitting your server.

That's a poor explanation but I think you should get the idea.
Serhat
QUOTE (HomePCIT)
That's a poor explanation but I think you should get the idea.

Yes, I understand the idea. It is clear that not all possible types of attack can be stopped. However, we do remain with these questions:

a) Is there any blocking done at all against attacks involving legit connections? If the answer is 'no', then a simple attack could involve continuously making connections from a couple hundred compromised systems. Perhaps we have a paradoxical situation where attacks are easier to stop as they are made harder to trace.

B) At least one post elsewhere in this forum mentioned blocking an offending IP (in the firewall presumably), but still receiving several megabits worth of (failed) connection attempts. What's up with that? Even if on the server-side, you can determine which IPs belong to compromised machines, how will that help you stop the attack?
HomePCIT
QUOTE (Serhat)
Yes, I understand the idea. It is clear that not all possible types of attack can be stopped. However, we do remain with these questions:

a) Is there any blocking done at all against attacks involving legit connections? If the answer is 'no', then a simple attack could involve continuously making connections from a couple hundred compromised systems. Perhaps we have a paradoxical situation where attacks are easier to stop as they are made harder to trace.


IMHO, not automatically. It is possible if you provide the appropriate details to get SM to assist with blocking from their network infrastructure.

QUOTE (Serhat)
B) At least one post elsewhere in this forum mentioned blocking an offending IP (in the firewall presumably), but still receiving several megabits worth of (failed) connection attempts. What's up with that? Even if on the server-side, you can determine which IPs belong to compromised machines, how will that help you stop the attack?


Ok. If you gather details of compromised machines you can get SM to assist with blocking. Software/hardware Firewalls can block traffic from reaching the server. Does that stop DoS attacks, no. Can a hardware firewall be overloaded and essentially stop legitimate traffic from making it to the server, yes. Can a software firewall suffer the same way, yes. A hardware firewall would be more able to cope with this sort of thing as it has dedicated hardware which will work faster than a software firewall. A firewall provides added security, not complete security from all attacks.

Theoretically if an extremely large DDoS attack was directed towards an SM located server it could affect more than just the server it is directed at as it could overload a router/switch and affect many servers. SM network/security engineers would have monitoring to inform them of such things and when determined that something of this nature is occuring they take adequate measures to defend against it.
AlexAT
Back to much connections from single IP icon_smile.gif

Is there any way to limit number of such kind of connections?
On which side (server, SM) ?
HomePCIT
QUOTE (AlexAT)
Back to much connections from single IP icon_smile.gif

Is there any way to limit number of such kind of connections?
On which side (server, SM) ?


If it appears to be a DoS type of attack (even if it's legitimate traffic) you could liase with SM to block the traffic. You can also use a hardware/software firewall on your machine to block the traffic, although a software firewall will put some load on your server as the requests will actually be reaching it.

There are software throttling mechanisms but I'm not sure what/how/if they will limit the number of connections from any one given IP. You could always tweak apache to reduce the number of connections that it accepts before rejecting them.
AlexAT
It seems that I can not configure apache to limit number of connections from any IP.

What I need is to limit **each** visitors (IP) in for example 50-100 connections.

Somebody use APF?
Is there any switch for this?
HomePCIT
QUOTE (AlexAT)
It seems that I can not configure apache to limit number of connections from any IP.

What I need is to limit **each** visitors (IP) in for example 50-100 connections.

Somebody use APF?
Is there any switch for this?


As far as I know APF will only allow you to block or accept traffic, not throttle it. Try this: http://www-106.ibm.com/developerworks/linu...fw/?n-l-4191#h4
AlexAT
thank you!
I will.
HomePCIT
QUOTE (AlexAT)
thank you!
I will.


You're welcome. I hope it suits what you are after.
AlexAT
you gave me excellent scripts!
dynfw is really good.

but it does not provide functionality like "drop IP when reach X connections from them in Y minutes/hors/days".

with this script possible only to drop all IPs for conditions but I need to drop only "seems bad" IP.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.