Defending the data center

© 2009 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKSEC-2205 1

In the Headlines…Security Is Still Very Relevant


Where Are We Now?

Securing virtualized environments is a big concern

We are still early in virtualization adoption

Two forms of virtualization we are discussing. Both apply to the Data Center

Server virtualization

Device virtualization

Security requirements shouldn’t change with virtualization


Data CenterCore

VM VM VM

VMVMVM

Data Center Services Layer

Virtual Access

Access Layer

Data Center Aggregation Layer

Virtual Infrastructure

Services

Top of Rack/End of Row

Aggregation/Distribution

Data Center Terms


Data Center Security Challenges

Virtualization

Applications

Data Loss

Compliance

Availability


Stateful Packet FilteringAdditional Firewall Services for Server Farm specific protection

Server Load BalancingServer Load Balancing masks servers and applications

Application FirewallApplication Firewall mitigates XSS, HTTP, SQL, XML based attacks

Network Intrusion PreventionIPS/IDS: provides traffic analysis and forensics

Flow Based Traffic AnalysisNetwork Analysis for traffic monitoring and data analysis

XML based Application ControlXML Gateway to protect and optimize Web-based services

Stateful Packet FilteringInitial filter for all DC ingress and egress traffic. Virtual Context allow correlation to Nexus VDC.

Network Foundation ProtectionInfrastructure Security features are enabled to protect device, traffic plane, and control plane. Device virtualization provides control, data, and management plane segmentation

Data CenterCore

VM VM VM

VMVMVM


Virtual Access

Access Layer

Enhanced Layer 2 SecurityAccess List, Dynamic ARP Inspection, DHCP Snooping, IP Source Guard, Port Security, Private VLANs, QoS

Endpoint securityHost intrusion prevention protect server against zero day attacks

Layer 2 Flow MonitoringNetFlow, ERSPAN, SPAN


•Visibility•Even Correlation

HIPS, Firewalls,IPS, Netflow, Syslog

•Forensics•Anomaly Detection•Compliance

CSM CS-MARS

Security Management

Addressing theChallenges


Data Center: Aggregation


Device Virtualization:Nexus 7000 Virtual Device Contexts

Up to 4 separate virtual switches from a single physical chassis with common supervisor module(s)

Separate control plane instances and management/CLI for each virtual switch

Interfaces only belong to one of the active VDCs in the chassis, external connectivity required to pass traffic between VDCs of the same switch

VDCs


Cat6k Cat6k

N7k2-VDC1

N7k2-VDC2

N7k1-VDC1

N7k1-VDC2

Po99

vrf2 vrf1vrf1 vrf2

10.8.0.x/24.2

10.8.2.x/24

10.8.3.x/24

.1.1 .1

.2.2(SVI 3) .2.1 (SVI 3)

Po99

10.8.162.3/24 10.8.162.2/2410.8.152.3/24 10.8.152.2/24

RID:8.8.8.1 RID:8.8.8.2

RID:4.4.4.1 RID:4.4.4.2RID:5.5.5.1 RID:5.5.5.2

RID:3.3.3.1 RID:3.3.3.2

10.8.152.5 10.8.152.6 10.8.162.610.8.162.5

Aggregation Layer with VDCs

Outside Virtual Device Context

InsideVirtual Device Context


Cat6k Cat6k

N7k2-VDC1

N7k2-VDC2

N7k1-VDC1

N7k1-VDC2

OSPF NSSA Area 81

Po99

OSPF Area 0

vrf2 vrf1vrf1 vrf2

10.8.0.x/24.2

10.8.2.x/24

10.8.3.x/24

.1.1 .1

.2.2(SVI 3) .2.1 (SVI 3)

Po99

10.8.162.3/24 10.8.162.2/2410.8.152.3/24 10.8.152.2/24

RID:8.8.8.1 RID:8.8.8.2

RID:4.4.4.1 RID:4.4.4.2RID:5.5.5.1 RID:5.5.5.2

RID:3.3.3.1 RID:3.3.3.2

10.8.152.5 10.8.152.6 10.8.162.610.8.162.5

Control and Segmentation

Control Routing Propagation

Example: inject only default route to internal VDC

Traffic between VDCs must be routed or bridged via external

Access controlled to inside and outside contexts


Aggregation Security Features

CoPP

Protect the supervisor from DoS attacks preventing outages. Prevent Layer 2 broadcast storms and irrelevant traffic redirections to CPU

Broadcast Suppression

Protects the data center against broadcast storms at the port level that pose risks to bandwidth availability

Packet Sanity Checks

Forwarding engine performs extensive checks on IPv4 and IPv6 packet headers to protect the network from illegal packets.

LinkSec

Wire-rate link-layer cryptography is provided at all ports. Packets are encrypted on egress and decrypted on ingress so they are clear inside the device.


Control Plane Policing (CoPP)

The Control-Plane is critical to network operation. DoS attack targeting the Control-Plane can be devastating to the network stability and availability leading to business-impacting network outages

A Denial of Service (DoS) attack to Control/Management Plane, which can be perpetrated either inadvertently or maliciously, typically involves high rates of traffic that result in excessive CPU utilization

Nexus 7000

CoPP is a hardware-based feature that protects the Supervisor from DoS attacks

It achieves this by controlling the rate at which packets are allowed to reach the Supervisor

Linecard

FELinecard

FETransit Packets

Transit Packets

Layer 2 Protocols Layer 3 ProtocolsVLAN

PVLANOSPFBGP

EIGRP

GLBPHSRPIGMP

UDLDCDP

802.1XSTPLACP PIMCTS SNMP

……

Control Plane

Supervisor

Logic Representation of the Fabric Modules



NX-OS provides a default policy that can be set when the system is first brought up.

One of the following CoPP policy options can be chosen from of the initial setup script:

Strict: ~11Kpps CIR

Moderate: the PIR is 25% higher than the CIR of the strict default policy

Lenient: the PIR is 50% higher than the CIR of the strict default policy

None: no control plane policy is applied

If the initial configuration script is skipped, NX-OS will apply the strict policy. Obviously the policy can be later tuned/modified.

CoPP supports IPv4, IPv6, ARP and MAC ACLs and it is able to match on packets generating exceptions and redirections

The rate in the policy-map can be configured as packet per second (pps), however the statistics will still be shown in bytes per second (bps)

Nexus 7000



The CoPP supports the same QoS statistics as any other interface

It will show the stats of the class forming the service policy for every Forwarding Engine

An interesting feature, in terms of stats, is the possibility to see the hits for each ACE in the ACL matched by the class-map. This helps narrowing down the origin of the attack. Just remember to enable the stats in the ACL:

DC3(config)# ip access-list my-acl

DC3(config-ip-acl)# deny udp any any

DC3(config-ip-acl)# permit ip any any

DC3(config-ip-acl)# statistics


Broadcast Suppression

High volumes of broadcast traffic can impact bandwidth availability and impact network performance – so a way to limit this traffic type is required

Traffic Storm Control allows controlled amount of “storm” traffic to be forwarded out a target port as a percentage of the total bandwidth of the port

The switch monitors outgoing “storm” traffic at 1 second intervals comparing the volume of storm traffic with the configured level that this port can forward

Traffic in excess of the configured limit is dropped

The suppression mechanism is the same on both 1G and 10G linecards

Double digit granularity

DC3# config tDC3(config)# int e 2/24DC3(config-if)# storm-control broadcast level 25.16


Packet Sanity Checks Nexus Forwarding Engine performs Sanity checks on the header fields of IPv4

packets.

Nexus Packet Sanity checks protect the network and the system from “illegal” packets.

The IP sanity checks are enabled by default and can be individually disabled. The packets failing the Sanity checks will be dropped and a counter will be kept.

Checks on IPv4 packets: IPv4 checksum IP header length minimum Ethernet Frame length minimum Fragment length maximum Unexpected fragment IP version UDP length maximum TCP length maximum TCP tiny fragment Broadcast Source IP Address Reserved IP Addresses Identical IP Dst & Src Address Destination IP Address is zero Source IP is a Class D Address Class E Src or Dst IP

Nexus# show hardware forwarding ip verify

IPv4 IDS Checks Status Pkt-----------------------------+---------+------address source broadcast Enabled 0 address source multicast Enabled 0 address destination zero Enabled 0 address identical Enabled 0 address source reserved Enabled 0 address class-e Disabled 0 checksum Enabled 0 protocol Enabled 0 fragment Enabled 0 length minimum Enabled 0 length consistent Enabled 0 length maximum max-frag Enabled 0 length maximum udp Enabled 0 length maximum max-tcp Enabled 0 tcp flags Disabled 0 tcp tiny-frag Enabled 0 version Enabled 0

Nexus(config)# platform ipv4 verify


Nexus ACLsKey Points

Verify-Commit programming paradigm for better usability and manageability

Atomic configuration update with no traffic interruption for continuous operations

Selective hardware programming for better scalability and resources utilization

ACL syntax improvements for better usability and manageability:• Slash notation for IP addresses• No standard/extended and named/numbered ACLs

Support for Object groups, Time-ranges and Re-sequencing

ACL-based Features: RACLs, VACLs, PACLs and PBR...

ACLs Matching: Layer2, Layer3 and Layer4 header fields (usingIPv4, ARP and MAC access lists)


Additional Nexus 7000 Tidbits

Virtualization support

AAA configuration and operation are local to the VDC.

AAA authentication methods for the console login only apply to the default VDC.

AAA accounting log is on per VDC basis

Role Based Access

Four default roles

Network-admin

Permission to create/delete/assign resources to VDC.

Can create other roles and users.

Network-operator

Permission to run show command across all VDCs.

VDC-admin

Permission to manage a VDC, create other VDC roles and users

for that VDC.

VDC-operator

Local to a VDC and has show command privilege


Data Center: Security Services(and Others)


Security Services

Data CenterCore

VM VM VM

VMVMVM

Virtual Access

Access Layer



Security Service Integration

Deploy security services and appliances as transparently as possible.

Maintain predictable traffic flows to ensure availability

Need to think about scalability of current infrastructure when planning designs.

Create Security Zones based on Trust

Minimal impact to allowed functions while maintaining

Enforcement, Isolation, Visibility

Business model, compliance, applications, can all drive policy

One model does not fit all but there are some design guidelines we can provide


Security Services

N7k2-VDC2N7k1-VDC2

ASA1

ACE2

ASA2

ASA2ASA1

ACE

SVI-161

SVI-151SVI-151

SVI-161

vrf2 vrf1vrf1 vrf2 Po99

Po99

10.8.162.3 10.8.162.2

10.8.152.3 10.8.152.2

hsrp.1

hsrp.1

hsrp.7 hsrp.7

10.8.162.5 10.8.162.610.8.152.610.8.152.5

IPS

162

162

161

152

151

WAF

190

IPS

WAF

164


ASA Physical Connections

Redundant physical chassis provide virtual platform

Physical interfaces allocated to independent VDCs

Fault tolerance and state VLANs leverage VDC2 Po99

ASA5580-1

ASA5580-2

Nexus7000

Nexus7000

Eth2/3

VLAN 172

Eth2/1

Eth3/0

Po99VLAN 171

Eth2/3

VLAN 172

Eth2/1

VLAN 171

Eth3/1Eth3/1

Eth3/0

VLAN 172 – State VLAN

VLAN 171 – Failover VLAN


N7k1-VDC2

ASA2

ASA1

ACE

SVI-161

SVI-151

vrf1 vrf2

10.8.162.3

10.8.152.3

hsrp.1

hsrp.7

10.8.162.5 10.8.152.5IPS

162

162

161

163,164

WAF

190

SS1

164

Security Services

ASA Stateful Firewall

Virtual Contexts

Transparent mode

ACE LB

Transparent mode

Web Application Firewall

Firewall farm

Network IPS/IDS

Inline or promiscuous

Transparent Services Are “Sandwiched” between Nexus VDCs


Examples


SS1 SS2

Virtual Context on ASA for ORACLE DB Protection

ACE2ACE1

IPS1 IPS2

163,164 163,164

162

163

164

N7k2-VDC2N7k1-VDC2

vrf1vrf1 Po99

hsrp.1 hsrp.110.8.141.3 10.8.141.2

ASA2-vc3ASA1-vc3

141 141

Oracle DB

142 142

E2/37 E2/37E2/38 E2/38

E3/2

E3/3

E3/2

E3/3

Bond142: 10.8.141.151


Example of Server to Database access through virtual firewall context.

N7k2-VDC2N7k1-VDC2

vrf1vrf1 Po99

STP roothsrp.1

ASA2-vc3ASA1-vc3

VLAN 141 VLAN 141

Oracle DB

VLAN 142 VLAN 142

E2/37 E2/37E2/38 E2/38

Bond142: 10.8.141.151

Srv-A


WAF Incidents Showing Attack


WAF Event Viewer Attack Details


Using ACE and WAF to Maintain Real Client IP Address as Source in Server Logs


Server Logging

Session persistence maybe maintained via HTTP header insertion

ACE LB and Web Application Firewall support this functionality


Access Layer


Data Center Physical Access Layer

The physical data center access layer is fairly well understood.

The features and design options at this layer have evolved through the use of virtualization

Security features for the access layer have been available and deployed for quite some time

A few highlights for the physical access layer before we look at Virtual Access…


VM VM VM

VMVMVM

Virtual Access

Access Layer

Data CenterCore



Data Center Access Layer

Data Center Access


Security Considerations

In many cases server tiers/clusters are separated by VLANs

Servers are often Layer 2 adjacent

Must allow for mobility

DR

Maintenance

Security is key in maintaining availability of servers and applications connected here.


Make Use of Switch Security Features

Anti-spoofing features

Dynamioc ARP Inspection, IP Source Guard, DHCP Snooping

STP protection (BPDU Guard)

QoS

Broadcast Packet Suppression

PVLANs

Access Lists

SPAN, ERSPAN, NetFlow


Virtual Access and Security


Server Virtualization

Benefits of Virtualization

Power savings

Consolidation of resources

Server portability

Application failover

Uplink Ports

Virtual Ethernet (vnet) Adapters

Uplink Ports

Physical Adapters



Hypervisors: Type 1 or Type 2

Type 1 hypervisors as shown below are built into a pre-hardened host. There is no distinct boundary between the host operating system and the hypervisor.

Type 2 hypervisors as shown below are installed as separate software on top of the existing host operating system

Primary role of the host OS or hypervisor is to work with the VMM to coordinate access to the physical host system's hardware resources (CPU, Device Drivers, etc)

Theoretically the hypervisor should have fewer security vulnerabilities because it runs minimal services and contains only essential code BUT maintaining security updates is still important!


Server Virtualization Security Concerns

Secure HypervisorMitigate risk towards the hypervisor

an attacker gaining unauthorized access to the hypervisor and taking control of the physical server and related virtual servers

Rogue VMsHas a guest operating system been compromised?

Virtual Server Mobility

Inter-VM traffic visibility and securityTraffic between two virtual machines can flow across the bus inside the hosting physical server and not be required to be switched on an external network where traditional tools can be used

VMware “virtual switch” lacks security features available in Cisco switching platforms

Shared File system between VMsVMFS and VMotion

Consolidated SANs or NAS attached storage

vnet adapters

Uplink Ports

Physical Adapters


vnet adapters

Uplink Ports

Physical Adapters

Securing the Hypervisor…

Hypervisor has access to all resources

Manages all system resources

Manages LAN & SAN access

vSwitch lacks “standard” network functions

No visibility into VM-to-VM traffic on a port group

No visibility into VM-to-Hypervisor calls

!!!!

!!

!!


vnet adapters

Uplink Ports

Physical Adapters

Virtual Machine LAN Security

Be aware of security affinities

Would you place all your applications on the same VLAN?

Challenging troubleshooting & monitoring environment

Recommendation: Do not consolidate servers with unlike security affinities onto a single VLAN

DMZ Web Server

Application Servers

Database Server

!! !!

!!


Virtual Machine VMotion Security

VMotion enables workload mobility & Disaster Recovery

Increases server utilization efficiency by balancing workloads between servers

VMs can move between ESX cluster members with the same configuration

Port-groups, VLANs, etc

Inconsistent security policies enforcement and visibility

Policies applied at the server port or VLAN cannot be consistently applied

Vmotion traffic sent in clear text. Take precautions for isolating

vnet adapters

Uplink Ports

Physical Adapters

vnet adapters

Uplink Ports

Physical Adapters

ESX Cluster

.11 .13

Permit .11 <-> .12Deny .11 <-> .13Deny .12 <-> .13

X

.12


Virtual Machine Exploits

Several Theoretical Exploits

Gain Control of the Hypervisor

Exploiting vMotion

Reconnaissance: Virtual Machine Detection

VME artifacts

Malware that detects virtual machines

Tools: (The Red Pill, Scoopy & Doo, VMDetect, etc)

Virtual machine-based root kits

Theoretical attacks are interesting but lets focus on the simple things that cover 99% of the issues. Most people don’t even have the simple items covered!

Lets worry about this before we worry about theoretical Hypervisor attacks.


Things to Ponder…

Traditional Security Problems Unchanged

Security Policies still need to be enforced

Virtualization introduces some new flavors

Hypervisor is a new layer of privileged software

Potential loss of separation of duties

Limited visibility into inter-VM traffic

So What’s the Secret Ingredient?


There Is NO Secret Ingredient!

Security best practices still apply!

If you would not do it on a non-virtualized server, you probably should not do it on a virtualized server.

But we can address the virtualization concerns…


Physical Access Switch

Integrated Nexus 1000V Virtual Switch

Merging Physical to Virtual Infrastructure


Virtual Access Fabric: Nexus 1000V

Nexus VSM

Nexus VEMs

DC-5020-1 DC-5020-2

VSS-ACC

N7k1-VDC2 N7k2-VDC2

APC w/src-mac

hash

Po71

Po72

Po1 Po2 Po3

Po151

TrunkingUplinks

ESX4

vSwitch


Nexus 1000V Key Features

Includes Key Cisco Network and Security features

Addressing Issues for:

VM Isolation

Separation of Duties

VM Visibility


Separation of Duties: Network and Server Teams

A network feature macro

Example: Features are configured under a port profile once and can be inherited by access ports

Familiar IOS look and feel for network teams to configure virtual infrastructure

PromiscuousPort

10.10.10.10 10.10.20.2010.10.30.30

port-profile vm180 vmware port-group pg180 switchport mode access switchport access vlan 180 ip flow monitor ESE-flow input ip flow monitor ESE-flow output no shutdown state enabled interface Vethernet9 inherit port-profile vm180 interface Vethernet10 inherit port-profile vm180

port-profile vm180 vmware port-group pg180 switchport mode access switchport access vlan 180 ip flow monitor ESE-flow input ip flow monitor ESE-flow output no shutdown state enabled interface Vethernet9 inherit port-profile vm180 interface Vethernet10 inherit port-profile vm180

Port Profiles


Separation of Duties: Network and Server Teams1. Nexus 1000V automatically enables port groups in Virtual Center via API

2. Server Admin uses Virtual Center to assign vnic policy from available port groups

3. Nexus 1000V automatically enables VM connectivity at VM power-on

Workflow remains unchanged


VMotion

1. Virtual Center kicks off a VMotion (manual/DRS) & notifies Nexus 1000V

2. During VM replication, Nexus 1000V copies VM port state to new host

3. Once VMotion completes, port on new ESX host is brought up & VM’s MAC address is announced to the network

Mobile Properties Include:

Port policy

Interface state and counters

Flow statistics

Remote port mirror session

vnet adapters

Uplink Ports

Physical Adapters

vnet adapters

Uplink Ports

Physical Adapters

VMotion


Community

VLAN

Isolated VLAN

PromiscuousPort

VM Isolation: Cisco Private VLANs

Private VLANs provide layer 2 isolation for hosts in the same subnet

Traditional Cisco PVLANs are supported: Isolated & Community ports

Physical Infrastructure is PVLAN aware. You can carry PVLAN to physical devices ie: FWSM


PromiscuousPort

10.10.10.10

10.10.10.1

10.10.20.20

10.10.20.20

dcvsm(config)# ip access-list deny-vm-to-vm-trafficdcvsm(config-acl)# deny ip host 10.10.10.10 host 10.10.20.20dcvsm(config-acl)# permit ip any any

VM Isolation and Traffic Control

Port ACLs

Limit VM to VM traffic flows

Enforce the way you enforce between physical servers today

Use in conjunction with VLANs, PVLANs


PromiscuousPort

10.10.10.10 10.10.20.20

192.168.20.0

Isolating Production and Management Traffic

Isolate management traffic from production

Enforce physical separation and virtual separation

dcvsm(config)# ip access-list deny-vm-traffic-to-service consoledcvsm(config-acl)# deny ip 10.10.0.0 192.168.20.0dcvsm(config-acl)# permit ip any any


PromiscuousPort

10.10.10.10 10.10.20.20

ip arp inspection vlan 180!ip arp inspection filter staticIP vlan 180arp access-list staticIP permit ip host 10.10.10.10 mac host 00:50:56:87:18:2d permit ip host 10.10.20.20 mac host 00:50:56:87:18:3d permit ip host 10.10.30.30 mac host 00:50:56:87:18:4d!errdisable recovery cause arp-inspectionerrdisable recovery interval 120! switchport access vlan 180 switchport mode access ip arp inspection limit rate 100

ip arp inspection vlan 180!ip arp inspection filter staticIP vlan 180arp access-list staticIP permit ip host 10.10.10.10 mac host 00:50:56:87:18:2d permit ip host 10.10.20.20 mac host 00:50:56:87:18:3d permit ip host 10.10.30.30 mac host 00:50:56:87:18:4d!errdisable recovery cause arp-inspectionerrdisable recovery interval 120! switchport access vlan 180 switchport mode access ip arp inspection limit rate 100

10.10.30.30

Anti-Spoofing

Protection against man-in-the middle attacks

Dynamic ARP Inspection, DHCP Snooping, IP Source Guard


Services

IDS1Network Analysis Module

ERSPAN DST

ID:1ID:2

VM to VM Visibility

ERSPAN source requires use of ERSPAN destination

Only one IP address associated with the ERSPAN source/destination per switch

ERSPAN ID provides segmentation

Permit protocol type header “0x88BE” for ERSPAN GRE

ERSPAN frame considerations:

ERSPAN does not support fragmentation

Appends 50 Byte header to frame

Default 1500 MTU allows for 1468 byte frames

Max frame size supported 9,202 bytes

ERSPAN


ERSPAN

Nexus 1000 ConfigurationNexus 1000 Configuration

port-profile erspan capability l3control vmware port-group switchport access vlan 3000 no shutdown system vlan 3000 state enabled!monitor session 1 type erspan-source description - to SS1 NAM via VLAN 3000 source interface Vethernet8 both destination ip 10.8.33.4 erspan-id 1 ip ttl 64 ip prec 0 ip dscp 0 mtu 1500 no shutmonitor session 2 type erspan-source description - to SS1 IDS1 via VLAN 3000 source interface Vethernet8 both destination ip 10.8.33.4 erspan-id 2 ip ttl 64 ip prec 0 ip dscp 0 mtu 1500 no shut

port-profile erspan capability l3control vmware port-group switchport access vlan 3000 no shutdown system vlan 3000 state enabled!monitor session 1 type erspan-source description - to SS1 NAM via VLAN 3000 source interface Vethernet8 both destination ip 10.8.33.4 erspan-id 1 ip ttl 64 ip prec 0 ip dscp 0 mtu 1500 no shutmonitor session 2 type erspan-source description - to SS1 IDS1 via VLAN 3000 source interface Vethernet8 both destination ip 10.8.33.4 erspan-id 2 ip ttl 64 ip prec 0 ip dscp 0 mtu 1500 no shut


ERSPAN – IDS and NAM

Comprehensive view of VM traffic via ERSPAN to two network analysis devices simultaneously

NAM and IDS provide clarity. In this example, port scan of VM detected on IDS and visible on NAM


Example: Using ERSPAN to IDS for VM to VM Traffic

ERSPAN DSTIP: 10.8.33.4

10.8.180.230

Services

IDS1Network Analysis Module

ID:1ID:2

10.8.180.234


Out-of-BandNetFlow Collector

In-BandNetFlow Collector

VM to VM Visibility

N1k requires Netflow source interface

Defaults to Mgmt0

Support v9 format

NetFlow


NetFlow

Maximum of one flow monitor per interface per direction is permitted

Maximum of two flow exporters per monitor are permitted

Port profiles afford easy deployment

flow exporter exporttest

description exportv9

destination <IP ADDRESS> use-vrf management

transport udp 3000

source mgmt0

version 9

template data timeout 1200

option exporter-stats timeout 1200

flow monitor NAMTest

description default flow to NAM

record netflow-original

exporter exporttest

timeout inactive 600

timeout active 1800

cache size 15000

port-profile vm180

vmware port-group pg180

switchport mode access

switchport access vlan 180

ip flow monitor NAMTest input

ip flow monitor NAMTest output

flow exporter exporttest

description exportv9

destination <IP ADDRESS> use-vrf management

transport udp 3000

source mgmt0

version 9

template data timeout 1200

option exporter-stats timeout 1200

flow monitor NAMTest

description default flow to NAM

record netflow-original

exporter exporttest

timeout inactive 600

timeout active 1800

cache size 15000

port-profile vm180

vmware port-group pg180

switchport mode access

switchport access vlan 180

ip flow monitor NAMTest input

ip flow monitor NAMTest output


Protect the Endpoint

Host Posture & Event Information

Cisco Security Agent Host IPS

Network IPS

CSAManagement Center

SDEEHost Posture &

Quarantine Events

VM Guest OS Protection

A host is quarantined manually by a Cisco Security Agent MC administrator or rule-generated by global correlation

Quarantine events include

the reason for the quarantine

the protocol associated with a rule violation (TCP, UDP, or ICMP), an indicator on whether a rule-based violation was associated with an established TCP connection or a UDP session

the IP address of the host to be quarantined.

Host IPS and Integration with Network IPS


Remember…

Security best practices still apply

Limit Data Flow to other servers and resources

Do not use non-persistent disks

Harden the Host OS, Hypervisor, & Guest OS

Use AV, maintain patches and updates

Consider using a HIPS solution


Takeaways

Device Virtualization

Scale use of network and security components

Flexible integration options

Can get complicated…plan accordingly


Secure virtual machine environment

Use features to maintain visibility

Ensure Separation of Duties is maintained

Don’t do what you wouldn’t do on a physical machine


Key Threats Mitigated


Additional Resources

Data Center Design Zone

http://www.cisco.com/go/designzone

Defending the data center

Technology

Transcript of Defending the data center