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

[Nathan Hruby]

That sounds really complicated.  Why not just make the DHCP server
update DNS vis DDNS using a preshared key?  Examples:
- http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
- http://hackerific.net/2007/12/24/dynamic-dns-with-dhcp-and-bind-9/

Yes, a rouge DHCP server could still poison your clients and do bad
things.  If you believe that's an attack vector that you're at risk
for, using WPA-enterprise on private WIFi, captive portals + traffic
limiting on public networks, port-based security / mac filtering,
802.11x, and good old good physical security are good things to do to
limit your risks.  Most of these features are available on
out-of-the-box consumer grade network hardware and only require a
minimal amount of setup (some features assume you have things like
ldap or radius available and may not be immediately useful).

HTH,

-n

On Thu, Sep 13, 2012 at 8:08 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi Robert,
>
> --- On Thu, 9/13/12, Robert Hunter <hunter at tfug.org> wrote:
>
>> > Yes, but that would only be common in enterprise scenarios.
>> > I suspect you won't find any SOHO kit with those features!
>>
>> Your "SOHO" argument doesn't exactly hold up.  Support for features
>> like VLANs, and firewalls are available on many consumer-grade routers
>> -- if not out-of-the-box, then possibly via custom firmware, (e.g.,
>> DD-WRT, or Tomato).  You could also roll-your-own (e.g., an Intel box
>> + NIC(s) + your favorite "unix"), or shop around for some old
>> enterprise gear.
>
> Sure!  But that assumes you have the skillset necessary to do
> this.  And, are willing to discard your existing kit in order
> to replace it with something with these capabilities.
>
> And, it still isn't a guaranteed fix.  E.g., plug the device in
> question directly into that laptop (or, use a dual-NIC laptop
> as a bridge) and the fancy switch doesn't help you at all!
> Once the code is loaded, remove the laptop and sneak back out
> of the house "innocently".
>
>> > You wouldn't want to run the risk of someone (friend/foe)
>> > surreptitiously installing a new image in your HVAC controller
>> > just by plugging in a rogue host that tricks the controller
>> > into accepting a new image from *it* instead of the *real*
>> > image server...
>>
>> I would start by reducing the exposure of your utility
>> network.
>
> Yes.  But, again, that assumes the consumer is aware of this
> risk, understands it and is willing to invest the time and
> money to make those changes.  "Why can't I keep things the
> way they are?"
>
> How many folks *actively* worry about their internet exposure?
> Or, information leaks from their cell phones?  etc.
>
>> > It seems that the only "safe" way of doing this is to use
>> > a more secure protocol.
>>
>> Probably overkill.  However, I agree that many commonly used
>> networking protocols are showing their age.  And security is one of
>> those things that needs to be addressed at a more fundamental level.
>> It's a matter of the "common case" changing.  Twenty years ago, if
>> you were running a computer network at home, you were probably
>> one savvyguy.  These days you risk annoying your guests if you
>> don't have WiFi.
>
> And, there is a growing confidence and acceptance of smart
> devices in and around the home.  Would you want to do anything
> *more* than plug in your new, Internet-enabled thermostat?  Or,
> would you piss and moan when you opened the box and found a
> long-winded discussion about how, as a new, proud owner of
> the Thermo9000, you also had to make the following changes to
> your infrastructure before you could *use* it?
>
>> And then you have to worry about those people who call themselves
>> "friends", but given the opportunity, would hack your home automation
>> systems.  Sigh.
>
> Or, folks who don't understand the consequences of their actions,
> malicious or otherwise.
>
> I.e., today, finding homes with this level of automation is
> pretty hard.  Security by obscurity is almost a viable approach!
> (No, not really!).
>
> But, once this sort of thing is more commonplace, I don't
> doubt you won't see the same sort of "problems" like folks
> joy(war)riding on open access points because their owners
> didn't think to change the SSID from "linksys" to something
> else, etc.
>
> If, OTOH, you make the product itself inherently secure,
> then you avoid these issues.  Sure, you don't make life
> any better for the workstations/equipment that still rely
> on legacy protocols.  But, that's not *your* (my) goal!
>
> (There are still a bunch of threats that have to be addressed.
> But, this closes up a whole family of "problems" that would
> have represented "low hanging fruit" to a would-be rogue
> actor)
>
> --don
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org



-- 
-------------------------------------------
nathan hruby <nhruby at gmail.com>
metaphysically wrinkle-free
-------------------------------------------