I am the technology coordinator for a small, private K12 school in rural Upstate New York. One of our challenges is filtering Internet access so that the students may have access to the Internet as much as possible while not requiring constant, direct supervision.
To meet these needs we decided that we were limited to WhiteListing – managing a list of all allowed websites and blocking everything by default as opposed to blacklisting where everything is allowed except for a specific list of banned sites. Whitelisting means that we have to manually maintain a list of approved websites, but the parents are confident that the students are only able to access pre-approved web sites.
Before getting into the implementation details, I would like to detail how our network is laid out to put this project into context. We are a pure 32bit Novell OpenSUSE environment, both desktops and servers, with a single Netgear ProSafe Firewall connecting us to a donated Time-Warner RoadRunner cable connection (Thank You, Time Warner RR!!)
Each desktop is setup without routing so they are limited to communications within the subnet only. We have no fears of needing to grow beyond our /25 subnet’s limit anytime soon. We have no DHCP and use static IP assignments throughout the school including machines connected via wireless. Those machines used for administrators (not teachers – but office use where students do not have access) are routable and will not use our filter (for extra security they are allowed external access at the firewall via an IP list.) All other machines can only get access to the Internet through the use of the proxy server. This also allows us to improve bandwidth utilization through aggressive caching since the set of allowed sites is so limited and well known.
For our proxy server hardware we are using an HP Proliant DL380 G2 with dual Pentium IIIs 1.4GHz processors, 1.25GB and six hot-swap 36GB 10,000RPM SCSI drives arranged as RAID 0+1. This machines is far more than adequate for our needs and does an amazing job. We could easily run on a DL360 G1 with just a single processor, half that memory and two drives in RAID 1 without any problem. Our previous machine, which we used for years without any issues in performance, was a Proliant 3000, dual Pentium II 333MHz, 1GB and five 4.3GB 7,200RPM drives in RAID 5.
The older system ran SUSE 9.2 and ran wonderfully for a long time. I am writing this HowTo guide as I move us to OpenSUSE 11 and do a fresh installation of our proxy server.
As we are running on OpenSUSE Linux 11, I want to work with Novell managed packages as much as possible. For the proxy portion of our system we will use the Linux standard proxy server Squid. OpenSUSE’s repository offers us both Squid3 and Squid2. We will go ahead and use the latest Squid Proxy package for OpenSUSE 11, Squid3 3.0.5. The downside to going with the newer Squid3 package is that OpenSUSE’s YaST tool cannot yet manage it so you are stuck working only from the configuration files.
For advanced filtering we have two primary choices: SquidGuard and DansGuardian. SquidGuard has the advantage of being included in the OpenSUSE repositories making it easier to manage from a patch perspective. DansGuardian is what I have used in the past. It is available as an RPM from the OpenSUSE Build site but is not available through the YaST repositories. DansGuardian is GPL’d but the author asks that you not exercise your GPL right (GPL in fact but not in spirit.) So, I like to avoid DansGuardian simply because I can’t figure out if the author even wants me to use his software or not.
For our purposes here, using nothing but whitelisting, we do not need the features of either SquidGuard or DansGuardian and can avoid them completely. If you are looking to do more than just whitefiltering they are your best bets.
Installing the Proxy Server: Squid
Installing Squid3 on OpenSUSE 11 is extremely simple.
zypper install squid3
Of course, if you prefer, you can always use OpenSUSE’s YaST utility, either graphically through the desktop or through an ncurses interface on the command line to install Squid and any necessary dependencies. I find that working through Zypper (or Yum on a Red Hat, CentOS or Fedora system) to be the most effecient by far.
These are the changes that I made to /etc/squid/squid.conf:
acl localnet srv 192.168.4.0/25
http_access allow all whitelist
http_access deny all
That’s it. Very, very simple. The first line is simply to allow my local network. You will need to add in your own local network and not mine for this to work for you. If you stick with the Squid3 defaults then all private networks are allowed locally by default so that is a completely viable option.
The next two lines, http_access, first tell the system to allow access to anyone “all” to sites included in the whitelist. The next line says to deny access to anyone who did not get allowed from the previous rule.
The last line, http_port, is also completely optionaly. The default port for Squid is 3128 but I prefer to run my proxy on the more common 8080 port. This is just easier to remember when setting up desktops.
With the default install of Squid3, Squid is not configured to start automatically. So we need to use chkconfig to configure Squid to start on system boot. You can skip this step if, for some reason, you do not want your proxy system to start automatically when your server restarts.
chkconfig –level 3 squid
Before we actually start Squid, though, we will want to create our whitelist file which will be the main configuration file that we will be using after Squid is up and running.
Creating the Whitelist
Using your favourite text editor (that’s vi for me) create the file /etc/squid/whitelist. This file is just a simple list of websites that will be allowed. The one thing of which to be aware is the fact that your entries need to lead with a dot. If you leave off the dot you will have problems. Here is an example from my own whitelist:
In this example, all United States government web sites will be allowed (those ending in .gov) as well as this blog, UNICEF, the Electronic Frontier Foundation and The Conversations Network. Anytime that you alter this file you will need to ask Squid to reread its configuration.
Configuring the Desktop Clients
If you are like me, you will be using OpenSUSE on your desktops as well which I highly recommend. OpenSUSE makes a wonderful desktop, especially with KDE4. With OpenSUSE you have the option of setting your proxy settings using the handy YaST tool. This is fine. If you are like me, you will prefer to use the command line – mostly because it is easily scriptable but also because it will work for non-SUSE Linux boxes as well.
To set your proxy temporarily just for the current session to test your proxy server you can simply:
Notice that you will need to use your own IP address here as well as your own port number if you decided to use one other than 8080. My proxy server’s IP address is 192.168.4.2 so modify accordingly.
The most common means of setting this variable to survive through a reboot is to use /etc/profile so that it will apply to all users. Simply add this line to /etc/profile:
In OpenSUSE, there is a better place to set this information. Let’s look at /etc/sysconfig/proxy. This file is a central proxy settings file for all of the OpenSUSE which makes it very handy so that we don’t have to worry about users not picking up changes from other locations. It is also nice as it will allow us to have some advanced settings if we so desire.
In my case, I am only using the proxy server to handle HTTP and HTTPS requests (we are blocking FTP and GOPHER entirely) so we only need to edit the two lines pertaining to those protocols as well as the “no proxy” setting to list which locations should not be proxied but accessed directly. Here are my settings:
With these changes you should now have a functioning, whitelisting proxy server to protect your network. OpenSUSE’s default installation of FireFox is set to bypass its own proxy settings and to pick up the system changes automatically. Tools like w3m and wget will use the system proxy settings as well. If you are using a client that is either unable to or is not configured to get its settings from the system then you will need to configure its proxy settings manually on an application by application basis.