SquidGuard allows you to block sites selectively based on the name of the user, using the "user" keyword in a src acl. However, for this to work, squidGuard needs to receive the username from the squid proxy. The process by which the proxy gets the username (and potentially the password) of the user from the client is known as proxy authentication, or "proxy auth" for short.

One method involves the ident protocol. The ident service is specified in RFC 1413 (which is based on an earlier and obsolete RFC 931) and provides a protocol for one computer to query another as to the identity of a user who is trying to use a service on the first computer. From the text of the RFC:

     This is a connection based application on TCP. A server listens for
     TCP connections on TCP port 113 (decimal). Once a connection is
     established, the server reads a line of data which specifies the
     connection of interest. If it exists, the system dependent user
     identifier of the connection of interest is sent as the reply...

For this to work, you have to run a little server program on each client. (I have a server for Windows which runs with a tray icon - here is a ZIP file of it including source). This is not a big problem, and you can even cause it to happen at every login using system policies on an NT or SambaPDC network. Then you configure squid with an acl of type "ident REQUIRED" and use http_access allow or deny with that acl:

acl idents ident REQUIRED
...
http_access allow idents

Then you add the proper statements to your squidguard.conf file, and blocking by user occurs.

IDENT vs. Squid's Transparent mode

The transparent mode of squid allows you to set up a proxy, and the users' computers will use it without changing their browser settings - UNLESS you need to know the identity of the user on the client. Though there are several options for letting squid know the identity of a connecting user, at this time none of them work with transparent mode. Some of them APPEAR to work at first, but exhibit problems later. For instance, you can have a working configuration and then change to transparent mode, and it will continue to work for awhile, but then later on you won't get any blocking or else you can't see any pages at all. This delay of symptoms is a side affect of the caching action of squid.

Ideally, I would like to have a method of selectively blocking access to web sites; based on network user login name; which did not require me to configure each client and which could not be bypassed by a user on the client. Also, this should not interfere with applications such as Microsoft Front Page which require authentication of a local user by a remote server. The ident method is simple to configure; however, in transparent mode, squid uses the remote web server ip address as the origin address of the ident request, instead of using the address of the server squid is on. As a result, the ident reply tries to go to the remote server. Whether it gets there or not, the squid server never sees it. I still think that this is a bug. Some individuals on the squid project have politely disagreed with me, quoting the RESTRICTIONS section of the RFC. At any rate, this leaves out transparent mode if you want to use ident and restriction access by user name (as opposed to ip address). Other authentication scheme fail with transparent mode for this or other reasons.

An alternative to true transparent proxying which does often work is to use the "autoconfigure" capability of some web browsers. By "some" I mean Internet Explorer, mainly; autoconfigure in Netscape 6 is broken (AFAIK) although 4.7 is useable but different from IE in how it is set up. This also requires you to run a web server on the squid box. Briefly, you put a file called wpad.dat in the root of your web server, and in your DNS setup create a CNAME entry "wpad" which points to that server. The contents of wpad.dat are a javascript program called FindProxyForURL, and it can be complicated or simple. A simple example is:

function FindProxyForURL(url, host)
{
  if (shExpMatch( host, "<your server name>*"))
    return "DIRECT";
  if (!isResolvable(host))
    return "DIRECT";
  //If they have only specified a hostname, go directly.
  if (isPlainHostName(host))
    return "DIRECT";
  if (url.substring(0, 5) == "http:")
    return "PROXY <your server name>:3128";
  else
    return "DIRECT";
}

If you set things up this way, then you can go into IE's Tools...Options...Connection...Lan prop page and check the box that says "Automatically detect settings". This is often the default setup anyway. And that will be enough for the proxy server to be "transparent" to your browser. (You can create a system policy to set this, too) This will not *force* browsers to use your proxy - to do that, you have to use the a firewall or NAT rule (for instance, an ipchains rule re-directing all www traffic from your LAN to the squid port on your server).

Note that the autoconfigure method can be used with other methods of proxy-authentication, too. However, some of those methods will prompt for an additional username/password.

Finally, a disclaimer - ident is not a secure way of restricting access via your proxy. If people can log into your clients as anyone they want or if they are savvy enough to replace your identd server with one of their own (which could always reply with the username "root", for instance), then you've been outflanked. For an elementary school environment, ident has worked fine; in fact, I have even set this up in a home where there was was a lot of activity on hacker and warez sites occurring, and the hacker practitioner still hasn't figured out what's up (I hope he doesn't monitor this site!)
 

Other authentication methods

Ident can be a security risk in two ways that I am aware of. Firstly, it allows a computer can retrieve a valid username from any computer with a logged on user. However, this is really only a risk if the attacker has access to computers on your internal network. I always use NAT and a firewall that blocks ident requests, so I consider this a low risk. Of course anyone with access to your internal computers could run a program on one of them to scan the network for valid usernames, but usually if a person has that kind of access they already know a bunch of valid user names. Of course the reason knowing valid usernames is a risk is that it would allow someone to try to get logged on as a valid user by guessing the password, for instance. If logged on users have low access rights this decreases the risk.

The other way an ident server increases risk is that it may be subject to buffer overrun attacks, which could allow an attacker to gain complete control over the user's computer. However, this again requires access to the internal network to be effective.

For these reasons, and because configuration is relatively simple, I have continued to use an ident program (one I wrote) to provide usernames for squidguard to use for per user blocking. I have tried other authentication schemes as well, but all but the LANMAN trick give the user another password prompt, which I find undesirable. The LANMAN auth method has security issues of its own which affect the server, so I don't use it either.

The newest (version 3.02a or later) version of samba, combined with the latest (version 2.5 or later) squid, provides a means of authenticating against a Windows NT network, using the credentials of the user logged into the network on the client. This means that the user won't have to enter his name/password again, and that the password management can be left to the Windows domain system. This is a reasonable combination of security and convenience for most applications.
The authentication method to use is "winbind". You can read about it here, including how to configure squid (and briefly, samba) to use this. I am not using this method myself yet because a) I don't consider Samba 3.0 stable enough to use in production and b) I am not yet using winbind where I am using Samba 3.0. I have tried to use it but encountered problems.

Return to the Squidguard FAQ Supplement

Comments or corrections please to morris@maynidea.com