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

[Amos Jeffries]

On 13/04/2017 1:15 p.m., Alex Rousskov wrote:
> On 04/12/2017 12:16 PM, Amos Jeffries wrote:
> 
>> Changes to http_access defaults
> 
> Clearly stating what you are trying to accomplish with these changes may
> help others evaluate your proposal. Your initial email focuses on _how_
> you are going to accomplish some implied/vague goal. What is the goal here?
> 

I've have two goals here:

1) reduce peoples ability to shoot themselves in the foot.

 This is an ongoing problem with newbies and even with more experienced
naive people.
 But there are some few cases where foot shooting is the local sport and
we have to let it happen.


2) further reduce the things people are required to manually configure
in squid.conf to get a usable Squid.

Telling people where to put their custom rules in relation to these
settings is getting to be a rather monotonous problem.

ALso, sometimes it is not easy to find the right words to describe the
location when language/knowledge barriers or previous screwing up of
squid.conf contents gets in the way.


I have the idea that we can do this porposal or something equivalent to
get rid of these problems with a technical fix for the long-term.

> 
>> I have become convinced that Squid always checks those
>> security rules, then do the custom access rules. All other orderings
>> seem to have turned out to be problematic and security-buggy in some
>> edge cases or another.
> 
> s/Squid always checks/Squid should always check/
> 

Oops. Yes. Thank you for that.

> 
>> What are peoples opinions about making the following items built-in
>> defaults?
>>
>>  acl Safe_ports port 21 80 443
>>  acl CONNECT_ports port 443
>>  acl CONNECT method CONNECT
>>
>>  http_acces deny !Safe_ports
>>  http_access deny CONNECT !CONNECT_ports
> 
>> The above change will have some effect on installations that try to use
>> an empty squid.conf.
> 
> And on many other existing installations, of course, especially on those
> with complex access rules which are usually the most difficult to
> modify/adjust. In other words, this is a pretty serious change.
> 
> 
>> If the proposal goes ahead some extra additions
>> would be included to retain that default-reject behaviour.
> 
> It is difficult to properly evaluate your proposal until it details how
> one would be able to override the proposed defaults.

Okay. As I mentioned to yuri's post:

 acl Safe_ports port 0-65535
 acl CONNECT_ports port 0-65535


NP: s/CONNECT_pors/SSL_ports/ depending on whether the name change there
happens or not. I had initially the idea that detecting the SSL_ports
existence as a way to determine between old and new configs. Similar to
the deny_unsafe_ports approach you propose below.


> These defaults, in
> some shape or form, make sense for most installations, of course. The
> difficult parts are:
> 
> * minimizing surprises (e.g, when the hidden defaults change, are wrong,
> and/or interact with deny_info rules in surprising ways);
> 
> * avoiding configurations that compute essentially the same rules
> multiple times (hidden defaults + explicit defaults); and
> 
> * designing a configuration approach to overwrite defaults without
> either screwing up a lot of admins or virtually eliminating the positive
> effect of those defaults in new configurations.
> 
> 
> To address the last bullet, we could add a
> 
>   deny_unsafe_ports <on|off>
> 
> directive.
> 
> If that directive is "on" by default [for any squid.conf that does not
> define a Safe_ports ACL??], then it does not address the first two
> bullets well.
> 
> Perhaps it should be off by default but explicitly added (and turned
> "on") to every newly generated squid.conf.default?
> 

If it is on by default unless we have reason to turn it off, we have
trouble with all the intentional open-proxy or similar configs.

If it is off by default unless we have reason to turn it on. That does
not help at all for newbie admin installs which most need it to be on by
default.


With Safe_ports being a default too, the detect would have to be based
on SSL_ports. In which case, we may as well use an internal boolean
check for SSL_ports as the detection of old installation instead of
putting anything confusing in front of newbie admin.
 - this will also catch the case of newbie cut-n-pasting old configs.

However, that still leaves us with trouble for all the intentional
open-proxy or similar configs. They will still have surprise blocking of
unsafe traffic until config gets adjusted.

> 
> Also, how will the http_access rules in newly generated
> squid.conf.default look like if we add default http_access rules?
> 

I expect it would look like it does now but without the top two deny rules:

  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 am worried that adding hidden default http_access rules will make
> things overall worse rather than solving the problem you are trying to
> solve. I wonder if fiddling with http_access internals might be the
> wrong direction here.
> 
> 
> Thank you,
> 
> Alex.
> 

Noted. Thank you for the feedback.

Amos