Previous Table of Contents Next Hour 15 Firewall and Proxy Server Basics Three can keep a secret if two are dead. -Benjamin Franklin This is a scary yet kind of fun hour. I hope you've brought your secret detective code ring and your security blanket. We're going to go seriously James Bond here; you can expect a couple of nifty devices, explosions, bad guys, good guys, and gunplay by the end of the hour. (No, not really. This is a family book.) For some reason, the public perception seems to be that a firewall or proxy server is the major security concern on any network. In reality, although a well-configured firewall or proxy server is really, really important, it's only one piece in a larger security model. Although I won't get into this topic in tremendous detail here, network security relies on good password policies, server configuration, diligent application of security-related operating system and application patches, network auditing, and user dial-in policies (just to name a few things besides firewalls). Just as any responsible corporation has locks on its doors (the firewalls), it also probably distributes corporate ID tags, has receptionists to greet and keep the public from casually intruding on the work environment, and has an accounting system to keep track of the disbursement of funds. Although not every corporation has security guards-much less security guards with guns-they do have locks on their doors and are basically secure. ______________________________________________________________ My personal theory about network security is this: The best way to secure a system that's on a network is to unplug it from the hub, disconnect all dial-up ports, burn the Internet router, disconnect the system's hard drive, and start using paper. (For some reason, this is not a popular security policy.) Failing this, all you can accomplish is best-effort security-and keep good backups. Firewalls are a good beginning to best-effort security. They keep your most obvious entry points locked down and act as a gateway from your inside network to the outside world. ______________________________________________________________ Top Secrets Let's lay out some definitions here. When most folks talk about firewalls, they usually mean packet-filtering routers. As we discussed in the last hour, a router is the glue between two or more network segments. Therefore, a packet-filtering router refers to a router that has rules as to who and what is allowed to be routed between its interfaces. Not so bad, huh? What's a proxy server? First of all, it's not any kind of router. So what is it? Like any kind of server, a proxy server offers services. It's basically a multihomed server that accepts requests on a certain socket and forwards these requests to a server on the other side. Think of a proxy server as a big, bad security guard who will go into a bad network neighborhood for you, retrieve what you want, and return it to you-all without exposing your poor carapace to harm. As in voting, the proxy server proxies you-that is, it acts as your agent to go do something and then reports back to you what the results were. Going back to our old friend the telephone analogy, bear in mind that a proxy server is not "telephone equipment"; it's merely an agent that has two different telephones connected to two different telephone systems. This is hardly the stuff that spy novels are made of. Nonetheless, if you're like most folks, you'll not be configuring your own packet-filtering firewall or proxy server. This is probably a good idea; a misconfigured firewall is almost as bad as no firewall. In some cases, it can actually be worse than no firewall, because it may give you a potentially false sense of security. Granted, we're not doing any soup-to-nuts firewall configuration, but let's take a look at the theory behind it, which will let you start to investigate a given situation and glean what might be wrong. TCP Versus UDP Germane to the theory behind firewalling is the idea that connections can be limited based on the service being offered or sought. Because each TCP/IP service has a unique socket number that it listens to (remember from the telephone analogy that a socket is the extension number that the service person for the company answers), it's reasonably easy for a router or proxy server to limit connections to these sockets. Because limits are placed on the socket numbers themselves, it follows that the service is also limited. This means you can pick and choose among the services that may travel in or out of the firewall. ______________________________________________________________ Actually, services don't have to run on their default socket number; just as your boss can make you sit at a different telephone, a network administrator can change the socket number of a service. This is fairly unusual, but it does happen. For example, students sometimes run their own Web servers on different sockets because the university has occupied the default Web socket with the official Web server. The firewall upshot here is that if you run a service on a nonstandard socket, people might not be able to traverse the firewall to get to you. ______________________________________________________________ This is reasonably easy with TCP (Transmission Control Protocol) sockets. A TCP connection is a connection-oriented call-like a true phone call, where someone dials someone else and establishes a two-way link. A UDP (User Datagram Protocol) conversation, on the other hand, is basically like when I throw you a crumpled-up piece of paper containing a message, and you throw one back at me. This is called a connectionless session. You can think of the difference between TCP and UDP as the difference between you and me using two tin cans and a string (TCP) to communicate versus you and me passing notes in class (UDP). Keep in mind that a note can be easily misdirected. It's fairly trivial for TCP connections to be limited, because the reply to the connection is basically within the same connection. It's a lot harder to do this with UDP sockets. A UDP connection throws out a packet and then waits for the reply. Because no connection exists, the firewall must be configured to accept random UDP packets, any of which might be a reply. Typically, a range of UDP ports has to be allowed in through the firewall, which implies a lot of trust. Some administrators (depending on their site security policies) disallow UDP through the firewall-period. Others rely on SMLI (Stateful Multi-Level Inspection) firewalls, which "remember" the packets that have passed through them and accept responses appropriately. Previous Table of Contents Next