Hi again...

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? 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 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?

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?

Sander
 


-----Original Message-----
From: Tom Eastep [mailto:[email protected]] 
Sent: dinsdag 13 april 2010 15:49
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:
> When reading the 'man shorewall-rules' again I wonder if I can
> accomplice the same behavior with this single rule:
> 
> 
> #ACTION       SOURCE  DEST                    PROTO   DEST    SOURCE
ORIGINAL        RATE      USER/         MARK
>                                                       PORT(S) PORT(S) DEST
LIMIT     GROUP
>HTTP(DNAT)     net     loc:192.168.1.160       -       -       -       -
s:HTTPACCESS:3/min:3
> 
> 
> It looks to me if this has the same effect as the two rules given
> below (if I understand the rules correctly). So could someone then
> tell me what the difference is (if any) between the two ways to
> achieve this effect?

The above rule is broken in Shorewall releases prior to 4.4.8. So I
don't recommend using it unless

> 
> And one last question... Both limiting rules work by counting the
> current connected TCP sessions right?

No.

The Limit action works by keeping track of how many connections were
made in the last period; if that is greater than the limit, then the
connection is optionally logged then dropped; otherwise, the connection
is accepted.

Using per-IP limiting in the RATE/LIMIT column as shown above involves a
token bucket (http://en.wikipedia.org/wiki/Token_bucket). If the source
IP has a token, then the connection is allowed and the IP has one fewer
tokens; otherwise, the connection is passed to the next applicable rule.
See http://www.shorewall.net/configuration_file_basics.htm#RateLimit.

-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

Reply via email to