CHAPTER
8 Firewall Deployment Considerations
FIREWALLS CAN BE COMPLEX security solutions. You should plan the deployment of a firewall carefully, whether it’s for a small home office or a large corporation. Evaluate as many firewall deployment considerations as possible before ramping up.
Make a clear determination as to what types of traffic you will allow to cross the network border and which types you want to block. Evaluate common security strategies. They include security through obscurity, principle of least privilege, simplicity, defense in depth, defense diversity, chokepoint, weakest link, fail-safe, and forced universal participation. Determine which strategies you want to use and integrate them into the organization’s security policy and its firewall deployment.
Evaluate the purpose and content of the firewall policy. Clearly define the software and hardware firewall options you will use when adopting the firewall policy. Determine whether features such as reverse proxy and port forwarding are necessary to the infrastructure’s network communications. Weigh the benefits of bastion host OSs before using new firewalls. Make sure to order firewall rules properly and use the least number of rules possible to enforce security goals.
Every organization is different and must evaluate its own business and security needs. Determine which tasks are essential, which are optional, which are personal, and which are malicious. Use firewalls and other controls to support what’s necessary and block everything else. Security administrators are responsible for evaluating needs and solutions and for preparing a response when security and business interfere with each other.
Chapter 8 Topics
This chapter covers the following topics and concepts:
What should you allow and what you should block when using a firewall
What common security strategies for firewall deployments are
What essential elements of a firewall policy are
What the software and hardware options for firewalls are
What the benefit and purpose of reverse proxy are
What the use and benefit of port forwarding are
Which considerations aid in selecting a bastion host operating system (OS)
How to construct and order firewall rules
How to evaluate needs and solutions in designing security
What happens when security gets in the way of doing business
Chapter 8 Goals
When you complete this chapter, you will be able to:
Compose a firewall policy defining what to allow and what to block
Describe various firewall security strategies
Define the pros and cons of reverse proxy and port forwarding
Explain the importance of a bastion host
Assess the business impact of security over availability and performance
What Should You Allow and What Should You Block?
The most commonly asked question when installing a firewall is, “What should be allowed and what should be blocked?” This question assumes a distinct and definitive answer. The answer, however, is subjective and variable.
A single security stance or filtering configuration that works for every situation, every organization, and every system doesn’t exist. Network security managers must investigate the needs and threats to make informed decisions about what traffic to allow and what traffic to block.
The first stage in making this determination is to perform a complete inventory of all needed or desired communications. This should include every transaction between internal systems, as well as any interaction with external systems. As part of this inventory, indicate the protocol in use, the port(s) in use, and the likely source and destination addresses.
A possible inventory of network communications could look like Table 8-1.
This is not an exhaustive table, but it shows the basic idea of an inventory of network communications. Notice that some communications are internal only, while others cross the network boundary. Based on a complete and exhaustive inventory of your network’s communications, you can establish a potential rule base.
From the inventory, block from crossing the network border all communications that should only be internal. In most cases, the default-deny rule of a rule set will block those communications from doing so. However, when a port or protocol is in common, it’s possible that an Allow rule for a valid external communication would also allow external entities access to an internal-only communication.
In Table 8-1, an example of this issue is the e-mail protocol SMTP operating over port 25. By defining an allow-exception rule, you could create a loophole that threatens the internal communication on this same port. Reduce or eliminate this risk by using a very specific rule or by adding an additional Deny exception.
A very specific rule in this example would allow external communication over port 25 only if it originated from the internal e-mail server at 192.168.42.115. With this rule defined, if any other internal host attempted an external SMTP communication on port 25, it would not be allowed because the IP address would not match this specific rule. The communication would instead be blocked by the default deny.
TABLE 8-1 A partial list of communications occurring on a network.
If an allow-exception rule for external communications also applies to internal communications, you can add a specific deny-exception rule just prior to the Allow rule. The Deny exception can specifically block internal communications from crossing the network border, but still allow the subsequent Allow exception to grant access to the valid transactions.
After you complete a thorough inventory of network communications, you should determine which communications are mission-critical, important, optional, for personal recreational use, or actually malicious. Block any traffic you deem malicious or just unwanted, whether through an explicit Deny or via the catchall default deny.
Evaluate all other forms or types of traffic against several factors, including policy. If it’s not in support of the business, is it really needed? Are communications for personal entertainment or nonbusiness functions permitted by policy or considered a waste of resources? Are any communications duplicated or redundant? Is this a waste of resources, an expansion of the attack surface, a valid redundancy, or avoidance of a single point of failure? Are any of the communications no longer necessary? If so, should you disable or remove them?
Base your evaluation of the many other possible questions or issues on your organization’s policy statements, including mission and goals. Take the time to understand the communication needs of your network, then design the filtering rule set accordingly. Remember that the firewall is often the front sentry or the first line of defense against malicious communications originating from outside networks. Leaning toward caution and locking things down is a more effective security stance than leaving communications open and hoping detection mechanisms will notice malicious events.
Traffic Inventory
A common, and free, network protocol analyzer (or sniffer) for doing a traffic inventory is Wireshark (www.wireshark.org). Wireshark can be used in the absence of a firewall, with a firewall set to allow all traffic, or even in the presence of a firewall to inventory all traffic on the network. Traffic can then be partitioned into traffic that needs to cross the firewall and traffic that should not cross the firewall. Use of a sniffer tool in general, or Wireshark specifically, for traffic inventory is done to highlight all traffic and make sure that the firewall rules have a better chance of being accurate. During the traffic inventory, you can uncover a lot of previously hidden information about the network. You can find out which applications and users are the top consumers of bandwidth. You can find out which protocols are actually in use on the network. And you can surface malicious uses that you haven’t known about before. Some of the more advanced firewalls also have this functionality built-in.
While some exceptions to these suggestions will arise from your organization’s business model or strategies, the following items are commonly considered communications to block in most, if not all, circumstances:
All Internet control message protocol (ICMP) traffic originating from the Internet
Any traffic directed specifically to the firewall
Any traffic to known closed ports
Any traffic to known ports of known malware, such as 31337, used by Back Orifice
Inbound Transmission Control Protocol (TCP) 53 to block external domain name system (DNS) zone transfer requests
Inbound User Datagram Protocol (UDP) 53 to block external DNS user queries
Any traffic from IP addresses on a blacklist
Any traffic from internal IP addresses that are not assigned
As an organization manages its security over time, especially as it reacts to intrusion attempts, experiences scanning, and becomes the target of hacking and flooding, it must create additional communication filtering rules to respond to real-world conditions. Security does not stand still. Hacker attacks are constantly changing. Thus, the filtering rules that work well today may be insufficient in the near future.
Networks can be very large and very complex. Be fully aware of the communications taking place across your network to know what to allow and what to block. In addition to this knowledge, having established a security strategy through a written security policy will direct and guide the deployment of firewall rules, as well as other aspects of your security infrastructure.
Common Security Strategies for Firewall Deployments
A security strategy is a guideline, philosophy, or approach to using security for firewalls, as well as the entire organizational security infrastructure. Many different strategies are available. Some organizations focus on a single strategy, while others combine several strategies into a custom policy.
Security Through Obscurity
Security through obscurity is the idea of gaining protection by using abnormal configurations. This is both a positive security action and a poor one. It simply depends on the type of obscurity involved. A poor choice for security through obscurity would be to use alternative configurations for standard products.
With a network environment based on standard products, whether operating systems, network services, or security solution, just modifying basic configuration settings does not actually provide true security. For example, a service typically operating on one port that’s reconfigured to use a different port is not good security. Also, changing names, addresses, network size, subnetting, bandwidth consumption, or even spoofing banners, headers, or identity does not provide true security but may provide some protection against elementary attacks.
Some common mistaken examples of obscurity-based security include:
Hiding your front door key under a rock in a flower bed
Connecting to the Internet with the assumption that your system is one in 300 million and therefore won’t be noticed
Hiding money in a mattress
Keeping an encryption algorithm secret
Hiding your car keys behind your bumper while at the park or beach
Changing the default service port of a network service
Hiding your financial records among the audio files on your MP3 player
All attempts to provide network security based on hide-and-seek can be overcome or bypassed with basic network scanning techniques. When a hacker can discover or breach a host, service, or network just by looking hard enough, no real security exists. Hiding might work for keeping colored eggs and candy secure, but a security solution employed by bunnies has no place in a modern IT environment.
Security through obscurity is problematic for several reasons. First, if it’s the only form of security employed, no real security exists. Second, the obscurity method employed might not actually be as obscure as you think. Hiding a key under a flowerpot is not as obscure as burying it in an unmarked location in the middle of a field. Third, it often distracts from accurately assessing the true state of security provided by other measures. Fourth, obscurity can instill a false sense of confidence.
True security through obscurity relies on using obscure and nonstandard technologies. If everyone knows the most common or most popular operating system or software product is insecure, it can be a security improvement to use a more obscure product instead. This doesn’t guarantee that other flaws or vulnerabilities won’t be present on the alternative system, but usually the exact same exploit or compromise won’t be a risk.
However, switching to an alternative technology is a security improvement only if the same flaw does not also exist there. It must provide actual security in and of itself. Switching technologies, such as changing operating systems, does not eliminate the need for security management. It simply moves the security concerns to other areas.
Generally, security is obtained through obscurity only when hackers are unable to determine which technologies you are using. The less hackers know about your software, configuration, deployment, addressing, infrastructure design, patching schemes, and so on, the less successful their attempts to compromise security will be. Obscuring information about the internal IT environment itself is a primary defense against their hide-and-seek mentality.
Least Privilege
The principle of least privilege is one of the basic concepts of network security. The idea behind the principle of least privilege is that users should have the minimum level of access to resources needed to complete assigned tasks. Any abilities, access, or privileges beyond that necessary minimum increase the risk of compromise and lead to wasted time, effort, and focus.
In most environments, most users need not access every host, every system, every resource, every file, every network service, and every Internet resource. Within a default-deny environment, you block all access to all resources, internal and external, by default. You use the principle of least privilege by adding explicit and specific allow-exceptions only when necessary based on job descriptions.
However, the drawback to least privilege is the need to control every user’s access individually. Each worker will need individually defined resource and activity permissions. This represents a significant increase in user administration. Because of this extra overhead, many organizations only partially use least privilege.
A common practice is to group users into collections of similar job functions or security levels, granting permissions to the group as a whole. This gives users additional privileges beyond what is strictly necessary for their work, but not enough to present a serious risk to the organization’s security, stability, or confidentiality. Instead, this small security tradeoff considerably cuts down on administrative overhead.
An extension of the principle of least privilege known as separation of duties specifically addresses administrative users. A lazy and insecure approach to network security is to grant some high-end users full administrative privileges across the entire IT infrastructure. This is a recipe for disaster. If an administrator makes a mistake, then he or she can accidentally harm the entire organization. If an administrator becomes disgruntled, feels wronged by the company, or is marked for layoff or forced retirement, he or she can deliberately harm the organization and would have the systemwide power to do it. If another user or an external intruder compromised such an administrator’s account, a hacker could use the administrator’s advanced access to cause significant havoc.
A safer approach is to apply the principle of least privilege to all users, especially administrators. Under the label of separation of duties, divide the collection of all administrative tasks into small sets of privileges, focusing on a single task, system, service, or issue. Then, assign administrators subtasks within one of these focused areas and permissions only within the scope of their assigned tasks. This compartmentalizes administrative functions and provides a type of firewall or blockage against accidents, sabotage, and intrusion.
The result of applying separation of duties is that you eliminate godlike systemwide administrators. Instead, each administrator has sufficient privileges only within a limited scope of responsibility. Some areas may have multiple administrators and some administrators may have powers in multiple areas, but overall the compartmentalization of administrative privileges significantly increases security and decreases risk.
Keep in mind that the principle of least privilege applies to both users and systems alike. Controlling which resources and communication pathways a service or device can touch will directly reduce the potential for abnormalities, abuse, and compromise.
Simplicity
Keeping things simple is an important part of security. It makes them easier to understand, manage, and troubleshoot. When things are too complex, they are much more difficult to understand, much harder to manage, and much more complicated to troubleshoot. Furthermore, it’s harder to verify that a complex system is providing adequate security.
The more complex a solution, the more room for mistakes, bugs, flaws, or oversights to creep in undetected by security administrators. The more complex the system, the more likely a hacker can find a vulnerability unseen by the system designers and network managers.
Simple is not always possible, however, especially when it comes to software and network infrastructures. But when you have a choice between a simpler solution and a more complex one, the simpler option may provide a more realistic and verifiable level of security. As someone once said, “Keep things as simple as possible, but no simpler.” Keep in mind that too simple has the same flaws as too complex. Avoid sacrificing security for the sake of simplicity.
Defense in Depth
Installing a security infrastructure requires numerous systems to interact and interlock. The goal of any security solution is to prevent unwanted events while supporting authorized and necessary ones. A reliable security infrastructure is typically not a single control, a single defense, or a single countermeasure. Instead, multiple security safeguards provide complete and exhaustive coverage.
One aspect of infrastructure security design is to think of the defenses as multiple layers or barriers to access secured resources. This is known as layered defenses or defense in depth. When designing security, consider the net result if any component of the security system were to fail. If a single component failing results in a compromise or intrusion, the environment has a single layer of protection. When defense in depth is used, a single component failure does not result in compromise or intrusion. Instead, each component has a backup, an alternative, or a supplemental component. Depending on a single security product as the sole component of a security solution is a bad idea. Firewalls are great products, but firewalls alone cannot provide complete security. They are only one component, one piece of a complete security infrastructure. A proper security infrastructure has numerous components interlocked and deployed in layers or levels.
Another aspect of defense in depth is to deploy multiple subnets in series to separate private resources from public. This is known as an N-tier deployment. N represents the number of subnets under private control. Figure 8-1 shows a common construction of a three-tiered deployment using a demilitarized zone (DMZ), a database subnet, and the private local area network (LAN).
When properly implemented, defense in depth ensures that multiple security controls are involved in every communication, connection, and transaction, regardless of its source or destination. Through the use of multiple or redundant security systems, any attempt to compromise or breach security becomes substantially more difficult, not only for the external intruder, but for the internal saboteur as well.
FIGURE 8-1
An example of an N-tier deployment.
Diversity of Defense
Diversity of defense is similar to defense in depth—it supports multiple layers of security. The difference is that each (or at least most) of the layers uses a different security mechanism. Thus, the diversity of defense comes from using a collection of diverse security solutions.
Multiple firewalls in a series is defense in depth, but not defense diversity. Adding tools such as an intrusion detection system (IDS), antivirus, strong authentication, virtual private network (VPN) support, and granular access control converts a monolithic defense in depth to a more substantial, multilayered, diverse type of security.
It might be tempting to claim that having multiple firewalls from different vendors (or any security mechanism from different vendors) constitutes diversity of defense. While using different products from different vendors will reduce some forms of risk, it’s not as beneficial as true diversity—not just of vendors but also of security component types.
Using a variety of vendors will reduce the likelihood that a single flaw in one product is present in every other product from different vendors. For example, using three different vendor antivirus products is a reasonable idea. Having one vendor for clients, one vendor for internal servers, and a third vendor for border devices will increase the likelihood of detecting malicious code and decrease the threat from undetected malware. However, relying exclusively on antivirus and using no other type of security mechanism is a poor security solution.
Proper defense in depth will include diversity in both vendor selection and security component types. Be aware, though, that focusing too heavily on vendor diversity can increase management and administration complexity. It’s difficult enough to manage single-vendor solutions, but when two, three, or more different vendor products of the same product type are involved, the complexity of management increases significantly.
When selecting products, whether by type or vendor, keep in mind the overall infrastructure design, such as parallel versus serial connections, as well as redundancy options. In some circumstances, using two different defenses can result in a larger rather than reduced attack surface. For example, if two different products each have a different vulnerability when they are deployed in parallel, then both weaknesses are vulnerable simultaneously, giving the hacker the option of one or the other. Were they to be deployed in series, the hacker would have to compromise the first layer of defense successfully before attempting to breach the second. Consider whether the planned diversity is truly a security improvement, since poor design can lead to reduced security when you employ diversity improperly.
When investigating and designing an infrastructure to include diversity of defense elements, keep the following concerns in mind:
Some companies resell their products, technology, or intellectual property through other vendors. Private-label or relabeled products from company B might be the same product from company A with a different name or packaging.
Security systems configured by the same security administrator can potentially have the same misconfiguration or design weakness. Consider using a team of security administrators, or at least have several security experts review and check all configurations.
Many products come from a single original code base or standard. Product version 2.0 from company A and product version 5.0 from company B might both include the same protocol stack code borrowed from an open-source or creative commons–licensed code base. Don’t automatically assume that products from different vendors, even with different build versions, represent 100 percent different programming.
Many systems of the same type will all have the same inherent weaknesses in the underlying technology, design, and security concept.
When implementing diversity, ensure that you are using actual diversity-improving security rather than false or misguided diversity that reduces security. All security designs and perceptions should withstand the scrutiny of evaluation and testing.
Chokepoint
A chokepoint forces all traffic, communications, and activities through a single pathway or channel. This pathway can be used to control bandwidth consumption, filter content, provide authentication services, or enforce authorization. The purpose of a chokepoint is to ensure that the security device at the control location controls everything. No traffic, user, or data passes unchecked.
Other names for a chokepoint include checkpoint, filter pathway, or bottleneck. A chokepoint can be used to force network traffic along a single pathway monitored or filtered using security devices, including routers, switches, firewalls, IDS/intrusion prevention system (IPS), antivirus, network access control (NAC), and so on. A choke-point can also control user activity, such as requiring authentication and enforcing access control.
As a security measure, a chokepoint has value only if it’s hard to bypass or avoid the bottleneck itself. If a hacker can interact with a target without going through a chokepoint’s filtering system, then the chokepoint is worthless.
If the security of a network has chokepoint infrastructure components as a central part of the infrastructure, be sure to evaluate and consider all possible alternative pathways a hacker might employ. For example, a firewall is less effective as a chokepoint if outsiders can access wireless access points, physical connection ports, or dial-up modems.
In many cases, a single chokepoint won’t be enough. Using multiple chokepoints may be the only effective means of ensuring that your network evaluates and filters all traffic. Some potential chokepoints can include any crossing of a network domain boundary into another. By using chokepoints across the boundaries of a typical IT infrastructure, you filter most pathways of communications that could host malicious interactions.
Consider potential indirect routes that might bypass “standard” chokepoints. For example, if a VPN link is established between two sites, whether branch offices or business partners, the Internet connection of one site could be an alternate pathway into the second site. This breach is possible if one site uses strong chokepoint security while the other does not. And even though it may be old fashioned, don’t forget to check for dial-up access to a LAN’s servers or other components. Dial-up access can serve as a backdoor for hackers to circumvent the security protections prepared to block them at the front door.
Weakest Link
Any chain is only as strong as its weakest link. A security infrastructure is only as strong as its weakest component. You must know your security infrastructure thoroughly to have an understanding of where the weakest point lies. Once you’ve identified the weakest link, replace or remove it.
The weakest link security stance is an ongoing process of locating the least secure element of an infrastructure and securing it. Once you’ve secured the current weakest link, it’s no longer the weakest link, and therefore a new weakest link exists. Repeat the cycle by seeking out the next weak point and improving it.
The idea behind this security stance or process is that hackers are performing this exact task as they seek out vulnerabilities to compromise. Ultimately, hackers discover and break the weakest links to gain access and entry into a secured environment. By actively and consistently seeking out vulnerabilities and weak points to secure them, you reduce the potential of a hacker finding and exploiting a weak link.
Weakest links are inevitable. But a strong weakest link is always better than a frail weakest link. Using a find-it-then-secure-it mentality helps build security that can withstand most common exploitation and intrusion attempts.
Fail-Safe
Fail-safe, fail-secure, fail-open, and fail-closed are not only design elements of firewalls and other security controls. Fail-safe is also an overarching security stance to drive an organization’s security. The fail-safe security stance is not just about using fail-safe security devices, but about designing the overall infrastructure with fail-safe as a core focus.
When any aspect of security fails, the best result of that failure is to fail into a state that supports or maintains essential security protections. Generally, this means to maintain confidentiality and integrity protections. However, most fail-safe solutions will sacrifice availability protection to retain confidentiality and integrity.
Fail-safe does not need to be a standalone security stance. You can integrate fail-safe notions into any security perspective. Keep in mind the ultimate goals and policies of your organization. If availability is the top priority, then fail-safe may not be as viable an option as for environments where you can sacrifice availability to support other security protections.
Forced Universal Participation
It almost goes without saying that for security to be effective, everyone must work within the limitations established by your organization’s written security policy. If you make exceptions—for upper level managers, for instance, who see themselves as being above the rules, able to do whatever they want without consequences—then you have only an assumption of security. No true security is present. Security works only when you employ forced universal participation.
Every worker, every manager, every senior executive, every temporary worker, every consultant, every vendor, every customer, every business partner, and every outsider must be forced to work within the security policy’s limitations. Yes, exceptions often are necessary in the real world, but when exceptions become the norm, security is lost. When it’s easy to bypass, avoid, or even ignore security controls, an attacker can use that same pathway to compromise the entire security environment.
Universal participation is not just about official configurations and designs. Every enterprise that cares enough about security to write a security policy has official configurations and designs that assume everyone follows the same rules. When it’s unwritten policy to violate security to accomplish work tasks, an obvious disconnect exists between security and productivity. In this situation, reexamine both security and productivity goals. Security should support productivity, not impede it.
Universal participation is not just about paying lip service to the rules, however. It’s also about ensuring that everyone abides by security limitations. Potentially, users have many ways to purposefully violate security. This often occurs in environments where workers perceive the security limitations as too restrictive or when newly imposed rules strongly limit freedoms they enjoyed previously. The less workers believe in and buy into the organization’s security policy, the more likely they are to violate rules they perceive as unfair.
Examples of users purposefully avoiding or violating security—that is, not actively supporting and participating in security—include:
Choosing poor passwords
Sharing accounts with others
Using personal computer equipment on the company LAN
Installing an unauthorized wireless access point
Using personal removable media on company equipment
Using proxy tools to bypass firewall filtering
Configuring a dial-out modem connection to establish unfiltered Internet access
Using Internet based remote-access/remote-control tools to access their workstation from an external system without authorization
Installing unapproved software
To achieve universal participation in the security efforts, either workers must believe that compliance is in their best interests, or you must force compliance through consequences for violations. In most cases, voluntary compliance is better, because it causes workers to support the security effort rather than setting up employees to be adversaries pitted against the security infrastructure.
Essential Elements of a Firewall Policy
A firewall policy is a security policy that focuses on the deployment of firewalls within the organization’s IT infrastructure. The first step in deploying a firewall is constructing a firewall policy. Once you’ve established a firewall policy, deploy subsequently installed firewalls in full compliance with the firewall.
A written firewall policy provides several benefits and serves several purposes, such as:
A guide for installation
A guide for configuration
A tool to assist in troubleshooting
A guideline to detect changes and differences
A mechanism to ensure consistent filtering across all firewalls
A firewall policy should address several specific issues and contain specific configuration details. One of the first important elements of a firewall policy is defining and designating security zones. Every network has different zones of risk and zones of trust. Often, zones are differentiated along the same lines as a typical IT infrastructure. Create clear descriptions of what each subnet does, its level of risk, and its level of trust. Based on this information, you can formulate a basic firewall deployment strategy.
A firewall policy should define specifically what type of firewall you need. It may even prescribe the specific vendor, make, and model of firewalls at each zone transition or interface. Firewall types include static packet filtering, proxy, and stateful inspection.
For each prescribed firewall, define a complete firewall rule set. Define each rule in full detail, not just the configuration settings to make on the firewall’s interface. Support each rule with justifications and reasons why you defined or selected it. Give a clear indication of the orders of the rules.
A firewall policy should also prescribe host software firewalls for deployment on clients and servers. This should include configuration settings and rule sets as well. Design and configure host firewalls to complement appliance firewall security.
The firewall policy should also address:
What to log
How logging happens
Where to store log files
How often to review log files
What add-ons or enhancements to use
Who is responsible for firewall administration
How to access firewall configuration interfaces
Where to physically and logically locate the firewall
What level of physical access control is necessary
What form of backup or redundancy is present
How to manage encryption and where to use or disallow it
How to deploy and configure IDS/IPS to interact with firewalls
As with every security policy, the firewall policy must be as exhaustive as possible. It should address and define every aspect of firewall design, deployment, implementation, management, tuning, repairing, recovery, troubleshooting, and monitoring. A firewall policy should be the first and last authority on all things firewall within the organization.
The first draft of a firewall policy will probably not be exhaustive or accurate. So, review and improve your firewall policy periodically, just as you do with the rest of your organization’s security policy. Each review period should assess whether the firewall is meeting the security needs and how to improve it so it continues to provide sufficient security. Work all improvements into the written security policy. Then adjust the deployed infrastructure to comply with the written security policy.
Software and Hardware Options for Firewalls
Remember that most real-world solutions include a combination of software and hardware firewall options.
Since technology changes and advances so swiftly, it’s not wise to make specific product recommendations here. Many products can go through significant upgrade or generational change in as little as six months. So, this discussion will focus on software and hardware options in more generic terms.
Many operating systems include host software firewalls as part of their standard installation build. Microsoft Windows XP is one well-known example. Beginning with Service Pack 2, Windows XP has included the Windows Firewall as a standard security component. Other operating systems may offer optional firewall products. A software host-based firewall has benefits on both client systems and servers.
You can usually replace a native or default software firewall product found within a general-purpose operating system (OS) with a third-party option. Many open source, free, and commercial host software firewalls are easily available. When considering third-party options, especially when replacing the native firewall, consider whether investing time, effort, or money in an alternative host software firewall is as effective an investment as using an appliance firewall to enhance or supplement a host firewall.
Home users, SOHO environments, and small companies may benefit from a firewall on their Internet connection devices. Most DSL and cable modem devices include basic to moderately capable firewall options. Evaluate the included firewall in an Internet connection device rather than automatically discarding it as insufficient or inferior. Many current Internet service provider (ISP) devices include firewalls that are more than adequate for small network environments.
Most wireless access points, both consumer and commercial grade, include some form of firewall to provide filtering services for wireless clients and physical cable connections as well. Many wireless access points could be accurately labeled as routers and/or switches, especially when they include two to six extra-wired connection ports.
If a separate dedicated firewall device is necessary in addition to an ISP device or a wireless access point, consider building a firewall using leftover hardware. Building your own hardware firewall can be a way to obtain firewall appliance control and security on a shoestring budget.
technical TIP
It’s often possible to replace an appliance or device firewall’s OS with a third-party alternative. This can apply even to ISP devices and wireless access points. Some of the better-known device firmware replacement options are DD-WRT, Open WRT, and Tomato.
The final step up in terms of firewall options is the appliance firewall, which is a dedicated hardware device functioning as a black-box sentry. Appliance firewalls can range from low-end consumer-grade to very expensive high-end, commercial-grade solutions. In most mid-sized and larger organizations, a dedicated hardware firewall is a necessity. Whether you buy that firewall as a pre-built component or build it depends on your organization’s knowledge, skill, and budget.
Keep in mind that security is not about always purchasing the most expensive, the best-known, the most efficient, or even the most secure option. Budgets are not infinite. Your goal should be to deploy security that is adequate and effective for the environment within the confines and limitations of your budget, knowledge, and skill. Getting sufficient security at the best price possible is usually everyone’s priority.
Benefit and Purpose of Reverse Proxy
Reverse proxy is a firewall service that allows external users access to internally hosted Web resources. This service takes the traditional proxy function and inverts it. Instead of hiding the identity of the client reaching out to the Internet, reverse proxy hides the identity of the Web server accessed by the Internet (or external) client.
External users direct their queries to a public Internet IP address and a default or assigned port number as when accessing any service. However, the IP address is the address of a proxy server, not the actual Web server hosting the requested resource. The proxy server then performs network address translation (NAT) on the request to convert the destination address to the internal (likely private) address of the resource host.
You can deploy reverse proxy to support load balancing or load distribution across multiple internal resource hosts. This allows clients to use a single public address to access a cluster of internal Web servers.
Other common reasons to deploy reverse proxy include:
Reverse caching—Reverse caching allows static content to be cached and served by the proxy rather than requiring that each request for the same content be served by the Web server itself.
Security—Using a reverse proxy adds an additional layer of protection and control between Internet-based users and internally hosted servers. Proxying allows the real identities of the internal servers to remain unknown or at least obfuscated.
Encryption—The proxy server itself can serve as the endpoint for Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption tunnels. This can allow a firewall or IDS to monitor and filter the contents of the traffic before it reaches the Web servers. Proxy-based encryption can also benefit from hardware and software acceleration to maintain high-performance communications.
Reverse proxy does not have to function solely on the private network’s borders. It can also operate internally between subnets or departments, especially within IT infrastructures of very large corporations. Reverse proxy is also useful in an extranet or a DMZ. Just because a Web site is hosted for public access does not mean security precautions should vanish. Indirect access by reverse proxy can often be a significant security benefit when you deploy and manage it properly.
Use and Benefit of Port Forwarding
Port forwarding is a firewall, proxy, and routing service that can receive a resource request on an interface at one port, then forward the request to another address on the same or different port. Port forwarding is used in reverse proxy, but only for Web traffic. Port forwarding itself can support any service on any port.
Port forwarding is a variation or enhancement of NAT. When a request reaches an outward-facing interface to a specific port, the request goes to an internal host. The routing is controlled by a static NAT mapping that defines which internal IP address and port will receive communications sent to an external IP address and port.
Port forwarding does not support caching, encryption endpoint, or load balancing. Only a single internal machine can use a forwarded port at a time. The internal receiving (destination) host will perceive the source of the communications as the port-forwarding device because the translation service will rewrite the source address as its own. Thus, the destination system will not know the real originator of a communication.
You can find port forwarding services on almost any service or device that supports NAT. This includes most firewalls (hardware and software), wireless access points, and Internet connection devices (such as DSL and cable modems). Port forwarding is also an essential element in the Internet Connection Sharing (ICS) service of Windows that allows multiple systems to share a single Internet connection through the primary connected computer.
Considerations for Selecting a Bastion Host OS
A bastion host OS is a system designed, built, and deployed specifically to serve as a front-line defense for a network. A bastion host is the first (or nearly so) host accessed by external entities on their way to access DMZ, extranet, or private network resources. The bastion host withstands the brunt of any attack attempt to provide protection for hosts behind it.
Bastions were the highly fortified sections of medieval castles designed to assist with defense. The bastion was located along the castle perimeter wherever access attempts were likely, such as around the main gateway or entrance, any side or back entrances, or natural landscape pathways of approach. The bastion areas usually had thicker, stronger walls, room for additional warriors, and special defensive features. These special defensive features might have included slits for shooting arrows, holes for ramming spears or pushing away ladders, and pots of boiling oil to pour on attackers.
On modern computer networks, a bastion is a fortified computer device—possibly a host, firewall, or router—placed in the line of fire between privately owned and controlled networks and the public Internet. The purpose of a bastion host is to provide frontline filtering and defense against typical attacks. Most firewalls, especially appliance, hardware, or device firewalls, operate as bastion hosts. Software firewalls can also be bastion hosts if the host is properly locked down and hardened.
Knowing that firewalls are commonly deployed as bastion hosts raises the question of what type of operating system (OS) you should use as the host OS on a bastion host firewall. Two main categories or divisions of bastion host OSs are proprietary OSs and general purpose OSs.
Proprietary OSs are operating systems built exclusively to run on a bastion host device. Most appliance firewalls employ a proprietary operating system. This includes commercial firewall devices as well as many ISP connection devices and wireless access points. These proprietary bastion host OSs support the functions or services critical to security (or their other primary purposes) and little else. An example of a proprietary bastion host OS is Cisco IOS.
A firewall device’s bastion host OS supports only firewall functions. An ISP connection device’s bastion host OS supports firewall services and connectivity services. A wireless access point’s bastion host OS supports firewall services, wired connectivity services, wireless connectivity services, and possibly other services, such as 802.1x.
General purpose OSs include Windows, Linux, Mac OS, UNIX, and others. These are operating systems that support a wide variety of purposes and functions, including serving as client or server host OSs. When used as a bastion host OS, they must be hardened and locked down. Otherwise, an insecure host OS can render the security provided by a firewall worthless. If an attacker can crash the firewall host or bypass the firewall filtering, then the firewall is not providing effective security.
It’s possible to reasonably harden a general purpose OS for use as a bastion host OS, but this takes specific and detailed modifications. Most software firewall products include a guide to perform OS hardening to improve the security of the bastion host and reduce the vulnerabilities and backdoors that might permit firewall compromise.
Some firewalls include a prehardened version of a general purpose OS as the bastion host OS. This is the case for many Linux-based firewalls, such as SmoothWall.
The benefit of using a general purpose OS as a bastion host OS is that such OSs are widely available. Some are free—mostly Linux variations. Also, you can leverage your current knowledge and skill with a general purpose OS when you are using it as a bastion host OS. Keep in mind, however, that general purpose OSs are much more widely attacked and the risk of new exploits is high.
The benefits of a proprietary OS as a bastion host OS are fewer known attacks and less risk of future exploits. However, proprietary OSs might be significantly different from other OSs in the environment and may require learning a completely new system to properly and securely administer the firewall. Also, most proprietary OSs are officially released only on the bastion host hardware. This makes them more difficult to obtain and more expensive in most cases (at least in comparison to free and open source alternatives).
Constructing and Ordering Firewall Rules
As you begin to seriously consider the options for firewall deployment, a close examination of firewall rules is critical to success. The most important aspect of a firewall rule set is its order.
Getting rules out of order causes unexpected and unwanted consequences. This can include traffic you want to block and other unwanted traffic crossing the checkpoint. Rule-set ordering is critical to the successful operation of firewall security.
The first and most basic rule-set-ordering convention is that the universal Deny rule should be the last and final rule. The use of deny by default or default denial rests on the premise that the last rule is the catchall rule to block all traffic not allowed access due to a previous rule-based exception.
Another common guideline to rule-set ordering is to place critical Deny exceptions first or early in the rule set. When specific internal or external IP addresses or ports, or even entire protocols, are to be absolutely blocked, you may need a Deny exception rather than relying upon the default-deny final rule. Some of the previous Allow exceptions might inadvertently permit communications due to universal application (with the use of ANY). By using a preemptive specific enforced denial before any of the Allow exceptions, you eliminate the possibility of accidentally allowing a known malicious or unwanted communication.
Whenever possible, use fewer rules rather than more rules. Even with proper ordering, the more rules you have, the greater the likelihood of configuring something incorrectly or creating a loophole. One issue that causes more rules rather than fewer is infrastructure design specifically related to addressing. A need for more rules arises if a range of IP addresses is allowed access, but within that range, some addresses are refused access. For example, compare two scenarios.
First, a network has a host address range of 192.168.42.140–190. All hosts except for 188, 189, and 190 are allowed access to a certain port. A single rule allowing hosts 140–187 is all that is necessary because the default-deny rule takes care of blocking the remaining non-included hosts.
Second, a network has a host address range of 192.168.42.140–190. All hosts except for 165, 171, and 188 are allowed access to a certain port. You need multiple rules to use this configuration. One or more rules must define Deny exceptions for 165, 171, and 188, followed by the Allow rule of the 140–190 range. If the firewall allows only a single address or a range of addresses per rule rather than allowing a list of nonsequential addresses, then three Deny rules would be necessary in this scenario.
In this example, network design and addressing can be used to make firewall rule-set construction either larger and more complex or shorter and more distinct and compact. The latter is preferred for administrative purposes as well as security and efficiency. If the process of creating rules requires a significant number of special exceptions to modify or adjust ranges of addresses or ports, consider reconfiguring the network rather than using a too complex or too long rule set. When designing or writing firewall rules, especially when writing pairs or sets of rules, consider using a single rule or a simpler rule set if the network’s addressing scheme, infrastructure design, or subnet layout is adjusted.
As another guideline to ordering rule sets, consider placing rules related to more common traffic earlier in the set rather than later. Comparing traffic to the rule sets takes time; each check of each rule takes some finite amount of time. The fewer rules you need to check before you grant an Allow, the less delay to the traffic stream. Prioritize in the rule-set list the more commonly used forms of traffic, whether by
IP address, port, or protocol. Put the less commonly used forms of traffic further down in the rule-set list.
Ultimately, rule sets are about enforcing security relevant to the organization. The rule set should reflect the guidelines prescribed in your written security policy, specifically the firewall policy. The goal of designing, writing, and ordering rules for a firewall should be to focus on obtaining the necessary security. Elegance and speed are dividends, but not as essential as blocking the bad and allowing the good. Never lose focus on the primary goal: filtering traffic in accordance with your security policy.
Evaluating Needs and Solutions in Designing Security
Any organization larger than a single person will generate multiple opinions about what should and should not be allowed across the firewall. Almost everyone would agree on allowing (at some level) the necessary protocols, applications, and services essential for mission-critical or at least operationally necessary business tasks to cross the firewall-secured network boundaries.
Opinions may differ about what constitutes a necessary business task, but if it’s a necessary task, the organization’s security solution should make the task possible. Restrictions, limitations, filtering, and logging of even necessary business communications must occur. The point, however, is making a determination about what should and should not cross a firewall.
Generally, four main types of communications take place within a business environment: business-essential, business-wanted, personal, and malicious. Business-essential communications must take place or the business itself will suffer. Blocking critical transactions will directly cause problems for the business by impeding the production and distribution of products, inhibiting customer service, reducing profits, and so on. The security infrastructure must support business-essential communications.
Business-wanted communications are not essential to the core function or purpose of the organization. The failure of these business communications might be inconvenient or reduce quantity or quality, but the essential business functions will go on. Business-wanted communications help the business do what it does better, faster, cheaper, cleaner, more efficiently, or in a flashier way. But when those wants are not available for whatever reason, the business’s core activities still function sufficiently.
Personal communications are those transactions between individuals inside the company and with external entities not directly related to business tasks. If you eliminated personal communications, all business functions would continue unhindered. However, that’s in a perfect world. In the real world, stifling human communications can lead to low job satisfaction, feelings of isolation, and even worker disaffection. This, in turn, causes a reduction in productivity and quality.
Most organizations must strike a balance between allowing only business communications and allowing all communications. Obviously, allowing every communication is a bad idea from a security standpoint as well as a productivity one. Often, a modest level of Web site access, filtered e-mail access, and potentially other nonthreatening services as forms of personal communications can travel on and over company equipment during work hours with a reasonable amount of security.
But no clear or distinct boundaries define what level of personal communication will maintain worker morale and job satisfaction. It’s often fairly obvious when restrictions are too tight because job performance suffers or breaches of security increase. Part of the solution to this problem is educating users or workers about what is acceptable and unacceptable behavior on the company’s network. This includes defining what types of communications to allow or block, whether for business or personal use.
Malicious traffic, the fourth common type of network traffic, should always be blocked. This is a widely held security stance and the whole point of using security in the first place. However, it’s not easy to identify all malicious traffic, and it can sometimes appear to be one of the other three common forms of communications. Improving security over time is essential to maximizing protections against malicious communications while at the same time supporting necessary, desired, or benign personal communications.
Every organization must define its own parameters and justifications for each type of transaction allowed across any security perimeter, whether network traffic or physical access. Whatever the determination, clearly spell out the designations for valid versus invalid transactions in your organization’s written security policy, and then implement them in the security infrastructure.
Once you’ve defined necessary transactions and prescribed the desired security, use these concepts in actual security-enforcing software and hardware solutions. This is where your understanding of the goals of security, the organization’s mission, and the budget is critical. There is always a product that costs more, but more expensive does not always mean better security. In fact, in many cases, cheap or free solutions can offer equivalent or better security than the most expensive product available.
Using security is an essential part of the risk assessment and management process. Part of evaluating security is understanding the threats, attacks, and risks as well as the available countermeasures. One aspect of understanding countermeasures is performing a cost/benefit analysis to obtain the best security solution for the invested dollar. Don’t just purchase the most expensive solution; that’s never a reliable measure of security quality.
Also, don’t automatically purchase the product your cost/benefit analysis says is the best option. You must also evaluate each proposed solution in light of all other elements of the security infrastructure as well as the size of your budget. It’s usually not the right choice to spend 50 percent or more of the budget on a single security component. Instead, devise a spending plan or ratio tool to guide the procurement of security solutions.
One possible method is to allocate 10 percent of the budget to each of the 10 major sections or divisions of security addressed. This assumes you can divide the overall security of your organization into just 10 compartments—you might need 30 sections or maybe you can get by with just four. Whatever the number of divisions you use, grant each an equal or weighted portion of the budget based on risk. When a solution costs more than is available within a certain section, you can then shift funds between sections as needed.
The purpose of this system is to make security administrators and designers more aware of the cost of security and to prevent overspending in one area and underspending in another. You should spend security funds somewhat evenly to secure the overall organization, rather than over-securing one area and neglecting another. If a hacker or intruder encounters a highly fortified defense, he or she is likely to go looking for a less secure backdoor.
Ultimately, you should treat your security budget just like any other budget. Categorize and prioritize expenses. Outline spending on paper before writing the first check or swiping the plastic. Allocating funds based on needs and importance, then adjusting those allocations based on market conditions or changing threats, is all part of proper security management (as well as security budget management).
What Happens When Security Gets in the Way of Doing Business?
Organizations exist to perform tasks such as producing products or providing services. When the security infrastructure interferes with essential business tasks, something has to change. Security should prevent compromise while supporting and allowing business functions. When security changes or when business tasks change, the security policy and the business should adjust.
Absent this adjustment, security can interfere with business operations. Many organizations will never face this situation, but every business must have a response plan in place in case it does. When business tasks are at odds with security protections, what should you do?
A few short-term options are available, none of them optimal. One short-term option is disabling security so the business tasks go forward. Whether the security is disabled for a short period or permanently, you provide the opportunity for compromise, intrusion, or sabotage. Using this shortsighted solution might not immediately cause harm to the infrastructure, but it establishes a pattern and mindset that security is not important.
Organizations might get away with turning off security defenses. Hackers might not ever notice the reduction of defense or might not happen to time their probing or attacks to correspond to the period of disabled security. However, even if no actual attacks occur due to the security reduction, the real damage is done.
The real damage is the change in mentality toward security, a shift from viewing security as essential and mandatory to optional and nonessential. Once an organization believes that security can be turned off when inconvenient, then security suffers, and it’s only a matter of time before a catastrophic compromise occurs. Security depends on vigilance. Once the commitment to vigilance is lost, so is real security.
Another short-term option is not to perform the task that security is blocking. If the task is not essential, it might be possible to move forward as an organization without performing that specific task again. However, if it’s an essential or critical task, failing to support it will negatively affect the organization.
There is another way. The preferred and secure long-term response is to reevaluate the business task in the light of the security infrastructure. Design a new security solution or modify how the task is accomplished. Support both security and business functions. They are both essential to the long-term stability and vitality of an organization.
CHAPTER SUMMARY
Never deploy firewalls hastily. Instead, use careful investigation and planning in the design and use of firewalls. Consider numerous firewall deployment issues.
Some important concerns include deciding:
What to allow and block
Which security strategies to integrate
Whether the firewall policy is sufficient
Which hardware or software options to use
Whether you need reverse proxy
Whether to configure port forwarding
Which bastion host OS to use
How to order the firewall rule sets
What the essential firewall needs are
How the firewall will interact or interfere with business processes
KEY CONCEPTS AND TERMS
Bastion host OS
Diversity of defense
General purpose OS
Proprietary OS
Reverse caching
Security stance
Universal participation
Weakest link
CHAPTER 7 SUMMARY
1. When crafting firewall rules, determining what to allow versus what to block is primarily dependent on what factor?
A. Traffic levels
B. Business tasks
C. Bandwidth
D. User preferences
E. Timing
2. The first step in determining what to allow and what to block in a firewall’s rule set is:
A. Reviewing vulnerability watch lists
B. Polling users for what services they want
C. Reading blogs about best practices for firewall rules
D. Recording traffic for 24 hours
E. Creating an inventory of business communications
3. What is the purpose of including rules that block ports, such as 31337?
A. To prevent users from accessing social networking sites
B. To prevent DNS zone transfers
C. To stop ICMP traffic
D. To block known remote-access and remote-control malware
E. To allow users to employ cloud backup solutions
4. What security strategy is based on the concept of locking the environment down so users can perform their assigned tasks but little else?
A. Simplicity
B. Principle of least privilege
C. Diversity of defense
D. Chokepoint
E. Weakest link
5. What security strategy reverts to a secure position in the event of a compromise?
A. Fail-safe
B. Universal participation
C. Defense in depth
D. Security through obscurity
E. N-tier deployment
6. Which security stance most directly focuses on the use of firewalls or other filtering devices as its primary means of controlling communications?
A. Universal participation
B. Weakest link
C. Fail-safe
D. Chokepoint
E. Simplicity
7. A firewall policy performs all of the following functions except:
A. Assisting in troubleshooting
B. Placing blame for intrusions
C. Guiding installation
D. Ensuring consistent filtering across the infrastructure
E. Detecting changes in deployed settings
8. Which of the following is not a viable option for an enterprise network that needs to control and filter network traffic?
A. Virtual firewall
B. Appliance firewall
C. Physical firewall
D. Host firewall
E. Software firewall
9. A reverse proxy is useful in which of the following scenarios?
A. To grant outside users access to internal e-mail servers
B. To support internal users accessing the public Internet
C. To allow private hosts to access external Web servers
D. To offer external entities access to an internal Web server
E. To cache file transfers for peer-to-peer exchange protocols
10. All of the following are true statements with regard to port forwarding except:
A. It is a variation of NAT.
B. It is limited to Web traffic only.
C. It hides the identity of internal hosts.
D. It allows the use of nonstandard ports for publicly accessed services.
E. Internal servers do not see the identity of the real source of a communication.
11. Which of the following statements is true with respect to reverse proxy?
A. Reverse proxy cannot be used in conjunction with secured Web sites.
B. Reverse proxy can be used with tunnel mode IPSec VPNs.
C. Reverse proxy can only support SSL tunnels.
D. Reverse proxy caches client requests and archives them for load balancing purposes.
E. The reverse proxy server can act as the endpoint for a TLS tunnel.
12. Which of the following is not a true statement with regard to port forwarding?
A. Port forwarding services can be found on almost any service or device that supports NAT.
B. Port forwarding is an essential element in the Internet Connection Sharing (ICS) service of Windows.
C. Port forwarding is used in reverse proxy, but only for Web traffic.
D. Port forwarding supports caching, encryption endpoint, and load balancing.
E. Port forwarding is a variation or enhancement of NAT.
13. Which of the following is not considered a viable option as a bastion host OS?
A. UNIX
B. Linux
C. Android
D. Mac OS
E. Windows 7
14. You are selecting a new appliance firewall for deployment in the company network. You are concerned with OS flaws and exploits appearing not only on your hosts but also on the firewall. To minimize that risk, what bastion host OS should you choose?
A. Cisco IOS
B. Windows 7
C. UNIX
D. Mac OS
E. Linux
15. What is the most important aspect or feature of a bastion host OS?
A. Leveraging existing OS administrative knowledge
B. Ease of use
C. Remote administration
D. Resistance to attacks and compromise attempts
E. Support of a wide range of services
16. What is always the most important element within a firewall rule set?
A. Using specific addresses instead of ANY
B. Listing Deny exceptions after Allow exceptions
C. Listing inbound exceptions before outbound exceptions
D. Having a final rule of default-deny
E. Blocking every known malicious port
17. Which of the following examples of complete firewall rule sets is the most valid?
A.
B.
C.
D.
E.
18. Which of the following guidelines is most important?
A. Include all specific denials for known malicious remote-control tools after explicit Allow rules.
B. Include every possible address and port in a rule within the set to ensure an explicit callout exists for every type of communication.
C. There should be more inbound rules than outbound rules.
D. Place explicit Deny rules for individual systems before explicit Allow rules for ranges that include those individual systems.
E. Place universal Allow rules before universal Deny rules.
19. When considering the security response triggered by a firewall detecting unwanted traffic, what is the main factor in choosing between a response that protects confidentiality and integrity and a response that protects availability?
A. Traffic load
B. Number of external clients
C. Port in use
D. Business mission and goals
E. Whether the breach takes place during non-business hours
20. When security mechanisms and business communications are at odds, what is the best and most secure response?
A. Disable security to allow the business communication.
B. Modify the security policy to protect the business communication.
C. Disable both security and the offending business communication.
D. Disable business communication to maintain security.
E. Do nothing.