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
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.
Edit /etc/apt/apt.conf, and make sure the username and password are written in the proxy URL; it should look something like this:
Make sure it's also set for https and others as required.
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