# MongoDB Security<br />ch3 Auditing and Best Practices

###### tags: `MongoDB University M310`

## Describe auditing capabilities
Auditing is an **enterprise** feature in MongoDB.

Why do we audit our database
* Add Accountability
* Investigate Suspecious Activity
* Monitor Database Activities

Auditing Capabilities
* Schema (DDL)
* Replica Set and Sharded Cluster
* Authentication and Authorization
* CRUD Operations (DML)

## Auditing output format

{
    atype: <String>,
    ts: {
        "$date":: <timestamp>
    },
    local: {
        ip: <String>, port: <int>
    },
    remote: {
        ip: <String>, port: <int>
    },
    users: [
        { user: <String>, db: <String> }
    ],
    roles: [
        { roles: <String>, db: <String> }
    ],
    param: <document>,
    result: <int>
}

* atype: action type
* ts: timestamp, time of the event
* local: ip addr and port number of running mongod instance
* remote: ip addr and port number of in coming connection associated with the event
* users: user and authentication database of user
* roles: the roles granted to the user
* param: detail of **atype** event
* reslt: error code

## Configuring audit from command line

mongod --dbpath /data/db --logpath /data/db/mongo.log --fork auditDestination <args>

**args can only be passed**:
* **syslog**: depend on opSys
* **console**
* **file**: needs to more options(auditFormat, autditPath)

mongod --dbpath /data/db --logpath /data/db/mongo.log --fork --auditDestination file --auditFormat JSON --auditPath /data/db/auditLog.json

#### config file

systemLog:
    destination: file
    path: /data/db/mongo.log
storage:
    dbpath: /data/db
auditLog:
    destination: file
    format: JSON
    path: /data/db/auditLog.json

## Definition of filters
By default only 3 catergories be audited
* Schema (DDL)
* Replica Set and Sharded Cluster
* Authentication and Authorization

Because once we audit CRUD operation, there will be too many log.
That makes us lose performance and hard to read the logs.

### Audit filter
for example:

{ "atype": { "$in": { "createCollection", "dropCollection" } } }

## Enabling the first audit filter
With command line

mongod --auditFilter <filterStr>

Add in config file

systemLog:
    destination: file
    path: /data/db/mongo.log
storage:
    dbpath: /data/db
auditLog:
    destination: file
    format: JSON
    path: /data/db/auditLog.json
    filter: '{ "atype": { "$in": { "createCollection", "dropCollection" } } }'

## DDL operations definition
* DDL (Data Definition Language)
**make change of schema of a database.**
* createCollection
* createDatabase
* createIndex
* renameCollection
* dropCollection
* dropDatabase
* dropIndex
* DML (Data Manipulation Language)
**manipulate the data within database**

:::info
**Most of auditing action are actually related to DDL rather than DML operations, EXCEPT 'authCheck'.** Becuase for the most part, auditing within MongoDB is designed to monitor changes made to the configuration of database
:::

## Example of DDL audit filter

Simple example for **createIndex** operation in **my-app** database

{ "atype": "createIndex", "param.ns": { "ns": "/^my-app\./" } }

## DML operations definition
* DML (Data Manipulation Language)
**manipulate the data within database**
* authCheck
* CRUD

:::info
The action type of **CRUD** is **authCheck**!

This is because CRUD operations are passed as parameters to the authCheck event.

Every time that you try to create, read, update or destroy data within your database, authCheck is going to be the action type that's actually firing from an auditing perspective.
:::

## Enabling auditAuthorizationSuccess

To enable the auditing of DML operations, actually we want to do is enable the auditing of **authorization success**

systemLog:
    destination: file
    path: /data/db/mongo.log
storage:
    dbpath: /data/db
auditLog:
    destination: file
    format: JSON
    path: /data/db/auditLog.json
setParameter: { auditAuthorizationSuccess: true }

:::info
By setting auditAuthorizationSuccess to true we can effectively audit CRUD operations as an authCheck is required for all CRUD operations.
:::

## Log Redaction
MongoDB provides a further strengthening protection by redact data from the system log

## Log Redaction Setup
:::warning
To capture every signle CRUD instruction into our logs.

Set the slow ms value to -1.

db.setProfilingLevel(0, -1)

:::
#### To enable redaction we have 3 different options.

1. Pass **redactClientLogData** to mongod

mongod --redactClientLogData

2. Set up in mongodb config file

storage:
    dbPath: /data/redaction
systemLog:
    destination: file
    path: /data/redaction.log
security:
    redactionClientLogData: true

3. In mongodb shell

Once the server reboots, we need to make sure to set it up again

db.adminCommand({setParameter:1, redactionClientLogData: 1})

:::danger
mongos | mongod

The flag should be set on Mongos and Mongod. make sure to redact the log message of all individual mongos and all individual mongod. Otherwise, might get a leak!
:::

## Security Checklists

* Enable Access Control and enforce Authentication
* Configure a Role Access Control
* Encrypt Communication
* Encrypt and Protect Data
* Limit Network Exposure
* Audit System Activity
* Run mongod With Dedicated User
* Run mongod With Secure Configuration Options
* Request a Security Technical Implementation Guide(STIG)
* Consider Security Standards Compliance

#### Enable Access Control and enforce Authentication
* SCRAM-SHA-1
* X.509 Certificates
* Require authenticaiton for all clients
* Enable authentication on each MongoDB server

**Disable server-side scripting**

mongod --noscripting

## Security Reports

**Reporting a Vulnerability in MongoDB

* Submit a ticket on the SECURITY Project on our JIRA
* Send an email to [e-mail]