[192005] in North American Network Operators' Group
Re: IoT security, was Krebs on Security booted off Akamai network
daemon@ATHENA.MIT.EDU (Mel Beckman)
Sun Oct 9 11:46:56 2016
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Stephen Satchell <list@satchell.net>
Date: Sun, 9 Oct 2016 15:46:50 +0000
In-Reply-To: <98b356a2-5406-b264-73e5-ecfe5c7697f3@satchell.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Stephen,
But they don=92t, in fact, allow such a console. And I don=92t think such a=
thing is even a good idea on IoT devices, because permitting inbound conne=
ctions is a pathway to exploitation.=20
As I noted in my post, I=92ve put it on its own VLAN, which is better than =
a DMZ: no inbound access at all, and no access to any other network or devi=
ces. I only permit port 80 outbound to the Lacrosse cloud server, and will =
get notified of any other traffic.
But this is a wired device, which made it easier to sequester. If it were W=
iFi my task would have been much harder, and most IoT devices do seem to be=
WiFi.
-mel
> On Oct 9, 2016, at 8:33 AM, Stephen Satchell <list@satchell.net> wrote:
>=20
> 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.
>=20
> 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=
.
>=20
> For IPv4, this is barely tolerable. For IPv6, not so much.
>=20
> 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.
>=20
> Would you put this thing on a DMZ? I thought not... :)
