For your enterprise firewall implementation strategy, you will need to know firewall/VPN placement in the network, how many you will need, and how to manage and maintain your perimeter security after you've successfully rolled out your solution. Jump to other sections of this Firewall Guide to learn more.
Introduction to firewalls
Types of firewalls
Choosing a firewall
Firewall implementation and placement
→ Placement of a firewall
→ Are two firewalls better than one?
→ Firewall implementation precautions
Firewall management and maintenance
PLACEMENT OF A FIREWALL
When developing a perimeter protection strategy for an organization, one of the most common questions is "Where should I place firewalls for maximum effectiveness?" Security expert Mike Chapple breaks up firewall placement into three basic topology options: bastion host, screened subnet and dual firewalls.
The first, bastion host topology, is the most basic option, and is well suited for relatively simple networks. This topology would work well if you're merely using the firewall to protect a corporate network that is used mainly for surfing the Internet, but it is probably not sufficient if you host a website or email server.
The screened subnet option provides a solution that allows organizations to offer services securely to Internet users. Any servers that host public services are placed in the demilitarized zone (DMZ), which is separated from both the Internet and the trusted network by the firewall. Therefore, if a malicious user does manage to compromise the firewall, he or she does not have access to the Intranet (providing that the firewall is properly configured).
The most secure (and most expensive) option is to implement a screened subnet using two firewalls. The use of two firewalls still allows the organization to offer services to Internet users through the use of a DMZ, but provides an added layer of protection.
To read a more in-depth description of these options view the rest of Chapple's tip on firewall placement.
ARE TWO FIREWALLS BETTER THAN ONE?
Generally speaking, there isn't much work to do in these areas; it's about maintaining these controls and adapting them as dynamic infrastructures change. The maturity of the technology offers the opportunity to focus limited financial and human resources on more challenging problems, such as endpoint/server management and application security.
SearchSecurity expert Mike Chapple says that two firewalls from different vendors may not cause processing delays, but if not used and arranged correctly, the devices can become a hassle for IT teams. If you're experiencing network latency by adding an additional firewall, consider the placement of the firewalls. Are they both directly connected to each other with nothing else in between? If that's the case, consider using a different firewall topology that will get the most out of the two firewalls.
Read the rest of this Q&A about how to get the most out of two separate firewalls on SearchSecurity.com.
FIREWALL IMPLEMENTATION PRECAUTIONS
Many people think that as long as their SAN or NAS is behind a firewall then everything is protected. This is a myth of network security. Most storage environments span across multiple networks, both private and public.
Storage devices are serving up multiple network segments and creating a virtual bridge that basically negates any sort of firewall put in place. This can provide a conduit into the storage environment, especially when a system is attacked and taken control of in the DMZ or public segment. The storage back end can then be fully accessible to the attacker because there is a path for the attack.
FIREWALL MANAGEMENT AND MAINTENANCE
We can only dream that once you've made it through the challenging phases of firewall selection and architecture design, you're finished setting up a DMZ. In the real world of firewall management, we're faced with balancing a continuous stream of change requests and vendor patches against the operational management of our firewalls. Configurations change quickly and often, making it difficult to keep on top of routine maintenance tasks.
Network security expert Michael Chapple takes a look at four practical areas where some basic log analysis can provide valuable firewall management data:
- Monitor rule activity: System administrators tend to be quick on the trigger to ask for new rules, but not quite so eager to let you know when a rule is no longer necessary. Monitoring rule activity can provide some valuable insight to assist you with managing the rulebase. If a rule that was once heavily used suddenly goes quiet, you should investigate whether the rule is still needed. If it's no longer necessary, trim it from your rulebase. Legacy rules have a way of piling up and adding unnecessary complexity.
Over the years, Chapple had a chance to analyze the rulebases of many production firewalls, and estimates that at least 20% of the average firewall's rulebase is unnecessary. There are systems where this ratio is as high as 60%.
- Traffic flows: Monitor logs for abnormal traffic patterns. If servers that normally receive a low volume of traffic are suddenly responsible for a significant portion of traffic passing through the firewall (either in total connections or bytes passed), then you have a situation worthy of further investigation. While flash crowds are to be expected in some situations (such as a Web server during a period of unusual interest), they are also often signs of misconfigured systems or attacks in progress.
- Rule violations: Looking at traffic denied by your firewall may lead to interesting findings. This is especially true for traffic that originates from inside your network. The most common cause of this activity is a misconfigured system or a user who isn't aware of traffic restrictions, but analysis of rule violations may also uncover attempts at passing malicious traffic through the device.
- Denied probes: If you've ever analyzed the log of a firewall that's connected to the Internet, you know that it's futile to investigate probes directed at your network from the Internet. They're far too frequent and often represent dead ends. However, you may not have considered analyzing logs for probes originating from inside the trusted network. These are extremely interesting, as they most likely represent either a compromised internal system seeking to scan Internet hosts or an internal user running a scanning tool -- both scenarios that merit attention.
Your firewall audit logs are a veritable goldmine of network security intelligence. Use them to your advantage!
This tip on firewall management data was excerpted from SearchSecurity.com.
>> View SearchNetworking.com's Network Security Best Practices and Products resource page to learn more.
This was first published in January 2008