My backfill is here, so now I'm 100% on the NAC project where I work. That can be good... cool toys to play with... :excited:
It can also be bad... I'm a single point of blame, now... :'(
What's the worst that can happen? Only the network blowing up... :glitch:
All in all, though, I'm overall stoked. I'm a FTE that gets to do consulting stuff, and I have a job (operations and engineering) when I go "back on the bench" when the project is over.
NAC project over??? :rofl: hahahahah. it'll be ongoing forever, the project ends when you turn NAC off.
you = Homer
NAC = Bart
:developers:
It means that, basically, they just told me that I have a job for life there. :banana:
Part of what I enjoy about NAC is how interdisciplinary it becomes, and very quickly at that. If it's taken as a switch question of just putting in something at the port level that checks a cert and then accepts/denies on that criteria and possibly others, even then it's a project that involves the switch team and the desktop team. (Or guys, if your firm is small or medium sized.) But because NAC products are sold with more than just an Identify Friend or Foe (IFF) system, it will have connections to the teams or guys that do desktop updates, anti-malware, threat detection/threat response, help desk, routing (VLAN harmonization, anyone?), firewalls, PKI, Active Directory, and various production/lab/high-risk/high-security environments.
I've always enjoyed being able to be a generalist, and this role is a great fit for me. Yes, the work is very complicated and I've made more than one manager's head spin when he said, "I'm fairly technical. Go ahead and give me the details."
I do prefer project work to operational "My Internet needs rebooting" issues, so this promises to be a rich experience for me. It will mean that I will be trading vendor lunches that the rest of the team gets to head out on for more "We'll order in" situations, but that's not all that bad.
We are using ForeScout CounterACT as our NAC solution, which we chose after a head-to-head comparison with Cisco ISE. I know there's people in the world that make their bread-and-butter from ISE, so I'm not going to vendor bash. In fact, a good comparison is important so that a person can make an informed decision about what NAC product is the best fit for their firm. There is a lot of cool stuff in ISE, and there's a lot of cool stuff in CounterACT.
Of course, I'll be writing about NAC a lot, and I plan to keep it vendor-neutral. NAC project work has a lot of stuff that has to happen, regardless of which vendor you choose. You will be touching the switches. You will be touching the clients. You will be having meetings with people that are concerned because they heard of NAC going in at another company and, right after that, the machines rose up to kill their human masters. (I am convinced that the trigger for the Terminator series was a NAC deployment gone horribly, horribly wrong. Same for The Matrix. Be cool if there was a Terminator vs. The Matrix movie. But I digress.)
NAC means having the right kinds of meetings with the right kinds of people in order to meet the needs and goals of the project. If you want to learn how everything connects to everything else in a company, start a NAC project.
Quote from: deanwebb on February 13, 2015, 08:49:52 AM
If you want to learn how everything connects to everything else in a company, start a NAC project.
This is the Federal Government boyah, no oneknows how anything is connected to anything else.
other than "through a firewall".
So yer doing NAC native IPv6? or is that next week's project?
Hey, we just had a meeting that cut our paperwork in half, when everyone agreed that half the forms didn't apply to this instance. Score!
Dean,
I am looking at a NAC project Q4 of this year or so. Do you have some documentation in which you used for the deployment. This will be my first time. deploying...
I don't have any internal docs that I can share, but I can get into theory and practice stuff here. First question, how many endpoints are in your network? Include wireless, guest systems, desktops, laptops. And phones. And printers. Also badge readers/cameras/network-enabled coffee brewers. Just an estimate is good.
Then the next question is how many sites do you have? Those two questions help to guide you towards a centralized or decentralized approach.
Quote from: deanwebb on February 13, 2015, 01:02:26 PM
I don't have any internal docs that I can share, but I can get into theory and practice stuff here. First question, how many endpoints are in your network? Include wireless, guest systems, desktops, laptops. And phones. And printers. Also badge readers/cameras/network-enabled coffee brewers. Just an estimate is good.
Then the next question is how many sites do you have? Those two questions help to guide you towards a centralized or decentralized approach.
Tricky question because Most of end devices are not even on our domain, they are thin clients either connecting to VDI/Citrix.. if that mkes a difference.
If you count every piece of equipment... maybe 5k computers. 500 or so printers. 200 routers, 200 or so switches, 300 or so APs
One site? If so, then that's a slam-dunk for "centralized".
How many systems on wired? Wireless? Do you have a guest network?
One of my personal favorite things to do is blame NAC for every anomaly on the network.
Can't ping host? - NAC
Can't nslookup host? - NAC
Host can't route out? - NAC
Quote from: Seittit on February 13, 2015, 02:48:10 PM
One of my personal favorite things to do is blame NAC for every anomaly on the network.
Can't ping host? - NAC
Can't nslookup host? - NAC
Host can't route out? - NAC
Stop it. We're in monitor mode. We haven't done anything to impact that, yet.
And the easiest way to see if NAC has borked a box is to hit the NAC console to see if there are any authentication failures, blocked devices, or the like. If so, well, there's your problem. If not, hahahahaha it's not the NAC, suckers!
Quote from: deanwebb on February 13, 2015, 03:50:35 PM
Stop it. We're in monitor mode. We haven't done anything to impact that, yet.
And the easiest way to see if NAC has borked a box is to hit the NAC console to see if there are any authentication failures, blocked devices, or the like. If so, well, there's your problem. If not, hahahahaha it's not the NAC, suckers!
Yeah, but, what if NAC was NAC'ing itself!?!
Quote from: Seittit on February 13, 2015, 04:40:01 PM
Quote from: deanwebb on February 13, 2015, 03:50:35 PM
Stop it. We're in monitor mode. We haven't done anything to impact that, yet.
And the easiest way to see if NAC has borked a box is to hit the NAC console to see if there are any authentication failures, blocked devices, or the like. If so, well, there's your problem. If not, hahahahaha it's not the NAC, suckers!
Yeah, but, what if NAC was NAC'ing itself!?!
That's why one always excludes the IP range of the NAC devices from NAC.
Here's my intro to NAC video: https://www.youtube.com/watch?v=_HNPVCqJihk
How NAC could have saved the Death Star: http://youtu.be/nhLUVg7pqNM
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!
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.
... 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...
Quote from: deanwebb on March 17, 2015, 11:53:51 AM
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.
Hahahaha you're funny, ristau. :o
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. :doh:
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.
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.
Quote from: Reggle on March 24, 2015, 01:46:26 PM
NAC somewhat equals a large-scale team building event.
:lol: :rofl: :problem?:
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.
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.
Quote from: deanwebb on March 17, 2015, 11:53:51 AM
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.
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.
I'm interested in hearing what others do to solve sccm with nac so do share yours
Sent from my iPhone using Tapatalk
Quote from: jinxer on April 08, 2015, 12:40:18 PM
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?
Quote from: deanwebb on April 08, 2015, 01:43:14 PM
Quote from: jinxer on April 08, 2015, 12:40:18 PM
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..
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...
Random idea, as I currently don't have time for proper research: would 802.1x with MAB (MAC authentication bypass) work to put stuff in a remediation VLAN somehow?
Yes. The remediation VLAN needs to exist on the switch. Basically, the condition should be if the device gets a RADIUS-Rejected, assign it to that VLAN. That VLAN would have access to things needed to get back on the network. Keep in mind that one RADIUS-Rejected is the same as another, so that remediation VLAN will also be where baddies are left to hang out, as well as salesmen from remote locations that never read the emails about needing to upgrade their systems.
KERBUMP
I got 99 problems, and a client issue is all of them.
:frustration:
Just remember that when you're doing a NAC project. If something goes wrong, make a check on the switch config and the NAC system config... if all looks well, then it's a client setting. It's not the proxy, it's not the firewall, it's not the IPS, it's not the switch, it's not the router, it's not the NAC, it's not even the load balancer. It's a setting on the client, possibly the same bad setting on multiple clients. Look at the clients. Look at them good and hard before you start changing anything that's not on a client.
Because if you don't fix the client, you will spend hours chasing your tail in all the places where the problem simply does not exist. :angry: