Re: IoT security, was Krebs on Security booted off Akamai network

[Large Hadron Collider <large.hadron.collider () gmx com>]

On 2016-10-09 08:33 AM, Stephen Satchell wrote:
> On 10/09/2016 07:31 AM, Mel Beckman wrote:
> > remote RF temperature sensor hub for home, the GW-1000U.
> > ...
> > The device accepts TCP connections on 22, 80, and 443.  Theoretically
> > I can't see why it ever needs ongoing inbound connections, so this
> > seems to be a security concession made by the maker. Also, it appears
> > to support SSL, but uses plaintext. Why? Because it's easier to debug
> > in the early deployments, I'll wager. But the thing has been out for
> > years and they're still not using encryption, even though the device
> > apparently has the ability.
> I could see one reason, and one reason only:  to allow the customer to
> use a "control panel" with a local computer, smartphone app, or tablet
> app to set capabilities, options, and preferences.  That said, the
> manufacturer probably thought that the sensor would be shielded from the
> Internet by a Wireless Access Point with NAT, so that there would be no
> direct exposure (in theory) to inbound connections from the outside world.
>
> For IPv4, this is barely tolerable.  For IPv6, not so much.
For v6, what I'd do is firewall all but the safest (SIP, RTP basically) 
of out-of-local-network(s) inbounds to the device unless you visit an 
intranet webpage from the device that allows you to open all inbound. 
The page would be a one time deal (would survive across reinstalls as 
long as the router remembers you) and would record your MAC address. It 
would ask "You hereby agree that your device's connection security is 
your responsibility and only your responsibility. You hereby indemnify 
and hold harmless the owner of the network infrastructure for [bla de 
bla legal jargon basically don't sue if yer hakt]. Would you like to 
open blocked inbound connections? [Yes / Oui / Да] [No / Non / Нет]"
> As a developer, I can tell you that "easier to debug in the early
> deployments" means that the later deployments won't be locked down until
> the manufacturer gets a fine, judgement, or other monetary hit.
>
> Would you put this thing on a DMZ?  I thought not...   :)
I wouldn't even put a well-secured desktop running all the best 
firewalling in a TNZ (trusted network zone, term I think is less 
misleading than DMZ, referring to a state of being unfirewalled)