User Authentication on Squid Proxy Server

In our previous article you may find tips on varying basic configuration options for Squid caching proxy server by adjusting the main configuration file. This article covers more advanced Squid configurations involving user authentication.

Despite pretty high potential of basic configurations, some functions that might make work with proxy server more comfortable are operated only by “helpers” - additional software. One of the most important tasks that the majority of helpers fulfill is user authentication. Squid proxy server itself doesn’t operate this task, but is able to decode HTTP-header “Authorization” and transmit the acquired information to a helper. Then the helper examines the information and if login/pass data is correct, it replies proxy server. After that Squid checks user’s access rights and either gives access or displays 407 HTTP error, in case authentication has failed.

Squid package includes helpers that are able to perform authentication by several basic means. Each helper operates according to its unique authentication scheme and replies proxy server with positive or negative response. It is possible to configure a number of authentication schemes simultaneously – in this case proxy server successively tries different schemes depending on their serial number in squid.conf file.

One should note that authentication is impossible in transparent proxy mode. This limitation is predefined by the peculiarities of TCP/IP protocol operation but not the Squid functionality weak spots.

Third-party modules activation and configuration is performed by auth_param directive in the main configuration file:

auth_param scheme parameter [setting]

scheme parameter takes the value of a supported authentication scheme. Scheme parameters set the chosen scheme configurations and may vary for different authentication schemes. Instead of Squid packed-in helpers, one may use any third-party modules or even self-made scripts as helpers that check login/pass data.

After authentication scheme and helper have been configured it is important to create acl (access control list) that activates the configured authentication module and allows the authorized users to access the network.

Initially acl command line has the following format:

acl acl_name acl_type argument

In order to create an access control list that would include authorized users acl_type parameter should be proxy_auth. Also, one shouldn’t forget that this acl should have access, given by http_access directive.

Basic Authentication Configuration

Basic is the simplest authentication method dating back to HTTP/1.0. It is based on the process of giving proxy server the credentials by user’s web browser. Login and password are linked by colon, encrypted in bese64 and put into “Authorization” field of HTTP request. One shouldn’t forget that credentials encrypting in base64 isn’t a protective and implies open password transmission. Actually, the only benefit of basic scheme is the fact that it’s supported by any web browser and other web clients.

Authentication via NCSA

In this scheme passwords are stored in a simple text-file that contains credentials encrypted in base54. By default Squid basic authentication is operated via helper stored in /usr/lib/squid3/ncsa_auth. It examines the accordance of login/pass combination with data in the file and sends server OK or ERR as a response.

Note that even authentication success doesn’t guarantee access to network – all authorized users may be controlled by access control rules, inscribed in acl of the Squid main configuration file. Therefore, in the first place it is necessary to add configurations for basic-authentication helper to the proxy server config file:

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers 
# here /usr/lib/squid3/ncsa_auth is a helper path and  /etc/squid3/squidusers is a path to the file containing login/pass combinations.
acl lan proxy_auth REQUIRED # creation of access list of all authenticated users
http_access allow lan # users from lan list have internet access

You may use htpasswdutility to create a file with passwords for basic authentication implementation. This utility is included in apache2-utils package for Debian/Ubuntu. The htpasswd directive has the following syntax:

htpasswd [-c] /passwdfile username

-с parameter is used only to create a new file, not to change the existing file.

In the example below you may see how to create a new file for credentials (squidusers) and add users (user1 and user2) with passwords 12345:

htpasswd -c /etc/squid3/squidusers user1

New password:
Re-type new password:
Adding password for user user1

cat /etc/squid3/squidusers
user1:12345

htpasswd /etc/squid3/squidusers user2

New password:
Re-type new password:
Adding password for user user2

cat /etc/squid3/squidusers
user1:12345
user2:12345

It is advisable to allow reading only for the user and the group that Squid represents:

chmod 440 /etc/squid3/squidusers
chown proxy:proxy /etc/squid3/squidusers

To complete new authentication scheme configuration, restart Squid. However, in case the changes were made to an existing authentication scheme, it’s enough to refresh configurations:

squid3 -k reconfigure or /etc/init.d/squid3 reload

Authentication via MySQL Database

Apart from storing credentials in a file, you may use basic authentication via database. In this case “login:pass” data is stored in MySQL database.

Firstly, it’s necessary to create a database and a table for storing passwords. To do this, you should execute several queries to MySQL server:

create database squid; # deatabase is created
CREATE TABLE 'passwd' (
'user' varchar(32) NOT NULL default '',
'password' varchar(35) NOT NULL default '',
'enabled' tinyint(1) NOT NULL default '1',
'fullname' varchar(60) default NULL,
'comment' varchar(60) default NULL,
PRIMARY KEY ('id')); # passwd table with fields user, password, enabled, fullname and comment is created

You may add a test record to the table by:

insert into passwd values('test','pass',1,'Test User','for test');

Now MySQL configuration is complete and as a next step you should activate DB authentication in the configuration file (squid.conf) in the same way as you would do with basic authentication:

auth_param basic program /usr/local/squid/libexec/squid_db_auth --user user --password password --md5 --persist
acl db-auth proxy_auth REQUIRED
http_access allow db-auth

Here are main parameters of the helper:

• --user - name of DB user;
• --password - access password for DB;
• --table - table in DB, "passwd" by default;
• --usercol - column of usernames, "user" by default;
• --passwdcol - column of passwords, "password" by default;
• --plaintext - means that password in the database is stored as a plain text;
• --md5 - means that passwords are encrypted in md5 without salt;
• --salt - salt for password encryption;
• --persist - holds open connection with DB between requests.

Once configuration is complete, refresh proxy server configuration by:

squid3 -k reconfigure

Apart from NCSA and MySQL, Squid package contains many other helpers that operate such data sources as LDAP, RADIUS, PAM, etc.

Digest Authentication

This method appears to be more preferable than basic authentication, because it encrypts password before sending it through the net. The overall scheme of work is pretty similar to the basic method, except for the fact that in the server-client data exchange credentials are encrypted with MD5. Server and client replies are “diluted” with random values and then a password is sent as a hash. Encryption and decryption is operated by htdigestutility, which is usually installed inside the apache2-utilspackage. You may find the helper that allows operating digest authentication in /usr/lib/squid3/digest_pw_auth.

As well as for basic authentication, there are helpers for digest authentication that allow using different user data sources.

Along with basic and digest authentication, Squid also supports NTLM and Negotiate authentication. These schemes aren’t so widespread and are mostly used within corporate networks – their configuration is a topic for another article.

General User Authentication Configurations

It’s not enough just to configure authentication type – you should also configure general user authentication parameters. You may use auth_param directive for that.

children

auth_param basic children 5

This parameter defines the number of subprocesses that authentication program operates simultaneously. Basic value is 5, which means that no more than 5 users can be authenticated simultaneously. If one more client would like to get access at the same moment, he or she will have to wait for a vacant process. On the one hand increasing the number of processes may accelerate proxy server. On the other hand, excessive number of processes may cause server overload, especially in case of malfunction.

realm

auth_param basic realm Corporate proxy server Squid

This parameter allows specifying the line that will be sent to a client through the authorization window. As a rule, it is a proxy server name or a comment to notify user that he is authorizing in Squid.

credentialsttl

auth_param basic credentialsttl 2 hours

The credentialsttl parameter defines the time frame for storing username:password data in cache. As the time is up user has to pass authentication again.

casesensitive

auth_param basic casesensitive off

This parameter is responsible for username case sensitivity. It should be activated, if one is going to apply case sensitive database.

blankpassword

auth_param basic blankpassword off

This parameter allows activating blank password support. By default, authentication with blank password is possible in quest access mode only.

Additional Directives

Along with auth_param there is a range of directives that influence authentication:

authenticate_cache_garbage_interval 1 hour

The directive above defines the period of storing user’s login in cache. The default value should not be changed without particular reason.

authenticate_ttl 1 hour

This directive defines the period of time that precedes user’s authentication data removal from proxy server. By default, user has to repeat authorization after an hour since the last activity.

authenticate_ip_ttl 0 seconds

This directive sets the period of storing user’s IP address. In case IPs often change, it’s advisable to set a short period of time, no longer than several minutes. Otherwise, for the network with static IP distribution, it is possible to set longer periods.

Conclusion

Capacity of Squid proxy server configuration allows implementing a wide range of network configurations – one should just take time making up the middle way between security and convenience. There is no universal way to prevent an unauthorized access to network. Therefore, authentication scheme at proxy server level should be regarded as a tool to collect statistic that may contribute to network optimization and prevent undesirable accidents.

Any authentication scheme implementation causes a certain level of users’ discomfort and increase in complexity of network maintenance. Moreover, one should keep in mind that Squid transparent mode excludes authorization – each computer has to be configured for work with proxy server. Overall, before implementing any authentication scheme, first of all, you should think over the network operation process and ask yourself “Is it possible to achieve the same security level without user authentication?”