Re: [squid-users] ext_user ACL

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 10 Feb 2012 15:19:24 +1300

On 10/02/2012 6:20 a.m., Wladner Klimach wrote:
> Amos,
>
> look at this:
>
> ACL::ChecklistMatches: result for 'restrictedDomains' is 1
> 2012/02/09 15:16:00.498| ACLList::matches: result is true
> 2012/02/09 15:16:00.498| ACLList::matches: checking restrictUsers
> 2012/02/09 15:16:00.498| ACL::checklistMatches: checking 'restrictUsers'
> 2012/02/09 15:16:00.498| ACL::cacheMatchAcl: cache hit on acl
> 'restrictUsers' (0x7f402fb23e40)
> 2012/02/09 15:16:00.498| ACL::ChecklistMatches: result for 'restrictUsers' is 1
> 2012/02/09 15:16:00.498| ACLList::matches: result is true
> 2012/02/09 15:16:00.498| aclmatchAclList: 0x7f40304547d8 returning
> true (AND list satisfied)
> 2012/02/09 15:16:00.498| ACLChecklist::markFinished: 0x7f40304547d8
> checklist processing finished
> 2012/02/09 15:16:00.498| ACLChecklist::check: 0x7f40304547d8 match
> found, calling back with 0
> 2012/02/09 15:16:00.498| ACLFilledChecklist::checkCallback:
> 0x7f40304547d8 answer=0
> 2012/02/09 15:16:00.498| ACLChecklist::checkCallback: 0x7f40304547d8 answer=0
> 2012/02/09 15:16:00.498| aclIsProxyAuth: called for restrictUsers
> 2012/02/09 15:16:00.498| ACL::FindByName 'restrictUsers'
> 2012/02/09 15:16:00.498| aclIsProxyAuth: returning 1
> 2012/02/09 15:16:00.498| Gadgets.cc(57) aclGetDenyInfoPage: got called
> for restrictUsers
> 2012/02/09 15:16:00.498| aclGetDenyInfoPage: no match
>
>
> Even though the logs show as squid blocking one page, at the browser I

Re: "What's the problem?"

  That only shows Squid matching "deny restrictedDomains restrictUsers"
and looking for a page to send in the 407 response created by
aclIsProxyAuth.
  It may be the first of several such sequences, while the browser tries
to find some credentials which Squid will accept. Ending in an allowed.

There is not enough to see the browser actually getting the page load.
You will need to keep following the trace further to see what was sent
back to the browser, and whether that is actually the request which your
successful access result came from.

> still can access it. Here is my .conf:
>
> auth_param negotiate program
> /etc/squid/squid-3.1.16/helpers/negotiate_auth/squid_kerb_auth/squid_kerb_auth
> -s HTTP/trotsky.example.com
> auth_param negotiate children 10
> auth_param negotiate keep_alive on
>
> # ACLs externas para buscar grupo baseado em Kerberos.
> external_acl_type squid_kerb_ldap ttl=3600 negative_ttl=3600 %LOGIN
> /etc/squid/squid-3.1.16/squid_kerb_ldap/squid_kerb_ldap -S
> californio.example.com -g
> Internet_at_EXAMPLE.COM
> ##################
> visible_hostname example.com
> dns_nameservers 127.0.0.1
> append_domain .camara.gov.br
> hierarchy_stoplist cgi-bin ?
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
>
> follow_x_forwarded_for allow localhost
>
> # Recommended minimum configuration:
> #
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl SSL_ports port 443
> acl SSL_ports port 1863
> acl SSL_ports port 563
> acl SSL_ports port 465
> acl SSL_ports port 995
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 563 # https
> acl Safe_ports port 465 # https
> acl Safe_ports port 995 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
> acl QUERY urlpath_regex cgi-bin \?
> no_cache deny QUERY
>
> # Recommended minimum Access Permission configuration:
> #
> acl AUTENTICADO proxy_auth REQUIRED
> # Only allow cachemgr access from localhost
> acl ldap_group_check external squid_kerb_ldap
> acl Maquinas_Portaria src "/etc/squid/Maquinas_Portaria.txt"
> acl Horario_Portaria time MTWHF 7:00-20:00
> http_access deny Maquinas_Portaria Horario_Portaria
> acl Horario_youtube time TWH 9:00-20:00
> acl bloqueio-youtube dstdomain www.youtube.com
> http_access deny bloqueio-youtube Horario_youtube
> acl restrictUsers proxy_auth P_7501_at_EXAMPLE.COM
> acl restrictedDomains url_regex -i "/etc/squid/InstantMessenger"
> http_access deny restrictedDomains restrictUsers

Denies if the user *is* logged in. Okay as an idea, but if the user is
NOT logged in it will request credentials until one of the restrictUsers
set is given. You can stick " all" at the end of that access line to
skip challenging for credentials for other users and not logged in users.

> http_access allow ldap_group_check

Unlimited access to anyone in the group unless they are visiting
youtube, using Instant Messager, or one of the Maquinas_Portaria machines.

This has a big security holes. These people are allowed management
access to your proxy, access unsafe ports, and to relay traffic through
your proxy with CONNECT tunnels whenever they please.
  Notice how they can use CONNECT to a proxy outside your network to get
access to Youtube and use Instant Messager despite your controls. This
is why the CONNECT security rule is recommended to be above your users
allow rules.

> #http_access allow AUTENTICADO
> #http_access allow localnet
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny to_localhost
>
> http_access allow CONNECT SSL_Ports

This is also a broken inversion of the security protections. It permits
CONNECT tunnels to be made to anywhere if it was a port in SSL_Ports.
The whole idea of the default security is to block non-SSL ports, not to
permit unlimited access to SSL ports. Thus the particular form of:

     http_access deny CONNECT !SSL_Ports

... and also why it is recommended to be above any other allow rules for
your clients.

The set starting from "allow manager localhost" down to "deny
to_localhost" are similar protections, also recommended to be run first
before any client allow rules.

> http_access deny all
>
>
> What's the problem?
>
> Regards,
>
> Wladner
>

Amos
Received on Fri Feb 10 2012 - 02:19:32 MST

This archive was generated by hypermail 2.2.0 : Fri Feb 10 2012 - 12:00:03 MST