2

We have visitors on our campus who bring their own laptops and devices and use our wireless and wired networks. When we receive a copyright infringement notice (typically BitTorrenting), we are required to quarantine that MAC address so that it no longer has Internet access. No matter what website it tries to visit, it is sent to a web page explaining to the user that the device has been quarantined.

We have thus far implemented this in ISC DHCP on Linux. We have multiple VLANs with one or more public-IP subnets and one RFC1918 quarantine subnet each. All clients are leased IPs in the public-IP subnet(s) unless you're in a list of known bad MACs. Then, you are sent to the quarantine subnet so that your traffic is unroutable on the Internet (you are isolated by subnet only, not by VLAN).

We would like to move to Windows DHCP in light of the IPAM role but I cannot figure out how to replicate this in Windows DHCP 2012 (Assign DHCP IPs for specific MAC prefixes on Windows Server 2008 R2 suggests it was not possible in 2008 R2), even while using policies.

So here's what I'd like: The administrator/help desk provides and maintains a list of MAC addresses that are to be quarantined. The DHCP server places those MACs into the quarantine subnet on the respective VLAN, no matter which VLAN the client is in.

I don't think reservations would work: We currently have about 300 registered bad MACs and about 12 VLANs. I don't want to make 300 x 12 reservations nor have to add 12 reservations per new MAC address. Not to mention all of the quarantine subnets are /24s.

We do not have NPS/NAC. You do not have to register your MAC address get network access. We use Cisco routers/switches.

Thanks.

Easter Sunshine
  • 246
  • 1
  • 5
  • 11
  • "When we receive a copyright infringement notice" - wouldn't it be easier to just block the ability to use torrents/p2p in the first place and not have to deal with getting such a notice? – TheCleaner Jun 28 '13 at 21:47
  • Some places do that, but that also blocks legal torrent traffic. E.g. same in game updates which use it, or the FreeBSD torrents which I usually keep running for weeks after a new release. I know that most of the torrent traffic will be pirated stuff, but blocking everything is an overreaction. – Hennes Jun 28 '13 at 23:39
  • We do not want to block BitTorrent or P2P; those are intentionally allowed on the network. We want to quarantine devices that have been compromised, botted, or partook in copyright infringement, whether via P2P or not. – Easter Sunshine Jun 29 '13 at 00:46
  • Interesting. Have a comparable issue here. Using ISC DHCP we are able to distict clients with known and unknown MAC. Known Clients get other IPs than unknown clients. We use the "deny-unknown-clients" and "allow-unknown-clients" for this purpose. This works very well. Nevertheless I want to switch to Windows DHCP server, because of DHCPv6. As a first step I would be happy to create two scopes, one for known and one for unknown clients with respect to MAC. –  Sep 17 '13 at 16:50

1 Answers1

2

The Microsoft DHCP server has no concept of a list of MAC addresses that are outside one of the configured DHCP scopes. I'm also not aware of any way to get the Microsoft DHCP server to return an IP address outside of the scope in which the DHCP relay agent's GIADDR address falls. I don't think you're going to be able to replicate what you had w/ the Microsoft DHCP Server.

As an aside: Before you consider handing-out IP addresses to public clients using a Microsoft DHCP server you may want to get a clear statement from Microsoft as to whether or not these devices need CALs. Microsoft has made contradictory statements about this. To be "safe" I always use a non-Microsoft DHCP server for public subnets.

Edit:

You're absolutely right that a DHCP superscope will allow IP addresses to be assigned to clients outside the subnet of the GIADDR that the relay agent passes. It's not a feature I've ever used in production but, even so, I feel like a bit of an ass for not thinking of it.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • Thanks for your advice about CALs for devices that are leased public IPv4s via MS DHCP. Unfortunately, neither we, our reseller of Microsoft software, nor our contacts at Microsoft can decipher Microsoft licensing. There is a way to get MS DHCP to return an IP address outside the scope containing the relay agent's IP. By grouping multiple scopes, say 2001:db8:bc:23::/64 and 2001:db8:bc:339::/64, into a superscope where the relay agent's IP is 2001:db8:bc:23::1, you can get the DHCP server to lease an IP to a client in the scope not including the relay agent. – Easter Sunshine Jun 29 '13 at 00:49
  • Agh! Yeah-- a superscope will do it. I've never used the feature in production so I didn't think about that. I'm dropping on an edit to make this answer suck less. – Evan Anderson Jun 29 '13 at 04:07