Stephen, But they don’t, in fact, allow such a console. And I don’t think such a thing is even a good idea on IoT devices, because permitting inbound connections is a pathway to exploitation.
As I noted in my post, I’ve 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 devices. 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 WiFi 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 <l...@satchell.net> 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. > > 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... :)