Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`FIREWALL ROUTERS AND PACKET FILTERING
`
`Gary Kessler
`February 1995
`An edited version of this paper appeared with the title
`"Build Great Firewalls" in Network VAR, June 1995.
`
`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
`
`1 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 1
`
`

`

`Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`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
` | | | |
` ----------
`
`FIGURE 1. "Inside" and "outside" filter reference points.
`
`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:
`Dir: Whether this rule is being used to filter an inbound or outbound packet, from the
`perspective of the router.
`Action: Whether this rule is being used to allow or block a particular packet type.
`Protocol: The protocol to which this rule applies (IP, TCP, UDP, or ICMP).
`Address/Port Information: An optional source and/or destination IP address (from/to) to identify
`the relevant hosts, and an optional source and/or destination port address (source/destination) to
`identify the application to which this rule applies (see Table 1). For this example, assume that
`the local network's FTP server and mail server have IP addresses 254.1.1.1 and 254.1.1.2,
`respectively; we will also pretend that this is a Class C address, so that this domain's network
`identifier is 254.1.1.0. (In most rule formats, the portion of the address to which applies may be
`specified with a subnet mask or by indicating how many bits are significant. Thus, to refer to
`only the network identifier portion of a Class C address, the rule would indicate a mask of
`255.255.255.0 or a value of 24.)
`Flags: Used here to indicate whether this rule pertains to a TCP virtual circuit that is being
`initiated with this packet or to a TCP connection that has already been established (estab). This
`can usually be determined by examining the setting of the Flags field in the TCP segment
`
`2 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 2
`
`

`

`Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`Header. In particular, the Acknowledgement (ACK) flag is used to indicate whether the
`Acknowledgement Number in this segment is valid or not; it is usually set except in the first
`segment used for connection establishment. The Reset (RST) flag is used to force an immediate
`termination of a TCP connection. For filtering purposes, a TCP connection is considered to be
`established if the ACK or RST flag is set.
`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.
`
`TABLE 1. Some well-know TCP/UDP port numbers.
`
`--------------------------------------------------------------------
`| 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 |
`
`3 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 3
`
`

`

`Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`| 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.
`
`4 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 4
`
`

`

`Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`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
`
`5 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 5
`
`

`

`Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`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
`
`FIGURE 2. A slightly more sophisticated approach: an "external" firewall router used in combination with an
`application gateway and "internal" router.
`
`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
`
`6 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 6
`
`

`

`Firewall Routers
`
`http://www.garykessler.net/library/firewall.html
`
`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 firewalls@greatcircle.com; subscribe to the list by sending e-mail to
`majordomo@greatcircle.com 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 cert-advisory-request@cert.org 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: cert@cert.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.
`
`7 of 7
`
`5/27/14 8:55 PM
`
`Google Ex. 1417, pg. 7
`
`