CometAnywhere Security

From CometWiki

Revision as of 13:42, 23 May 2009 by Badge (Talk | contribs)
Jump to: navigation, search

Comet Machine-Specific Security

Overview

Most Comet users are familiar with the "ENTER PASSWORD" prompt they see when they launch Comet each day. This prompt is displayed by the secured version of QMONITOR. For many years, QMONITOR was the first program to be run when a Comet system was started. However, that is no longer true.

Today when you launch Comet98 and Comet2000, CMONITOR is the first program to be run in all foreground partitions. This program (and related utilities) can be used to add two extra layers of security to a Comet system.

This extra security can be particularly valuable for CometAnywhere host systems. For example, suppose a system manager wants to allow certain remote users to access the Comet system while restricting others. Or suppose that the manager wants to prevent a former employee from accessing a host Comet system from a remote location. These situations can be handled with Comet's machine-specific security scheme.

Here's how this works. The Comet and CometAnywhere startup program (COSW) generates a unique value for each computer where the program is run[1]. This is called the "session identification number" (aka "session ID"). The manager of the Comet system can create a list of authorized session ID's on the host system, and use this list to control access to the Comet system.

There are two layers to this security scheme. They are called the "inner door" and "outer door." Briefly,

The "inner door" validates a remote user's session ID against a list of values stored in a "security file" that's stored on the host system[2]

The "outer door" validates a remote user's session ID against a list of values stored in the Comet system's "session table"[3]

You can use the "inner door" scheme by itself, or can combine the "inner door" and "outer door" schemes for greater security. We will explain the "inner door" first, and then describe how to use both schemes simultaneously.

The "inner door" is implemented in CMONITOR. This program compares a user's session ID with values stored in the security file, granting access only to those users whose ID's are contained in the file. (If you have not implemented this security scheme, CMONITOR simply runs the QMONITOR.)

The IDMAINT utility program (number 41 on the Comet Utility Programs menu) provides the mechanism for creating the security file and adding/deleting session ID numbers.

The second layer of security, called the "outer door," is an optional layer that places the ID's of all authorized users in the session table of the host Comet system. Comet compares a user's session ID with the values stored in the session table, granting access only to those users whose ID's are contained in the table. Note that this step occurs before CMONITOR is run.

To review:

The inner door validates the user's session ID against the security file.

The outer door validates the user's session ID against the session table.

It's worth noting that both of these steps occur before the user sees the "ENTER PASSWORD" prompt of QMONITOR.

The outer door/inner door scheme may seem redundant, but it has some big advantages. One of them is a feature we haven't described yet, and that's the ability to ban a remote user from accessing the host Comet system. The system manager can delete an authorized user from the security file and place their session ID on a list of excluded users in the session table. If an excluded user tries to access the host system via CometAnywhere, he or she is rejected at the outer door. This is an excellent way to prevent a former employee, for example, from accessing a host Comet system from a remote location.

Here is a summary of the programs and files that are part of the machine-specific security system. Detailed instructions on how to use these programs are contained in the next section of this document.

· CMONITOR, the "inner door" of this security scheme, runs in each foreground partition when Comet is started. If the machine-specific security scheme has been implemented, CMONITOR validates the user's ID and runs QMONITOR. If the user's ID is not contained in the security file, the user is not allowed to access the host system. If the security scheme has not been implemented, CMONITOR simply runs QMONITOR.

· The "outer door" refers to the outermost level of security for a Comet system. The session table on the host system contains a list of authorized session ID's and may also contain a list of excluded users.

· IDMAINT is a utility program that implements the security scheme. When you run this program for the first time, it creates a security file named IDFILE (you specify the directory) that contains the list of authorized users and (optionally) the excluded users. This program includes the option to close the outer door, and contains additional features that are described below.

How to Implement the Machine-Specific Security System

The following instructions explain how to implement the machine-specific security scheme.

  • 1. Make sure you have the latest version of Comet98 or Comet2000, the REL directory, and the UTL directory.
  • 2. Run the IDMAINT utility from the READY prompt or from the Comet Utility Programs menu.
  • 3. Since this is the first time you are running this program, it will prompt you for a directory name where it will create the security file (IDFILE). We recommend using the COS directory.
  • 4. The main screen in IDMAINT is now displayed. Choose the "Admin (S)ettings" option by typing "S" and pressing Enter.
  • 5. Answer the administrative settings prompts as follows:

Enable Build Mode? Y

Secure Remote Users Only? N

Backdoor Getin Password (leave blank)

Welcome message at start-up? Y

Here's an explanation:

· The "build mode" setting is active only when the outer door is open (i.e., not in effect). When build mode is enabled, all users attempting to access the Comet host system are allowed in. The CMONITOR program asks each user to type their name, which (along with their session ID) is written to the security file. This is the least secure setting in this overall scheme (after all, the outer door is open and the inner door lets anyone access the host system), but it can be an easy way to establish new users and their session ID's. For the first user (you), it's obviously the quickest way to add your record to the security file.

· The machine-specific security scheme can be used to secure all users who attempt to access the host (including the local user), or can be used for just the remote CometAnywhere users. The "Secure Remote Users Only?" prompt lets you choose which setting you want. For now, you will be securing the local system, so answer "N" to this prompt.

· The "backdoor getin password" is in effect only when the outer door is open. For now, leave this field blank. We'll explain it below.

· The CMONITOR program optionally displays a welcome message (on the control line) when you start Comet. If you want to display this message, type "Y" at the fourth prompt, otherwise type "N". (Note that the security QMONITOR displays a message on the control line, which overwrites this welcome message. Therefore, this option is meaningful only for non-security QMONITOR systems.)

  • 6. At the "Correct?" prompt, type "Y" and press Enter.
  • 7. At the main screen menu, press Enter without typing anything. The program displays information about the status of the outer door. At the "Close outer door?" prompt, type "N" and press Enter.

(At this point, you haven't established any authorized users, so it wouldn't make sense to close the outer door. Besides, with no authorized users, the IDMAINT program does not close the outer door.)

  • 8. Here's what happens next. Upon exiting, the IDMAINT program runs the CMONITOR program, which displays the following prompt: 
Welcome to the Comet Authorization Registration
.
Enter Your Name:
.
Correct?

Remember that the outer door is open and the inner door is closed, but build mode is enabled. Translation: any user who accesses the host system is allowed to enter.

Type your name, then answer "Y" to the "Correct?" prompt.

  • 9. CMONITOR writes your name and session ID number to the security file, and then runs QMONITOR.
  • 10. At this point, you have established the local computer as an authorized user. If you leave the settings as they are at this point, the next time you start Comet you will not be asked to type your name. That's because CMONITOR compares your session ID number to the security file. Since it finds a match in the file, you are granted access to the system.
  • 11. Let's take a look at the information that has been stored in the security file. Run IDMAINT again. This time, the main screen shows that the local computer is included as an authorized user. The following information is displayed: 
·        Your name
.
·        Your session ID number
.
·        The date you became an authorized user
.
·        The location of your system. Since you are the local user, this field says "Local." When you use this security scheme to validate CometAnywhere remote users, those entries will say "Remote."
  • 12. Press Enter at the main menu. At the "Close outer door?" prompt, type "Y" and press Enter.
  • 13. The program displays the outer door status, including the fact that there is one authorized user (you) and no excluded users. The next time you start Comet, you will pass through two security levels: the outer door (session table) and the inner door (security file).
  • 14. So far, you have authorized the local system only. Now it's time to authorize a CometAnywhere remote user. There are several ways to do this.

First things first, though. The only way to authorize a remote user is to open the outer door. Do this by running IDMAINT, pressing Enter at the main menu, and answering "N" to the "Close outer door?" prompt.

  • 15. Here's where things stand now. The outer door is open, the inner door is closed (as long as the security file exists, the inner door is closed), and build mode is enabled. That means that a remote CometAnywhere user can access the host system (assuming that all of the correct licensing and configuration requirements have been met).
  • 16. When a remote user accesses the host system, they will see the same prompt you did in step 8. When they respond, their name and session ID number is added to the security file. You can verify this by running IDMAINT and looking at the information on the main screen.
  • 17. You can continue to register remote CometAnywhere users in this way, but remember that with build mode enabled and the outer door open, any remote user with CometAnywhere software and knowledge of your host's IP address or domain name can access your host system.
  • 18. Here's another, and more secure, option for registering remote users. First, use IDMAINT to disable build mode (use the Admin Settings and type "N" at the first prompt).
  • 19. At the main menu in IDMAINT, choose the "(O)ne Time Passwords" option (type "O" and press Enter).
  • 20. Next, choose the "(A)dd password" option (type "A" and press Enter).
  • 21. Type the remote user's name and a one-time password they will use to access the host system. This information is stored in the security file.

Note: If you are creating passwords for more than one remote user, assign a unique password to each user. That way, you'll be able to periodically check who has not gotten on the system yet. You'll also know when the last user has gotten on to the system, which will mean it's OK for you to close the outer door. In addition, you'll have control over what is entered for the user's name.

  • 22. Inform the remote user of their password. When they try to access the Comet host system, CMONITOR displays the following message and prompt:

You have not been authorized to sign-on to this system.

In order to do so you must enter an ACTIVATION password.

Please enter your ACTIVATION password

  • 23. Here's what happens when the remote user enters their password: 
·        The one-time password is validated against the security file.
.
·        The one-time password is then erased from the security file.
.
·        The remote user's name and session ID are added to the security file.
  • 23. Using one-time passwords to register remote users is more secure than using build mode, because the remote user must know something to access the host system. It's not available for just any remote user. Therefore, we recommend this procedure.

The footnote to this recommendation is a reminder that the outer door must be open for one-time password registration to work. For tighter security, the system manager could assign a one-time password, open the outer door long enough for the new remote user to register, and then close the outer door again. Obviously, this takes coordination between the remote user and the manager of the host system, but it's worth the effort for the extra security of having the outer door closed during routine operation of the host system.

  • 24. There's another way to register a remote user. It's known as a "backdoor password," and we recommend careful consideration before using this feature. Here's how it works.

In IDMAINT, the admin settings screen contains a prompt that reads "Backdoor Getin Password." If you leave this field blank, the feature is disabled. If you enter a password in this field, it functions at the same security level as a one-time password. The difference is that a backdoor password is not erased when the remote user is registered.

The positive side of this feature is that a remote CometAnywhere user will always have a way to register with a Comet host system (assuming, of course, that the outer door remains open and that they know the backdoor password).

The negative side is that any remote user, including ones that are not welcomed, could guess the backdoor password and gain access to your host system. For this reason, you should be very careful when choosing this option.

  • 25. At some point, it may be necessary to delete an authorized user's record from this security scheme. Do this by using the "(D)elete user" option at the main menu in IDMAINT (type "D" and press Enter).

The program displays the following prompt: 

           Enter Line# to Delete:

Type the line number corresponding to the user's ID, and press Enter. You are asked to confirm your action.

Note: Deleting a user's ID simply removes their record from the security file. To remove their entry from the session table as well, you must use IDMAINT to update the session table and close the outer door again.

  • 26. After you have confirmed your action to delete a user's ID, the following prompt is displayed: 
Add to Exclude List?

If you answer "Y" to this question, the deleted user's ID will be added to the list of excluded users. Remember that the enforcement of this list is done at the outer door, which guarantees that excluded users won't even get to the CMONITOR program.

If you answer "N" to this question, the user's ID is not added to the list of excluded users.

  • 27. Here's information about some of the other options in the IDMAINT program.

· From the main menu, you can view the list of excluded users by choosing the "e(X)cluded users" option (type "X" and press Enter). Once the list of excluded users is displayed, you can return to the main menu (and list of authorized users) either typing "A" and pressing Enter, or by pressing Enter without typing anything. Or, you can delete an excluded user by using the "(D)elete user" option.

· At the "(O)ne Time Password" screen, you can either add a new one-time password, or delete a one-time password you no longer want.

· The program includes validation for all add/delete/change options.

· When you exit from the program (by pressing Enter at the main menu), the program opens the outer door and gives you the option of closing the outer door again. If you close the outer door, the program updates the session table and displays a status message showing the number of authorized users and number of excluded users.

A Review of Security Levels

This section is presented as a review of the various security levels available for a Comet system. While some of this material may seem redundant, it's included here as a way to help system managers choose the appropriate security level for their system(s).

Comet systems enjoy a certain level of security based on the design of Comet itself. For example, without a copy of the COSW program, no remote user can gain access to a CometAnywhere host, since the packets are encrypted and the protocol is specific to CometAnywhere. The security scheme described in this document extends this built-in security to the machine-specific level.

The least secure Comet system is one with a non-security QMONITOR and no inner door/outer door scheme. If such a system is also a CometAnywhere host, virtually any remote CometAnywhere user can access this system without a password or without providing any logon identification. We certainly hope that no one is running a system like this!

From this point on in the discussion, we'll assume that you're running a security version of QMONITOR. Doing so means that a remote user must know a password in order to access your host system. However, the system is still vulnerable to someone who can guess one of your passwords.

Comet's machine-specific security system offers two extra layers of security. Since there are several ways to configure these layers, we'll review the least secure first. When build mode is enabled (with the outer door open), any remote user can access the host system simply by typing a name. This method doesn't validate the user's identification, but it does store their session ID number in the security file. If the system manager later determines that this user should not have access, their ID can be deleted from the security file. (Of course, the same remote user could logon again, so this method doesn't really offer a great deal of security.)

If build mode is disabled, a remote user who wants to access the host system must be assigned a one-time password. This password covers their initial entry into the system. For subsequent entries, their session ID is validated against the security file. This method offers one layer of machine-specific security.

You can also create a backdoor password that works like a one-time password. In other words, a remote user who knows the backdoor password can access the host system (initially using the password, and subsequently having their session ID validated against the security file). As we mentioned above, this method leaves a gap in an otherwise tight security scheme, so we recommend prudence here.

A superior scheme is to use the outer door in combination with the inner door and security QMONITOR. The outer door consists of two lists that are stored in the Comet session table. The first list contains the session ID numbers of all of the excluded users. Comet compares this list with the session ID of a remote user attempting to access the host system. If the ID's match, Comet rejects the remote user at the outer door.

The second list contains the session ID numbers of all the authorized users. When a remote user tries to access the host system, Comet compares its session table with the session ID reported by CometAnywhere. In this case, if the ID's match, the user proceeds through the outer door to the inner door.

The outer door must be open to register new users (i.e., build mode enabled, one-time passwords, and backdoor password). Therefore, the manager of the host system has to coordinate with remote users in order to plan time when the outer door is open. Once the remote users are registered, the manager can close the outer door and rely on two layers of machine-specific security.

Network Considerations

If you are running the machine-specific security scheme on a network, here are some things to note.

· First, we recommend creating the security file on a server-based directory that is accessed by all Comet nodes (for example, the COS directory). That way, the inner door will apply to all nodes, and all session ID numbers (local and remote) will be validated against a single copy of the security file.

· To implement the outer door, you must run IDMAINT on each node where you want it to be in effect. That's because the outer door works by writing information to the session table of each Comet system.

You can close the outer door on one node, while not closing it on the others. For example, suppose your network includes one node that is a CometAnywhere host (the other nodes are local Comet nodes). If you close the outer door on the CometAnywhere host system only, you'll be securing that machine via entries in its session table and validation against the security file (i.e., outer and inner doors). The dual-level security will apply to that node only. The other nodes will be secured via the inner door scheme only.

· If you exit from Comet on a node where the outer door has been closed, when you restart Comet on that node the outer door will still be closed.

· The IDMAINT program includes the following prompt on the "admin settings" screen: 

Secure Remote Users Only?

If you answer "Y" to this prompt, the security scheme will validate remote CometAnywhere users only.

If you answer "N" to this prompt, the security scheme will validate both remote CometAnywhere uses and local Comet nodes.

Behind the Scenes

For more information about the session table, see the SESTAB demo program in the DMW directory (available at the download area at Signature.Net). This program contains the following options: 

           List items
.
           Get item
.
           Set item
.
           Delete item
.
           Enable/Disable table
.
           Inquire Session ID
.
           Set Security Level

The above options refer to the two lists, where "I" is the "include list" (the list of authorized users) and "E" is the "exclude list."

The source code for SESTAB is included in the DWM directory.

Publication date: September 6, 2000

Updated on November 30, 2000

[1] COSW uses a Windows function to generate this value. Microsoft guarantees that this value is unique.

[2] The "security file" is a keyed file named IDFILE. This file is created and maintained by the IDMAINT utility program.

[3] The "session table" is a system-level table of values associated with the host system.

Retrieved from "http://wiki.signature.net/index.php/CometAnywhere_Security"
Personal tools