But it's better to try anyway.
I'm not sure if it will be really a heavy load for the kernel since it will just be IP matching.. i mean that's just matching 32 bit data. Even if it's many, a trick perhaps like masking for comparison will really be easy. I also think that the kernel in a computer system is much more robust than a blocker or filter in a common router. This is just a possibility of how the kernel might do it although I haven't examined the source code yet.
And yet again I think they're commonly weaker than the kernel's netfilter system.

But try anyway.

Btw is it possible to make a SYN attack with fake IP sources like the theory of idle scanning? This will make things more difficult.

0 members found this post helpful.

Surviving a DDoS attack depends on two things. First you have to have enough bandwidth to process the requests. If you're saturating your port, you're done, you need to buffer it upstream, and that depends on your provider. Some have it, and those that do, will likely charge you for it. This is because this type of protection isn't cheap. The equipment required to filter datacenter level traffic is pretty expensive.

With that being said, if you can filter the traffic, and at 20Mbps, you might be able to, and if you're running nginx, it can be configured to filter based on User-Agent string.

It'd look like:
#block based on user agent string
if ($http_user_agent = 'Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1') {
return 403;
}

Of course, this all depends on what you're using to serve the traffic. If you're not using nginx, you may want to look at a simple set of scritps to ban multiple IPs. I explain it here: http://blog.jim80.net/2009/05/30/dyn...xible-and-fun/

1 members found this post helpful.

Netfilter uses RAM for storing rules and conntrack buckets. Netfilter requires CPU cycles to process filters. Netfilter rules work on a "first match wins" basis. Using Netfilter rules for blacklists makes processing harder. The amount of inbound requests to process simultaneously may be so huge that eventually:
- HW will start dropping packets as it just can't cope,
- CPU will be swamped while it tries to "walk" the filter tree for each new conn,
- RAM gets filled by added conntrack entries,
- RAM gets filled by added blacklist entries.
As RAM and CPU get over-exercised the machine will spiral down, showing high load and wait states, into resource starvation. Basically it'll be DoSsing itself under "measures" suggested.


Yeah, sure. But what characteristics set aside DoS traffic from regular traffic? How much time do you have (if you haven't got a plan) before you can practically try to mitigate the DoS? If it's a DDoS with say regular HTTP requests then how would you filter traffic? Edge routers can apply bogon filters to filter out invalid traffic, limit traffic to a volume the pipe can handle and do packet inspection to scrub traffic well before it hits the server and without taxing the server. Maybe read up before you add more "advice"?

My thought is to, instead of 'try anyway', to think on if the tool is adequate and, if it is, how the tool will impact your workflow, factoring the work involved in setting up and maintaining the tool. As I said before, setting it up is hardly trivial and it requires constant maintenance and tuning and vigilance...this may be more than what the OP wants, as not everyone wants or needs to try for the sake of trying, especially if they need a corporate-level solution quickly.

BTW, it actually doesn't take much to take down a firewall...I've seen it before (saw it with MSBlaster and other major security events). I saw one customer network that had a lot of IRC bot traffic that kept growing and, over time, the firewall crashed. I saw this happen twice with two different customers. Much of this was due to the state table not being able to cope with the sheer amount of traffic. Adjusting the table setting to a higher quantity is also just borrowing time. This is one of the reasons why border routers and switches are more efficient in dealing with traffic such as DoS/DDoS.

Yep. That's how I've seen it happen IRL. I've seen this happen quite a few times, actually...enough to where we've learned the best and worst ways to mitigate such traffic.

We still don't have any log/dump input from OP, we can stop guessing. If Goni will post something, then we can probably suggest some methodics.

That depends on who you're addressing as "we". If you don't have practical experience with (D)DoS mitigation then it's probably best for you too to back off and read up on things before you offer "advice" or try to regulate threads in the Linux Security forum.

That *can* be technically correct but basing on your (researched?) explanation does systems (on most cases) eventually break the way you imply? Especially, will that apply to the OP's machine and to the level of the attacks it tries to fend? Also does all kernel versions, implementations and even configurations apply? How 'bout different hardware configurations?

Compared to the amount of processing and resources spent on transfering data from every network layer to the apache server, processing every TCP syn packet, processing of IO write for apache logs and other miscellaneous kernel mode calls made by the apache server, and more more processes vs. the amount of processing spent with filtering packets on the IP layer.. which one is more expensive? Remember the whole frame is already removed on the IP layer.

Do I really have to make an assumption of the OPs situation first before making any suggestion? Shouldn't you better just add that up as an another advice with respect to my idea for the OP's sake?I was assuming you already know what my idea meant. The first is to detect attacks using Snort in the TCP layer and HTTP layer then if an attack is detected, add the IP for filtering. The final filtering is done on the IP layer. On a slight doubt it may appear as permanently filtering an IP is a bad idea.. well this is just were the next steps that are still based from many variables will follow. For example, lifetime of a filter rule may be limited.Here we go a gain with the try to be really expert first before you show an idea.

Why do I have to read up? I think my what you think is an advice which is really just a suggestion does not really make much of a conflict unlike the way you try to exaggerate (as always as it appears). If such routers can be used to filter some of the traffic why not just add them as helpers anyway.

Also are those routers capable of filtering the way advance filtration softwares can do? With the capable routers, aren't they also using resources, and also perhaps also have an internal memory and (commonly a lot slower?) processor?

In the end I think it is still really up to the OP to decide what he think suits best for the situation. Giving it an idea or whatever you call it is not really that of a problem unless it's really not valid.

0 members found this post helpful.

Ok if that's really the case. I now recognize or consider your idea. ..Although, I still hope my contribution regarding use of Snort still helps.

0 members found this post helpful.

It's not based on research but actual practice with host-based DDoS mitigation. It suffices to say I've learned my lesson.


If we're talking (simple, single) host-based, then we're talking kernel. The premise remains that, simply due to the nature of a DDoS, end-points won't and can't cope. Of course you don't have to take that from me and that's why I started my first thread reply saying "If you search this forum you'll see replied time and time again that any end-point "solutions" simply won't work": documentation and references can be found outside of LQ on all major security sites like CERT, the SANS reading room, CISCO, Juniper, Arbor a gazillion mailing lists et cetera.


There can be no comparison as in time traffic won't even hit the web server anymore and filtering will lead to resource starvation too.


Sure single purpose network devices consume resources but think of the old UNIX adage "to perform one task only and excel at performing": routers don't need to juggle a gazillion disparate tasks so blocking illegal packets, null-routing, scrubbing packets before hand-off or completely blocking off the end-point is way less expensive at edge routers.


It always is and nobody sane would challenge that.

Hey, I'm not saying that Snort won't work, but its a long-haul type tool. Lots of people tend to try to install it once they've determined they need it, but (and this is just my opinion) that's too late. Those same people will more than likely only use it until it becomes a nuisance to maintain for them. You won't get results with that tool until you've massively tuned it to your environment.

So, go ahead...give it a shot if you want. You're the master of your own domain.

Not the obvious. You're talking about the behavior of netfilter, right?
Still it sounds like you made an assumption on your last post. Also with regards to reconsidering your first post, it seems that it just makes the difference between your persuasions and/or concepts compared to mine just vague or unclear.

Really, how much starvation can this really cause. Also, remember that we have to take account all the resources we have including the routers. Costs, risks to use to front devices, operation expenses and limitations of current available resources should also be considered as part of the decision.

If we're talking about stress with respect to the web server, shouldn't we should also consider the stress with respect to the other equipment? Note what the OP said before:
But that can only be blocking off TCP syn attacks, no? How 'bout the HTTP patterns? Well maybe on some routers but not all right?
Well I'm glad you consider that

0 members found this post helpful.

If I had a domain, I will find doing such things rather amusing. Defending is a lot more fun than attacking. .. and a lot more for counterattacks.

0 members found this post helpful.

Here is a sick, twisted and downright evil idea: Point your domain to THEIR IP! That otta be fun. That is, if there is one central IP you can find, but if it's a botnet with many different IPs, my idea is retarded.

0 members found this post helpful.

And how on earth you're going to find a central IP of b-net? If it's run by evilcrackers, their net is probably built the way you won't find which IP is main. Most commonly that is impossible.
And well, domain is needed to host something. Not to host cracker servers.