Skip to content

Commit

Permalink
M310 - MongoDB Security
Browse files Browse the repository at this point in the history
  • Loading branch information
AlessandroCorradini committed Sep 25, 2019
1 parent 4df6cc1 commit 84f41d6
Show file tree
Hide file tree
Showing 33 changed files with 1,743 additions and 1 deletion.
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Homework 1.1 : Enable SCRAM-SHA-1

**Problem:**

In this first homework exercise we would like for you to demonstrate that you are able to get a standalone server up and running with authentication enabled.

Let's bring up our Vagrant machine, available as part of the lesson handouts.

```
$ cd m310-vagrant-env
$ vagrant up
$ vagrant ssh database
```

For this exercise we want you to perform the following set of tasks:

- Launch mongod with no authentication enabled
- Create user alice with password secret on admin database and role root
- Relaunch mongod with authentication enabled
- Run command
```
db.runCommand({getParameter: 1, authenticationMechanisms: 1})
```

Which of the following statements will successfully run the above command on the standalone server that you've set up?

- mongo -u alice -p secret --eval "db.runCommand({getParameter: 1, authenticationMechanisms: 1})" --authenticationDatabase admin
- **mongo -u alice -p secret --eval "db=db.getSisterDB('admin');db.runCommand({getParameter: 1, authenticationMechanisms: 1})" --authenticationDatabase admin**
- mongo -u alice -p secret --eval "db.runCommand({getParameter: 1, authenticationMechanisms: 1})"
- mongo --eval "db.runCommand({getParameter: 1, authenticationMechanisms: 1})"
- **mongo admin -u alice -p secret --eval "db.runCommand({getParameter: 1, authenticationMechanisms: 1})"**
- **mongo admin --eval "db.auth('alice', 'secret');db.runCommand({getParameter: 1, authenticationMechanisms: 1})"**
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# Homework 1.2 : Enabling Authentication on a Running Replica Set

**Problem:**

For this lab you are going to take a running replica set (that doesn't have authentication enabled) and are going to enable authentication on it.

One of the provided scripts creates a replica set with authentication disabled.

After you've copied the handout scripts into the shared folder, run the following commands inside the VM in order to start the replica set.

```
$ cd ~/shared
$ ./setup-hw-1.2.sh
```

You can inspect setup-hw-1.2.sh to see the parameters used to set up the replica set, but for convenience here's that information.

<table border="1" class="docutils">
<colgroup>
<col width="12%">
<col width="29%">
<col width="29%">
<col width="29%">
</colgroup>
<thead valign="bottom">
<tr><th class="head">Type</th>
<th class="head">Primary</th>
<th class="head">Secondary</th>
<th class="head">Secondary</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Port</td>
<td>31120</td>
<td>31121</td>
<td>31122</td>
</tr>
<tr><td>DBPath</td>
<td>~/M310-HW-1.2/r0</td>
<td>~/M310-HW-1.2/r1</td>
<td>~/M310-HW-1.2/r2</td>
</tr>
<tr><td>LogPath</td>
<td>~/M310-HW-1.2/r0/mongodb.log</td>
<td>~/M310-HW-1.2/r1/mongodb.log</td>
<td>~/M310-HW-1.2/r2/mongodb.log</td>
</tr>
</tbody>
</table>

In order to enable authentication on this running replica set you're going to need to figure out how to perform the following tasks.

- Create a keyfile to use for internal authentication between the members of the replica set.
- Safely shutdown each member of the replica set, starting with the secondaries to prevent any rollbacks.
- Starting with the primary, restart each member using the shared keyfile you generated.
- Finally, create a user with the root role with the username admin and the password webscale on the admin database.

Note: If you don't create a user with these credentials, you will not get the correct output for submitting your answer.

After you've enabled authentication on the replica set you can run the following script and copy the output into the submission area below.

```
$ cd ~/shared
$ ./validate-hw-1.2.sh
```

Note: If you've successfully enabled authentication on the replica set, then the validation script should output a JSON object with two keys: unauthorizedStatus and memberStatuses. The first key confirms that authentication is enabled, and the second verifies that all members are still up and running.

**{ unauthorizedStatus: { "ok" : 0, "errmsg" : "not authorized on admin to execute command { replSetGetStatus: 1.0 }", "code" : 13 }, memberStatuses: ["PRIMARY","SECONDARY","SECONDARY"] }**
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# Homework 1.3: Enabling Internal Authentication using X.509

**Problem:**

In this lab you are going to start your own replica set with internal authentication enabled using X.509 certificates.

We have provided you with the necessary certificates via the handout.

Your task is to create a three member replica set that uses X.509 certificates for internal authentication. Below are the settings you should use for your replica set. Failure to comply with these parameters will result in incorrect results.

<table border="1" class="docutils">
<colgroup>
<col width="12%">
<col width="29%">
<col width="29%">
<col width="29%">
</colgroup>
<thead valign="bottom">
<tr><th class="head">Type</th>
<th class="head">Primary</th>
<th class="head">Secondary</th>
<th class="head">Secondary</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Port</td>
<td>31130</td>
<td>31131</td>
<td>31132</td>
</tr>
<tr><td>DBPath</td>
<td>~/M310-HW-1.3/r0</td>
<td>~/M310-HW-1.3/r1</td>
<td>~/M310-HW-1.3/r2</td>
</tr>
<tr><td>LogPath</td>
<td>~/M310-HW-1.3/r0/mongodb.log</td>
<td>~/M310-HW-1.3/r1/mongodb.log</td>
<td>~/M310-HW-1.3/r2/mongodb.log</td>
</tr>
</tbody>
</table>

Make sure to copy the certs folder directly to the m310-vagrant-env/shared folder. If the certificates are not in this location then your results will be incorrect. When SSHed into the VM your home file structure should look similar to this:

```
~
`-- shared
|-- certs
| |-- ca.pem
| |-- client.pem
| `-- server.pem
`-- validate-hw-1.3.sh
```

After you have setup your replica set with internal authentication using X.509 certificates, create a user on the admin database with the root role for the client.pem certificate.

After creating your user run the following script and copy the output into the submission area below.

When you set up your replica set make sure that you use the fully qualified domain name (FQDN) when initiating the replica set. Failing to do so will prevent the validation script from working properly. All of the homework should be completed with Vagrant, so the FQDN will be database.m310.mongodb.university.

```
$ cd ~/shared
$ ./validate-hw-1.3.sh
```

Note: If you've successfully enabled authentication on the replica set, then the validation script should output a JSON object with two keys: unauthorizedStatus and memberStatuses. The first key confirms that authentication is enabled, and the second verifies that all members are still up and running.

**{ unauthorizedStatus: { "ok" : 0, "errmsg" : "not authorized on admin to execute command { replSetGetStatus: 1.0 }", "code" : 13 }, memberStatuses: ["PRIMARY","SECONDARY","SECONDARY"] }**
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Homework 1.4: Migrating MONGODB-CR to SCRAM-SHA-1

**Problem:**

For this lab you are going to migrate a database from using the MONGODB-CR authentication mechanism to SCRAM-SHA-1.

We've provided you with a script that will set up and start a mongod against some MongoDB 2.6 data files that include user data. A user was created on these 2.6 data files, alice, her password is secret. You'll need to copy the files to the shared folder.

```
$ cd ~/shared
$ ./setup-hw-1.4.sh
```

Once your MongoDB Enterprise 3.2 server is up and running with the 2.6 data files it's your job to migrate the server (and Alice's account) over to SCRAM-SHA-1.

After you've successfully completed the migration you can run the following script and copy the last line of output into the submission area below.

```
$ cd ~/shared
$ ./validate-hw-1.4.sh
```
**[ "SCRAM-SHA-1" ]**
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# Homework 1.5: Enabling Mixed Authentication Mechanisms

**Problem:**

In this lab you're going to start your own replica set with a mix of SCRAM-SHA-1, X.509, and keyfile based authentication enabled.

We've provided you with the necessary certificates via the handout.

Your task is to create a three member replica set that uses X.509 certificates and SCRAM-SHA-1 for client authentication. You'll then use keyfile authentication for internal authentication. Below are the settings you should use for your replica set. Failure to comply with these parameters will result in incorrect results.

<table border="1" class="docutils">
<colgroup>
<col width="12%">
<col width="29%">
<col width="29%">
<col width="29%">
</colgroup>
<thead valign="bottom">
<tr><th class="head">Type</th>
<th class="head">Primary</th>
<th class="head">Secondary</th>
<th class="head">Secondary</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Port</td>
<td>31150</td>
<td>31151</td>
<td>31152</td>
</tr>
<tr><td>DBPath</td>
<td>~/M310-HW-1.5/r0</td>
<td>~/M310-HW-1.5/r1</td>
<td>~/M310-HW-1.5/r2</td>
</tr>
<tr><td>LogPath</td>
<td>~/M310-HW-1.5/r0/mongodb.log</td>
<td>~/M310-HW-1.5/r1/mongodb.log</td>
<td>~/M310-HW-1.5/r2/mongodb.log</td>
</tr>
</tbody>
</table>

Make sure to copy the certs folder directly to the m310-vagrant-env/shared folder. If the certificates are not in this location then your results will be incorrect. When SSHed into the database VM your home file structure should look similar to this:

```
~
`-- shared
|-- certs
| |-- ca.pem
| |-- client.pem
| `-- server.pem
`-- validate-hw-1.5.sh
```

After you have set up your replica set with all the mechanisms enabled then create a SCRAM-SHA-1 user named will with a password of $uperAdmin with the root role on the admin database.

After creating an account for Will then create another account for the client.pem certificate. Give this user the userAdminAnyDatabase role on the admin database.

After creating both users run the following validation script and copy the output into the submission area below.

```
$ cd ~/shared
$ ./validate-hw-1.5.sh
```

Note: If you've successfully enabled authentication on the replica set, then the validation script should output a JSON object with three keys: unauthorizedStatus, memberStatuses, and users. The first key confirms that authentication is enabled, the second verifies that all members are still up and running, and the last one validates the users you were supposed to create.

**{ unauthorizedStatus: { "ok" : 0, "errmsg" : "not authorized on admin to execute command { replSetGetStatus: 1.0 }", "code" : 13 }, memberStatuses: ["PRIMARY","SECONDARY","SECONDARY"], users: [{"_id":"admin.will","roles":[{"role":"root","db":"admin"}]},{"_id":"$external.C=US,ST=New York,L=New York City,O=MongoDB,OU=University2,CN=M310 Client","roles":[{"role":"userAdminAnyDatabase","db":"admin"}]}] }**
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
# Homework 1.6: Enabling LDAP Authentication on a Replica Set

**Problem:**

In this lab, you will create a replica set that uses LDAP for authentication.

In the previous exercises for this course, you may have noticed that we have been specifying database as the hostname after the vagrant ssh command. This is because our Vagrantfile, which contains instructions to vagrant on how to set up the VMs, contains instructions for a second VM with the hostname of infrastructure.

For this assignment, you will need to use the two VMs which will communicate over your computer's local network.

Your MongoDB replica set cluster will be on the database VM and the OpenLDAP server will be on the infrastructure VM.

Note: These are not real Internet public hostnames. The hostname resolution for each is specified in the /etc/hosts files on each of the VMs.

In order to start the OpenLDAP on the infrastructure VM, run the following commands.

```
$ cd m310-vagrant-env
$ vagrant up
$ vagrant ssh infrastructure
```

Part of your provided scripts in the handout setup OpenLDAP and add a user named adam with the password password. After you've copied the handout's files to the shared folder your file structure should look like:

```
~
`-- shared
|-- ldap
| |-- Domain.ldif
| |-- pw.ldif
| `-- Users.ldif
|-- ldapconfig.py
|-- setup-hw-1.6.sh
`-- validate-hw-1.6.sh
```

On infrastructure go ahead and configure OpenLDAP by running:

```
$ cd ~/shared
$ ./setup-hw-1.6.sh
```

After you've got OpenLDAP up and running your ready to do your part! In order to enable LDAP authentication on this running replica set you're going to need to figure out how to perform the following tasks.

- Configure saslauthd to automatically start and use LDAP as its mechanism.

- Configure saslauthd to talk to the LDAP server. The information below will be very useful.

```
LDAP Server IP: infrastructure.m310.mongodb.university
LDAP Search Base: ou=Users,dc=mongodb,dc=com
LDAP Search Filter: (cn=%u)
```

- Start the saslauthd service.
- Fix the permissions on the saslauthd socket directory.
- Start three mongod instances on ports 31160, 31161, and 31162 with LDAP support enabled.
- Connect to the primary and initiate the replica set.
- Create an account for adam.
- Verify that you can authenticate to MongoDB with the username adam and his LDAP password of password.
- Add the other members of the replica set.
- Connect to the LDAP VM and change Adam's password to "webscale" by issuing the following command.

```
$ python ldapconfig.py passwd -u adam -op password -np webscale
```

- Reconnect to the Ubuntu VM and verify that adam's new password works.

Note: It's probably a good idea to test that your Ubuntu VM can talk to your LDAP server with testsaslauthd before you create your replica set. It's also important to point out that saslauthd caches credentials. When you change the password on infrastructure you might need to restart the saslauthd service in order to use the new password.

After you've enabled LDAP authentication on your replica set you can run the following script and copy the output into the submission area below.

```
$ cd ~/shared
$ ./validate-hw-1.6.sh
```

Note: If you've successfully enabled authentication on the replica set, then the validation script should output a JSON object with two keys: unauthorizedStatus and memberStatuses. The first key confirms that authentication is enabled, and the second verifies that all members are still up and running.

**{ unauthorizedStatus: { "ok" : 0, "errmsg" : "not authorized on admin to execute command { replSetGetStatus: 1.0 }", "code" : 13 }, memberStatuses: ["PRIMARY","SECONDARY","SECONDARY"] }**

0 comments on commit 84f41d6

Please sign in to comment.