https://twitter.com/iD8266_1/status/797218996139524100
https://jjssoftware.github.io/esp8266-password-complexify/
Simple: Use the MQTT protocol, then there’s nothing to connect to on the devices …
I do use MQTT and I understand the motivation of this approach but I’d say it’s oversimplifying things to say “simple, use MQTT and all problems are solved because the back end IOT devices are hidden / protected”.
Introduce MQTT and you’re no longer connecting directly to devices but it can be argued that going down the MQTT path just moves the goal posts of what may be exploitable when the MQTT broker or some system connected to is publicly accessible. There are lots of things that still need to be thought through i.e.
- MQTT broker transport layer security / a VPN is needed at the gateway
- The MQTT broker system stack security / broker (OS?) attack surface needs consideration. What platform or device is the MQTT broker running on, is this secure?
- What about IDS and packet inspection to detect malicious or probing traffic?
- MQTT application layer (device) username / password security will always still need consideration
- What about MQTT broker<->device communication, TLS here too?
I agree that MQTT comes with some advantages one of them being we’re centralizing some of the network to a single maintainable point. That said, an SSL reverse proxy setup does this too.
Agree. But at least the burden of protecting against incoming attacks (e.g. telnet, http) are moved from the devices (which may very well be tiny computers with limited resources) to the MQTT broker.
And yes, MQTT should run on top of TLS encryption, but let’s face it, that’s where it get difficult.
And we also need someone like CheckPoint to make a firewall that can do deep-inspection of the MQTT packets (and terminate TLS-based connections so that to can inspect the packets in that situation too).
… so definitely not there yet 
@William_Bello If I understand correctly about what you mean by the term downported, I think you’re describing implementation of port forwarding from an internet facing router / appliance to some internal DMZ zone placed router on the LAN where ESP / IOT devices reside. Is that it?
@William_Bello I can’t find much about downporting at all as a term but it looks like you’re talking: http://www.linfo.org/network_segment.html / https://en.wikipedia.org/wiki/Network_segmentation.
It looks like a decent approach that certainly can’t harm because it’s another layer of security. If considered as a single layer, personally I’d say the benefits of this so far as security is concerned will depend on the protocols enabled on target devices. I mean the most secure device is one that’s not on the network at all but as you implement features on a networked device and the more access you need to those features, the weaker that device’s security will naturally become.
I do agree with what you said earlier about attacking an ESP8266 or other embedded networked device would likely be a targetted attack however anyone can develop any feature they like for an MCU. Projects like arduino core for the ESP8266 make it really quite trivial to implement web server, web sockets and telnet like interfaces.
Once somebody has gone down the road to implement features like these on an IOT device and an end user decides they are determined they really must have direct access to these features on that device over the internet then the only way they’re going to get access is to start punching holes in firewall ports to enable access. Segmented network or no segmented network, this is the only way to make that work.
It’s at this point someone has to call stop and start talking about data encryption and making devices as secure as possible, which is the theme of the article that I wrote.
I’m no security expert or network expert myself - my thing is software, but I’ve worked with pen testers and white hat hackers and in my experience these are the really clever guys. I’m sure pretty much any device on any network can be exploited in some way if it’s not behind multiple layers of security.