Agree
Certainly, but the most important thing is to inform NR users and so that they can easily secure themselves by looking at this new topic and FAQ
2 Likes
I still think the key is that users are made aware upon first start of node-red - on cli this is done, however, anyone running home assistant or docker wouldn't see it i believe. Next best "bet" is the introduction "tour" when accessing the gui for the first time. I think it should be the very first message with a clear warning.
1 Like
... or have the manage palette through throw up an error or info or something. I say the manage palette because that actually obtains a json every now and then to obtain a updated list of available updates.
So there could also be an extra "security warning" section for displaying a warning in all Node-RED instances.
But: I'm only mindstorming here, this isn't a feature request! 
Edit: throw .. through .. dyslexiac
I don't agree, sorry. A message that appears once and never again ticks the "Don't blame us, we warned you" box but it's no use at all for educating new users.
If I fail to close one door of my car while the engine is running there is a red light that stays on until I fix it.
IMHO the editor should nag you all the time if you have not set up [some minimal level of] security. Possibly "Do not expose this Node-Red installation on the internet without protecting it!" on the editor title bar.
You could disable the warning in settings.js (or by setting a login password, etc).
1 Like
No, sorry, I have to disagree with that. In doing it that way, you are encouraging or even enforcing that people try to make Node-RED itself "secure". And that is not the only way to do things nor is it even the "best" way to do things.
If I have a secure enclave in my datacentre I want my edge security to handle things, I never want potentially insecure stuff to reach my services.
Even in a home environment, we've many times talked about using 3rd-party tooling to provide the security and not Node-RED itself. Whether that is Cloudflare Zero Trust or NGINX with some IDAM/SSO tooling or some similar method.
If you are going to give people a powerful tool, you need to give them the information about the risks as well as the benefits. But you can't make them do the right thing, that is on them.
4 Likes
I was about to add some jokes here - but that's only going to water the message. Discarded.
Thus: This word is so true! Thank you! 
1 Like
The red light in my dashboard doesn't make me close the door.
It's discrete and always there.
Unlike the loud audible bleeping when there is a bag of shopping in the passenger seat which doesn't have it's seatbelt fastened.
One is helpful, one is a pain in the ear.
It's a question of getting the right level.
While I don't have any idea what a secure enclave in your data centre is, I hope your edge security has sufficient knowledge to be comfortable turning off the warning in settings.js.
But who do we need to protect anyway, new individual users or professionals served by the edges of secure enclaves in a data centre?
1 Like
Neither, Educate instead.
The analogy of the car breaks down when you start to think that such a powerful tool is not released into your hands without significant training (in most sensible countries anyway).
But the car manufacturer is not responsible for that training nor the certification at the end of it.
Ideally, people putting services onto the Internet using a powerful tool such as Node-RED would be trained and certified. Sadly, I don't think that will happen.
And any annoying warning built into Node-RED will be the same as the annoyance you find with that shopping bag. But in node-red's case, someone will find the code and simply disable it because it is annoying.
Of course it is, that is the whole point. You use the right tool for the job and the right tool is the one that has been battle tested to hell and back over many years. Like we are supposed to design nodes in node-red - do one job and do it well. Node-RED does not need to be everything to everyone - indeed the more it extends itself, the more bugs it gets (this is not a commentary on the devs, it is a well studied and proven truth).
I could go on more about specialisms and edge cases and much more - this is my day-job after all. But I won't bore everyone and I've made my point.
The people asking for advice in this forum appear to be individuals running NR on their home network, nobody has said "My NR flow is blank and now all my sales data is encrypted".
There is not much sign of concern from the developers about the current default level of security (none) provided for little Jimmy who got a Pi for Christmas and has heard that Node-red is the best thing you can use it for.
No surprise really, I wouldn't expect crisis discussions to be in public.
But victims have for years been reporting that their NR system has been hacked and very little has been done.
Pointless for amateurs like me to try and make suggestions I guess.
2 Likes
Not pointless at all. Most of the devs read most of these posts, but as has been pointed out real security IS hard, and has also been pointed out is often best done outside of Node-RED using proven tools. The other hard part is how to migrate users over without instantly locking them out of their existing systems. I can well imagine the howls when folk upgrade and lose contact with all their docker containers or remote installs. Not an excuse for not doing something, but that something needs to be carefully thought through. All ideas gratefully considered.
5 Likes
I was thinking of small changes such as a "auto disable" of the editor after a certain time. For example, after the editor has been closed for a while. The user would have to manually enable it (the editor) again through a command or just by editing the settings.js.
This feature does not have to be set by default. But I would advertise it in the release announcement.
OMG! No. How can anyone learn if they can't experiment? As I baby I fell on my face with my first steps, after that I used my hands to cushion my fall.
What should be happening is that the community around Node-RED provides support and best-practices for newbies and not certification. After all, we are not talking about a nuclear reactor here, we're talking about software that most people use to turn their lights on and off! And those that do control a nuclear reactor with Node-RED should be able to do that but not around the corner from me 
100.5% this! Even though I am the first to say Node-RED can do anything, the core should be compact and solid and stable (CSS) - plugins provide the extras that are needed for specific use cases. Think Linux and Firefox: if firefox has a bug, I don't need to upgrade Linux. Unfortunately what Node-RED doesn't not have is the C standard library that, for Linux, defines exactly the functionality that needs to be provided. Node-RED has yet to define a clear set of functionality that it should provide.
Disagree.
That's exactly who should be listened to since the issues a beginner goes through are those that most people go through. Very few people will face an issue with a html node but everyone is potentially confronted with a security issue because they left their NR instance facing an hostile internet.
Honestly, the very first thing that should happen is the creation of a security topic here in the forum with tips and ideas for better security, ideally focused on beginners.
Side note: the red light already exists in Node-RED
---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------
What? I don't care. Each and every time I do a flow restart on my unreachable Pi installation.... should I be able to turn that off since I know the Pi is unreachable? Probably not.
I dont think this would help because the attacks seem to be happening from the http Admin API and not the Editor directly. One clue for this the "id": "ab53bcf4-2295-4b8b-96f0-7d657623c8d2", they used when injecting the malicious flow. It doesnt look like a standard Node id .. so possibly is was software generated and not from the Editor.
Some suggestions could be
- unhide all nodes during import (Admin API injection) ..
but we still have the issue of them being at position 9999 - maybe have any exec nodes disabled on Import ?
But these are moo points if they get to the stage of being able to post flow .. it means they are in
so good security up front
Why would the API be enabled by default? 
So that means our customers could technically still have access to the flows, even though the editor is disabled?
Edit: If the editor is password protected, I can still get access through the API without password?? Okay, at least both (editor and API) are protected if pw is enabled Securing Node-RED : Node-RED
because thats how the Editor communicates with the runtime
exactly
Then at least disable the API if the editor is disabled per default and allow to override/change this behaviour through settings.
It wasn't a serious proposal. 
Though I am not sure people quite realise what Node-RED is capable of and how dangerous it can be in the wrong hands. A bit like a car. Extending the analogy, my grandad let me drive his car on the beach when I was about 6yo - my mum was horrified but it was a great learning experience - BUT, it was supervised and it was safe. You wouldn't let a 6yo drive a car on the road unless you were mad, so why do we let anyone dump unsecured, powerful servers on the Internet where they can be used to harm potentially BILLIONS of people?
Which brings me onto a, I personally think, much better suggestion for a small change to Node-RED that would not hamper people from playing and trying stuff but WOULD force them to think twice about exposing direct to the internet.
At the moment, I believe that the Node-RED servers allow access from any source network - e.g. they are bound to IP address 0.0.0.0. It would be simple enough to change this. It could simply be changed to localhost though that might confuse people setting up on a home network, or it could be limited to non-routable addresses (172., 10., etc)
As long as the instructions for setup were clear about how to change to a more open setup - and explain the risks and mitigations - I think that would be an excellent way to improve general security for non-experts without being too limiting to people.
2 Likes
well the parameter to do that is there in settings.js - so we could do that. If we did that via the script it would mostly only affect "home" type users (and indeed we could add yet another command line option to Not do it) - the main argument against is that binding to 127.0.0.1 would only allow access from that machine which is a pain for anyone running headless. (Then again it's not dissimilar to what mosquito does...). The other problem with it is that it is the bind address so once you do open it to allow access from (say) your laptop then it is now also open to your router and anything that comes through that. Slightly better would be middleware that allowed access from your local subnet but excluding your router. If anyone has a neat algorithm for that please let me know !
I think we might be making a mountain of a molehill here - it's getting to the point of guns don't kill, humans kill. You give a six year a rubber duck and you won't imagine what it will do with it! /s
One thing that everyone is forgetting is the risk of importing a node/flow that has a backdoor. With 4800+ packages, are we sure they are all above-board?
What I want to say is that there are endless security risks and in part, it's simpler to wait until something happens instead of expecting/imagining the unexpected ...
Edit: Something I thought about doing was making a unmodifiable Node-RED. So I'm on Heroku and heroku has no writable filesystem, so the storage of the flows.json is a blob in postgres. But actually I don't need to do that since - in theory - I can make my changes locally and commit the flows.json into the repository that I deploy to heroku (deployment is done with a git push). So the initial flows.json is part of the source code, gets loaded by Node-RED and any deployment done within Node-RED is null&void since Node-RED can't write to the filesystem. It's a kind of setup between a dynamic server (changes being stored somewhere) and static pages (i.e. something like GitHub pages, no server) since Node-RED can still be dynamic but everything is in memory, responding to events.
1 Like
Indeed, which is why I offered the half-way house of only allowing non-routable address access which is already a LOT safer.
It would still have the advantage of putting a small bump in the road for people to have to think about. So I still think it is worth doing.
I can't think of a foolproof way to exclude just the router. In theory, excluding the default gateway would do the job, but I don't think that is foolproof. My networking is a bit rusty but I think even in a home environment some people might have a default gateway that wasn't their router. Maybe others would know. Anyway, that's the nearest I can get to an exception.
That's exactly the point I was making really. Sensible countries don't force gun manufacturers to make their guns safe, they control gun sales so that only relatively sane people can have them. (sorry folks from the USA) 
Certainly not saying that people who expose servers to the Internet aren't sane by the way! Mostly, they lack the experience or knowledge to do so safely.
Node-RED is most certainly the software equivalent of a gun. Useful in the right circumstances, dangerous in the wrong.
So we shouldn't be over-engineering Node-RED to compensate. But, as mentioned, some small tweaks might help.
1 Like
