Setting up a Squid forward proxy can be a pretty daunting task since Squid is an extremely flexible piece of software. In this article, I’m going to provide a minimal non-caching, authenticated configuration. I have tested this with Squid 3.1.12 on Ubuntu 13.04, but with minor adjustments it should work for other systems as well.
First of all, we install Squid and some utilities that we need later:
# apt-get install squid apache2-utils
The proxy is going to use HTTP Digest authentication to authenticate users using a local password file. For larger setups, Squid can also authenticate against LDAP directories or Kerberos, but that’s beyond the scope of this article.
Now, let’s create a new password file (you have to be user root
):
# cd /etc/squid3/ # touch passwd # chown proxy.proxy passwd # chmod 640 passwd
Changing the owner and restricting access isn’t strictly required, but it’s good practice since the file’s contents will contain unsalted MD5-hashed passwords.
Using the htdigest(1)
utility from apache2-utils
, we can add users to the password file or change passwords of existing users:
# htdigest /etc/squid3/passwd SurfinUSA matthias Adding user matthias in realm SurfinUSA New password: Re-type new password: #
The realm we pass on the command line has to be the same as the realm we use for Squid later. The format of the file is quite simple:
matthias:SurfinUSA:0fb904a2a976add85091cf0115db9d7b
It consists of username, realm, and an MD5 hash. The hash is calculated from the user name, realm and password:
$ echo -n matthias:SurfinUSA:secret | md5sum - 0fb904a2a976add85091cf0115db9d7b - $
To save us trouble later, we test whether the file works as intended. Squid uses external programs to authenticate users; for Digest authentication, it pipes username and realm to an external program (Update: renamed to digest_file_auth recently!) and if username and realm are known to the program, it returns the MD5 hash:
# /usr/lib/squid3/digest_pw_auth -c /etc/squid3/passwd "matthias":"SurfinUSA" 0fb904a2a976add85091cf0115db9d7b CTRL^D #
Looks good, so we can move on to Squid itself. The default configuration file in /etc/squid3/squid.conf
has 5800 heavily commented lines which makes it a bit unwieldy to edit. Since we don’t need Squid’s full power, it’s easier to start from an empty file. It turns out that this is all we need:
auth_param digest program /usr/lib/squid3/digest_pw_auth -c /etc/squid3/passwd auth_param digest realm SurfinUSA auth_param digest children 2 acl auth_users proxy_auth REQUIRED http_access allow auth_users http_access deny all http_port 13128
The auth_param
lines set up digest authentication. In our example, Squid runs two digest_pw_auth
child processes for authenticating users. The acl
line basically places all authenticated users in a group auth_users
. Using the http_access
command, only users from this group are allowed access, to all others, access is denied (careful, order matters for http_access
!).
Finally, we let Squid listen on port 13128. To prevent script kiddies from attacking your proxy, we use a non-standard port (3128 is Squid’s default).
Finally, reload the configuration file:
# service squid3 reload
Check the log file in /var/log/squid3/cache.log
for errors and if there are none, let’s test the proxy:
$ curl -i --proxy-digest -U matthias --proxy http://localhost:13128 URL Enter proxy password for user 'matthias': [...] $
You should get the same web page that you’d get when calling curl URL
without any proxy settings. If that worked, congratulations! You now have a working HTTP proxy that you can use from your web browser.
Our configuration doesn’t cache resources on disk, so it doesn’t use much disk space. The access log in /var/log/squid3/access.log
, however, tends to get quite large over time. You may want to either configure log rotation or turn it off completely using the following command in squid.conf
:
access_log none
Finally, a word of advice: HTTP traffic between your browser and the proxy is transmitted unencrypted, so you should not use this setup for transmitting sensitive information over an untrusted network. If you want protection between your browser and Squid, you would have to set up SSL connections using the https_port
command (which Firefox doesn’t support).
For secure web surfing via a public Wifi network at a conference or a coffee shop consider using a SOCKS proxy using OpenSSH or a VPN.
very nice detail, a lot of people dont worry about ‘proving’ each step, therefor the user is left to more or less believe they are being told the right information, this instruction helped me figure out where I was making an error, and also how to prove what I was doing was right or wrong, thanks a lot!
Thanks for your message, I’m glad you like it! I struggled quite a while with a segfaulting digest_pw_auth due to misconfiguration, so I thought I’d save others the trouble :)
I love linux . I am working squid but i have a problem. If any body can help me . problem is that , my wish when a user login a system, same user, same password he can easlly login another system or computer. So that is issue and i am also don’t want this matter. So kindly any one can help to me . I make a project web base user-authentication . But it has a problem, when a single user login a web-base user authentication, then same user name and same password he can easlly login another computer or system in web-base user authentication. So that i can not want to do this thing . so kingly help me in this project. If i make this project then i will lanch in my department. So plz plz help me now …..This project is consists only web-base user authentication, using squid server and appache server for user authentication ………
1) I am using Centos 6.5 OS
2) Squid server for web-base authentication
3) Appachi server for web-base authentication
If I get you right, you want to use the same user names and passwords for both servers which means you’ll have to use the same authentication backend (ie. password file). In the simplest case, both Squid and Apache run on the same machine. Then you can use Squid’s digest authentication file (“passwd” in my example above) for Apache, too. It’s the same file format, you just need to configure Apache’s mod_auth_digest module. If Squid and Apache are on different hosts, maybe you can regularly sync the password file from one host to the other using cron and rsync.
In a more complicated scenario, you’d have a central LDAP server (maybe even ActiveDirectory) containing your user database. Both Apache and Squid support LDAP authentication, but it’s quite difficult to set up if you’ve never done it before.
Hi,
I have a question.
If I want to offer 2 or more different authentications on different ports, on same SQUID instance, is it possible?
If yes, can you share a sample file? concatenating two files to one did not help me.
E.g. port 3128 – basic http authentication
port 3129 – digest http authentication
port 3130 – transparent
port 3131 – NTLMV2
Thanks for your help
Hi
i need provide proxy services for both domain and no domain users so i try to implement multiple authentication schemes but never works for me, can anybody help me with a tested example about this or show me another possible solucion. i have squid 3.5.22 in debian. thanks in advanced
Just leaving a note here in case other folks are trying to use digest authentication with squid running on Windows. There is a bug in the code for the program “digest_file_auth.exe” that requires that Squid’s digest authentication file (passwd in the examples here) have Unix line endings (LF only), not the traditional Windows EOL (CR-LF). I couldn’t figure out what was going on until I looked at the source code. Hope this helps and thanks for the article.