100% NAC

[deanwebb]

Now we're starting to talk about enforcement... and what happens when we have a PE or PXE build that gets put together on the corporate network without any sort of identifying criteria to differentiate it from a threat box... fun times!

[Reggle]

I've never combined PXE builds and NAC. Does not look like a good plan. You could have a PXE server reachable from the guest/default unauthenticated VLAN, although that will obviously introduce some sort of security issue.

[deanwebb]

... unless that default VLAN needs access to practically the entire network, or at least the entire server farm... on all the protocols and ports that Windows uses...

[icecream-guy]

without any sort of identifying criteria to differentiate it from a threat box... fun times!

It's considered a threat box.  If policy and procedures are not followed to correctly implement devices and do not meet the requirement of the data center and/or company, consider it a threat.

If policy and procedures are followed, NAC will see it as a friendly device and do it's thing.

Simple as that.

[deanwebb]

Hahahaha you're funny, ristau. 

The desktop people like to do things in their certain way, and that way makes it difficult to do NAC. There are things we can do that will make NAC work well, but will destroy the build process in all but 5% of our locations. Policy and procedures are currently followed for the desktop build guys, but NAC will make changes to them.

And we haven't even discussed with HR and Legal about what happens when we have a false positive and kick a legit user to a quarantine VLAN. There are countries where that might be... troublesome... since it involves information gained from what might constitute illegal surveillance.

[deanwebb]

Fun stuff for the day: creating logic flows for determining who should and should not be on the network. But, before we enforce this stuff, we have to show how many devices need remediation and then get them remediated.

This will lead to people complaining, "but there will be devices that won't get on the network!" That's right, they won't. We have to fix them.

"But there will still be some that won't get fixed! Legitimate users will be blocked!" If they're not fixed, they're not legitimate. We can create the means to remediate, but we can't keep letting devices connect to the network that fail to meet minimum requirements.

"But some hackers will get past those minimum requirements! You must block them!" In due time... and at least now the hackers have to make an effort to get on. Before NAC is in enforcement mode, they can just walk on in and grab a port and start scanning.

Fun stuff. That, and specifying to the TAM what I want changed in how the executive dashboard web stuff displays.

[Reggle]

The difficult part of NAC never is the technical implementation. It's the politics, misconceptions and narrow-mindedness that you have to get out of a group of people that is the trouble.

You know, NAC somewhat equals a large-scale team building event.

[deanwebb]

NAC somewhat equals a large-scale team building event.

I want that as a title of a Gartner article. Then I'll get the whole company to hate me as an organizer of said event, but at least they'd cooperate just to get it all over with so that they could get back to work.

[deanwebb]

Here's a thought that I wish we had had earlier in the deployment:

All our NAC devices will need to be able to receive SNMP traps from participating switches. Should one device go down, another will be needed to take its place with a minimum of disruption.

If we give all our NAC devices IP addresses in the same subnet and do some fancy routing tricks with a zillion /30 networks, we can have that "NAC device subnet" placed into an ACL that has appropriate SNMP permissions.

If you have only a few switches to manage, this won't be a big deal. If you have only a few NAC devices to keep track of, also no big deal. If you're in an enterprise with maybe a hundred or more NAC devices and switches that number in the thousands, this can make that ACL change on all those switches very straightforward.

[jinxer]

Now we're starting to talk about enforcement... and what happens when we have a PE or PXE build that gets put together on the corporate network without any sort of identifying criteria to differentiate it from a threat box... fun times!

What i did was set up a standalone box (LDAP) which handles all MAB records (one should have one anyway instead of in ISE local db).. Talked to the SCCM guys to give me a list of all MAC addresses thats in there, created a script and put everything in a csv file and imported it to the MAB standalone server. Gave them instructions that when large batches come in, they put it in that csv file and run the script themself and all is good.

Created a AuthZ rule that referenced the group where i put the all the computers from SCCM in and gave that "only" access to ports required to successfully PXE and let SCCM push its image on...

Now as with anything MAB, its not THAT secure, but atleast its a 2nd layer to what you have to open to get PXE/SCCM running anyhow in a production network.

[deanwebb]

That's one way of doing it... we're hoping to see if we can discover anything that they can have in common that's less MAB-intensive.

[jinxer]

I'm interested in hearing what others do to solve sccm with nac so do share yours


Sent from my iPhone using Tapatalk

[deanwebb]

I'm interested in hearing what others do to solve sccm with nac so do share yours

What issues with SCCM are you having? Pushing out a client or integration with NAC itself?

[jinxer]

I'm interested in hearing what others do to solve sccm with nac so do share yours

What issues with SCCM are you having? Pushing out a client or integration with NAC itself?

Well to get it to run is easy.. But how you do it is interesting.. Place it in a restricted VLAN with acl's only? Which opens up alot if you want it to install and run through sequences that joins it to the domain gets certs and so forth.

Or maybe some other way.. Like MAB+restricted VLAN+ACLs etc..

[deanwebb]

One solution I've seen for other environments is the secured build area. It's a room with network drops that has access to the general LAN that isn't under strict enforcement. Boxes get built there and then enter the real world with all their certs, files, clients, etc. needed for network access. Personally, I'd like a more elegant solution...