Tag Archives: cache

Proxy Authentication with Squid

How does Proxy Authentication work in Squid?

Users will be authenticated if squid is configured to use proxy_auth ACLs.

Browsers send the user’s authentication credentials in the Authorization request header.

If Squid gets a request and the http_access rule list gets to a proxy_auth ACL, Squid looks for the Authorization header. If the header is present, Squid decodes it and extracts a username and password.

If the header is missing, Squid returns an HTTP reply with status 407 (Proxy Authentication Required). The user agent (browser) receives the 407 reply and then prompts the user to enter a name and password. The name and password are encoded, and sent in the Authorization header for subsequent requests to the proxy. Also see this example Authorization Header from .htaccess files.

NOTE: The name and password are encoded using “base64″ (See section 11.1 of RFC 2616). However, base64 is a binary-to-text encoding only, it does NOT encrypt the information it encodes. This means that the username and password are essentially “cleartext” between the browser and the proxy. Therefore, you probably should not use the same username and password that you would use for your account login.

Authentication is actually performed outside of main Squid process. When Squid starts, it spawns a number of authentication subprocesses. These processes read usernames and passwords on stdin, and reply with “OK” or “ERR” on stdout. This technique allows you to use a number of different authentication protocols (named “schemes” in this context). When multiple authentication schemes are offered by the server (Squid in this case), it is up to the User-Agent to choose one and authenticate using it. By RFC it should choose the safest one it can handle; in practice usually Microsoft Internet Explorer chooses the first one it’s been offered that it can handle, and Mozilla browsers are bug-compatible with the Microsoft system in this field.

The Squid source code comes with a few authentication backends (“helpers“) for Basic authentication. These include:

  • LDAP: Uses the Lightweight Directory Access Protocol
  • NCSA: Uses an NCSA-style username and password file.
  • MSNT: Uses a Windows NT authentication domain.
  • PAM: Uses the Unix Pluggable Authentication Modules scheme.
  • SMB: Uses a SMB server like Windows NT or Samba.
  • getpwam: Uses the old-fashioned Unix password file.
  • SASL: Uses SALS libraries.
  • mswin_sspi: Windows native authenticator
  • YP: Uses the NIS database

In addition Squid also supports the NTLM, Negotiate and Digest authentication schemes which provide more secure authentication methods, in that where the password is not exchanged in plain text over the wire. Each scheme have their own set of helpers and auth_param settings. Notice that helpers for different authentication schemes use different protocols to talk with squid, so they can’t be mixed.

For information on how to set up NTLM authentication see NTLM config examples.

In order to authenticate users, you need to compile and install one of the supplied authentication modules found in the helpers/basic_auth/ directory, one of the others, or supply your own.

You tell Squid which authentication program to use with the auth_param option in squid.conf. You specify the name of the program, plus any command line options if necessary. For example:

auth_param basic program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd

How do I use authentication in access controls?

Make sure that your authentication program is installed and working correctly. You can test it by hand.

Add some proxy_auth ACL entries to your squid configuration. For example:

acl foo proxy_auth REQUIRED
http_access allow foo
http_access deny all

The REQUIRED term means that any authenticated user will match the ACL named foo.

Squid allows you to provide fine-grained controls by specifying individual user names. For example:

acl foo proxy_auth REQUIRED
acl bar proxy_auth lisa sarah frank joe
acl daytime time 08:00-17:00
http_access allow bar
http_access allow foo daytime
http_access deny all

In this example, users named lisa, sarah, joe, and frank are allowed to use the proxy at all times. Other users are allowed only during daytime hours.

How do I ask for authentication of an already authenticated user?

If a user is authenticated at the proxy you cannot “log out” and re-authenticate. The user usually has to close and re-open the browser windows to be able to re-login at the proxy. A simple configuration will probably look like this:

acl my_auth proxy_auth REQUIRED
http_access allow my_auth
http_access deny all

But there is a trick which can force the user to authenticate with a different account in certain situations. This happens if you deny access with an authentication related ACL last in the http_access deny statement. Example configuration:

acl my_auth proxy_auth REQUIRED
acl google_users proxyauth user1 user2 user3
acl google dstdomain .google.com
http_access deny google !google_users
http_access allow my_auth
http_access deny all

In this case if the user requests http://www.google.com then first second http_access line matches and triggers re-authentication unless the user is one of the listed users. Remember: it’s always the last ACL on a http_access line that “matches”. If the matching ACL deals with authentication a re-authentication is triggered. If you didn’t want that you would need to switch the order of ACLs so that you get http_access deny !google_users google.

You might also run into an authentication loop if you are not careful. Assume that you use LDAP group lookups and want to deny access based on an LDAP group (e.g. only members of a certain LDAP group are allowed to reach certain web sites). In this case you may trigger re-authentication although you don’t intend to. This config is likely wrong for you:

acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED

http_access deny !ldapgroup-allowed
http_access allow all

The second http_access line would force the user to re-authenticate time and again if he/she is not member of the PROXY_ALLOWED group. This is perhaps not what you want. You rather wanted to deny access to non-members. So you need to rewrite this http_access line so that an ACL matches that has nothing to do with authentication. This is the correct example:

acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED

http_access deny !ldapgroup-allowed all
http_access allow all

This way the http_access line still matches. But it’s the all ACL which is now last in the line. Since all is a static ACL (that always matches) and has nothing to do with authentication you will find that the access is just denied.

More Info

Example .htaccess

Send Custom Headers

Header set P3P "policyref=\"http://www.askapache.com/w3c/p3p.xml\""
Header set X-Pingback "http://www.askapache.com/xmlrpc.php"
Header set Content-Language "en-US"
Header set Vary "Accept-Encoding"

Blocking based on User-Agent Header

SetEnvIfNoCase ^User-Agent$ .*(craftbot|download|extract|stripper|sucker|ninja|clshttp|webspider|leacher|collector|grabber|webpictures) HTTP_SAFE_BADBOT
SetEnvIfNoCase ^User-Agent$ .*(libwww-perl|aesop_com_spiderman) HTTP_SAFE_BADBOT
Deny from env=HTTP_SAFE_BADBOT

proxy_auth acl causing challenge loop
> Well, I really prefer the old behaviour, so I hope the behaviour is not
> hardcoded, but configurable.

It’s not hardcoded, instead it is dependent on how your http_access rules
are constructed.

Squid prompts for login credentials if the user is denied access by an
authentication related acl (proxy_auth, proxyauth_regex, external using
%LOGIN).

http_access deny someacl authacl
prompts for new credentials if matched (denied by authacl)
http_access deny authacl someacl
does nor prompt for new credentials (denied by someacl)

Further Resources

  1. smb.conf man page
  2. smbclient man page
  3. ntlm_auth man page
  4. Configuring Squid Proxy To Authenticate With Active Directory
  5. Samba & Active Directory
  6. The Linux-PAM System Administrators’ Guide

Original Source: ProxyAuthentication © Creative Commons Attribution Sharealike 2.5 License

Caching Files in .htaccess with Expires

Files and Cache Expiration

For Apache to send along Expires with your staticly served files, you will need to make sure that mod_expires has been installed on your server. It is fairly standard and none of my servers I checked (that includes OS X’s Apache installation), didn’t have mod_expired on the system. You may have to search through your httpd.conf file and uncomment (remove the pound-signs) from the following lines, however:

#LoadModule expires_module libexec/httpd/mod_expires.so

#AddModule mod_expires.c

Once you’ve uncommented these lines, you should restart Apache. It differs depending on your system, but generally you can issue the following command:

sudo apachectl restart

If that didn’t work, look through your system’s manual or documentation for more information on how to restart Apache.

Once that’s done, go to the directory where your statically served files are contained and add or edit the .htaccess file in that directory. Add the following lines:


<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
       ExpiresActive on
       ExpiresDefault "access plus 1 year"
   </filesmatch>
</ifmodule>

The following bit: jpg|gif|png|css|js specifies the file types you’d like to target and this other bit: ExpiresDefault "access plus 1 year" specifies how long into the future you’d like to set the expiration date. In this case it’s one year into the future.