Re: IP address assignment problem



Davy Davidson wrote:
Hi,
I have a little problem and seek for ur thoughts, let's assume I'm in a very open environment where everyone can very easily try to get his/her laptop on the network and IP addresses are assigned by a DHCP server and we are in a domain environment, how do I prevent machines that are not part of our domain to be assigned an IP address?
As has been indicated in previous responses to your question, there are a couple of approaches to this problem.

The most basic is to do what you ask - use MAC addresses to prevent machines that aren't registered from getting IPs leased. The downsides to this method are that it is expensive to administer (since you need mac registrations for every workstation on your lan), and only provides a trivial level of security, since it is very trivial to get the MAC address of a machine which is registered (or just assign yourself a static address). This approach doesn't stop your rogue clients from connecting to other clients, but merely doesn't give them the information they normally need to do so.

There are some "Secure DHCP" products, but I haven't yet seen any that actually solve the problem (and some of them seem simply to use MAC-based assignment but with a slightly less clunky interface than the microsoft DHCP mmc), so I'd be very wary of them and the promises they make.

MAC Filtering, port locking, or any of the other names by which it's referred to use MAC addresses again - but at the switch level. This is a good deal more clumsy, since you generally have no centralised database to maintain and frequently your MAC registrations will be done on a port-by-port basis, but has the slight advantage that - at least in theory - *no* traffic will be allowed by the switch for the wrong mac address. The benefit of this approach is that it should be marginally harder to get a legitimate MAC to use (you need *precisely* the right one for the given port and your opportunities for sniffing are limited), but stealing an existing workstation's network socket and reading the MAC address from the label on the back of the unit really isn't that hard. Effort required, significant.. ease of bypass, minimal.

Moving up a level, then, what you really want to do is accept that DHCP is insecure and design your network such that it assumes this to be the case. Most basically, with a well-segmented network that's kept up to date, you may decide this is an acceptable risk. Assuming that you've crossed this bridge and decided it isn't (no, I don't think I really think so either), we move on to what else we can do.

There are two basic methodologies you can apply to do this. The first method is to use authentication at the switch level, using 802.1x, designed for just this purpose. Using 802.1x, your workstations authenticate through the switch to a radius server (IAS, steel-belted radius, freeradius, whatever..) before they are allowed any connectivity. This authentication can use X.509 certificates, computer account credentials from AD, or whatever else you'd normally configure radius to authenticate with (these are the big two). Windows has a built-in 802.1x supplicant, and (in XP, at least) it's enabled by default, so assuming you allow connections from computer accounts, this can be an entirely server/switch-side implementation if you have XP (and probably 2k) clients - workstations should "just work" with the new system. (Disclaimer: Testing, controlled environment, etc etc.)

Depending upon your equipment (to avoid much pain this approach will *require* decent managed switches from the likes of 3com, cisco, nortel, HP, et al), you may also be able to do fun stuff like allocate different machines different vlans, so all clients in your Engineering OU get dropped into the engineering vlan (and consequently the engineering broadcast domain/subnet) irrespective of where onsite they plug in. This, to my mind, as well as the ability to arbitrarily chop machines network access off at the switch fairly quickly right from AD (depending upon the interval you configure for radius re-authentication) is a really nice advantage of implementing this solution. Once you have it up, there's lots more you can do with it.

Many higher-end access points such as the cisco aironet units and the HP Procurve access points (which have the slight benefit of having a lifetime warranty - hurrah!) also do similar for wireless using WPA-radius or WPA2-radius, either with multiple SSIDs (engineering SSID, development SSID, all from one physical unit, each connecting to a different vlan), or using radius authentication and data stored in AD to dictate which VLAN a given account is tied to. This will require a hotfix on XP clients to support WPA2 (KB893357).

Authentication in this manner is great, but may cause problems with older machines without a supplicant for 802.1x (or, if you configure WPA2, machines whose wireless drivers don't support it), and support for radius authentication requires expensive equipment. Getting radius working properly and reliably with wireless equipment can also be slightly painful at times. There's dynamic WEP too, but WPA2-Radius is so much nicer it's worth buying new network cards.

The second method in this respect is to use something like IPSec (which is what NAC/NAQC use) to effectively enforce a host-based firewalling policy across groups of machines. In this manner, you can force your domain clients *only* to communicate to other domain clients that also have IPSec configured. Microsoft call this "Server and Domain Isolation" using IPSec, and if you google for that term, you will find some great support material from technet that goes through how this works. The same applies to the preceding method regarding wireless & radius, if you search for "securing wireless lans" - the first two hits are the PEAP and Passwords documentation and the Certificate-based documentation from technet. They're great - worth a read even if you don't intend to implement it (or if you're just interested in IAS).

Last but not least, there are the most expensive options - options like cisco NAP (Network Access Protection) which integrate centralized authentication with policy enforced using a supplicant on the host. These are probably overkill based on your requirements, since you probably don't need to enforce antivirus policies &c on your clients before granting them access to particular portions of the network. These options will probably require similar (or larger) amounts of infrastructure to that put in place for a radius solution (which is free if you have windows licenses - IAS, the microsoft AD-integrated radius server is a windows component), in addition to server infrastructure for your chosen solution, on top of compliant network hardware at any tier of your network you need to enforce this protection on.

Overall, I think the IPSec methodology is probably your best bet if you don't have all-managed switches. It doesn't protect against Denial of Service against your clients or network stack-based attacks, but it should stop clients from connecting to network resources (even with credentials), unless your intruders have some fairly high-level technical skills and administrative access to workstations or servers to see how your solution is configured and steal/copy credentials or certificates. At that point we're entering the realms in which a determined intruder would be just as well using an authorized workstation for nefariousness anyhow.

Why was DHCP never retrofitted with authentication, you say? Well, actually, it sort of was - RFC 3118 sets out Authentication for DHCP - it's just that no-one has ever bothered implementing it! (And if they had, it still wouldn't solve the static assignment issue raised at the beginning of my e-mail).

Hope that helps. Not to plug it too much, but if you're interested, I wrote a paper on why DHCP is insecure (and why it deserves more love). It, and a set of presentation slides on the same topic, are online at http://jeremiad.org/download.shtml

- James.
Thanks

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! http://search.msn.com/


---------------------------------------------------------------------------

---------------------------------------------------------------------------





---------------------------------------------------------------------------
---------------------------------------------------------------------------



Relevant Pages

  • Re: wireless network disconnects when using IEEE 802.1x authentica
    ... since it gets encrypted before it leaves the wireless NIC ... For a home network or small ... >> Change that authentication key say every six months. ... >> RADIUS server to do that, and it works best if you've got an Active ...
    (microsoft.public.windowsxp.security_admin)
  • Re: wireless network disconnects when using IEEE 802.1x authentica
    ... > If your hardware can perform WPA PSK, ... > Change that authentication key say every six months. ... > individually setting keys in clients. ... > RADIUS server to do that, and it works best if you've got an Active ...
    (microsoft.public.windowsxp.security_admin)
  • PEAP Authentication in IAS
    ... I'm using a Procurve 2650 as Radius Client, ... Authentication in the network configuration of Windows XP and CHAP ...
    (microsoft.public.windows.server.active_directory)
  • Re: Lock down LAN
    ... When you use these switches and configure them as RADIUS clients to ... authentication fails, the client computer does not receive an IP address ... and the user cannot access the network. ... But if you have people accessing your LAN from home or other locations with ...
    (microsoft.public.internet.radius)
  • RE: Kerberos and NTLM Authentication protocol
    ... authentication to cifs shares via ip address, ... A network is ... Kerberos and NTLM Authentication protocol ... In a domain with DC 2003 and clients all windows 2000 and XP: ...
    (Security-Basics)