|
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.
|
