[RFC] Changes to http_access defaults

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[RFC] Changes to http_access defaults

Amos Jeffries
Administrator
When I implemented the major changes to squid.conf in 3.1/3.2  there
were a lot of installations placing custom config rules above the lines
I describe now as "default security checks". The !Safe_ports and
!SSL_ports deny lines.

At the time I also believed reverse-proxy config had to go above that to
work properly. Which was the major argument behind leaving them manually
configured.

That reverse-proxy reason has turned out to be incorrect and over the
years since 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.


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


This makes the three protocols Squid-4/5 can officially support (HTTP,
HTTPS, FTP) acceptable by default.

I have excluded the other protocols that are safe, but usually not
necessary to proxy in modern traffic. They can remain 'recommended'
configurable defaults like today.

Likewise the manager rules (for now) since local conditions can
sometimes allow them to be optimized better than our current recommended
default.


The above change will have some effect on installations that try to use
an empty squid.conf. If the proposal goes ahead some extra additions
would be included to retain that default-reject behaviour.

Ideas? opinions?


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Alex Rousskov
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 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/


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


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


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.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Dan Purgert
Quoting Alex Rousskov <[hidden email]>:

> 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 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/
>
>
>> 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.
>
>
How would a "built-in default" alter an existing setup? I mean, in  
every other instance that I can think of, if the config file includes  
the directive, the config file's version overrides the default ...

--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (1K) Download Attachment
attachment1 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Yuri Voinov



13.04.2017 21:14, Dan Purgert пишет:
Quoting Alex Rousskov [hidden email]:

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


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.



How would a "built-in default" alter an existing setup? I mean, in every other instance that I can think of, if the config file includes the directive, the config file's version overrides the default ...
This is normal behaviour. System administrator should have possibility to override ANY default.



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

--
Bugs to the Future

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Alex Rousskov
On 04/13/2017 09:58 AM, Yuri Voinov wrote:
> 13.04.2017 21:14, Dan Purgert пишет:

>> How would a "built-in default" alter an existing setup? I mean, in
>> every other instance that I can think of, if the config file includes
>> the directive, the config file's version overrides the default ...

> This is normal behaviour. System administrator should have possibility
> to override ANY default.

That much is understood. What is not yet clear are the exact conditions
under which those defaults disappear. This is one of the two primary
questions the RFC does not answer yet (the other one being what exactly
this change is actually trying to accomplish).

"Normally", foo_bar defaults disappear at the first sign of an explicit
foo_bar rule in squid.conf. However, that will probably defeat the
(unspecified) purpose of supporting http_access defaults because every
Squid needs non-default http_access rules!

The suspected uselessness of "normal" behavior is exactly why those two
questions must be answered in the updated version of the RFC.

My earlier response sketched one way to add http_access defaults that do
not disappear so easily that they become useless (see
deny_unsafe_ports), but that idea has its own serious flaws. The "many
folks misconfigure access rules" problem may not have a good solution
(under Squid control); we should be careful not to make things worse
while not solving the unsolvable problem.

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

Alex Rousskov
On 04/13/2017 10:39 AM, Alex Rousskov wrote:

> The "many folks misconfigure access rules" problem may not have a
> good solution (under Squid control); we should be careful not to make
> things worse while not solving the unsolvable problem.


Here is an alternative idea: Instead of adding default http_access rules
inside Squid, add an optional squid.conf lint/checker. For many
configurations, especially the simple ones used by new Squid admins, it
is fairly easy to _automatically_ check whether these default rules are
violated.

If these rules are violated, Squid will log a startup warning like this:

  WARNING: Your http_access rules allow CONNECT to unsafe port XXX.
  More info at http://...?warning=xyz&port=XXX.

The URL will detail the dangers and also explain how to disable this
specific warning or linting as a whole.

I can discuss/detail this further if there is consensus that automated
checking is overall better than built-in http_access defaults.
Unfortunately, I do not have the time to volunteer an implementation.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

joseph
Alex Rousskov wrote
On 04/13/2017 10:39 AM, Alex Rousskov wrote:

> The "many folks misconfigure access rules" problem may not have a
> good solution (under Squid control); we should be careful not to make
> things worse while not solving the unsolvable problem.


Here is an alternative idea: Instead of adding default http_access rules
inside Squid, add an optional squid.conf lint/checker. For many
configurations, especially the simple ones used by new Squid admins, it
is fairly easy to _automatically_ check whether these default rules are
violated.

If these rules are violated, Squid will log a startup warning like this:

  WARNING: Your http_access rules allow CONNECT to unsafe port XXX.
  More info at http://...?warning=xyz&port=XXX.

The URL will detail the dangers and also explain how to disable this
specific warning or linting as a whole.

I can discuss/detail this further if there is consensus that automated
checking is overall better than built-in http_access defaults.
Unfortunately, I do not have the time to volunteer an implementation.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
agreed on the warning part only  :)
 as yuri said --> System administrator should have possibility to override ANY default.
{ANY == ANY}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Amos Jeffries
Administrator
In reply to this post by Dan Purgert
On 14/04/2017 3:14 a.m., Dan Purgert wrote:

> Quoting Alex Rousskov <[hidden email]>:
>
>> 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 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/
>>
>>
>>> 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.
>>
>>
>
> How would a "built-in default" alter an existing setup? I mean, in every
> other instance that I can think of, if the config file includes the
> directive, the config file's version overrides the default ...
>

The way built-in's are generally done in Squid is to have a set of lines
that are hard-coded and treated as existing "above" the first line of
squid.conf.

For existing setups where non-443 ports were desired with CONNECT this
approach would mean admin have to list them in SSL_ports/CONNECT_ports
instead of simply removing all lines mentioning "SSL_Ports".

That is really a practice people should be doing anyway, so is this
change from whatever you are doing to a way that enforces best-practice
going to be a major issue for anyone?


[That is part of the reason I've sent this RFC to all of squid-users,
instead of just squid-dev. To see what sort of issues people will have
with that kind of change, and how widespread the trouble would be.]

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Amos Jeffries
Administrator
In reply to this post by Yuri Voinov
On 14/04/2017 3:58 a.m., Yuri Voinov wrote:

>
>
> 13.04.2017 21:14, Dan Purgert пишет:
>> Quoting Alex Rousskov <[hidden email]>:
>>
>>> 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 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/
>>>
>>>
>>>> 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.
>>>
>>>
>>
>> How would a "built-in default" alter an existing setup? I mean, in
>> every other instance that I can think of, if the config file includes
>> the directive, the config file's version overrides the default ...
> This is normal behaviour. System administrator should have possibility
> to override ANY default.

Yes, and override remains possible. Just in a way that does not involve
deleting lines from squid.conf.

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.

For example;

 today to make Squid an open proxy you _erase_ these lines:

  http_access deny !Safe_ports
  http_access deny CONNECT !SSL_ports

Alternatively you can also *add* these lines:

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

That second way will work both before and after the proposed change.
(Module the proposed rename of SSL_ports to CONNECT_ports). This makes
it a little but harder for newbies or naive people to get themselves
into trouble, without removing ability for advanced needs.


As Alex pointed out it does mean change for anyone with those advanced
configs. So it is a matter of whether the pain is too great or there is
a better way. Thus 'RFC' to everyone.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squid-dev] [RFC] Changes to http_access defaults

Amos Jeffries
Administrator
In reply to this post by Alex Rousskov
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


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

Amos Jeffries
Administrator
In reply to this post by Alex Rousskov
On 14/04/2017 4:52 a.m., Alex Rousskov wrote:
> On 04/13/2017 10:39 AM, Alex Rousskov wrote:
>
>> The "many folks misconfigure access rules" problem may not have a
>> good solution (under Squid control); we should be careful not to make
>> things worse while not solving the unsolvable problem.
>
>
> Here is an alternative idea: Instead of adding default http_access rules
> inside Squid, add an optional squid.conf lint/checker.

We have a lint checker in "-k parse" and "-k check" anyway. That is not
going away and these kind of checks are a good idea regardless of what
the built-in default config is.

So that is not an exclusive alternative. It is something we will need to
do along with (or before) the config changes.


> For many
> configurations, especially the simple ones used by new Squid admins, it
> is fairly easy to _automatically_ check whether these default rules are
> violated.
>
> If these rules are violated, Squid will log a startup warning like this:
>
>   WARNING: Your http_access rules allow CONNECT to unsafe port XXX.
>   More info at http://...?warning=xyz&port=XXX.
>
> The URL will detail the dangers and also explain how to disable this
> specific warning or linting as a whole.
>
> I can discuss/detail this further if there is consensus that automated
> checking is overall better than built-in http_access defaults.
> Unfortunately, I do not have the time to volunteer an implementation.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

Alex Rousskov
In reply to this post by joseph
On 04/14/2017 04:19 AM, joseph wrote:

> System administrator should have possibility to override ANY default.

I do not know why you are saying the above. AFAIK, everybody is in
agreement that admins should be able to overwrite any defaults, at least
at the level of the configured Squid functionality.

Folks may object to hidden http_access rules that admins can configure
to do nothing (i.e., have no effect on Squid functionality) but cannot
_remove_, but I do not think you are talking about that aspect. I
certainly was not.

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

Matus UHLAR - fantomas
In reply to this post by Amos Jeffries
On 13.04.17 06:16, Amos Jeffries wrote:
>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

shouldn't that be more like following?

acl Safe_ports port 80
acl CONNECT_ports port 21 443

> http_acces deny !Safe_ports
> http_access deny CONNECT !CONNECT_ports



--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
(R)etry, (A)bort, (C)ancer
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

Alex Rousskov
In reply to this post by Amos Jeffries
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.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] Changes to http_access defaults

Amos Jeffries
Administrator
In reply to this post by Matus UHLAR - fantomas
On 15/04/2017 3:22 a.m., Matus UHLAR - fantomas wrote:

> On 13.04.17 06:16, Amos Jeffries wrote:
>> 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
>
> shouldn't that be more like following?
>
> acl Safe_ports port 80
> acl CONNECT_ports port 21 443
>
>> http_acces deny !Safe_ports
>> http_access deny CONNECT !CONNECT_ports
>
>

No. The !Safe_ports would deny port 21 and 443 usage.

SSL_ports/CONNECT_ports is a sub-set of safe ports whre CONNECT is also
potentially permitted.

Amos


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Loading...