IoT security, was Krebs on Security booted off Akamai network
Large Hadron Collider
large.hadron.collider at gmx.com
Sun Oct 9 19:50:21 UTC 2016
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)
More information about the NANOG