Network (In)Security Through IP Packet Filtering
`
`D. Brent Chapman
`
`G
`
`reat Circle Associates
`
`Brent@GreatCircle.COM
`+1 415 962 0841
`
`1057 West Dana Stree
`t
`ountain View, CA 94041
`
`M
`
`ABSTRACT
`
`Ever-increasing numbers of IP router products are offering packet filtering as a tool
`
`or improving network security. Used properly, packet filtering is a useful tool for
`he security-conscious network administrator, but
`its effective use requires a
`ehorough understanding of its capabilities and weaknesses, and of the quirks of th
`
`articular protocols that filters are being applied to. This paper examines the utility
`tf IP packet filtering as a network security measure, briefly contrasts IP packe
`
`ltering to alternative network security approaches such as application-level gate-
`ays, describes what packet filters might examine in each packet, and describes the
`haracteristics of common application protocols as they relate to packet filtering.
`he paper then identifies and examines problems common to many current packet
`ltering implementations, shows how these problems can easily undermine the net-
`-ork administrator’s intents and lead to a false sense of security, and proposes solu
`
`the paper concludes that packet filtering is
`ions to these problems. Finally,
`urrently a viable network security mechanism, but that its utility could be greatly
`mproved with the extensions proposed in the paper.
`
`cw
`
`fiT
`
`tw
`
`ic
`
`tf
`
`pt
`
`fio
`
`1. Introduction
`This paper considers packet filtering as a mechanism for implementing network security
`olicies. The consideration is from the point of view of a site or network administrator (wh
`o
`s interested in providing the best possible service to their users while maintaining adequate
`ecurity of their site or network, and who often has an "us versus them" attitude with regard to
`xternal organizations), which is not necessarily the same point of view that a service provider
`)r router vendor (who is interested in providing network services or products to customers
`
`ight have. An assumption made throughout is that a site administrator is generally more
`nterested in keeping outsiders out than in trying to police insiders, and that the goal is to keep
`utsiders from breaking in and insiders from accidentally exposing valuable data or services,
`ot to prevent insiders from intentionally and maliciously subverting security measures. This
`aper does not consider military-grade "secure IP" implementations (those that implement the
`-IP security options" that may be specified in IP packet headers) and related issues; it is lim
`
`ted to what is commonly available for sale to the general public.
`kPacket filtering may be used as a mechanism to implement a wide variety of networ
`
`ecurity policies. The primary goal of these policies is generally to prevent unauthorized
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`ublished in Proceedings of the Third USENIX UNIX Security Symposium; Baltimore, MD; September, 1992.
`
`ip
`
`es
`
`mo
`
`oi
`
`pn
`
`i"
`
`s
`
`P(cid:0)
`
`GUEST TEK EXHIBIT 1014
`Guest Tek v. Nomadix, IPR2019-01191
`
`

`

`an
`
`ag
`
`gB
`
`gi
`
`mi
`
`oh
`
`it
`
`eo
`
`rt
`
`ta
`
`hT
`
`am
`
`am
`
`sw
`
`tm
`
`detwork access without hindering authorized network access; the definitions of "unauthorize
`
`ccess" and "authorized access" vary widely from one organization to another. A secondary
`doal is often that the mechanisms be transparent in terms of performance, user awareness, an
`
`pplication awareness of the security measures. Another secondary goal is often that the
`eechanisms used be simple to configure and maintain, thus increasing the likelihood that th
`
`olicy will be correctly and completely implemented; in the words of Bill Cheswick of AT&T
`ell Laboratories, "Complex security isn’t". Packet filtering is a mechanism which can, to
`a
`reater or lesser extent, fulfill all these goals, but only through thorough understanding of its
`strengths and weaknesses and careful application of its capabilities.
`Several factors complicate implementation of these policies using packet filtering, includ-
`lng asymmetric access requirements, differing requirements for various internal and externa
`
`roups of machines, and the varying characteristics of the particular protocols, services, and
`mplementations of these protocols and services that the filters are to be applied to. Asym
`-
`etric access requirements usually arise when an organization desires that its internal systems
`ave more access to external systems than vice versa. Differing requirements arise when an
`rganization desires that some groups of machines have different network access privileges
`han other groups of machines (for instance, the organization may feel that a particular subne
`t
`s more secure than standard, and thus can safely take advantage of expanded network access,
`r they may feel that a particular subnet is especially valuable, and thus its exposure to the
`xternal network should be as limited as possible). Alternatively, an organization may desire
`eo allow more or less network access to some specific group of external machines than to th
`
`est of the external world (for instance, a company might want to extend greater network
`sccess than usual to a key client with whom they are collaborating, and less network acces
`
`han usual to a local university which is known to be the source of repeated cracker attacks).
`he characteristics of particular protocols, services, and implementations also greatly affect
`ow effective filtering can be; this particular issue is discussed in detail below, in Section 3
`and Appendix A.
`Common alternatives to packet filtering for network security include securing each
`nachine with network access and using application gateways. Allowing network access on a
`
`ll-or-nothing basis (a very coarse form of packet filtering) then attempting to secure each
`eachine that has network access is generally impractical; few sites have the resources to secur
`
`nd then monitor every machine that needs even occasional network access. Application gate-
`ays, such as those used by AT&T [Ches90], Digital Equipment Corporation [Ranum92], and
`everal other organizations, are also often impractical because they require internal hosts to run
`-odified (and often custom-written or otherwise not commonly available) versions of applica
`
`If a suitably modified ver-
`ions (such as "ftp" and "telnet") in order to reach external hosts.
`ion of an application is not available for a given internal host (a modified TELNET client fo
`r
`personal computer, for instance), that internal host’s users are simply out of luck and are
`nable to reach the past the application gateway.
`
`pm
`
`as
`
`2u
`
`. How Packet Filtering Works
`
`n2.1. What packet filters base their decisions o
`
`Current IP packet filtering implementations all operate in the same basic fashion; they
`earse the headers of a packet and then apply rules from a simple rule base to determin
`
`hether to route or drop† the packet. Generally, the header fields that are available to the filter
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`"Permit" and "deny" are used synonymously with "route" and "drop" throughout this paper. If a router decides to
`permit" or "route" a packet, it is passed through to its destination as if filtering never occurred.
`-If a router de
`
`ides to "deny" or "drop" a packet, the packet is simply discarded, as if it never existed; depending on the filter-
`
`wp
`
`†(cid:0)
`
`c"
`
`- 2 -
`
`

`

`are packet type (TCP, UDP, etc.), source IP address, destination IP address, and destination
`eCP/UDP port. For some reason, the source TCP/UDP port is often not one of the availabl
`
`elds; this is a significant deficiency discussed in detail in Section 4.2.
`sIn addition to the information contained in the headers, many filtering implementation
`
`also allow the administrator to specify rules based on which router interface the packet is des-
`
`ined to go out on, and some allow rules based on which interface the packet came in on
`.
`eing able to specify filters on both inbound and outbound† interfaces allows you significant
`ontrol over where the router appears in the filtering scheme (whether it is "inside" or "out-
`ide" your packet filtering "fence"), and is very convenient (if not essential) for useful filtering
`n routers with more than two interfaces.
`dIf certain packets can be dropped using inboun
`
`lters on a given interface, those packets don’t have to be mentioned in the outbound filters on
`nll the other interfaces; this simplifies the filtering specifications. Further, some filters that a
`
`dministrator would like to be able to implement require knowledge of which interface a
`acket came in on; for instance,
`the administrator may wish to drop all packets coming
`nbound from the external interface that claim to be from an internal host, in order to guard
`against attacks from the outside world that use faked internal source addresses.
`Some routers with very rudimentary packet filtering capabilities don’t parse the headers,
`ut instead require the administrator to specify byte ranges within the header to examine, and
`he patterns to look for in those ranges. This is almost useless, because it requires the adminis-
`rator to have a very detailed understanding of the structure of an IP packet.
`It is totally
`nworkable for packets using IP option fields within the IP header, which cause the location of
`he beginning of the higher-level TCP or UDP headers to vary; this variation makes it very
`ifficult for the administrator to find and examine the TCP or UDP port information.
`
`Bt
`
`sc
`
`fio
`
`aa
`
`ip
`
`tb
`
`ut
`
`dt
`
`fiT
`
`2.2. How packet filtering rules are specified
`Generally, the filtering rules are expressed as a table of conditions and actions that are
`-pplied in a certain order until a decision to route or drop the packet is reached. When a partic
`
`lar packet meets all the conditions specified in a given row of the table, the action specified in
`shat row (whether to route or drop the packet) is carried out; in some filtering implementation
`
`Mogul89], the action can also indicate whether or not to notify the sender that the packet has
`een dropped (through an ICMP message), and whether or not to log the packet and the action
`aken on it. Some systems apply the rules in the sequence specified by the administrator until
`hey find a rule that applies [Mogul89][Cisco90], which determines whether to drop or route
`he packet. Others enforce a particular order of rule application based on the criteria in the
`ules, such as source and destination address, regardless of the order in which the rules wer
`e
`pecified by the administrator. Some, for instance, apply filtering rules in the same order as
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`ing implementation (and sometimes on the filtering specification), the router might send an ICMP message (usual-
`y "host unreachable") back to the source of a packet that is dropped, or it might simply pretend it never received
`he packet.
`Throughout this paper, the terms "inbound" and "outbound" are usually used to refer to connections or packets
`rom the point of view of the protected network as a whole, and sometimes used to refer to packets from the
`oint of view of the filtering router (which is at the edge of the internal network, between the internal network
`nd the external world), or to the router interfaces those packets will pass through. A packet might appear to b
`e
`inbound" to the filtering router on its way to the external world, but that packet is "outbound" from the internal
`etwork as a whole. An "outbound connection" is a connection initiated from a client on an internal machine to a
`erver on an external machine; note that while the connection as a whole is outbound, it includes both outbound
`rackets (those from the internal client to the external server) and inbound packets (those from the external serve
`
`ack to the internal client). Similarly, an "inbound connection" is a connection initiated from a client on an exter-
`-al machine to a server on an internal machine. The "inbound interface" for a packet is the interface on the filter
`
`ng router that the packet appeared on, while the "outbound interface" is the interface the packet will go out on if
`it isn’t denied by the application of the filtering rules.
`
`ua
`
`[t
`
`tb
`
`tt
`
`sr
`
`†
`
`tl
`
`pf
`
`"a
`
`sn
`
`bp
`
`in
`
`- 3 -
`
`

`

`pr
`
`tt
`
`wa
`
`souting table entries; that is, they apply rules referring to more specific addresses (such as rule
`
`ertaining to specific hosts) before rules with less specific addresses (such as rules pertaining
`ho whole subnets and networks) [CHS91][Telebit92a]. The more complex the way in whic
`
`he router reorders rules, the more difficult it is for the administrator to understand the rules
`,nd their application; routers which apply rules in the order specified by the administrator
`
`ithout reordering the rules, are easier for an administrator to understand and configure, and
`herefore more likely to yield correct and complete filter sets.
`
`2t
`
`.3. A packet filtering example
`For example, consider this scenario. The network administrator of a company with Class
`network 123.45 wishes to disallow access from the Internet
`lto his network in genera
`
`123.45.0.0/16)†. The administrator has a special subnet in his network (123.45.6.0/24) that is
`sed in a collaborative project with a local university which has class B network 135.79; he
`ishes to permit access to the special subnet (123.45.6.0/24) from all subnets of the university
`e135.79.0.0/16). Finally, he wishes to deny access (except to the subnet that is open to th
`
`hole university) from a specific subnet (135.79.99.0/24) at the university, because the subnet
`s known to be insecure and a haven for crackers. For simplicity, we will consider only pack-
`ts flowing from the university to the corporation; symmetric rules (reversing the SrcAddr and
`-stAddr in each of the rules below) would need to be added to deal with packets from the cor
`
`oration to the university. Rule C is the "default" rule, which specifies what happens if none
`of the other rules apply.
`
`(B
`
`wu
`
`w(
`
`ei
`
`pD
`
`Rule
`A
`B
`C
`
`SrcAddr
`135.79.0.0/16
`135.79.99.0/24
`0.0.0.0/0
`
`DstAddr
`123.45.6.0/24
`123.45.0.0/16
`0.0.0.0/0
`
`Action
`tpermi
`
`deny
`yden
`
`
`Consider these "sample" packets, their desired treatment under the policy outlined above,
`
`nd their treatment depending on whether the rules above are applied in order "ABC" or
`BAC".
`
`"a
`
`SrcAddr
`135.79.99.1
`135.79.99.1
`135.79.1.1
`135.79.1.1
`
`DstAddr
`123.45.1.1
`123.45.6.1
`123.45.6.1
`123.45.1.1
`
`Desired Action
`deny
`permit
`permit
`deny
`
`ABC action
`deny (B)
`permit (A)
`permit (A)
`deny (C)
`
`BAC action
`deny (B)
`deny (B)
`permit (A
`deny (C)
`
`)
`
`Packet
`
`21
`
`43
`
`sA router that applies the rules in the order ABC will achieve the desired results: packet
`
`rom the "hacker haven" subnet at the university to the company network in general (such as
`acket 1 above) will be denied (by rule B), packets from the university "hacker haven" subne
`t
`the university to the company’s collaboration subnet (such as packet 2 above) will be
`t
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`Throughout this paper, the syntax "a.b.c.d/y" denotes "the address a.b.c.d, with the top y bits significant for com-
`-arison". In other words, 123.45.0.0/16 means that the top 16 bits (123.45) are significant for comparisons to oth
`
`r addresses. The address 123.45.6.7 thus matches 123.0.0.0/8, 123.45.0.0/16, and 123.45.6/24, but not
`23.45.99.0/24. A pattern with 0 significant bits (such as 0.0.0.0/0) matches any address, while a pattern with 32
`ignificant bits (such as 123.45.6.7/32) matches only that particular address (123.45.6.7). This syntax is a simpler
`orm of expressing an address pattern than the traditional "address, wildcard mask" tuple, particularly when the
`oundary between the wildcarded and non-wildcarded bits doesn’t fall on an 8-bit boundary (for instance, on a
`eisco router, the pattern 123.0.0.0/8 would be represented as "123.0.0.0 0.255.255.255", 123.45.6.0/24 would b
`
`epresented as "123.45.6.0 0.0.0.255", and 123.45.6.240/28 would be represented as "123.45.6.240 0.0.0.15").
`his syntax was originated in the KA9Q networking package for PCs, and is used in the Telebit NetBlazer and
`ther products.
`
`ep
`
`s1
`
`bf
`
`rC
`
`oT
`
`f
`
`ap
`
`†(cid:0)
`
`- 4 -
`
`

`

`sp
`
`bu
`
`ts
`
`ermitted (by rule A), packets from the university’s general network to the company’s "open
`"
`ubnet (such as packet 3 above) will be permitted (by rule A), and packets from the
`lniversity’s general network to the company’s general network (such as packet 4 above) wil
`
`e denied (by rule C).
`If, however,
`the router reorders the rules by sorting them into order by number of
`ignificant bits in the source address then number of significant bits in the destination address
`,
`If the rules are applied in the order
`he same set of rules will be applied in the order BAC.
`AC, packet 2 will be denied, when we want it to be permitted.
`
`2B
`
`.4. Packet filtering caveats
`
`s2.4.1. Complexity of packet filtering specification
`
`In fact, there’s a subtle error in this example that illustrates how difficult it is to correctly
`tet up filters using such low-level specifications. Rule B above, which appears to restric
`
`ccess from the "hacker haven" net, is actually superfluous and unnecessary, and is the cause
`f the incorrect denial of packet 2 if the rules are applied in the order BAC.
`eIf you remov
`
`ule B, both types of routers (those that apply rules in the order specified, and those that
`eorder rules by number of significant bits in source or destination addresses) will process the
`ules in the order AC. When processed in that order, the result table becomes:
`
`as
`
`ro
`
`rr
`
`Desired Action
`deny
`permit
`permit
`deny
`
`AC action
`deny (C)
`permit (A
`)
`permit (A)
`deny (C)
`
`DstAddr
`123.45.1.1
`123.45.6.1
`123.45.6.1
`123.45.1.1
`
`SrcAddr
`135.79.99.1
`135.79.99.1
`135.79.1.1
`135.79.1.1
`
`Packet
`1
`
`32
`
`4
`
`There are two points here. First, correctly specifying filters is difficult. Second, reordering
`
`tltering rules makes correctly specifying filters even more difficult, by turning a filter set tha
`
`orks (even if it’s in fact overspecified) if evaluated in the order given into a filter set that
`doesn’t work.
`Even though the example presented above is a relatively simple application of packet
`ltering, most administrators will probably read through it several times before they feel they
`nderstand what is going on. Consider that the more difficult the rules are to comprehend, the
`ess likely the rules will be correct and complete. The way in which filtering rules must b
`e
`pecified and the order in which they are applied are key determinants of how useful and
`-owerful a given router’s filtering capabilities are. Most implementations require the adminis
`
`rator to specify filters in ways which make the filters easy for the router to parse and apply,
`ut make them very difficult for the administrator to comprehend and consider.
`
`wfi
`
`ufi
`
`sl
`
`tp
`
`2b
`
`.4.2. Reliance on accurate IP source addresses
`Most filtering implementations, of necessity, rely on the accuracy of IP source addresses
`o make filtering decisions. IP source addresses can easily be faked, however, as discussed in
`Bellovin89], [Kent89], [Bellovin92a], and [Bellovin92b]. This is a particular case where
`leing able to filter inbound packets is useful. If a packet that appears to be from one interna
`
`achine to another internal machine comes in over the link from the outside world, you should
`e mighty suspicious.
`nIf your router can be told to drop such packets using inbound filters o
`
`he external interface, your filtering specifications for internal interfaces can be made both
`much simpler and more secure.
`
`[t
`
`mb
`
`tb
`
`- 5 -
`
`

`

`2.4.3. Dangers of IP source routing
`Another IP feature ripe for potential abuse is IP source routing. Essentially, an IP packet
`ith source routing information included tells routers how to route the packet, rather than let-
`ing the routers decide for themselves. An attacker could use this to their advantage [Bello-
`in89]. Unless you have a specific need to allow packets with IP source routes between you
`r
`nternal network and the outside world, it’s probably a good idea for your router to ignore IP
`-ource route instructions; whether source routing can be disabled, whether it is enabled or dis
`
`bled by default, and how to disable it vary from vendor to vendor.
`
`iv
`
`as
`
`tw
`
`2.4.4. Complications due to IP fragmentation
`Yet another complication to packet filtering is IP packet fragmentation. IP supports the
`rotion that any router along a packet’s path may "fragment" that packet into several smalle
`
`ackets, to accommodate the limitations of underlying media, to be reassembled into the origi-
`tal IP packet at the destination. For instance, an FDDI frame is much larger than an Etherne
`
`rame; a router between an FDDI ring and an Ethernet may need to split an IP packet that fit
`n a single FDDI frame into multiple fragments that fit into the smaller Ethernet frames. The
`roblem with this, from a packet filtering point of view, is that only the first of the IP frag-
`ents has the higher-level protocol (TCP or UDP) headers from the original packet, which
`ay be necessary to make a filtering decision concerning the fragment. Different filtering
`emplementations take a variety of responses to this situation. Some apply filters only to th
`
`rst fragment (which contains the necessary higher-level protocol headers), and simply route
`ehe rest, on the assumption that if the first fragment is dropped by the filters, the rest of th
`
`ragments can’t be reassembled into a full packet, and will cause no harm [CHS91]. Others
`eep a cache of recently-seen first fragments and the filtering decision that was reached, and
`ook up non-first fragments in this cache in order to apply the same decision [Mogul89].
`In
`tarticular, it is dangerous to suppress only the first fragment of outbound packets; you migh
`
`e leaking valuable data in the non-first fragments that are routed on out.
`
`mm
`
`fii
`
`ft
`
`lk
`
`bp
`
`pn
`
`fn
`
`pi
`
`3. Filtering-Related Characteristics of Application Protocols
`Each application protocol has its own particular characteristics that relate to IP packet
`ltering, that may or may not differ from other protocols. Particular implementations of a
`iven protocol also have their own characteristics that are not a result of the protocol per se,
`ut a result of design decisions made by the implementors. Since these implementation charac-
`eristics are not covered in the specification of the protocol (though they aren’t counter to the
`,pecification), they are likely to vary between different implementations of the same protocol
`
`nd might change even within a given implementation as that implementation evolves. These
`sharacteristics include what port a server uses, what port a client uses, whether the service i
`
`ypically offered over UDP or TCP or both, and so forth. An understanding of these charac-
`eristics is essential for setting up effective filters to allow, disallow, or limit the use of these
`rotocols. Appendix A discusses in detail the filtering-related characteristics of several com-
`on protocols.
`
`gfi
`
`tb
`
`as
`
`tc
`
`pt
`
`.1. "Random" ports aren’t really random
`Although implementations of various protocols might appear to use a "random" ports for
`he client end and a well-known port for the server end, the ports chosen for the client end
`sed are usually not totally random. While not explicitly supported by the RFCs, systems based
`n BSD UNIX usually reserve ports below 1024 for use by "privileged" processes, and allow
`nly processes running as root to bind to those ports; conversely, non-privileged processes
`smust use ports at or above 1024. Further, if a program doesn’t request a particular port, it i
`
`
`ut
`
`oo
`
`3m
`
`- 6 -
`
`

`

`
`
`,ften simply assigned the port after the last one assigned; if the last port assigned was 5150
`he next one assigned will probably be 5151.
`
`to
`
`3.2. Privileged versus non-privileged port
`s
`The distinction between "privileged" and "non-privileged" ports (those below 1024 and at
`tr above 1024, respectively) is found throughout BSD-based systems (and other systems tha
`
`raw from a BSD background; keep in mind that almost all UNIX IP networking, including
`-ysV IP networking, draws heavily from the original BSD network implementation). This dis
`
`inction is not codified in the RFCs, and is therefore best regarded as a widely used conven-
`ion, but not as a standard. Nonetheless, if you’re protecting UNIX systems, the convention
`an be a useful one. You can, for instance, generally forbid all inbound connections to ports
`elow 1024, and then open up specific exceptions for specific services that you wish to enable
`he outside world to use, such as SMTP, TELNET, or FTP; to allow the "return" packets for
`onnections to such services, you allow all packets to external destination ports at or above
`024.
`
`do
`
`tS
`
`ct
`
`tb
`
`1c
`
`While it would simplify filtering if all services were offered on ports below 1024 and all
`lients used ports at or above 1024, many vulnerable services (such as X, OpenWindows, and
`number of database servers) use server ports at or above 1024, and several vulnerable clients
`such as the Berkeley r* programs) use client ports below 1024. These should be carefully
`xcepted from the "allow all packets to destination ports at or above 1024" type of rules that
`llow return packets for outbound services.
`
`ac
`
`e(
`
`4a
`
`Ui
`
`s"
`
`. Problems With Current Packet Filtering Implementations
`nIP packet filtering, while a useful network security tool, is not a panacea, particularly i
`
`
`the form in which it is currently implemented by many vendors. Problems with many current
`mplementations include complexity of configuration and administration, omission of the source
`DP/TCP port from the fields that filtering can be based on, unexpected interactions between
`eunrelated" parts of the filter rule set, cumbersome filter specifications forced by simpl
`
`pecification mechanisms, a lack of testing and debugging tools, and an inability to deal
`ffectively with RPC-based protocols such as YP/NIS and NFS.
`
`4e
`
`.1. Filters are difficult to configure
`The first problem with many current IP packet filtering implementations as network secu-
`ity mechanisms is that the filtering is usually very difficult to configure, modify, maintain, and
`est, leaving the administrator with little confidence that the filters are correctly and completely
`epecified. The simple syntax used in many filtering implementations makes life easy for th
`
`outer (it’s easy for the router to parse the filter specifications, and fast for the router to apply
`hem), but difficult for the administrator (it’s like programming in assembly language).
`dInstea
`
`f being able to use high-level language abstractions ("if this and that and not something-else
`;hen permit else deny"), the administrator is forced to produce a tabular representation of rules
`
`he desired behavior may or may not map well on to such a representation.
`tAdministrators often consider networking activity in terms of "connections", while packe
`
`ltering, by definition, is concerned with the packets making up a connection. An administrator
`tight think in terms of "an inbound SMTP connection", but this must be translated into a
`
`east two filtering rules (one for the inbound packets from the client to the server, and one for
`-he outbound packets from the server back to the client) in a table-driven filtering implementa
`
`ion. The concept of a connection is applied even when considering a connectionless protocol
`uch as UDP or ICMP; for instance, administrators speak of "NFS connections" and "DNS
`onnections". This mismatch between the abstractions used by many administrators and the
`
`tr
`
`rs
`
`ot
`
`tt
`
`fi
`
`lm
`
`tt
`
`cs
`
`- 7 -
`
`

`

`mechanisms provided by many filtering implementations contributes to the difficulty of
`orrectly and completely specifying packet filters.
`
`.2. TCP and UDP source port are often omitted from filtering criteria
`Another problem is that current filtering implementations often omit the source UDP/TC
`P
`ort from consideration in filtering rules, leading to common cases where it is impossible to
`p
`rllow both inbound and outbound traffic to a service without opening up gaping holes to othe
`
`ervices. For instance, without being able to consider both the source and destination port
`umbers of a given packet, you can’t allow inbound SMTP connections to internal machines
`for inbound email) and outbound SMTP connections to all external machines (so that you can
`lend outbound mail) without ending up allowing all connections between internal and externa
`
`achines where both ends of the connection are on ports at or above port 1024. To see this,
`magine your router’s rule table has 6 variables for rules on a given interface: direction
`whether the packet is inbound to or outbound from internal network), packet type (UDP or
`CP), source address, destination address, destination port, and action (whether to drop o
`r
`oute the packet). You would need 5 rules in such a table to allow both inbound SMTP
`where an external host connects to an internal host to send email) and outbound SMTP (wher
`e
`n internal host connects to any external host to send mail). The rules would look something
`like this:
`
`sa
`
`(n
`
`ms
`
`(i
`
`rT
`
`a(
`
`4c
`
`DstPort
`25
`>=1024
`25
`>=1024
`any
`
`Action
`tpermi
`
`permit
`tpermi
`
`permit
`deny
`
`DstAddr
`internal
`external
`external
`internal
`any
`
`Direction
`in
`out
`out
`in
`either
`
`Type
`TCP
`TCP
`TCP
`TCP
`any
`
`SrcAddr
`external
`internal
`internal
`external
`any
`
`Rule
`A
`B
`
`DC
`
`E
`
`
`
`
`
`The default action (rule E), if none of the preceding rules apply, is to drop the packet.
`,Rules A and B, together, allow the "inbound" SMTP connections; for inbound packets
`
`the source address is an "external" address, the destination address is "internal", and the desti-
`ation port is 25, while for outbound packets, the source address is "internal", the destination
`ddress is "external", and the destination port is at or above 1024. Rules C and D, together,
`imilarly allow the "outgoing" SMTP connections. Consider, however, a TCP connection
`etween an internal host and an external host where both ports used in the connection are
`bove 1023.
`Incoming packets for such a connection will be passed by rule D. Outgoing
`ackets for such a connection will be passed by rule B. The problem is that, while rules A
`dnd B together do what you want and rules C and D together do what you want, rules B an
`
`together allow all connections between internal and external hosts where both ends of the
`onnection are on a port number above 1024. Current filter specification syntaxes are ripe with
`pportunities for such unexpected and undesired interactions.
`eIf source port could be examined in making the routing decisions, the rule table abov
`ould become:
`
`
`
`SrcPort
`>=1024
`25
`>=1024
`25
`any
`
`DstPort
`25
`>=1024
`25
`>=1024
`any
`
`Action