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