On Wed, 2005-12-21 at 11:59 +1000, Murad Talukdar wrote: > Hi, > Is there a way to stop a W2003 DHCP server from giving out leases for IP's > if a machine does not belong to the domain? > Or is this a fruitless question that someone simply needs to point out > something very simple to me.
In short, no - most of the available solutions to this problem fall into one of the following categories: a) uses another technology to compensate for DHCP's lack of security (ports locked by MAC address, radius, IPSec, etc) b) relies upon other insecure technologies (eg. reservations based on MAC address) c) is proprietary (most of the 'secure dhcp' solutions). In many instances, solutions fall into more than one category - Cisco produce a technology known as Network Admission Control (http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html) which falls into C and A, but which would quite effectively prevent rogue clients causing damage, if this is what you're trying to accomplish. Cisco also have something called 'DHCP snooping', which is simpler and addresses the problem a little more directly (but is still proprietary). These work quite well, but are expensive if you don't already have a cisco infrastructure. In a windows environment, I'd be looking at Server and Domain Isolation using IPSec (http://www.microsoft.com/technet/security/topics/architectureanddesign/ipsec/default.mspx). Although this doesn't solve the problem, it mitigates it to some extent by securing a network against non-domain clients (isolating higher-level protocols like samba/cifs and kerberos from clients connected to the network at a lower level), and could be used to protect clients against man in the middle attacks as well. It isn't a panacea, and won't stop denial of service attacks, but it should theoretically prevent unauthorised access to resources (and man in the middle attacks) from all but the most determined and skilled of attackers if implemented properly. Obviously, neither Cisco NAC or IPSec prevent attacks levied by malicious domain clients with poorly configured policies or which have been compromised in some other way (or have a malicious user). There is an RFC for authenticated DHCP (RFC3118), but it hasn't ever been implemented that I know of - it would even be possible to incorporate an authentication mechanism into AD using vendor extensions for regular DHCP and a GPO which once connected to the domain (ie. you'd have to initially propagate the GPO and the authentication mechanism to the client physically/logically or have a segment for which this was turned off) used a key to turn off talking to unauthenticated dhcp servers. Alternatively, you could enable a far more aggressive firewalling policy when connected to an unauthenticated DHCP server, and only allowed things like kerberos and cifs when connected to a lan segment serviced by an authenticated DHCP server. (Similar to existing policies which are applied based on a slow network link) DHCPv6 (DHCP for IPv6) has authentication built into one of the more recent RFCs, but this is obviously not really much help, and it seems likely that most small(ish) IPv6 networks will be using stateless auto-configuration anyway, rather than implementing a full (stateful) DHCPv6 server! Most solutions are going to fall shy of ideal in some way, so it's really going to be a case of identifying your goals and finding something that best matches. Physical security of your building and careful port allocation on switches are almost always going to be a part of this. As a brief plug (because it's useful), I did a presentation on this which I've stuck the slides for online (www.jeremiad.org/download.shtml). The slides were based on a paper I've written which should be being published online at some point before christmas. Hope that helps! - James. > A machine can't join the domain if it doesn't have an IP first(chicken and > egg type thing) I can see that but obviously I'm missing something > here-perhaps it's a question of layers-the domain is working at a 'higher' > layer? > Kind Regards > Murad Talukdar -- James (njan) Eaton-Lee | 10807960 | http://www.jeremiad.org Semper Monemus Sed Non Audiunt, Ergo Lartus - (Jean-Croix) sites: https://www.bsrf.org.uk ~ http://www.security-forums.com ca: https://www.cacert.org/index.php?id=3
smime.p7s
Description: S/MIME cryptographic signature
