So what is a firewall?

In a building, a firewall is a specially-built wall that protects the rest of the building in the event of a fire, by preventing the fire from spreading. Network firewalls follow the same principle: they keep the 'flames' of the Internet out where they belong, protecting your assets (be they CPU cycles, disk space or next year's Nobel Prize-winning nuclear formulae). Firewalls act as a protective barrier between your private network and the rest of the world.

Why would I want a firewall?

One of the simplest reasons for wanting a firewall is this: you and your roommate have an apartment, and you decide to create a LAN (Local Area Network) with your computers so that you can play networked SimCity when the need strikes. Since you're already sharing everything else and you only have the one phone line, you get out your old 486, slap Linux on it, and use it to dial into the outside world. Unless you're a fortunate person, you won't have dedicated IP addresses for your machine, the dialup machine, and your roommate's machine, so you decide to use one of the unroutable address spaces[1]. Now that little dialup box has to translate every address on the way out, and since it does, you decide it would be handy to have it configured to keep other people out--wouldn't want them stealing your top secret SimCity designs!--and hey, presto! You now have a need for a firewall: a box that will deal with the outside Internet for you, and exchange your data in a safe manner with the rest of the world. Note that 'safe' here also means 'not broken'--that's where the address translation portion comes in.

OK, why wouldn't I want a firewall?

In short, if it's got nothing to do. If you have one machine, your workstation at home, that dials up to your ISP and that's the only machine connecting to the outside world at one time from your location, you probably don't need a firewall--you can implement all the security you need on that box directly without the need for adding an intermediary. That applies as well if you have a workstation on your desk in your office: you don't need a firewall in your cubicle between you and the rest of the network, but your network itself should have a firewall to protect all those hosts.

So you want to own a firewall

There are two basic kinds of firewalls: Packet-Filtering, and Proxying. They evolved from two slightly different, yet very similar ways of ways of approaching network security. Let's look at each one for a moment:

• Proxying firewalls came out of having to do address translation from one network to another. On a proxy-based firewall, the interior hosts make a connection to the firewall, which accepts their packets, and then rewrites them to make it seem as if they came from it, before passing them on to the outside world. To create this illusion, the firewall runs daemons, or proxies, which listen on the port you want to talk to your eventual destination on, 'intercept' the traffic, and rewrite it. They also maintain sessions, so that when they see a returning packet from that host you just sent a request to, they can rewrite the packet on the way in so that it gets back to you. A typical conversation, say, getting a web page, would look something like this: Host "A" (10.1.1.2) wants to get a web page from Host "C" (www.redhat.com, or 199.183.24.133). Host "B", the firewall, has two addresses: 10.1.1.1, with which it talks to the 10.1.1.0 private network, and 199.72.32.114, which is reachable by anyone in the world using TCP/IP. Here's what the packets might look like, in simplified form:
  1. Packet from A to B's proxy:

  Destination:	199.183.24.133
  Source:	10.1.1.2
  DATA:	GET /index.html HTTP/1.0

  2. Now B rewrites the packet before dropping it onto the wire to go to Red Hat:

  Destination:	199.183.24.133
  Source:	199.72.32.114
  DATA:	GET /index.html HTTP/1.0

  3. The proxy running on B continues to run, and then sees the reply from the server containing the data:

  Destination:	199.72.32.114
  Source:	199.183.24.133
  DATA:	[Insert lots of HTML here]

  3. Since the proxy saw the request, it knows how to rewrite the incoming packet again:

  Destination:	10.1.1.2
  Source:	199.183.24.133
  DATA:	[Insert lots of HTML here]

  Notice the big tradeoff here: speed. There's now a third party in every single transaction you make with the outside world. Every packet that the firewall allows to pass must be rewritten to appear that it comes from the firewall, and then the responses must also be coded to return to the proper host. For a user-based LAN running on a T1 connection to the outside world (a mid-sized office of 75 or so), this extra time won't really be noticeable except perhaps when that bozo comes back from lunch who always fires up PointCast and RealAudio to get his news, forcing the firewall to rewrite a lot of packets, very quickly. As a side note, it is for this reason that many admins don't even allow RealAudio or PointCast connections through their firewalls: that much data can bog a proxy down. The real advantage here that you get in return is that your internal network is pretty darn safe: so long as every internal host only talks to the firewall and no one else, your internal network could consist of almost any legal address you wanted, and the world will never know. One option if you do have a routable set of internal addresses, of course, is to implement a transparent proxy: this doesn't rewrite the packets, it just takes the packet from A, examines it to make sure it's allowed, then hands it to C without alteration. Both C and A think they're talking to each other without intermediaries, but you still get to control the flow and content of the data passing between them.

  In fact, transparent proxies are similar to the other variety of firewall: the Packet-filtering firewall. Instead of having an application running that picks up each packet, examines it, then rewrites it and sends it on, the Packet-filtering firewall simply examines each packet it sees to make sure the connection it wants is legal. If it is, it lets the packet go; if not, it drops the packet. It's a simple implementation, which makes this a good firewall for high-speed connections.

  The unrouteable address spaces (AKA the 'Martian' networks) are defined in RFC 1918, created by a group working for the IAB. In order to facilitate the use of TCP/IP addressing for networks that did not require any outside access from other networks (e.g. an airport terminal display network), the IANA (Internet Assigned Numbers Authority) set aside three networks as private and unrouteable. Those blocks of addresses may be used by anyone, but no one may register them with any authority as routable addresses for a host. If you have a network behind a firewall, the firewall can translate your private network addresses into its public address, so that you can have a very large network which can easily talk out to the Internet, but cannot be reached from the outside. To quote RFC 1918,

  The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
  10.0.0.0 - 10.255.255.255 (10/8 prefix)
  172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
  192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

  return
  -| Previous: Network Environment Security Page | | Next: Tools of the Trade |-