Prevent unauthorized DHCP servers/devices.

In the past 3 years we have had 3-4 incidents where employees had mistakenly
connected DHCP servers/appliances to our internal network which of course
caused all kinds of chaos when users would not get correct IP addresses
assigned. This is quite a chink in the network as it leaves us totally open
to this type of incident and it can be a bit of a pain to track down the
offending device.

We have a Windows 2003 AD environment with our PDC acting as the sold DHCP
server and our network is comrised entirely of Cisco network devices (C6500
core switches and C3750 end point switches). Sadly, the AD function of
allowing authorized servers with DHCP does little to stop unauthorized
devices on the network from server addresses to clients that request them.

I have heard of a few options - dhcp snooping, port filtering, etc.Can
anyone recommend a 'silver bullet' approach/solution to nip this one in the
butt? Thanks, appreciate any advice.

"Barkley Bees" wrote:

> In the past 3 years we have had 3-4 incidents where employees had mistakenly
> connected DHCP servers/appliances to our internal network which of course
> caused all kinds of chaos when users would not get correct IP addresses
> assigned. This is quite a chink in the network as it leaves us totally open
> to this type of incident and it can be a bit of a pain to track down the
> offending device.
>
> We have a Windows 2003 AD environment with our PDC acting as the sold DHCP
> server and our network is comrised entirely of Cisco network devices (C6500
> core switches and C3750 end point switches). Sadly, the AD function of
> allowing authorized servers with DHCP does little to stop unauthorized
> devices on the network from server addresses to clients that request them.
>
> I have heard of a few options - dhcp snooping, port filtering, etc.Can
> anyone recommend a 'silver bullet' approach/solution to nip this one in the
> butt? Thanks, appreciate any advice.
>
>
I have not been able to find a 'silver bullet' to prevent rogue DHCP servers
interfering with a text-book Windows LAN.

There are two lead bullets which can be effective:

1) Make it a dismissal offence to plug anything into an Ethernet port owned
by the organisation that has not been approved and configured by the Sys
Admin. Since these devices are typically routers, modems, firewalls, and
such, it is a major security issue if they are installed on an ad-hoc basis.
(In the UK we are required to safety test any employee-owned electrical
device plugged into a power socket, just in case an employee is shocked by
his own mobile phone charger!)

2) Disable DHCP servers and clients. Configure your LAN with a 'hosts' file
for name resolution, and configure client routing table as required in the
logon script.
--
Regards,
Newell White

There is no *software* solution to stoping humans from bringing something to
work and plugging it in. Just like Newell said in his point
#1,...Management has to control their humans,...they are their humans,..they
hired the humans,...they have to control their humans.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"Barkley Bees" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In the past 3 years we have had 3-4 incidents where employees had
> mistakenly connected DHCP servers/appliances to our internal network which
> of course caused all kinds of chaos when users would not get correct IP
> addresses assigned. This is quite a chink in the network as it leaves us
> totally open to this type of incident and it can be a bit of a pain to
> track down the offending device.
>
> We have a Windows 2003 AD environment with our PDC acting as the sold DHCP
> server and our network is comrised entirely of Cisco network devices
> (C6500 core switches and C3750 end point switches). Sadly, the AD function
> of allowing authorized servers with DHCP does little to stop unauthorized
> devices on the network from server addresses to clients that request them.
>
> I have heard of a few options - dhcp snooping, port filtering, etc.Can
> anyone recommend a 'silver bullet' approach/solution to nip this one in
> the butt? Thanks, appreciate any advice.
>
>

I guess End Point security tied to network access control is the solution to
this. Things can't connect to your network unless they pass your policy
rules.
On the specific question of DHCP, as it is an OS-agnostic network service it
would have to be the network that stopped it.
Anthony,
http://www.airdesk.co.uk

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> There is no *software* solution to stoping humans from bringing something
> to work and plugging it in. Just like Newell said in his point
> #1,...Management has to control their humans,...they are their
> humans,..they hired the humans,...they have to control their humans.
>
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
> "Barkley Bees" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> In the past 3 years we have had 3-4 incidents where employees had
>> mistakenly connected DHCP servers/appliances to our internal network
>> which of course caused all kinds of chaos when users would not get
>> correct IP addresses assigned. This is quite a chink in the network as it
>> leaves us totally open to this type of incident and it can be a bit of a
>> pain to track down the offending device.
>>
>> We have a Windows 2003 AD environment with our PDC acting as the sold
>> DHCP server and our network is comrised entirely of Cisco network devices
>> (C6500 core switches and C3750 end point switches). Sadly, the AD
>> function of allowing authorized servers with DHCP does little to stop
>> unauthorized devices on the network from server addresses to clients that
>> request them.
>>
>> I have heard of a few options - dhcp snooping, port filtering, etc.Can
>> anyone recommend a 'silver bullet' approach/solution to nip this one in
>> the butt? Thanks, appreciate any advice.
>>
>>
>
>

Yea, if you have the money and the infrastructure to do it,..and the
expertise. Most that I run across that ask this question have none of the
three and those that do have all three already know to do it and aren't
asking.

The problem I have here is that they would never spend the money on it and
my biggest offenders are people who come in with laptops,..who are sitting
next to one of the Managers who tell them to "hook it up" with the thinking
that "It works at my house,...it should work here". Then when the ISA
Server doesn't let them to the Internet because thier machines isn't a
domain member, and they're not using a domain account,...I get the call
asking "What's wrong with our network?"

But I guess in the end they may have gotten an IP Config but it didn't
provide them with anything usefull because security does "begin and end" at
Layer3. However there is still the virus infection risk.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"Anthony [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I guess End Point security tied to network access control is the solution
>to this. Things can't connect to your network unless they pass your policy
>rules.
> On the specific question of DHCP, as it is an OS-agnostic network service
> it would have to be the network that stopped it.
> Anthony,
> http://www.airdesk.co.uk
>
> "Phillip Windell" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> There is no *software* solution to stoping humans from bringing something
>> to work and plugging it in. Just like Newell said in his point
>> #1,...Management has to control their humans,...they are their
>> humans,..they hired the humans,...they have to control their humans.
>>
>>
>> --
>> Phillip Windell
>> www.wandtv.com
>>
>> The views expressed, are my own and not those of my employer, or
>> Microsoft,
>> or anyone else associated with me, including my cats.
>> -----------------------------------------------------
>>
>> "Barkley Bees" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> In the past 3 years we have had 3-4 incidents where employees had
>>> mistakenly connected DHCP servers/appliances to our internal network
>>> which of course caused all kinds of chaos when users would not get
>>> correct IP addresses assigned. This is quite a chink in the network as
>>> it leaves us totally open to this type of incident and it can be a bit
>>> of a pain to track down the offending device.
>>>
>>> We have a Windows 2003 AD environment with our PDC acting as the sold
>>> DHCP server and our network is comrised entirely of Cisco network
>>> devices (C6500 core switches and C3750 end point switches). Sadly, the
>>> AD function of allowing authorized servers with DHCP does little to stop
>>> unauthorized devices on the network from server addresses to clients
>>> that request them.
>>>
>>> I have heard of a few options - dhcp snooping, port filtering, etc.Can
>>> anyone recommend a 'silver bullet' approach/solution to nip this one in
>>> the butt? Thanks, appreciate any advice.
>>>
>>>
>>
>>
>
>

In article <(E-Mail Removed)>, (E-Mail Removed)
says...
> In the past 3 years we have had 3-4 incidents where employees had mistakenly
> connected DHCP servers/appliances to our internal network which of course
> caused all kinds of chaos when users would not get correct IP addresses

Hi There is a little bit more dangerous behavour when someone bring
up rouge DHCP. At client computers "only !" is changed address for DNS
servers and after that there is no name resolution, no access for
resources because client cannot find DC etc. That can be seen very often
on Intel network cards. I think that this is very stressing and I wonder
how can be possible that DHCP client change only address for DNS servers
and not IP, gateway etc. ?

DHCPLocator - DHCPLoc.exe from Support tools is very useful tool to find
out rouge DHCP servers on network.

From my point of view, when you must to authorize DHCP in AD is just a
waste of time.

What I think would be really cool is if a business that had something like
that happen to them would "sue" the offender for the finactial equivalent of
the "down time" it caused due to their neglignet behavor,...and then have
that beome publicly known that someone was successfully sued for doing
that,...it would stop a lot of that stuff.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"Barkley Bees" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In the past 3 years we have had 3-4 incidents where employees had
> mistakenly connected DHCP servers/appliances to our internal network which
> of course caused all kinds of chaos when users would not get correct IP
> addresses assigned. This is quite a chink in the network as it leaves us
> totally open to this type of incident and it can be a bit of a pain to
> track down the offending device.
>
> We have a Windows 2003 AD environment with our PDC acting as the sold DHCP
> server and our network is comrised entirely of Cisco network devices
> (C6500 core switches and C3750 end point switches). Sadly, the AD function
> of allowing authorized servers with DHCP does little to stop unauthorized
> devices on the network from server addresses to clients that request them.
>
> I have heard of a few options - dhcp snooping, port filtering, etc.Can
> anyone recommend a 'silver bullet' approach/solution to nip this one in
> the butt? Thanks, appreciate any advice.
>
>