On 25/05/24 07:28, Kevin wrote:
Hi,
We have 2 external ACLs that take a request's data (IP, authenticated
username, URL, user-agent, etc) and uses that information to determine
whether a user or host should be permitted to access that URL. It
almost always works well, but we have a recurring occasional issue that
I can't figure out.
When it occurs, it's always around 4AM. This particular request occurs
often - averages about once a second throughout the day.
What we see is a "403 forbidden" for a (should be) permitted site from
an authenticated user from the same IP/user and to the same site that
gets a "202 connection established" every other time.
Is maybe 4am the time when your auth system refreshes all nonce?
- thus making any currently in-use by the clients invalid until they
re-auth. You might see a mix of 403/401/407 in a bunch at such times.
Or maybe in a similar style one/some of the clients is broken and fails
to update its nonce before it expires at 4am?
- looking at which client agent and IP were getting the 403 and/or the
nonce which received 403 will give you hints about this possibility.
Or your network router(s) do garbage collection and terminate
long-running connections to free up TCP resources?
- thus forcing a lot of client re-connects at 4am, which may:
a) overload the auth system/helper, or
b) break a transaction that included nonce update for clients -
resulting in their next request being invalid nonce.
Or maybe you have log processing software that does "squid -k restart"
instead of the proper "squid -k rotate" to get access to the log files?
Or maybe your auth system has a limit on how large nonce-count can become?
- I notice that the working request has 0x2F uses and the forbidden
has 0x35 (suspiciously close to 50 in decimal)
The difference I see in the logs: though all the digest auth info looks
okay, the %un field in the log for the usual (successful) request is the
authenticated username, while in the failed request, it's "-". So
though there hasn't been an authentication error or "authentication
required" in the log - and the username is in the authentication details
in the log entry - it seems like squid isn't recognizing that username
as %un.
Be aware that a properly behaving client will *not* send credentials
until they are requested, after which it should *always* send
credentials on that same connection (even if they are not requested
explicitly).
That means some requests on a multiplex/pipeline/keep-alive connection
MAY arrive with credentials and be accepted(2xx)/denied(403) without
authentication having occured. Entirely due to your *_access directives
sequence. In these cases the log will show auth headers but no value for
%un and/or %ul.
My squid.conf first tests a request to see if an unauthenticated request
from a particular host is permitted. That external ACL doesn't take a
username as an argument. If that external ACL passes, the request is
allowed.
Please *show* the config lines rather than describing what you *think*
they do. Their exact ordering matters *a lot*.
Obfuscation of sensitive details is okay/expected so long as you makes
it easy for us to tell that value A and value B are different.
FWIW; if your config file is *actually* containing only what you
described it is missing a number of things necessary to have a safe and
secure proxy. A look at your full config (without comments or empty
lines) will help us point out any unnoticed issues for you to consider
fixing.
The next line in squid.conf is
acl auth_users proxy_auth REQUIRED
FYI the above just means that Squid is using authentication. It says
nothing about when the authentication will be (or not be) performed.
... and after that, the external ACL that takes the username as well as
the other info.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
