[squid-users] Any suggestions or comments about my configuration? squid 3.5.20

[Amos Jeffries]

On 20/09/18 8:52 AM, Service MV wrote:
> Dear Ones, the more I use Squid the more I realize how powerful it is.
> And like all powerful software it can be complex at first.
> I would like to share my settings and if possible listen (read actually)
> your comments and suggestions.
> My goals of using squid:
> - Transparent authentication of my AD users (2012R2)
> - Internet access rules based on users belonging to AD groups.
> - Non-authenticated clients (Win PCs) cannot navigate through the proxy.
> - That the clients (Win PCs) not belonging to an AD group allowed in
> squid, cannot navigate through the proxy.
> 
> My test scenario:
> - A VM CentOS 7 Core over VirtualBox 5.2, 1 NIC.
> - My VM is attached to my domain W2012R2 (following this
> post https://www.rootusers.com/how-to-join-centos-linux-to-an-active-directory-domain/)
> to achieve kerberos authentication transparent to the user. SElinux
> disabled. Owner permissions to user squid in all folders/files involved.
> - squid 3.5.20 installed and working great with kerberos, NTLM and basic
> authentication.
> 
> squid.conf
> ### negotiate kerberos & ntlm authentication

FYI: the technical terms for these are Negotiate/NTLM and
Negotiate/Kerberos.  With the '/' being part of the type name, not the
usual meaning of alternative words.

> auth_param negotiate program /usr/sbin/negotiate_wrapper --ntlm
> /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --kerberos
> /usr/lib64/squid/negotiate_kerberos_auth -r -i -s GSS_C_NO_NAME 
> auth_param negotiate children 10 
> auth_param negotiate keep_alive on
>
...
> 
> ### LDAP group membership sources
> # WEB_ACCESS_1
> external_acl_type AD_WEB_ACCESS_1 %LOGIN
> /usr/lib64/squid/ext_ldap_group_acl -P -R -b OU=USERS,DC=netgol,DC=local
> -D ldap -W "/etc/squid/ldap_pass.txt" -f
> (&(sAMAccountName=%u)(memberOf=cn=WEB_ACCESS_1,OU=INTERNET,OU=PERMISOS,OU=NETGOL,DC=netgol,DC=local))
> -h s-dc1.netgol.local -p 3268
> acl WEB_ACCESS_1 external AD_WEB_ACCESS_1 web-access-1
> 
> # WEB_ACCESS_2
> external_acl_type AD_WEB_ACCESS_2 %LOGIN
> /usr/lib64/squid/ext_ldap_group_acl -P -R -b OU=USERS,DC=netgol,DC=local
> -D ldap -W "/etc/squid/ldap_pass.txt" -f
> (&(sAMAccountName=%u)(memberOf=cn=WEB_ACCESS_2,OU=INTERNET,OU=PERMISOS,OU=NETGOL,DC=netgol,DC=local))
> -h s-dc1.netgol.local -p 3268
> acl WEB_ACCESS_2 external AD_WEB_ACCESS_2 web-access-2
> 
> # WEB_ACCESS_3
> external_acl_type AD_WEB_ACCESS_3 %LOGIN
> /usr/lib64/squid/ext_ldap_group_acl -P -R -b OU=USERS,DC=netgol,DC=local
> -D ldap -W "/etc/squid/ldap_pass.txt" -f
> (&(sAMAccountName=%u)(memberOf=cn=WEB_ACCESS_3,OU=INTERNET,OU=PERMISOS,OU=NETGOL,DC=netgol,DC=local))
> -h s-dc1.netgol.local -p 3268
> acl WEB_ACCESS_3 external AD_WEB_ACCESS_3 web-access-3

I notice several useful things about these external_acl_type definitions:

 1) that they are identical except for the "memberOf=cn=WEB_ACCESS_"
string in the LDAP query.

 2) that the group name you pass the helper ("web-access-1/2/3") is
never actually used (no %g in the filter syntax).

That means you can simplify quite a lot just by passing the real group
name to the helper and using %g.

  external_acl_type AD_WEB_ACCESS %LOGIN \
    /usr/lib64/squid/ext_ldap_group_acl -P -R \
   -b OU=USERS,DC=netgol,DC=local \
   -D ldap -W "/etc/squid/ldap_pass.txt" \
  -f
"(&(sAMAccountName=%u)(memberOf=cn=%g,OU=INTERNET,OU=PERMISOS,OU=NETGOL,DC=netgol,DC=local))"
\
  -h s-dc1.netgol.local -p 3268


   acl WEB_ACCESS_1 external AD_WEB_ACCESS WEB_ACCESS_1
   acl WEB_ACCESS_2 external AD_WEB_ACCESS WEB_ACCESS_2
   acl WEB_ACCESS_3 external AD_WEB_ACCESS WEB_ACCESS_3



(I suspect there is something you can do to simplify the AD tree for -b
and -f LDAP parameters. But someone more familiar with LDAP syntax will
have to go over that.)

> 
> ### HTTP access control policies
> http_access deny !Safe_ports 
> http_access deny CONNECT !SSL_ports 
> http_access allow localhost manager 
> http_access deny manager

Your policy said:
 "Non-authenticated clients (Win PCs) cannot navigate through the proxy."

So what you need to start with in your custom rules, is one which says
only that not-auth clients are forbidden.

 acl auth proxy_auth REQUIRED
 http_access deny !auth

... now to reach the below tests a client *must* be logged in. You can
safely assume that credentials are available for all tests below.


FYI: Squid will send an auth-challenge denial instead of a regular
forbid error page. If your clients are logged into AD correctly they
will authenticate transparently as you wish. If the client is *not*
logged into the domain they *might* see a popup - that has nothing to do
with Squid and can only be resolved at the browser.
  Note that Squid will have already been doing this for the external
ACLs, but this is a simpler and clearer way to write the config which
also allows you to make the group checks send a hard 403 forbidden
instead of having to always allow clients to re-login.



> http_access deny WEB_ACCESS_1 LS_malicius
> http_access deny WEB_ACCESS_2 LS_malicius
> http_access deny WEB_ACCESS_3 LS_malicius

Since none of the groups is allowed to LS_malicius you do not actually
have to know what group they are in to block that traffic.

Just use:
 http_access deny LS_malicius

You can further optimize performance by placing that above the login
line. Since login is a waste of cycles if you are only going to reject.

The only reason you might want to deny here is to log which user was
trying to go there (infected?). So you need to decide if that log detail
is worth the slower performance and heavier load on AD. The performance
benefit varies by network and may be extremely small (or not) - so you
may want to experiment and measure.


> http_access deny WEB_ACCESS_1 LS_remotecontrol
> http_access deny WEB_ACCESS_2 LS_remotecontrol

Similar, but slightly different here for LS_remotecontrol.

In this case note that group #3 is about to be allowed to do anythign,
including this traffic. So you can allow them now:

 http_access allow WEB_ACCESS_3

... then do the denial for the remaining groups without needing to check
which group is which.

   http_access deny LS_remotecontrol

... then the regular group #1 and #2 allow.

> http_access allow WEB_ACCESS_1
> http_access allow WEB_ACCESS_2

> http_access allow localhost

Your policy statements do not mention anything about localhost traffic
being allowed to use the proxy. Is this something you can remove?


> http_access deny all
> 

So to summarize, you http_access should look like this (modulo your
localhost decision):


  ### HTTP access control policies
  http_access deny !Safe_ports
  http_access deny CONNECT !SSL_ports
  http_access allow localhost manager
  http_access deny manager
  http_access deny !auth
  http_access allow localhost
  http_access deny LS_malicius
  http_access allow WEB_ACCESS_3
  http_access deny LS_remotecontrol
  http_access allow WEB_ACCESS_1
  http_access allow WEB_ACCESS_2
  http_access deny all



> ### personalization ###
> http_port 8080 
> coredump_dir /var/spool/squid 
> refresh_pattern ^ftp: 1440 20% 10080 
> refresh_pattern ^gopher: 1440 0% 1440 
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 
> refresh_pattern .  0 20% 4320 
> quick_abort_min 0 KB 
> quick_abort_max 0 KB 
> read_timeout 5 minutes 
> request_timeout 3 minutes 
> half_closed_clients off 
> shutdown_lifetime 15 seconds 
> log_icp_queries off 
> dns_v4_first on 
> ipcache_size 2048 
> ipcache_low 90 
> fqdncache_size 4096 
> forwarded_for off 
> cache_mgr system at netgol.net
> visible_hostname proxy.netgol.local 
> httpd_suppress_version_string on 
> uri_whitespace strip
> logfile_rotate 7
> debug_options rotate=7
> 

In the above, you might want to add config comments for yourself
mentioning why each of the above is different from the defaults.

If they are just copy-paste from a tutorial without understanding why,
then maybe the defaults are fine for your needs.

Some of what you have above *are* the modern defaults which do not need
configuring (eg half_closed_clients, uri_whitespace, ipcache_low, maybe
coredump_dir).

Some are irrelevant. eg log_icp_queries is pointless when ICP is
disabled by default, "debug_options rotate=N" defaults to the
logfile_rotate value.

Some are intended to resolve quite specific issues which are not
relevant on most networks (eg dns_v4_first, forwarded_for,
visible_hostname, half_closed_clients) and you may actually need
different settings than people commonly paste blindly into web
tutorials. Read the docs for those options particularly the descriptions
of use-cases, caveats, and any WARNINGS / NOTICE text.


And last but not least - always run "squid -k parse" after changing
config or upgrading the proxy.  Squid can detect a large number of
config problems and tells you about them, usually with instructions on
how to resolve it.


HTH
Amos