Building a Linux-Based Appliance

Have you ever solved the same system administration problem for many clients and wished you didn't have to reinvent the wheel every time? Or had the desire to build your own appliance but not known how? A recent consulting project gave us the incentive we needed to build our own appliance. By sharing the technical and business challenges we encountered and the solutions we implemented, we hope to offer some insight that will help you bring your own Linux-based appliance to market.

Our clients ask us to do a wide variety of IT projects, from setting up e-mail to implementing firewalls and VPN configurations. On a recent project, a customer asked us to look into the company's existing firewall configuration. They had a Cisco PIX firewall in place, but it was using an outdated version of the Cisco software. Given the costs involved in adding VPN support and purchasing the upgrade, they asked us to review with them the other firewall options on the market, including Check Point FW-1 and a Linux IPTables/IPSec solution. Based on their business requirements, they ultimately decided to go with a Check Point FW-1 firewall and VPN solution.

In implementing security solutions for other customers, and solving similar issues for each implementation, we had developed the idea of building a standalone firewall appliance. But we had not yet worked with the right customer to make an implementation possible. What finally made the decision to build an appliance easy was this particular customer's willingness to beta test the product.

In previous implementations we had developed some simple shell script-based tools to help automate common tasks for our customers and enhance the functionality of existing vendor-supplied tools. But as we developed the security appliance, we realized these shell scripts were simply not sufficient for a commercial product. As we developed a more advanced set of tools, we created a number of product features that should be useful for any appliance, not only a security appliance.

With our goal in mind, we put together the following set of product requirements. We knew our customers would require a true standalone box in which all administration functionality would be completely self-contained and provided by the appliance itself. There should be no need for a separate Windows- or Solaris-based client (e.g., the existing Check Point tools.) Moreover, the configuration software we provided would have to offer significant enhancements to the existing vendor-supplied tools. Our software would need to include backup/restore/undo functionalities. Given that our hardware platform would be engineered to be fully redundant and to support automatic failover (two complete systems in a single 1U form factor), our appliance would need to come with built-in, preconfigured failover software support. In other words, our box would need to support all the fundamental components of a true appliance solution.

Users of single-function boxes, such as routers, have long known the major advantage of a complete, standalone appliance solution: the administrator can log on from virtually any machine or terminal to make configuration changes. There is no need to have special Windows, Solaris or other client software available/installed to make changes. Moreover, the administrator does not need to ensure hardware and software compatibility, install and configure the operating system, and then add and configure application software and management clients. With an appliance everything is completely self-contained. The administrator simply drops the new box into the network, logs in via ssh or a web browser to configure a few key settings, and the box is up and running.

For Linux Journal readers, it goes without saying that Linux is the obvious choice for building appliances. It is worth mentioning that we also investigated Solaris and the Windows 2000 Server Appliance Kit as alternative platforms. Linux won because it was cost-effective, had a great community with good development support and had source code readily available.

Our V1 product does not include any changes to the kernel. Nevertheless, it was critical to know that as our customer base grows and our customers' requirements increase, we have the option of fine-tuning system performance and parameters through access to the source code. Moreover, there really is no better form of documentation than being able to look directly at the source code. And in the case of a bug or security hole, we are not dependent on any vendor for a patch or fix. In the worst-case scenario, we can make changes ourselves until a vendor supplied patch becomes available.

We also wanted to use a platform that was well tested and vendor supported; would be easily and positively recognized by our enterprise customers; was used by lots of other developers, so it would be easy to have questions answered; and, most importantly, was supported by the vendors whose software we would be using on the appliance--in this case, Check Point. So while using SuSE was intriguing, Checkpoint's default support for Red Hat made Red Hat the clear choice for our product.