S 4.429 Secure configuration of Lotus Notes/Domino

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Immediately after the installation, upgrade or migration, the installed, upgraded or migrated components must be configured. This is the only way to ensure that weaknesses of the default configuration cannot be used for attack within the period of time between the installation and configuration.

Secure basic configuration

The secure basic configuration of the Lotus Domino server includes correcting default insecure system parameters:

• By default, the anonymous access to Domino servers must be denied. If no xACLs (extended access controls) are used (in this case, the anonymous access is denied when installing the xACLs), the ANONYMOUS group must by default be set to NO ACCESS during the Domino installation. Access of Lotus Notes users whose certificates were issued by unknown certification instances and for whom there is no Cross certificate is treated by Domino as anonymous access. If anonymous access is permitted for individual databases, this must be released explicitly on the database level. If anonymous access to dedicated servers is desired, such access must be planned accordingly in the overall architecture and protected using other security safeguards. In particular, these servers should not provide services with high protection requirements.
• For the hash values of the HTTP passwords, the more secure hash format with salt value must be selected (available in Notes 4.6 and higher). This can be done via Actions -> Edit Directory Profile and selecting Yes in the check box Use more secure Internet password format. See also the Technote 1244808 of the manufacturer.

In addition to this, the access security settings being effective at the level of the Lotus Notes/Domino-Servers (and not at the level of the Domino services) must be made within the framework of the secure basic configuration:

• The comparison of the public key of the user's Notes ID when logging in with the copy of the public key stored in the name and address book must be activated by default.
• The access to the server must be restricted to the users listed in the name and address book of the server.
• The server check of the password of the Notes ID via hash values must be activated. This entails the risk that only the ID of the attacker is accepted as legitimate ID after the password has been changed when an attacker copies the ID and compromises the Notes password.
• Access/Deny lists must be set up and maintained both for servers and users. Thus, undesired connections can already be denied when the server is accessed (for example, for IDs of employees who have already left the organisation or if access is restricted to a limited period of time after expiration of a defined period of time).
• The use of routing servers (pass-through) must be prevented, if possible using a security-oriented architecture and network topology of the used Lotus Notes/Domino platform and the restriction of the pass-through access to defined user groups. General routing for all requesting servers (Routing via Server = *) must be avoided in any case.
• Certain server operations can be restricted on a list of users or groups. Examples of such operations are creating databases, generating replicas, using monitors, the administration via the web interface and running agents and scripts. Depending on the option, different requirements are used if no explicit list is stated. For example, all users can create new databases by default.
• The access rights to the name and address book (abbreviation: NAB, file names.nsf) must be assigned as restrictively as possible even if this results in compromises when the users use different functions.
• Administrative access rights must be assigned according to the administration concept for Lotus Notes/Domino using administrative roles [GroupCreator], [GroupModifier], [ServerCreator], [ServerModifier], [UserCreator], [UserModifier], [NetCreator] and [NetModifier].

Secure configuration of server settings for communication

Adequate communication security can be ensured via a SSL-encrypted connection with a communication partner authorised by a certificate.

A Domino server can be configured for the SSL use by means of the server certificate administration tool (certsrv.nsf). The prerequisite is the implementation of the concept for the domain and certificate hierarchies in S 2.207 Security concept for Lotus Notes/Domino. Afterwards, it is possible to configure individually at the log level (e.g. email logs IMAP, POP3, SMTP) for which logs SSL must be activated. The activation should be carried out depending on the protection requirements of the services used.

Forcing SSL connections can also be set for web access at the database level (web: Prompt for SSL connection). If possible, the SSL connection configuration should not be configured to the setting Only-server-authentication, but to Client certificate authentication as authentication method (not all logs support the client certificate authentication).

The following server-side parameters must be configured in compliance with the encryption policies of the organisation:

• Version of the SSL log (if possible, only SSL 3.0, as encryption methods for SSL 2.0 cannot be set in Domino),
• Accept SSL site certificates (setting NO to prevent the Internet server from being accessed without shared certificates),
• Accept expired SSL certificates (in general, setting YES to prevent problems with expired client certificates, NO for high and very high protection requirements),
• SSL encryption code (according to the organisation's own encryption concept, generally avoiding no encryption with MD5 MAC, no encryption with SHA-1 MAC and the 40-bit RC4 as well as the 56-bit DES encryption).

Secure service configuration

Among other things, Domino offers the following services:

• email services (Notes Mail, POP3-Mail, SMTP-Mail, IMAP-Mail)
• web services (Webserver, Instant Messaging and Presence, News (NNTP), web services in compliance with W3C-Standard SOAP 1.1, WebDAV)
• database services (including database replication and DB2 connection)
• DAOS (Domino Attachment and Object Service)
• groupware services
• Directory and CA services (certificate hierarchy services) including LDAP interface.

A secure service configuration must take into consideration both the common standards regarding the secure parameterisation of the services and the context within the framework of the security architecture in which this service is run. Thus, the configuration of an email or Instant Messaging service used only within the company and run on a Domino server without external connections can differ significantly from the configuration of the same service run on a server in the DMZ (demilitarised zone) for handling the email traffic and for instant messaging connection to the Internet.

It is therefore necessary to perform a security analysis for each service taking into account not only the protection requirements of the service, but also the protection requirements of the Domino server (and thus the other services running on the same Domino server). For this purpose, the recommendations described in S 2.207 Security concept for Lotus Notes/Domino must be implemented, especially the concept for the protection of the used Domino services contained in this safeguard.

For each service, both an authorisation concept for the access to the service (access concept) must be developed in the corresponding security concept and the service-specific parameters must be configured securely. Here, especially insecure default settings of the software must be corrected. This concept must be implemented for each Domino service directly after the installation of the service.

Services not in use should, if possible, not be installed by selecting an appropriate basic installation. If this is not possible, the corresponding server tasks must be deactivated.

Secure client configuration

For the Lotus Notes/Domino platform, different clients can be used. In this respect, a distinction must be made between the following types depending on the application scenario:

• administrative clients
• developer clients
• clients for end users.

From a technological perspective, a distinction must be made between the following clients:

• proprietary Notes clients
• Eclipse-based clients (Notes 8 and higher)
• browsers as clients
• proprietary clients on PDAs and smartphones
• foreign email clients accessing the Domino server via IMAP and POP3.

In general, all client types used must be protected according to the organisation-specific hardening concept and configuration requirements referred to in S 2.207 Security concept for Lotus Notes/Domino. For clients operated in connection with push services, the client-side parameters of the concept for the use of push services in S 2.207 Security concept for Lotus Notes/Domino must also be taken into consideration during configuration.

When planning the architecture, it must already be defined which client types are to be used. In this respect, it must be taken into account that different configurations might be required depending on the application scenario and protection requirements of the clients. In general, administrative and other clients with high protection requirements must be protected more restrictively.

In the client configuration, weaknesses arising from insecure default settings must be remedied. In addition to this, the parameters for the establishment of a secure connection, the replication parameters and the parameters for the Notes-based encryption of all client-side data must be taken into account. Here, the requirements of planning the communication security in S 2.206 Planning the use of Lotus Notes/Domino, the concept regarding the protection of the Domino services in S 2.207 Security concept for Lotus Notes/Domino and the concept regarding the use of the own security mechanisms of Notes/Domino in S 2.207 Security concept for Lotus Notes/Domino (among other things, for the encryption of the client-side data) must be taken into consideration.

If the Full client is used for the first time, the new complexity must be taken into account and detailed configuration requirements (ideally together with an adequate training offer for the users) must be prepared for the rollout.

Review questions:

• Are configuration requirements representing corresponding concepts for the protection of the services available and implemented for all services used?
• Are configuration requirements available for all clients used?
• If sensitive information (protection requirements "very high") is kept on clients (e.g. via replication), is this information adequately encrypted?