Is it possible to have a dashboard accessible though an external method? I was looking for it in the forums but only saw one question with a response of IBMCloud server.
My specific scenario:
Currently have a nodered dashboard locally with a dashboard with a button that controls a smart switch
My goal:
Have this dashboard be published on a website so that I can go directly to a URL while not on the home network and press the button to activate the smart switch
Thanks in advance
Edit: I meant to say the I wanted access to the UI, not the dashboard
If you actually want a web page that is delivered through a non-Node-RED web server, there are still ways to achieve that.
But not using Dashboard. That is because most of Dashboard is delivered by the Node-RED web server and is intimately linked. Code is delivered to the front-end from Node-RED, not just data.
Using uibuilder, you can have pages that are delivered by a different web server. But it isn't very well tested I'm afraid. And I'm not sure I would really recommend it anyway.
What would be more sensible would be to write that external page to use Node-RED as an API server instead. That is perfectly possible, indeed pretty easy.
You will need to decide what kind of data interaction you want. Whether a simple REST interface or perhaps Websockets. Or you could run up an MQTT server along side your web server and use that instead (likely to be more robust than websockets).
However, which ever way you choose, you will still need to pay careful attention to the security of your Node-RED server. Lots has been written about that subject on this forum. Both the why and the how.
....to be honest, I'd not go through the hassle to expose a dashboard if only feature required is remote control of one/some switche(s).
I'd use a local mqtt server with a bridge to a cloud hosted mqtt server for my switch topics, so I can control the switches from everywhere via mqtt.
clients for mqtt are available for your smart phone and integration with node-red is easy.
I totally misspoke, I meant to say that I have a ui with a button that I wanted to access without having to be on the same network as the node-red server. I know that you said it's not very well tested, but is there documentation on how to do that somewhere?
Yes, it is in the uibuilder documentation. Basically, you have to pass more parameters to the uibuilder.start function.
Frankly though, that is a lot of bother for a single button a Telegram bot would give you secure remote access to send a command and receive some output. Then you wouldn't need to expose node-red to the Internet at all.
Thank you! I actually purposely am exposing it to the internet because this will be used in terms of an escape-room type of thing where an external person can control the on-off of one specific switch given that they have the link.
If it really is an escape room setup, I would recommend having everything on a local network - all of the escape rooms I've been to (albeit not that many) have been set up this way. A single Pi could probably run a reasonably complex escape room with ESP8266's where you need control but don't want to run wires. No need for the Internet at all.
I can't stress enough, connecting things to the Internet should not be undertaken lightly. We have already seen compromised Node-RED systems.
Thanks. Yeah I tend to keep forgetting to include pertinent info lol. We have node-red set up internally/locally for our local functions in our escape room and that's fine. We are moving towards a virtual game as well, so for the virtual game only, the idea is that a player would be able to control a smart switch in the game and see it function on Zoom through them pressing a button on a webpage. That's the reason why we're going for this route, and whether it's the best method or not, I don't really know but it's the only thing I can think of right now.
In that case, my recommendation is that you set up a 2nd Pi - preferably in a DMZ (where both the inside and outside network edges are protected by their own firewall settings. Most decent routers should allow you to set this up).
Then use the outer Pi to run NGINX or Caddy with HTTPS termination. Your page will send the button press via the web server to Node-RED (which will have no direct input from the Internet). You can set that instance of Node-RED to run without the admin interface once you've set the flow up. The flow will use an http-in node to define a REST API endpoint. Make sure that your web server does not allow websockets in from the Internet.
On that outer Pi, set Node-RED to have MQTTS access to your broker that runs on the inner Pi (this step would not be viable on a truly secure system but should be OK for you).
Set up acme.sh on the Inner Pi to talk to Let's Encrypt and get the keys/certificates needed for HTTPS and MQTTS. Send the appropriate certificates and keys from the inner Pi to the outer (so that the outer Pi continues to have minimal access to the inner network).
So the outer firewall only needs to allow port 443 (https) inbound and only to the outer Pi. The inner firewall only allows through inbound mqtts and only from the outer Pi. The outer Pi is only running a web server and Node-RED with no admin interface.
You will likely want SSH on the outer Pi (certainly don't run a desktop) - move that to a non-standard port and only allow traffic on that port from your inner network.
This probably sounds quite complex but it isn't that bad really. It will certainly leave you with a reasonably secure setup that is unlikely to end up with your business crashing because of compromised hardware and software.
I shouldn't really need to say but will for clarity - this is not a professional recommendation. It is some friendly non-professional thoughts. If in doubt, hire a professional to protect your business.
And if you think you are too small to warrant any hacker attention - think again. Hacks mostly start with automated probes and equally automated insertions of services onto poorly protected systems. Indeed, most hacks will never see attention from a real person but will either add your system to a giant botnet and/or will insert malware to encrypt everything and/or, if you have customer data, steal that and sell it on the dark web.
NGROK is a useful tool. However, it is a developers tool really - perhaps a bit of a stretch to use it for this purpose.
Also worth noting that the default configuration of NGROK is not secure. There is another thread somewhere on the forum where I describe how to make it more secure.
I resolved a similar issue by using a cloud based Node Red instance called IoT Creator. This is offered by a not for profit educational foundation and it is free for non-commercial projects. I signed up at: https://microfacturingusa.org/iot-creator/ , built my GUI and exchange data between my local network and the cloud based IoT Creator instance via MQTT. Now I can access my Home Automation website from anywhere in the world.
I use Blynk app for this purpose, for a non developer like me was fairly straight foreword to set up and worlds easier than setting up proper secure remote access to a home pi. It’s free for non commercial use but because I have about 20 buttons/widgets In the app now I paid a few bucks extra (one time) to get those. I don’t know what it would be for commercial use
I use OpenVPN for external access. Best of both worlds, you have external access that works as if you are on your own LAN plus the security of Node RED being behind a VPN. If you stealth the port no one will know a server exists there and it won't show up on Shodan. You can run the VPN server from a RPI or I run it from my router.
If you publish the UI directly to the internet, there will be hacking attempts within an hour. All from bots at first, but it only escalates from there. I trust very few things to be hardened enough to be internet facing with access to my LAN.
Just remember that a VPN is remote access into the heart of your home network. Any mobile/laptop devices that are connected are potential doors. Make absolutely certain that you keep those devices secure at all times.
Thats why I use an NGROK configuration that is left turned off. On the extremely rare occasions that I do need remote access (Telegram is normally enough), I have a Telegram command that is sent to Node-RED which turns on a secure configuration of NGROK. There is, of course, another Telegram command to turn it off again. Best of both worlds - and not to forget that the default configuration of NGROK is certainly NOT secure.
Never heard of ngrok, looks cool. Curious how you handle authentication while the port is open. I would also like to understand better what your threat model is and how ngrok improves on a vpn. I'm not seeing it yet.
You can find my description of a secure setup with NGROK in another post.
The threat model is that the devices that are your remote endpoints for your VPN are the most vulnerable by definition since they are mobile, left in hotel rooms, in your pocket, etc. If they are compromised, the attacker potentially has full access to your home network - typically not the most secure.
NGROK is a VPN of a particular type. It just uses a proxy that is accessible from the Internet. The NGROK app runs on a computer inside your network and it reaches out to the NGROK proxy, your remote client also reaches out to the proxy and that's where they connect. The advantage being that you don't need to do complex firewall/router configurations.
By leaving the NGROK server NOT running it means that there are less edges that could open vulnerabilities. No point in having an open door when you don't need one.
So to be clear, something like NGROK removes a potential vulnerability from opening your firewall and removes another potential hole by not having a VPN running all the time.
If I understand correctly, the threat is endpoint devices being stolen then compromised and used to access the home network. Is that correct?
OpenVPN as implemented is lower risk in my use case. YMMV.
When doing threat assessment I consider the probability of the threat occurring and severity of consequences. I come up with a probability/severity score. For the threat you outlined (device stolen, compromised then used to infiltrate my network) the score is low/low. The probability of my device being stolen is low, given history. The probability of it being compromised after theft is near zero. The consequences of my VPN being compromised are low. Node-RED runs on an isolated subnet and compromise beyond that is unlikely. At worst someone could play with the lights or thermostat.
When I assess the threat of putting my Node-RED instance on the internet (even momentarily), I consider the probability of a bot poking at it to be medium. The consequences of compromise are still low. As far as I can tell you aren't doing anything to authenticate beyond username/password vs. OpenVPN using key signed packets for SSL handshake and certificates signed by my key for authentication. I haven't evaluated but I don't think Node-RED was designed to be hardened, internet-facing software. OpenVPN was designed for that. The NGROK solution scores medium/low, a move in the wrong direction for my use case.
Node-RED could start/stop a VPN server as you do the NGROK server and accomplish the same thing. What's to stop someone from using Telegram on the stolen/compromised device to start the NGROK server?
a Telegram bot would give you secure remote access to send a command and receive some output. Then you wouldn't need to expose node-red to the Internet at all.