Web Hosting
Home > Articles > Web Hosting Related > Budget Firewall


Open-source firewalls are often the cheapest and most appropriate solution for protecting your servers.

Tony Bourke Special to Hostingtech | tbourke@hostingtech.com

Just like you were told in health class, you should always use protection. In the Internet world, this means putting a firewall between your servers and the Internet (and its bad guys). There are a plethora of choices for secure firewalls available on the market, from Cisco to CheckPoint, from NetScreen to Raptor. Unfortunately, it is not always possible to use one of those fancy commercial firewalls, due to any number of financial or logistic reasons. Fortunately, there are open-source alternatives that can address these issues.

The biggest factor constraining the implementation of a firewall is probably cost. Commercial firewall hardware products can start at $10,000 for a redundant set, and not everyone can afford that, especially given the current economic climate. Combine the cost with certain logistic issues, and commercial firewalls are doubly impractical. For example, does it make sense to spend $10,000 if you need to protect $4,000 worth of equipment? If you need to protect several dozen machines, spread across several locations, does it make good fiscal sense to deploy a commercial solution, one that would require a separate firewall for each location?

Bandwidth needs can also be a constraint, because many commercial firewalls have a limitation of 70 to 90 Mbps. This range serves as a good rule of thumb; however, it depends greatly on the type of traffic and the type of firewall used. There are firewalls that are capable of higher levels of traffic, but they can cost somewhere in the six-figure range.

To avoid some of these limitations, system administrators have developed a few alternatives to the firewall. One method is to use no firewall at all. This is fine, so long as you don't care about security and can sleep at night, knowing a decent hacker can use a cracked machine to invade others in the same network. A better alternative is to put ACLs (access control lists) on the routers that provide the connectivity to the installation. ACLs basically give routers much of the functionality of a firewall. However, in certain hosting situations, this can raise performance concerns. With the ACL configuration, if one site gets attacked, it could bring the router's performance down or knock it out completely, affecting other customers.

The open-source alternative
If you don't have a generous hosting provider, an overflowing I.T. budget, or the desire to leave your servers flapping in the wind, you might want to consider another alternative: open-source, server-based firewalls. These firewalls are applications that run on various commercial and noncommercial Unix operating systems, such as Linux, Solaris, and FreeBSD. Like the commercial firewalls, they provide the basic functionality, such as packet filtering, stateful awareness (ZDNet defines "statefulness" as the ability of a network to ensure that all requests from a given client are processed through the same server), and NAT (network address translation), and they are free. These solutions require a nominal expenditure for additional equipment, if at all.

Server-based firewalls work by becoming part of the operating system's networking stack, the segment that handles network communications. Most commercial firewalls also work this way, although they are typically more specialized than a general operating system. For example, CheckPoint can run on top of Solaris or Windows NT/2000, although it takes over the machine completely and does not allow any other applications to be run. Nokia's firewalls run CheckPoint on a heavily modified version of FreeBSD. Firewalls such as PIX or NetScreen are written from the ground up as firewalls, and do not run on a regular operating system.

The open-source firewalls run on top of the operating system, just like CheckPoint or Nokia; however, they do not necessarily negate the rest of the machine's functionality. They are typically loaded in as a kernel module or compiled directly into the kernel.

Open-source firewall: A few models
There are two common scenarios for using open-source and freeware-type firewalls. Each scenario depends on a particular situation and the desired result.

The first scenario is a server-based firewall solution. This is when the firewall code runs on each individual server, making each machine responsible for its own protection. This is good when cost conservation is crucial, because no additional hardware or commercial software is required. It works well for the small-to-medium hosting operation, such as a Web access or e-mail provider, with 10 or fewer servers.

This scenario also handles high-bandwidth situations extremely well. Take the example of a site with multiple servers pushing about 100 Mbps between them. A firewall capable of protecting a group of servers at this traffic level could easily cost in the high six-figures. Putting the firewall code on each individual server distributes the firewall load to the individual machines, so no one device handles all of the traffic. Even at high levels of traffic, a machine's own firewall can usually handle whatever level of traffic the machine itself can generate without any trouble.

The drawback to this type of scenario is that, with any more servers, maintaining the rule sets for all the firewalls can become a logistic headache and even a security hazard. A setup like this requires that every machine must run an OS that has a firewall application available, in order to be protected. This means that some types of OS will not be suitable for use in the server environment, despite potentially having other desirable features. Even with these drawbacks, this is probably the most common usage for open-source firewalls.

A more traditional method is to assign a single machine to be a dedicated firewall, in much the same way that commercial firewalls are implemented.

This is useful when there are a number of devices needing protection. For most installations, the machine need not be a powerhouse. A Pentium II-class computer running at around 300 MHz or more should be plenty for most traffic levels. This type of machine can be put together very inexpensively, usually for much less than $1,000. For higher traffic levels (20 Mbps or more, generally speaking) a higher-class machine may be required, but even then the cost is very low.

In a typical office situation, the firewall device protects machines behind the firewall by using something often called one-to-many NAT or IP masquerading. This prevents inbound communication directly to the office computers, but still allows them to make outbound connections. In an office environment, it is rarely necessary to allow access to desktop computers from outside the private network. Often, the office machines sit on a non-routed RFC 1918 address space (such as the 10.0.0.0/8 network), and are all assigned to a single public IP address on their way out. All outbound connections come from the same IP address, no matter which computer initiated the connection, and inbound connections are prohibited.

OS breakdown
There is a variety of free, open-source, OS-level firewalls available, running on a variety of Unix platforms. Making the right choice depends on individual demand, platform, and preference. Netfilter, IPFilter, packet filter, and BPF (Berkeley Packet Filter) are the most popular tools available. Freeware and openly developed software applications use various licenses (e.g., GPL, FSF, Berkeley, etc.), and it is important to check each license to make sure the intended uses are in compliance with the applicable license.

For Linux, the OS-level firewall depends on the version of the Linux kernel you are running:

  • Linux 2.0: ipfwadm (non-stateful)
  • Linux 2.2: ipchains (non-stateful)
  • Linux 2.4: netfilter (stateful)

    If you are running Linux as a firewall or a firewalled host, use Linux 2.4 with its netfilter firewall code, because it is stateful. Earlier versions are not stateful, and their use increases the potential for being attacked as a result.

    FreeBSD and NetBSD come with IPFilter as the firewall package, as well as BPF (Berkeley Packet Filter). OpenBSD used to incorporate IPFilter with its basic distribution, but beginning with version 3.0, it uses its own filter, simply called "packet filter." OpenBSD is widely regarded as a highly secure operating system, and it is ideal for use as a firewall.

    IPFilter is also the most popular firewall freeware package for Solaris and is compatible for versions 2.6 through 8. With IPFilter, it is important to know if you are running Solaris 7 or 8 in 64-bit mode. If so, then the IPFilter binary needs to be compiled for 64-bit Solaris, because IPFilter is a kernel module. Versions of GCC (GNU's open-source C compiler) prior to 3.0 cannot compile 64-bit binaries for Solaris. To successfully compile IPFilter requires Sun's "cc" application or a specially compiled GCC 3.0. Sun's cc is quite expensive, and this can present a problem. Fortunately, on the IPFilter download site there is a pre-compiled 64-bit binary version available to address this issue.

    The other Unix flavors, such as IBM's AIX, SGI's IRIX, and Hewlett-Packard's HP-UX all have OS-level firewalls available, including versions of IPFilter and the BPF.

    Windows 2000 and Windows XP have a built-in network packet filter. It can be accessed by checking the network control panel, picking the interface, checking the TCP/IP properties, going into advanced, options, then properties of TCP/IP filtering. From there you can choose which services, protocols, and ports to be allowed. These options are not stateful, however.

    Stateful firewalls
    Statefulness is a critical feature for firewalls to have, but not all of the OS-level firewalls have this functionality. It is important because it allows much greater flexibility and control over the type of traffic that is permitted. Without stateful capability, a firewall's rules for a Web server might look something like this:

    Allow in TCP port 80
    Allow in TCP ports >= 1023
    Deny everything else

    You'll note that the firewall is allowing all ports above 1023. This is necessary for outbound connections to work, because the TCP protocol uses a TCP port above 1022, locally, for an outbound connection to transfer data. Here is an example where an outbound SSH connection from one workstation (192.168.0.15) to another machine (192.168.0.25) is being made. A netstat (Unix and Windows command to show active TCP connections) shows the following TCP information:

    Proto
    Local Address
    Foreign Address
    State
    TCP
    192.168.0.15:22
    192.168.0.25:1029
    established

    The destination port is 22, but the local TCP port of 1029 is also used for that connection. For any outbound TCP connection to work, all TCP ports 1023 and above must be allowed through. This leaves a significant portion of any machine vulnerable to attack or probing, and any number of illicit services can be setup by users or by Trojan horses or viruses.

    In an actual setting, the remote machine makes a connection to the local machine on any port 1023 or higher. The outbound connection is on port 80 with the local connection on port 1029. Blocking anything on TCP port 1023 or higher would prevent that two-way connection from functioning, and all outbound connections would not work. Statefulness takes care of this by not only inspecting the source, destination, and connection ports, but also what TCP state the connections are in. For a stateful firewall, the rules for a Web server might look like this:

    Allow in TCP port 80
    Allow in TCP established
    Deny everything else

    The "TCP established" rule allows us to close ports 1023 and higher, because the stateful firewall can check the TCP state. The rule says that if the inbound connection is based on an already established outbound connection, then let it through. Such an inbound connection has an EST (established) flag, which only a stateful firewall can check for.

    Most OS-level firewalls are now stateful inspection, although there are exceptions. Make sure you know the capabilities of the package you plan to purchase. For instance, Linux 2.0 and 2.2 use ipfwadm and ipchains respectively, neither of which are stateful. If Linux is to be used for the firewall, it is better to upgrade to the Linux 2.4 kernel and its netfilter package, which is stateful. The built-in Windows TCP/IP filtering is not stateful.

    Exposing yourself
    There are certain types of malicious attacks that most types of firewalls cannot prevent against, such as certain types of DOS (Denial of Service) attacks, certain types of DDOS (Distributed Denial of Service) attacks, a ping flood, or other high-traffic flood. The firewalls mentioned do not have any way of checking the Layer 5-7 traffic to determine if the traffic should be blocked; therefore, any service that is open (e.g. SMTP, POP3, and HTTP) and has an exploit is vulnerable. It is important to keep up-to-date on server software patches and to keep an eye on the various security mailing lists and announcements.

    The best firewalls also cannot protect against weak passwords, back doors left open, un-patched Web servers, or other common sense type security measures. A firewall is only one piece in a larger security picture, and, as the saying goes, security is only as strong as its weakest link.

    These open-source, server-based firewall solutions offer a great alternative to the commercial firewall products. They are effective, flexible, and free. Although they might not provide all the functionality of commercial firewalls, they do provide protection in situations where commercial firewalls are not a viable choice.

  • Web HostingWeb Hosting

    http://www.powweb.com/

    Web Host


    web hosting related articles