He writes about “the VLAN leaking myth” and how it encourages clients to utilize physically separate network infrastructure in the DMZ’s. Now first things first, I wouldn’t call VLAN leaking a myth. At one time it was a very real and serious vulnerability that was exploited by overflowing the capacity of the switch you were attacking, and causing it to “downgrade” from switch to a hub. Once this happened you now had access to previously protected devices, as well as having the ability to sniff data as it passed through the shared hub backplane.

As he mentions though, this is 8 years ago. Most switches have evolved to the point where backplanes far exceed the traffic that could ever be injected into their switchports. Even beyond backplane enhancements there are many ways to further firm up your security stance – Virtual Device Contexts, not using Layer 3 SVI’s on a DMZ VLAN, utilizing PVLANs, using port security, virtual routing instances, and many more. Of course, there are still many other attack vectors that still remain, but can be mitigated by utilizing features built into the majority of enterprise switches available today.

I think the real question is not “are VLANs safe in a DMZ”. The important question is have you mitigated the probability of compromise (the actual threat) to levels that are acceptable to your business. This question remains whether you have a standalone switch or not. So many times we hear about risk risk and more risk. But risk alone is meaningless in a business context. What is important is combining risk with likelihood. For that I like to use a simple table to come up with the true threat.

For example, as I drive to Fry’s there is the risk of me dying due to a car crash. The impact of me dying is very high (risk) however the likelihood of an accident is low, and furthermore I reduce (mitigate) the latent risk (threat) by wearing my seat belt. So all in all the threat of me dying on my way to Fry’s is pretty darn low.

In a business context this may be that I have public facing web servers and network devices in my DMZ. The impact of them being compromised is that my public image may be tarnished for a short time, and my end users may lose productivity if they are not able to VPN into work, or access the Internet while on premise. I mitigate this risk by using firewalls and both host and network based Intrusion Prevention Systems as well as implementing best security practices on my network and systems devices. The latent risk (threat) remaining is at a level that is acceptable to the business leaders, so the system is allowed.

One question that I have seen coming up more often as we move towards fully virtualized data centers is centered around commingling of virtual infrastructure. There are some hard questions which challenge some practices that we have held true over the years.

• Should you allow sharing of physical memory on a host virtual machine between an internal and DMZ server?
• Should you allow virtual infrastructure from multiple security zones to share a storage array or cluster of arrays?
• Should you allow multiple virtual switches in different security zones commingling on the same ESX or Hyper-V cluster?
• Should you allow virtual firewall and load balancing instances protecting internal and external zones to reside on the same hardware?
• Should you allow virtual routing instances from multiple zones to share a physical infrastructure?

In the past world of standalone systems, the additional cost of providing a wholly separate infrastructure for DMZ environments was relatively low. Each system generally had internal disk, or at most direct attached storage. Network devices themselves were scaled down to support one chassis one function. This fit quite neatly into the Enterprise Composite Network model that was quite common from 1999-2003.

Now, many data centers have moved to the Service Oriented Network Architecture (SONA). In this model the cost of a virtualized data center is primarily focused on foundation elements such as the virtual storage and virtual fabrics, virtualized network, and virtual systems elements. The cost of providing additional virtualized services off these elements is low, however the cost of duplicating the physical infrastructure is quite high on both the capital and operational levels. This is forcing the technical and executive leadership at many companies to take a long hard look at the true threats they are facing in previously physically separate security zones such as DMZ’s, Financial and other secure zones. In the end, they are having to decide whether the threat remaining after their security controls is worth duplicating hundreds of thousands of dollars worth of infrastructure or not.

These are hard questions, with really no single good answer. My gut feel is that over the next few years we will continue the move towards the fully virtualized data center where components such as memory, PCI-X buses, storage and network devices are even further decentralized. This will make the cost of duplicating the infrastructure more and more significant, causing consolidated data center (or compute) fabrics to be the norm. At this point the discussion will move away from securing zones by creating separate infrastructure, to providing end to end security, starting integrated application level security, maybe with TrustSec or a dirivative, all the way down to securing the data at rest on disk. For the time being however, the best we can do is sit down and do an honest appraisel of our security stances, mitigate what we can, and do our best to design data center architectures that provide the flexibility of implementing whatever choice the technical and business leaders agree on.Similar Posts:

• Moving towards a Green Data Center – Truth behind the hype
• Cisco’s Cloud Computing Offering
• About Colin McNamara
• Vote for my VMworld presentation – #3221 Built to fail (shameless pandering)
• Simplifying remote site security with Cisco’s new video surveillance modules on the ISR
• Interesting TechWise TV episode on virtualization

--Colin McNamara

Measuring and mitigating risk involved with sharing virtual infrastructure between DMZ and Internal environments

NX-OS / DCNM XML API Fundamental Technology

Netconf – platform for secure communication of XML data between DCNM / NX-OS and mgmt station.

XML, using clear text tags, creates a self describing API. This is necessary because of the confusion and unneccessary complexity inherent in the current SNMP MIB based structure commonly in place today.

Webservices API = SOAP/XML over HTTPS.

Netconf/XML on NX-OS capabilities.

• Must be run over SSH
• Maximum of eight concurrent NetConf Sessions per nexus virtual device context.
• Every single CLI capabilities is assigned a XML tag

JMS is supported in DCNM as wel as NETCONF

• Native integration with IBM Message Queue

Similar Posts:

• Arista Networks – Their approach to cloud networking
• Challenges integrating VMware into Cisco networks
• Interesting TechWise TV episode on virtualization
• Identity aware networking using Cisco TrustSec
• Why was Storage Networking my first CCIE? And What did I do to prepare?
• Cool new features in 12.4(15)T

--Colin McNamara

Cisco Nexus NX-OS and DCNM XML API’s – Cisco Live 2008

One feature that is new, and frankly extremely exciting is Virtual Device Contexts. Each virtual device runs with its own process, vs the use of tagged differentiators in technologies such as VRF-Lite. This provides for paravirtualized management instances, and clear lines of delineation for both software and hardware for a resource that can be shared between different groups within an enterprise.

Chassis that run NX-OS will support In Service Software Upgrades (NSSU) to allow operations groups to upgrade operating systems with zero downtime. This is accomplished through a combination of modular software architecture, and the decoupling for the control and forwarding planes.

One of my favorite features in SAN-OS is the embedded is fabric analyser. This is a tool that can sniff management traffic without having to plug in a sniffer, or provision a span port. You can dump in real time to a tcpdump like interface in the command line, output to a local file, or map to the ip of a wireshark instance that layer 3 access to the management port. Cisco again has taken the best of SAN-OS and bundled it with NX-OS. You will be able to remotely span management traffic without having to set up rspan, or trudge down to the datacenter to set up a sniffer.

Now, your router can call home right now so that is not a totally new feature. Smart Call Home was released recently into IOS. But that still doesn’t stop it from being a great feature. This allows you to configure NX-OS powered devices to mail an xml formatted troubleshooting email to TAC, and / or your support staff. This has been proven to drop the average time to resolution from 16-30 hours to 6 hours.

Now the drum roll…… All IP routing features are VRF aware. This has been a point of contention with me for a while. As Cisco and the market in general has embraced virtualization as an answer to pressing business concerns of leveraging shared infrastructure, while retaining security controls segregating disparate environments technologies such as MPLS and VRF within the datacenter have become more and more prevalent. That is great, however it never fails that the feature you need at that moment always seems to be coming out in the NEXT IOS release. With Cisco NX-OS 4.0 this is no longer a question.

Now, if I was a CIO and I was reading about all these new technologies that Cisco was pushing with NX-OS, I would frankly be cautious, and rightfully so. The thing is, most of these features are not new, they have been in use, and in production under the most stringent uptime conditions in the world – storage networking. They have been tried and tested on Cisco’s MDS line of storage networking switches. So get comfortable, get educated, but most importantly get on board for DataCenter 3.0.Similar Posts:

• The emergence of MDS features in Cisco’s datacenter networking equipment
• Cisco is using Linux virtualization and 40 core CPU’s for its next generation routers
• New features in VMware 3.1
• Link Round Up – L2TPv3 FCOE Trill Wounded Warriors
• Arista Networks – Their approach to cloud networking
• About Colin McNamara

--Colin McNamara

Cisco NX-OS 4.0 | Next Generation Internet Operating System

Highlights of the the Nexus 7000′s features are -

• 15 Terrabit per second backplane
• Support for 40 and 100 gig ports in the future
• Seperate control and data planes
• link layer encryption
• front to back airflow (FINALLY available in a non NEBS chassis)
• Lossless non blocking fabric (VOQ enabled)
• Fibre Channel, Infinaband, and Ethernet blades in one unified platform
• Cisco Data Center Network Manager (MDS Fabric Manager on steroids)
• Virtual Device Contexts (Network Systems virtualization, the next level past VRF route tags)

You can learn more about this switch in upcoming articles, and at http://www.cisco.com/en/US/products/ps9402/index.htmlSimilar Posts:

• Cisco Nexus 4000 Blade Switch
• Nexus 5020 – Consolidated 10 Gig Ethernet and 4 Gig Fibre Channel
• Simplifying your Data Center with Cisco’s Nexus 2000 Fabric Extender (FEX)
• Interesting TechWise TV episode on virtualization
• Humor inside the Nexus 5000 switch fabric architecture
• Cisco releases Nexus 1000V virtual switch for VMware

--Colin McNamara

Cisco Nexus 7000 DataCenter switch released – Welcome to DataCenter 3.0