(A) Assume the identify of a Domino administrator, (B) Attain access to all web user credentials including user names, passwords and internet addresses and (C) Attain operating system level access.1. Prevent unauthorized access to Domino server DBs / mailboxes by identifying security holes in Access Control Lists (ACLs).
A. Generate ACL reports including expanding nested group ACL entries using a 3rd party tool such as ACL Dominator in the Beacon Award nominated Notes Crucial tools suite.
B. Review the reports to see if any unathorized users inadvertantly have access to each database or mailbox.
C. Fix ACL issues discovered in reports including any changes required to Domino Directory (DD) person or group documents.
2. Prevent hackers from decrypting hashed Domino web passwords:
A. Web autheticated hackers with minimal access
Cross-site request forgery (CSRF) vulnerability in webadmin.nsf (aka Domino Web Administrator) in Domino 9.0 and 8.5 (and most likely 11 and 10) allow remote authenticated users to hijack the authentication of unspecified victims via unknown vectors, as well as, operating system level access.
ACTION REQUIRED: Delete webadmin.nsf and webadmin.ntf from all Domino web servers.
B. Notes ID and web autheticated autheticated hackers with minimal access
a. Open HCL DD (names.nsf). Click File - Application - Access Control List - Advanced, then select "Enforce a consistent Access..." as seen below. Click "Enable Extended Access" as seen below, then click OK - OK - OK.
b. Click File - Application - Access Control List, then "Extended Access" button a seen below.
c. In the Target pane, select the root [ /] and click "Add" button - Default.
d. Select "Default" in the Access List pane.
e. Click "Form and Field Access" button. The Form and Field dialog box appears.
f. Select "Person" In the Forms list box. Leave the Access settings for Forms blank.
g. Select "HTTPPassword" in the Fields list box and select "Deny" for Read and Write access. Select "dspHTTPPassword" (it it exists) in the Fields list box and select "Deny" for Read and Write access. Click OK.
Note: Optionally, you can deny access on these fields as well if you do no want to tip off hackers about your company password requirements: HTTPPasswordChangeDate, HTTPPasswordChangeInterval, HTTPPasswordGraceInterval, PasswordChangeDate, PasswordChangeInterval, PasswordDigest, PasswordGracePeriod, CheckPassword
h. In the Target pane, select the root [ /] and click "Add" button - Self. Select "The container and descendants" for Scope of Target field. Select "Allow" for all access options.
i. In the Target pane, select the root [ /] and click "Add" button - Name. Click the person icon, then select the name of your Servers group, then click "Add" button. Select the name of your Domino administrator group, then click "Add" button. Click OK.
i.e. LocalDomainSerers, LocalDomainAdmins
j. Select, for example, LocalDomainServers, then select "The container and descendants" for Scope of Target field. Select "Allow" for all access options.
k. Select, for example, LocalDomainAdmins, then select "The container and descendants" for Scope of Target field. Select "Allow" for all access options.
l. Click OK - OK
Note: If Anonymous access was previously defined in the access list, it should be set up to deny read and write access to HTTPPassword and dspHTTPPassword (if it appears) fields in the Person form.
3. Prevent hackers from displaying all Domino Directory users (i.e. web login user names): This flaw will allow a web authenticated user to see all the Domino Directory users, web login user names and internet addresses. Hackers can attempt to guess passwords or send users phishing emails to attain passwords.
Note: Once xACLs are enabled for a Domino Directory, LDAP anonymous access is not controlled by the list of fields in the All Server Configuration document. Since the default xACL setting for Anonymous is "No Access," once xACLs are enabled all anonymous LDAP searches will fail.
ACTION REQUIRED: Open HCL DD (names.nsf). Click File - Application - Access Control List - Advanced, then set Maximum Internet and Password to: No Access. Click OK button. Optionally, for even tighter security check all 30 internal Domino systems DBs (*see list below) and set Maximum Internet and Password to: No Access
Note: The native Domino web password change feature will still working properly. i.e. /names.nsf?changepassword
Note: Warning - If a Domino web form is performing lookups (.i.e. @DBLookup) to the HCL DD (names.nsf), then it will return an error. You might consider changing the code and moving data to either (A) your existing web app app or (B) if looking up authentication credentials, then to an external (secondary) DD which uses a difficult to guess filename. i.e. extnames2020.nsf
Note: Warning - If a Domino web app uses client side web technologies which make calls to web addresses with "names.nsf", then it most likely will stop working. i.e. Ajax calls to names.nsf
Note: Warning - If a Domino web app is creating web accounts with an agent set to run as "Run as web user" you might need to set Maximum Internet and Password to: Depositor
4. Prevent hackers from quickly decrypting Domino hashed passwords if they attain access to Domino Directory: Enable stronger Domino web encrypted hash passwords.
A. Open HCL DD. Click Actions - Edit Directory Profile. Change "Use more secure Internet Passwords" field to Yes with highest Domino release option as seen in example below. Click Save & Close button. Restart Domino server software.
B. Force user to change password on next web login. Edit user's person record in HCL DD. Click Administration tab, then select Yes in "Force user to change..." field as seen below. Click Save & Close button. NOTE: You can also create a simple Formula agent which changes this value for all selected users. i.e. FIELD HTTPPasswordForceChange := "1";
5. Prevent hackers from guessing Domino web passwords with several repeated attempts: Enable Domino Internet Password Lockout feature. You can give the IT help desk ACL Editor access to unlock users in the "Internet Password Lockout" Notes DB if user's call to get unlocked. Or simple set auto-unlock to 15 minutes. This will help prevent hackers from guessing passwords for users over several attempts.
ACTION REQUIRED: Create the Domino "Internet Password Lockout" DB (inetlockout.nsf) using the template in the Domino data server root folder. Edit the Domino web server configuration record, then click the Security tab and changes settings as seen in the example below. Click Save & Close button. Restart Domino HTTP server task.
6. Prevent hackers from guessing Domino web passwords using data dictionaries with trivial passwords: Increase Domino web password requirements using a Domino Security policy
A. Create or edit existing Domino Security policy. Open HCL DD, then click Configurations - Servers - Policies. Create or edit a Security policy. Click Password Management tab. Change "Required Password Quality" field, for example, to 13 (password quality scale table can bee seen in reference sources link below). Click Save & Close button.
B. Force user to change password on next web login. Edit user's person record in HCL DD. Click Administration tab, then select Yes in "Force user to change..." field as seen below and click Save & Close button. Click Save & Close button. NOTE: You can also create a simple Formula agent which changes this value for all selected users. NOTE: You can also create a simple Formula agent which changes this value for all selected users. i.e. FIELD HTTPPasswordForceChange := "1";
7. Prevent hackers from easily guessing simple Domino web login user names: Domino by default allows multiple user names for each user including first name, last name, short name, etc. This potentially allows a user with unique first or last name to be guessed by a hacker. i.e. John, Jill, Smith, Jones
ACTION REQUIRED: Open HCL DD and edit Domino web server record. Click Security tab, then change the "Internet Authentication" field to "Fewer name variations..." as seen below.
* Domino internal system DBs
- cdc.nsf (Condensed Domino Directory if exists - might be another filename)
- certsrv.nsf (Server Certificate Administration if exists - might be another filename)
- da.nsf (Director Assistance if exists - might be another filename)
- daoscat.nsf (DAOS Catalog if exists)
- dbdirman.nsf (Domino Directory cache)
- dircat.nsf (Directory Catalog if exists)
- domlog.nsf (Domino Log if exists - might be another filename; ignore if web logs writing to OS text files)
- edc.nsf (Extended Domino Directory if exists - might be another filename)
- idvault.nsf (ID Vault if exists)
- inetlockout.nsf (Internet Lockouts if exists - might be another filename)
- lndfr.nsf (Domino Fault Reports if exists)
- LotusTraveler.nsf (HCL Traveler if exists - might be another filename)
- mtdata/mtstore.nsf (if exists)
- password.nsf (Password Recovery generic mailbox - might be another filename)
- reports.nsf (Reports Database if exists - might be another filename)
- smupgrade.nsf (SmartUpgrade Kits if exists - might be another filename)
- xnames.nsf (External / Secondary Domino Directory if exists - might be another filename)
HCL Domino password quality scale
When creating passwords for user, server, or certifier IDs, you need to understand the criteria by which Domino measures password strength and security. Domino measures this criteria according to the level assigned on its password quality scale. The scale assigns a minimum level of quality to the password on an ID file. Domino bases the password quality on the number and variety of characters in the password.
Securing Internet passwords for HCL Domino Server
Internet passwords can be subject to attacks by malicious sources. However, there are measures you can take to make Internet passwords more secure.
Server security for HCL Domino
To secure Domino servers, you allow and prevent user and server access. You can restrict the activities that users and servers may perform on the server.
Overview of HCL Domino security
This section describes security features, including execution control lists, IDs, and SSL. Setting up security for your organization is a critical task. Your security infrastructure is critical for protecting your organization's IT resources and assets. As an administrator, you need to give careful consideration to your organization's security requirements before you set up any servers or users. Up-front planning pays off later in minimizing the risks of compromised security.
Securing a HCL Domino Web server
Many customers use Domino for their intranet or Internet sites. Securing the Domino server in these environments is very important to ensure both the integrity of the data and the availability of the Web site, especially on the Internet. In this article, we discuss how you can use Domino security features to enforce security in your Web environment. We begin with a quick overview of the Domino security model. Then we look at securing a Web server through Web authentication, server security, and data security. This article assumes that you are an experienced Domino system administrator.
Securing a HCL Domino Web Server: A case study
Many customers use 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 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.
Securing a HCL Domino Web server: Using the new Internet lockout feature
Internet password lockout lets administrators set a threshold value for Internet password authentication failures for users of Domino applications, including Domino Web Access. This lockout helps to prevent brute force and dictionary attacks on user Internet accounts by locking out any user who fails to log in within a preset number of attempts. Information about authentication failures and lockouts is maintained in the Internet Lockout application, where the administrator can clear failures and unlock user accounts.