Realistic security risks of exposing node-red dashboard to the internet on home network.

[Micah Burlingame]

Clearly there are security risks associated with letting any internet traffic onto a home network but how far do the risks extend? Would I only be risking the dashboard itself? The entire raspberry pi I am running it on? or my entire home network?

[Zenofmud]

This has been talked about before - see this thread  https://groups.google.com/d/msgid/node-red/0439d246-1f74-4754-b452-7d93c3f75e11%40googlegroups.com and this https://github.com/node-red/cookbook.nodered.org/wiki/How-to-safely-expose-Node-RED-to-the-Internet

On May 27, 2017, at 4:32 PM, Micah Burlingame <micahl...@gmail.com> wrote:

Clearly there are security risks associated with letting any internet traffic onto a home network but how far do the risks extend? Would I only be risking the dashboard itself? The entire raspberry pi I am running it on? or my entire home network?

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/1c619d30-793a-4eda-912e-92cff3deaf45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Micah Burlingame]

These links don't answer my question. They just say that there are risks and provide methods of security. My question is what those risks actually are.

[Colin Law]

If you don't impose any security at all then your whole network could
be compromised. Certainly your node red system would be compromised
as anyone could edit your flows.

Colin

> https://groups.google.com/d/msgid/node-red/5ef636b7-659f-4d89-aea5-674203512af6%40googlegroups.com.

[Julian Knight]

There are perhaps 3 main risks.

Firstly, as Colin says, that the Dashboard would give entry to an attacker that could then be used to move on to more valuable targets. That we don't know of any right now doesn't mean that there aren't any though that is somewhat mitigated by the fact that Node-RED is still a modest target and so probably hasn't received a lot of attention.

The more obvious risk is that only limited security is currently available and so an attacker could intercept traffic and - worse of all - if you are using Node-RED as many of us do, for home automation and security - an attacker could control automation systems within your home. Imagine coming back from holiday and finding that the heating had been turned up to max for the last week or two. The bill on your water meter maxed out and plants dead because all the garden watering system was turned on fully and left on. You get the picture hopefully.

The third risk related to the first. That an automated bot network discovers your network, finds a vulnerability and sets up a link to a command and control (C2) service. It then becomes part of a botnet that extends attacks across the Internet

The first risk is a major problem in any network and a common form of attack - but generally only with high-value targets which your home is unlikely to be.

The second risk is also fairly unlikely to occur but the impact could be enormous if you have potentially sensitive systems such as the ones mentioned.

The third risk is actually the most likely to occur. While this might not really have much direct impact on your system, it has a massive impact on the rest of the Internet and leaves you open to legal or even criminal damage charges and explanations to be made that you would certainly prefer to avoid.

Only you can assess the risks and the impacts but certainly none of us want to wake up to a headline that implicates Node-RED in an Internet botnet and none of us want a headline about someone's house burned down because of Node-RED.

As for me, this is an easy choice to make. A significant part of my job is to ensure that my employers systems are secure and I can't do that if I end up botching my own security. Nor do I want to make the Internet an even worse place by allowing my systems to be part of a botnet. And though I don't currently have automation on really critical systems, that might not always be the case and I don't want to have to constantly think/worry about that. So I don't connect Node-RED to the Internet directly and probably won't for some while yet.

What I can do in order to get remote control over my system with little risk is to use a secure messaging system such as Telegram to act as a go-between. I can get Node-RED to talk to my mobile devices via my Telegram bot. I can also control the system via simple commands. The bot is limited to specific Telegram client ID's and devices and all comms takes place over secure channels. I have to trust the Telegram service but that is a vastly lower risk.

[Walter Kraembring]

I have a dedicated RPi with VPN Server to allow access to my network from internet. I connect with a VPN Client, then I can work with the node-red flow or dashboard and others as I like.

Isn't that the most secure way?

[Julian Knight]

Well, the MOST secure way would be not to allow external access at all :-)

VPN is secure as long as your laptop isn't compromised, that's true internally as well of course - and as long as the credentials to your VPN are secure - so a cheap password not so good. Also, you compromise VPN security if you start split-tunnelling or bridging networks. But yes, that gives good security. If you trust the 3rd parties, tools such as NGROK are also reasonable alternatives. A VPN doesn't actually give access to NR from the Internet really though so if you wanted other people to access your Dashboard, you would have to give them VPN access too - I have to admit, I didn't read the original question in that light.

[Walter Kraembring]

OK, understood

Could the DMZ be used somehow? I mean separating NR and the GUI/Dashboard in some way? Or is this a stupid thought?

[urs.epp...@switch.ch]

Thanks for the various good thoughts here on this topic.

Currently my node-red installation is on the internal home network, as is the MQTT broker. A VPN server is hosted on the same installation, offering access from remote, no bridging on the client.

I do plan to offer some limited access to third parties. My current thinking: Setup a RaspPi with node-red in a DMZ. This system will talk to the internal node-red via the MQTT broker. That way I can control on the internal node-red system, what commands I accept and what data I publish. The RaspPi does nothing else, so I can stick in a new SSD card with the initial OS/setup, whenever something feels funny.

For your amusement: I publish some of the MQTT broker messages on a public service: https://shiftr.io/urs-eppenberger/Dyssihof/embed?zoom=1

I bridge the internal broker with the public broker on broker.shiftr.io using node-red, stripping away the payload, so no measurements leak out or commands find their way in. It is just a nice visualization of the topic tree and the messages.

[Julian Knight]

Now that is SUPER cool!! I do hope you can share how you do that on the flows site or a blog post.

In terms of public access. Personally, I possibly wouldn't choose to run Node-RED in a DMZ, my preference would be to run NGINX in the DMZ to act as a reverse proxy to Node-RED running on an internal network. That way you only get something exposed that is very heavily battle tested and can provide it's own security. 

Incidentally, most home routers don't really do DMZ's properly so I wouldn't rely on them for security that much. Choosing something like a Ubiquiti EdgeRouter Lite would allow a proper DMZ setup with separate firewall rules between each segment but would still cost the same (with a Ubiquiti UniFi AP for Wi-Fi) as a high-end home router.

[Zenofmud]

I second that - Wow that looks cool!

[urs.epp...@switch.ch]

In terms of public access. Personally, I possibly wouldn't choose to run Node-RED in a DMZ, my preference would be to run NGINX in the DMZ to act as a reverse proxy to Node-RED running on an internal network. That way you only get something exposed that is very heavily battle tested and can provide it's own security. 

mmhhmm, a reverse proxy. Did not think of that. Usually I hate all these middleboxes messing with my data connections. But when it comes to securing my home network, this seems a good idea. Will have a look at it. Many thanks.

[Julian Knight]

I know what you mean but it is actually the preferred approach for micro-services in general and node.js specifically. It also helps in larger setups with load balancing and high-availability.

Just remember that Dashboard uses two channels. HTTP for the main page delivery then Websockets for IPC. The websockets part is particularly challenging to secure right now as it isn't yet integrated into the wider Node-RED security. However, there are quite a few posts about using NGINX to secure websockets.

[Julian Knight]

OK, I see now that this is a feature of https://shiftr.io/features

I've not seen that before.

[Philipp Protschka]

Are you talking about unsecured expose ? i.e. without passwords? or with passwords and perhaps ssl?

today i set up node red on a machine also running local apache with virtual hosts (proxy) and a letsencrypt certificate for a subdomain.

So it goes like subdomain-> router (port forward 80) -> apache redirect to https -> apache virtual host proxy redirect with ssl -> localhost:1880 + websockets -> Nodered Login with username and password.

Is this not secure because of the websockets? can the websockets be used without the node red Authorization? :/

my site config looks like this:

<VirtualHost *:443>

  ProxyPreserveHost On

  ProxyRequests Off

  ServerName red.yourdomain.com

  SSLEngine on

  SSLCertificateFile /etc/letsencrypt/live/red.yourdomain.com/fullchain.pem

  SSLCertificateKeyFile /etc/letsencrypt/live/red.yourdomain.com/privkey.pem

# websockets:

  ProxyPass /comms ws://localhost:1880/comms

  ProxyPassReverse /comms ws://localhost:1880/comms

# regular http:

  ProxyPass / http://localhost:1880/

  ProxyPassReverse / http://localhost:1880/

</VirtualHost>

# this redirect all http request to https

<VirtualHost *:80>

  ServerName example.org

  ServerSignature Off

  RewriteEngine on

  RewriteCond %{HTTPS} !=on

  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [NE,R,L]

</VirtualHost>

[Julian Knight]

The websocket nodes in Node-RED currently don't use any of NR's authentication or authorisation features. I think that is improved in the next release. So if someone does manage to intercept your traffic - via a man in the middle attack for example - they would have access to a lot of data and potentially to some controls.

I realise that this is not that likely an event unless someone was actively attacking you or your household personally but still not something you'd really want to leave open if you are controlling anything critical.

While TLS helps a lot, it isn't perfect by any means. Certificate pinning helps.

Just to be recap, using TLS should generally stop interception but weaknesses in TLS implementation and config can leave you open to MiTM attacks and the lack of authentication and authorisation currently on the websocket interface could leave you open to unauthorised remote commands.

A relatively small risk unless you are being actively attacked but a large impact if you are using NR to control critical systems.

One interesting approach to fixing this would be to use NGINX itself to do the authentication and authorisation. That way, you wouldn't ever need to do it in Node-RED. https://github.com/auth0/nginx-jwt, https://blog.imaginea.com/stateless-authentication-implementation-using-jwt-nginxlua-and-memcached/