Single-server setups

[Nateowami]

In reading the description the key phrase I missed was "MongoDB instances." I have a single-server setup. Naturally the tests didn't make much sense then, as only a few ports are open on my server, and MongoDB isn't one of them.

However, I did note a few things: When it scanned hostname:27017 it congratulated me for listening on a non-obvious port. Actually, this is the default port. The fact that it's not open shouldn't make a difference to the audit given that the second test checks that it "only accepts connections from whitelisted hosts / networks."

The advanced mode doesn't make much sense for my setup either. I would suggest making it a little more obvious the use-case this is intended for.

Perhaps there could also be some notes about which of these might apply to setups where MongoDB is on the same server as the application? I imagine quite a few of these issues apply (e.g. server-side JavaScript).

Now if I may digress momentarily:

• The "Mongo apocalypse" could have been greatly mitigated with proper backups. While this isn't security per se, and data would still be compromised, I think it would be worth adding a small reminder to the results page, given the context of this tool.
• Very nice design. This is the prettiest console UI I've seen.

[aesedepece]

Hi @Nateowami, Thanks a lot for your valuable feedback.

However, I did note a few things: When it scanned hostname:27017 it congratulated me for listening on a non-obvious port. Actually, this is the default port. The fact that it's not open shouldn't make a difference to the audit given that the second test checks that it "only accepts connections from whitelisted hosts / networks."

This logic has changed as of 6f6f75fcc8664b4a97f00c69d552957a6a121a61. Now it checks if there is an actual MongoDB listening at the provided address and port, and if there isn't, it simply shows an error message instead of continuing with the tests.

We are also studying the best way to recommend backups. That's a great suggestion.