- Using Firewalls to Segment Internal Resources
Perhaps the most overlooked implementation of a firewall is on the internal network.
Many companies make the mistake of considering their entire internal network to be a
trusted network. Unfortunately, the prevalence of worms and viruses today undermine
this philosophy. Companies are repeatedly decimated by worms that spread unchecked
throughout the network because there are no firewalls implemented throughout the
internal network to segment and control traffic on the internal network. In a number of
instances, firewalls should be considered on the internal network:
• To protect sensitive internal resources
• To protect from WAN or remote-access (VPN, dial-in, etc.) requests
• To protect individual internal resources
Protecting Sensitive Internal Resources
Sensitive internal resources include any servers that contain critical and sensitive data
such as human resources (HR) data, financial data, or source code. This could also
include segmenting resources based on things such as department or job function. These
servers and resources should really only be accessed by certain individuals, and in
conjunction with access controls in place on the server itself, a firewall can be used to
prevent unauthorized hosts from even being able to access the server in the first place.
For example, if the HR server only should be accessed by the HR department, and the HR
department resources are on a defined range of IP addresses, a firewall can be configured
to only allow those IP addresses to access the server over the network. An even better
implementation exists in environments where the firewall can be configured, frequently
through the use of VLANS, to place all the HR resources (both the servers and the
computers of all the HR users) on the same protected subnet. This enables you to
configure the firewall to block all traffic from external sources, while still allowing the
HR users to access any resources on the rest of the internal network. Figure 9-6 depicts
this kind of segmentation.
Figure 9-6. Using a Virtual Firewall to Protect Internal Resources
- Protecting from WAN or Remote-Access Requests
Another overlooked part of the internal network is the remote locations that exist either
across the WAN or across a VPN or dial-in connection. Because these are still corporate-
owned and-managed networks, the tendency is to treat them as trusted network segments.
Unfortunately, small office locations rarely are given the level of technical resources that
the corporate or larger office locations are. That makes those remote computers and
systems more vulnerable to attack and compromise than the systems at the well-managed
To protect against this, all traffic from remote locations should be filtered such that the
- remote systems only have access to the resources that they require. For example, think of
your network as a wheel (the central office) with a bunch of spokes (the remote offices).
The odds are in favor that most of the remote offices do not need to communicate with
each other. As a result, you should prevent them from being able to do so. This policy has
the intentional side effect of also working to prevent the spread of worms throughout
your network by ensuring that the remote offices are unable to infect each other directly.
Filtering of the WAN traffic should not be restricted only to preventing the remote offices
from communicating with each other, however. Even at the central or main offices,
firewalls should be implemented to control the resources that remote offices are allowed
to access. For example, if the remote offices only need access to e-mail, implement a
firewall to only allow access to the e-mail servers.
Protecting Individual Internal Resources
Individual internal resources can range from your important servers to every single
device on your network. On the surface, it may seem an insurmountable task to protect all
of your internal resources. However, through the use of a combination of network and in
particular host-based firewalls, it is a surprisingly doable task to implement a filtering
strategy throughout your internal network that can effectively protect any individual
resource on the entire internal network.
Be Realistic When Implementing Internal Firewalls
It is easy to become overwhelmed with implementing firewalls on the internal network
because we have a tendency to think that we need a full-blown firewall everywhere.
Unless your company is exceedingly rich, you probably will not get 100 dedicated
firewalls to filter traffic from 100 WAN connections. Keep in mind that when we are
talking about firewalls, we are talking about everything from simple packet-filtering
routers to full-blown application proxies. It is important to select the proper firewall for
the correct circumstances, and although a packet-filtering router is probably not a good
choice as your only line of defense from the Internet, it can be a great choice for use
within the internal network.
Because most of your WAN circuits and subnets have to traverse a router anyway,
implementing filtering on the router is an easy thing to do without needing to spend the
money necessary to implement a separate and distinct firewall. When you consider the
functionality provided by routers that are capable of running firewall code, such as the
Cisco IOS Firewall, it becomes easy to implement full-featured firewall filtering
throughout the network at a minimal cost.
Also keep in mind the performance implications of implementing firewalls throughout
the internal network. Most firewalls do a fine job of performance as it relates to Internet
- connections. When you start looking at implementing firewalls on internal networks,
however, keep in mind that the amount of bandwidth required for internal networks is
typically much, much higher (T1 speeds versus Gigabit Ethernet speeds) and that the
firewall needs to be able to handle these increased levels of performance or it will
become a bottleneck on your network.
Finally, perhaps the best firewall for use on an internal network is a virtual firewall
running on the corresponding switch or network device. As previously mentioned, this
allows for devices on the switch fabric, regardless of what ports they may be connected
to, to be effectively protected from other devices.