As discussed in the previous chapter, firewalls can be deployed in multiple modes, including routed and transparent, and most of them can be virtualized into security contexts that provide cost-effective solutions.
Virtual Firewalls
The virtual firewall is a security context and it is a way to partition a physical firewall into multiple logical devices, each with its own configuration. This is similar to having multiple standalone firewalls but without having to buy separate devices. When defining security contexts on a device, the old configuration will be saved in the appropriate file and the new virtual firewalls will each have dedicated configuration files. Security contexts are distinct and independent firewalls in the sense of having their own attributes, such as the following:
- Security policies
- Assigned interfaces
- NAT rules
- Access Control Lists
- Administrators
Each virtual firewall has a system configuration that can be modified through the administrator context, which is created automatically when converting from single-mode to multiple-mode. The administrator context is just like any other virtual firewall, with the exception that it is the one used to access the system and configure it. Typically in the design, the VLANs are linked to security contexts and most firewalls allow for multiple VLANs to be assigned to a single security context.
Some of the technologies that are not supported on common virtual firewalls include:
- IPsec VPN
- Secure Sockets Layer (SSL) VPN
- Dynamic routing protocols
Another important concept in virtual firewall design involves resource classes. When configuring an ASA device, all resources are available to all security contexts, by default. This can be modified from the administrator context that allows the creation of new contexts and the assignment of resources to each of them. These resources can be grouped into resource classes and these can be easily managed and assigned to security contexts from the administrator context.
Active/Active Failover Firewalls
The active/active failover mechanism used on firewall devices leverages the virtual context feature. The best results are obtained when the two devices configured with active/active failover have an identical platform and operating system. The two firewalls must be connected with a failover state link and this can be accomplished in three ways:
- Single physical link: Both the failover and stateful information are transmitted on this link.
- Dual physical links: The failover information is exchanged on one interface and the stateful information (maintaining the TCP connection and the translation rules) is exchanged on another.
- Dual redundant physical links: These act as a single logical link that carries both the failover and stateful information between the firewalls.
Figure 9.4 – Active/Active Failover Firewall Deployment
Although the two devices are identical, either firewall modules or ASA devices, the security contexts feature will be leveraged. As depicted in Figure 9.4 above, this is accomplished by defining two security contexts on each firewall that will accomplish the following functions:
- Context 1 is the active firewall for the left device (FW 1).
- Context 3 is the standby firewall for the left device (FW 1).
- Context 2 is the standby firewall for the right device (FW 2).
- Context 4 is the active firewall for the right firewall device (FW 2).
This scenario provides two virtual firewalls, with the physical devices each being partitioned in one active and one standby context. Contexts 1 and 3 in Figure 9.4 are logically grouped across the two physical devices, just like Contexts 2 and 4 are. In many situations, the security contexts feature will serve only as a mechanism to create active/active failover configurations, but on high-end devices, this functionality can be used for both creating active/active topologies and assigning a set of VLANs to each virtual firewall.
Private VLANs
Private VLANs (PVLANs) can be an option for adding an extra security layer in the Enterprise Campus module or the data center submodule, especially in the e-commerce submodule. A PVLAN is a way to take a VLAN and divide it into more logical components, which allows groups of servers or individual servers to be isolated, quarantining them from other devices.
To build a good trust model between servers and the DMZ, consider separating the servers so that if one of the servers is compromised (e.g., by a worm or a Trojan attack), it will not affect other servers in the same subnet. PVLANs function by creating secondary VLANs within a primary VLAN. The secondary VLANs can be defined based on the way the associated port is defined on the switch:
- Community VLANs: They communicate with devices in the same community VLAN and with promiscuous ports on the primary VLANs.
- Isolated VLANs: They communicate only with promiscuous ports on the primary VLANs.
| Note: Promiscuous ports are those that allow the sending and receiving of frames from any other port on the VLAN and they are usually connected to a router or other default gateway. |
Figure 9.5 – Private VLANs
As illustrated in Figure 9.5 above, the primary VLAN usually represents the server farm and this can be divided into secondary VLANs for private traffic flows. Secondary VLANs are logical VLANs within a VLAN and they are similar to subinterfaces on a physical interface. Community ports can communicate with ports configured with the same community or with promiscuous ports but they cannot communicate with ports from other communities or with isolated ports. On the other hand, isolated ports can communicate only with the upstream promiscuous ports to reach the default gateway.
Implementing PVLANs is a good way to connect and secure server farms (secondary community VLANs) and isolated servers (secondary isolated VLANs). A major advantage of using PVLANs is that no additional STP instances are created when secondary VLANs are defined. Using the classic model of dedicated VLANs, each newly created VLAN would imply adding an extra STP instance, which would increase the management overhead. PVLANs can also be trunked across multiple switches in complex environments to span across the data center infrastructure.
If PVLANs are trunked across switches, VTP (VLAN trunking protocol) will not be supported. Configuring the switches for PVLANs requires operating in transparent mode and manually adding all of the VLANs on the switches.
Zone-Based Firewalls
A zone-based firewall policy is an IOS feature that can leverage the existing ISR routers by configuring firewall functionalities on them, as opposed to using dedicated ASA devices or firewall modules. Cisco Zone Based Firewall (ZBF) functionality was introduces in Cisco IOS 12.4(6)T as an evolution from traditional firewall implementation, which was an interface-based model (the “ip inspect” command can be applied on an interface in the inbound or outbound direction). The limitations imposed by the traditional firewall implementation led to the development of zone-based firewalls, which work by following these steps:
- 1. Create security zones.
- 2. Place an interface or multiple interfaces into each security zone.
- 3. Create unidirectional zone pairs to define relationships between zones.
- 4. Apply a modular, flexible, granular policy (using class maps, policy maps, and service policy) to the zone pairs.
Figure 9.6 – Example of a Zone-Based Firewall
Analyzing Figure 9.6 above, a few security zones (i.e., Trusted, Untrusted, and DMZ) have been created and interfaces have been placed into each zone (i.e., Gigabit0/0 in the Trusted Zone, Gigabit0/1 in the Untrusted Zone, and Gigabit0/2 in the DMZ). After defining the zones and assigning interfaces, unidirectional zone pairs can be created to enforce policies for traffic passing through the three defined zones:
- Trusted to DMZ
- DMZ to Trusted
- Trusted to Untrusted
- Untrusted to Trusted
- DMZ to Untrusted
- Untrusted to DMZ
After the zone pairs are defined, different policies can be applied to them, and once the modular policies have been created and the zone-pair relationships have been defined, other interfaces are placed into that zone and the policy applies to it automatically. Using zone-based firewalls no longer requires having just one ACL per interface per direction per protocol to provide security policies.
Zone-based firewalls provide major advantages because they use a modular configuration structure (similar to modular QoS), including:
- Modularity
- Flexibility
- Granularity
| Note: Zone-based firewalls have replaced the older Context Based Access Control (CBAC) firewall technology that was implemented using the “ip inspect” command on various interfaces. |