In my last post on this topic, I highlighted just how true the words “Work is no longer a place you go, but what you do” really are. We now have the ability to work anytime, anywhere, using any device. As easy as this has made the lives of workers all over the world, it’s made the lives of security administrators immensely difficult. Providing secure access to the corporate network in a borderless world, while still somehow keeping out the bad stuff, has caused traditional security policies to become increasingly difficult to configure, manage, and troubleshoot – the source of inordinate amounts of pain for security administrators.
That’s why Cisco has introduced identity-based firewall security as a new capability of the ASA platform. As the first installation of what will soon become full context-aware security, identity-based firewall security enables security administrators to utilize the plain language names of users and groups in policy definitions. Rather than authoring and managing the growing list of IP addresses to cover every possible location, device, or protocol that may be required for secure access to the network, identity-based firewall security enables security administrators to grant access to “Jeff.” Regardless of where I am or what I’m using for access, I’m still Jeff… so in the simplest case, my administrator can literally write one policy to provide “Jeff” access to the corporate network, rather than six different IP addresses for all the instantiations of Jeff.
The Unified Network Services (UNS) portfolio of Layer 4-7 services (such as ACE and WAAS) also includes Cisco’s data center security solutions. A critical part of that security portfolio is our virtualization-aware firewall solution, Virtual Security Gateway (VSG). In a series of upcoming blog posts, I’ll be sharing a few use case scenarios that our customers are implementing with VSG.
For those of you new to VSG, I’ll point out that VSG’s role is to act as a virtual firewall between zones of virtual machines. Isolating traffic between VM zones has been very challenging prior to VSG because: 1) security policies have to be enforced between VMs running on the same server or same virtual switch (where there’s no place to put a firewall), 2) VMs move all around the network and the security policies (as enforced in the firewall) must follow the VM, and 3) the need to maintain segregation of duties for compliance purposes between the security and application server teams, where security is potentially enforced inside the virtual server.
A few years back I set up IPv6 connectivity on my home network for the first time. I had a rush of exhilaration when the first ping and traceroute commands completed successfully. Suddenly, I was free of Network Address Translation and bypassing my firewall, connecting directly to any IPv6 device on the Internet. But then it slowly dawned on me that those people same people could also directly connect to my device! In a panic, I wondered if my SMB shares were visible to the world, or if criminals could relentlessly probe my open ports for zero-day vulnerabilities. How could I even check if I had any open ports? My fear got the best of me and I disabled IPv6.
I contacted my friend Dan and posed my dilemma to him. How could I tell if my ports were locked down on a machine which ran IPv6? A number of sites provided port scanners for IPv4, but nobody had a general purpose scanner for IPv6. Hurricane Electric provided one, but only for devices that were on their network. Dan hacked up a primitive IPv6 open port testing site, which uses NMAP to scan an IPv6 visitor for typically vulnerable ports before issuing a simple report. I was pleased to discover that my computer did not answer on any of those commonly attacked ports.
In this process, I discovered that many modern operating systems with IPv6 enabled also come with a set of reasonable host firewall defaults which do not expose listening ports as much as I had expected based on my experience with IPv4. Many hosts with IPv6 enabled by default also come with some very sensible settings to prevent network-launched crimes of opportunity from malicious users.
IPv6 also provides a natural defense against classic portscanning attacks, where an attacker probes for commonly vulnerable ports of every IP address on a subnet. For densely packed IPv4 service provider networks with one IP address assigned per typical user, a few thousand probes across a known DSL or cable subnet can yield a rich collection of potential targets. Since the address space of IPv6 is so much larger and sparsely populated than IPv4, blind portscanning of subnets becomes impractical since a typical IPv6 subnet contains quintillions of addresses hosting a relatively small number of end devices.
Most people already have IPv6 capability whether they know it or not. All Microsoft operating systems such as Windows Vista and all MacOS releases since 10.2 have IPv6 installed enabled by default. Mobile devices running Android 2.1, Apple iOS 4.0, and Symbian 7.0 are configured likewise as is nearly every *nix variant you can name. Even the venerable and ubiquitous Windows XP has a latent IPv6 stack which can be activated with a single command.
Typically, IPv6 enabled systems will prefer IPv6 connections over IPv4, so a misconfigured or malfunctioning IPv6 network will cause connectivity problems. Many popular troubleshooting regimens simply prescribe disabling IPv6 as the “solution,” which really does nothing more than to hide the underlying problem with the IPv6 network. When you have a network problem that is “solved” by disabling IPv6, you have masked the symptom of a bigger problem that warrants further investigation.