This article doesn’t reiterate the benefits or values of consolidation, but seeks to level-set the new challenges that must be faced with regard to firewalls. However, it’s important to mention a few benefits of or savings associated with providing a physically secure networking environment:
• Latency is improved as data can be quickly moved between virtual operating environments; in some cases, taking advantage of memory access speeds.
• Communications are enhanced, both in latency and MIPS consumption, as link encryption is no longer needed, since only the two environments that need to communicate are on a physically secure, isolated network that nobody can see, let alone penetrate.
At a platform level, all the virtual networking connections are configurable and identifiable in one place. They can be audited for compliance or per security policy in a secure environment. HiperSockets can be configured to provide communications between two or more LPARs. In the z/VM environment, virtual LANs can be configured to provide communications between two or more guests. Each of these environments is easily audited for compliance. These tools provide the network architect with the building blocks needed to provide a previously distributed solution a home in the physically secure, virtual server environment on System z.
There’s no one right way of doing things and no best practices that fit every scenario. Success with a new consolidation effort requires assurance that the existing security policy is enforceable. If a project is started and the firewall security policy must be changed to make it work, history has shown repeatedly that the project is likely to be doomed. It’s far easier to deploy a solution in compliance with an existing security policy, transitioning from the distributed solution in Figure 1 to the consolidation solution seen in Figure 2, with the goal of augmenting the solution later to take advantage of platform enhancements or capabilities.
Bringing the Firewall Inside
A possible improvement to consider is to bring the firewalls inside the System z hardware, as portrayed in Figure 3. In this case, using a BrandX firewall appliance isn’t an option, so we turn to open source Linux solutions such as ip_tables, netfilters, and connection tracking (ip_ conntrack and nf-conntrack). Together they provide packet and port filtering with network address and port translation as well as stateless or stateful packet filtering. This may be all that’s needed. Depending on the number of firewalls deployed, management can occur on a case-by-case basis. In the case of multiple firewalls, some implementers have been successful using other open source projects, such as FireStarter and Firewall Builder, to manage their firewalls. These projects are a start. As the community grows and requirements develop, work remains to be done before the solutions can be considered enterprise ready to manage large numbers of firewalls.
Another alternative when running in a physically secure environment, such as System z, is to use the firewall capabilities of a host firewall technology. This is analogous to many of the “personal” firewall solutions that are used on home and business laptops and workstations around the world, but the firewall capability is brought into the host image; for example, the firewall would run as part of the TCP/IP stack in the application server in Figure 4.
Remember that firewalls tend to fall in the domain of the network team. Usually, they’re responsible for all networks, including network security technologies, regardless of whether the networks are cross-country or local, Internet-connected or intranet only, cabled, wireless, or physically secure virtual networks inside the System z hardware. If the team responsible for the platform, including hardware and software, isn’t talking openly with the team responsible for the networking, the project will have a rough time getting off the ground. These teams need to get in the same room and decide what problem they’re trying to solve and what firewall solution their security policy will support. They need to look at the flows for the end-to-end solution and understand what encryption is needed, where, and why. Only then can they understand if they can take advantage of the physical security of the virtualization platform or the benefits of eliminating link encryption in this environment.
