[squid-users] [RFC] Changes to http_access defaults

Alex Rousskov rousskov at measurement-factory.com
Fri Apr 14 15:47:57 UTC 2017


On 04/14/2017 06:22 AM, Amos Jeffries wrote:

> To override the propsed default you *add* ports to the Safe_ports and
> CONNECT_ports (ala SSL_Ports) lines to make them no longer be denied.

>  acl Safe_ports port 0-65535
>  acl SSL_Ports port 0-65535

Thank you for sharing this important detail! I like this clever design
and agree that this approach allows admins to overwrite the proposed
default behavior/functionality.

This approach carries the following overwriting price:

* For every access, Squid will pointlessly evaluate the following:
  http_access deny !all_ports
  http_access deny CONNECT !all_ports

Is this an acceptable price to pay?

(The evaluation is pointless because the rules never match (because
all_ports always matches). In this context, the admin wants the rules to
never match, so that she can insert her own rules overwriting the
default. So the functionality is correct, but the default rules cannot
be removed and are evaluated.)

We could add a rule optimizer that will detect and remove some
never-matching rules, including the above ones. If the overwriting price
is too high, adding such an optimizer may become a precondition. The
optimizing logic is straightforward, but things like deny_info will
complicate implementation.

All other alternatives proposed so far do not have this performance penalty.


> I've have two goals here:
> 
> 1) reduce peoples ability to shoot themselves in the foot.
> 2) further reduce the things people are required to manually configure

All three proposed options satisfy #1.

All three proposed options satisfy #2 if "manual configuration" is
defined as editing squid.conf.default. The lint option does not satisfy
#2 if "manual configuration" is defined as editing squid.conf.empty. How
should we define "manual configuration" in this context so that we can
compare options using a common set of criteria?


> I expect [squid.conf.default to look like this]:

>   http_access allow localhost manager
>   http_access deny manager
> 
>   # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> 
>   http_access allow localnet
>   http_access allow localhost
>   http_access deny all

I think the proposal would be a lot more attractive if it results in
elimination of all of the http_access rules from squid.conf.default. As
it currently stands, the changes imply many headaches, but still do not
solve the "reasonable default access restrictions" problem. In other
words, we are already paying a lot but still gaining little.

What if we raise the bar and declare reaching the "reasonable default
access restrictions" as the goal? Can we solve that problem instead,
with comparable headache severity of the original proposal?

For example, Squid could automatically add something like the following:

  # always added at the top of user-configured http_access rules
  http_access deny usuallyDenied
  http_access allow manager

  # always added at the bottom of user-configured http_access rules
  http_access allow usuallyAllowed
  http_access deny all

And remove all of the http_access rules from squid.conf.default.

The admin will be able to adjust usuallyDenied, usuallyAllowed, and
manager any-of ACLs to effectively disable them (just like in your
proposal). And we can add an optimizer to remove effectively disabled ACLs.


> the proposed rename of SSL_ports to CONNECT_ports

Let's discuss the exact ACL names later (when/if there is a principle
agreement to implement the proposed changes). For now, I will only note
that we should not use ACL names that might clash with those used by
existing configurations (for hopefully obvious reasons).


Thank you,

Alex.



More information about the squid-users mailing list