Security hardening guide

Authentication restrictions

Tarantool Enterprise Edition provides the ability to apply additional restrictions for user authentication. For example, you can specify the minimum time between authentication attempts or disable access for guest users.

The following configuration options are available:

• auth_delay
• disable_guest

auth_delay¶

Specifies a period of time (in seconds) that a specific user should wait for the next attempt after failed authentication.

With the configuration below, Tarantool refuses the authentication attempt if the previous attempt was less than 5 seconds ago.

box.cfg{ auth_delay = 5 }

Since version: 2.11

Type: number

Default: 0

Environment variable: TT_AUTH_DELAY

Dynamic: yes

disable_guest¶

If true, disables access over remote connections from unauthenticated or guest access users. This option affects both net.box and replication connections.

Since version: 2.11

Type: boolean

Default: false

Environment variable: TT_DISABLE_GUEST

Dynamic: yes

Password policy

A password policy allows you to improve database security by enforcing the use of strong passwords, setting up a maximum password age, and so on. When you create a new user with box.schema.user.create or update the password of an existing user with box.schema.user.passwd, the password is checked against the configured password policy settings.

The following configuration options are available:

• password_min_length
• password_enforce_uppercase
• password_enforce_lowercase
• password_enforce_digits
• password_enforce_specialchars
• password_lifetime_days
• password_history_length

password_min_length¶

Specifies the minimum number of characters for a password.

The following example shows how to set the minimum password length to 10.

box.cfg{ password_min_length = 10 }

Since version: 2.11

Type: integer

Default: 0

Environment variable: TT_PASSWORD_MIN_LENGTH

Dynamic: yes

password_enforce_uppercase¶

If true, a password should contain uppercase letters (A-Z).

Since version: 2.11

Type: boolean

Default: false

Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE

Dynamic: yes

password_enforce_lowercase¶

If true, a password should contain lowercase letters (a-z).

Since version: 2.11

Type: boolean

Default: false

Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE

Dynamic: yes

password_enforce_digits¶

If true, a password should contain digits (0-9).

Since version: 2.11

Type: boolean

Default: false

Environment variable: TT_PASSWORD_ENFORCE_DIGITS

Dynamic: yes

password_enforce_specialchars¶

If true, a password should contain at least one special character (such as &|?!@$).

Since version: 2.11

Type: boolean

Default: false

Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS

Dynamic: yes

password_lifetime_days¶

Specifies the maximum period of time (in days) a user can use the same password. When this period ends, a user gets the “Password expired” error on a login attempt. To restore access for such users, use box.schema.user.passwd.

Note

The default 0 value means that a password never expires.

The example below shows how to set a maximum password age to 365 days.

box.cfg{ password_lifetime_days = 365 }

Since version: 2.11

Type: integer

Default: 0

Environment variable: TT_PASSWORD_LIFETIME_DAYS

Dynamic: yes

password_history_length¶

Specifies the number of unique new user passwords before an old password can be reused.

In the example below, a new password should differ from the last three passwords.

box.cfg{ password_history_length = 3 }

Since version: 2.11

Type: integer

Default: 0

Environment variable: TT_PASSWORD_HISTORY_LENGTH

Dynamic: yes

Note

Tarantool uses the auth_history field in the box.space._user system space to store user passwords.

Authentication protocol

By default, Tarantool uses the CHAP protocol to authenticate users and applies SHA-1 hashing to passwords. Note that CHAP stores password hashes in the _user space unsalted. If an attacker gains access to the database, they may crack a password, for example, using a rainbow table.

In the Enterprise Edition, you can enable PAP authentication with the SHA256 hashing algorithm. For PAP, a password is salted with a user-unique salt before saving it in the database, which keeps the database protected from cracking using a rainbow table.

To enable PAP, specify the box.cfg.auth_type option as follows:

box.cfg{ auth_type = 'pap-sha256' }

For new users, the box.schema.user.create method will generate authentication data using PAP-SHA256. For existing users, you need to reset a password using box.schema.user.passwd to use the new authentication protocol.

The examples below show how to specify the authentication protocol on the client side:

• For net.box, you can specify the authentication protocol using the auth_type URI parameter or the corresponding connection option:

  -- URI parameters
  conn = require('net.box').connect(
      'username:password@localhost:3301?auth_type=pap-sha256')
  
  -- URI parameters table
  conn = require('net.box').connect({
      uri = 'username:password@localhost:3301',
      params = {auth_type = 'pap-sha256'},
  })
  
  -- Connection options
  conn = require('net.box').connect('localhost:3301', {
      user = 'username',
      password = 'password',
      auth_type = 'pap-sha256',
  })
  

• For replication configuration, the authentication protocol can be specified in URI parameters:

  -- URI parameters
  box.cfg{
      replication = {
          'replicator:password@localhost:3301?auth_type=pap-sha256',
      },
  }
  
  -- URI parameters table
  box.cfg{
      replication = {
          {
              uri = 'replicator:password@localhost:3301',
              params = {auth_type = 'pap-sha256'},
          },
      },
  }
  

If the authentication protocol isn’t specified explicitly on the client side, the client uses the protocol configured on the server via box.cfg.auth_type.

Configuration

To configure traffic encryption, you need to set the special URI parameters for a particular connection. The parameters can be set for the following box.cfg options and nex.box method:

• box.cfg.listen – on the server side.
• box.cfg.replication–on the client side.
• net_box_object.connect()–on the client side.

Below is the list of the parameters. In the next section, you can find details and examples on what should be configured on both the server side and the client side.

• transport – enables SSL encryption for a connection if set to ssl. The default value is plain, which means the encryption is off. If the parameter is not set, the encryption is off too. Other encryption-related parameters can be used only if the transport = 'ssl' is set.

  Example:

  c = require('net.box').connect({
      uri = 'localhost:3301',
      params = {transport = 'ssl'}
  })
  

• ssl_key_file – a path to a private SSL key file. Mandatory for a server. For a client, it’s mandatory if the ssl_ca_file parameter is set for a server; otherwise, optional. If the private key is encrypted, provide a password for it in the ssl_password or ssl_password_file parameter.

• ssl_cert_file – a path to an SSL certificate file. Mandatory for a server. For a client, it’s mandatory if the ssl_ca_file parameter is set for a server; otherwise, optional.

• ssl_ca_file – a path to a trusted certificate authorities (CA) file. Optional. If not set, the peer won’t be checked for authenticity.

  Both a server and a client can use the ssl_ca_file parameter:

  • If it’s on the server side, the server verifies the client.
  • If it’s on the client side, the client verifies the server.
  • If both sides have the CA files, the sever and the client verify each other.

• ssl_ciphers – a colon-separated (:) list of SSL cipher suites the connection can use. See the Supported ciphers section for details. Optional. Note that the list is not validated: if a cipher suite is unknown, Tarantool just ignores it, doesn’t establish the connection and writes to the log that no shared cipher found.

• ssl_password – a password for an encrypted private SSL key. Optional. Alternatively, the password can be provided in ssl_password_file.

• ssl_password_file – a text file with one or more passwords for encrypted private SSL keys (each on a separate line). Optional. Alternatively, the password can be provided in ssl_password.

  Tarantool applies the ssl_password and ssl_password_file parameters in the following order:

  1. If ssl_password is provided, Tarantool tries to decrypt the private key with it.
  2. If ssl_password is incorrect or isn’t provided, Tarantool tries all passwords from ssl_password_file one by one in the order they are written.
  3. If ssl_password and all passwords from ssl_password_file are incorrect, or none of them is provided, Tarantool treats the private key as unencrypted.

Configuration example:

box.cfg{ listen = {
    uri = 'localhost:3301',
    params = {
        transport = 'ssl',
        ssl_key_file = '/path_to_key_file',
        ssl_cert_file = '/path_to_cert_file',
        ssl_ciphers = 'HIGH:!aNULL',
        ssl_password = 'topsecret'
    }
}}

box.cfg{ listen = {
    uri = 'localhost:3301',
    params = {
        transport = 'ssl',
        ssl_key_file = '/path_to_key_file',
        ssl_cert_file = '/path_to_cert_file',
        ssl_ciphers = 'GOST2012-GOST8912-GOST8912'
    }
}}

export TT_LISTEN="localhost:3301?transport=ssl&ssl_cert_file=/path_to_cert_file&ssl_key_file=/path_to_key_file"

Server-client configuration details

When configuring the traffic encryption, you need to specify the necessary parameters on both the server side and the client side. Below you can find the summary on the options and parameters to be used and examples of configuration.

Server side

• Is configured via the box.cfg.listen option.
• Mandatory URI parameters: transport, ssl_key_file and ssl_cert_file.
• Optional URI parameters: ssl_ca_file, ssl_ciphers, ssl_password, and ssl_password_file.

Client side

• Is configured via the box.cfg.replication option (see details) or net_box_object.connect().

Parameters:

• If the server side has only the transport, ssl_key_file and ssl_cert_file parameters set, on the client side, you need to specify only transport = ssl as the mandatory parameter. All other URI parameters are optional.
• If the server side also has the ssl_ca_file parameter set, on the client side, you need to specify transport, ssl_key_file and ssl_cert_file as the mandatory parameters. Other parameters – ssl_ca_file, ssl_ciphers, ssl_password, and ssl_password_file – are optional.

Encrypting traffic

Since version 2.10.0, Tarantool Enterprise Edition has built-in support for using SSL to encrypt the client-server communications over binary connections, that is, between Tarantool instances in a cluster. For details on enabling SSL encryption, see the Traffic encryption section of this guide.

In case the built-in encryption is not set for particular connections, consider the following security recommendations:

• setting up connection tunneling, or
• encrypting the actual data stored in the database.

For more information on data encryption, see the crypto module reference.

The HTTP server module provided by rocks does not support the HTTPS protocol. To set up a secure connection for a client (e.g., REST service), consider hiding the Tarantool instance (router if it is a cluster of instances) behind an Nginx server and setting up an SSL certificate for it.

To make sure that no information can be intercepted ‘from the wild’, run nginx on the same physical server as the instance and set up their communication over a Unix socket. For more information, see the socket module reference.

Firewall configuration

To protect the cluster from any unwanted network activity ‘from the wild’, configure the firewall on each server to allow traffic on ports listed in Network requirements.

If you are using static IP addresses, whitelist them, again, on each server as the cluster has a full mesh network topology. Consider blacklisting all the other addresses on all servers except the router (running behind the Nginx server).

Tarantool Enterprise does not provide defense against DoS or DDoS attacks. Consider using third-party software instead.

Data integrity

Tarantool Enterprise Edition does not keep checksums or provide the means to control data integrity. However, it ensures data persistence using a write-ahead log, regularly snapshots the entire data set to disk, and checks the data format whenever it reads the data back from the disk. For more information, see the Data persistence section.