On Mon, 5 Sep 2011 07:14:35 -0700 (PDT), Leon - wrote:
Hi!
I'm experiencing a strange behaviour with our Squid installation at
work.
The version is "Starting Squid Cache version 2.7.STABLE9 for
x86_64-debian-linux-gnu..." according to cache.log.
(Debian Linux 6.0.2)
The scenario is the following:
We're part of a corporate network where each user has to authenticate
with his/her Active Directory password to the company-wide proxy
server.
However we have some special Windows machines that run with local
accounts only.
On these machines we run Antivirus software that need web access in
order to get their updates, and it would be a great hassle to provide
user passwords on these machine regularly, since all users are
required to change their AD passwords every 90 days.
Problem #1: allowing users to self-authenticate (their machine is both
originating credentials and acting as the verifier DC to check that they
are correct). This is a very weak link in the security layers. This
undermines most of the security benefit of the 90-day password rotation.
Attackers don't have to guess passwords, they just use one of these
machines.
To solve this we have setup a local Squid where we have manually
configured the proxy password to use in the squid.conf file using a
cache_peer entry for the upstream company-wide proxy.
The Windows clients with local accounts are setup to use this local
squid as their proxy.
Then after 90 days when the password needs to be changed, we only
need to update the squid.conf file, and all the 100+ machines with
local accounts can still get their Antivirus updates
So in short our local Squid is de-authenticating the web access for
these local clients.
There is no "de-" about it. The Squid is automatically _upgrade_
authenticating anyone who can connect to it. Just like you configured to
happen. As long as you understand that the login used by this Squid box
is extremely vulnerable to attack and being used by unwanted visitors.
You can (and should) configure the higher security area where everything
is on the DC to treat it carefully.
(sorry if you know the above already, adding it mostly for others
reading this).
So far so good, and it all works perfect for example for normal web
browsing, including SSL.
However the strange issue arises with one of the softwares, namely
Nod 32 that needs to authenticate to the Eset server in order to
retrieve the virus definition files.
The Nod32 client uses a simple GET request with the Authorization
header set to the login/password (encoded in base64).
The problem is that Squid rewrites this Authorization header and
replaces the login/password hash with the login/password used for the
upstream cache_peer.
The cache_peer authentication is provided in the Proxy-Authorization
header, so replacing the contents also of the Authorization header
with the same data definitely seems like a bug to me?
Also, for testing purposes I've tried to use the header_replace
statement in squid.conf to force the contents of the Authorization
header to the proper login/password hash, but this doesn't work
either.
Squid still puts the same hash as for the Proxy-Authorization also in
the Authorization header.
<snip>
From squid.conf:
cache_peer 10.23.3.5 parent 8080 0 no-query default originserver
proxy-only no-digest login=<login>:<password>
header_replace Authorization <HASH FROM NOD32 CREDENTIALS> <- Only
used temporarily for testing purposes.
Wireshark shows the following when Nod32 tries to authenticate to the
Eset server:
Proxy-Authorization: Basic <HASH FROM cache_peer CREDENTIALS>
Authorization: Basic <HASH FROM cache_peer CREDENTIALS>
Nod32 is logging into the Squid. Which it knows is a proxy.
And of course it should look like this:
Proxy-Authorization: Basic <HASH FROM cache_peer CREDENTIALS>
Authorization: Basic <HASH FROM NOD32 CREDENTIALS>
A final note: It has been confirmed that the Nod32 client sends the
correct login/password hash by running Wireshark also directly on one
of the Windows clients.
Your cache_peer is both an originserver AND required to get a static
pair of login credentials. Proxy authentication is not part of the
origin formatted HTTP syntax, so can't be sent and work with origin
servers. The only way the required login credentials can be sent is via
WWW-Auth* headers.
If the Nod32 box is a proxy, remove the "originserver" traffic type
flag.
If the Nod32 box needs the www-auth credentials sent by the client app,
remove login= entirely or replace with "login=PASS" (exact text).
Also, the "default" flag means that peer can be used as a backup
pathway to the Internet. This clashes with the meaning of originserver
which flags it as an individual "dead end" / web server data source.
Amos
