DHCP ENCRYPTED TO DOMAIN MEMBERS

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Good Day.

We Have a big Client, and we need to implement DHCP security, the security
consist is the only the domain members can have an IP via DHCP, the visitors
computers cannot obtain an IP via DHCP. I don´t know how implement this
solution, I Was try whit IPSec without results.

Thanks for Help me.
 
Well, you cannot use IPsec directly as the machines do
not yet have a configured IP stack.
You may want to look into a quarantine style use of an
initial vlan handed out to any machine by dhcp, followed
by configuration with an IP validly routable on the corp
network after checks.
Alternatively, and painfully, you could control this by
having all IPs in the DHCP scopes reserved by MAC
(Note: this one is fallible/spoofable).
 
Thanks Roger.
Can I Encrypt the acknowledge ip message by IPSec? or Make Secure the UDP
port 67 an 68?

Thanks for help me, have a nice day



"Roger Abell" escribió:
 
Oseas Millan ha scritto:
Good Day.

We Have a big Client, and we need to implement DHCP security, the security
consist is the only the domain members can have an IP via DHCP, the visitors
computers cannot obtain an IP via DHCP. I don´t know how implement this
solution, I Was try whit IPSec without results.

Thanks for Help me.
Click to expand...
Hi, normally you can only do this with network components, for examples
with CISCO eth2VLAN. A trash VLAN is selected as default when the
MACisn't know by the system. If the MAC is know the compuer will connect
to the configured VLAN. This is not valid only for DHCP address but also
for static.

Ciao
Maurizio
 
That can not be done with ipsec. However if all the domain computers are
Windows 2000/2003 or XP Pro you can use ipsec in the domain to prevent non
domain computers from accessing any domain computer with a ipsec "require"
policy. Ipsec is not something that can be implemented without some planning
and testing though and domain controllers must be exempt from ipsec policy
that use negotiation security by adding their static IP addresses to a rule
that has a permit filter action. The link below is to a great paper on
ipsec. It is for Windows 2003, but much better than anything I have seen for
Windows 2000. Almost all of it applies to Windows 2000 also except for
mainly the extra protection for startup, default exemptions, no ipsecmon mmc
snapin, and command line tools like netsh can not be used for W2K ipsec. The
article can also be downloaded for much easier reading.

http://www.microsoft.com/resources/.../all/deployguide/en-us/DNSBJ_IPS_OVERVIEW.asp
http://tinyurl.com/2v8na -- same link as above shorter.

Using DHCP to manage security is not that strong a measure as it is easy for
someone to configure their computer with static IP to access the network.
You might also look into switches that can filter ports by mac address or
better yet use 802.1X authentication for port access. 802.1X however
requires compatible operating systems, and an IAS and Certificate Authority
on the network of which Windows 2000/2003 both can do. Mac address filtering
can increase network security and keep out the idle curious but not truly
malicious user. The link below shows how 802.1X can be used to protect a
network and provide guest access also if needed. --- Steve

http://www.hp.com/rnd/pdf_html/guest_vlan_paper.htm
 
I think you are trying to head down a fruitless road.
Use of a quanantine vlan is the most direct solution.

(Bootp and its udp traffic has nothing to do with a
DHCP lease negotiation.)
 
Well, one caveat here.

You can't use IPsec to secure communications from a client to a DC, so the
client policy would list the DC's in the exemption list. You could however,
use DC to DC IPsec and on the DC, the exemption list would *not* contain
DC's...

I'd recommend using 802.1x *with* IPsec since they are very complimentary.

I'd also recommend performing a proper threat model, to determine exactly
what the threat is you are trying to mitigate. Work your way through the
attack tree, then come up with a clear picture of what you can and can not
do with the approach you select.

I'll also point out that VLAN's, while ACL'd, are *not* security constructs.
They are traffic segmentation constructs. Woe be unto the person who uses
multiple VLAN's on the same switch fabric and presumes that one is more
secure than any other. Ettercap 0wnz all on a switch. :)
 
Back
Top