Introduction

In many networks, it's useful to control external traffic to ensure security. Some companies use proxy servers to be able to limit external traffic (and thus, firewall rules) to a single set of systems.

Testing in Ubuntu

Ubuntu is used in all kinds of environments, that's why we need to make sure systems behind proxy servers perform as well as others; and that all the services someone might want to access are available and reachable.

We must exercise care to make sure new feature development does not break proxy support for packages in Ubuntu; this includes testing commonly used packages and filing bugs.

Any package that requires talking to a server on the Internet potentially needs to speak to a proxy server to get there, and thus must be tested.

Software that needs testing

• Software Center
• software-properties (add-apt-repository and the GUIs)
• browsers (firefox, chromium, epiphany, midori, konqueror, etc.)
• Ubuntu One
• Webapps
• Empathy
• Pidgin
• etc.

Setting up a proxy testing rig

To test proxy support in Ubuntu; you'll usually need two systems. One will act as the proxy server (can be an external machine or a virtual machine), and one will be used as a client (again, external/different hardware system or another virtual machine).

For simplicity, we'll use a squid server to act as a proxy system on a virtual machine; and use another virtual machine as the client; this document assumes the virtual machines are already created, installed, and booted.

Setting up the squid VM

Basic setup, with no authentication

First, install squid 3:

 sudo apt-get install squid3 

Squid by itself once installed has a pretty reasonable configuration. The only major issue is that it doesn't listen on any other address than 127.0.0.1; which is a problem for us -- we want it to listen on the network so we can know exactly what goes on between the server and client.

So edit /etc/squid3/squid.conf, and find the following lines:

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
#acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
#acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
#acl localnet src fc00::/7       # RFC 4193 local private network range
#acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

Uncomment the one that matches the details of your network.

Now, find the following lines:

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet

And uncomment http_access allow localnet.

This is minimal, simple configuration that will allow any system on the local network to access the squid proxy.

With this done, restart squid to get the changes applied:

 sudo restart squid3 

You should now be able to use the proxy for HTTP, HTTPS, and SOCKS by pointing a client to the server's IP address, with port 3128.

Advanced setup: enabling authentication

It's useful to also test an authenticated proxy, even if implementations of proxy support will usually include the authentication parts if an application uses standard proxy libraries (such as libproxy).

To do this; edit the squid configuration file /etc/squid3/squid.conf.

Find the lines:

##auth_param basic children 5
##auth_param basic realm Squid proxy-caching web server
##auth_param basic credentialsttl 2 hours

And make them look like so:

auth_param basic program /usr/lib/squid3/pam_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Now, go back to the acl localnet line and add "proxy_auth REQUIRED" to it:

acl localnet proxy_auth REQUIRED src ...

Finally, save and exit the file; then navigate to /usr/lib/squid3.

You'll need to set pam_auth as setuid. This is a potentially insecure setup; so I would suggest using a custom VM that gets used only within your network and only for the purpose of testing proxy:

Should figure out a way to use pam_auth without requiring it to be setuid...

$ cd /usr/lib/squid3
$ sudo chmod 4755 pam_auth

You can then restart Squid3:

 sudo restart squid3 

From here, you should be able to use user accounts configured on the proxy server to use the proxy software; for example, if the 'ubuntu' user on the proxy server exists and has a password 'password'; use 'ubuntu' as a username when asked on the client, and use 'password' as the password.

Setting up the client (optional)

If you don't want to set up firewall rules for the client, you may skip this, but you should then look at packet captures (using tcpdump or another tool) to make sure the traffic really goes through the proxy and not directly to the destination.

The client requires some minimal firewall rules to make sure traffic really goes through the proxy. We can set those up with ufw.

# block all ports but DNS and proxy access
sudo ufw enable
sudo ufw allow out 53/udp
sudo ufw allow out 3128/tcp
sudo ufw deny out eth0 1:65535/tcp

To disable the firewall changes; keeping the standard firewall rules:

sudo ufw delete allow out 53/udp
sudo ufw delete allow out 3128/tcp
sudo ufw delete deny out eth0 1:65535/tcp

And optionally disable the firewall altogether:

 sudo ufw disable 

Then you can go ahead and setup proxy in GNOME or KDE:

Proxy settings for GNOME are under the Network item in System Settings.

Proxy settings for KDE are under Network Settings in System Settings.

With this done, you should see that /etc/environment has been set up to list the proxy servers that were configured in GNOME or KDE; starting a new terminal, you should also see that they are included in the environment. The environment variables to look for are the following:

• http_proxy / HTTP_PROXY
• https_proxy / HTTPS_PROXY
• ftp_proxy / FTP_PROXY
• all_proxy / ALL_PROXY # this is the variable for SOCKS.

Configuring authentication for proxy client

Some applications require further configuration for proxy when using authentication. These parameters are unfortunately not yet available in UI.

Some of these settings will be visible in clear text in configuration files.

Configuring command-line applications

Edit /etc/environment, add the username/password settings in the URL; see below.

Configuring APT

Edit /etc/apt/apt.conf, and make sure the username and password are written in the proxy URL; it should look something like this:

 Acquire::http::proxy "http://user:password@proxy.server:3128/" 

Make sure it's also set for https and others as required.

Configuring GNOME

Gnome applications may need authentication too; you can set those in gsettings:

gsettings set org.gnome.system.proxy.http authentication-password 'password'
gsettings set org.gnome.system.proxy.http authentication-user 'user'
gsettings set org.gnome.system.proxy.http use-authentication true

Verifying proxy usage

On the client

On the client; you can use tcpdump to verify that all traffic goes through the proxy:

sudo tcpdump -ni eth0

You should only see traffic on port 53, and on port 3128 to the proxy server.

To further check:

sudo tcpdump -ni eth0 tcp port 80

If your system is properly configured and the browser is set to use proxy (automatic when set in GNOME), you should not see traffic on port 80 as you browse web pages.

If firewalling is used, the pages will not load anyway because the ports for web (80 and 443) are being blocked, see above.

On the server

The proxy server lists all access attempts in a log file: /var/log/squid3/access.log. You can look at what happens on the proxy server with the following command:

sudo less /var/log/squid3/access.log