Ok... Thanks for the good info. Very much appreciated! After reading your comments I decided to use the RATE/LIMIT option (only available in version 4.4.8) instead, since it has the burst option which sounds really good in my case :)
I do have one question about that... The doc's say: "After each interval (15 seconds) that passes without a connection arriving, the burst count is incremented by 1 but is not allowed to exceed its initial setting". It says "without a connection arriving", but I assume that even if a connection arrives during the interval (which gets past along to the other rules and is not matched to the rule in question because the burst count is 0), then after the interval period the burst count in incremented? Or does the burst count only gets incremented when no new connection arrives at the rule for at least the duration of the interval period? Sander -----Original Message----- From: Tom Eastep [mailto:[email protected]] Sent: donderdag 15 april 2010 18:03 To: Shorewall Users Subject: Re: [Shorewall-users] Using the limit action on a DNAT rule to prevent DoS attackson a specific port S. J. van Harmelen wrote: > Today I tried to put my Shorewall config in production, but had to undo it > really fast because I had connection problems. When trying to connect to our > website I noticed that it connected, but then wasn't able to load the whole > page in one time. Now I understand how a webpage is loaded (each picture is > a separate call to the webserver) so I know it has something to do with the > limit action that I set... > > You already explained how the limit action works: > > "The Limit action works by keeping track of how many connections were > made in the last period" > > But I still have trouble understanding what you are saying here (sorry). In > the example of loading a webpage with a few pictures in it... Is every > request to the server counted as a new connection? I neither know nor do I care when Web browsers decide to open new connections to a server. I know that if I look at about:config in my Firefox (Iceweasel) browser, there is a max-connections-per-server setting that has the value 15. So I further assume that any limiting of connections to less than 15 in a short period of time would cause issues for my browser. > In that case I guess it's > not really useful to set a limit action on a http rule, right? As then it's > quite hard to set the correct limit number to enable normal browsing but > prevent DoS'ing... I think, as in all such things, you should start out with a conservative setting and go from there. > > I also read about the connlimit option. Should that be a better option in > this case? I take it that this option does indeed just count the total > numbers of concurrent TCP sessions from a specific IP address, the only > drawback is that the connection aren't counted per rule but in total over > all rules, correct? That's correct. > > Any pros and cons I miss? And the doc's don't say what happens when a new > session is started when then limit is reached? Will the w session be logged > and dropped? Like any netfilter rule, if the rule doesn't match then the connection is passed on to the next rule. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
