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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
