Firewall Fundamentals

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.

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 central office.

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.