Pages

Saturday, August 21, 2010

Virtual APs Will Make You Look Like a Fool

Virtual APs are nothing new...

That being said, the landscape HAS changed. Windows 7's ability to run virtual APs is about to make the threat vector a WHOLE lot easier for hackers to make mince-meat of your network security. You're 802.1x authentication.... kiss it goodbye; your WPA2-AES encryption.... doesn't mean a thing.

Authorized network users will connect to your network using whatever security you have in-place, then virtualize, bridge and re-broadcast the connection. You thought rogue APs were tough to handle. You ain't seen nothin' yet!

The tools and resources for everyday users to turn your network against you are growing by the minute, and you had better be prepared to make some changes. Connectify has been around for a while, but requires specific adapters. Now this website makes it even simpler and configures Windows for you. For dedicated hackers, how about a whole web-based (cloud based SaaS) solution to manage a whole swarm of devices.




Things just got interesting, in a big way! I can see botnets of infected Windows 7 machines heading toward my network, eager to connect, virtualize, and bridge connections. They're coming, and chanting "virtualize, virtualize" while in lock-step formation like a platoon of soldiers ready to blow your network to pieces.

How will you prepare your wireless network? For starters:

  1. Don't let users have access to network credentials. How will they get on then? Transition away from PEAP user authentication to something based on the device or company asset, rather than user accounts. Try PEAP using machine accounts, or EAP-TLS using machine certificates.
  2. Secure the operating system. Hard drive encryption, anti-virus... you know the usual suspects.
  3. Remove local admin access from your users! If they can't configure virtual APs on company assets, they're stuck trying to bring in personal devices.
  4. Prevent personal devices from connecting. If you've implemented point #1, then you've gone a long way to making this a reality. Common everyday users won't know how to dig machine credentials or certificates out of a system. Dedicated hackers, well they're another story.
  5. Deploy a NAC/NAP solution to control access to internal network segments.
  6. Deploy WIPS/WIDS solutions to monitor your airspace and alert on virtualized hosts.
None of this is foolproof, but it's a start. Security ain't easy. The "Defense-in-Depth" strategy for this threat is going to take a lot of layers, get to building! After all, we don't want these virtual APs to make you look like a fool.

If you have other suggestions, please feel free to share!


-Andrew

5 comments:

  1. Solution: Throw Windows from your network and either use Mac or Linux.

    ReplyDelete
  2. Changing platforms won't change the threat. This capability is readily available on those systems as well. I've been using Atheros with MadWiFi drivers since forever, which supports multiple virtual adapters.

    A systemic approach to network security is the only way an organization can reduce risk. Making blanket generalizations regarding different technologies won't make your data any more secure; it will just make you look incompetent when a data breach occurs.

    Now, I'm not a big Windows fanboy, or Apple fanboy, or Linux evangelist. I like to think that I'm platform agnostic. As long as I can get my work done, I'm happy. I get tired of listening to the endless Microsoft versus Apple rant that people spew. Who cares? No one.

    ReplyDelete
  3. Any corporate environment worth its salt shouldn't allow the end user to have administrative privileges on their laptop/pc. If the user cannot install the VirutalAccessPoint or Connecitfy software, they cannot make their machine a hot-spot.

    ReplyDelete
  4. Jennifer, I agree with your point. In my opinion the bigger threat is non-corporate workstations that people bring into the workplace. If user auth is based on their username/password then they can most likely connect any device to the network. Only implementing a NAC/NAP solution can identify and quarantine these devices. A poor engineer's alternative is to switch to machine auth to prevent users from having access to credentials required for network access.

    Also, many small businesses still don't restrict local admin access on workstations for various reasons. Some don't have the technical expertise to do so, while others have legacy apps that require local admin rights and can't remove those rights until they replace those apps.

    Andrew

    ReplyDelete
  5. When Windows interfaces are bridged, they send spanning-tree BPDUs, and if bpdu-guard is enabled on the switch port, that port will be disabled until manually reset.

    ReplyDelete