Chris Linfoot | DOMCFG.nsf - what did I miss?

Thursday, 21. September 2006

DOMCFG.nsf - what did I miss?

In a recent security audit the auditor, having failed to find anything hugely significant, did point out that some allegedly critical system databases on Internet facing Domino servers were open to anonymous access. When we checked, "some" was in fact one - DOMCFG.nsf.

Well, if you have custom login forms in DOMCFG.nsf, you can't disable anonymous access - the help says to set it to Reader which is exactly how we have it set.

Make sure the Web server exists. (cwl: duh!)
From the Domino Administrator, choose File - Database - New.
Under Server, enter the name of the Domino server on which you want to create this database.
Select the Domino Web Server Configuration template (DOMCFG5.NTF) from the Advanced Templates list.
Under Title, enter a name for the database.
Under File name, enter DOMCFG.NSF.
Note The database must have this file name.
Click OK.
Add an entry named Anonymous to the database ACL and give the entry Reader access. (cwl: emphasis added)
Map custom Web server messages.

Trouble is if you then surf to, for example, http://domino.example.com/domcfg.nsf, you will see a web version of DOMCFG in all its glory and if you open some documents (login form, change password form and error message form), you can edit them and save the change even if not authenticated!

The design is a completely standard DOMCFG as shipped with Domino 7.

So, why is a reader able to save changes to documents in this database? Because the above mentioned forms are all available to public access users.

Does anyone else see this? Have you locked it down? What did I miss?

Oh, and Jan-Piet, if you are reading, I believe the phrase you are about to type into the comments box is (allow me) - Yeah, it fails on that too!

Category: Notes
Technorati: IBM Lotus Domino

Comments :

1. Martijn de Jong21/09/2006 16:48:54

Chris,
I didn"t actually check it, but isn't it simply a matter of taking public write access away from the anonymous entry in the ACL. If my memory serves me right, you don't need it to use it for logging in.

2. Chris Linfoot21/09/2006 16:51:11

Yes, taking public write access away in the ACL prevents anonymous changes. But anonymous readers can still look and that makes me nervous.

3. Vince21/09/2006 17:13:47
Homepage: http://www.vincedimascio.com

I think you just have to give Anonymous no access but enable read/write for "public access". Then set your form to "available to public access users".

-Vince

4. Kendall21/09/2006 17:35:48

domcfg.ntf's [-Default-] entry doesn't have "Write public docs" checked. When adding Anonymous, did you set it to No Access and then set it to Reader? Notes has this annoying "feature" where upgrading access checks boxes you don't check, and downgrading unchecks boxes. Because of this, I've learned to carefully inspect all checkboxes in the ACL when changing entries. I almost never want what Notes changes on its own in the ACL dialog...sigh. (I'd love to lose this "feature"!) Anyway, my domcfg.nsf didn't have that box checked for either -Default- or Anonymous, but thanks for the heads up.

BTW, Anonymous is generally only needed to differentiate from -Default-. I rarely use Anonymous. There might be something weird in how the server uses domcfg.nsf that requires Anonymous; I haven't tested. But everywhere else, it's redundant if -Default- and Anonymous have identical access. If it is really needed for domcfg.nsf even if identical to -Default-, Lotus should add an [Anonymous] entry to the template and document it better.

Anyway, I'm not worried about someone reading such basic config info; security through obscurity is no security, and they can only see the names of forms they will eventually see anyway, right? But accessing domcfg.nsf with only Reader access shouldn't pull up that interface! Yuck.

5. Peter von Stöckel21/09/2006 20:14:38
Homepage: http://www.bananahome.com/

Actually, you would need to set Anonymous to Reader, without the Write Public Documents. If Anonymous has that checkbox checked, anyone could create documents in domcfg.nsf, with the login form (or any other form open for public access). This could potentially be a problem, since they could create new rules in domcfg.nsf if modifications where made to the forms. This would not be good.

My domcfg.nsf has Anonymous as Reader, and I am prompted to login when trying to access a form via web browser, that is, it is working as expected.

Regarding the thought of leaving out Anonymous from the ACL, because -Default- has the same rights really makes my spine itch. Anonymous should never have the same rights to a DB as -Default-. Even if there would be a case when Anonymous and -Default- would have the same access, you should have the entry there anyway, as a reminder that Anonymous and -Default- actually have the same rights.

6. Chris Linfoot21/09/2006 20:44:26

@4 "But accessing domcfg.nsf with only Reader access shouldn't pull up that interface! Yuck."

That's pretty much where I am with this too.

@5: I agree re anonymous/default.

Generally the problem appears to be twofold:

- the absence of [Anonymous] in the template ACL and
- why is there even a web UI to this database at all?

7. Peter21/09/2006 22:22:09

What happens if you click the "Don't Allow URL open" on the first tab of the Database Properties dialog box, in the "Web Access" section?

Wouldn't that solve the issue? Or am I misunderstanding the setting?

8. Michael Urspringer21/09/2006 22:31:57
Homepage: http://www.urspringer.de

Just curious if technote 1230037 is the solution for that? It's almost that what Vince already suggested:

The technote reads:
<...>
In order to change this behavior and make the domcfg.nsf database more secure, the customer should add an Anonymous entry to the ACL of the domcfg.nsf database.
The Anonymous entry should have an access level of "No Access" but the checkbox for "Read Public Documents" should be selected. If this checkbox is not selected, then anonymous users will be able to use the custom login form or any custom error pages which the customer has created in the domcfg.nsf database.

9. Kendall22/09/2006 07:16:16

I guess I don't see the need for a reminder in the ACL in the form of a redundant entry. If anything, that seems like a bad idea to me, since it seems to imply a difference that doesn't exist. But redundancy is one of my pet peeves....

Michael - thanks for the technote pointer. I wonder why Lotus didn't change the defaults after writing the technote.