WPM -- Web-Based Proxy Manager

Gunnar Wolf

There are many high-quality proxies and firewalls for Linux and other UNIX platforms. However, managing them has always involved going to the command line to write some obscure-syntax commands or modifying a configuration file lost somewhere in the server directories' hierarchy. In order to make these changes, it is also necessary to be the superuser, good old root, thus making it impossible for non-privileged users to perform these management tasks.

A common problem in computer centers (specifically in schools) is to have a large number of computers with limited connection to the Internet. WPM was inspired by a problem like this, although it will surely be able to solve many others. In this article, however, I will focus on the scenario usually seen in a school computer center.

Ideally, every computer lab in school should be available for use by any group, and Internet speed should be as fast as possible. A teacher, however, must also be able to block Internet access if necessary so that the students will focus on the class subject or program. There should also be different access levels (i.e., only the systems administrator can lift all restrictions, or a teacher can be limited to controlling a single IP address at once, not the whole laboratory). As an administrator, I also want to quickly and easily view which laboratories or computers have access or are restricted. Furthermore, with an eye to the future, the system should also be able to activate or deactivate a restriction to a certain range of computers, making the administration easier on the whole system.

All this should be carried out through a simple interface for two reasons. First, we don't want the teachers, who usually are not systems administrators, to suffer through complicated procedures and arcane commands. (And, we don't want to give them all the root password.) Second, we want to make it easy on ourselves to manage the system.

With all this in mind, and after working at two different schools with this situation, I started writing this program. I decided to put it under the GPL license so that my work can be useful to as many users as possible.

How is WPM Implemented?

I chose Perl as the language on which to write WPM, mainly because of the easy interaction it has with the Web, thanks to CGI.pm. I also like the freedom of programming it provides, without the need to declare and typify variables, keep a constant eye on memory allocation in order to maintain a decent degree of security, etc. In short, it lets me focus on the code. Yes, I know that C code is much more efficient than Perl code, but WPM is formed by very small modules, so the speed gain would be unnoticed. Also, because part of WPM runs as root, not having to worry about stack overflows lets me sleep better at night. If you consider the fact that WPM will be called in less than once an hour on average, I think you will agree that Perl suits the job better than any other language.

WPM doesn't really configure the proxy. It actually manages a firewall for the computer that runs the proxy, keeping it from listening to the requests of the computers that are blocked at a certain moment.

WPM currently requires Linux 2.2 to work, because it needs to interact with ipchains, Linux's firewalling manager. However, adding support for additional architectures should be pretty straightforward.

Structurally, WPM has two main parts: the CGIs and the daemon. The CGIs handle all user interaction, the state display, user management, and the interaction with the daemon. CGIs need as a non-privileged user, usually nobody. On the other hand, the daemon executes all the firewall commands and informs the invoking CGI of the actual state. I must also mention that WPM is still considered beta. It still has many defects to fix and many features to add and, although it is usable, there is room for improvement.

How Does WPM Work?

Before using the program, we must first start the daemon. Enter WPM's directory and, as root, run:

wpmd -c wpmd.conf

To start the program, use a Web browser, and point it to the desired address. In my case, this is http://proxy.myorg.org/wpm.html -- a reasonable name. We are greeted by a login requester and, as this is our first time using WPM, we will log in with the default account, wpm (password wpm).

Figure 1 shows the main menu. I will go from the bottom up and because changing a password is pretty obvious, I will skip that. Figure 2 shows the network segments configuration menu. From here, I can easily add or drop IP addresses from a segment, create or delete segments, and assign names to segment numbers. Note that in order to delete a segment, you only have to delete all the IP addresses that conform it.

Figure 3 shows the daemon configuration. Here I can configure the network (class A, B, or C) that I will be limiting with WPM. I can write the network portion, be it a single number (for class C addresses like the ones in the example) or numbers separated by dots (for class B or class C addresses). I can also modify WPM's behavior, changing the port where it will listen to requests. This allows us to have more than one instance of WPM in the same computer, with maybe different profiles and areas available for different users to control. I can also modify the location of the passwords file, the network that WPM will be acting for, the port in which the proxy will be listening (by default, I chose Squid's 3128), the path and name for the log file, and the detail level that should be logged. By putting together the network portion in Figure 3 and the host portion in Figure 2, you have the complete IP addresses.

Figure 4 shows the account management, which is also very straightforward. We can change each account's name, as well as the associated access level. Of course, if we were using a less privileged account (0 being the highest privilege level), we would not be able to modify higher level accounts, nor could we give an account higher privileges than our own. Also, in order to delete an account, level 0 is needed.

The most useful part of the program lies in the next screen, Figure 5. This shows how it would display if we entered when segment 1 (First Segment) had Internet access completely disabled (red color). Segment 3 (Lost in space) appears in yellow, which shows us that some computers are allowed access while some are denied, and segments 2 and 4 appear in green, which means they have unrestricted Internet access.

This coloring scheme was easily implemented using the command ipchains-save (see sidebar). Comparing the output from that command against the segments definition file, I get the actual status of each segment.

In this last screen, we can take different actions -- allowing or denying whole segments by pushing the buttons next to the colored list, allowing or denying a single IP's access to the Internet, entering a single IP address, and allowing with one single click access to all the computers in our system.

What Lies Ahead

WPM is perfectly usable now and is being used in Mexico, Singapore, Brazil, Finland, Israel, Malaysia, Australia, the United States, and New Zealand. However, there is still lots of work to be done. My next priority is to allow for state to be saved (i.e., making WPM save its current state each time it performs changes, so that when it is started over it remembers how it was last set up). I would like to modularize it a bit more, so that the commands that the daemon uses to fire specific ipchains rules can be changed and work correctly with other implementations and operating systems, or so that they could work in a different way, such as forwarding the connection to a different port in order to explain the situation instead of just rejecting the connection.

There are many other additions I want to put in WPM. The main ones I have thought of, and which will surely come before 1.0 release, are:

• Automated scheduling -- Some way of inserting or removing commands from the crontab so that the programmed actions can be automatically executed on a daily, weekly, or monthly basis. I doubt it will be too useful to add a by minute, hour, or yearly basis, but it is possible without any extra work to do so.
• Support for different network configurations -- Although Class C networks are the most common, they are not the only ones. WPM correctly handles network segments smaller or larger, but not in the most elegant way. It is more a hack than a permanent solution.
• Anything you want -- This is a 100% free GPL project. I started the program, and until today have written the majority of the code. However, you can be sure that anything you send in will be included, and if you only send me a suggestion, I'll try to implement it.

WPM is not meant for every use. Managing a firewall is certainly way over its expectations. However, I think many administrators will find it useful for their specific network configurations and may also come up with new uses.

About the Author

Gunnar Wolf works as a sys admin and programmer for UNAM and has been an active member of Mexico's Linux User Group. He likes to do some Perl programming in his spare time.