Thoughts on securing your NodeBB installation

julian

About two weeks ago, the creator of Redis, antirez, published a blog entry in response to perceived security "faults" in Redis.

From time to time I get security reports about Redis. It’s good to get reports, but it’s odd that what I get is usually about things like Lua sandbox escaping, insecure temporary file creation, and similar issues, in a software which is designed (as we explain in our security page here http://redis.io/topics/security) to be totally insecure if exposed to the outside world.

Click here to see the full blog post

? Offline

Despite using SSH Keys I also recommend to change your SSH Port and to disable direct root login.

xen

How to allow access to redis with two ip?

bind (my ip)
bind 127.0.0.1

But I still can not access from their computer.

This is necessary, because I use Redis Desktop Manager.

julian

@xen The bind directive accepts space-separated values.

I'd recommend using an SSH tunnel to access Redis from your desktop, while maintaining the bind set to 127.0.0.1.

@AOKP Good points. Also keep your server up-to-date

? Offline

This post is deleted!

rbeer

@xen
Binding a port through your ssh connection is actually quite simple.
(The following assumes that you are using the OpenSSH client on GNU/Linux)

tl;dr:
https://youtu.be/vC7Smc67gPg

Start the SSH client with ssh [email protected] -L 7000:localhost:6379
So basically like you would normally do, appending -L ... with the syntax:
- local_port:interface_on_remote:remote_port (ssh manpage)
You should have an interactive session to your remote, prompt and all or whatever your setup resolves into when logging in over SSH. Again, business as usual is expected here.
Now comes the good part: Since you tunneled your local port 7000 to the remotes localhost interface on (redis-) port 6379, you can create a new connection in Redis Desktop Manager, ignoring the SSH tab in the "New Connection" dialog and simply connecting to localhost:7000.

xinbenlv

Reading this as a new NodeBB site admin I really appreciate the suggestion. I think it would be greatly helpful if something like NodeBB or Discourse as a platform label provide tools for scan and auditing common security breaches for new setups, mostly due to use default values in credentials and by passing firewalls etc.

I understand as open source softwares, Pull Request is better than suggestion, but let me put this suggestion here. Maybe it will encourage some white-hat hacker sometime in the future.

gotwf

@xinbenlv Why add bloat to maintain a function secondary to NodeBB's purpose that will always be done better via dedicated pen test tools? There are many, many Linux ditros available as USB keys to facilitate such. Just be sure you are running scan modes and not crack modes.

On the other hand, perhaps you are looking for some Purely Psychological Protection, a.k.a. "Security Theater"??

A couple mentions I have not seen mentioned that you may want to explore:

P.S.; This thread is from five years ago. Obviously much has changed since then. Yet much of the song remains the same. Just tryin' to be helpful. Apologies if "necro-posting".

xinbenlv

@gotwf You are absolutely right. I certainly agree with you a dedicated tool instead of built-in with NodeBB will be better.

What I argue is that the platform software community like NodeBB comes up with customization or a collection of recommendation of existing tool-sets that will get the deployment security to the certain level. For example, common mistakes of new admins of NodeBB: if you've uses NodeBB default password for the admin password, or turned on Sandbox feature that's not meant for production.

And thank you for your list of tools. That's very helpful.