Whew. Hard to tell where to start. I'll try and cover some basics,
but the result will necessarily be very superficial.
Lemme start by defining "firewall": a system for providing control
over network traffic at a choke point. A choke point is a place in
your network's design where all traffic must flow to get between two
areas, with different security policies. In commonest case, the
choke point is where your internet connection comes in to your
in-house net, and the two areas with different security policies are
your in-house net, where you want some security, and the internet,
where there isn't any.
Now the essential feature that emerges from this view is the focus
on the security policy. Before you shop for a firewall, you need to
decide what kind enforcement you want to use it for. Depending on
your policy, one firewall will be better than another. After you've
narrowed the list of possible firewalls down to the ones that work
well at enforcing your desired security policy, the next decision is
probably what sort of platform it runs on and what user interface it
offers for configuration and maintenance; these you'll pick to fit
your in-house expertise. Then comes cost.
A really great, perfect firewall needs to be chosen after you have
specified an exact security policy, in detail.
A firewall can be one box, or it can be many boxes. There are some
standard building blocks that people use to assemble firewalls. Some
building blocks include:
Simple packet filters have a table of rules. They take each
packet in isolation, as it's received, check it against the
rules, and decide whether to allow it through, to simply
discard it, or perhaps to return an error.
Stateful packet filters also have a table of rules. They also have
an in-memory notepad, where they can keep notes on what they
have seen before. The rules can check for things in the
packet, cross-reference with the notepad, and can also
update the notepad. This allows them to do tricks like
tracking TCP connections; the commonest application is to
allow outbound TCP connections without allowing uncontrolled
incoming traffic. An outbound TCP connection must permit the
return packets of that connection through. So a stateful
packet filter makes a note in its notepad anytime it sees a
TCP start-of-connection packet going out. When it sees a TCP
packet coming in, it can check the notepad and see if that
packet belongs to an established connection, and if so allow
it through.
Some packet filters get a little more clever still; they partially
rewrite the packets before forwarding them. This is commonly
done for Network Address Translation (NAT), to allow
connections from a hidden internal network to appear to come
from the firewalling machine itself, hiding the addresses
used on the inside. This is nice since it allows you to use
private addresses (specified in RFC 1918) on your inside
network.
Application proxies are a different beast entirely. Instead of
filtering packets, perhaps modifying them slighly as they go
past, application proxies never allow _any_ packets through.
Where a packet filter is basically a router, forwarding
packets from one interface to another, an application proxy
is basically a server, running daemons that service various
network protocols. Each of these servers is typically also a
client; it turns around and makes the request that the
customer asked for, on the customer's behalf (as a proxy
forthe customer, hence the name), and returns whatever
answer comes back. Application proxies don't forward
packets, they accept connections and issue new connections
of their own, possibly copying some traffic from one
connection to another, possibly modifying that traffic as it
goes past.
As a rule of thumb, with modern computers running modern software,
application proxies tend to have significantly higher latency (delay
between the request and the start of the answer) than packet
filters, but once the delay has passed they aren't much slower
(their bandwidth is good). They also tend to be free of certain
subtle security problems related to obscure, strange kinds of
packets, intended to trick badly-written network stacks. And
application proxies tend to examine the details of the traffic
stream more closely, and to perform more sophisticated analysis and
transformations on the traffic.
You mentioned ipchains. That's the simple packet filtering code
built into current production Linux kernels. It doesn't do stateful
packet filtering for most applications, but it's somewhat connected
with some special-purpose stateful code in Linux, for doing what
they call IP Masquerading, which is a simple subset of Network
Address Translation (NAT) useful for common applications. So you
_can_ have "outbound-only TCP sessions" with Linux Masq code going,
but not with ipchains filtering on normal routing between normal
networks.
There's another packet filtering program available, that
_does_ stateful packet filtering, although it hasn't
been ported to current Linux releases. It's available
for many other Unixes, though, including Solaris. It's
called IP Filter, by Darren Reed, and available from
<URL:http://coombs.anu.edu.au/~avalon/ip-filter.html>.
For lots of purposes, I like building a bastion host (simply, a very
very tightly-secured machine) running packet filtering and proxies
both. There are lots of proxies available. Some of my favourites
are:
<URL:http://www.fwtk.org/>
The Firewall Toolkit, a collection of assorted proxies for
various protocols.
<URL:http://www.squid-cache.org/>
Squid, a high-performance caching HTTP proxy
<URL:http://cr.yp.to/dnscache.html>
dnscache, a DNS caching nameserver (recursive resolver)
<URL:http://www.postfix.org/>
Postfix, a high-security high-performance email (SMTP)
server, and therefore an SMTP proxy.
<URL:http://cr.yp.to/qmail.html>
Qmail, another SMTP server.
Another favourite building block is ssh
<URL:http://www.openssh.org/>, which is useful not only for remote
admin of a firewall, but also for building tightly controlled
tunnels through one, for e.g. updating content on a web server
sitting on the other side of one.
To finish, I'll give a few examples of where I use different kinds
of firewalls.
When I'm setting up a web server farm, I don't use a distinct
firewall as such anywhere. I protect every machine with packet
filtering running on that machine, limiting access to only daemons
that really should be accessible to the public, and I configure
them very carefully. I disable as many daemons as I can on these
machines. The only additional protection I employ lies at the
border, on the router; every border router for every network
anywhere should do some basic filtering, blocking forged source
addresses incoming and outgoing, blocking directed IP broadcast, and
blocking traffic claiming to be to or from the RFC 1918 reserved
addresses.
When I'm setting up a small office, for people who care less about
the tightest possible security than about great performance and
convenient use of most applications, I will use Linux's Masq code to
allow outbound-only TCP, and I'll run Postfix, dnscache, and squid
on the firewall as proxies for smtp, DNS, and http (outbound only).
When I'm setting up a firewall for people who care more about
security then about maximizing their entertainment potential, I'll
deploy servers for things like public web service, public DNS
service, public SMTP email service, etc. into a DMZ between outer
and inner screening routers. Between the DMZ network and the inner
screening router, there will be a dual-interface bastion host, with
proxies reinforced by packet filtering; it won't be doing any packet
forwarding, only proxying, the packet filtering is there to make
it easy to apply blocking rules per-interface. The only protocols
allowed through will be outbound file xfers through http-gw (from
fwtk) with applet stripping, email forwarded by postfix, dns proxied
by dnscache, and select, carefully configured port forwarding
allowing specific ssh connections to hosts in the DMZ.
If you are nervous about the prospect of assembling your own
firewall from scratch, by all means check out various other
offerings, but first figure out what kind of controls you want to
impose, and evaluate them in terms of their ability to let you do
what you want.
-Bennett
PGP signature
