Preventing DHCP leases

[markettm]

Hi everyone, I have a question about preventing DHCP leases. Is there a way to configure my DHCP server to only allow leases to my corporate domain machines?

Everyone runs DHCP, and some travel from one branch site to another (ie, one subnet to another) so setting up reservations isn't feasible. Also locking down ports on the switch isn't an option.

Is there anyway I can lock down DHCP handing out addresses only to my domain machines and noone else?

 

[shrubble]

I'm sure there is a way to only issue leases by the MAC address of each machine, I'll go poke around in the server and see if I can find where you would do that. If that is the solution, I don't envy you for having to set it up; MAC addresses are a pain in the butt!

deletion mistake
no I can't recover that
you didn't save it

-Shrubble

http://www.ishrubble.com

 

[markettm]

Thanks for the help Shrubble!

 

[shrubble]

Is the problem because of WiFi? For instance, are you having trouble with people getting DHCP leases with wireless devices when they roam into your area (and thus just sucking up your internet access), or are suspect machines able to authenticate on your network?

deletion mistake
no I can't recover that
you didn't save it

-Shrubble

http://www.ishrubble.com

 

[markettm]

The problem is consultants who come in and plug in their laptops. They run DHCP so they pick up and IP address and then if they're infected it can propogate through our network.

We don't have any wireless rolled out here yet, so that's not a factor.

So far, the only thing of value I can find is tying my Cisco switches in to my IAS/RADIUS server to authenticate the machine as being a member of my domain and if not the switch won't active the port to allow a DHCP lease conversation to happen.

 

[BackupGurus]

markettm, If you have Cisco switches why not create a separate VLAN for consultants and have two separate zones-One RADIUS controlled, one for your consultants. On your routers config your ACLs so that only your Radius-enabled VLAN routes to the network and the 'consultant' VLAN only routes to the Internet. This will solve worm propogation.

This, coupled with an inspection policy for any network-resident PCs should solve the problem permanently. Only allow those users that have qualified (e.g. no worms, virii, antivirus running and updated, etc.) setup for RADIUS authentication.

From the sounds of things managing your network off of allowed MAC addresses doesn't seem feasible.

Dave

http://www.easiestfilesystem.com

 

[markettm]

Thanks for the followup Dave. If I ACL off the consultants to just being able to route to the internet, my thinking is to not give them access at all.

I have a number of traveling users going to from site to site, so setting up reservations for all those on multiple subnets would be a management nightmare.

I also toyed with the idea of shutting off ports on switches, but we'd be called constantly when a person arrived at a site and needed a port activated. I need to have them all activated since I never know how many road warriors will be in any office at any given time.

Can't seem to be able to enforce just a written policy of not letting any outside machines to attach to our network at these remote sites.

I'm leaning more towards forcing the machine to authenticate via PEAP through the switch and my IAS/RADIUS and then if authenticated let the DHCP conversation happen. Only thing I worry about is latency between these remote sites and my IAS here.

 

[GlenJohnson]

The problem is consultants who come in and plug in their laptops.

Can't create a group policy called "Consultants" where they would log in, and once the policy "Consultants" comes up, they get scanned?

Glen A. Johnson
If you're from Northern Illinois/Southern Wisconsin feel free to join the Tek-Tips in Chicago, Illinois Forum.

TTinChicago
Johnson Computers

 

[markettm]

Hi Glen, thanks for your reponse. This would work if all users who came in were domain users. I'm having issues with non-domain users coming in with non-domain member machines and simply plugging into a network port and picking up an IP address.

They're not logging into the domain obviously at that point so no policies coming down on them.

Damage is already done if they are infected.

 

[GlenJohnson]

What's protecting you from viruses?

Glen A. Johnson
If you're from Northern Illinois/Southern Wisconsin feel free to join the Tek-Tips in Chicago, Illinois Forum.

TTinChicago
Johnson Computers

 

[ricpinto]

Assuming everything is domain base and no share can be access by a guest user then the only way for them to get interested in your network is the internet connection or printing. So if you can let internet connection/printing available only to authenticated user then they will be discourage to plug their laptop next time. It's really difficult to protect the network from the inside especially if you leave a malicious guy with a laptop that is connected to your LAN. He can just trick/persuade on unsuspecting user to provide a password or something, sooner or later.

 

[BackupGurus]

Guys, group policy is well off base b/c markettm is hitting the nail on the head about worms. I wouldn't be too concerned about latency from remote sites...even VPN sites would have a total round trip latency under about 80ms (unless you're crossing the big pond).

Cisco Security Agent could redirect consultants to a DMZ based upon service pack level or running applications. You can also set it to put people in the DMZ until the agent is identified and/or the machine is clean. You could also do the same thing with my previous post and limit the services on the DMZ. Or, add additional network interfaces and do port filtering on any of the DMZ machines.

Regardless, this Group Policy nonsense would do nothing to protect against a worm. The worm would be actively spreading before group policy could even kick in...not to mention all of those PCs that aren't domain members.

 

[markettm]

Thanks BackupGurus. I had a discussion with our Cisco rep last week and they are coming out with a new product to help just this situation.

He also alluded to the fact that latency may not be as a big a factor as I had initially thought. They have a more formal product coming out for the switch level end of summer, so I'm waiting to get some white papers on it.

Thanks everyone for your input here!