Re: [squid-users] Issue with access list / download

On 28.11.2012 05:11, Will I am wrote:
> Hi there,
>
> I try to set up some rights but I failed :
>
> I would like to set rights like this :
>
> FULL_ACCESS full acces ... no restriction
> STD_PLUS just limited download to 100 MB + some files are
> blocked ( exe, doc, etc ...)
> STD limited to download to 16 MB + some files are
> blocked (exe, doc, etc ...)
> NO_ACCESS No internet
>
> Could you please check my access list and tell me what's wrong ?
> Indeed users who is in STD group can download
> unlimited and same thing with STD_PLUS group.
> However, if comment these lines :
>
> #reply_body_max_size 100 MB Internetplus
> #http_access allow Internetplus
>
> STD group is limited to 16 MB and STD_PLUS group as well.
>
> Any help ?

Squid version? the behaviour you describe is the 2.7 behaviour before
ACLs control was added to reply_body_max_size. But I don't see some of
the squid-2.x specific config definitions.

> ------------------------------
>
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>
> auth_param ntlm program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 30
>
> auth_param basic program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-basic
> auth_param basic children 5
> auth_param basic realm Proxy Web LESIEUR
> auth_param basic credentialsttl 4 hours
> auth_param basic casesensitive off
>
> external_acl_type ad_group %LOGIN /usr/lib/squid/wbinfo_group.pl
>
> #
>
> -----------------------------------------------------------------------------
> # DEFINITION DES ACCESS CONTROL LIST
> #
>
> -----------------------------------------------------------------------------
>
> acl asn_hosts src 10.68.10.0/23
>
> acl whitelist dstdomain "/etc/squid/sites.whitelist.txt"
> acl blockfiles urlpath_regex "/etc/squid/blocks.files.acl"
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dst 127.0.0.0/8
> acl SSL_ports port 443 21
> acl safe_ports port 161 # boitier eRemote
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistred 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 Safe_ports port 8080

NP: notice how 8080 is in the range "1025-65535 # unregistred ports".

You can reduce your config by removing that line.

> acl purge method PURGE
> acl CONNECT method CONNECT
> acl snmppublic snmp_community public
> acl ftp proto 21

NP: '21://' is not a valid URL scheme. This should be having no effect.

Try:
  acl FTP proto FTP

> acl Internetlimite external ad_group STD
> acl Internetplus external ad_group STD_PLUS
> acl InternetFullAccess external ad_group FULL_ACCESS
> acl InternetNok external ad_group NO_ACCESS
> acl password proxy_auth REQUIRED
>
>
> #---------------------------------------------------------------------------------
> # LISTE DES AUTORISATTIONS
>
> #---------------------------------------------------------------------------------
>
> http_access deny InternetNok
> http_access allow whitelist
> http_access allow CONNECT whitelist

NP: 'allow whitelist' is already done. Adding CONNECT as an extra
condition does nothing but waste CPU on non-whitelisted requests.

> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow manager localhost
> http_access deny manager
> http_access allow purge
> http_access deny purge

NP: purge is already allowed for any user (logged in or not), this
'deny' does nothing but waste CPU on all non-PURGE requests.

> http_access allow asn_hosts
> http_access deny !password

NP: you have 'deny InternetNok' above which requires %LOGIN in order to
be checked.
In other words, nobody without a password will get past 'deny
InternetNok' and this 'deny !password' does nothing.

> http_access allow password

The beginning of your noticed problem is that anyone who can login is
allowed before group gets checked by http_access controls.
reply_body_max_size is a 'fast' type control which does not wait for its
own external ACL lookups to complete.
  I think if you look very closely you will find each user gets at least
one 'free' request of any size before either limit is applied. As the
first request hits reply_body_max_size a new group check is triggerd,
but not waiting for it to have an answer the ACL fails to match (next
requests might use the result from request #1).

Remove the above "http_access allow password" and things should work as
you expect. *IF* this is a 3.0 or later version Squid.

*if* the problem remains in a 3.0-3.2 version Squid try adding 'all' as
the last (right-hand side) ACL on the reply_body_max_size lines. They
should not be invalidating credentials and preparing a challenge, but
there are some bugs in the older Squid external_acl handling which can
cause that to happen. If you find that this 'all' hack works, please
report it to bugzilla with the relevant details about your Squid.

Amos
Received on Wed Nov 28 2012 - 00:56:06 MST