0

Suppose I run mongodb as a service with the --auth option (requiring a username and password to CRUD data) in an AWS EC2 shell (which does not ask for a password when you sudo)

Now, suppose someone has hacked into the terminal of my stack via SSH and they cannot query mongodb yet because of the --auth option. (irrelevant how, but lets say the stole the .pem file, stole the AWS admin password and changed security permissions so that anyone can ssh in from any ip address, however it happened, they're in)

Couldn't this person just kill the mongodb process, change the config file (or just not use the config file at all) and start mongodb without the --auth option at all?

At which point, they could CRUD anything they wanted. If this is the case, I have 2 questions:

  1. What are suggestions on preventing this as a security risk? (perhaps owning the mongodb process by a user/group that not even sudo would a allow shutting down? i.e another unknown username/password combination that the hacker would need to brute-force crack?)

  2. Does using --auth matter at all (supposing i've already secured my database through the use-of public facing token-based end-points - because I don't want people sending usernames & passwords to my end-points. I see that as less secure than using a token)

many thanks

2

1) What are suggestions on preventing this as a security risk? (perhaps owning the mongodb process by a user/group that not even sudo would a allow shutting down? i.e another unknown username/password combination that the hacker would need to brute-force crack?)

Defense in depth requires multiple layers of security. You are correct that an attacker gaining superuser access has broad access to your server, but appear to be trivialising the effort to do so. In your suggested scenario there are multiple serious security compromises: an attacker has access to your AWS credentials, the client .pem file, and password-less sudo access. With this level of access an attacker effectively has full control over your AWS infrastructure.

A non-comprehensive list of proactive security measures to consider include:

  • Lock down the default ec2-user SSH account so it can only be used locally or from a limited set of trusted IPs.
  • Update your sudoers configuration (using visudo) to avoid or limit password-less login. sudo access can be limited to a subset of commands with or without prompting for the user's password. A NOPASSWD configuration for some or all sudo commands is a convenience but certainly not a requirement.
  • Limit SSH network exposure via firewall or TCP wrappers (see: Keeping SSH access secure).
  • Create an SSH account with more limited access for remote login.
  • Add monitoring/alerting for remote login attempts (successful & unsuccesful)

2) Does using --auth matter at all (supposing i've already secured my database through the use-of public facing token-based end-points - because I don't want people sending usernames & passwords to my end-points. I see that as less secure than using a token)

Securing your public API end points is a related (but separate) exercise from securing your database. A real-life analogy might be: "if you have a lock on your front gate, should you also lock your front door or put your valuables in a safe?".

Having authentication & access control enabled is part of your defense in depth strategy and a first step in the MongoDB Security Checklist. If someone compromised your application server or another trusted network host, they should not automatically gain full access to your database deployment. Access control can also prevent some application logic errors: for example, ensuring your API is limited to CRUD operations and cannot be (ab)used to send cluster reconfiguration commands. You need to consider security between your end users and your API, your API and your database deployment, and all other aspects of your infrastructure. A good defense in depth strategy will include monitoring and intrusion detection so you are aware of when your defenses are being tested and potentially compromised.

  • Thanks Stennie. I like what you're saying. The only thing I can't get passed is that with the --auth option, you need username & password as input, so wouldn't that mean all requests to API end-points would require username & password going over the network? – user1709076 Mar 2 '17 at 20:24
  • Authentication for your API endpoints should use separate credentials; API users are only connecting to your API server, not to your MongoDB deployment. Your API server should validate credentials (eg. API token or API username+password) and take care of the interaction with your MongoDB server. For example, see: RESTHeart's How Clients Authenticate approach. Your API servers should need (and use) MongoDB credentials, but your API end users should not. – Stennie Mar 3 '17 at 15:39
  • I thought the point of the token was to prevent sending username/password in the request? So it looks like people are base64-encoding username/password & token in the request – user1709076 Mar 6 '17 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.