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

[Tyler Kilian]

Some switches have security features such as DHCP Snooping, that can help mitigate the threat of rogue DHCP servers.   Some common sense network segmentation can also help mitigate the issue by reducing the scope of issue.   The overall point being that there are some ways to protect yourself.

Tyler

On Sep 13, 2012, at 1:01 AM, Bexley Hall <bexley401 at yahoo.com> wrote:

> 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
> 
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org