[Tfug] Static/Dynamic (IP,name) bindings

[Bexley Hall]

Hi,

--- On Wed, 9/12/12, unixmito at SDF.ORG <unixmito at SDF.ORG> wrote:

> > To that end, are there any downsides of using DHCPd (coordinate
> > with BIND) to manage this sort of thing?  I.e., specify "fixed"
> > addresses for those hosts that I really want/need to sit at
> > specific places /managed from the dhcpd instead of manually
> > coordinating static assignments in each node with static
> > A and PTR records in the name server.
> 
> http://answers.oreilly.com/topic/84-how-to-add-static-hosts-to-dhcp/
> 
> I think this will help.

Yes, I know how to implement it -- just not sure of the risks
associated with it!

E.g., I would *assume* most organizations do *not* assign static
IP's *at* each workstation.  Rather, administer them centrally
with workstations configured to accept an IP *imposed* on them.
And, "locking down" those configuration options by simply
denying the casual user access to privileged accounts on "his/her"
workstation.

Given how easy it is to carry a laptop into an organization;
And, how easily that person can have a privileged account *on*
that laptop (running WhateverOS);

What's to stop someone from setting up a rogue DHCP service on
that laptop, plugging it in to a convenient network jack and
hijacking any workstations "unfortunate enough" to be listening
to it's counterfeit replies?  (i.e., that individual could probably
also surreptitiously walk around rebooting machines to increase
their chances of being snared by his bogus service!)

AFAIK, there is no way you can even *monitor* that this is
happening!  Sure, the DHCP request is broadcast and visible
to every device on the subnet... but, the *reply* (from the
rogue server) will be routed directly to the client (assuming
switched fabric) and not visible to the legitimate DHCP server
(i.e., it won't know that the client has "successfully"
accepted a reply from the rogue server in preference to the reply
that was legitimately offered!)

E.g., I've got about 45 diskless "appliances" that I need to
centrally administer (boot images, names, IP's, routing, etc.).
And, several "diskless workstations".  Not to mention "regular"
workstations (different vendors, OS's, etc.).  The COTS boxes
give me very little control over what I can do in terms of
boot protocols (e.g., I don't think any of them support the
authentication options of DHCP).

I can mitigate the problem among the most crucial nodes by
keeping those on a separate, "private" subnet.  I.e., an
attacker would have to bring a screwdriver and start dismantling
things to make them vulnerable. (I already keep the access point
on its own subnet so I can filter things coming in/out via that
path)

But, this would be an expensive "solution" for *other* sites
deploying the same sorts of appliances.  I need to "co-operate"
with "normal" machines -- as much as possible.
 
> > I recognize there's a risk in the DHCPd communicating with
> > the name server (to register updates, etc.).  And, some risk
> > with clients communicating with the DHCP service.  If, however,
> > all of this sits behind my bastion host, do I have any *real*
> > risks to be wary of?
> 
> From my experience the only real danger that I see behind a
> relatively secured NAT is arp poisoning and similar tactics that 
> would redirect traffic from a host to use a poisoned DNS server.
> Polling the ARP table periodically vis a vis cron to check against
> a static reference would seem to help.

The most critical nodes communicate securely (shared secrets,
etc.).  And, look all the way *down* the protocol stack to
ensure nothing "funny" is happening on the wire (i.e., detect
attack attempts).

It seems like I need to extend this security envelope to include
the initialization protocols as well.  I.e., all the information
that DHCP/BOOTP/TFTP effectively conveys should be forge-proof (?)
 
> It's not quite clear what type of topology you've adopted in
> relation to what is represented by the nameserver and what isn't.
> But I hope this help /somewhat/.

Thx,
--don