Data Center Security Topologies

Transcription

1 March, 2003 Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA Tel: NETS (6387) Fax:

2 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB s public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iquick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iq Expertise, the iq logo, iq Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0304R) Copyright 2004 Cisco Systems, Inc. All rights reserved.

3 CONTENTS 1 Topologies 1 Packet Filtering: Aggregation Layer 3 ACLs 3 Appliance Firewalls 4 Integrated Firewalls 6 Packet Filtering: Access Layer 7 Security for Multi-Tier Server Farms 8 Intrusion Detection Sensors 10 Network IDS: Aggregation Layer 10 Network IDS: Access Layer 11 Host IDS 12 I NDEX i

4 Contents ii

5 The Intranet data center has traditionally been an area where security deployments have been thinly implemented. Based on client surveys, growing security threats, and the increasing need to protect proprietary information; it is necessary to provide security to protect the data center from internally initiated attacks, whether malicious in nature or not. The security options discussed in this document include packet filtering and intrusion detection for network devices, servers, and applications. The goal of this document is to provide an overview and understanding of the security options available for the intranet server farm and provide topologies that and recommendations for each of these options. Topologies Figure 1 provides an overview of a large scale enterprise network. Figure 1also shows the location of the intranet data center in the network. In this topology, the intranet data center aggregation switches are directly connected to the campus core switches. There are no firewalls or IDS devices deployed between the data center switches and the campus core. The goal is to create security perimeters and domains for both the network devices and applications residing in this internal data center similar to the protection given to external (Internet) facing devices and systems. 1

6 Topologies Figure 1 Enterprise Network and Intranet Data Center PSTN SP1 Internet SP2 VPN Partners WAN Remote Office Internet Gateway Internet Edge DMZ Or Or Private WAN Internet Server Farm Extranet Data Center Corporate Infrastructure Campus Core Intranet Data Center The intranet data center aggregation layer provides a key location for deploying firewall and IDS services, along with a variety of other services including: content switching, SSL offloading, and VPN termination. In this architecture, the aggregation switches are in an active-standby (Layer 2-7) configuration. This means that the active aggregation switch is the spanning tree root, the Hot Standby Router Protocol (HSRP) active router, and active for content switching and other Layer 4-7 services. This document focuses on deploying both appliance and integrated packet filtering and IDS services at the data center aggregation layer to protect both data center infrastructure devices and servers. Additionally, this document also discusses supplemental security features that you can deploy at the data center access layer. 2

7 Packet Filtering: Aggregation Layer Packet Filtering: Aggregation Layer Packet filtering provides a means for blocking unwanted externally sourced or internally sourced network and application traffic. Packet filter services deployed at the intranet data center aggregation layer consists of ACLs, appliance-based firewalls, and integrated blade-based firewall modules. This section provides overviews of the three options. Figure 2 shows the location of the data center aggregation layer. Figure 2 Intranet Data Center Aggregation Layer Campus Core Data Center Aggregation Layer Front-end Layer Application Layer Database Layer ACLs ACL deployment in the data center is most beneficial for limiting access to and from devices (for example, subnet segregation) through basic Layer 3 and Layer 4 packet filtering. ACLs can be set to filter by port, but in most cases are not capable of providing upper-layer application protection. This is partially due to ACLs lack of support for stateful packet inspection, which is a key differentiator between ACLs and firewalls. Stateful packet inspection allows firewalls to perform packet by packet inspection on connection oriented requests, denying incomplete or malformed requests. 3

8 Packet Filtering: Aggregation Layer Appliance Firewalls In typical designs incorporating an appliance firewall, the firewalls are deployed inline between the data center aggregation layer and the core switches. This inline topology is sometimes deployed for Internet-facing data center designs, but is not necessarily optimal for the intranet data center for several reasons. If the firewalls are deployed inline as show in Figure 3, routing between the campus core and data center is limited to static routing. Figure 3 Appliance Firewall Deployment Campus Core This static routing requirement introduces redundancy issues, and also places limitations on the amount of deployable features available. With static routing deployed, any loss of upstream routes on the outside of the firewall is undetectable. If the upstream device or link fails, traffic is simply dropped by the firewall and the data center aggregation switch is completely unaware. Note Beginning with PIX software release 6.3, OSPF support was added, thereby eliminating the static routing limitation. For redundancy, the active and standby firewalls send and receive hello packets on the outside and inside interfaces respectively. On the inside interfaces, the hello packets are exchanged via the Layer 2 etherchannel configured between the data center aggregation switches. Because the outside interfaces must also exchange hello packets, a Layer 2 connection must be configured between the campus core switches. This outside Layer 2 connection configuration is not recommended because it brings Layer 2 into the core of the network and creates the possibility of a Layer 2 loop. 4

9 Packet Filtering: Aggregation Layer For companies interested in deploying disaster recovery or business continuance, the Content Switching Module (CSM) route health injection (RHI) feature plays an important role for the internal networks. This feature allows the CSM to place a host route for the virtual IP address (VIP) in the multi-layer switch feature card (MSFC), which is then propagated through out the network via the interior routing protocol. Without dynamic routing protocol support on the firewall, this route cannot be propagated from the data center switches to the campus core. If a static route is created as an alternative, traffic can be black- holed because the route does not disappear when the VIP becomes unavailable. As an alternative to deploying firewalls in front of the aggregation switches, you can deploy these firewalls on as services switches. Service switches connect to the aggregation switches through Layer 2 trunks. Instead of deploying devices that provide services like SSL offloading, content switching, and caching at the aggregation layer switches, you can connect these devices to the services switches. Two primary benefits of utilizing the services switches are port preservation on the aggregation switches and IOS restrictions on the aggregation switches. Specific versions of IOS must be used to support the desired switch modules, which may not integrate well with a strict change management system. In some cases, it can take six months to a year of testing to change software versions on core network devices. Moving this requirement from the data center aggregation switches to the services switches allows for faster deployment of these modules. Figure 4 Firewalls Deployed on Data Center Service Switches Campus Core When inbound traffic is received on the data center aggregation switch, a static route is used to forward the traffic over the Layer 2 links to the services switch. Figure 4 shows the location and connectivity of the services switches and their physical connection to the firewalls. The services switch has two Layer 2 trunk links, the active link connected to the Layer 2 active aggregation switch and a standby link (blocking) to the secondary Layer 2 aggregation switch. When traffic arrives on the services switch, it is forwarded to the outside interface of the firewall. The firewall then either blocks or forwards the traffic out of the inside interface back to the services switch. Because the firewall has both the outside and inside interfaces connected to the same switch, security concerns often arise. One of the primary concerns is that VLAN hopping may occur. VLAN hopping is the ability of an attacker to hop VLANs, therefore bypassing the firewall altogether. A recent series of tests performed on the Catalyst product 5

10 Packet Filtering: Aggregation Layer line were specifically directed at testing the vulnerability of VLANs in these found that when VLAN security configuration guidelines were properly followed, they were not able to hop or bypass VLANs on these switches utilizing a variety of well known attacks. The URL below provides a link to security document. 4fda.pdf Once again this design does not allow administrators to deploy RHI for the intranet data center. The fact that the CSM resides in the services switch and shares its client side VLAN with the inside interface of the firewall, renders the RHI feature unusable. The CSM client-side VLAN must reside on the MSFC for the VIP host route to be placed in the routing table. For additional information on RHI, see the additional links section at the end of this document. Integrated Firewalls The Firewall Services Module (FWSM) is an integrated firewall for the Catalyst 6000 series switches. The FWSM is configured similarly to a PIX firewall and therefore can be deployed to perform stateful packet inspection for both inbound and outbound traffic, as well as server to server communications. This module provides packet inspection at a 5 gigabit throughput rate and supports the OSPF dynamic routing protocol. Figure 5 shows the intranet data center aggregation switches with a pair of FWSMs. Figure 5 Data Center Aggregations Switches with FWSM Campus Core These previously mentioned features and upcoming features like firewall virtualization, make the FWSM a key element in redesigning security for the data center. A particular use is in designing and deploying security for the multi-tier server farm, which with the FWSM becomes much cleaner and easier to manage. This is detailed in the Security for Multi-Tier Server Farms section on page 8 of this document. 6

11 Packet Filtering: Access Layer The FWSM is deployed in the same chassis as the MSFC and can be placed either in front or behind the MSFC as shown in Figure 6. Also included in the Figure 6 is the respective location of the CSM. Figure 6 Logical Diagram of the FWSM, MSFC, & CSM with FWSM in Front and Behind the MSFC MSFC Outside MSFC Inside CSM CSM CSM CSM Data Center Aggregation Switch Data Center Aggregation Switch To prevent VLAN misconfiguration which may allow traffic to bypass the FWSM, you must pay close attention to which VLANs are configured on the outside and inside interfaces of the FWSM. The side of the MSFC where you place the FWSM is dependent upon the type of configuration you are trying to achieve. Note If you are deploying the RHI feature of the CSM, the FWSM should be placed on the outside of the MSFC. This is because the CSM must place a host route for the VIP in the MSFC and therefore must share a VLAN with the MSFC on the CSM's client-side VLAN. When various blades like the CSM, SSLSM, VPNSM, and IDSM are placed into the same chassis, configuration complexities arise. Software versions, VLAN configuration, and logical placement can all play important parts in interoperability of these modules. Packet Filtering: Access Layer You can deploy PVLANs and IOS ACLs or VLAN ACLs (VACLs) at the access layer to limit communication to, from, and between the servers residing in the server farm. The concept of PVLANs is simple: PVLANs offer a means of providing Layer 2 isolation of servers from other servers residing in the server farm. All traffic into the server farm passes through a primary VLAN. This primary VLAN is mapped to one or more secondary VLANs. The secondary VLANs can be configured as either isolated or community VLANs. Servers placed in isolated VLANs cannot communicate with any other servers in the server farm. Servers placed in community VLANs can only communicate with other servers also residing in the community VLAN. 7

12 Security for Multi-Tier Server Farms Figure 7 PVLANs Limit Server Communication Primary VLAN Primary VLAN Isolated Community Isolated Community Because PVLANs provide only Layer 2 isolation between servers, you must configure ACLs in Cisco IOS or on Cisco firewalls to deny any Layer 3 access as well. Traffic with a source address of a device residing in the server farm should not be allowed to also have a destination address of another device residing in the server farm. If this filtering is not put in place, there is a possibility that the packet could simply be routed at Layer 3 to the desired server therefore bypassing the Layer 2 isolation all together. PVLANs can be very beneficial for a number of reasons. If the servers in your data center house sensitive material, each one can be isolated on its own VLAN without wasting IP addresses. PVLANs also help to provide assurance that if one of the servers in your data center is compromised, the other servers cannot be reached at either Layer 2 or Layer 3. For additional information about Private VLANs, see the Deploying Private VLANS in the Data Center document. Security for Multi-Tier Server Farms Multi-tier (often referred to as Nth-tier) server farms consist of three primary tiers: presentation tier, application tier, and the database tier. Depending on the deployed application, the web tier and application tier can either reside on the same physical server or on separate servers. Most vendors have gone with a physical three tier model, where the web and application tiers reside on separate servers. This multi-tier architecture introduces a good deal of complexity into the data center architecture. In multi-tier architectures, security is often deployed for each tier. Filtering is recommended and should be performed in front of the presentation tier, between the presentation and application tiers, and between the application and database tiers. Packet filtering is also often performed between servers residing in the same tier as well. The packet filtering recommendations are dependent on the type of architecture deployed. For the physical multi-tier server farm, as stated above, Cisco recommends that you filter at each layer, which provides the maximum amount of security for the server farm. With the traditional appliance-based firewall, filtering at each layer requires a minimum of two firewalls at each tier. This in turn adds to the complexity of physical connections, management, and high availability. Figure 8 shows a typical multi-tier server farm architecture with appliance-based firewalls deployed at each tier. 8

13 Security for Multi-Tier Server Farms Figure 8 Appliance-Based Firewalls Providing Security for the Multi-Tier Server Farm Campus Core First Tier Web Tier Second Tier Application Tier Third Tier Database Tier The FWSM provides an excellent option for reducing the complexity of deploying security in a multi-tier architecture. By consolidating the firewalls in a central location, management and physical connectivity issues are dramatically reduced. Note The logical topology is the same regardless of the physical topology. You can configure separate VLANs on the FWSM for each layer with routing and packet filtering performed between each tier. This allows all traffic between VLANs to pass through the FWSM, therefore centralizing packet filtering services on a single physical pair of firewalls. Future software releases for the FWSM will support a firewall virtualization feature. This feature allows a single FWSM to be virtualized into multiple logical firewalls. This virtualization allows you to create separate logical firewalls per tier, and, if desirable, per customer. Figure 9 shows the multi-tier server farm with the FWSM. 9

14 Intrusion Detection Sensors Figure 9 FWSM Providing Security for the Multi-Tier Server Farm Campus Core FWSM with Multi-Firewall Virtualization Web Tier Application Tier Database Tier Intrusion Detection Sensors Network IDS: Aggregation Layer Network IDS devices should be deployed at the data center aggregation switches to provide a comprehensive level of protection for the data center network devices and a first level of protection for server farm components. These network IDS sensors can be logically configured to reside behind the firewall modules also deployed in the aggregation switches. This allows the sensor to shun network attacks that were not filtered while passing through the firewall. When deployed in the aggregation switches, you should configure the network IDS sensors to monitor synchronous traffic flows. This allows the sensor to see both portions of the traffic flow, which in turn lowers the amount of false positives and false negatives the sensor reports if only allowed to have a one-sided view of the flow. The network IDS devices are capable of shunning network attacks through proactive manipulation of ACLs. When configured policies are violated, and the attack signature is 10

15 Intrusion Detection Sensors matched, the IDS device can dynamically configure ACLs to shun the attack before it is able to compromise any servers or devices. Figure 10 provides an overview of network IDS deployment in the data center. Figure 10 Network IDS in the Data Center Campus Core Aggregation Layer Network IDS Monitoring Synchronous Traffic Flows Outbound Traffic Inbound Traffic Data Center Aggregation Switches Outbound Traffic More granular server and application specific monitoring Acc Net Mo Synch Asynch Inbound Traffic Because of the possibility of heavy traffic flowing through the data center, Cisco recommends that you deploy a gigabit capable IDS device. An IDS with gigabit throughput capabilities is able to monitor greater amounts of traffic through the data center, increasing the level of security. Currently, the IDS 4250 appliance IDS device is capable of providing gigabit monitoring capabilities. In the near future, a gigabit capable IDS module for the Catalyst 6000 will be available. Functionality of these devices is very similar and therefore, regardless of which is used, the same recommendations on what types of traffic to monitor and where will be maintained. Network IDS: Access Layer IDS sensors can also be deployed at the data center access layer. This can provide an optional additional layer of security for the network devices and servers. At the access layer, the sensors should be configured to monitor both synchronous and asynchronous traffic originated from the server farm. Synchronous traffic monitoring is performed at a more granular level for server and application traffic. Additionally, Cisco recommends that you monitor server initiated asynchronous traffic that. If an attacker is able to compromise a server and begins to launch an attack initiated from the internal server farm, the network IDS sensor in the access switch is able to monitor and shun the attack, thereby protecting other internal systems from being compromised. 11

16 Intrusion Detection Sensors Two options are also available for deploying network IDSs at the data center access layer. For both Catalyst 6000 and other install bases, the gigabit appliance IDS sensors are available. For access layers consisting of Catalyst 6000 series switches only, the gigabit intrusion detection sensor module (IDSM) will be available in the near future. Host IDS Cisco's Host IDS solution provides blanket coverage for the server operating system and to the applications running on the server. The Host IDS agent software is loaded onto the server platform and monitored from a central management station. Currently the server operating systems supported are: Windows 2000, Windows NT, and Sun Solaris. The Host IDS sensor shuns attacks by actively monitoring traffic to the server and stopping an attack before it is allowed to execute. Figure 11 HIDS for the Server Farm Host IDS Campus Core Server OS and Application Protection Firewall While the network IDS upstream protects against network and some server and application attacks, the Host IDS sensor protects against different types of malicious attacks, such as: OS and application vulnerabilities Uploading malicious executables Information gathering Sniffer installation Password attacks Buffer overflows 12

17 INDEX 6 A ACLs 3 appliance-based firewall 3 B buffer overflows 12 C caching 5 content switching 2, 5 Content Switching Module see CSM CSM 5 I IDS IDS device 1, 11 IDSM 7, 12 integrated blade-based firewall modules 3 Intrusion Dectection Sensor Module see IDSM intrusion detection sensors 12 IOS ACLs 7 L Layer 2 isolation 8 M MSFC 5 Multi-layer Switch Feature Card see MSFC F firewalls 1 firewall virtualization feature 9 FWSM 6 H host IDS 12 Hot Standby Router Protocol see HSRP HSRP 2 N Nth-tier 8 O OS and application vulnerabilities 12 OSPF 4 P packet filter service 3 password attacks 12 13

18 Index PIX 4 PVLANs 7 R RHI 5, 7 route health injection see RHI S sniffer installation 12 SSL offloading 2, 5 SSLSM 7 Sun Solaris 12 synchronous monitoring 11 U uploading malicious executables 12 V VACLs 7 VLAN hopping 5 VPNSM 7 VPN termination 2 W Windows Windows NT 12 14