I am just wondering what is the best way to communicate with a Node-RED server running on a raspberry pi (or other edge device) via the internet (e.g. using a mobile phone connected to the internet via data network ).
Additional requirements:
The goal is to access the node-red-dashboard or the web page created by node-red nodes (like http in, http response)
ssl
no need to install any specific app on the mobile phone
no need to share passwords or other credentials
the url of the node-red-dashboard or web page must contain some "key" so it is difficult to guess. Moreover it should be relatively easy to regenerate this key in order to block users with old key from accessing the web page.
FYI: The idea is to share the URL via QR code printed on a paper sticked to a wall. Using their mobile camera they can scan the QR code and so quickly navigate to this URL without any need to enter the full URL.
the communication should support the upload of big files (about 10MB max) from mobile phone to Node-RED.
Just to note that this has been covered many times before both on this forum, in the cookbook and various blogs.
This is something of a movable feast depending on your requirements.
Before getting to the actual advice, I would say that my preference would always be NOT to do it. That is because Node-RED and even a Pi are tools for experimentation (or at least have grown out of that use-case). Node-RED in particular is a generic platform for building fast prototypes. It is excellent at it but it has had limited security tests done on it and both it, and the things it depends on are fast moving. Security then can lag behind the change-curve.
Using a bot framework on a reasonably secure platform such as Telegram therefore likely will remain a far more secure option for many use-cases.
2nd choice behind a bot framework would be using a securely configured intermediary. For example, see my recent post about securely configuring NGROK. Note that the default settings for NGROK are certainly not secure.
So, if we assume that the above doesn't meet your requirements, My own advice would be as follows:
Put the Node-RED service "behind" a reverse proxy using something like NGINX, HAproxy, etc. This can also be used to simplify your URL's (remove the need for the port number for example). It can also be used to add login protection to specific URL's. Protection from a proxy server will nearly always be stronger than from a Node.JS app.
Use the proxy to terminate your TLS sessions (rather than using Node-RED for that)
Use Let's Encrypt to provide a valid and secure certificate.
Make sure that you disable the Pi user. Create a user for you to use for administrative purposes. Create a separate user to run Node-RED. That user should be given minimal permissions. Of course, all users must have strong passcodes of at least 10-12 characters - preferably randomly generated and kept in a password manager.
Make sure that the root, pi and node-red users cannot log into SSH. Preferably configure SSH to only allow certificate-based login and generate a cert for your admin user.
Install and configure Linux tools to auto-ban access for users and IP addresses that exceed security parameters to prevent brute-force logins.
Set up some alerting so that you know when your Pi is being attacked and when it might be subject to DDOS.
Preferably, expose a separate instance of Node-RED that only has the features needed for external access, nothing more. Certainly keep the exposed instance separate to any IoT or home automation processing.
Similarly, it is much better to dedicate a separate Pi for the external access. Remove all unnecessary applications. That pi should have no access to anything else on your network unless it really needs it. If it does need some access, try to push from another device rather than pull from this one.
A bonus step is to only allow access to the external-facing Pi from Cloudflare and then use Cloudflare's certificate and security to add an extra layer of protection. This also adds DDOS protection, some security reporting and analytics. A great set of bonuses for free!
A second bonus step is to change the external port for your SSH service (assuming to allow access from the Internet - better if you don't of course). Common ports are attacked immediately and even with the protection outlined above against brute-force attacks, it still fills up your logs and hides other issues.
Above all, do not assume that there is no interest in your server. Any server exposed to the Internet will receive automated attacks within 30 seconds. We've already seen compromises of exposed Node-RED systems and attacks against Linux servers are very common.
This would be very problematic for me. You are exposing a site. Even assuming that you use a random URL path, everyone at the party is potentially exposed as I've outlined in the other thread.
I would go further and tell people that the URL is valid only for 3 days or whatever in order to minimise the risk.
That is sensible and easily done.
Depending on where in the world you are based (but probably true for most places now), you should make sure that the landing page includes clear information about the fact that images will be available to everyone with the link. You must also provide a contact so that people can let you know if an image needs to be removed and you will need to be prepared to respond to such requests very quickly. Just bear in mind that the owner of the server is taking on a responsibility here, in places like the EU, this is backed up in law.
It would probably be even better to provide a self-service "take down" for images. That at least hides the image while you review the request. Keep clear records of requests and your responses.
You will also need to think about whether minors (children) will be present at the party. If so, you are starting to really enter dangerous territory unless you make it clear to everyone before they come that you will be having this capability so that people have the ability to object or not come.
Very interesting indeed! How would you rate having a vpn server dedicated/running on a separate Pi for remote access and a vpn client in the phone. As the only possible way to remotely reach your Node-RED on your home network?
Oddly, that doesn't provide as much protection as you might think in this case.
The simple reason for that is that you are extending your internal network out to the end user devices.
Those devices - at least assuming a predominance of Android - are VERY likely to include at least 1 or 2 compromised devices.
So while those might not be all that likely to specifically compromise your Pi (not impossible but perhaps not all that likely), they will almost certainly try to compromise other phones on the same VPN It is also possible that malware on the phone might try to exfiltrate the images from your web app - not sure how likely that is to be honest though I know that there is plenty of malware that tries to grab images and videos from phones in the hopes of grabbing some porn.
But yes, at least you are stopping access from elsewhere which is good.
Honestly, I think a lot of this is going to come down to how often you are going to do this, who the party-goers are (how risky they are and whether there are people present who need additional privacy such as children) and how long you intend to keep the site active after the party.
I think that I'd probably just use a separate Pi running your web app only along with NGROK configured for HTTPS only. Then I'd only keep the link open until the end of the party, then I'd put all the images onto a static website (or Amazon photos or similar) with a password. Keep them there for a week and remove.
I've not much doubt that you would get away with absolutely minimal security 99.999% of the time. But that small percentage might well result in a very high impact.
it is a private party with limited number of people - all family.
the link will only allow to upload photos. It will not give any access to uploaded photos
Thanks for suggesting VPN but I don't think VPN meets my requirements 3 and 4:
no need to install any specific app on the mobile phone
no need to share passwords or other credentials
I have already a solution for my problem using balena.io and accessing Node-RED using the public device URL provided by balena (in my case the public device URL routes first to nginx (reverse proxy) running in a container which then routes the request to node-red running in another container). This works but it means that communication is routed via Balena cloud servers and I don't know how it will react to the load (although I am not really expecting a lot of photos being uploaded).
Major annoyance is that for this I need to share the balena public device URL which can not be regenerated easily.
I need to have a closer look at many interesting points raised by @TotallyInformation.