On 14/08/2012 8:32 p.m., Eugene M. Zheganin wrote:
Hi.
Since I always receive comprehensive answers here I decided to ask
about one more long existed problem.
I use squids in corporate environment along with traffic quotas and
custom deny info pages. Yeah, flatrated internet came long ago in
Russia too, but my supervisors think that limiting the traffic is
still an effective way of fighting slackers.
So, the goal is to show a page 'you're not authorized' to unauthorized
users (bad username/password pair, or no username, or intercepted
traffic), 'this is denied' page on some restricted URLs, and mostly -
'you're out of traffic' to users with no traffic left. Here I step on
one thing that is keeping me away from that. Imagine I have similar
config:
acl unauthorized proxy_auth -
acl no-traffic-left external self-written-script
acl allowed-users external some-LDAP-checking
acl some-other-users external some-LDAP-checking
http_access deny unauthorized
http_access deny no-traffic-left
http_access allow allowed-users
http_access deny all
deny_info NOTRAFFIC no-traffic-left
deny_info UNAUTHORIZED unauthorized
deny_info NOACCESS all
So, to the actual point. I will simply describe how it does work from
my experience. So, imagine user 'foobar' is trying to get the access.
It matches both the no-traffic-left and the allowed-users ACLs.
Futhermore, allowed-users is a group of users. In a configuration
above, when squid will receive the 'foobar' username on the
'http_access deny no-traffic-left' line, it won't block the foobar
user, but instead it will reprompt for the credentials. So, in order
to actually block users like foobar, I need to say something about
src, like this:
http_access deny unauthorized all
That is where you are going bad. Since it is re-challenging its clear
you use %LOGIN for that external helper. What you actually need is:
acl no_traffic src all
http_access deny no-traffic-left no_traffic
deny_info NOTRAFFIC no_traffic
(and remove the "deny_info NOTRAFFIC no-traffic-left")
This way squid will immidiately block such users. But, here the
problem comes: last matching ACL will be 'all', so I'm unable to tell
users with no traffic why exaclty they are blocked. I tried the way
http_access deny all unauthorized
But it works the same way as the line without 'all', - it keeps
reprompting for the passwords. It looks like 'hey, do you know some
other password, so I can grant you an access ?'. Is there any
possibility of ... in the term of packet filters, say to squid 'block
it immidiately' ? The way 'quick' works in pf, or, if you prefer, the
same way the 'L' flag works in apache's mod_rewrite ? I mean, I need a
mechanism of saying that this rule should actually be the last if it
matches. And the other question - I have a feeling that this happens
only if a username matches more that one proxy_auth ACL. For example
this doesn't happen to the user '-', or any other fake user (I was
using for a long time the fake username to represent the entity
without credentials).
No. It happens if "deny" is the operation to perform on any ACL which
tests user credentials (proxy_auth ACL type or external type with %LOGIN
in the format).
Amos
