[squid-users] acl maxconn and max_user_ip config help please

[B. Henry]

Bless you Sir!
I think I follow you everywhere, and will study this carefully along with a couple examples from the online documentation when I am trtaveling.
One last question on this topic; any gotchas with the max_user_ip acl rule?
And excuse my sloppy omission in
> >  http_access foo_MC
My ignorance is great, I really must not shoot myself in the feet with errors like this.
Thanks for your clear and complete explanations.   


-- 
     B.H.
   Registerd Linux User 521886


  Amos Jeffries wrote:
Mon, Jul 18, 2016 at 07:15:48PM +1200

> On 18/07/2016 6:23 p.m., B. Henry wrote:
> > First, thanks for answering.
> > Second, I have read the entire default conf file, yes, once made the mistake of reading one for a different squid version than mine, but then got a fresh 
> > copy of the one for my exact version.
> > I've also read the FAQ, and most all the configuration guide, but if I had not I certainly would be greatful for the links.
> > My misunderstanding then is now in how to apply a rule that will only effect group foo with out reusing the name.
> > Would I first name the group as I have and then make a maxconn line, e.g.
> > acl foo_MC maxconn 15
> > and then
> >  http_access allow foo
> >  http_access foo_MC
> > 
> > and if this is correct, 
> 
> It is not correct as-is. The allow/deny action is missing on the foo_MC
> line. (Plus the logic mistake explained below.)
> 
> > is it just the ordering there that means that this maxconn will only apply to group foo?
> 
> No. The above config means the opposite of that.
> 
> Top-to-bottom, left-to-right boolean conditions.
> 
>  # if foo, then Allow
>  http_access allow foo
> 
>  # else if foo_MC, then ???
>  http_access ??? foo_MC
> 
>  # else if true, then deny
>  http_access deny all
> 
> foo_MC test will never be reached (and so not applied) for anything
> which is already Allow'ed by the "foo" ACL test.
>  
> So logically, the foo_MC rule is applied (only) to non-"foo" traffic.
> 
> 
> > If not, how do I make the rule only apply to group foo?
> 
> 
> One would usually construct the access lists to enforce a logically
> arranged policy something like this:
> 
>  # 0) default security rules preventing various attacks
>  http_access deny !Safe_ports
>  http_access deny CONNECT !SSL_ports
> 
>  # 1) prevent foo from using more that 15 TCP connections to the proxy
>  http_access deny foo foo_MC
> 
>  # 2) allow foo (with 15 or les connections) to use the proxy
>  http_access allow foo
> 
>  # 3) allow LAN clients (not in group foo) to use the proxy
>  http_access allow locanet
> 
>  # 4) deny other (external / non-LAN) traffic
>  http_access deny all
> 
> 
> Any http_access line which contains 'foo' ACL can only match when that
> test of foo is a match, so that action on it by definition applies only
> to the set of transactions where foo is matched/true.
> 
> Any http_access line which matches completely will halt http_access
> processing. So a line which contains only "foo" ACL and the action, will
> prevent any following lines being used for that group.
> 
> The above two points/details are why the "deny foo foo_MC" line is
> ordered above the "allow foo" line in the above example config.
>  --> If they were the other way around the "allow foo" would end the
> processing for "foo" group with an allow action. The any line containign
> "foo" after that would never be a match for anything that could reach it.
> 
> 
> 
> PS. there is a gotcha with the maxconn ACL in HTTP/1.1 traffic that you
> need to be aware of. Particularly when using the -s flag.
> 
>  If a client opens more than maxconn limit number of TCP connections.
> Then *any* HTTP request received from that client on *any* of those
> connections will see a true/match for the maxconn test. So will be
> denied until one of the connections is closed.
> 
>  maxconn was designed for use in HTTP/1.0 traffic where each TCP
> connection carried only one HTTP request, then gets closed. So the deny
> action would directly result in -1 TCP connections and other requests
> possibly being allowed.
> 
>  HTTP/1.1 connections (eg Squid-3.1 and later) are by default
> persistent, so can carry multiple requests. The denial response does not
> trigger a -1 TCP connection like HTTP/.0 did. So HTTP/1.1 connections
> can stay open and triggering denial for a long while after the client
> hits the limit. Traffic where maxconn works well is becoming rare.
> 
> Amos
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users