|
|
This chapter discusses initial configuration of server settings for the Policy Database. In this chapter, you will find the following topics:
The Policy Database panel enables you to define the rules governing checkpoint events and to specify the maximum size allowed for the log file created by a Policy Database. In addition, you can export the Policy Database key from this panel on a primary server for use when installing GUI client software on remote administrative workstations.
The Policy Database is a proprietary knowledge store. It is an active object-oriented database derived from the frame technologies developed by the artificial intelligence community. The Policy Database acts as a central repository for configuration data, as well as for information that Policy Monitor Points record as part of the daily activity of a Policy Enforcement Point, including audit records and system integrity data.
The Policy Database is an event-driven system that provides call-backs and notifications to agents that register an interest in particular data and changes in state associated with that data in the Policy Database store. These notifications enable the agents to react to changes in the stored data. For example, when a new audit record is generated, agents of the Monitoring Subsystem that are interested in this kind of audit record are notified. These agents then examine the new data and update any associated state related to that audit record.
The Policy Database provides a common communication interface for agents within the security system. This common interface reduces the complexity of the security system and enables you to add new agents to the system without affecting existing agents. An agent only needs to be aware of what data it should register an interest in and what data it generates. It does not understand the specifics of communicating with other agents. Because the interface with the Policy Database is constant, agents only have to know how to interface with it.
When a Policy Database checkpoint event occurs, all information stored in the memory cache is written to data files on the hard drive. The log file tracks changes that you make to the system. Changes signify information, such as configuration settings and audit event records, that differ from those settings stored in the data files.
In the event that the host on which the Policy Database resides is shutdown prematurely, such as by a power failure, the Policy Database uses the log file to recreate the state of the system before it was shutdown. Checkpoint events reduce the amount of time required to recreate this "last known good" state, because they reduce the size of and number of changes in the log file. The smaller the difference between the in-memory data and the data files, the faster the host running the Policy Database can "recover" and resume normal activity, such as recording audit records and accepting changes to existing network policies.
However, checkpoint events consume much of the system resources and, therefore, reduce the number of audit records that can be recorded while a checkpoint is being performed. The Policy Database synchronizes its in-memory working data with the data stored in the on-disk data files when the specified amount of time elapses or when the log file tracking the changes made since the last checkpoint exceeds the maximum specified file size value---whichever occurs first.
A similar, but non-interactive, form of authentication is used for communications between a client agent and the Policy Database. The method by which a session between a client agent and the server (in this case, the Policy Database) is secured depends on whether that client agent is local or remote to the Policy Database server.
For local inter-agent communications, the Policy Database uses a nameless shared memory library. When a client requests a session from the server, the Policy Database authenticates the client. If the authentication succeeds, the server passes a handle to the memory location containing the information requested by the client. Otherwise, the session request is rejected.
For remote communications, the Policy Database uses a proprietary, secure wire protocol to provide bulk encryption of the channel between the client and the server. All traffic that passes between the Policy Database and remote client agents is encrypted using a private key symmetric algorithm provided by the Microsoft Crypto API. By encrypting the traffic, the Policy Database ensures that information cannot be analyzed by packet sniffers when agents are distributed among multiple computers. An example of a distributed agent is the GUI client when it is configured for remote administration. An example of a local agent is the GUI client when it is configured for local administration.
You can perform the following tasks from the Policy Database panel. For step-by-step procedures on performing a specific task, refer to the corresponding task topic.
You can specify a custom TCP port on which the Policy Database listens for requests from clients, such as the GUI client, update agent, and other Policy Databases (such as secondary servers in a distributed installation). This feature is useful if you already have a network service that listens on the default TCP port, which is TCP port 2567, used by the Policy Database.
To modify the TCP port for the Policy Database, you must modify the provided network service definition (the Cisco Policy Database definition under the Network Services branch of the Tools and Services tree) or define a custom network service. To make the Policy Database consistent with your new port setting, you must then select that network service in the Policy Database panel. This modification ensures that any security policies that you have applied that permit Policy Database network traffic will continue to operate correctly once you have modified the port value.
 |
Note By changing the Cisco Policy Database definition rather than defining a new network service, you can ensure that any applied security policies that enable Policy Database communications across a Policy Enforcement Point will be updated automatically. |
When you specify a network service that uses a TCP port value different from the value used by the network service that is currently associated with the Policy Database, you must restart the Cisco Controlled Host Component service before it will respond to requests on the new port. You can restart the Cisco Controlled Host Component service by stopping and starting that service in the Services dialog box in Windows NT Control Panel. After this service is restarted, the new port number is picked up automatically.
To modify the TCP port used to connect to the Policy Database, perform the following task:
Step 2 Right-click the Cisco Policy Database icon in the Navigator pane, and click Properties on the shortcut menu.
Result: The TCP panel appears in the View pane. You can make any changes directly in this panel.
Step 3 To change the TCP port value used by the Cisco Policy Database network service, type that new port number in the Port box under Instance Settings.
This port number identifies the TCP port that the Policy Database uses to communicate with other Cisco Secure Policy Manager components. By default, the Policy Database uses TCP port 2567, as assigned by IANA, to conduct these communications.
Step 4 To accept your changes and close the selected panel, click OK.
|
Note For the change to take effect, you must select Cisco Policy Database in the Associated Network Service box in the Policy Database panel. Then, you must restart the Cisco Controlled Host Component service. For more information on restarting the Cisco Controlled Host Component service, see Restarting the Policy Database. |
Step 5 To save any changes that you have made, click Save on the File menu.
You can specify the IP address that the Policy Database uses when listening for requests from other Cisco Secure Policy Manager components. This feature is useful if you are interested in separating Cisco Secure Policy Manager services across different IP addresses so you can monitor network sessions across Policy Enforcement Points between these services and the Policy Database. By assigning separate IP addresses, you can study network sessions with the Policy Database that occur across a Policy Enforcement Point and develop custom reports that summarize this activity.
To modify the IP address used to connect to the Policy Database, perform the following task:
Step 2 To view the Policy Database panel, point to Properties and click Policy Database on the shortcut menu.
Result: The Policy Database panel appears in the View pane.
Step 3 To change the IP address on which the Policy Database running on this host listens for requests from the GUI client workstations and other Cisco Secure Policy Manager components, click the new IP address in the IP Address list under General Settings.
The IP addresses listed are those IP addresses that are defined for the Primary or Secondary Server node that you selected. These addresses are defined in the IP Addresses box in the General panel of the selected server node. By default, the Policy Database uses the first IP address in the IP Addresses box.
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
From the Policy Database panel, you can specify the network service that is associated with the Policy Database. This network service identifies the TCP port on which the Policy Database communicates with other Cisco Secure Policy Manager components, including the GUI clients. When you specify a network service that uses a TCP port value different from the one used by the network service that is currently associated with the Policy Database, you must restart the Policy Database before it will respond to requests on the new port. For more information about restarting the Policy Database, see Restarting the Policy Database.
To select the network service definition used to connect to the Policy Database, perform the following task:
Step 2 To view the Policy Database panel, point to Properties and click Policy Database on the shortcut menu.
Result: The Policy Database panel appears in the View pane.
Step 3 To select the network service definition used by the Policy Database running on this host, click that network service in the Associated Network Service box.
This network service must be defined under the Network Services branch of the Tools and Services tree. By default, the Policy Database uses the Cisco Policy Database network service, which specifies TCP port 2567, as assigned by IANA, to conduct communications. If you change this port setting from the default value of 2567, you must restart the Cisco Controlled Host Component service for the change to take effect. For more information about restarting the Cisco Controlled Host Component service, see Restarting the Policy Database.
 |
Caution If you change the network service name from Cisco Policy Database, any security policies that you have applied that permit this service to pass through Policy Enforcement Points will need to be updated manually. |
|
Caution Stopping a Windows NT service can result in the loss of data and state. Therefore, any components or users who are requesting services at the time you stop a Windows NT service must reissue their requests after the service is restarted. |
Step 4 To accept your changes and close the selected panel, click OK.
Step 5 To save any changes that you have made, click Save on the File menu.
When you change the TCP port value by modifying the Cisco Policy Database network service definition, you must also restart the Policy Database by either rebooting the server on which it is running or stopping and restarting the Cisco Controlled Host Component service in the Services dialog box found in Windows NT Control Panel. In addition, you should close any GUI clients that may be accessing the Policy Database before you perform this task. This topic explains how to stop the Cisco Controlled Host Component service.
|
Caution Stopping a Windows NT service can result in the loss of data and state. Therefore, any components or users who are requesting services at the time you stop a Windows NT service must reissue their requests after the service is restarted. |
To restart Policy Database, perform the following task:
Step 2 To display the Services dialog box, double-click the Services icon in Control Panel.
Result: The Services dialog box appears.
Step 3 To select the Cisco Controlled Host Component service, scroll through the list of services and click the service named Cisco Controlled Host Component.
Step 4 To stop the Cisco Controlled Host Component service, click Stop.
Result: The Services dialog box displays a message prompting you for confirmation to stop the selected service.
Step 5 To confirm that you want to stop the service, click Yes.
Result: The Services dialog box appears while the service is stopped. This action causes all Cisco Secure Policy Manager processes to stop, including the Policy Database service (named fms.exe).
Step 6 To restart the Cisco Controlled Host Component service, click Start.
Result: The Service Control dialog box appears while the service is started. This action restarts all Cisco Secure Policy Manager processes, including the fms.exe service. After these processes are restarted, normal operation resumes.
Step 7 To close the Services dialog box, click Close on the File menu.
Step 8 To close Control Panel, click Close on the File menu.
To facilitate secure traffic between the Primary Policy Database and a remote host from which you intend to administer that Primary Policy Database, you must export a key from the Primary Policy Database and import it to the remote host. You can export this key to your local machine, to a network machine, or to a diskette, whichever is most conveniently accessed when you are setting up remote administration.
|
Caution We strongly recommend that you import this key to a diskette or some other medium that you can lock up securely. At the least, any network shares or hosts containing the key should be secured and have restricted access. Otherwise, the security of the Primary Policy Database, and hence your networks, could be compromised. |
Using the GUI client (remote/standalone or otherwise), you can administer more than one Primary Policy Database. To administer more than one Primary Policy Database, you must export the Policy Database key from each Primary Policy Database and import it in to the GUI client that you want to use.
Even though you can administer more than one Primary Policy Database from a single GUI client, only one person at a time, using the full access privilege, can administer each Primary Policy Database. However, no restrictions exist for how many administrators using the read-only privilege can connect to a Primary Policy Database.
To export a file key, perform the following task:
Step 2 To view the Policy Database panel, point to Properties, and then click Policy Database on the shortcut menu.
Result: The Policy Database panel appears in the View pane.
Step 3 To export the key, click Export Key under General Settings.
Result: The Export Key To dialog box appears, presenting a tree-based view of your Cisco Secure Policy Manager folder.
Step 4 To specify the location where you want to export the key file, select that destination in the Save in box.
You can create a new folder by clicking the Create New Folder icon, typing a name for the new folder, and pressing Enter.
Step 5 To specify the name for the key file, type that name in the File name box.
Step 6 To export the file to the specified location, click OK.
The new file is created at the specified location.
This topic explains how to schedule checkpoint events for the Policy Database. By defining a checkpoint rule, you are specifying how frequently the Policy Database should write the information stored in its memory cache to the database files on the server's hard drive. When you schedule a checkpoint event, you can also define the maximum size allowed for the log file before requiring a checkpoint.
To schedule checkpoints for the Policy Database, perform the following task:
Step 2 To view the Policy Database panel, point to Properties, and then click Policy Database on the shortcut menu.
Result: The Policy Database panel appears in the View pane.
Step 3 To select the time interval that you want to use to schedule checkpoints, specify either a time of day or how often (in hours).
You can specify this interval on the basis of either a daily time or an unbounded number of hours between each checkpoint.
Step 4 To specify the maximum size (in megabytes) that the working log file can reach before requiring a checkpoint, type the value in the Limit log file size to box.
The Policy Database synchronizes its working data with the data stored in the working log files when the specified amount of time elapses or when the log file tracking the changes made since the last checkpoint exceeds the specified value---whichever occurs first.
|
Note This log file contains entries about what changes were made to the working memory. The size of the file determines how long the system takes to recover in the event of a system crash. During recovery, the security system must replay the entire log before it can synchronize with the state of the system before the crash occurred. However, you should not make the maximum size of this file too small because system resources are consumed each time a checkpoint occurs. The optimal value for the maximum log file size depends on the speed of the hard drive, the type of processors, and the amount of physical memory installed in the server. |
Step 5 To accept your changes and close the selected panel, click OK.
Step 6 To save any changes that you have made, click Save on the File menu.
Posted: Tue May 30 08:28:12 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.