So you have come to the realization that your network, along with every other network in the universe, ought to be connected to the Internet! While preparing for the connection, installing software, training users, and managing addresses, it is critical that network administrators devote some time to one issue that has gone relatively under-reported in the popular Internet press until recently; namely, that of security (or lack thereof). Security is an issue often over-looked by many companies attaching to the net, particularly if they have limited experience attaching to the outside world; security may be lacking on the local network in the first place, it may be viewed as an unnecessary bother, or passwords may seem like all the protection anyone could want or need. Securing your network from the outside world to your level of comfort is not tacky or unfriendly; it is a necessary precaution and, in some cases, may be a legal requirement.
Immediately after reading this article, all LAN/Internet administrators should read Firewalls and Internet Security: Repelling the Wily Hacker (Addison-Wesley, 1994) by W.R. Cheswick and S.M. Bellovin, both of AT&T. The book is TCP/IP-specific and very UNIX-centric, but the lessons to be learned extend easily to other operating systems and maybe even to some other protocol stacks. The book also contains an extensive list of additional resources, code, and security tools.
But more to the point: this book will not only convince you why security precautions are absolutely necessary, but it will cure you once and for all if you believe that passwords provide adequate protection from the serious intruder. The book also describes holes in the TCP/IP protocol stack that you might never have imagined. Without adequate security, your LAN is not merely attached to the Internet, but it is much more a part of the Internet than you really want. It is certainly true that all protocol stacks have security holes but the very public nature of TCP/IP and the Internet makes all such holes appear to be almost unique to this environment. I give this book my highest possible recommendation: I Spent My Own Money To Buy The Book.
Firewalls, according to Cheswick and Bellovin, may be generally classified into three types: packet filters, application gateways, and circuit gateways. Packet filters block the transmission of packets based upon the protocol, address, and/or port identifier, while application gateways filter traffic using application-specific rules. Circuit gateways act as a TCP relay; an external remote host connects to a TCP port at the gateway and the gateway, in turn, establishes a TCP connection to the intended destination on the internal local network. Often, more than one of these types may be used together.
This article will focus on simple packet filtering for a couple of reasons. First, almost all routers have some form of filtering capability. Second, understanding packet filters requires an understanding of the TCP/IP protocols that is helpful in establishing other gateway protections. It should be noted that some experts consider packet filters to be the weakest form of firewall protection, primarily because of the difficulty in correctly setting up the filtering rules (making them possible to circumvent since they're often not set up correctly!). Nevertheless, packet filtering is also the most easily accessible form of firewall protection in most environments and is a good first step.
inside ---------- outside | | | | LAN side ======+======| Router |======+====== WAN/Internet side | | | | ----------
When setting up packet filters, you must first determine what filtering capabilities your router has and where you want to filter. If your router has one or more LAN ("inside") ports and/or one or more WAN ("outside") ports, you probably want to filter on the outside, to protect the router (Fig. 1). Most routers do, in fact, allow you to build packet filters and apply them on a per-port basis.
In the discussion below, the rules are stated in a simple, general form that does not follow any particular router vendor's format; readers are urged to consult their vendor and/or vendor's literature for specific information about their own system. In each filtering rule below, we can specify:
The list below is a sample set of packet filtering rules that might be assigned to the router's WAN (outside) interface:
# Dir Action Protocol Address/Port Information Flags -- --- ------ -------- ----------------------------------- ----- 1 IN ALLOW TCP source=23 estab 1 OUT ALLOW TCP dest=23 2 IN ALLOW TCP source=21 estab 2 OUT ALLOW TCP dest=21 3 IN ALLOW TCP source=20; dest>1023 3 OUT ALLOW TCP dest=20 4 IN ALLOW TCP to: 254.1.1.1; dest=21 4 OUT ALLOW TCP from: 254.1.1.1; source=21 estab 5 IN ALLOW TCP to: 254.1.1.1; dest=20 estab 5 OUT ALLOW TCP from: 254.1.1.1; source=20 6 IN ALLOW TCP to: 254.1.1.2; dest=25 6 OUT ALLOW TCP from: 254.1.1.2; source=25 estab 7 IN ALLOW TCP to: 254.1.1.2; dest=25 estab 7 OUT ALLOW TCP from: 254.1.1.2; source=25 8 IN ALLOW UDP dest=53 8 OUT ALLOW UDP dest=53 9 IN ALLOW ICMP 9 OUT ALLOW ICMP
The first rule applies to Telnet, an application that runs over TCP. Standard Telnet servers use the well-known port #23. Rule 1 allows outgoing packets to a Telnet server; it also allows incoming Telnet packets from a Telnet server if they are part of an existing connection. The result of this rule-pair is that any of the LAN users can establish a Telnet connection to an Internet host but no one on the Internet can establish a Telnet connection to one of the LAN's hosts. In my environment, for example, this rule makes sense; no one is supposed to be running Telnet server software on their system and, if they do, we don't want it accessible from the outside.
-------------------------------------------------------------------- | Port | Protocol | Port Name (Function) | |-------+----------+-----------------------------------------------| | 20 | TCP | ftp-data (FTP data connection) | | 21 | TCP | ftp (FTP control connection) | | 23 | TCP | telnet | | 25 | TCP | smtp (Simple Mail Transfer Protocol) | | 43 | TCP | whois/nicname | | 53 | TCP/UDP | dns (Domain Name System) zone transfer/query | | 67 | UDP | bootp (Bootstrap protocol) | | 69 | UDP | tftp (Trivial File Transfer Protocol) | | 70 | TCP | gopher | | 79 | TCP | finger | | 80 | TCP | http (HyperText Transfer Protocol) | | 111 | UDP | rpc (SUN Remote Procedure Call) | | 119 | TCP | nntp (Network News Transfer Protocol) | | 123 | TCP/UDP | ntp (Network Time Protocol) | | 161 | UDP | snmp (Simple Network Management Protocol) | | 162 | UDP | snmp-trap (SNMP Trap) | | 179 | TCP | bgp (Border Gateway Protocol) | | 513 | TCP | rlogin | | 514 | TCP | rexec | | 517 | TCP/UDP | talk | | 520 | UDP | route (Routing Information Protocol) | | 2049 | UDP | nfs (Network File System) | | 6000 | TCP/UDP | x11 (X-Windows) | --------------------------------------------------------------------
The next four rules deal with the File Transfer Protocol (FTP), another protocol that operates over TCP. When a user (the client) opens an FTP session with a remote host (the server), the client sets up an FTP-control connection to the server on TCP port #21. When the client sends FTP commands to obtain directory listings or to initiate file transfers, for example, the FTP server establishes an FTP-data connection with the client using TCP port #20; the FTP client is assigned some TCP port number greater than 1023. Note that the server sets up a new FTP-data connection for each dir, get, or put command and that the client is assigned a new TCP port number for each new FTP-data connection. Rule 2, then, allows outgoing FTP-control packets, but limits incoming FTP-control packets to existing connections, while Rule 3 allows incoming and outgoing FTP-data packets. These two rule-pairs allow our users to establish an FTP connection with any FTP server on the Internet.
Rules 4 and 5 also deal with FTP; they limit new incoming FTP-control connections and new outgoing FTP-data connections only between the LAN's FTP server (IP address 254.1.1.1) and a remote host. These rule-pairs, then, allow any Internet host to establish an FTP connection to the designated FTP server but to no other host on the LAN.
Rules 6 and 7 are very similar to Rules 4 and 5. These two rule-pairs allow incoming and outgoing SMTP packets (TCP port #25) between the mail server (IP address 254.1.1.2) and any Internet host. (This rule, although common, may be too broad since now any Internet host can attempt to establish an SMTP connection to the local mail system. To limit the scope, some networks only allow SMTP connections between their own mail system and a designated mail relay; a problem can arise, however, if the mail relay goes down, although the rule could still limit connections to a known network.)
Rule 8 allows incoming and outgoing Domain Name Server (DNS) query packets (UDP port #53). Rule 9 allows inbound and outbound Internet Control Message Protocol (ICMP) packets. Other similar rules can be applied for other ports and applications, such as Gopher, http, Whois/NICNAME, Finger, Netnews, RIP, and SNMP; only allow packets that are relevant to your system.
Network administrators may want to carefully consider why some common applications are supported at all. In today's environment, for example, why respond to Finger requests with full system and/or user information? Password guessing is the first type of attack that may be tried on your system and Finger helps attackers by giving them a list of valid user names; it also provides a way that an attacker can find accounts that have been inactive for some time. An increasing number of sites limit Finger by not providing a Finger daemon, filtering external Finger requests, limiting the information supplied in the response, or employing a Finger daemon that responds to all requests with a standard banner message from the network administrator.
Many experts subscribe to the theory that you should deny access to all services except the ones that you explicitly want users to have access to. CERT has issued several advisories regarding filtering suggestions for many of the well-known ports listed in Table 1; see also Cheswick & Bellovin's book and literature from your vendor. Note that some routers will automatically block anything not explicitly permitted; alternatively, you could add the following rules to prevent use of any TCP or UDP port not explicitly allowed by an earlier rule:
10 IN BLOCK TCP 10 OUT BLOCK TCP 11 IN BLOCK UDP 11 OUT BLOCK UDP
Be careful that you have permitted all of the protocols that you want before you shut the door. Be aware also that this type of blanket denial will block some legitimate uses of non-standard ports; some experimental Gopher and WWW servers, for example, use ports other than 70 and 80, respectively.
Rules 10 and 11 are also an example where rule ordering can be very important. The packet filter routine will usually process rules in order until either a rule is matched or the rule list exhausted. Consider what would happen if these last two rules were accidently inserted before, say, Rule 6. In that case, no SMTP or DNS packets would ever be allowed to enter or leave through the router.
Another type of packet filtering that should be employed blocks IP spoofing, a form of attack where an intruder replaces their own IP address with a valid IP address from another network. IP spoofing takes advantage of those applications that use authentication based upon the source IP address, possibly leading to unauthorized use of data base, commercial, and/or system resources. IP spoofing was a major part of the intrusion widely publicized in early January 1995. As an aside, the "holes" in TCP/IP that made it possible were described in papers written as much as 7 or more years ago.
Rule 12 prevents IP spoofing attacks by blocking any incoming packet if it contains a source address from the internal network (remember, we're pretending that our address is a Class C address!). The second part of the rule blocks outgoing packets that contain a source IP address that differs from the local network's address, to prevent IP spoofing attacks being launched from this network. If possible, log these events; these are bona fide attacks if they occur. (These rules are shown at the end for ease of discussion only; in fact, they should probably be the first rules defined.)
12 IN BLOCK IP from: 254.1.1.0 12 OUT BLOCK IP not-from: 254.1.1.0
Although the examples here are oriented towards filtering on the outside interface, inside filtering may also be employed for a number of reasons. One reason would be limit access to the router. Most routers have a dedicated management port where the network administrator can directly attach via a terminal. However, the network manager can also usually Telnet to the router, log on, and then perform management functions over the local network. Even if Telnet connections from the outside cannot be established because of the outside filtering rules above, none of those rules would prevent a user from Telneting to the router from the inside. It is difficult to limit internal access to the router in the configuration shown in Figure 1 because it is very hard to prevent IP address spoofing from a nefarious user on the inside. If TCP/IP software is loaded on each PC on a LAN, for example, anyone can temporarily change their IP address to that of the administrator. If you anticipate attacks from the inside, use a directly-connected terminal for router management and use the router's operating system to disable Telnet access.
------------ --------------- ------------ LAN #1 ===| Internal | | Application | | Firewall | | Router | | Gateway | | Router |=== Internet LAN #2 ===| | | | | | -----+------ -------+------- -----+------ | | | =====+=================+================+===== LAN #3
A combination of inside and outside filtering might also be used when resources on two different LANs attached to the same router are to be given different levels of protection. Alternatively, a common configuration is to place an application gateway on a LAN with two routers, where one router is connected to the WAN and the other router to the internal corporate LAN, as shown in Figure 2; the packet filtering rules on the different sides of the Internal Router and Firewall Router will certainly be different.
Packet filtering is clearly not the final word on security. While this capability exists with almost all routers today, there is still debate whether packet filtering provides sufficient protection or merely yields a false sense of security (literally and figuratively!). Application-level filters probably provide better security but are harder to build and maintain. Yet, almost any system can be broken through without continued vigilance by users; firewalls cannot, for example, protect a site from attacks in which something is legitimately mailed or transferred to an internal host and then executed (such as attacks against Sendmail).
There is much more involved in setting up a packet filtering router than described here, not to mention setting up more powerful firewalls and taking stronger security measures. Some additional information may be found on the Internet, of course! One good starting place may be accessed by pointing your WWW browser at www.greatcircle.com/firewalls or www.tis.com for a list of frequently asked questions (FAQ) and other firewall-related topics. The FAQ is particularly informative and discusses such topics as what a firewall can and cannot do; setting up proxy FTP, Telnet, Finger, and DNS servers; and problems with source routed packets. A firewall discussion list is also available on the Internet at email@example.com; subscribe to the list by sending e-mail to firstname.lastname@example.org and place the line "subscribe firewalls" in the body of the message.
Two Request for Comments (RFC) documents are directly related to these issues as well. RFC 1244 ("Site Security Handbook") is an excellent guide to the purpose and creation -- and enforcement -- of security guidelines; it also includes an extensive bibliography and list of resource materials and help centers. RFC 1281 ("Guidelines for the Secure Operation of the Internet") suggests guidelines for users, service providers, and equipment vendors.
Network administrators responsible for Internet access should be on the electronic distribution list for advisories from the Computer Emergency Response Team (CERT). CERT's charter is to act as a clearinghouse for break-ins to computer systems via the Internet or security holes reported in vendor's software; they disseminate appropriate information about such events and how to prevent or fix them. To automatically receive CERT advisories, send e-mail to email@example.com and place the word "subscribe" in the body of the message. Past CERT advisories can be obtained via anonymous FTP in the /pub/cert_advisories directory at info.cert.org. CERT may be contacted at the Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213-3890 (Telephone: +1 412 268-7090; Fax: +1 412 268-6989; E-mail: firstname.lastname@example.org).
Finally, contact your router vendor. Many have on-line WWW and/or ftp sites, as well as electronic mailing lists.
The bottom-line is: Do Not Allow Your Network To Go Unprotected. The Internet is a community comprising many millions of users and there are people who would be happy to break into your network, just as there are people who would be happy to break into your home if a door or window is left ajar. Still not convinced? Read The Cuckoo's Egg by C. Stoll and Cyberpunk by K. Hafner and J. Markoff.