Using a case study, the authors of this article describe some best practices and recommendations from the field for securing an IBM Lotus Domino Web server.

Many customers use IBM Lotus Domino in their intranet or Internet Web sites. Securing a Domino server in these environments is important to ensure integrity of data and availability of the Web site, especially on the Internet. Our previous developerWorks Lotus article, "Securing a Domino Web Server" discussed the Domino security model and how to secure a Web server with respect to Web authentication, server security, and data security. In this article, you learn the specific configurations and settings to implement these features, using a recent customer case study. This article assumes that you are an experienced Domino system administrator.

The article is divided into the following sections:

• System administration and usage – how access and administration are separated
• Case study architecture – the architecture of our single Domino server environment
• Domino server configuration – specific configuration and settings to make the server secure
• Application configuration – how a DSAPI filter was used to provide stronger authentication and authorization controls
• System monitoring – how security and access events were monitored

System administration and usage

In this case study, we separated the users into two groups. One group included the Web application users, and the second group included the server administrators. The Web application group contained internal and external users who use the Web application. The second group contained internal administrators who administer both the server’s operating system and the Lotus Domino server. There was no administration of the server performed from the Internet, and to further reinforce this, the webadmin.ntf and webadmin.nsf databases were removed. Thus, administration of the server was performed only by the Lotus Domino Administrator client and through the Secure Shell utility (SSH), which is an encrypted method of access for Linux servers that is only available for the internal administrators.

Linux was chosen for this case study for two primary reasons. Linux is not subject to the same level of virus attacks as other operating systems, and it provides a secure method of remote administration. Linux also provides the ability to disable all unnecessary or unused services on the operating system, limiting the potential for security risks by reducing the number of services operating on the server.

We also separated our administration group into two subgroups, one to administer the operating system and a second subgroup to administer the Lotus Domino server. The operating system administration group was responsible for all operating system functions, such as upgrades, backups, operating system users, group administration, and installation of Lotus Domino. The Lotus Domino administrators were responsible for the users and group administration, server configuration, and server maintenance.

Case study architecture

Our customer needed a simple external Web site to publish research information as part of a virtual library. Although the content was private, the volume of the data and features required were well suited to a Lotus Domino environment, and a single-server solution was designed to meet their needs.

This case study involves a single Lotus Domino Web server located in the network demilitarized zone (DMZ) and running SUSE Linux and Lotus Domino 7. The techniques demonstrated in this article work with any operating system; however, we chose Linux over Microsoft Windows as a less vulnerable target to viruses and hacking. We used SSH because it provides secure encrypted access to a remote Linux server, which provides access to a single application database. Figure 1 illustrates the case study architecture.

Figure 1. Case study architecture

By making only ports 80 and 443 accessible from the Internet, we prevent the server from being compromised. Also, you can see that ports 22, 80, 443, and 1352 are the only ports accessible from the internal network (which is normally defined as the trusted network). This also limits the exposure of the servers to any internal malicious activity. These ports are described in Table 1.

Table 1. Network port definitions

Port Number	Port Description
22	Secure Shell (SSH) is a program that logs into another computer over a network to execute commands on a remote machine. It provides strong authentication and secure communications over insecure channels. It's typically used on a UNIX or Linux operating system.
80	HyperText Transfer Protocol (HTTP) is the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted and which actions Web servers and browsers should take in response to various commands.
443	Secure Sockets Layer (SSL) uses a cryptographic system that uses two keys to encrypt data: a public key known to everyone and a private or secret key known only to the recipient of the message. SSL encrypts HTTP traffic.
1352	Notes Remote Procedure Call (NRPC) is the foundation for communication between Notes clients and Domino servers or between two Domino servers. Enabling port encryption is recommended.

NOTE: The targeted server is located between two firewalls. This configuration provides the ability to assign different permissions and access levels based on access from the trusted network and the untrusted Internet.

Domino server configuration

This section discusses the Domino server configuration used for our case study, including the Domino Server document and Configuration document settings that are most relevant to security. Let's start by looking at the Domino Server document. There are two new options to Lotus Domino 7 that do not necessarily apply to Web servers, but assist in the administration of an external domain. These options are "Compare public keys" and "Log public key mismatches."

Typically, administrators for an organization cross-certify their IDs with the external domain. These two options allow for enforcement of public key matching. Should an ID become compromised, a new public key can be generated by the creation of a new ID, locking the old ID out of the system. These new settings with the highest level of security are shown in figure 2.

Figure 2. Public key checking

All HTTP communications with the server were enforced to use the SSL protocol. If you configure the Domino Server document to redirect all HTTP requests to SSL, it forces all HTTP connections to use SSL. All anonymous SSL connections to the server were also blocked. The server does not display any information to the user until the user has authenticated. The Server document settings are shown in figure 3.

Figure 3. Server Web settings

The SSL certificate is generated following the procedure in the developerWorks Lotus article, "Trust Yourself: Become your own Certification Authority."

You can enforce stronger Internet authentication settings with the Notes.ini NABWebLookupView parameter. The parameter locks out all other name variations besides the user name listed in the first column of the view used to perform look-ups. In our case study, we allowed authentication only with the users’ common name (for example, Matthew Milza). If a user were to try any other variation of his name, such as Internet email address, he would not be allowed to access the system.

Now, let's configure the Notes.ini settings parameter in the Server Configuration document and create a view called "($webaccess)" in the Domino Directory that sorts only by common name. A sample of the view is shown in figure 4, and the Notes.ini settings for the Configuration document are shown in figure 5.

Figure 4. Web authentication view



Figure 5. NABWebLookupView configuration setting

Application configuration

With Lotus Domino, you can create and manage password policies for Lotus Notes passwords; however, Lotus Domino does not provide all the same password policy capabilities for Web authentication out-of-the-box. Lotus Domino 7 provides the ability to enforce Internet password changes after a specified length of time and enforces password quality and length, which you can configure by means of a security policy. Lotus Domino 7 also allows you to lock out a user account and to force a password change on next authentication.

To enforce a stronger Internet password policy, you can develop a custom authentication Domino Security API (DSAPI) filter, or authentication can occur against an LDAP directory. Most LDAP directories can enforce an adequate password policy.

Our solution requires a more complete set of ID management features, as follows:

• Separate account expiration and password expiration rules
• Password quality, length, and special character checking
• Digest of previously used passwords
• User self-service for password change and password reset functions
• Failed login-attempt lockout
• Configurable Web user interface forms, text, and graphics

To provide these features, let's turn to an IBM Software Services for Lotus (ISSL) asset that employs a custom authentication DSAPI filter. This asset, called Internet Password Manager (IPM), satisfies all the security functions needed for this case study.

NOTE: IPM is a custom set of Domino databases and DSAPI filter that provides more control over the management of Web passwords. For more information about this asset, please contact the authors.

IPM adds several design elements to the Domino Directory to provide the account management functions to enable, disable, extend, and reset user accounts manually. Additional Domino application databases (NSF files) are created from supplied templates to provide the user interface features for logon, password change, and mail notifications. Specific groups are defined to control the password administrators and servers that are participating in the password management environment.

Figure 6 shows the specific Configuration document in the Domino Directory that controls the features of the password management system.

Figure 6. Internet Password Management Configuration document

A subform that extends the Person document schema displays the settings that are added for each user (see figure 7).

Figure 7. Additional subform in Person document

The core processing is provided through a DSAPI filter that was developed for the operating system and is placed in the Domino server’s Program directory. To enable the Domino HTTP server to use IPM, you must configure the Authorization Extension filter. For each participating server, add the DSAPI filter library name of the installed Authorization Extension (for example, libipwext.so) to the DSAPI filter file names field (see figure 8). This is found in the Server document under the Internet Protocols tab - HTTP subtab DSAPI area. Once configured, these additional databases and settings enable the user interface and password controls to enforce the enhanced security features.

Figure 8. DSAPI filter file name

The default logon page is shown in figure 9.

Figure 9. Default Logon page

As an example scenario, if the user repeatedly attempts to access the site, but fails to log on with the correct password, access is denied. Based on the configuration parameters, the failed logon attempts lock out the user from the system and are shown in the server console (see figure 10).

Figure 10. Server logging of logon failures and lockouts

You can also restrict access to system databases through Access Control List (ACL) settings and the "Don’t allow URL open" database property located in the Web Access section on the Basics tab of the properties box. This prevents the database from being opened from the Web, which was a new feature in Lotus Domino 6. When you enable the property on the Domino Directory (names.nsf), users can still authenticate, which is quite useful when registered users need to remain anonymous to other users of the server.

Domino Domain Monitoring

Domino Domain Monitor (DDM) is new to Lotus Domino 7. DDM uses a set of pre-configured probes to gather status/process information about the servers being monitored. These probes collect data related to applications, databases, directories, messaging, replication, security, the operating system, the server, and the Web. Special filters enable you to select the type and level of data recorded by the probes. After the data has been collected, it is consolidated, organized, and processed into easy-to-read summary reports. DDM comes with three out-of-the-box security probes that check the Server document, Server Configuration document, and Person documents to verify that the settings meet best practices. It can also report unauthorized access attempts to the server and thus is a useful tool for auditing your Lotus Domino server security.

DDM results are collected automatically in the Event Resolution Center (ERC). Each event that is processed and placed into the ERC database has a document link back to the specific monitor that generated the event. The ERC is updated with a status document each time a probe detects an error or when a particular threshold is exceeded. By viewing DDM events recorded in the ERC, you can identify (and in some cases, even predict) systemic Domino events. The ERC is automatically created when you start the first server. The ERC database is based on the new template ddm.ntf; by default, its file name is ddm.nsf. Figure 11 shows an example of how to enable the Best Practices Probe in the Events4.nsf database.

Figure 11. Security Probe document

The Specifics tab from the Security Probe document provides a list of server settings that are validated by this probe, including:

• Compare Notes Public Key against those stored in directory
• Check password
• Allow anonymous Notes connections
• Required change interval
• Check passwords on Notes IDs
• Check for existence of ID file in the Person document
• Internet authentication
• Check the security of SSL settings
• Check the security of Web settings
• Check the security of Domino Directory settings
• Check the security of Mail settings
• Check the security of DIIOP settings
• Check the security of the Remote Debug Manager
• Use more secure Internet passwords
• Security settings in my Configuration Document
• Internet password
• Verify all Server document Security tab sections:
  • Admins
  • Program
  • Web
  • Security settings
  • Server access
  • Pass-thru use

The following tables demonstrate the type of information each probe displays in ERC. The ERC database (filename ddm.nsf) contains the data generated by active DDM probes. When a probe runs, it records all relevant data it finds (if any) in a report that is placed in the ERC. This report contains the results of the specific probe, the probable cause that generated the result, suggested solutions for each event, and a link to the probe that was used to generate this event. Then a probe runs and records all relevant data it finds (if any) into a report that is placed in the ERC. This report contains the results of the specific probe, the probable cause that generated the result, suggested solutions for each event, and a link to the probe that was used to generate this event.

NOTE: This example does not show the full results of the probe.

Security Best Practices Probe: Server Document

Results: Server Documents have been analyzed, and 30 percent of the configuration does not match recommended best practices.

Administration section

Field name	Field value	Recommendation
Administer the server from a browser	EMPTY	Verify that this field specifies a name or group of names, and that it does not contain an asterisk value.

Programmability Restrictions section

Field name	Field value	Recommendation
All fields in this section are configured according to best practices

Security Best Practices Probe: Server Configuration Documents

Server Configuration Documents have been analyzed, and 5 percent of the configuration does not match recommended best practices.

Configuration section

Field name	Field value	Recommendation
DNS Blacklist filters	Disabled	When enabled, Domino will check if the connecting host is listed in the Blacklist at the specified sites.
Verify connecting host name in DNS	Disabled	When enabled, Domino will verify the name of the connecting host by performing a reverse DNS lookup.
Verify senders domain in DNS	Disabled	When enabled, Domino will verify that the sender's domain exists before delivery processing continues.
Verify that local domain recipients exist in the Domino Directory	Disabled	When enabled, Domino will verify that the recipient is a valid user before delivery processing continues.
Encrypt all delivered mail	Disabled	When enabled, Domino will encrypt messages to local mail files.

Security Best Practices Probe: Person Documents

Potential security risks have been found in four Person document(s). Four have been reported to the Details tab inside. 31 percent of the configuration does not match recommended best practices.

Eight person document(s) from the Domino Directory were analyzed. The number of potential security risks are reported below.

User Name: my admin/myorg
Field name	Field value	Recommendation
Check password	Don't check password	It is recommended that this field be set to - Check Password.
Required change interval	0	It is recommended to have a password change interval set.
Grace period	0	Enter the length of time in days that users have to change an expired password.
Checking for User ID	User ID is still attached to Person Document.	Save and detach this User ID to the id folder in your data directory.

One of the biggest security issues identified during formal audits is known as Configuration Shift. Over time, configuration for a server can change due to various issues, fixes, and troubleshooting. At the end of the day, this can be a significant security issue. Change control should be used to help manage Configuration Shift, but it does not always catch unwanted changes that are manifested in the Server document. You can use DDM to detect this shift by creating a Security Configuration probe. The DDM Security Configuration probe compares one Domino Server document and a target Server document, and then reports any differences and/or discrepancies. This type of security probe also has a Specifics tab that you can configure, enabling you to compare one server configuration to the server being probed and helping you identify Configuration Shift. Probe options include the following (see figure 12 for an example):

• Which server should be used as the guideline server?
• Which server settings should be compared to the guideline server's settings? You have several options:
  • Directory Profile Note
  • Security settings in the Server Configuration document
  • Server document (All Sections) or individual sections such as Admins, Program, Web, and so on.

Figure 12. Security Configuration Probe
 

Activity Logging

Activity Logging records user activity by person, database, and access protocol. It is often used in conjunction with Activity Trends, which collect and store activity statistics as current observations and historical trends. The activity statistics relate to the server, databases, users, and connections of users to databases and enables administrators to track the users who are active on a system. The data should be reviewed monthly, and any user who was not active in the past 90 days should be locked out of the system--a policy that helps prevent unused accounts from being accessible.

Figure 13 displays the statistics to be logged for our implementation in which tracking was enabled for all server agents, HTTP sessions, SMTP sessions, SMTP mail, Notes database sessions, Notes sessions, and Notes mail.

Figure 13. Activity Logging configuration

Activity Trends provide information, such as the last time a user accessed the server, that you can use to keep track of accounts that are inactive (see figure 14). In this case study, accounts that are inactive for 60 days were monitored. The account was then locked out of the system for 30 days, and once a total of 90 days of inactivity was tracked, the account was removed.

Figure 14. User activity tracking

Activity Trends can also keep track of which databases users are accessing in the Connections\By User view. This can be used to verify that users are not accessing inappropriate databases and can be used in addition to the Domino Web Server Log discussed below, providing additional user activity tracking at a high level. (The details of the HTTP requests are stored in the Domino Web Server Log database.)

You can log your server activity and Web server requests to the Domino Web Server Log (DOMLOG.NSF) database (see figure 15). This option is preferable if you want to create views and view data in different ways. Logging to a database is somewhat slower than logging to text files, especially at busy sites, and the size of the database can become large so that maintenance becomes an issue. However, if you use the Domino Web Server Log, you can treat this information as you would other Notes databases while using built-in features to analyze the results.

Figure 15. Example of Domino Web Server Log

The DOMLOG.NSF database logs all Domino Web server activity and tracks the following information about each HTTP request:

• Date and time the request was made
• User's IP address (or the DNS address, if DNS lookup is enabled in the Server document)
• User's name (if the user supplied a name and password to access the server)
• Status code the server returns to the browser to indicate its success or failure in generating the request
• Length of the information, in bytes, sent from the server to the browser
• Type of data accessed by the user, for example, text/html or image/gif
• HTTP request sent to the server from the browser
• Type of browser used to access the server
• Internal and Common Gateway Interface (CGI) program errors
• URL the user visited to gain access to a page on this site
• Server's IP address or DNS name
• Amount of time, in milliseconds, to process the request
• Cookies sent from the browser
• Translated URL (the full path of the actual server resource, if available)

The Domino Web Server Log for our case study is configured to track IP addresses that have accessed the Web server. If there are IP addresses that are constantly probing the site, they can be blocked at the firewall. As you can see from the example in figure 15, the incoming IP addresses are tracked until the user authenticates, after which all sessions are tracked under that user’s name. This can help prevent denial of service attacks.

NOTE: There are some third-party DSAPI filters that perform this function automatically.

The DSAPI filter used to provide Internet password management also provides some statistics that can be monitored. Alerts are set for when users are locked out of the system due to exceeding the threshold for failed login attempts, as follows:

IPWEXT.Login.Failed.Lock = Login attempts with invalid password resulting in account lockout

Additional security considerations

Port probing is a process that involves scanning all available ports on your server that are accessible to the Internet. A server should only be accessible on a limited number of ports. The ports that are opened for our server were detailed above. Port probing by hackers is usually an attempt to execute malicious code on a server or to take control of the server by looking for vulnerable ports.

Operating-system updates and patches should be installed on a regular basis. We used a Linux server for our case study because most patches can be installed without affecting the Domino server. Patches to the Kernel require a reboot, and patches to the TCP/IP protocol may affect the Domino server. All unnecessary packages or software should be removed from the server. Because updates on a Linux server rarely affect the Domino server, updates were scheduled to occur weekly.

The United States Computer Emergency Readiness Team (USCERT) posts any new vulnerability in the operating system, firewall, network, or software. The team sends out emergency warning reports as well as weekly reports that should be reviewed to minimize potential vulnerabilities.

For Lotus Notes and Domino security vulnerabilities, refer to the developerWorks Lotus Security page.

You should continually monitor the entire computer infrastructure. You should also review the Domino Web Server Log, Activity Trends, DDM probe results, and USCERT reports monthly, and review the logs to thwart hacking attempts. If you notice the same IP address range attempting to access the server, or the same malformed URLs being sent to the server, these requests should be blocked by the firewall or by the Domino server. Continuous monitoring assists in preventing unauthorized access to the Web server.

About the authors

		Matthew Milza is a Senior I/T Specialist. He is an experienced Lotus consultant specializing in administration, infrastructure, and security. Matthew has worked with numerous companies as a Lotus Software consultant and has experience as an architect for Lotus Domino, Lotus QuickPlace, and Lotus Sametime infrastructures. He has co-authored an IBM Redbook on Lotus security and an IBM Redpaper on Lotus Domino performance and has also published articles in Lotus Advisor on single sign-on and Lotus Domino mail server performance.

		Scott Rogers is a project manager with IBM Software Services for Lotus. During his nearly 12 years of Lotus Notes and Domino consulting experience, he has focused on messaging and high-value business applications for small- and medium-sized organizations. When not responding to instant messages from six different services, he enjoys relaxing with his family in Northborough, Massachusetts.