NAC Active Directory SSO Security Vulnerability

paul.l.kyte · ‎06-03-2008

I am currently implementing and testing the NAC Appliance solution for clean access. I have noticed a massive flaw in the security of this product, unless I'm mistaken. I was wondering if anyone can comment on this.

In order to utilise Active Directory SS0 I need to allow communications from the unauthenticated VLAN to the active directory servers on the below listed ports. This means that any device that is connected to the network and is not authenticated will be able to communicate with my servers on these ports. as you can see these are some of the most vulnerable ports on a microsoft server and hence I have my network and AD wide open to hackers and viruses. Surely this is wrong or have I misunderstood how the NAC AD SSO works?

Ports (TCP/UDP)

53

88

135

137

138

139

389

445

636

1600

3268

3269

5000-5101

Many thanks for your help.

Regards,

Paul

tj.mitchell · ‎06-03-2008

The unauthenticated VLAN if I remember correctly shouldn't have a L3 interface on the switches, all traffic must traverse the NAC Appliance. If the user doesn't enter the proper credentials the users stays in the unauthenticated VLAN and can't pass traffic because there isn't a gateway or L3 device for forwarding traffic to and NAC will not pass the traffic.

The NAC Appliance is acting almost like a proxy for the user and if you have the proper credentials it will change the VLAN on the port your plugged into and you'll have access to what you need.

When testing this for a client awhile ago, I didn't have access to anything on any port if left in the unauthenticated VLAN.

HTH..

pls rate if this was helpful.

paul.l.kyte · ‎06-04-2008

Deart j.mitchell

Unfortunately you are quite wrong. The ports are available to all devices on the unauthenticated VLAN when not authenticated. In other words the NAC Appliance is providing a hole through to the AD servers. This is a major security flaw.

Has anyone else any comments on this.

Thanks,

Paul

tj.mitchell · ‎06-04-2008

Not sure about that as I have done a few installations if the network is setup correctly you won't have the issue. I have done it inline and OOB both with SSO and never ran into the issue that you are talking about when the network was setup correctly. I had to fix a few issues on the first time that I installed the appliance due to the problem that you are describing, once that was resolved I didn't have the issue.

I'm going by experience on this from what I have done and working with other engineers, it did take a me a bit to get it working properly the first time. You can say I'm wrong or what ever but if the devices are setup correctly and network is configured correctly then you should not have the issue as you are describing.

paul.l.kyte · ‎06-04-2008

Hi there,

I understand what you are saying but from my experience and testing it is not like you say.

In order to get SSO working I have had to edit the policy on the unauthenticated role to allow access to port 88 and 389 on my AD Servers the other side of the appliance. This got me thinking is this a hole? I then tested it with an unauthenticated PC and I could connect to these ports. I then changed the policy to allow snmp to the servers and this allowed the unauthenticated PC to walk the MIBs of the AD Servers. I then changed the policy to allow all TCP and UDP, I could then access all ports on the AD Servers. All this from an unauthenticated PC!!!

The IP Policy on roles looks like a massive security hole in the appliance and the solution. I would like to think that I'm wrong but testing proves me right.

Are you or anyone able to show that I'm wrong? Maybe I don't need to set the policy on the unauthenticated VLAN to allow access to the AD Servers. The book stated to do this and without it the SSO doesn't work. Maybe I've missed something in the configuration and setup. If you can put me right I would be most grateful.

Thanks,

Paul

cleidh_mor · ‎06-05-2008

Hi Paul,

You are correct in that the servers will be open on the ports listed, but unfortunately there's nothing much you can do about it. IMO NAC is not intended to protect your DCs from concerted attack - it's more of a compliance product, ensuring that all the clients on the network are up to a certain security standard before they're allowed unfettered access to the whole network.

If you're really concerned about the risks of having windows ports open (and who isn't?) then you could either put an IPS between the DCs and the NAS or spend some time hardening your DCs.

The bottom line is that to authenticate against the DCs, you have to have the relevant ports open just like a web server behind a firewall.

HTH

paul.l.kyte · ‎06-05-2008

Thanks for this reply, I thought I was right but just couldn't believe a 'security' appliance could be so insecure or rather not a security appliance.

Of course my life would be made much better if the NAC appliance used 802.1x to control the switch ports. Is there any likelyhood that this will be the case in future?

Thanks,

Paul

cleidh_mor · ‎06-05-2008

Well, it's kind of a replacement for dot1x if you think about it because the port isn't fully functional until the user has authenticated.

That's not to say that Cisco aren't working on something like 802.1x integration, but since that was their first attempt at NAC (i.e. NAC framework) I would be quite surprised.

Personally the way I look at it is that having the NAC appliance in there is still providing a high level of security just by stopping access to all ports on your DCs. I think the best analogy is still the webserver - you *have* to allow ports 80 and 443 through all your multiple layers of security because otherwise your clients can't hit your webserver. The same applies to your DCs - the only way you can keep them totally safe is by isolating them from the network but then no-one will be able to log in.

I suppose the next step for Cisco would be using the NAS as a kind of proxy for the DC, but how that would integrate with AD I'm not sure. From the way that AD SSO is set up on NAC appliances, it certainly needs looked at.

Cheers,

m_zabetian · ‎08-28-2008

Base on Cisco Doc you have to make this hole for getting to domain and Also if you don't open right port you SSO it will fail. because agent get information from you pc after U login to domain so if you fail in some point of auth your SSO will fail however you get to windows and U think you pass AD auth.

CoetzerJ · ‎06-10-2008

Hi Paul,

With ADSSO, the workstation is required to Authenticate to the Active Directory Network prior to the Clean Access Agent starting up on the workstation. If most of those ports are not open, then the workstation will not be able to authenticate to AD (but use cached cridentials, if available on the workstation), causing the ADSSO Agent to Fail, as the required Kerberos tokens would not have been provided to the workstation at login, and hence the clean access agent will not be able to transparently authenticate.

Hope this helps in explaining why the ports are required to be open.

Dont know about the 5000,5101 ports, have you configured your AD to use that for RPC? The standard is usually in the region of 1024 - 1027, sometimes (but very occasional) above that, depending on how many services start up on your AD servers.

Maybe another way to limit the ports down is to configure only secure comms, ie have AD set up to only use the SSL type ports and not the clear text ports .. but I am not AD expert, so not 100% sure if it can function in Secure mode only, during Authentication.