Overview
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.
Our Infrastructure
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.
The Software
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.
Configuring Squid
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
http_port 8080
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:
.gov
.sheepguardingllama.com
.unicef.org
.eff.org
.conversationsnetwork.org
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:
http_proxy="http://192.168.4.2:8080/"
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:
export http_proxy=http://192.168.4.2:8080/
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:
HTTP_PROXY="http://192.168.4.2:8080/"
HTTPS_PROXY="http://192.168.4.2:8080/"
NO_PROXY="localhost, 127.0.0.1"
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.
Nice to know that we get free, automatic linkbacks just by mentioning Novell OpenSUSE Linux! Awesome. The anti-Novell people just added incentive to talk about SUSE. 😉
i have problem configuring the http_access allow all whitelist
squid wont run properly for this.
please help
Michael, can you post your http_access config for me to see? Do you need to use http_access for your whitelist? Normally whitelisting works best if left wide open.
Were you able to get the fans to quiet down from their full 100% to the lower quieter level?
by fans I mean the server fans (sorry I didn’t add that in my last posting).
Mike, when I start the server up it runs all out but by the time that the operating system is loading it quiets down quite a bit. I never hear it go all of the way up except for when it is rebooting.
Are you working with a DL380 G2?
Yes I am. And I’ve found that loading HPASM works wonders. I’m still trying to research how to get the same done in debian and ubuntu. I’ll see if I can post a quick how to here for you, or at the very least post a link to a site that I’ve been working with for help to get it running a little quieter.
Ok, I know it’s been a while, but anyway here’s some details on how I got the LOUD fans to throttle down to how they should be.
-download “hpasm-7.5.1-8.sles8.i386.rpm” from hp.com
-once OS is installed install the HPASM pack by running:
# rpm -ivh hpasm-7.5.1-8.sles8.i386.rpm
that should install HPASM.
to get it to work for you:
# hpasm activate
-when it asks you a question about weather or not to fuse with the kernel and that it may “taint” the kernel answer no.
the rest should be pretty much self explanatory. I believe HP has instructions on how to get it working on their site.
If everything was done correctly HPASM will automatically load on every reboot by itself 🙂
I should also add…
Ubuntu server doesn’t work easily with this server at all. I’d like to give debian another shot as I could get a fully functioning OS, but I had some trouble getting the fans to throttle down. That said I’m using OpenSUSE 11.1 with great success on my server.
If I am not mistaken, RHEL and Suse are supported officially on that hardware and Debian/Ubuntu are not which may lead to some of the problems.
I always run HPASM so have not noticed the fan problems 🙂
Thanks for the info.
this contains incorrect configuration for squid. It is missing the a line that should read similar to this :
acl whitelist dstdomain “/etc/squid/whitelist”
If you don’t define the name “whitelist”, it won’t be able to find where whitelist is located.
Else, it will not work!!!
Нey there woulԁ уou mind sharing which blog plаtfогm уou’re working with? I’m going to start my own blog soon but I’m having a difficult time making a decision between BlogEngine/Wordpress/B2evolution and Drupal. The reason I ask is because your design seems different then most blogs and I’m looking for ѕomething completelу unique.
P.S Sorry fοr getting оff-topic but I hаd to ask!
WordPress