Enterprises have increasingly explored and deployed virtual environments in today's off-premises world, but operating...
in a virtual realm further complicates an enterprise's defensive architecture consideration. That being said, while the environment is more complicated (see Figure 1), a product set that properly integrates with VMware can greatly reduce administrative burden by facilitating management through a single pane of glass in vSphere.
With a large number of available technologies to consider, deciding which way to go can be difficult at best. So where do you begin? Most often going back to the basics is a great starting point. A multilayer approach to security has long been regarded as a best practice; hence a good place to begin your organization's security architecture considerations is in front of its VMware infrastructure. This tip will explore why border router ingress and egress filtering is key to those considerations.
Begin your defensive architecture at the Internet gateway
In securing your enterprise's VMware infrastructure, consideration should be given first to its external gateway architecture. This will enhance data center security by both providing a multilayer security architecture and enforcing the rule of least privilege. This can be achieved by using a sound defensive architecture, such as the example shown in Figure 2.
In the architecture pictured in Figure 2, the organization begins by pre-screening traffic inbound and outbound to add an additional layer of security. This also provides the benefit of reducing traffic volume to the virtual data center to only traffic that is necessary to fulfill business needs.
Enterprises could then take advantage of what is likely already available -- its current physical firewall. Use of the physical firewall in front of the data center essentially provides an air gap before traffic is seen by the virtual firewalls that operate within the data center. This is advantageous not only because of the benefits of an air gap, but also for a reduction in the risk of Common Mode Fault as the physical firewall is most likely a disparate technology from a disparate vendor.
Let's explore in depth.
Security at the border router
In many organizations, the border router is maintained by the network team. The primary consideration is availability and moving packets as quickly as possible with little -- if any -- regard for security.
However, security can be enhanced dramatically by using the border router as a first line of defense. This can be achieved by performing ingress and egress filtering within the border router.
The goal of ingress filtering is to take advantage of the highly efficient Layer 2 IP address filtering capability of the border router to drop traffic that has a high probability of being malicious.
Start by dropping any traffic that arrives at the Internet-facing external interface and meets the following criteria:
- A source IP address that is in use as an address within the internal network. This eliminates a malicious person from spoofing an internal IP address to take advantage of a poorly written firewall rule.
- A source IP address that is a private address. This eliminates traffic from an improperly configured Internet-based host or a spoofed address from a malicious person.
- A source IP address that is a loopback address. This eliminates traffic from a malicious person that is spoofing a loopback address to take advantage of a poorly written firewall rule.
- A source IP address that is a multicast address. This eliminates undesired multicast traffic. Note, care should be taken if multicast traffic is necessary for business purposes (i.e., load balancing).
- A source IP address that is a service or management network address. This eliminates a malicious person from gaining access to the service/management network from the public Internet. If access to the service/management is needed for IT personnel via the Internet, it should be done over a VPN or SSH.
- A source IP address from a region of the world that you do not do business with. Another valuable ingress filtering consideration that is gaining popularity is to either only allow traffic from specific regions of the world that your organization does business with, or to blacklist dangerous regions that your company prefers to not access its environment. For example, say your enterprise sells widgets, and they are only sold within the U.S. Why would your company ever accept traffic from any inbound connection that did not originate from the U.S.? Enterprises can dramatically reduce their organization's risk by filtering out unnecessary and likely malicious traffic. There are several free and subscription-based services that can be used to create access control lists for the border router.
Logging for ingress-filtered traffic should only include legitimate source IP addresses. If a source IP address is spoofed, your organization will not be able to trace it back to its real source anyway; it will just be wasting disk space and CPU cycles handling the log entries.
Securing your enterprise
The products available to secure enterprise VMware environments are abundant and expanding rapidly. Current third-party vendors that support VMware include but are not limited to:
- Altor Networks Inc. (a Juniper Networks Inc. company)
- Apani Networks Inc.
- Blue Lane Technologies Inc.
- Catbird Networks Inc.
- Cenzic Inc.
- Check Point Software Technologies Ltd.
- Cisco Systems Inc.
- F5 Networks Inc.
- Fortinet Inc.
- McAfee Inc.
- Palo Alto Networks Inc.
- Secure Computing (now Intel Corp.)
- Shavlik Technologies
- Sophos Ltd.
- Stonesoft Corp.
- Symantec Corp.
- Trend Micro Inc.
- Tripwire Inc.
- Webroot Inc
The goal of egress filtering is to take advantage of the highly efficient Layer 2 IP address filtering and Layer 3 port filtering capability of the border router to drop traffic leaving the network that has a high probability of being malicious, as well as to prevent inadvertent data leakage.
Organizations should start by dropping any outbound traffic that arrives at the internal-facing interface that meets the following criteria:
- A source IP address that is not an address within the internal network. This stops a malicious person within a company's environment from spoofing an external IP address as the source address. Simply put, traffic leaving your network with a source address that is not from your network is likely to be a malicious insider doing things they should not be doing. While there may not be a direct security benefit for your organization, blocking spoofed IP addresses from leaving your network makes your organization "responsible net-citizens."
- A source IP address that is not your email SMTP server (TCP 25) that is sending email. This eliminates a compromised internal system from being used as an email relay and potentially having your organization's IP address placed on an email spammer reputation blacklist.
- A destination port for an "internal use only" network service. This eliminates potential information leakage when typical Microsoft services such as MSRPC (TCP/UDP 135), NetBIOS (TCP/UDP 137-139), SMB (TCP 445) or other internal services such as TFTP (UDP 69), Syslog (UDP 514; if using SyslogNG or Rsyslog you should block the respective TCP port used) and SNMP (UDP 161-162) attempt to communicate with remote hosts.
- A destination port associated with known malicious services. This eliminates known malicious services such as IRC (TCP 6660–6669) from leaving the internal network. IRC historically has been a favored protocol for botnet communications to command-and-control servers.
Outbound ICMP considerations include:
- Blocking ICMP echo replies (Type 0 Code 0) to eliminate covert channel tools such as Loki from covertly sending data out of an organization.
- Blocking ICMP host unreachable (Type 3 Code 1) to eliminate the use of unsolicited echo reply packets from being used to map your network using host the unreachable messages for hosts that do not exist.
- Blocking ICMP time exceeded in transit (Type 11 Code 0) to eliminate the use of mapping tools, such as Firewalk, from being used to map your network.
Logging for egress-filtered traffic should include all dropped outbound traffic except internal-use-only services MS RPC, NetBIOS and SMB. Dropped outbound traffic could be an organization's first indicator of a compromised machine or wayward insider doing things they should not be doing.
If an organization has recently moved from physical servers to virtualization, it is likely that it already has physical firewalls in place to protect the formerly physical servers. So why not put these devices to good use in a layered defense with an air gap deployment in front of your organization's VMware infrastructure?
This makes sense; the security team is already up to speed on the firewall and the ongoing support and maintenance costs are generally reasonable. If your company followed the ingress and egress filtering recommendations at the border router above, it will have likely extended the life of the physical firewall by reducing its traffic load; this could facilitate additional future growth in traffic flow for your environment.
The firewall should be configured to fully support your organization's security policy. An enterprise will likely use VMware firewall technologies within the VMware infrastructure, but it will get additional defense in depth using the external physical firewall to complement the virtual firewalls within the VMware data center.
Lastly, an organization will achieve a significant reduction in common mode fault issues by using two different firewalls from different manufacturers that utilize different technologies and code bases. Further, a company will gain an additional air gap advantage of the physical firewall being outside of the virtual data center, meaning a compromise within the virtual data center could potentially still be blocked from the exfiltration of data using the external air gap physical firewall.
Considerations for the security of an enterprise's VMware data center begin outside of the virtual realm at its connection point to the public Internet. This gateway connection -- when protected by a properly configured border router using ingress and egress filtering and a physical firewall to complement the virtual firewalls within the virtual data center -- can afford significant security and performance benefits.
In the simplest of terms, an organization is dropping malicious traffic before it ever enters the virtual data center. It is also preventing malicious traffic and data from leaking out of the environment. The "juice is worth the squeeze" from a security perspective alone, but your enterprise also gets the performance benefit of the VMware firewalls within the virtual data center now looking at potentially less traffic (which is already dropped at the border router and physical firewall), which creates less CPU consumption by the host running the VMware firewalls internally, which equates to a higher density of virtual machines on that host.
About the author:
Paul Henry is a senior instructor with the SANS Institute and one of the world's foremost global information security and computer forensic experts with more than 30 years of experience covering all 10 domains of network security. Paul began his career in critical infrastructure/process control supporting power generation, and currently manages security initiatives and incident response for Global 2000 enterprises and government organizations worldwide. He is also a principal at vNet Security LLC, and serves as a retained security expert for multiple financial and healthcare firms.
Check out the latest virtualization security news and advice from SearchCloudSecurity.
Uncover the top virtualization security risks and how to mitigate them.