|
|
John Kemp
kemp@ns.uoregon.edu
As electronic security breaches increasingly become a cause for concern, a
number of groups on the UO campus are recognizing a greater need for improved
network security. This article focuses on one of the tools that can potentially
improve network security: firewalls.
Installing a firewall requires careful consideration and planning, since a
firewall is most often placed in a critical path within a network topology.
This article discusses some of the most common questions that come up when considering
firewall deployment, and also attempts to clarify some of the implications of
introducing a firewall into a network topology.
The installation of a firewall requires a clear understanding of the networking
requirements of a group. The installation is likely to have a direct impact
on every machine behind the firewall. Since firewalls are tools used to implement
network security policy, no firewall design should ever be considered without
first clearly defining the ultimate security policy goals.
Risk assessment. The development of a security policy is driven by risk
assessment and vulnerability analysis. A group needs to ask questions such as--"What
are we trying to protect?" "Do we have anything of value on these
computers?" "What would happen if we had a break- in?" If there
is something of significant value on the network, then a risk assessment should
be carried out. After a general risk assessment is performed, a more detailed
inventory of open network services and potential vulnerabilities should follow.
It is not always the case that a firewall is the right tool for the job. If
there are only a few computers within a group, then a firewall might be more
than is required. Tightening host security is always a good idea, and in some
cases is more than sufficient. Isolating sensitive hosts off of the network
can also be a practical solution in some cases. But in general, choosing a firewall
may be appropriate when there is a valuable asset that is at risk, or there
are so many computers being used within a group that being sure of good host
security is not possible.
A general "posture" or "stance" is usually chosen for the
security policy design. This stance is used as a starting point and a conceptual
framework for guiding further development of the policy. Three of the most common
postures are discussed below: trust inside, least privilege, and selective blocking.
Trust inside. The most popular stance is known as "trust inside."
In this scenario, it is assumed that the most significant threats will come
from outside the local area network, and the emphasis of the policy will be
keeping outsiders from getting in. This type of stance is frequently implemented
by defining a firewall rule set that permits all connections which are initiated
from the inside, but blocks connections initiated from the outside. This type
of policy is easy to conceptualize and fairly easy to implement and manage.
Least privilege. Another common stance is known as "least privilege."
In this stance, it is assumed that all network connections are blocked in both
directions as a starting point, and the policy is incrementally opened to define
precisely what is allowed. This is also known as the "deny everything"
stance. Some of the individual-PC software firewalls operate in this manner,
for example "ZoneAlarm Pro" and "Sygate Personal Firewall."
These products force you to define firewall rules for each and every network
application that is used for an outgoing connection, and also force you to define
firewall rules upon receipt of new incoming connections.
Selective blocking. "Selective blocking" is another common
posture. This is also known as an "accept everything" starting point.
The policy is fine tuned by explicitly denying only selected connections which
are known to be potentially dangerous. This is clearly the most vulnerable stance
to use as a starting point. Selective blocking is often used as a first line
of defense. One example is the blocking of selected incoming ports using packet
filtering on a border router.
The type of firewall you choose will depend not only on the policy goals, but
also on the resources available to your organization and the performance requirements
of the device. Other obvious considerations are the availability of VPN software,
routing and addressing features, the ease of use of the management interface,
costs for support maintenance, availability of hardware redundancy, and so on.
Firewalls are typically categorized into a few types: packet filters, stateful
inspection firewalls, and application proxies. Stateful inspection firewalls,
which are sometimes referred to as "session-based firewalls," have
become more popular in recent years. The development of hardware redundancy
including session failover is a more recent feature. Every firewall product
may have some or all of these general firewall capabilities.
Hardware appliances, such as the Netscreen-204, Cisco PIX 515, and Sonicwall
Pro, continue to be popular because of their ease-of-use and low maintenance
requirements. Since these devices do not have hard disk drives, they tend to
have a high degree of hardware reliability. More expensive products, such as
the Netscreen 500 and Cisco PIX 535, support higher speed interfaces at higher
cost.
Do-it-yourself Unix-based firewalls running iptables, ipchains, or ipfilter,
can also perform well. But the time, energy, and expertise required to develop
a DIY solution can be significant. The only place where these devices seem to
make sense is where there is a full-time staff member who has a good feel for
the operating system being used as well as a good understanding of networking
fundamentals.
There are even cases where the existing campus router for the subnet is capable of providing sufficient packet filtering to meet the needs of a group. Since routers are usually busy performing routing tasks, this kind of setup is the exception rather than the rule. But it can be an option when the policy in question is short, clear, and not subject to change.
Firewalls are typically located at the boundary between two networks. In a
campus environment this border is often defined to be the department subnet.
At the University of Oregon, each department has at least one connection to
one of the campus routers. This connection leads to a primary backbone switch
located somewhere in the department's building. Firewalls would most often be
installed in the wiring closet of the department, with the external/unprotected
interface of the firewall connected to the campus router connection, and the
internal/protected interface as the connection to the backbone switch (see
Fig. 1 above).
Additional switches can be deployed to build up a richer environment. Switches
can be placed in front of and behind the firewall to support different functionality.
For example, some of the buildings on campus have dual router connections, and
hot-standby protocols are used to failover in case of a router malfunction.
A switch sitting in front of the firewall that is connected to both of these
campus router interfaces can be used to preserve the router link redundancy.
This technique is also useful for interfacing media types. If the firewall
supports only 10/100 interfaces and the router has a gigabit interface, a switch
that has both gigabit and 10/100 interfaces can be used in front of the firewall
to link the two devices. Switches are also often added on additional ports on
the firewall to create DMZs (see "What is a DMZ?"
below).
It should be clear that this kind of installation requires coordination. Great
care should be taken to ensure that all necessary hardware is available at the
time of installation, and that the network media types match up. Once a device
is installed, it should be tested carefully for correct operation and for performance.
Planning for the DMZ ("demilitarized zone," a perimeter network outside
the protected internal network) is a critical step that's often overlooked.
A traditional firewall designÑthe so-called "three legged firewall"Ñwill
have an external/untrusted interface, an internal/trusted interface, and a DMZ
interface (see Fig. 1 above). The need for a DMZ is clear:
a machine with public services, such as public web servers and mail server front
ends, should go out on the DMZ.
The DMZ is a "semi-protected" zone. The rule of thumb is to assume
that any machine placed on the DMZ is put at risk. The reason that this is an
acceptable tradeoff is that it is much better to have a machine hacked on the
DMZ than it is to have a machine hacked on the internal network. Great care
should be taken so that interactions with the DMZ do not also expose the internal
network.
In the absence of a DMZ, groups tend to make poor policy decisions. Without
a DMZ, a group may be tempted to offer public services from machines within
their trusted internal segment. This is a bad idea. One need look no further
than the recent Nimda/CodeRed attacks against IIS, or the recent SSH buffer
overflow vulnerabilities, to find examples of the danger of relaxing security
policies for the sake of convenience. Opening ports through the firewall to
the internal network should only be considered as a last resort.
Since the DMZ is dedicated to public access servers, the IP addressing scheme
for the DMZ is often normal IP addressing. The size of the DMZ and the number
of addresses used by the DMZ will depend on the number of servers and services
that need to be presented to the outside.
The addressing scheme chosen for the internal/trusted interface is a critical
decision that must be made well before installation begins. The traditional
approach is to use private addressing on the internal/trusted network and then
use NAT on the external interface of the firewall to translate the addresses
of active connections so that they are routable (see Glossary
below ).
Whether or not private addressing is used, the need for a DMZ implies that
more than one security zone must be defined and maintained. In these situations
the firewall acts like a router, directing traffic from one zone to the other.
It is easier to keep track of these different security zones when they fall
under well-defined subnet boundaries. These boundaries can be created by splitting
a subnet into parts using different length subnet masks, or by using wholly
different subnet addressing. In addition, decisions have to be made on where
and when public addressing or private addressing is used.
The real benefit of private addressing is that a machine that is on the internal
network, when it is not actively connecting to some outside service, will be
virtually invisible to the outside world. This characteristic is achieved as
a consequence of the nature of connection state tables on stateful-inspection
firewalls, and the fact that private addresses are not routed. This design is
one of the most robust and most common.
One common complaint about internal private addressing is that renumbering
of all of the machines on the internal network must take place at the time of
firewall installation. Renumbering can be a daunting task, so it is best to
plan ahead. Most firewalls come with a built-in DHCP server to simplify this
task.
If your network group comprises a large number of computers or has valuable
assets at risk, you may need to install a firewall to ensure security.
With careful assessment and planning, including choosing the security policy and type of firewall that best meet your needs, installing a firewall can go a long way toward easing your network security concerns.
Firewall - a device used to implement a security policy between networks.
A firewall has multiple network interfaces, and is typically used to create
a secure boundary between untrusted external networks and trusted internal networks.
The security policy defines what type of access is allowed between the connected
networks.
DMZ - demilitarized zone, a perimeter network established to house public
services, maintained outside of the internal/protected network. Since a DMZ
will be open to allow public access to services, it is considered less secure
than the internal/protected network.
Private Addresses - a specified set of IP address ranges that have been
set aside for use within internal networks. These addresses begin with the following
prefixes: 10.x.x.x, 192.168.x.x, and 172.16.x.x-172.31.x.x. Organizations use
these addresses internally but do not forward them beyond their routers. See
RFC 1597 at http://www.nic.mil/ftp/rfc/rfc1597.txt
NAT - network address translation, a method by which IP addresses are
mapped transparently from one group of addresses to another. If ports are also
mapped, this may be referred to as "port address translation." NAT
is often used to map a set of private/internal addresses to a smaller set of
public/external addresses. See RFC 1631 at http://www.nic.mil/ftp/rfc/rfc1631.txt
VPN - virtual private network, a secure network connection built on top
of an existing public network. VPNs are used to connect remote clients or remote
branch offices to local protected networks using secure encryption and authentication
technologies. (See "Virtual Private
Network Services Ready for UO Off-Campus...Users" on pp. 6-8).