CSA Rules

 < Day Day Up > 

Rules are the smallest enforcement component in relation to the enforcement hierarchy. There are several rule types available that enable you to limit, monitor, and control interaction on agent-protected systems. Rules can deny or allow interaction with the local agent user interface, allow or prevent network access, and control file usage. To better understand rule definition, you first need to grasp several concepts shared across the many rule types, such as user and system states. The next sections cover those shared concepts.

Understanding State Sets

State sets are a new concept introduced in the CSA 4.5 release. This feature enables you to define rules that can be distributed to the remote agents as part of normal polling that will remain inactive until the state set matching criteria is satisfied. There are two types of state sets:

  • User state

  • System state

The application of either (or both) types of sets enables you to define policies that become enabled based on the user logged in to the local system and the location of the computer at that moment in time.

User State Sets

User state sets provide a mechanism to enforce varying policies based on the user logged in to the system. You can enforce rule modules based on the username and group information cached upon logging in to the system. This is an excellent way to provide the common user a specific set of system control and network access while logged on and maintaining the ability to grant greater access to administrative or technical support personnel. For example, you might have policies in place that prevent the local user from stopping the Security Agent Windows Service unless the user logged in to the system is in the Administrators group. Although this condition-based method of applying rules can prove extremely useful, you should apply this method only when absolutely necessary because it increases the size of the policy transmitted to and from all protected systems and increases the processing required on the endpoint to verify the state condition.

NOTE

In previous versions of the CSA product, to accomplish a rule change on a remote system, you need to centrally change the host s policy and force a poll for the new rule to propagate, allowing the temporary access required for troubleshooting. With user state sets in version 4.5, it is now much easier to perform support tasks without a several-step well-timed process.


User state sets are configured centrally on the CSA Management Console (MC) and applied to rules as needed. To configure and view various user state sets, choose Configuration > User State Sets. Several predefined user state sets are included with the CSA installation that might already suit your requirements, as shown in Figure 4-1.

Figure 4-1. Predefined User State Sets


NOTE

When defining user state sets, you can use security identifiers (SIDs) for Windows groups to match groups regardless of how they are spelled in different languages.


The following list describes a few of the predefined user state sets:

  • Administrators This set shows users in the Administrators group defined using the SID S-1-5-32-544 rather than the group name (for accuracy when using multiple languages, from an operating system perspective).

  • Anonymous Login (Null Session) This set contains null sessions by corresponding SID.

  • Dialup This set shows all users who have logged in to the system via a dialup connection.

  • Root This set lists UNIX root users.

  • Service This set shows entities that have logged on as a service by SID.

Many other predefined user state sets such as Backup Operators, Everyone, Guest, and nonroot may also prove helpful in your environment.

To define a new user state set, click New at the bottom of the listing page. This opens the Configuration window. Defining the user state set requires some simple configuration, as follows:

  • Name and Description Name and describe the set as appropriate.

  • Configuration You need to set a few configurable parameters to ensure a unique state is defined:

    • Users Matching Enter the usernames that are part of this set; otherwise, by default, all users are entered. You can use the But Not field to exclude certain users from the set by username; otherwise, by default, none are excluded.

    • Groups Matching Enter the group name or names that will match this set definition; otherwise, the default is all. You can use the But Not field to exclude certain groups listed here from the set definition; otherwise, by default, none are excluded.

  • References Link If any rules use this set, you can directly access the specific rules by clicking this link.

  • Save and Delete Use the Save or Delete buttons to commit or delete any changes to this set whether old or new.

As an example configuration of a user state set, Figure 4-2 illustrates the configuration necessary to create a set that will match users who are part of the Windows Contractor group. This configuration is useful for an organization that provides contracted staff members user accounts and use of corporate resources but wants to limit access based on security agent policy.

Figure 4-2. Defining a Contractor User State Set


NOTE

The use of wildcards (*) is allowed in the User fields but not in the Group fields.


System State Sets

System state sets provide a mechanism to enforce varying levels of policy at the rule module level according to the current system state. System state parameters include information such as the following:

  • Network Admission Control (NAC) posture

  • System security level

  • IP address or subnet

  • DNS suffix

  • Whether the system is currently booting

  • Whether an installation of software is currently underway

  • Whether the CSA MC server is reachable

  • Whether a rootkit currently is detected

  • Whether a virus has been detected

You can set these various factors singly or in combination to provide granular system state definitions. It is most common to set the required matching of at least two parameters to limit the ability of the end system to "spoof" a parameter such as the IP address to manipulate the local rule base.

Several system state sets are predefined on the CSA MC server, as shown in Figure 4-3. To access these system state sets or create a new one, choose Configuration > Rule Modules > System State Sets to open the listing page.

Figure 4-3. Predefined System State Sets


Some of the more useful predefined system state sets are as follows:

  • Cisco Trust Agent Infected Posture This set only uses the Trust Agent Posture parameter as matching criteria. If the NAC posture returned to the CTA is infected, you can apply specific rule modules to the agent.

  • Management Center Reachable This state set matches when the CSA MC server is reachable from the agent system. This typically only happens when the agent is connected directly to the corporate network through a LAN or remote-access connection.

  • Security Level Low This set matches when the slider bar on the remote agent UI is set to Low.

  • System Booting When the system is booting, you can specify interaction allowed.

  • Virus Detected If a virus has been detected by the local supported antivirus product, you can apply a more restrictive rule module.

The predefined system state sets are very simple, but extremely useful. To create your own customized system state set, some configuration is necessary. To create a new set, click New at the bottom of the listing page, and then configure the following set parameters:

  • Name and Description Enter a name and description that will be useful to all administrators.

  • Network Admission Control Use the Cisco Trust Agent Posture option within this parameter to choose the posture you want to match. The posture token is returned to the CTA and then in turn to the CSA as part of the NAC process. Options here are Don t Care, Healthy, Checkup, Quarantine, Infected, Unknown, or Other. Don t Care matches any or no token. To choose multiple postures, use Ctrl-mouse click.

  • System Security Use the Security Level option within this parameter to match the slider bar security level chosen on the remote agent in the GUI. Note that the default setting on the agent system is Medium. To choose multiple criteria, use Ctrl-mouse click. The slider bar functionality provided to agent-protected systems is user selectable and therefore typically changes as a result of end-user interaction and modification rather than a location-based parameter.

  • System Location The configuration options here relate to the IP address-based location detected by the agent relating the local system connectivity:

    • Network Address Range Enter literal values or apply network address sets (variable) to match the current IP address of the system.

    • DNS Suffix Matching Specify a DNS suffix the system may use at any given time, such as CSA.com versus serviceprovider.net. Use the But Not field to enter DNS suffixes that should be excluded from this set.

  • Additional State Conditions Click Add State to add additional parameters that should be matched as part of the system state. All of the following parameters have the options Don t Care, Yes, and No:

    • System Booting This setting matches if the local system is undergoing the boot process or is not booting depending on the criteria chosen.

    • Installation Process Detected You can use the system state set to apply a more- or less-restrictive policy during an installation on the local system.

    • Management Center Reachable If the CSA MC server is reachable by the agent, you can apply a different set of rules than if it is not reachable. This is an excellent parameter to match in concert with other parameters to determine whether the user is located on a corporate network, VPN connection, or possibly off-site.

    • Rootkit Detected If the system detects a rootkit, you can apply different rules to the agent.

    • Virus Detected If the local supported antivirus package has reported a virus on the system, you might want to provide a more strict policy until the virus has been cleaned and is no longer detected as present on the system.

  • References If this system state set has been used, the references are listed.

  • Save and Delete These buttons either commit the changes or delete the system state set.

To illustrate system state set creation, the following steps build a state condition that matches a system that is connected to the network via a Cisco VPN 3030 concentrator. Follow the steps to complete the task and view Figure 4-4 for the completed state:

Step 1.

Enter the name VPN Connected and add an appropriate description.

Step 2.

Do not change NAC or System Security parameters because they do not impact this state set.

Step 3.

Enter 10.99.99.0-10.99.99.255 as the network address range. This is the range of IP addresses served by the DHCP server only to VPN clients.

Step 4.

Enter csa.com as the DNS suffix for matching and leave the But Not field set to None.

Step 5.

Click Add State.

Step 6.

In the drop-down box, choose Management Center Reachable and Yes as the criteria.

Step 7.

Click Save and verify the configuration.

Figure 4-4. Sample System State Set Creation


You have just created a system state set that should only match your VPN users. You have guaranteed this by requiring the IP address range must be from the VPN pool, the DNS name must be the same as assigned by the VPN DHCP pool, and the CSA MC must be reachable. The CSA MC reachable criteria means you are somehow connected to the net-work, and because of the IP address specified, you can guarantee that you are connected via VPN because the CSA MC return traffic is working. If the IP address is manually changed but the system is elsewhere, routing issues will make the CSA MC unreachable. The system state could now be applied to a rule module that may grant or restrict certain access because of your location in the network.

NOTE

Many of the parameters used in system state sets can be spoofed, but the combination of certain criteria can help validate the overall system state and ensure the system state is accurate.


State Set Management

State set management is performed via the listing pages. On the listing page for either system or user state sets, the following management buttons display at the bottom of the screen:

  • New Create a new state set.

  • Delete Check the appropriate check boxes before the items in the list to delete one or more state sets simultaneously.

  • Clone To make a copy of a state set for modification, check the check box of the item you want to clone and click the Clone button.

  • Compare To compare multiple state sets to one another, check the appropriate check boxes and click the Compare button. You can only choose two items to compare at a time. The comparison is returned in the browser, as shown in Figure 4-5, with differences highlighted in red.

    Figure 4-5. Comparing Two System State Sets


Understanding Rule Actions

When defining various types of rules, you need to provide the type of action the rule will enforce if the defined rule matches the requested interaction.

Deny actions include the following:

  • High Priority Terminate Process Denies the action or resource request and attempts to terminate the process making the request. Termination of certain system processes could make the operating system unstable. To attempt to prevent an unstable system condition, CSA tries to specifically identify a particular thread and terminate it rather than the entire process when the process to be terminated is a process that would cause a system reboot or other abnormal and undesirable behavior.

  • Terminate Process Performs the same action as high priority terminate process but with a lower priority. Rule precedence is covered later in this chapter in the section "Rule Precedence and Manipulation."

  • High Priority Deny Denies the resource requested and does not terminate the process requesting the resource.

  • Deny Performs the same action as high priority deny with a lower precedence in rule ordering.

Allow actions include the following:

  • Allow Choose this option to allow access to the requested resource.

  • Default Action (Allow) The CSA differs from many security products because it allows all interaction on a system by default and only prevents actions that are specifically defined. Choose this option if you needed to allow an action that may be denied in a conflicting rule set that gets merged on a protected host system. Remember, CSA typically denies or limits interaction for a specified policy while allowing all other undefined interaction.

Query actions include the following:

  • Query User Default Terminate Asks the user whether the resource request is appropriate with a default action of terminate. If the user does not respond within 5 minutes or if the user cannot see the agent user interface (UI), the default action is taken.

  • Query User Default Deny Asks the user whether the resource request is appropriate with a default action of deny. If the user does not respond within 5 minutes or if the user cannot see the agent UI, the default action is taken.

  • Query User Default Allow Asks the user whether the resource request is appropriate with a default action of allow, as defined earlier. If the user does not respond within 5 minutes or if the user cannot see the agent UI, the default action is taken.

NOTE

Query rules are not allowed for Solaris users because they cannot interact with the local agent as on Windows and Linux systems. For Solaris users, the default action is always immediately taken.


Other actions include the following:

  • Monitor Enables you to match a resource request and log an event based on its occurrence without the need to define the request as a deny, allow, or terminate.

  • Add or Remove to/from Application Class Based on the resource request, you can add the process making the request to a dynamic application class or remove it from an application class if that is appropriate.

NOTE

When rules that are combined on a host conflict with one another, the resulting rule that is applied is determined by the precedence assigned to the action chosen in the rules. This precedence ordering process is covered in the section "Rule Precedence and Manipulation" later in this chapter.


Figure 4-6 shows an example of an action selection drop-down box.

Figure 4-6. Action Selection Drop-Down Box


Understanding Query Options

Query rules can be an effective way to provide security controls while also allowing the user to make the ultimate decision on whether the requested resource should be allowed. In some environments where the user is considered "untrusted," you are not required to use query options but could opt to only use explicit allow, deny, or terminate actions within your policies.

NOTE

Query settings are covered in detail in Chapter 5, "Understanding Application Classes and Variables," and are only covered at a high level in this chapter.


When the query action is chosen for a rule, an additional Query Settings drop-down box appears. From this drop-down, you choose the query setting that should occur as a result of the resource request. This list is ordered according to the default action defined for the query setting created. For an illustration of the query action selection and query setting Configuration page, see Figure 4-7 and Figure 4-8, respectively.

Figure 4-7. Query Action Selection for a Rule


Figure 4-8. Query Setting Configuration Page


It is also very important to understand that the default action associated with a particular query is a very powerful and necessary setting. The default action is the action that will take place automatically on systems that cannot see the agent UI per policy definition and on Solaris systems that do not have an interactive agent UI option. In addition to being the default action, it tends to serve as a hint to the user as the option the security team prefers the user consider. This can be a much more powerful suggestion than some people think.

NOTE

An interesting way to use query rules is to use this feature without presenting the user an option other than the default. You can present the user an informational message upon resource request but only provide terminate or deny action(s) as selectable buttons.


Rule Precedence and Manipulation

As you combine rules into rule modules, conflicting rules in the combined set may occur. It is imperative that you understand how the CSA system dictates which rule will take effect based on precedence. The following actions are in order of precedence with the entries at the top taking precedence over lower actions:

  1. High priority terminate process

  2. High priority deny

  3. Allow

  4. Query user (terminate)

  5. Query user (deny)

  6. Query user (allow)

  7. Terminate process

  8. Deny

  9. Default action allow

  10. Add process to application class

  11. Remove process from application class

  12. Monitor

NOTE

Monitor rules are always processed along with other rules that may be enforcement in nature, regardless of precedence.


The combined rule set is ordered by the preceding action order for application on the host. For items that use the same action type, if logging is set, that rule takes precedence over rules that do not have logging set.

You can manually manipulate this order through the use of a few configuration options. On many of the rules that you can configure, you have seen the option Take Precedence over Other Rules of the Same Action Type. This option, when chosen for a rule, places that rule at the top of the rule application list when being ordered against rules of the same action type.

NOTE

When CSA combines rules into an active agent policy, the order of rule evaluation is action type, rule precedence check box, and finally logging enabled or disabled. The agent therefore resolves conflicts first by action precedence, next by the rule precedence override check box, and finally by whether logging is enabled if all other rule configuration matches.


Query rules also have a precedence or prioritized order of evaluation when applied in a combined policy on the host. The order is manipulated by the options available to the query rules. The order of precedence for query rules is as follows:

  • Challenge option chosen

  • Don t ask again chosen

  • Log

Other Common Rule Configuration Options

A few configurable parameters are common across many of the rules that you can define in CSA policies. The options are for the most part generic and for informational purposes. These options are logging, descriptions, and the Enabled check box.

Logging is an option available from rule configuration pages. The configuration is as simple as either checking or unchecking the associated Log check box. Checking the Log check box ensures that an event is logged to the CSA MC event log and the local csalog.txt file. By default, all actions are set to log other than the allow action.

Another field common to various rules is the Description field. This field and the Detailed Description field should be used to assist other administrators during the troubleshooting process.

A final shared configuration option is the Enabled check box. If this is checked, the rule is active and enforced, whereas rules that have this option unchecked are not enforced. This is an easy way to disable a rule without deleting it from the rule set immediately.

CSA Rule Types

You can use several rule types when building policies for agent-protected systems. These rules control access to resources and can use all of the previously defined shared configuration options such as state sets, logging, query settings, and various actions. This section describes the various rule types available to you.

NOTE

For the next several sections describing the various rule types available, the operating systems that can use the rule type are printed in brackets next to the name of the rule type. The operating systems supported are denoted using a W for Windows systems and a U for UNIX (Solaris and Linux) systems.


Agent Service Control [W and U]

You can use the agent service control rule to control or monitor a local administrator s ability to stop the agent service on the protected system, prevent the user from stopping agent controls by setting the slider bar in the CSA UI to the off position, as well as monitor any attempt to modify agent configuration, executable, or data files. This rule is extremely important because any attempt to uninstall the agent requires the ability to stop the agent service. Preventing service stoppage also prevents uninstallation.

NOTE

Agent self-protection is not a configurable option and is always functioning when the agent is running. Agent self-protection prevents an agent from being modified, which could result in a compromised or Trojan horse and cause weakened security policy along with the possibility of modified log files and other undesirable outcomes.


The agent service control rule configuration parameters are as follows, as shown in Figure 4-9:

  • Description and Detailed Description Describe the rule to provide enough necessary information to aid in troubleshooting.

  • Enabled Check the box to activate the rule.

  • Take the Following Action Choose the appropriate action from the drop-down box.

    The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add or Remove Process to/from Application Class

    • Monitor

    By default, Query User is chosen.

  • Log Enable event log messages for this rule.

  • Take Precedence over Other Rules Choosing this option ensures this rule has a higher precedence when ordered against other rules in the policy, including conflicting rules.

  • Applications in the Following Class Choose the application class that identifies the process or application attempting to stop or modify the agent. By default, All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Stop the Agent Service Check this check box to apply this rule to any attempt to stop the running service on the system that matches the preceding criteria.

  • Attempt to Modify Local Agent Configuration Check this check box to apply this rule to any attempt to modify agent configuration, data, and program files. Although you cannot disable the ability to modify the agent files while the agent is running, you can monitor or tag the offensive process with this rule.

  • Save and Delete buttons Commit or delete the changes to this rule.

Figure 4-9. Agent Service Control Rule


Agent UI Control [W and U]

The agent UI control rule controls the user s ability to interact with the local security agent UI. The rule enables users to see the UI in the system tray as well as granularly control how much interaction is granted to the end user. Within this rule, you can provide user interaction capability such as the following:

  • Enable users to edit the local contact information associated with the agent

  • Enable users to modify agent security settings

  • Enable users to control the personal firewall and file protection mechanisms

NOTE

If this rule is not active on an agent, no user interaction is available because the default agent setting does not provide local interaction.


Figure 4-10 shows the agent UI control rule screen, which includes the following configuration parameters:

  • Allow User to Reset Agent UI Default Settings Check this box to allow the local user to reset all user-changed settings and permanently cached entries to the factory default.

  • Allow User Interaction Check this box to provide the visible tray icon and ability to receive pop-up messages and query messages. The user can also open the security agent UI to view the status of the agent, as well as view and clear query responses. This option also enables the user to choose from the following additional granular UI controls:

    • Allow User Access to Agent Configuration and Contact Information Enables the user to perform a fast poll and enter contact information for this agent system.

    • Allow User to Modify Agent Security Settings Provides the user the slider bar so that the user can possibly modify the local agent security level from off through high.

  • Allow User to Modify Agent Personal Firewall Settings Enables the user to use the personal firewall and file protection controls. These controls are additive to the global policies defined and cannot override global policy, but rather further secure the system.

Figure 4-10. Agent UI Control Rule


NOTE

The lists of parameters in this chapter focus on those features that are new or unintuitive. To reduce redundant explanations, parameters that appear in multiple rule screens do not appear in each list.


If the user has multiple agent UI control rules applied, a visible UI overrides an invisible UI. Also, any other check box in this rule type, if checked, overrides an unchecked check box from another conflicting rule.

Application Control [W and U]

The application control rule is used to control which applications can run on host systems. If you are attempting to prevent an application or process from executing on a host, use this type of rule. You can also use this rule to prevent a running application from starting other undesired processes. For example, you might want to enable the user to use a command shell such as cmd.exe but never want any other application to attempt to launch a shell (because this is typically a trademark of a virus, worm, or poor programming).

The application control rule configuration parameters include the following:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class Choose the application class that identifies the process or application attempting to execute on the system or attempting to start other processes. By default, All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Run Applications in the Following Application Class Choose the application class that identifies the process attempting to be started by the previously identified process or application. By default, this is set to All Applications.

  • But Not in the Following Class Choose any application class you want to exclude as a started process. The default is None.

Figure 4-11 shows an application control rule configured to prevent any application from attempting to spawn a command shell. You could very easily also create a rule of this type to prevent undesired applications from executing on corporate resources. You would first create an application class and file set combination that defines the list of undesired applications by filename or dynamic link library (DLL). You would then apply those building blocks to the application control rule as applications that should not run. Building blocks such as application classes and variables are covered in detail in their respective chapters throughout this book.

Figure 4-11. Configuring an Application Control Rule


Clipboard Access Control [W]

The clipboard access control rule proves useful in combination with other rules when you are trying to protect data from theft. If users can open a file, they can typically perform a copy function and move the chosen data from the file to the Windows clipboard. After that data is in the clipboard, users could copy the information to another file (or possibly e-mail to circumvent file control mechanisms). The clipboard access control rule only allows data moved within a defined application to be copied to authorized locations, while other applications can continue to use the clipboard function unimpeded. As an added feature, after this rule has been activated for a specific application, the Windows Print screen capability is also disabled. You cannot, however, prevent the user from using a digital camera or camera phone (hence the need for a physical security policy).

Figure 4-12 shows the clipboard access control rule screen, which includes the following configuration parameters:

  • Do Not Allow Other Applications to Read Clipboard Content Written by the Following Application Class Assign an application class to this rule type to specify the applications that should be allowed to share the clipboard data while other applications not defined by the class should have no access to the data. The default is All Applications.

  • But Not in the Following Class Choose any application class you want to provide clipboard access to the protected data. The default is None.

Figure 4-12. Clipboard Access Control Rule


COM Component Access Control [W]

The COM component access control rule is a mechanism that enables you to define which COM objects can be accessed by specific applications. COM objects allow for seamless interaction between processes on Windows systems but can be compromised just as seamlessly. As a result, you may want to control COM object access.

Figure 4-13 shows the COM component access control rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class Choose the application class that identifies the process or application attempting to access the COM object(s) to be identified. By default, All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Access a COM Component in the Following Component Set Choose the COM component set that identifies the COM object(s) you want to limit. By default, this is set to None. A COM component set is a variable that identifies the necessary components. You could also use literal terminology to refer to the COM object if desired.

Figure 4-13. COM Component Access Control Rule


Connection Rate Limit [W and U]

The connection rate limit rule controls the number of connections that can be opened both inbound and outbound on a system. This rule assists in preventing DoS attacks on the locally protected system by limiting the number of inbound connections received by the host from all hosts or on a per-host basis. You can also limit the number of outbound connections the machine can create to another host, which prevents the spread of DoS attacks. The enforced rate limits can also pertain to specific applications creating or terminating the connections or to all applications on the system.

Figure 4-14 shows the connection rate limit rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following class Choose the application class that identifies the process or application that should be rate limited. By default, All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Act As A Choose Client, Server, or Client-or-Server from the drop-down list to state whether the rate limit rule being created will limit inbound connections, outbound connections, or both.

  • Communicating With Choose All or Specific Hosts from the drop-down box, indicating whether the rate limit should be an overall rate limit or applied on a per-host basis.

  • Over Limit ofnumberNetwork Connections Enter the number of network connections pertaining to the configured rate limit. By default, the number is 100 per host.

  • InnumberMinutes Enter the time interval to monitor the connection defined. By default, this is 5 minutes.

Figure 4-14. Connection Rate Limit Rule


NOTE

You should not typically choose Terminate Process as an action for this type of rule when setting the rule for inbound connections because a DoS attempt or high threshold of normal traffic will shut down the process answering the connections. You may, however, want to choose Terminate Process when writing the rule to prevent outbound DoS attempts.


Data Access Control [W and U]

You should apply the data access control rule to web server systems. This type of rule monitors inbound web traffic and more specifically the Uniform Resource Identifier (URI) portion of the web requests. When watching URI traffic, the rule is specifically looking for malformed requests that may adversely impact the web server. The majority of known malformed requests are listed in the data set provided in the CSA MC installation, but you can create your own sets to catch new or specialized attacks.

This rule requires that the local system have the CSA data filter installed for the rule to be enforced. On Windows platforms, IIS and Apache installations are detected at agent installation time and the data filter is automatically loaded. If it is not loaded, you need to manually install the data filter by using the local csa_datafilter installation file. The data filter may also need to be manually installed if the web server was not loaded in the default directory. On UNIX platforms, the data filter always requires a manual installation.

NOTE

The URI in a web request contains the URL and the more detailed GET requests and parameters.


Figure 4-15 shows the data access control rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class Choose the application class that identifies the process or application that should be monitored for inbound URI traffic. By default, All Applications is the chosen class; however, only Apache, IIS, and iPlanet are supported.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Access These Data Sets Choose the data set variable containing the URI patterns you want to detect or enter literal values.

Figure 4-15. Data Access Control Rule with IIS Data Set Definition


File Access Control [W and U]

The file access control rule provides a mechanism to control which processes can read or write files or directories. These rules can lock down access of certain files and directories that need to be protected or ensure that certain types of applications can only read specific file types. When this rule applies to UNIX systems, understand that applying this rule to a symbolic link only protects the link and not the target file. You must specify that file as well to protect it.

Figure 4-16 shows the file access control rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following class Choose the application class that identifies the process or application that this rule will impact.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt the Following Operations Choose a combination of Read File, Write File, and Write Directory (create/delete/rename).

  • On Any of These Files Enter literal file or directory entries (with wildcards if necessary). You can also use file set variables that include the necessary values. You can also use network share locations if necessary. Another mechanism provided by the CSA architecture is the use of special variables such as @dynamic, @local, @system, @removable, and @floppy.

Figure 4-16. File Access Control Rule


File Version Control [W]

The file version control rule enables the security team to enforce which versions of an application are allowed or denied to execute on a system. This rule proves useful when you want your user base to run an application but there is a specific version of the application that includes a known vulnerability or bug. You can write a rule to prevent that specific version of the program from running on a CSA-protected system while allowing other versions or only a specific version of the application to run.

Figure 4-17 shows the file version control rule screen, including the following configuration parameters:

  • Take The Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • An Execution of the Following File Enter the filename without path information. This can be an EXE, DLL, or OCX file without wildcards.

  • With Version Within These Version Ranges Enter the version ranges you want to allow or prevent from running on the system. You can enter a specific version, such as 4.5.23, or a range, such as 4.5.23-4.7.60. You can attempt to get the version information by right-clicking the file and selecting properties or checking with the manufacturer. You can see an example of a file version for Internet Explorer in Figure 4-18.

    Figure 4-18. Locating the File Version of iexplore.exe


Figure 4-17. File Version Control Rule


Kernel Protection [W]

The kernel protection rule prevents unauthorized access to the operating system by not allowing drivers to dynamically load after system startup unless an exception for that specific driver has been made.

Figure 4-19 shows the kernel protection rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Deny

    • Allow

    • Deny

    • Add Process to Application Class

    • Monitor

    By default, Allow is chosen.

  • Modules Load After System Startup Checking the check box enforces a rule that takes the associated action if a module loads after system startup.

  • Included Modules Insert the file set to match, or enter the literal value. By default, the value is None, which disallows drivers from loading after system startup unless specifically mentioned here when the action is set to Deny.

  • Modules Modify Kernel Functionality This rule monitors attempts to modify system files but does not prevent the attempts. You could use a dynamic application class with this rule to create a restrictive policy as a result.

  • Included Module Hashes Use only the wizard to edit the entries in this field as part of a triggered event. This field is not intended to be manually edited.

  • Included Code Patterns Use only the wizard to edit the entries in this field as part of a triggered event. This field is not intended to be manually edited.

Figure 4-19. Kernel Protection Rule


NOTE

Windows updates and certain patches may trigger the kernel protection rule. If you allow the patch to install, you might need to write an exception to the particular installation to ensure a successful patch process. As always, testing and tuning in a test environment is the best approach before a production implementation.


Network Access Control [W and U]

You can use the network access control rule to control network access to and from specific applications as well as reporting applications attempting to listen on ports prior to receiving an active inbound connection. This rule allows granularity down to the protocol and port level as well as IP address ranges associated with the connectivity.

Figure 4-20 shows the network access control rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. If you use Query for this type of rule, the server automatically uses the default query action to enable a successful connection if necessary, but the user is still prompted. For further requests, the cached query response is automatically used in place of the default action.

  • Log check box Enable event log messages for this rule. For this particular rule type, even when Log is checked, broadcast traffic on UDP ports will not trigger an event.

  • Applications in the Following Class Choose the application class that identifies the process or application that should be allowed or denied network access. By default, All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Act As A Choose the Client, Server, Client-or-Server, or Listener. If you choose Listener, this rule detects applications that are listening on a port prior to detecting inbound communication. This is a great way to detect a Trojan horse that was loaded prior to the agent installation.

  • For Network Service Specify the network service by literal protocol/port such as TCP/25 or network service set.

  • Communicating with Host Addresses Choose the appropriate network address set or literal IP address or range for the remote IP address involved in the conversation. By default, the address is 0.0.0.0-255.255.255.255.

  • Using These Local Addresses Choose the appropriate network address set or literal IP address related to the local IP address for the conversation. By default the address is 0.0.0.0-255.255.255.255.

Figure 4-20. Network Access Control Rule


Network Shield [W and U]

The network shield rule requires the use of the network shim, which you can install on the system during installation of the CSA software. This rule provides various IP protocol stack-hardening mechanisms that can granularly be enabled and disabled during rule configuration.

Figure 4-21 shows the network shield rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Deny

    • Allow

    • Deny

    • Add Process to Application Class

    • Monitor

    By default, Allow is chosen.

  • IP Security Checks:

    • Invalid IP Header Perform a consistency check on the IP header, the length of the header, and the number of bytes in the header. Drop invalid packets.

    • Invalid IP Address Choose this option to prevent known invalid IP addresses or usage. Source multicast addresses and destination multicast addresses over TCP connections are examples of invalid IP addresses.

    • Source Routed Packets Match packets that are source routed.

    • Trace Route Match traceroute packets.

  • Transport Security Checks:

    • Invalid TCP/UDP/ICMP Header Similar to the IP header checks, including flags and flag combinations.

    • TCP SYN Flood Detect SYN flood attempts. This option does not function for UNIX systems because they already have SYN flood detection mechanisms.

    • TCP Blind Session Spoofing Attempts Make session numbers unpredictable. This option does not function for UNIX systems because they already have unpredictable session numbers.

    • TCP/UDP Port Scans Prevent the system from responding to port scan attempts and prevent sending connection error messages. This option also triggers a global event correlation on the CSA MC if several systems correlate a port scan attempt over a set period of time.

    • ICMP Ping Message Prevent ICMP scanning attempts.

    • ICMP Configuration Message Prevent ICMP configuration from occurring.

    • ICMP Information Message Prevent responding to ICMP information messages.

    • ICMP Covert Channel Cause the system to drop unsolicited echo response packets that could carry traffic as a backdoor channel to the system through firewalls and other filtering devices.

    • Malicious Packet Block packets that are known malicious packet types even if they are legally permissible by RFC (Request For Comment) IP standards.

  • System Startup Security Checks:

    • Unrestricted Network Connectivity During Boot Prevent attacks to services prior to the agent starting on Windows systems only.

  • Communicating with Host Address Enter the literal host or subnet address or use a network address set to identify the hosts to which this rule applies. You can use this field in combination with an allow rule to allow known scanners on your network to continue to probe the systems without creating unnecessary log data.

  • Using These Local Addresses Set the local address that this rule pertains to, such as @local, or a specific address or set variable.

Figure 4-21. Network Shield Rule Configuration


NT Event Log [W]

The NT event log rule provides a mechanism for correlating NT event log messages in the CSA MC event log. You can report wide ranges of events or specific events for correlation. If you decide to use this rule to send antivirus information to the event log, you can correlate the events on the CSA MC.

Figure 4-22 shows the NT event log rule screen, which includes the following configuration parameters:

  • Event Log Type Choose a combination of system, application, and security logs you want to monitor.

  • Event Source Enter the application or component name that is the source of the event in the log. The default is All, but could be a source, such as NtServicePack, which will pertain to events regarding the installation of a service pack on a system and may be very valuable information. Other event sources include DNS, DHCP, and antivirus packages. Figure 4-23 displays an example from a production NT Event Viewer system log.

    Figure 4-23. NT Event Viewer Entry


  • Severity Choose all severity levels that are appropriate: Information, Warning, Error, Audit Success, or Audit Failure.

  • Event Code Set this to a specific event code to identify a log event to monitor and report. By default, this is set to All Events.

Figure 4-22. NT Event Log Rule


NOTE

You can locate event codes by searching the Microsoft website or validating the information in production event logs.


Registry Access Control [W]

The registry access control rule is a control mechanism that can disallow or allow applications writing to the registry or specific keys and hives.

Figure 4-24 shows the registry access control rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class Choose the application class that identifies the process or application attempting to write to the registry. By default All Applications is the chosen class.

  • Attempt to Write Any of These Registry Entries Choose the registry set or enter the literal registry value that you want to identify for this rule. By default, this is set to None.

Figure 4-24. Registry Access Control Rule


Service Restart [W]

With the service restart rule, CSA can automatically restart Windows services that stop or are not responding to requests.

Figure 4-25 shows the service restart rule screen, which includes the following configuration parameters:

  • Restart the Following Service Enter the service name here as listed in the services control panel or by issuing the net start command.

  • When Not Responding to Service Control Manager Choose this option to cause CSA to attempt to restart the service if the service is not responding for any reason, including failure.

  • When Not Responding to Network Requests for Service Test the service for connectivity via the following several protocols: CTA EAP, Cisco VPN service protocols, DHCP/BOOTP, DNS, e-mail, ephemeral port ranges, FTP client data channel, FTP control channel, FTP server data channel, HTTP, IKE, instant messenger protocols, IRC user, Kerberos, LDAP, Location Service, Microsoft-DS, MMCC, MS SQL Server, NameServer, NetBIOS, NetBIOS Datagram Service, NetBIOS Datagram Service Protocol, NetBIOS Name Service, NetBIOS Name Service Protocol, NetBIOS Session Service, NNTP, Real Audio, Real Audio Server data channel, Rexec, Rlogin, SMB and NMB, SNMP, SOCKS, SSH, TCP, TCP ephemeral server ports, Telnet, TFTP, TFTP data channel, time protocols, UDP, or UDP ephemeral server ports. The network shim must be installed for this to work.

Figure 4-25. Service Restart Rule


Figure 4-25 shows a service restart rule along with a typical Windows net start command executed in a command shell. This list of services that result from the Windows command serve to illustrate the exact naming of a service that must be used when configuring a service restart rule. From the figure, you can see the DNS Server service name matches exactly as it is listed by Windows and will therefore be successfully implemented in the CSA policy.

Sniffer and Protocol Detection [W]

The sniffer and protocol detection rule logs events when non-IP protocols and packet sniffers are detected on the agent-protected system. Sniffers loaded on systems can steal proprietary traffic traversing the network, which may include intellectual data, e-mails, and username/password combinations. It is important that any system running as a sniffing entity be detected immediately to prevent loss of confidentiality and integrity. Non-IP protocols should also be treated with care because they could be used as backdoor transport mechanisms that circumvent various protective mechanisms such as network access control rules, network firewalls, and IDS/IPS appliances.

Figure 4-26 shows the sniffer and protocol detection rule screen, which includes the following configuration parameters:

  • Enabled Uncheck the box to deactivate the rule from any active running policy without permanently removing the rule from the system. You use this option when testing and tuning policy so that you can selectively turn off a rule without the need to re-create it later, which would be the case if you instead deleted the rule.

  • Exclude the Following Standard Protocols Choose the predetermined common non-IP protocols from the list using the Shift-mouse click or Ctrl-mouse click functionality for multiple selections. The list includes TCP/IP Protocol, AppleTalk Protocol, DLC Protocol, NDIS Proxy, NetBEUI Protocol, NWLink IPX/SPX Compatible Transport, QoS Packet Scheduler, Remote Access NDIS TAPI, Remote Access NDIS WAN, and Remote Access PPPOE.

  • Exclude the Following Non-Standard Protocols Enter nonstandard protocols and packet sniffers here, such as PacketDriver. The default entry is None.

Figure 4-26. Sniffer and Protocol Detection Rule


System API [W]

The system API rule enables you to prevent Trojan horse behavior and malicious code attempting to execute on the endpoint. Prior to CSA version 4.5, this functionality was nonconfigurable. This rule will most likely require you to create exceptions during the tuning process. Items that would require tuning include poorly written applications and software distribution mechanisms.

Figure 4-27 shows the system API rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class Choose the application class that identifies the process or application attempting to perform the chosen actions. By default All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • System Information Checks:

    • Access Local Configuration Information Detect code executing on a protected system that is attempting to read from the registry.

    • Access Local Password Information Choose to detect processes that attempt to read and steal local passwords.

  • System Monitoring Checks:

    • Monitor Media Devices Use this function to prevent devices connected to the system from grabbing local media streams. You also can use the Included Patterns input field to allow certain media devices to function without triggering the rule. To allow a specific media device to function appropriately, you specifically name the device and use an allow action. This rule can prevent Trojan horses from listening on a local microphone or from receiving pictures from a webcam. The excluded devices should use device\port as the entry method such as webco\camera.

    • Trap Keystrokes Detect devices that hook the keyboard. Processes that hook the keyboard are attempting to capture keystrokes as they are entered by the user. This is a typical behavior exhibited by Trojan horses. You may need to write rules of this type that allow (or exclude) certain processes from triggering this detection method because certain applications may need to legitimately trap keystrokes.

  • System Modification Checks:

    • Access Physical Memory Prevent processes from directly accessing physical memory. Typically, applications should execute using virtual memory restrictions.

    • Download and Invoke ActiveX Controls Detect applications that attempt to load and execute ActiveX controls. The application would most commonly be a web browser, but could also be malicious code.

    • Inject Code into Other Applications Detect code that has been marked as "downloaded" when it attempts to inject code into space owned and used by another application.

    • Write Memory Owned by Other Applications Detect an application that attempts to use or tamper with memory space being used by another application. Also, detect Trojans that can be hidden in another application as it attempts to access resources.

  • Atypical System Behavior Checks:

    • Access System Functions from Code Executing in Data or Stack Space Prevent buffer-overflow attacks. You also have the option to enter, manually or via the wizard, excluded patterns that should not trigger this rule, because some types of applications may perform using this method either intentionally or unintentionally (poor programming).

    • Handle Exceptions Detect applications that are running exception-handling routines. This is not a normal behavior for applications and should be noted.

    • Invoke Unusual System Calls Enable a trigger when an application attempts to use a system call that is rarely or never used in today s programs. These calls can have vulnerabilities associated with them that may be known or unknown, and you should prevent them because any attempt to use an uncommon system call is suspicious at best. You can use the Pattern Inclusion field (along with an allow rule) to allow certain applications that require these calls to continue to function.

Figure 4-27. System API Rule


Buffer Overflow [U]

The buffer overflow rule is a UNIX-specific rule that has some similar functionality to that provided by the Windows-only system API rule. The buffer overflow rule assists in detecting and preventing buffer overflows from resulting in escalating privileges of the user attempting the buffer overflow. A buffer overflow is most dangerous when it occurs in a program that has higher privileges than a user. The user could cause a buffer overflow to occur and when escaping the failed program gain the access capabilities previously granted to the application itself.

Figure 4-28 shows the buffer overflow rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • Allow

    • Query User (Allow or Terminate)

    • Terminate Process

    • Monitor

    By default, Allow is chosen.

  • Attempt the Following Operations Choose from the following options:

    • Attempted Buffer Overflow Detection Attempt to detect buffer overflows in UNIX executables typically as a result of attempted stack buffer overflows in LIBC routines.

    • Execute a System Call in an Unsafe Context Stop certain system calls that grant additional privileges or start additional processes from attempting to do so if they are coming from an application in a corrupted or invalid context.

    • Process Terminated by Operating System Due to Executing Code in Stack Space Force the use of the noexec_user_stack system variable with all executing processes. You can only monitor the interaction of this function and cannot use Deny.

    • Process Terminated Due to Signal or Internal Error Enable this feature to monitor when a process ends because of signal or internal errors and report to the event log.

    • Use of an Unsafe Format in PRINTF Call Prevent the %n format qualifier for printf() calls because it could be used to gain access to program flow information.

Figure 4-28. Buffer Overflow Rule


Network Interface Control [U]

The network interface control rule is a UNIX-specific rule that prevents a system from being able to place an interface in Promiscuous Mode. When a network interface is in Promiscuous Mode, it can act as a sniffer, which can be used to steal packets, including proprietary data and name and password information.

Figure 4-29 shows the network interface control rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class Choose the application class that identifies the process or application attempting to place the NIC in Promiscuous Mode. By default All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Open a Stream Connection to the NIC Driver Prevent stream connections to the NIC. You might need to write an allow rule to allow certain applications on your network to continue to function using stream connections.

  • Attempt to Put the NIC into Promiscuous Mode Detect and prevent placing the NIC in Promiscuous Mode.

Figure 4-29. Network Interface Control Rule


NOTE

Depending on the action you choose for the network interface control rule, checking one of the two check box actions at the bottom of the Configuration page will automatically choose the other because of the dependent nature of the two functions.


Resource Access Control [U]

The resource access control rule is a UNIX-specific rule that you can use to prevent symbolic link attacks from occurring on the system. This prevents links that are suspicious in how they are used as defined in the configuration parameters that follow.

Figure 4-30 shows the resource access control rule screen, which includes the following configuration parameters:

  • Symbolic Link Protection Check this box to enable the CSA to prevent common symbolic link attacks. A savvy user might attempt to create a symbolic link to a file that does not yet exist and use it to gain higher permissions or the ability to change the file it is linked to. Symbolic Link Protection prevents a link from functioning if

    • The parent directory is a temporary directory, such as /tmp.

    • The link s owner is not the same as the parent directory.

    • The link s owner is different from the UID of the process.

Figure 4-30. Resource Access Control Rule


Rootkit/Kernel Protection [U]

The rootkit/kernel protection rule is a UNIX-specific rule that prevents unauthorized drivers from loading after boot time unless specifically allowed to dynamically load. This is similar to the Windows-only kernel protection rule.

Figure 4-31 shows the rootkit/kernel protection rule screen, which includes the following configuration parameters:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in Any of the Following Class Choose the application class that identifies the process or application attempting to dynamically load drivers. By default All Applications is the chosen class.

  • But Not in the Following Class Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Load the Following Modules When used in an allow rule of this type, use this file to exclude specific drivers that are allowed to load. The default entry here is None.

Figure 4-31. Rootkit/Kernel Protection Rule


Syslog Control [U]

The syslog control rule is a UNIX-specific rule that can assist in the correlation of syslog events into the central CSA MC event log database. This is quite similar to the Windows-specific rule that took events from the NT event log and placed them in the CSA MC database.

The syslog control rule configuration parameters are as follows:

  • Take the Following Action Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Event Source Enter the syslog event source code information here that you want to match or exclude as per the rule definition. By default, All is chosen.

  • Facility Using the multiselection tool, choose the appropriate facilities from the list of options: auth, cron, daemon, kern, local0 through local7, lpr, mail, news, resv9 through resv14, syslog, user, or uucp.

    Figure 4-32. Syslog Control Rule


  • Priority Choose all the priority levels that should match: Debug, Information, Notice, Warning, Error, or Alert and Above.

  • Message Pattern Enter a literal string that should be in the message for it to trigger the rule. The default is All, but you can edit it to a specific value. An example is a literal such as packet dropped.

     < Day Day Up > 


    Cisco Security Agent
    Cisco Security Agent
    ISBN: 1587052059
    EAN: 2147483647
    Year: 2005
    Pages: 145
    Authors: Chad Sullivan

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net