Phoenix Adaptive Firewall: You’ve tried the rest; now try the best

You’ve seen those cute little Cobalt cube servers on television, in magazines, and in your dreams, but you haven’t taken the time to give one a test run. Why? Who really knows what they’re for? Web servers? File servers? Print servers? The little blue cubes are an enigma, and they have a reputation for being incredibly reliable and powerful for their size and cost. But what do they do? Well, I’m not sure. However, I do know what Progressive Systems has done to the Cobalt hardware. They’ve made it into the single best piece of security equipment I’ve ever had the privilege of using. What this little cube can do in minutes would take an administrator hours to pull off.

I have to admit that, when I first received the cube, I was a bit skeptical. The tiny appliance (7.25″ x 7.25″ x 7.25″) looks, for all intents and purposes, more like a micro space heater than a network appliance. With its black finish and hacker-esque green power light shining across the front, Progressive Systems’ Phoenix Adaptive Firewall looks more like a toy than a powerhouse security system. Looks, in this case, are most certainly deceiving. Somehow, Progressive has managed to pack into this minuscule cube more features than most full-sized firewall appliances and software packages could ever dream of.

Specs and such
According to the PhoenixWeb site , the Phoenix firewall uses Adaptive Firewall Technology to secure your network. Adaptive Firewall Technology consists of security features and applications working together to protect and hide network assets. Adaptive Firewall Technology includes:

• Adaptive State Analysis (ASA) firewall engine—ASA is a network-level firewall technology that goes beyond the simple packet filtering that’s most commonly implemented to protect networks. Packet filtering examines only a portion of the network packets that traverse between your network and the global Internet. ASA examines all aspects of incoming packets to ensure their validity.
• Anti-attack features—You may not realize it, but an unprotected network can have literally thousands of open holes, or ports, for network traffic to flow in and out of. A “port scan” is a common way to attack networks; the scan searches for all the possible holes in your network to exploit. Port-scanning applications are available for free on the Internet and have become very easy to use. The Phoenix firewall closes these ports and, depending on the security policy you set, dynamically opens and closes these ports based on the packet information provided by the ASA engine. Furthermore, the anti-attack features of this firewall recognize a scanning attack and will actually hide the Phoenix firewall and the network from the attack, maintaining business as usual for your important network applications.
• Network Address Translation (NAT)—The Phoenix firewall uses one-to-many NAT to hide your internal network behind the firewall protection of ASA. NAT can also be used to help conserve IP addresses, which is useful when Internet connectivity provides only a few routable IP addresses.

Additional features not listed on the Web site include:

• Access logging and monitoring
• Authentication secure remote management
• Packet firewall

What Progressive Systems has done, in effect, is to write a group of programs that function independently on top of a standard Linux kernel. The individual programs include:

• pafserver—Using an encrypted tunnel, the Secure Management System (SMS) allows remote administration via a Web browser (port 8181).
• paflogd—This is the logging daemon that’s used by the firewall appliance and that also rotates logs when they become large enough to cause a lag.
• thttpd-phoenix—A specialized Web server used for remote graphical user interface (GUI) management.
• pafnanny—Monitors the three critical programs (pafserver, paflogd, and thttpd-phoenix) and instantly restarts them if they come down. Without pafnanny, it would be possible for one of the critical programs to crash, thereby rendering remote management impossible.
• e-conduit—Provides the tunnel for SMS to communicate to pafserver.
• phoenix kernel module—A user-loadable kernel module that contains the firewall.
• firewall template files—User-configurable firewall applications and protocols.

The list of supported predefined applications is lengthy and covers nearly all the common applications that run over IP-based networks.

The physical appliance is laid out in a very straightforward manner. On the backside of the cube, you’ll find:

• A few buttons (for inputting information)
• Three Ethernet jacks (one for the external network, one for the internal network—each with a status indicator light—and one for a DMZ network connection)
• A serial port (so the appliance can be connected to a console terminal)
• A cooling fan port
• A power switch
• An AC jack
• An LCD screen
• A keyhole button (which allows access to additional features)

Although the machine is designed to be set up and forgotten about (being the Linux champ that it is), the aesthetically pleasing design, as shown in Figure A, will surely become a trophy that most admins will want to display.

Figure A

Here’s the front view of the Microserver.

Setup
My setup of the Phoenix Adaptive Firewall went off with only one small glitch. Out of the box, the cube should be set up to allow IP masquerading so that a machine within the firewall can use the remote administration tools or SMS. Somehow, however, the test machine I received had IPV forwarding set to off so I couldn’t open the remote GUI. Fortunately, tech support was only a phone call away, and the agent I spoke with solved my problem very quickly.

Other than that issue, the setup is as simple as:

• Powering on the appliance
• Opening the Network Configuration menu
• Entering the internal IP address (the address of the NIC that will serve inside the firewall)
• Entering the subnetmask of the internal IP address
• Entering the external IP address (the address used to serve outside the firewall)
• Entering the subnetmask of the external IP address
• Entering the gateway
• Saving the changes
• Rebooting the machine

Once the appliance itself is configured, you’re given a pass phrase for remote administration. (Remember to write down this password.) Now all that’s left for you to do is configure the machines within the firewall. For testing purposes, I had two machines running Red Hat Linux 6.1: one inside the firewall and one outside the firewall. The test machine inside the firewall was my personal desktop machine, and the one outside the firewall was my Linux test box running a simple server.

The private IP address I chose was within the 172.22.1.* range. The firewall’s internal NIC was set up as 172.22.1.1. The machine behind the firewall would have an IP of 172.22.1.2 and a gateway of 172.22.1.1 (hence the need to enable masquerading on the firewall box itself). The final machine, outside the firewall, would have a public IP address assigned by the network administrator (or the DHCP server).

Once I entered the numbers correctly for all the machines, it was time for me to take a look inside and see what this baby was all about!

The first look
Getting to the remote GUI is as simple as pointing a Java-enabled browser (Linux Netscape 4.06 or better) to the internal IP address on the firewall appliance at port 8181. So by entering http://172.22.1.1:8181/, I was greeted first by the Progressive splash screen, followed by a smaller login screen. (I should probably warn you that sometimes the Java script can take a bit of time to load.) Regardless of connection speed, the Java client can take anywhere from five to 25 seconds to load (and that’s on a base 10 LAN connection). Note: The same speeds applied when I was connected with my cable modem. This time issue is not really a problem because it is absolutely the ONLY waiting you’ll do with this system.

According to both the beta user manual and the tech support representative I spoke with, the Progressive GUI has a problem with certain desktop environment/Window manager combinations. Apparently, the most stable combination is KDE/Enlightenment. However, I didn’t have any problems running a GNOME/AfterStep combination. The GUI didn’t crash or lock up on me in over three weeks of testing the application—a fairly good track record.

Once the GUI was up and the login window was available, I entered the pass phrase and logged into the remote management system.

The first look at the progressive remote management system shows the post login window, shown in Figure B. The Progressive contact information is displayed smartly on the right, the navigation window is on the left, and the main menus appear as drop-down menus at the top.

Figure B

In the post login window, the Progressive contact information appears on the right.

The main window (the large window with the Progressive contact information) is where you’ll do all the configuring. Once you either select a service (from the left navigational menu) or open an existing firewall file, the contact window disappears and is replaced by the window shown in Figure C.

Figure C

For the network administrator migrating from a Microsoft environment, Progressive Systems’ interface will feel like home.

In this window, you’ll notice the change in both the main window and the left navigational window. The newly displayed main window is where nearly all the configuration will take place. Within this window, all firewall rules will be edited (with a click of a button or the entry of an IP address), and each service will display a very simple help file to aid the user in understanding what the service is all about.

As far as configuring the firewall rules through this interface goes, it couldn’t possibly get any easier! For the network administrator migrating from a Microsoft environment, Progressive Systems’ user interface will feel like home. Everything is well explained, well designed, and simple to follow.

Example configuration
Figure C shows Progressive Systems’ remote administrative tool (through Netscape) configuring the HTTP secure firewall rule. In the main window (on the right side), you’ll notice three check boxes (Incoming, Outgoing, and Enable), two main boxes (Local Servers and Remote Clients, which change as you click between Incoming and Outgoing), and the Firewall Assistance window. For this particular firewall rule, I’ll look at both incoming and outgoing traffic.

The incoming traffic is, for most situations, the most important traffic to monitor/block with firewall rules. For incoming traffic on secure HTTP, set it up to only allow certain IP addresses through the firewall. So, for this example, allow the IP address A.B.C.1 (obviously, this is not a real IP address) into the port assigned to secure HTTP, and allow that IP access to all IPs within the firewall. To do this, click Incoming, enter * in the Local Servers box, and enter A.B.C.1 in the Remote Clients box. If outgoing traffic is permitted and secure, you can then click the Outgoing button and enter * in both boxes. (This will allow anyone within your firewall to use secure HTTP to reach any outside server.)

Once you’ve set this specific rule, save your firewall file under a specific name, such as test. In order to save a new file, open the File menu, click Save Firewall File As, and enter the name. Once you’ve saved this file, you can then activate it by going to the Firewall menu and clicking Activate Firewall File or by pressing [Ctrl]F. Note: The firewall file you just saved has but one firewall rule—activating the file you’ve just created is a very insecure process. Use caution!

Out of the box, there are two basic types of firewall files: Passall and Outgoing Only. The names are fairly self-explanatory. The Passall file allows all traffic in and all traffic out. The OutgoingOnly file allows all outgoing traffic and no incoming traffic. Both of these files have their advantages, but they are rather limited. The best idea is to take the Outgoing Only file and modify it to suit your needs. With the Outgoing Only file, outgoing traffic is wide open, whereas incoming traffic is nonexistent. Depending on your needs, you’ll want to allow certain services in and not allow certain services out.

I suggest that one of the first things you do with this file is configure port forwarding. Port forwarding takes an incoming request (say, FTP on port 21) and tells the firewall system that when an incoming call for FTP comes in on port 21, send it to this machine instead. So, with the external IP address of A.B.C.1 associated with the firewall appliance, you can redirect services to whichever private IP address you wish. With one machine (inside the firewall) set up for FTP services on 192.34.5.1, follow these steps:

• Choose Port Forwarding Configuration from the Admin menu.
• Click Add.
• Enter the new name for the service (call it FTP).
• Click Enable.
• Click Forward TCPE.
• Enter the firewall’s IP in the Interface IP box.
• Enter 21 in the Port box.
• Type 21 in the Port box for the destination IP.
• Click OK.

Once this is configured, select Save And Activate Current from the Firewall menu. Now the firewall will re-route FTP traffic to the desired machine.

It was the ability to configure port forwarding services that sold me on this machine. Within two minutes of having the Progressive Systems’ firewall appliance up and running, I had FTP and ssh re-routing to my desktop machine. In order to do this on most other software or appliances, I’d have to jump through a multitude of obstacles and read a forest’s worth of books and a gig of how-tos! Not so with Progressive Systems.

The mysterious keyhole
The keyhole on the back of the appliance allows the administrator access to advanced functions of the system. These advanced functions include:

• Reset GUI Passphrase: Select the option Reset GUI Passphrase. Once you confirm this action, you’ll see a new GUI pass phrase displayed on the back LCD screen.
• Enable Telnet: This is not really an advanced feature since it’s also enabled through the GUI interface.
• Display MAC Address: This feature allows the administrator access to the hardware address of the appliance.
• Reset To Factory Defaults: This feature resets the appliance to its out-of-the-box state.

Logging
The Phoenix Adaptive Firewall has a built-in logging system, as any good security system would, that features a modicum of configurability. A typical log file from the PSF looks like:
3/13-19:47:46 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (560)
3/13-19:49:20 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (560)
3/13-19:49:20 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (555)
3/13-19:49:23 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (555)
3/13-19:49:29 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (555)
3/13-19:49:33 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (555)
3/13-19:49:33 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (555)
3/13-19:52:54 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (560)
3/13-19:52:54 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (555)
3/13-19:54:42 eth1:: udp 255.255.255.255/67 <- 0.0.0.0/68 328 !pass (560)

This file shows a small snippet of incoming traffic that’s not allowed to pass (indicated by !pass). I’ll break this log down:

Another very nice feature is the ability to download log files from within the system. Using the same menu that you use to view the log files (Admin | Logging), you can opt to download the log file to the local machine that’s being used to administer the firewall. The downloaded file is named phoenix.log and is much more complete than the information you can view from the remote GUI. You should keep tabs on this downloadable file for more in-depth monitoring of the firewall’s functioning.

Although you might be hesitant to hand over the security of the system you’ve spent hundreds and thousands of hours setting up and parenting to a point-and-click firewall device, Progressive Systems’ firewall will quickly change your mind and prove that Linux has reached well beyond the user-friendly stage. The price of the appliance is a bit steep—running approximately $3,200—but it’s well worth the cost. Such tight security that can be configured remotely, quickly, and without taking down a running system is worth much more than its weight in gold … and Progressive Systems’ firewall is the cream of the crop from this writer’s point of view.

If you’re interested in purchasing one of Progressive Systems’ firewall appliances, you can contact the company through its Web site . You won’t regret this purchase.
The machine I initially received for testing was a beta version of the product, and many of the issues I address in this Daily Drill Down were resolved once I received a full-release product. A few of the configurations had changed—but nothing that would create a problem. The full-release product, in fact, was even richer in features than the beta. Kudos, Progressive Systems!

Jack Wallen, Jr. is very pleased to have joined the TechRepublic staff as editor in chief of Linux content. Jack was thrown out of the “Window” back in 1995, when he grew tired of the “blue screen of death” and realized that “computing does not equal rebooting.” Prior to Jack’s headfirst dive into the computer industry, he was a professional actor with film, TV, and Broadway credits. Now, Jack is content with his new position of Linux Evangelist. Ladies and gentlemen—the poster boy for the Linux Generation!

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.