Building Internet Firewalls
`
`D. Brent Chapman and Elizabeth D. Zwicky
`
`O'Reilly & Associates, Inc.
`103 Morris Street, Suite A
`Sebastopol, CA 95472
`
`GUEST TEK EXHIBIT 1012
`Guest Tek v. Nomadix, IPR2019-01191
`
`

`

`Building Internet Firewalls
`by D. Brent Chapman and Elizabeth D. Zwicky
`
`Copyright © 1995 O'Reilly & Associates, Inc. All rights reserved.
`Printed in the United States of America.
`
`Editor: Deborah Russell
`
`Production Editor: Mary Anne Weeks Mayo
`
`Printing History:
`
`September 1995: First Edition.
`
`November 1995: Minor corrections.
`
`Nutshell Handbook and the Nutshell Handbook logo are registered trademarks of O 'Reilly &
`Associates, Inc.
`
`Many of the designations used by manufacturers and sellers to distinguish their products are
`claimed as trademarks. Where those designations appear in this book, and O 'Reilly &
`Associates, Inc. was aware of a trademark claim, the designations have been printed in caps
`or initial caps.
`
`While every precaution has been taken in the preparation of this book, the publisher assumes
`no responsibility for errors or omissions, or for damages resulting from the use of the
`information contained herein.
`
`This book is printed on acid-free paper with 85% recycled content, 15% post-consumer waste.
`O'Reilly & Associates is committed to using paper with the highest recycled content available
`consistent with high quality.
`
`ISBN: 1-56592-124-0
`
`[1/ 96]
`
`Form.
`Pre/a
`
`I: Nt
`
`1: Wi
`
`wt
`Wh
`Ho
`Wh
`
`2: lni
`
`Ele,
`File
`Ren
`Use
`The
`0th
`Info
`Rea
`an
`1en
`Tim
`ell
`
`

`

`In Tlii$. Chapter:
`• Wh)i Packet Filtering?
`• Coi[tftgurlng a Packet
`Filf~ng Router
`• Wbid.Does a Packet
`Loo/a• Like?
`• What Does the
`Router Do with
`Patfl#ts?
`• C@tN»tionsjor
`Padlift.Fflterlng Rules
`• Ftl##ng by Address
`• Ftl~ngby Service
`• Cb~ng a Packet
`Ftltef'!ng Router
`• Where to Do Packet
`Ftltifrl71g
`• Puidn It All
`Tog(Ji~~
`
`Packet Filtering
`
`P:lcket filtering is a network security mechanism that works by controlling what
`~ta can flow to and from a network. We provide a very brief introduction to high(cid:173)
`:.:-.-el IP networking concepts (a necessity for understanding packet filtering) here,
`~t if you're not already familiar with the topic, then before continuing, you
`!ibould refer to Appendix C for a more detailed discussion.
`
`T:, transfer information across a network, the information has to be broken up into
`s:::.all pieces, each of which is sent separately. Breaking the information into
`peces allows many systems to share the network, each sending pieces in turn. In
`l!P :1etworking, those small pieces of data are called packets. All data transfer across
`JP :1etworks happens in the form of packets.
`
`T.::.e basic device that interconnects IP networks is call<=d a router. A router may be
`;a dedicated piece of hardware that has no other purpose, or it may be a piece of
`s:r.ware that runs on a general-purpose UNIX or PC (MS-DOS, Windows, Macin(cid:173)
`tDs.c-i. or other) system. Packets traversing an internetwork (a network of networks)
`11:i',-el from router to router until they reach their destination. The Internet itself is
`•s:tc of the granddaddy of internetworks-the ultimate "network of networks."
`
`A :-outer has to make a routing decision about each packet it receives; it has to
`*.:;de how to send that packet on towards its ultimate destination. In general, a
`_, -et carries no information to help the router in this decision, other than the IP
`
`131
`
`

`

`~ - -
`
`132
`
`Chapter 6: Packet Filtering
`
`address of the packet's ultimate destination. The packet tells the router where it
`wants to go, but not how to get there. Routers communicate with each other using
`"routing protocols" such as the Routing Information Protocol (RIP) and Open
`Shortest Path First ( OSPF) to build routing tables in memory to determine how to
`get the packets to their destinations. When routing a packet, a router compares the
`packet's destination address to entries in the routing table and sends the packet
`onward as directed by the routing table. Often, there won't be a specific route for
`a particular destination, and the router will use a "default route;" generally, such a
`route directs the packet towards smarter or better-connected routers. (The default
`routes at most sites point towards the Internet.)
`
`In determining how to forward a packet towards its destination, a normal router
`looks only at a normal packet's destination address and asks only "How can I for(cid:173)
`ward this packet?" A packet filtering router also considers the question "Should I
`forward this packet?" The packet filtering router answers that question according
`to the security policy programmed into the router via the packet filtering rules.
`
`NOTE
`
`Some unusual packets do contain routing information about how they
`are to reach their destination, using the "source route" IP option. These
`packets, called source-routed packets, are discussed in the section called
`"IP Options" below.
`
`The address the data is (supposedly) coming from
`
`The address the data is going to
`
`l_
`
`(-Why Packet Filtering?
`/
`- Packet filtering lets you control (allow or disallow) data transfer based on:
`•
`•
`•
`Most packet filtering systems don't do anything based on the data itself; they dool: '
`make content-based decisions.* Packet filtering will let you say:
`
`The session and application protocols being used to transfer the data
`
`Don't let anybody use Telnet (an application protocol) to log in from the outside.
`
`or:
`
`Let everybody send us email via SMTP (another application protocol).
`
`or even:
`
`That machine can send us news via NNTP (yet another application protocol), but
`no other machines can do so.
`
`* Some packages, like CheckPoint's FireWall-1 product, are limited exceptions to this rule
`
`

`

`Why Packet Filtering?
`
`However, it won't let you say:
`
`133
`
`This user can Telnet in from outside, but no other users can do so.
`
`because "user" isn't something a packet filtering system can identify. And, it won't
`let you say:
`
`You can transfer these files but not those files.
`
`because "file" also isn't something the packet filtering system can identify.
`
`The main advantage of packet filtering is leverage: it allows you to provide, in a
`single place, particular protections for an entire network. Consider the Telnet ser(cid:173)
`vice as an example. If you disallow Telnet by turning off the Telnet server on all
`your hosts, you still have to worry about someone in your organization installing a
`new machine (or reinstalling an old one) with the Telnet server turned on. On the
`other hand, if Telnet is not allowed by your filtering router, such a new machine
`would be protected right from the start, regardless of whether or not its Telnet
`server was actually running. This is an example of the kind of "fail safe" stance we
`discussed in Chapter 3.
`
`Routers also present a useful choke point (also discussed in Chapter 3) for all of
`the traffic entering or leaving a network. Even if you have multiple routers for
`redundancy, you probably have far fewer routers, under much tighter control, than
`you have host machines.
`
`Certain protections can be provided only by filtering routers, and then only if they
`are deployed in particular locations in your network. For example, it's a good idea
`to reject all packets that have internal source addresses-that is, packets that claim
`to be coming from internal machines but that are actually coming in from the
`outside-because such packets are usually part of address-spoofing attacks. In
`such attacks, an attacker is pretending to be coming from an internal machine.
`Decision-making of this kind can be done only in a filtering router at the perime(cid:173)
`ter of your network. Only a filtering router in that location (which is, by definition,
`the boundary between "inside" and "outside") is able to recognize such a packet,
`by looking at the source address and whether the packet came from the inside
`(the internal network connection) or the outside (the external network connec(cid:173)
`tion). Figure 6-1 illustrates this type of source address forgery.
`
`Advantages of Packet Filtering
`Packet filtering has a number of advantages.
`
`One screening router can help protect an entire network
`
`One of the key advantages of packet filtering is that a single, strategically placed
`packet filtering router can help protect an entire network. If there is only one
`
`

`

`134
`
`Chapter 6: Packet Filtering
`
`10.2.3.1
`
`10.2.3.2
`
`Figure 6-1: Source address forgery
`
`router that connects your site to the Internet, you gain tremendous leverage on
`network security, regardless of the size of your site, by doing packet filtering on
`that router.
`
`Packet filtering doesn't require user knowledge or cooperation
`
`Unlike proxying, described in Chapter 7, packet filtering doesn't require any cus(cid:173)
`tom software or configuration of client machines, nor does it require any special
`training or procedures for users. When a packet filtering router decides to let a
`packet through, the router is indistinguishable from a normal router. Ideally, users
`won't even realize it's there, unless they try to do something that is prohibited
`(presumably because it is a security problem) by the packet filtering router's filter(cid:173)
`ing policy.
`
`This "transparency" means that packet filtering can be done without the coopera(cid:173)
`tion, and often without the knowledge, of users. The point is not that you can do
`this subversively, behind your users' backs (while actions like that are sometimes
`necessary-it all depends on the circumstances-they can be highly political).
`The point is that you can do packet filtering without their having to learn anything
`new to make it work, and without your having to depend on them to do (or not
`do) anything to make it work.
`
`Pad
`procl
`alrel
`
`Most
`and,
`are~
`sc,a
`Appc
`
`Ill
`p
`in
`to
`CII
`ql1
`ca
`yo
`
`Dis.
`AJdoJ
`IDusil
`
`a,,,.
`
`Despil
`miwa
`
`apalJii --· - 111 .. ..
`• .. .. 111111
`
`• OIi
`
`

`

`W1.ry Packet Filtering?
`
`135
`
`Packet filtering is widely available in many routers
`
`Packet filtering capabilities are available in many hardware and software routing
`products, both commercial and freely available over the Internet. Most sites
`already have packet filtering capabilities available in the routers they use.
`
`Most commercial router products, such as the routers from Livingston Enterprises
`and Cisco Systems, include packet filtering capabilities. Packet filtering capabilities
`are also available in a number of packages, such as Drawbridge, KarlBridge, and
`screend, that are freely distributed on the Internet; these are discussed in
`Appendix B.
`
`NOTE
`
`In this book, it's impossible to give a complete list of commercial and
`publicly available packages, because new products are constantly being
`introduced and packet filtering capabilities are constantly being added
`to existing products. Instead, in this chapter we concentrate on dis(cid:173)
`cussing generic packet filtering features and capabilities, and the conse(cid:173)
`quences of having-or not having-particular capabilities, so that you
`can make your own evaluation of the products currently available to
`you.
`
`Disadvantages of Packet Filtering
`Although packet filtering provides many advantages, there are some disadvantages
`to using packet filtering as well:
`
`Current filtering tools are not perfect
`
`Despite the widespread availability of packet filtering in various hardware and
`software packages, packet filtering is still not a perfect tool. The packet filtering
`capabilities of many of these products share, to a greater or lesser degree, com(cid:173)
`mon limitations:
`
`• The packet filtering rules tend to be hard to configure. Although there is a
`range of difficulty,
`it mostly runs from slightly mind-twisting to brain(cid:173)
`numbingly impossible.
`
`• Once configured, the packet filtering rules tend to be hard to test.
`
`• The packet filtering capabilities of many of the products are incomplete, mak(cid:173)
`ing implementation of certain types of highly desirable filters difficult or
`impossible.
`
`

`

`136
`
`Chapter 6: Packet Filtering
`
`• Like anything else, packet filtering packages may have bugs in them; these
`bugs are more likely than proxying bugs to result in security problems. Usu(cid:173)
`ally, a proxy that fails simply stops passing data, while a failed packet filtering
`implementation may allow packets it should have denied.
`
`Some protocols are not well suited to packet filtering
`
`Even with perfect packet filtering implementations, you will find that some proto(cid:173)
`cols just aren't well suited to security via packet filtering, for reasons we'll discuss
`later in this book. Such protocols include the Berkeley "r" commands (rep, rlogin,
`rdist, rsb, etc.) and RPC-based protocols such as NFS and NIS/YP. (The problems of
`using packet filtering to deal with these protocols are discussed in Chapter 8.)
`
`Some policies can't readily be enforced by normal packet filtering routers
`
`The information that a packet filtering router has available to it doesn't allow you
`to specify some rules you might like to have. For example, packets say what host
`they come from, but generally not what user. Therefore, you can't enforce restric(cid:173)
`tions on particular users. Similarly, packets say what port they're going to, but not
`what application; when you enforce restrictions on higher-level protocols, you do
`it by port number, hoping that nothing else is running on the port assigned to that
`protocol. Malicious insiders can easily subvert this kind of control.
`
`Configuring a Packet Filtering Router
`To configure a packet filtering router, you first need to decide what services you
`want to allow or deny, and then you need to translate your decisions into rules
`about packets. In reality, you probably don't care about the details of packets at
`all. What you want is to get your work done. For example, you want to receive
`mail from the Internet, and whether that's managed by packets or by Murphy's
`ghost is irrelevant to you. The router, on the other hand, cares only about packets,
`and only about very limited parts of them. In constructing the rules for your
`routers, you have to translate the general statement "Receive mail from the Inter(cid:173)
`net" into a description of the particular kinds of packets you want the router to
`allow to pass.
`
`The following sections outline the general concepts you need to keep in mind
`when translating decisions about services into rules about packets. The specific
`details for each service are described in Chapter 8.
`
`Protocols Are Usually Bidirectional
`Protocols are usually bidirectional; they almost always involve one side sending an
`inquiry or a command, and the other side sending a response of some kind. When
`
`Conjigu
`
`you're
`both w
`that ca1
`packe~
`
`'conver.
`attacks
`the atta
`maybe
`sation,
`dictable
`informa
`somethi
`your lei
`selves a
`
`Be Ca
`When j
`your cw
`guish b
`vices. A:
`both OU
`be displ
`services,
`with pac:
`cate de
`inbound
`
`De/au
`In Cbapl
`together
`per mittd
`prohibirf
`attitude I
`reftect th
`thing 3DI
`stand tt.
`enough 4
`puposes
`1he def.a
`SlaDCe.,.
`
`

`

`Configuring a Packet Filtering Router
`
`137
`
`you're planning your packet filtering rules, you need to remember that packets go
`both ways. For example, it doesn't do any good to allow outbound Telnet packets
`that carry your keystrokes to a remote host, if you don't also allow the incoming
`packets for that connection that carry the screen display back to you.
`
`· Conversely, it also won't do you any good to block only half a connection. Many
`attacks can be carried out if attackers can get packets into your network, even if
`the attackers can't get any responses back. This is possible because the responses
`may be predictable enough to allow attackers to carry on their side of the conver(cid:173)
`sation without having to actually see the responses at all. If the responses are pre(cid:173)
`dictable, an attacker doesn't need to see them. They won't be able to extract any
`information directly if they don't see the responses, but they may be able to do
`something that gives them the data indirectly. For example, even if they can't see
`your /etc/passwd file directly, they can probably issue a command to mail them(cid:173)
`selves a copy.
`
`Be Careful of 'Inbound' Versus 'Outbound' Semantics
`When you're planning your packet filtering strategy, you need to be careful in
`your discussions of "inbound" versus "outbound." You need to carefully distin(cid:173)
`guish between inbound and outbound packets, and inbound and qutbound ser(cid:173)
`vices. An outbound service (e.g., the Telnet service mentioned above) involves
`both outbound packets (your keystrokes) and inbound packets (the responses to
`be displayed on your screen). Although most people habitually think in terms of
`services, you need to make sure you think in terms of packets when you're dealing
`with packet filtering. When you talk to others about filtering, be sure to communi(cid:173)
`cate clearly whether you're talking about inbound versus outbound packets, or
`inbound versus outbound services.
`
`Default Permit Versus Default Deny
`In Chapter 3, we distingushed between the two stances you can choose in putting
`together your security policy: the default deny stance (that which is not expressly
`permitted is prohibited) and the default permit stance (that which is not explicitly
`prohibite.d is permitted). From a security point of view, it is far safer to take the
`attitude that things should be denied by default. Your packet filtering rules should
`reflect this stance. As we discussed earlier, start from a position of denying every(cid:173)
`thing and then set rules that allow only protocols that you need, that you under(cid:173)
`stand the security implications of, and that you feel that you can provide safely
`enough (according to your own particular definition of "safely enough") for your
`purposes
`
`The default deny stance is much safer and more effective than the default permit
`stance, which involves permitting everything by default and trying to block those
`
`-
`
`

`

`138
`
`Chapter 6: Packet Filtering
`
`things that you know are problems. The reality is that with such an approach,
`you'll never know about all the problems, and thus you'll never be able to do a
`complete job.
`
`In practical terms, the default deny stance means that your filtering rules should be
`a small list of specific things that you allow, perhaps with a few very specific'
`things you deny scattered throughout to make the logic come out right, followed
`by a default deny that covers everything else. We'll explain in detail how these
`rules work later in this chapter.
`
`What Does a Packet Look Like?
`To understand packet filtering, you first have to understand packets and how they
`are handled at each layer of the TCP /IP protocol stack:
`
`• Application layer (e.g., FTP, Telnet, HTTP)
`
`• Transport layer (TCP or UDP)
`
`•
`
`Internet layer (IP)
`
`• Network access layer (e.g., Ethernet, FDDI, ATM)
`
`Packets are constructed in such a way that layers for each protocol used for a par(cid:173)
`ticular connection are wrapped around the packets, like the layers of skin on an
`onion.
`
`At each layer, a packet has two parts: the header and the body. The header con(cid:173)
`tains protocol information relevant to that layer, while the body contains the data
`for that layer which often consists of a whole packet from the next layer in the
`stack. Each layer treats the information it gets from the layer above it as data, and
`applies its own header to this data. At each layer, the packet contains all of the
`information passed from the higher layer; nothing is lost. This process of preserv(cid:173)
`ing the data while attaching a new header is known as encapsulation.
`
`At the application layer, the packet consists simply of the data to be transferred
`(for example, part of a file being transferred during an FTP session). As it moves to
`the transport layer, the Transmission Control Protocol (TCP) or the User Datagram
`Protocol (UDP) preserves the data from the previous layer and attaches a header to
`it. At the next layer, IP considers the entire packet (consisting now of the TCP or
`UDP header and the data) to be data, and now attaches its own IP header. Finally,
`at the network access layer, Ethernet or another network protocol considers the
`entire IP packet passed to it to be data, and attaches its own header. Figure 6-2
`shows how this works.
`
`At the other side of the connection, this process is reversed. As the data is passed
`up from one layer to the next higher layer, each header (each skin of the onion) is
`stripped off by its respective layer. For example, the Internet layer removes the IP
`header before passing the encapsulated data up to the transport layer (TCP or
`UDP).
`
`Figu,
`
`In ti:
`point
`seve1
`the l:
`kno~
`issue
`Appe
`
`In th
`over
`then
`(such
`
`TC~
`Let's I
`Telnei
`here:
`tion,,
`ers th:
`
`

`

`Wbat Does a Packet Look Like?
`
`139
`
`Application Layer
`(SMTP, Telnet, FTP, etc.)
`
`Transport Layer
`(TCP, UDP, ICMP)
`
`Internet Layer
`(IP)
`
`Networt Access Layer
`(Ethernet, FDDI, ATM, etc.)
`
`Figure 6-2: Data encapsulation
`
`In trying to understand packet filtering, the most important information from our
`point of view is in the headers of the various layers. The sections below look at
`several examples of different types of packets and show the contents of each of
`the headers that packet filtering routers will be examining. We assume a certain
`knowledge of TCP/IP fundamentals, and concentrate on discussing the particular
`issues related to packet filtering. For a detailed introduction to TCP/IP, see
`Appendix C.
`
`In the discussion below, we start with a simple example demonstrating TCP/IP
`over Ethernet. From there, we go on to discuss IP's packet filtering characteristics,
`then protocols above IP (such as TCP, UDP, ICMP, and RPC), protocols below IP
`(such as Ethernet), and finally non-IP protocols (such as AppleTalk or IPX).
`
`TCP/IP/Ethernet Example
`Let's consider an example of a TCP/IP packet (for example, one that is part of a
`Telnet connection) on an Ethernet. There are four layers that we're interested in
`here: the Ethernet layer, the IP layer, the TCP layer, and the data layer. In this sec(cid:173)
`tion, we'll consider them from bottom to top and look at the contents of the head(cid:173)
`ers that the packet filtering routers will be examining.
`
`

`

`140
`
`Ethernet layer
`
`Chapter 6: Packet Filtering
`
`At the Ethernet layer, the packet consists of two parts: the Ethernet header and the
`Ethernet body. In general, you won't be able to do packet filtering based on infor(cid:173)
`mation in the Ethernet header. Basically, the header tells you:
`
`• What kind of packet this is-we'll assume in this example that it is an IP
`packet, as opposed to an AppleTalk packet, a Novell packet, a DECNET
`packet, or some other kind of packet.
`
`•
`
`•
`
`Tbe Ethernet address of the machine that put the packet onto this particular
`Ethernet network segment-the original source machine, if it's attached to this
`segment; otherwise, the last router in the path from the source machine to
`here.
`
`Tbe Ethernet address of the packet's destination on this particular Ethernet net(cid:173)
`work segment-perhaps the destination machine, if it's attached to this seg(cid:173)
`ment; otherwise, the next router in the path from here to the destination
`machine.
`
`Because we are considering IP packets in this example, we know that the Ethernet
`body contains an IP packet.
`
`IP layer
`
`At the IP layer, the IP packet is made up of two parts: the IP header and the IP
`body, as shown in Figure 6-3. From a packet filtering point of view, the IP header
`contains four interesting pieces of information:
`
`•
`
`•
`
`•
`
`•
`
`Tbe IP source address-four bytes long, and typically written as something like
`172.16.244.34.
`
`Tbe IP destination address-just like the IP source address.
`
`Tbe IP pt:otocol type-identifies the IP body as a TCP packet, as opposed to a
`UDP packet, an Internet Control Message Protocol (ICMP) packet, or some
`other type of packet.
`
`Tbe IP options field-which is almost always empty, but which is where
`options like the IP source route and the IP security options would be specified
`if they were used for a given packet. (See the discussion in "IP options"
`below.)
`
`IP may divide up a packet that is too large to cross a given network into a series of
`smaller packets called fragments. Fragmenting a packet doesn't change its struc(cid:173)
`ture at the IP layer (the IP headers are duplicated into each fragment), but it may
`mean that the body contains only a part of a packet at the next layer. (See the dis(cid:173)
`cussion in "IP fragmentation" below.)
`
`The IP body in this example contains an unfragmented TCP packet, although it
`could just as well contain the first fragment of a fragmented TCP packet.
`
`Figun
`
`•
`
`TCPl
`At the
`body.
`From
`piece
`1l
`pt
`• n
`• n
`The 11
`exami
`packet
`a subs
`nism tl
`a com:
`data).'
`theva
`
`The TI
`keystn:
`being 1
`
`

`

`What Does a Packet Look Like?
`
`141
`
`1:
`B
`E
`
`~
`3
`"'
`0 -
`~ 4
`
`14
`
`la
`
`I~
`
`Bits
`
`I~
`
`I~
`
`I~
`
`I~
`
`~1
`
`...
`~
`:,'.!
`::i::
`
`T
`l
`
`Figure 6-3: IP header and body
`
`TCP layer
`
`At the TCP layer, the packet again contains two parts: the TCP header and the TCP
`body. (Figure C-8 in Appendix C shows the format of the TCP header and body.)
`From a packet filtering point of view, the TCP header contains three interesting
`pieces of information:
`
`•
`
`•
`
`•
`
`1be TCP source port-a two-byte number, which specifies what client or server
`process the packet is coming from on the source machine
`
`1be TCP destination port-just like the TCP source port
`
`1be TCP flags field
`
`The TCP flags field contains one bit of interest for packet filtering: the ACK bit. By
`examining the ACK bit, a packet filtering router can determine whether a given
`packet is the first packet initiating a TCP connection (if the ACK bit is not set) or is
`a subsequent packet (if the ACK bit is set). The ACK bit is part of the TCP mecha(cid:173)
`nism that guarantees delivery of the data. The ACK bit is set whenever one side of
`a connection has received data from the other side (it acknowledges the received
`data). Therefore, the ACK bit is set on all packets going in either direction except
`the very first packet from the client to the server.
`
`The TCP body contains the actual "data" being transmitted--e.g., for Telnet the
`keystrokes or screen displays that are part of a Telnet session, or for FTP the data
`being transferred or commands being issued as part of an FTP session.
`
`

`

`142
`
`Chapter 6: Packet Filtering
`
`IP
`IP serves as a common middle ground for the Internet. It can have many different
`layers below it, such as Ethernet, token ring, FDDI, PPP, or carrier pigeon.• IP can
`have many other protocols layered on top of it, with TCP, UDP, and ICMP being by
`far the most common, at least outside of research environments. In this section,
`we discuss the special characteristics of IP relevant to packet filtering.
`
`IP options
`
`As we saw in the discussion of the IP layer above, IP headers include an options
`field, which is usually empty. In its design, the IP options field was intended as a
`place for special information or handling instructions that didn't have a specific
`field of their own in the header. However, TCP/IP's designers did such a good job
`of providing fields for everything necessary that the options field is almost always
`empty. In practice, IP options are very seldom used except for break-in attempts
`and (very rarely) for network debugging.
`
`The most common IP option a firewall would be confronted with is the IP source
`route option. Source routing lets the source of a packet specify the route the
`packet is supposed to take to its destination, rather than letting each router along
`the way use its routing tables to decide where to send the packet next. Source
`routing is supposed to override the instructions in the routing tables. In theory, the
`source routing option is useful for working around routers with broken or incor(cid:173)
`rect routing tables; if you know the route that the packet should take, but the rout(cid:173)
`ing tables are broken, you can override the bad information in the routing tables
`by specifying appropriate IP source route options on all your packets. In practice
`though, source routing is commonly used only by attackers who are attempting to
`circumvent security measures by causing packets to follow unexpected paths.
`
`Many packet filtering systems take the approach of dropping any packet that has
`any IP option set, without even trying to figure out what the option is or what it
`means; in general, this seems to work well, without causing any special problems.
`
`IP fragmentation
`
`Another IP-level consideration for packet filtering is fragmentation. One of the fea(cid:173)
`tures of IP is its ability to divide a large packet that otherwise couldn't traverse
`some network link (because of limitations on packet size along that link) into
`smaller packets, called fragments, which can traverse that link. The fragments are
`then reassembled into the full packet by the destination machine (not by the
`machine at the other end of the limited link; once a packet is fragmented, it stays
`fragmented until it reaches its destination).
`
`* See RFC1149, dated 1 April 1990, which defines the Avian Transport Protocol; RFCs dated
`1 April are usually worth reading.
`
`What
`
`IP fra
`
`Figun
`
`From
`the fu
`like T
`to allc
`fragm
`only<
`decide
`reasse
`many
`packe
`
`Thed
`if it&'
`packe
`reasse
`messai
`andw
`denial
`
`Outbo
`the WI
`mente
`
`

`

`What Does a Packet Look Like?
`
`143
`
`IP fragmentation is illustrated in Figure 6-4 .
`
`•
`•
`•
`
`Figure 6-4: Data fragmentation
`
`From a packet filtering point of view, the problem with fragmentation is that only
`the first fragment will contain the header information from higher-level protocols,
`like TCP, that the packet filtering system needs in order to decide whether or not
`to allow the full packet. The common packet filtering approach to dealing with
`fragmentation is to allow any nonfirst fragments through, and to do packet filtering
`only on the first fragment of a packet. This is safe because, if the packet filtering
`decides to drop the first fragment, the destination system will not be able to
`reassemble the rest of the fragments into the original packet, regardless of how
`many of the rest of the fragments it receives. If it can't reconstruct the original
`packet, the partially reassembled packet will not be accepted.
`
`The destination host will hold the fragments in memory for a while, waiting to see
`if it gets the mi$sing piece; this makes it possible for attackers to use fragmented
`packets in a denial of service attack. When the destination host gives up on
`reassembling the packet, it will send an ICMP "packet reassembly time expired"
`message back to the source host, which will tell an attacker that the host exists,
`and why the connection didn't succeed. There is nothing to be done about such
`denial of service attacks, but you can filter out the ICMP messages.
`
`Outbound fragments could conceivably contain data you don't want to release to
`the world. For example, an outbound NFS packet would almost certainly be frag(cid:173)
`mented, and if the file was confidential, that information would be released. If this
`
`

`

`144
`
`Chapter 6: Packet Filtering
`
`happens by accident, it's unlikely to be a problem; people do not generally hang
`around looking at the data in random packets going by just in case there's some(cid:173)
`thing interesting in them. You could wait a very long time for somebody to acci(cid:173)
`dentally send a fragment out with interesting data in it.
`
`If somebody inside intentionally uses fragmentation to transmit data, you have
`hostile users within the firewall, and no firewall can deal successfully with this
`problem. (They probably aren't very clever hostile users, though, because there
`are easier ways to get data out.)
`
`The only situation in which you need to worry about outbound fragments is the
`one in which you allow a request in but block the outbound reply. In this situa(cid:173)
`tion, nonfirst fragments of the reply will get out, and the attacker has reason to
`expect them and look for them. You can deal with this by being careful to filter
`out requests and by not relying on filtering out the replies.
`
`Protocols Above IP
`IP serves as the base for a number of different pro