0blivion nº2:(LOTUS.txt):15/03/2000 << Back To 0blivion nº 2

<< Prev file: INTRO.txt

Next file: NEWS1.txt >>

_____________________________________________________ / Oblivion Underground Magazine \ / Issue 2 15/04/2000 \ ▌ Lotus Security ▌ \ by Slider / \_____________________________________________________/ - SOF - Lotus Security <slider> Fjear my 12mb virtual memory tekniq - The Domino Server The Lotus Domino server is a combination Notes server and Internet server, allowing Web browsers dynamic access to Notes applications. This offers to users the global access and rich media of an Internet environment combined with the wonderful data organization and application development features of Notes. This chapter takes a very brief look at how Domino works. More detailed information can be found in Working with Lotus Notes and the Internet, which is shipped with Domino. Information is also available at http://domino.lotus.com. The Lotus Domino server is a Notes server with the same functions and components as previous Notes servers. In addition, Domino provides an HTTP server component to enable Web clients to communicate with the server and a URL interface with extensions that allow the Web client use of the Notes database components. Notes database components such as views, documents, links, navigators, and buttons are dynamically translated to HTML for URL requests. Domino also has access to the kind of files that any normal Web server would use. For example you can imbed HTML within Notes documents to control document formatting and links. You can also make use of graphic and multimedia formats such as GIF, JPEG and any other format that your browser can handle. In addition to the programmability provided by Notes itself, the Domino server provides you with the normal programming interfaces for Web servers and browsers, such as CGI and Java. An experienced Notes administrator will find that supporting Domino is familiar because all of the functions are defined in the Notes Public Address Book server document. There are two changes to the server document for Domino. A new HTTP server section is added to define basic Domino information and the security section has new fields to determine the basic access of Web clients and to define Secure Sockets Layer (SSL). - A Typical Domino Site Designing and maintaining a Domino server can be as simple or as complex as you wish. A typical Domino site will have a home page that Web users will see when they request the server. What the user sees is determined by the value of the Home URL field in the server document. The default value, ?Open, will present the user with a list of databases on the server. You can change this to present a navigator or view by putting the URL for that object in the Home URL field. In turn, the properties for home.nsf have been set to launch a Welcome Page navigator. Now, imagine that a Web user enters the URL of the server without specifying a file name (for example, http://server.ip.address). The user will see the Welcome Page navigator, which includes a series of hypertext links to other URLs. Within Notes these links are really connections to other databases, views, or navigators. In fact, in the example the Welcome Page navigator has been designed in Notes using a background graphic with link hotspots . The link hotspots have been translated by Domino into HTML anchor tags, leading to other URLs. - How Domino Works Domino translates Notes application components for delivery to the Web client. HTML combined with Domino URLs are created to represent Notes objects to a Web browser. HTML can be coded directly into formulas or Notes functions can be used and translated by Domino. Navigators are translated to image maps and graphics are translated to GIF or JPEG files. When a Web client opens a Domino server by typing http://servername, the URL coded in the Notes server document Home URL field will be used to determine what to show the user. The default is the ?Open Domino URL. This will show a bulleted list of databases on the server. Each bullet is a hypertext link to a database. When a user selects the URL for a database with no additional launch specifications, Domino will show a bulleted list of the views in the database. Each bullet is a hypertext link to a view. Often, a database will be defined to launch a navigator or the About Database document. Forms, documents, and views are dynamically translated into HTML for display to the Web user. Formulas are calculated at the time the object is presented. Actions defined in Notes forms and views that are included in the Notes action bar are translated to HTML and included at the top of the Domino page. Form processing is a good example of where the different capabilities of a Web browser and a Notes client may lead to a change in application design. An HTML form is very simple in construction, comprising of a number of fields that the user can type in or select with the mouse. The fields include various input gadgets (radio buttons, selection lists, text areas, etc.) but the operating paradigm is that the form contains only two action buttons, a submit button that sends the filled-in form to the server for processing and an optional reset button that clears all entries. Notes allows multiple buttons on a form, each invoking a different action. The way that Domino handles this discrepancy is to ignore all except for the first button on the form, which is assumed to be the submit button. Any formula for this button is ignored but the user will see the text. If you do not have a button on a form, a submit button is automatically generated when Domino translates the form to HTML. If a button is on the form, Domino associates the submit action with that button. (When the user clicks the button the document is submitted (saved).) Attachments to Notes documents are supported. The graphic representing the attachment is translated to a GIF file. When the Web user clicks on the image a file attachment URL is created so the the document can be downloaded. If the attachment needs to launch a helper application in the browser the normal process applies, in which the browser maintains a mapping between file extension, MIME type and the action to perform. CGI scripts, Perl scripts, Java, Java Script, VBScript are all supported to allow the database designer to build programming into Notes applications. There are some extensions to the Notes design function that are specific to HTTP access. These are mainly special $$fields on forms. For example, the $$Return field on a form allows the designer to determine what actions or messages occur when a user submits a form. When the user submits the form, the contents of the $$Return field cause the user to be presented with a message stating that the question has been submitted. The user can click on the text Return to Question and Answer View to return to that view. - Domino URLs As a Web browser user, you navigate among forms, documents, views, navigators and databases on a Domino server using Domino URLs, either by entering them directly or by clicking on a link. Domino URLs have the form: http://server/database/NotesObject?Action&Arguments Links of this kind to Notes objects can be coded into Notes applications in many ways. They can be invoked by Notes commands, simple actions available when defining hotspots, actions, and agents, or by coding HTML statements directly into Notes forms. Domino then takes the links and translates them into Domino URLs. When Domino builds a URL to link to documents and views it constructs a hierarchy of references using the universal ID (also called UnID) of the document or view. For example, if you click on a database record in a view, the URL that Domino directs you to will have the following format: http://server/db.nsf/viewUnID/documentUnID?OpenDocument. - Domino Security I have shown how the Notes and Web environments are molded together by the Domino server. You have seen how the two different clients have a lot in common and how Domino performs a mapping between them. There are some areas where the hybrid environment places limitations on the application developer, but in general it is possible to take a Notes application and make it available to the great horde of Web browsers with minimal alteration. But the biggest gap that Domino has to bridge between the Notes and Web environments is in the area of security. In Notes, security is fundamental to every operation. It is not possible to do anything without first establishing your credentials. By contrast, security in the Web is almost an afterthought; something that is incidental to the basic operation of servers and browsers. Security is what this text is all about. In the following I go into the detail of Web and Notes security features and explore how Domino pulls them together. However, to round off this description of how Domino works, here I summarize the techniques it uses to map security functions: ╖ Authentication of Web users is done by using HTTP basic authentication, keeping the user name and password in the Notes Public Address Book. ╖ Domino also makes it possible to access a Notes server without first identifying yourself, something that has not been possible before. Web users not in the Public Address Book are considered to have the name Anonymous. The Anonymous user ID is used as a normal Notes Web ID and can be assigned to security roles, groups, and ACLs. ╖ SSL capabilities are supported for connections requiring confidentiality and server authentication. ╖ Access control facilities in databases are used for security. These facilities are the same as in traditional Notes development with a few exceptions. - World Wide Web Security Features The World Wide Web offers many security challenges compared to Notes. In part this is because of the nature of the application; it is a lightweight, stateless protocol that does not lend itself to strong authentication methods. However, the main reason why the Web gives security concerns is because of the network in which it usually operates, the Internet. The Internet is not a single network, but is comprised of a number of IP networks linked by backbone routers. This results in a network with widespread public access that has no central point of management control. - Web Security Facilities The application level communications protocol used by the World Wide Web is the Hypertext Transfer Protocol (HTTP). HTTP includes a simple user ID and password-based authentication scheme known as basic authentication. The implementation of basic authentication is server-specific, but in general they all use it for two purposes: ╖ As a mechanism to identify which user is accessing the server ╖ To limit users to accessing specific pages (identified as Universal Resource Locators, URLs) Basic authentication is an attempt to address two of our security objectives, access control and authentication. However, it does not address questions of confidentiality or data integrity. For these objectives a protocol that uses cryptographic techniques is needed. There are several protocols that seek to meet these needs, but only one is universally implemented, namely the Secure Sockets Layer (SSL). I describe the operation of basic authentication and SSL in the following sections. - HTTP Basic Authentication Basic authentication is based on user IDs and passwords, rather than public key cryptography as in the case of Notes authentication. You have to configure the server to identify which parts of the document tree are protected. These zones of protection are known as realms. Each realm is associated with a set of user IDs and passwords that are allowed access. Realms can contain any kind of server object, such as CGI programs, as well as HTML pages. The detailed mechanism by which realms are defined varies from one server type to another. In the case of the Domino server, the basic authentication realms are defined using normal Notes access controls. Basic authentication uses a challenge mechanism to prompt users to authenticate themselves. The diagram shows that when a client requests a URL, the server checks to see if the URL requires user authentication. If it does, the server rejects the request, with a status code of 401. The browser then pops up a dialog box on the users screen, asking for a user ID and password. When the user has provided them, the browser resends the original request, but with the addition of the following MIME element within the HTTP header: Authorization: Basic <userID and password block> The user ID and password block is constructed by creating a string of the form: userID:password and then encoding it using the base64 algorithm. You may wonder, given the above description, why you are not repeatedly prompted for a password every time you access a new restricted page. The reason is that the browser caches the user ID, password, server name, and realm name in memory, so that if it receives another 401 status code for the same server/realm combination it can reissue the request using the appropriate user ID and password. In fact, most browsers go one stage further than this and send a user ID and password for any URL that is likely to need it. The way this is implemented varies from one browser to another, for example: ╖ Netscape Navigator sends the information with any URL that is in the same logical directory. For example, imagine that the user requests http://hostX/secret/foo.html and is prompted for a password with realm name PRIVATE. Netscape Navigator will store the details in memory. Later, if the user clicks on a link to URL http://hostX/secret/bar.html, the browser will send the user ID and password for realm PRIVATE in the request, without waiting for a 401 challenge from the server. ╖ Lotus Notes Web Navigator uses a similar technique, except that it sends whichever user ID and password it most recently used for the target server. ╖ Microsoft Internet Explorer behaves in the same way as Netscape. The objective of these tricks is to reduce network traffic and improve responsiveness, by eliminating a number of invalid requests and 401 status responses. They also, unfortunately, have the side-effect of re-transmitting the user ID and password when it may not in fact be necessary. - Is Basic Authentication Secure? There are two obvious loopholes in HTTP basic authentication: ╖ The user ID and password are included in the packet header, which means that they can be captured by anyone with a network sniffer or trace tool at any place in the session path. ╖ The user ID and password are cached in the browser, so if you leave the machine unattended anyone can use your ID to access restricted information. The second loophole is no different from any other situation where a machine is left unattended. The solution is one of user education: always lock the screen when not at your desk. Note that the caching is in memory, so the user information is lost once the Web browser has been shut down. The first loophole is more significant. The user ID and password are not encrypted when they are placed in the packet header, but instead are encoded with base64. Base64 is an algorithm that forms part of the Multipurpose Internet Mail Extensions (MIME) protocol. It is a mechanism that turns any bit stream into printable ASCII characters. In fact, the objective of base64 is not for masking data at all, but to provide a method to send binary data through a mail gateway that can only handle character data. The result of this is that by capturing the Authorization: Basic header from an HTTP request, an attacker can easily extract the user ID and password. How serious is this exposure? Within a corporate network it may not be a big problem. In fact, base64 offers protection of user IDs and passwords that is superior to many older protocols that send them as clear text. In the Internet it is a different story. Here you have to assume that someone, somewhere is tracing everything you send. Clearly HTTP basic authentication should not be used as the sole method of protection for any critical resource. You can make basic authentication secure by providing an encrypted connection for it to operate in. SSL is a good example of a protocol that encapsulates HTTP data in this way. - Secure Sockets Layer (SSL) The SSL protocol was originally created by Netscape Inc., but now it is implemented in World Wide Web browsers and servers from many vendors. SSL makes use of a number of cryptographic techniques, such as public key and symmetric key encryption, digital signatures and public key certificates. - SSL has two main objectives: 1. To ensure confidentiality, by encrypting the data that a client and server send. 2. To provide authentication of the session partners, using RSA public key methods. Most current implementations only require the server to be authenticated in this way, although the protocol does allow for client authentication. Although SSL is normally used to provide secure encapsulation of HTTP, it can be applied to any TCP/IP application. A number of implementations for other protocols have been developed. There are two parts to SSL: ╖ The handshake, in which the session partners introduce themselves and negotiate session characteristics. ╖ The record protocol, in which the session data is exchanged in an encrypted form. - The SSL Handshake The two hello messages are used to exchange information about the capabilities of the client and server. This includes a list of ciphersuites, combinations of cryptographic algorithms and key sizes that the client and server will accept for the session. Also the server provides a public key certificate. This is the method by which SSL checks identity and authenticity of the session partner. In this example I only show the steps for server authentication, but if client authentication was required there would be another message exchange using the client public key. Finally the session partners separately generate an encryption key, the master key from which they derive the keys to use in the encrypted session that follows. You can see from this example that there is significant additional overhead in starting up an SSL session compared with a normal HTTP connection. The protocol avoids some of this overhead by allowing the client and server to retain session key information and to resume that session without negotiating and authenticating a second time. - The SSL Record Protocol Once the master key has been determined, the client and server can use it to encrypt application data. The SSL record protocol specifies a format for these messages. In general they include a message digest to ensure that they have not been altered and the whole message is encrypted using a symmetric cipher. Usually this uses the RC2 or RC4 algorithm, although DES, triple-DES and IDEA are also supported by the specification. The U.S. National Security Agency (NSA), a department of the United States federal government imposes restrictions on the size of the encryption key that may be used in software exported outside the U.S. These rules are currently under review, but the present effect is to limit the key to an effective size of 40 bits. The RC2 and RC4 algorithms achieve this by using a key in which all but 40 bits are set to a fixed value. International (export) versions of software products have this hobbled security built into them. SSL caters for mismatches between the export and nonexport versions in the negotiation phase of the handshake. For example, if a U.S. browser tries to connect with SSL to an export server, they will agree on export-strength encryption. - Using SSL in Practice The negotiation and authentication process of the SSL handshake is rather complex, but fortunately it is transparent to the user. In fact, all that a user has to do to enter an SSL connection is to alter the URL prefix from http: to https:. This acts as a trigger to the browser software to start the SSL handshake. Once the SSL connection has been established the browser gives the user a visual indication. In the case of Netscape Navigator this is a key symbol at the lower left of the screen. - SSL Session Indicator in Netscape From the point of view of the Webmaster, SSL is also quite simple. First the Webmaster needs to generate a key pair for the server, and obtain a certificate for it. Normally this involves providing documentation to a certifying authority and paying an annual fee, although it is also possible to generate your own certificates for testing and intranet use. Once the server certificate has been installed, the Webmaster can create HTML links with an https: prefix to cause SSL to be invoked. For example: <A HREF=https://my_server/secret.doc>Go into SSL</A> - SSL and Certifying Authorities A certificate links the description of the owner of a key pair to the public part of the key. The validity of a certificate is guaranteed by the fact that it is signed by some trusted third party, the certifying authority (CA). But how does a certifying authority become trusted? In the case of an SSL-capable browser, the certificates of trusted authorities are kept in a key database, sometimes called a key ring file. The list of top-level authorities is pre-installed when you get the browser. This approach has the benefit of being very simple to set up; a browser can authenticate any server that obtains a public key certificate from one of the CAs in the list, without any configuration or communication with the CA required. However, there are also some problems arising from this method. The first is that a new CA will not automatically be recognized until the browser (wherever it may be in the world) has been updated. The second problem is that there is no way for certificate revocations to be processed. (For example, if a CA determines that a public key owner is fraudulent after a certificate is issued, the certificate will remain useable until it expires, without the end user being aware of any concern.) The browser vendors have a two-part scheme to overcome the first problem (new CAs): 1. There is a special MIME format, application/x-x509-ca-cert, which allows a browser to receive a new CA certificate that has been signed by one of the known CAs. However, this method is not widely implemented yet. (See http://home.netscape.com/eng/security/downloadcert.html for details of download formats.) 2. The browsers will tell you that you are connecting to a secure server whose certificate is not from a known CA. You can then elect to trust just that server (that is not the CA that signed the serveró s certificate). This latter approach is useful in an intranet environment, where you may want to create an enterprise-only CA. For Internet applications you should purchase a certificate from one of the known CAs, such as VeriSign. - SSL Client Authentication In the release 4.5, Domino does not make use of SSL client authentication; instead it uses SSL to provide an encrypted channel through which HTTP basic authentication user IDs and passwords can be exchanged safely. However, this is a rapidly-developing area and I expect that support for SSL client authentication will be added to Domino R4.6. Therefore the way that client authentication works and the product developments that will support it. Both client and server use digital signatures to identify themselves and those signatures use public keys that are validated by the existence of a shared hierarchy of certificate authorities. You may think that SSL could apply a similar approach to allow Web browsers to authenticate themselves, simply by having the client implement a mirror image of the server authentication process. In fact, this is exactly what the SSL protocol specifies, by adding to the handshake a server challenge that the client must encrypt using its private key. Unfortunately life is not that simple. Notes can support a symmetrical authentication scheme because you have control over the CA hierarchy and therefore you can ensure a region of shared trust. On the Web you do not have that luxury. The monolithic certification scheme used by servers is not flexible enough to support the large number of certificates that client authentication would require. To enable this there are two problems to be solved: 1. How can you serve a certificate to a browser without too much overhead and without requiring the user to go through a complex registration process? 2. How can you make the process scalable, so that you are not dependent on a small number of top-level CAs? A consensus has emerged on how these questions will be answered although, at the time of writing, products to implement the answers are still under development. Serving Certificates to Browsers: A public key certificate provides proof of identity and it is a reasonable assumption that the level of proof needed for a client is much lower than that needed for a server. Before providing a server certificate, the CA will require documentary proof of the legitimacy of the request. In the client case, this proof can often be provided online, because a lower level of checking is needed. This is especially true of an intranet environment and certificate server products are initially intended for organizations that want to set up an internal authentication process. Netscape has developed a protocol for serving client certificates that is supported by current versions of Navigator. The key to the mechanism is the <KEYGEN> tag, an HTML extension that only applies within a form. When the browser sees this tag, it generates a key pair and returns a certificate request for the key pair with the form when it is submitted. Making a Scalable Certificate Authority Scheme: SSL authentication relies on the session partners recognizing the CA that signed a certificate as a trusted entity. As I described earlier there are limitations in the way that this is currently implemented. The challenge is to create a scheme in which CAs can exchange information with other CAs, clients and server systems. This information includes information about new CAs and revoked certificates. In fact this is not just a requirement for CA function, but a more general requirement for the exchange of all sorts of directory information. There is already an OSI standard for exchange of directory information, the Directory Access Protocol (DAP) which is part of the X.500 standard. However, DAP is exclusively for X.500 directory servers and it makes demands on hosts and networks that limit its applicability, for example: ╖ DAP requires a full OSI communications and authentication architecture. ╖ It uses the full X.500 data model, which is more complex than required by most applications and which carries a heavy penalty in code complexity. The net result of these demands is to prohibit the use of full X.500 DAP implementations on small desktop operating systems. To overcome this, a subset of DAP, the Lightweight Directory Access Protocol (LDAP) has been developed. LDAP is specified in RFC1777. LDAP operates over TCP/IP, discards the requirement for OSI security, and employs simple string-based data encoding. This means that LDAP will be accessible from systems of all kinds, including regular Web clients. Lotus has announced that support for LDAP will be incorporated in future Notes products, meaning that directory information from the name and address book can be shared. At that point it will be possible to integrate SSL client authentication with the existing authentication methods of Notes. - Security in the Domino Server The Domino server allows you to use a Web browser in place of a normal Notes client, by mapping between Notes document formats and HTML. As each environment has different security facilities you would not expect an exact match between them. - Access Control and Authentication There are two types of Domino Web users, registered users and unregistered users. A registered user has a person document in the Public Address Book with his/her name and HTTP password. Domino refers to this document and password to authenticate a Web user. An unregistered user is given the name Anonymous ACL in the same no password. To control the access of Web users, you may specify the Web username or Anonymous in an manner as you would for a Notes user. - How and When Authentication is Performed Authentication of Web users is done by a technique known as basic authentication. For example, when Web users try to open a database that has a default access of No Access, they are asked by the Domino server to supply a valid name and password. Authentication succeeds if the username and password supplied match the appropriate fields in the Person document. The user is recognized as a registered Web user. - Basic Authentication with Domino Web users are only authenticated when they attempt to do something for which access is restricted. In other words, if the attempt is not restricted, Web users are not required to supply the username nor password and are recognized as Anonymous, even if they are registered. If there is an entry for user Anonymous in the target databases ACL, it defines an unregistered users access level. If there is no entry for Anonymous, such users receive the default access. For example, assume that a Web user who is registered in the Public Address Book, tries to open a database where the default access is No Access and user Anonymous is assigned reader access. He or she can open the database, views, and browse documents without entering a username and password because as Anonymous he or she has reader access, which is enough to perform these operations. When he or she tries to create a new document Domino will ask him or her to supply the username and password because author access or higher is required to create new document. Note: After a username and password is entered the Web browser remembers the information and re-sends it automatically in response to Dominos requests. In effect the Web session holds the username and appropriate access throughout the session. After authentication is done, the useró s session holds the username as the CGI environment variable REMOTE_USER. Domino interprets the REMOTE_USER variable as a username within the Notes world, and Notes applications receive the interpreted username. For example, the @Username function receives the Web useró s name from REMOTE_USER. If the REMOTE_USER value is undefined (or null), in other words a username has not yet been entered, Domino gives the special name Anonymous to the user session and Notes applications recognize the user as Anonymous. - Defining Web Users You may register new Web users from scratch, or let existing Notes users have access to the Domino Web server. To register the user from scratch, follow these steps: 1. Create a new Person document. 2. Enter the required information. The User name and HTTP password fields are the only fields used for Domino Web user authentication. The other fields are optional with the exception of the Last name field. Even though this field is not used in Domino authentication the form wonó t be saved without it. 3. Save and close the document. To give an existing Notes user Web access: 1. Open the Person document of the target user in edit mode. 2. Put a password into the HTTP Password field. 3. Save and close the document. The password placed in the HTTP password field of the Person document is one-way encrypted (or hashed) before saving. Only the hashed form is stored, so you cannot extract a useró s password if it is forgotten, only replace it. - Web User Capabilities Web users manipulate Domino databases using a Domino URL. Domino does not support all operations available to a Notes client. For example, you can open a view or document the same as with Notes, but you cannot open a properties infobox. - Encryption and Signature SSL security does not have the capability to encrypt or sign individual parts of a document. It is an all-or-nothing approach, so if SSL is invoked, the whole of a document is encrypted, including any artwork or other media files that may be embedded. For this reason, the Notes capability of encrypting fields in a document does not work with Domino. Similarly there is no ability to digitally sign a section of a form or of a mail message. - Access Control Limitations Most security features available for pure Lotus Notes are also available for Domino. However, from the viewpoint of access control, there are several significant differences. - Server Access List Server access lists for Notes servers provide security, however, server access lists do not work on Domino for Web users. You can control access on each database, but existence of a database on a server cannot be hidden completely from users with access to the server. - Server Access List Doesnó t Work with Domino Domino servers can be protected from Anonymous user access by setting the field Allow Anonymous Notes connections to No. If this field is set to Yes, every user (including unregistered Anonymous users) can access the Domino server and touch all databases. By specifying the (known or guessed) filename of the database with ?OpenDatabase Domino URL, you can determine whether it exists as a database. For example, if the attempt http://domino.lotus.com/names.nsf?OpenDatabase is restricted to authorized users, the user is asked to enter a valid username and password by Domino. If the specified filename is not a valid database name, the user will receive an error message. In addition, a user may try to see the database list using /?Open. For example, you can browse the database list of the Domino official site by entering http://domino.lotus.com/?Open. You can have the database name not be shown in the list by using the database properties infobox. You can also inhibit database browsing by configuring the server document. - ACL of Directory Link Domino does not support ACLs in databases reached through directory links. Directory links do work in Domino so it is necessary to closely review databases accessed via directory links (.DIR files). Anything stored in this manner should be open to the public. - Confidentiality To implement confidentiality between a Domino server and a Web browser, you must use Secure Sockets Layer (SSL). Without SSL, all data packets are not encrypted and their content can be stolen. - Elements of SSL Using SSL, all transactions are encrypted by the sender with a symmetric encryption algorithm, such as RC4 or DES, and are decrypted by the receiver. Before communication starts, the symmetric key is transferred from one to another during a handshake phase, using a public key encryption algorithm, such as RSA. Both directions of communication are encrypted with SSL, but only the server is authenticated using digital signature techniques. This authentication relies on the server having a public key certificate signed by a certifying authority (CA) that the browser recognizes. - Invoking SSL on Domino To invoke SSL on a Domino server, you must: 1. Prepare a key ring, which contains a public/private key pair and certificates 2. Configure the server document to enable the SSL port There are several ways to obtain a key ring: ╖ Use an existing key ring. This is what I did, using a key ring that was provided to IBM for test purposes. However, in general it is not good practice to move private keys between different servers. ╖ Generate a key ring using the Domino SSL Administration database and: - Create self-certified certification (suitable for testing purposes). - Send a certificate request to a commercial CA, such as VeriSign. - Send a certificate request to an internal CA; Domino itself may act as an internal root CA if you configure it so. The Domino SSL Administration Database is shipped with the Domino server. You can perform management tasks through this database, such as creating a key pair and a certification request, sending a certification request to a CA or letting Domino certify it, and storing a certificate into a key ring file. - Installing a Key Ring File and a Password File I installed an existing key ring file on our Domino server. Our key ring contains a public/private key pair and a certificate. The key pair is for RSA cryptosystem (512-bit key length) and created by IBM for testing purposes. This key ring file has the extension .KYR. A key ring file is password protected, very similar to the password protection that the Notes user.id file has. However, in the case of a server it is often not acceptable to require a password to be entered each time the system is restarted, for example, after a power failure. The circumvention for this is to stash a masked copy of the password in another file for the server to use when it starts up. In the case of Domino, the password is stored in a file with a .STH extension, whose basename is the same as .KYR file. For example, the password of KEYFILE.KYR is stored in KEYFILE.STH. Note that this mechanism is different from other Web server software such as the IBM Internet Connection Secure Server. In my case I knew the password of our key ring file, but did not have the corresponding .STH file. I used a cheap trick to create .STH file. The procedure was as follows: 1. Determine the password and filename of the key ring. Our key ring file is named V1S512.KYR. The password file must be V1S512.STH. 2. Open the Domino SSL Administration database and select Create Key Ring -Self- Certification. Click on the Create self-certified key ring button. 3. Fill in the information required. The key ring password is essential. Enter the password for the real key ring (in our case, the password for V1S512). Click OK to proceed. This will create two files, DUMMY.KYR and DUMMY.STH, in the Notes data directory. 5. Now DUMMY.STH contains the password for V1S512.KYR key ring file. Rename DUMMY.STH to V1S512.STH and erase DUMMY.KYR. - Protecting the Domino Server If you run a Notes server inside an enterprise network you do not usually have to think too much about how it may come under attack. By contrast, a Domino server providing access to Web users over the Internet is in a very exposed position. In fact, it has to boldly go where no Notes server has gone before. It may not come under attack by Klingons, but it will come under attack. There are several aspects to consider when protecting a server in this situation: ╖ How to place it within a firewall so that it gets the best possible protection, but can still do its job. ╖ How to set up the Notes access controls so that the server only allows the access I want, and does not expose information about Notes objects that I want to hide. ╖ How to harden the underlying operating system, so that it does not offer a target to a would-be cracker. ╖ How best to set up logging and monitoring. - Controlling Access to Notes Resources The database ACL is the first and the most important defense. To protect your Domino server, you must design the ACLs of all databases very carefully. Remember, the server access list does not work in Domino, but you can inhibit Web users from browsing the database list with the /?Open Domino URL. This is not security in a strict sense, but it does discourage the probes of an attacker. - Prohibiting Anonymous Web User Access to Domino Servers You can prohibit anonymous Web user access to a Domino server. There is a field named Allow anonymous HTTP connections in the security section of the server document. When this field is set to Yes, Web users can access databases as Anonymous users. When this field is set to No, every Web user will be asked to supply the username and password when he/she connects to the Domino server. No matter what database or form they request, they must have a valid username and password in the Public Address Book on the Domino server to gain access. - Protecting Databases from Anonymous User Access To protect databases from unregistered (Anonymous) Web users, create an entry in each databaseó s ACL called Anonymous and grant it No Access. In a database ACL, Anonymous can be listed as an individual or as a member of groups or roles, the same as registered Web users. An entry named Anonymous in the ACL specifies the access level of unregistered Web users. If Anonymous isnó t listed in the ACL, Domino grants the unregistered Web user access based on the databaseó s default access level. You should place an Anonymous entry in all database ACLs on the Domino server. In a mixed Notes and Domino environment a database administrator may assume the Default entry is for representing a Notes user. Anonymous users should be more restricted than that. - Maximum Internet Browser Access The database ACL gives you the option to set an access level for Web users that will set an upper limit to Web access to the database, regardless of individual ACL settings. In the database ACL advanced panel, the field Maximum Internet Browser Access can be set to determine the maximum access allowed for the database from Web browsers. - Specifying Maximum Internet Browser Access in Database ACL Inhibiting Web Users from Browsing the Database List You can inhibit Web users from browsing the database list. You usually want to do this, because in general you want Web users to follow the dialogs that you have carefully constructed and not be able to link to databases directly. In the security section of the server document, there is a field named Allow HTTP clients to browse databases. When this field is set to Yes, Web users can browse the database list of the Domino server by using a Domino URL, such as : http://domino.server.hostname/?Open When this field is set to No, Web users cannot do that. - Logging and Auditing Logging is an important tool for detecting attempted attacks and retracing successful ones. Generally the base operating system provides some level of logging, such as the UNIX syslog function or the Windows NT system logs. Ideally you want to save the logs on some machine other than the exposed server itself. The reason for this is that if someone breaks into the system he or she may try to cover his or her tracks, by removing log records, etc. The replication capabilities of Notes give us a simple way to achieve this. In addition to system logs, the Domino server provides a number of other logging facilities, which I focus on here. Any HTTP request to the Domino server will cause log records to be written to access and error logs. These logs can be put in text files, a Notes database, or both. The logging fields in the server document HTTP section (Access Log and Error Log) direct the log entries to text files. The presence of domlog.nsf directs log entries to the database. Logging in Domino is very intensive. You should consider this when deciding to create a log database. For instance, entering http://servername?Open from a Web browser can create four entries in the domlog.nsf database. - Domino Log Database If you decide to send the log records to a database you must create the domlog.nsf database using domlog.ntf. The basic design of the log database provides one form for log records and one view to display them. There is also an agent that runs on a daily schedule that deletes documents older than ten days. You may want to modify this if you find ten days worth of information is too much or too little. To get the agent to work you must go in and change the agent daily schedule to run on your server. - Tailoring the Domino Log Database To make this database more useful to us I did some tailoring to the design. I created several views I found to be useful and added agents to automate events I wanted to be aware of. To allow easy monitoring of invalid login attempts I created a view showing only those records. To select the records I chose those that have a username filled in but a 401 status code. A record with a 401 status code and no name would indicate the initial attempt to access a protected object. The user would then have the opportunity to log in. If this is unsuccessful, the record with the users name and the 401 status code is built. The second column is for counting the login attempts. It has a value of one and is totaled for each user and for the entire column. - Adding Agents to the Domino Log Database Browsing log files is not a very exciting prospect, so it would be useful to have tools to extract interesting events from the file. One advantage of using the Domino Log database is that it allows the administrator to use Notes features to do this. Creating agents to check for specific events is a good way to audit what is going on in the Domino server. As a simple example, I created an agent that runs on an hourly basis on the Domino server. The agent will scan through the Domino Log database using the Incorrect Login Attempts view to check for a large number of unsuccessful login attempts. If the agent finds that a user has tried to log in unsuccessfully more than ten times, a note is sent to the Notes administrator. - Domino Log Text Files If you choose to have log records sent to text files you must fill in the Access Log and Error Log fields in the HTTP section of the server document. A new text file is created for each log every day. The files created will have the date appended to their name. If the server document HTTP section has a value filled in the Access Log field, three files will be created. The access log using the prefix specified in the Access Log field plus the date, the agent log named agent_log.date, and the referer log named referer_log.date. If the server document HTTP section has a value filled in the Error Log field, two files will be created. The error log using the prefix specified in the Error Log field plus the date and the CGI error log named cgi_error.date. Slider. - EOF - Big thanks to RJ, this guy helped me write this, it was all tested on his subnet and server installations. Also thanks to phreakazoid, you know why. This was written with help from those ickle tablets with E's on them, and thoose big fuck off caffine tablets.