Internet Firewall Essentials by Eric Hall FireWall Basics What, Exactly, is a Firewall? Almost by definition, a "firewall" provides a filter that incoming or outgoing packets must pass through. If the firewall does something beyond filtering, like checking against a restrictions list, that's great, but it's not necessarily the "definition" of a firewall's function. Of course, most firewalls do perform some sort of "accept" or "reject" functionality, but that's strictly a matter of implementation. The simplest firewall could just be an Ethernet bridge that you keep powered off, only to be made available when the connection is needed. This would probably work for keeping intruders off of your network, but I doubt you'd enjoy the management interface much. Most firewall products offer much more in the way of actively filtering packets according to certain criteria that you establis h. These filtering firewall products can take many forms. They may be a replacement TCP/IP stack that you load on an existing system, or a software module that exclusively communicates with an existing stack. At the other end of the extreme, the product may be a completely independent operating system written explicitly with Internet security as the objective. There are also application-specific firewall products that only offer protection for certain types of Internet connectivity, such as SMTP or HTTP. There are also hardware-based products that typically fall into the router realm, allowing you to set filters for incoming and outgoing connections. Prices range from free (bundled with the stack or app) to tens of thousands of dollars. All of these products can rightly be called "firewalls" because essentially they trap inbound or outbound packets, analyze them, and then either send them on their way or toss them out. Any one of these products may or may not suit your needs. Once you've got a handle on the issues, however, you should be able to do your own product elimination, simply by comparing functional specifications. At the least, almost all firewall products offer IP address filtering. These filters work by examining the header of the IP packet and making pass/fail decisions based on the source and destination IP addresses. For clarification purposes, let's look at the figure above, which shows a simple two-segment network with a firewall separating them. One segment has a UNIX host, and the other has a PC client. When the PC client tries to Telnet to the UNIX host, the Telnet client on the PC generates a TCP packet, and hands it to the local stack for delivery. In turn, the stack places the TCP packet inside of an IP packet, and then sends to the UNIX host via the route defined in the PC client's TCP/IP stack. In our case, the PC client is sending the IP packet to the firewall for delivery to the UNIX host. Suppose that we have told the firewall that it is not to accept any packets destined for the UNIX host, as depicted in below. Then the firewall would reject the IP packet, perhaps bothering to tell the client or perhaps not. Since no IP traffic for that destination would get forwarded, only users on the same segment would be able to access the UNIX host. Another scenario might be that the firewall has been configured so that it simply will not accept any packets from that PC in particular. Then other systems could connect to the UNIX host, but that specific PC could not. This type of filtering is the most basic of all. By setting accept or reject filters per IP address, these types of products can provide very basic protection mechanisms for a simple LAN. If the systems are not allowed to communicate because of source or destination IP address filters, then the packets are simply rejected. These types of filters are commonly used in smaller shops that need to control where users can or cannot go, but beyond that they're not extremely reliable. IP addresses can be spoofed, so using these filters by themselves are not enough to stop an intruder from getting into your network. However, it is a fundamental building block of good firewall design, and is a critical component of a complete defensive infrastructure. If you do employ IP address filters, then make sure that you use IP addresses when you create your accept and reject tables, and don't use DNS host names, since DNS can be spoofed even more easily than IP addresses can be. TCP/UDP Port Filtering Using simple IP address comparison to allow or reject packets is a brute method of filtering. It doesn't allow for the possibility that multiple services may be running on the destination host, some of which we may want to allow users to access. For examp le, we may not want users to Telnet into the system, but we may want them to be able to access the SMTP/POP mail server that's running on it. To enable this level of control, we have to be able to set filters according to the TCP or UDP port numbers in conjunction with the IP address filters described earlier. For example, the default Telnet configuration calls for the server to monitor TCP port 23 for incoming connections. Therefore, if we know that we do not want to allow any Telnet connections to our UNIX host from the PC, we can simply tell the firewall to reject any IP packets going to the UNIX host that have a TCP destination port number of 23. Since the PC's Telnet client would normally generate just such a request, the service would effectively be disabled for it, as depicted above. It should be pointed out that this type of setup -- where we are explicitly excluding a port -- is generally a bad idea. If you need to protect a system, you're better off by rejecting everything, and only accepting the TCP or UDP packets that you know you want to let through. It may seem like more work, but it's less work in reality, and has the added benefit of keeping your systems from being easily compromised. In other words, of the two approaches -- that which is not forbidden is allowed, and that which is not expressly allowed is forbidden -- the latter one is safer. If we wanted to reverse this example, perhaps using SMTP and POP, then we would add these services to the acceptable list for the UNIX host's destination address, and reject all other packets. Therefore, any connection request bound for the UNIX host which had TCP destination port addresses of 110 or 25 would be allowed to pass, but no other packets would, since they wouldn't meet this "allow" condition. This would include Telnet, thereby providing the "exclude" condition described above, only with less work (told you so). By combining the IP addresses and TCP/UDP port numbers, you can develop some pretty reliable filters. For example, if your internal SMTP mail server only talks to your Internet Service Provider's (ISP's) mail server, then you could implement a firewall filter that only allowed incoming SMTP connections that came from the ISP's mail server, and are destined for your internal SMTP mail server. This will keep some of the hackers from being able to exploit any SENDMAIL weaknesses that you haven't plugged. This level of control is generally where many of the pseudo-firewall products stop. By allowing you to set your filters so that no incoming traffic from the Internet can access any ports except the ones you want, it would seem to preserve your security to a satisfactory degree. However, this is just not the case. Clients have TCP/UDP Ports, Too Since TCP/IP is a peer-to-peer protocol, each node has a unique address. This philosophy carries up into the applications layer as well, meaning that applications and services also have addresses (or port numbers). Since it takes two to tango, both the client and the server must have unique port numbers on their individual systems in order for a TCP or UDP connection to be established. For example, the Telnet server listens for incoming connections on port 23. However, the Telnet client also has a port number. Without this, the client's IP stack would not know which application the packet was for. Historically, almost all TCP/IP client applications use a randomly assigned port number above 1023 for their end of the connection. This is a legacy from TCP/IP's roots in the UNIX world. On UNIX systems, only the root account has access to ports below 1024, which are reserved for server services (like Telnet, FTP, etc.). In order to allow client applications to work, they must use port numbers above 1023. For you to allow an y sort of connection to work then, you must allow any packet with destination port numbers higher than 1023 to come into your network. If the response packets are not returned, the client will not be able to establish a connection. In terms of Internet firewalls, this can cause some problems in design. If you are to block all incoming ports, then you have just kept all of your clients from being able to use Internet resources. The inbound packets that are the responses to their external connection requests will not survive the firewall's inbound filters. You may think that it's okay to open up all ports above 1023. Not so. There are a lot of services that run on ports higher than 1023, such as X clients, and RPC-based services like NFS and NIS/YP. Most of the non-UNIX IP-specific products -- like NetWare/IP for example -- use port numbers that are above 1023 as well. This means that if you let any old packet that meets the above-1023 criteria into your network, then you're exposing those systems to attack, and none of them are particularly well known for their robust security mechanisms. Updated November 15, 1996 Print This Page E-mail this URL