Saturday, November 28, 2009

Cisco AnyConnect Client

For those that are still using the older AnyConnect Client there are several reasons to upgrade to the newer 2.4.0202 release or at a minimum the 2.3.2016 release. The 2.3.2016 fixed some issues with passcode vs password prompts within the Client windows when logging in. If you are using RSA SecurID I would recommend moving to 2.3.2016 or 2.4.0202 to avoid the sort of confusion the older client presents for end users.

The release notes for AnyConnect 2.4.0202 are here. Note that this version officially supports Microsoft Windows 7 32 and 64 bit and Apple OS X 10.6 and 10.6.1 both 32 and 64 bit.

One of the more interesting features they added was the Trusted Network Detection (TND) which in essence allows the AnyConnect client to determine when it is already on a trusted network and disconnect from the VPN or if it is NOT on a trusted network to initiate the VPN connection. I think this feature might need a bit of time before it works out all the kinks but it looks promising. I see it as an attempt by Cisco to address the unique abilities of Microsoft's DirectAccess feature without having to engineer anything new.
- Ed

Cisco ASA ASDM update

Cisco has had ASA 8.2.1(11) code out for about 2 months. I have several customers running it now because it addressed a lot of problems with the 8.2.1 code release that came out in May (the release notes are here - login may be required.) I recommend running it, it has been stable.

There is also a new ASDM version 6.2.3 that just came out in the beginning of Nov. I think 6.2.1 has been a good stable version so far with no major problems that I have encountered however I can never find a lot of release notes for the ASDM software for some odd reason. I haven't installed 6.2.3 yet on a production ASA deployment so no formal thoughts about it yet.

I also thought Cisco was going to keep ASA code and ASDM code releases in lock step with each other so it would be easier to tell which release of ASDM code would go with which release of ASA code but I guess that only goes for the first minor number and not the sub of interim releases. A shame because it does make life easier for people who don't use and/or install the ASA products on a regular basis to figure out the code they should be running and what works together. If you need PSIRT images they are available here. Even if you are not on a current contract you can download and use these versions as they address major security vulnerabilities that Cisco considers important enough to give out the code to fix the issue. The most recent code release under that PSIRT is 8.2.1(3) which is pretty new (June of 2009.)

I have not noticed any specific Java issues with any of the newer ASDM releases, looks like Cisco is paying more attention to that problem and making sure ASDM just works instead of having to fiddle around with Java versions and such.

On a side note, 8.2 code on the 5510's can be a problem and Cisco is recommending a memory upgrade for the 5510 series so that it can run without major performance problems. There is no problem installing and running the code on the 5510's at all, it is just an issue of how much memory is consumed depending on how much stuff you are doing on the ASA. Something to keep in mind, I really prefer the 5520 model because of this reason plus all the interfaces on the 5520's are Gigabit with the exception of the Management interface (which just seems to be a cheap cost cutting measure) which is 10/100.
- Ed

Monday, November 23, 2009

Follow up items to NAC / 802.1x post

I realized I left out some important clarifications on my post about NAC and 802.x, so here they are in no particular order. I've includes some other random thoughts too, just to keep life interesting.

1. I did not do a Cisco NAC Appliance + 802.1x (Cisco NAC Framework) deployment configuration - which would likely address some of the items in the fourth point. I would still argue that for trusted hosts that are able to run virtual machines you can still have issues with the overall security deployment and you need that HR/Security policy and procedures.

2. I did not address VMware's View (VDI) or ACE platforms or Microsoft's Remote Desktop or Citrix's XenApp or XenDesktop since they are all inherently remote access methods. I have not had a chance to look into View's authentication method supports but I imagine for the thin client machines simple MAC based security would suffice along with ACL's if a large thin client deployment is done.

For ACE I would recommend building out the internal network with 802.1x with a default guestnet configuration and let machines boot and get Internet access and then launch the ACE desktop to connect via VPN, just like if they are out on the public Internet. I would use this same method for people running View on a desktop or laptop since they have an underlying OS. With both of these solutions I see limited value in attempting to do single sign on or an 802.1x supplicant in the native OS. Basically you are building a public access network where View is the only service available or in the case of ACE where they have to VPN back for resources just like if they were on the public Internet.

3. I did not address the function of most of the agents used in NAC solutions and what benefit you might get from them. For instance, Cisco's Trust Agent (CTA) can allow the end host to pass posture information to Cisco ACS and can work with Cisco Security Agent (CSA) to build a more comprehensive solution. Basically, CTA was the first NAC client agent (2004?) and allows for end hosts to work with with a AAA server to do both authentication but also posture validation.

CSA is different, it works independently on the end host and watches the behavior of the native OS and basically denies any activity that looks outside the normal behavior of that machine. It doesn't care what an application or service is trying to do, if it isn't something that has been previously defined as ok it blocks it. It can run as a centrally managed or standalone configuration. So, if you glue the two together you can get health posture/remediation + validation of machine and end user + very secure end host with reduced exploitable footprint.

4. Some IT professionals argue it is easier and cheaper to run a VMware View setup (or a Pano Logic configuration) and just blow away potential desktops that don't meet company standards or appear to have issues (security or otherwise). They argue it is cheaper and more cost effective to simply deploy a new desktop than to determine what is wrong. They often also say you do not need to incur the cost of deploying either NAC or 802.1x solutions since everything is resident back on a VMware ESX host. I think the cost argument for not wasting time trying to determine what has gone wrong on a desktop OS makes sense. I would still argue that you want some sort of endpoint security to keep foreign systems from accessing your View configuration or ESX host. Also, you will still need to audit your systems for security issues and while patching the OS might have gotten easier and even automated the exposure from guest hosts isn't any different.

5. I think it is sort of obvious right now but I didn't mention it specifically, there is no unified framework or management method for deploying this as a solution right now. What does this mean for IT Professionals who are running and maintaining this? It is possible to break NAC or 802.1x by doing a simple upgrade of your AAA service or radius solution if there is a bug. It is possible to lock everyone out of the network by mis-applying the wrong policy configuration (always have a backup reserved port with no 802.1x or NAC authentication on it!) and you have to manage this on all the network devices connected to your network.

6. To the best of my knowledge there is no way to automate deployment of new switches on the network and have them self provision with 802.1x. You can avoid trusting a new switch connection by using Cisco TrustSec but I have not seen a lot of activity in that area myself.

7. I think there might be something to the argument that deploying an all wireless (no public access switchports) might be more secure in some cases. You can't address the DOS problems with wireless spectrum so that is a negative but it is only a single unified solution for wireless. Everything else is back in the datacenter on a trusted well known port.

8. I think there is also something to be said for shops that deploy everything in a data center and require everyone to VPN in to access content. Then they simply build out public access networks at their office locations and don't worry about port security. As bandwidth has gotten cheaper and cheaper this solution seems viable. With Cisco's AnyConnect client being able to auto reconnect it makes this a more tolerable solution to end users since they don't have to reconnect via VPN if they disconnect by losing network connectivity.

9. I believe Microsoft's DirectAccess solution is a great way to extend a corporate network with trusted client machines and still get the same sort of policy management. The solution allows IT professionals to run basic 802.1x. For machines that don't run a supplicant it still provide them basic corporate services in a dynamic VPN configuration no different then if they were on the public Internet by having them fall back to guestnet access. In addition, they can run the Microsoft's NAP solution with DirectAccess and have all the posture and remediation work happen regardless of location. The best part is that 802.1x can be run and maintained by the network team and NAP by the server team and neither solution gets in the way of the other for the most part.

Ok, that is it for now, I am sure I'll think of something else and I know I've forgotten a point or two so I will post again when they resurface in my head.
- Ed

Thursday, November 19, 2009

802.1x and NAC - Some thoughts

I spend the better part of a week getting 802.1x up and working for both wired/wireless utilizing Cisco ACS, 6500 switch and wireless lan controller plus I also have been working on a separate Cisco NAC Appliance deployment. After spending this much time on getting things working I thought I would review what I consider the benefits and downfalls of the solutions.

First, regarding Cisco NAC Appliance - the product works and is relatively easy to set up but is only full featured as a layer 2 solution right now, imho. The client is way behind where it should be and the layer 3 out of band solution is extremely lacking in the functionality that it really should have and that clients expect. If Cisco is able to make some of the improvements that they are talking about for the NAC Profiler + 802.1x infrastructure + ACS combo then it might be worth the effort but the price is still extremely high. The plus side is the integration with third party anti-virus solutions is excellent so posture and remediation should be leveraged with the product as you don't get that with a pure 802.1x deployment.

Second, Cisco ACS as a product is too long in the tooth and needs to be retooled. For those of us who have been around awhile ACS was what you used for dial up access, AD authentication integration (TACACS/Radius) and policy management for network devices. They are attempting to utilizing it as a policy management and framework engine and the interface and layout of the device is so circa 2000 it can't accommodate today's policy engine requirements. For example, even understanding how to get certificates loaded onto the platform and how they are being used is almost impossible to figure out and the limited logging and debug output is frustrating. Plus the additional burden of it being different depending on which OS solution you chose to deploy adds even more frustration into the mix. Building out Network Access Profiles isn't particularly intuitive or fun on the product either and many of the management functions are not in places you would think they should be. Also, you have to restart the ACS server way too many times for even the smallest changes, that really needs to get fixed.

Third, 802.1x wired solution is not the security be all that some seem to think it is. There are challenges with getting the solution to work correctly with IP handsets from different manufactures and the additional challenge of all the devices out there that do NOT have a supplicant built in and never will. This list includes network items like: printers, scanners, ip cameras, badge readers, environmental sensors, out of band console management, remote power devices, hvac controllers, lighting system controllers, projectors, AV systems and the list goes on and on. That being said, for end client machines, regardless of OS, 802.1x does have broad support and setting up supplicants to work properly is relatively easy and painless. The configuration for the switchport on the 6500 is pretty straightforward, a simple configuration like the following is all that is needed for 12.2.33SXI or newer code:
!
interface GigabitEthernet1/1
description - Standard 802.1x switchport
switchport
switchport access vlan 666
switchport mode access
switchport voice vlan 20
! - the next 4 lines are optional
authentication event fail action authorize vlan 666
authentication event server dead action authorize vlan 666
authentication event no-response action authorize vlan 666
authentication event server alive action reinitialize
authentication port-control auto
dot1x pae authenticator
! - the next line just changes the default value
dot1x timeout supp-timeout 10
auto qos voip trust
spanning-tree portfast edge
no shutdown
!

Assuming you have a guestnet vlan 666 or some sort of equivalent limited vlan roll you can make some very interesting default behaviors for 802.1x when there are foreign clients that connect to your network with no 802.1x supplicant. I set up the additional options to allow the radius server to tell the switch what vlan to put the port on depending on the logon credentials. The extremely useful part of this is that you can use the same principle to assign wireless vlan assignments while using a single SSID. You can even do the same default privilege configuration where if they fail to authenticate they are put in the guestnet vlan.

Fourth, you need a combination of switchport security, 802.1x and a well documented physical access policy to insure compliance to make the whole thing work. The reality of the matter is that folks who are trusted (have valid logon credentials) and want to do something malicious still can. I have been able to get several virtual machine combinations to bypass 802.1x and NAC deployments allowing non-approved client OS's full access to the network. I have also been able to completely lock out legitimate client machines due to poor timeout combinations between the 802.1x supplicant and the OS IP address request timers and the switchport. Then there is the issue of timing for logouts and host machines where their switchport does not go down on reboots allowing alternate OS's to be booted and gain access and not violate MAC based security either. The example, if the already authenticated client machine in the correct vlan is hard powered off but the hosts NIC adapter does not go "down" (several well known manufactures workstations do this) and the machine boots into a new OS (knoppix for instance) and comes back up with no supplicant and does a simple dhcp request it will get an IP address on the authenticated network and have the same MAC address as the trusted authenticated OS. Clearly not as secure as everyone thinks.

Fifth item is regarding wireless and the EAP authentication methods. In some ways the EAP methods for wired port aren't as much a concern. The end workstation has a direct (and likely unshared) connection to the switch that it is doing authentication. Wireless is a different situation where everyone is on the same share bandwidth spectrum and anyone can watch the traffic passing by on the "wire." Selection of the correct EAP method seems easy at first. Most folks seem to think that EAP-TLS is the best option since it requires certificates and you can combine it with end user credentials giving the combination of something you have (a certificate) and something you know (username and password). Getting EAP-TLS actually deployed and all the hosts and supplicants recognizing the certificate chains properly can be a much bigger project than people think. Especially because most of the folks who manage the certificate services are not in the networking group. In addition, there may be two sets of certificate services in use, public ones for websites, sslvpn termination and other public facing services and internal corporate certificate services (often Windows domain based.) Determining which one to use and how to load the trusted certificate authority on the device is a challenge.

Sixth, there may be some vendors that are worth looking at if you are serious about getting 802.1x up and running. The only vendor who had a great switchport authentication solution was Consentry Networks but they went the way of the dodo back in August of 2009. Since I consider Cisco ACS + Cisco switches to be a sub optimal solution (for now) given the complex scenarios a 802.1x wired/wireless deployment might require it looks like Avenda Systems might have the right solution. Their interface seems much better and the company founders came out of Cisco and Microsoft. Their solution addresses the right market and has the right bells and whistles at what appears to be the right price point too. I'll be trying it out some more in our lab and will do a post later with my thoughts about it.

Seventh, nothing seems to replace good IDS/IPS solutions for catching activity that seems out of place and alerting on it. In addition, Netflow/Sflow is really useful in understanding your network behavior and traffic patterns and really should be leveraged to understand when something is happening on your network that looks odd.

Finally, nothing replaces good HR/security policies and procedures. It isn't possible to do some of the exploits if your company really is careful about who has physical access to devices and actually follows controls for guests and contractors. Sounds silly but your employees are still your biggest strength and weakness in security. Training and rewarding behavior you want as a company goes a long way towards dealing with security concerns.
- Ed