Firewalls 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 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 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-known 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 |
| 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
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 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.
|
