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