Windows Server

DHCP filters may reduce the risk of rogue devices

Windows Server 2008's DHCP engine has a filter that can reduce risk of rogue devices. IT pro Rick Vanover discusses this new feature.

One of the least glamorous parts of IT is tracking down a rouge system that received a DHCP address, especially if it is causing an issue on the network. IT pros have become good at looking at a MAC address and determining what type of system it may be. For instance, users may bring a wireless router from home into the office or install a virtual machine without any protections on the network.

Windows Server 2008 R2's DHCP engine introduces a MAC address filter engine. The filter is pretty cool; it allows you to specify wildcard MAC address ranges to allow or deny address assignment on the network.

For example, take the requirement to prohibit Hyper-V, VirtualPC, or VirtualServer virtual machines from receiving IP addresses on your network. Figure A shows how you can do this with the filter. Figure A

Click the image to enlarge.

For the specific case of virtual machines, I created a scorecard of the MAC address types and the associated hypervisors.

Clearly, the DHCP filters are not bulletproof. Most hypervisors and wireless devices let users spoof MAC addresses. But chances are, this will knock out most of the users who could potentially do the least desirable things on your network. In the case of wireless devices, determining the organizationally unique identifiers (OUIs) for Linksys, Netgear, D-Link, and other products may be a good idea if you have a problem with unauthorized devices showing up on your network. A more strict approach is to set a filter only for the devices you expect to use on your network.

I think this is pretty neat for an otherwise boring service. Do you see yourself using this new feature? Let us know in the comments.

Stay on top of the latest Windows Server 2003 and Windows Server 2008 tips and tricks with our free Windows Server newsletter, delivered each Wednesday.

Automatically sign up today!

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

26 comments
spriefer
spriefer

Be cool to knock off the Iphones who are connecting to our wireless.

blarman
blarman

I can't see how this would work unless you have a really locked down environment and all your networking hardware, PC's and laptops come from specific vendors. Even then, not discounting spoofing, some vendors have multiple MAC address ranges. I understand you're trying to increase security, but this seems to me to be an administration nightmare. It would really help if the article were longer and went through a scenario as example.

Bogdan Peste
Bogdan Peste

Nifty trick...if you have a company of about 20 employees...and visitors/clients are connected to a different segment. Besides, failure to obtain an IP from DHCP hardly means limiting someone access to the network, because they can always manually set network settings. I don't find it scalable. A better solution is user/machine authentication. Configure your switch ports for 802.1x authentication, and put non-authenticating ports to a different VLAN, for visitors, where you can restrict access to resources.

Maurice Butler
Maurice Butler

Hi, In the past I have used reservations to control rogue devices. Devices I know about have a reservation, with good gateway etc.. Devices I don't know about get a C class address with access to a virus device that allows that machine to be scanned. Unless the user configures it to a fixed ip, manual entered gateway it is mostly under control. The DHCP filters are going to have the same problem with manually configured fixed addresses. - Nice Idea

chuckedson
chuckedson

The 802.1x protocol, or "dot1x" protocol was originally designed for wireless authentication, and is available in most business class 10/100/1000 switches. In a nutshell, when a device is plugged into a dot1x enabled interface (or a connected device powers on), the switch challenges that device for a username/password using the EAP/PEAP protocol. The switch passes the credentials entered by the user (or cached credentials for a currently logged on user) to a RADIUS server (like Free RADIUS or MS IAS for AD integration) for authentication. The RADIUS server validates the credentials and sends back a RADIUS-ACCEPT or RADIUS-REJECT to the switch, along with other possible parameters, like what VLAN to put the machine/user in, or even a host integrity result (i.e. is Antivirus installed, up to date, and running?) You can configure what type of traffic is allowed on the port before authentication. Most of the time people only allow DHCP and EAP/PEAP traffic to pass before the port is authorized. You can configure the port to do different things when an authentication failure occurs For instance, "Close Port". "Switch to Guest VLAN" is a popular one - allowing vendors and other guests access to a VLAN that is configured to only have Internet access, but not access to internal resources. On most switches, you can configure reauthorization on the switch interface (every "x" seconds, reauthorize). The Windows supplicant will use the current logon credentials automatically, so this is transparent to the user. And finally, the 802.1x protocol will attempt to authenticate a device by its MAC address if the EAP/PEAP challenge is not answered. You can add a MAC address list to most switches in local database. If the switch cannot find the MAC address locally, it will pass it up the line to the RADIUS server. If the MAC address is found anywhere, it will be allowed access - this good for printers, VOIP phones and other devices that do not have a supplicant that can answer the EAP/PEAP challenge. There is much more to this protocol, and space is limited here, but in a nutshell using the 802.1x protocol will make your network more secure, because you can control who and what gets on and where they can go in your network.

kevaburg
kevaburg

I'm talking about the machines physically connected to the network. The MAC address is examined before any IP address. In that way even wireless devices can be controlled. Individuals would be granted access based on their respective entries within the active Directory and not from the switch itself. It is actually very scalable and requires only the switch port of a new machine to be brought up and that new device to be booted to register its MAC in the amended table.

MrRich
MrRich

I'd like to see a write-up on that. Mostly I disable 802.1x in Windows because it seems to cause a communication problem with our domain controllers.

kevaburg
kevaburg

...but what does asdf mean?

kevaburg
kevaburg

...isn't restricting access at Layer 2 much more appealing than restricting it at Layer 3? The reason I say that is because any machine could have a different address based on lease durations. In this scenario I would suggest that reservations could cause more administrative effort than simply denying a rogue machine (PC etc) access to a switchport in the event that a MAC address doesn't add up.

sico_real
sico_real

Nice post, that explains perfectly how 802.1x works. I want and I hope to implement that in but do you or somebody knows if in HP Procurves I can keep some ports as untagged and other with 802.1x?

jjcanaday
jjcanaday

I'm really intrigued by your very clear explanation. I'm preparing to upgrade our network this quarter and, I would love to have some implementation information. Could you (or someone else) save me some searching?

hanoch
hanoch

one question - what do yo do when a user is activating the "clone pc MAC address" feature found in most devices thet can use DHCP ?

ITGuy2k
ITGuy2k

Cheers for the explanation, very interesting and informative :)

Bogdan Peste
Bogdan Peste

..what you mean when you say "..granted access based on their respective entries within the active Directory". Where is AD in this scenario?

rsprott
rsprott

Through your CA have PC's auto enroll to get a computer certificate. The layer 3 switch then checks passes that info to the IAS servers for acess. If they pass the switch allows the PC on the LAN if not... We move them to a guess VLAN.

Bogdan Peste
Bogdan Peste

I can imagine the problem you are describing is Server certificate validation for PEAP(which by the way you can set to ignore through Group Policy). I have this in a working environment, with Windows Server 2008 Domain Controllers. I also enabled the Certification Authority(this solves the certificate validation problem) and Radius roles on one of the DCs.

howard_davis
howard_davis

I am seriously considering implementing this at our school. Small Charter school that had really horrific security when I came in, now I would like to upgrade when we move to our new building. Tips? Tricks? Pros? Cons? Alternatives? Thanks!

mford66215
mford66215

asdf is what you type in the subject line when you have no subject. http://www.asdf.com/whatisasdf.html I found it on the internet, it must be true! woah, this got posted into the wrong discussion chain entirely! bummer.

chuckedson
chuckedson

Yes, with most business class switches you configure 802.1x on a per-port basis.

chuckedson
chuckedson

Oops I put in some tags by accident on the above post, so some info was stripped out when it went to post. You need to tell the switch where to go for RADIUS authentication. This goes under the aaa authentication section: radius server host [ipaddressofRADIUS] auth-port 1812 acct-port 1813 key [RADIUSserverkey]

chuckedson
chuckedson

The following commands represent the minimum required to setup 802.1x on a Cisco switch running IOS. 1. Setup the VLANs for use: conf t vlan 10 name production vlan 20 name quarantine vlan 30 name guest end 2. Setup aaa authentication: conf t aaa new-model aaa authentication login default group none (may not work on certain IOS see Cisco documentation) aaa authentication dot1x default group radius aaa authorization network default group radius radius server host auth-port 1812 acct-port 1813 key 3. Setup dot1x: conf t dot1x system-auth-control-enable dot1x guest-vlan supplicant (IOS 12.2(25)SEE or later) int fa0/23 (where fa0/23 represents your interface, i.e. fa0/23 equals fastethernet module 0 port 23 ? common to small workgroup switches) switchport mode access switchport access vlan 10 (where 10 = default vlan for port) dot1x port-control auto dot1x reauthentication dotx1x guest-vlan 30

chuckedson
chuckedson

Well, I suppose if a rogue computer/user on your network was able to learn the MAC address of a device that was entered into the MAC Address Bypass table or RADIUS server, then they could potentially be allowed in. The best would be NOT to use MAC Address Bypass at all . . . When shopping for VOIP phones, look for ones that have a built-in supplicant, so you can take advantage of the full 802.1x protocol, where you enter in a username/password. As for printers, configure the interface that the printer connects to with port security, so only the printer's MAC Address can connect to that port, and turn on 802.1x on all the other switch interfaces. The key here is to make sure that your wiring closet (IDF) is LOCKED, and that your security department does a walk through several times a day. As long as the switch is physically secure, you will be fine.

kevaburg
kevaburg

Personally I have never worked in an environment where a DHCP server has been in place on a Windows server and Active Directory has not been an integral part of the network. DHCP does not need to be on an AD DC but the fact AD has been installed was for me an assumption based on experience.

kevaburg
kevaburg

isn't it adding a layer of complexity that doesn't need to be there? I am simply saying that if the port has an allowed MAC address attached to it, then allow it. If not then close the port down. And then we are also assuming that a CA is in place in the first instance. Not everyone has it.

Editor's Picks