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.
