Table Of Contents
Available Rule Types
Overview
Rules Common to Windows and UNIX
Agent Service Control
Agent UI Control
Hiding the agent UI
Application Control
Connection Rate Limit
Data Access Control
Protecting web servers
Protecting MSRPC and LPC interfaces
Creating Data Access Control Rules
File Access Control
Network Access Control
Network Shield Rule
Windows Only Rules
Clipboard Access Control
COM Component Access Control
File Version Control
Kernel Protection
NT Event Log
Printer access control
Registry Access Control
Scan Event Log
Service Restart
Sniffer and Protocol Detection
System API Control Rule
UNIX Only Rules
Buffer Overflow Rule
Network Interface Control
Resource Access Control
Rootkit / kernel Protection
Syslog Control
General Syslog rule configuration examples
Available Rule Types
Overview
Rule modules contain various types of rules. Each rule type is intended to control a different set of system resources. For example, there is a rule type that controls access to files and directories and another rule type that controls network accesses. It is through the combining of the many available rule types that a rule module provides overall security to the entire system. This chapter provides information on each rule type.
This section contains the following topics.
•
Rules Common to Windows and UNIX
–Agent Service Control
–Agent UI Control
–Application Control
–Connection Rate Limit
–Data Access Control
–File Access Control
–Network Access Control
–Network Shield Rule
•Windows Only Rules
–Clipboard Access Control
–COM Component Access Control
–File Version Control
–Kernel Protection
–NT Event Log
–Printer access control
–Registry Access Control
–Scan Event Log
–Service Restart
–Sniffer and Protocol Detection
–System API Control Rule
•UNIX Only Rules
–Buffer Overflow Rule
–Network Interface Control
–Resource Access Control
–Rootkit / kernel Protection
–Syslog Control
Rules Common to Windows and UNIX
The following rule types are available for both Windows and UNIX policies.
Agent Service Control
Use the Agent service control rule to control whether administrators are allowed to stop agent security (This is via a net stop command on Windows or via /etc/init.d/ciscosec stop on UNIX. See Chapter 12, "Using Management Center for Cisco Security Agents Utilities," for details) and whether end users can disable security via the agent UI security slide bar. Stopping agent security disables all rules until security is manually resumed or the system is rebooted.
If you use this rule to deny agent service stops, the agent service cannot be stopped on the system in question and therefore agents cannot be uninstalled.
Note Although agents cannot be uninstalled by administrative users if this rule denies the stopping of the agent service, this rule does not prevent agent software updates from occurring.
You can also use this rule to monitor, terminate, or tag a process that attempts to modify the agent configuration.
These instructions are a continuation of Configuring Rule Modules, page 5-2.
Step 1 To add rules to your module, expand the rules area of the rule module and click the Add button. A pop-up list of the available rule types appears.
Step 2 Select the Agent service control rule. This takes you to the configuration view for this rule type (see Figure 6-1).
Step 3 In the Agent service control rule configuration view, enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the module and it will not be distributed to groups.
Step 4 Take the following action—(Note that not all action types are available for this rule on Windows platforms.) Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Options and Precedence, page 5-13.
Step 5 and
•Log—Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules—Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works. See Rules: Manipulating Precedence, page 5-16 for details.
Step 6 when
Applications in any of the following selected classes
Select one or more preconfigured application classes.
Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes. For application class configuration details, see Chapter 9, "Using Application Classes".
Note On UNIX systems, anyone with root access can stop the agent service. To prevent this, while still allowing administrators to stop the agent service, you would configure an Agent service control rule to Deny <All Applications> from stopping the service. Then configure another Agent service control rule which Allows only a UNIX Secured Management application class to stop the service.
But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
•attempt to disable agent security
This checkbox controls whether users with administrator privileges can stop the agent service from the Service Control Manager or by running net stop "Cisco Security Agent" from a command prompt on Windows or via /etc/init.d/ciscosec stop on UNIX.
Note This also controls whether the "Off" setting on the agent security level slidebar allows the end user to turn agent security off. If you do not allow the stopping of the agent service, the Off level, if available, is ineffective. See Agent UI Control for more information.
•attempt to modify local agent configuration
The Cisco Security Agent has built-in global security policies which protect agent binaries and data. (Note that this protection is only offered when the agent service is running and is not stopped or in Audit Mode.) While you cannot turn these non-logged, built-in rules off while the agent is active, you can use this rule to monitor, terminate, or tag a process that attempts to modify the agent configuration.
Step 7 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 8 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-1 Agent Service Control Rule (Windows)
Agent UI Control
Use the Agent UI rule to control how the agent user interface is displayed to end users. See Figure 6-2. In the absence of this rule, end users have no visible agent UI. If this rule is present in a module, you can select to display the agent UI and one or more controls to the end user. These controls give the user the ability to change certain aspects of their agent security. All the controls in this procedure are optional.
Note This rule only applies to Windows and Linux platforms. The agent UI is not supported on Solaris systems. Also note that Audit Mode does not apply to this rule type.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Agent UI Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 (Optional) Allow user to reset agent UI default settings—On Windows, Reset Cisco Security Agent is available from the Start>Programs>Cisco menu. On Linux, this is available from System Menu>Cisco Security Agent. By selecting this option, users can reset agent UI functionality to the original factory default settings All user set controls are lost and all persistent query responses are removed. This is useful on Windows platforms where different users with varying user agent permission settings may log into the same machine.
Step 6 (Optional) Allow user interaction—Selecting this checkbox causes the end user to have a visible and accessible agent UI, including a red flag in the system tray. With no other subsequent checkboxes selected, the agent UI contains a status view, a messages page to view agent events, and the ability to clear persistent and temporary query user responses. (If this rule is present in a module, but this checkbox is not selected, the end user will have no visible agent UI. In the presence of two or more Agent UI control rules, these rules are combined and selected checkboxes take precedence over unselected checkboxes.) See Hiding the agent UI for more information about not selecting this option.
Add one or more additional optional controls as follows:
•Allow user access to agent configuration and contact information: Selecting this checkbox allows the end user to enter Contact information into the agent UI. They also have access to a Poll button which allows them to force a manual polling of the MC.
•Allow user to modify agent security settings: Selecting this checkbox provides the end user with the ability to alter their security level by moving a slidebar between Off, Low, Medium, and High (in accordance with policies) and to manage the classification of untrusted content.
This checkbox provides an Off control on the agent UI. This Off control works in combination with the Agent service control rule (see Agent Service Control). You must both provide this slidebar to the end user and have an Agent service control rule in place which allows the agent security to be disabled in order for the Off setting to actually turn security off.
Allowing this action (moving the slidebar to Off) permits all users (including non-administrative users) to disable all rules on the agent until they are re-enabled by the user. (Note that if there is no agent UI present, agent security cannot be turned off.)
•Allow user to modify agent personal firewall settings—Selecting this checkbox provides the end user with the ability to dictate which applications are allowed network access. They also gain a file protection capability by which they can enter the names of local files that network applications are not allowed to access on their system. Note that if a user is allowed to configure personal firewall settings, resource access attempts on the system must pass both policy rules and firewall settings. (If you select this checkbox, you are providing the end user with controls that you have limited access to. Firewall queries and other information will not log to the CSA MC event log.)
Step 7 Suppress taskbar notifications—Selecting this check box in the Agent UI control rule, greatly reduces CSA notifications to the user. If the option is selected, user interaction with CSA is changed in these ways:
•The user no longer receives balloon messages.
•The flag icon in the system tray no longer pulses.
•The user no longer receives tool-tip text in the task bar icon.
•The user will no longer hear sounds for security events.
Note Users also have control over suppressing taskbar notifications. On the agent shortcut menu, users can select "Suppress Taskbar Notifications." If users choose to suppress taskbar notifications, then they gain control over turning this function on or off in the future. If an administrator changes the Suppress taskbar notifications check box in this rule after a user changes the setting, the administrator's action will have no affect on that user.
Step 8 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Hiding the agent UI
Not enabling the Allow user interaction checkbox in this rule has the following effects.
Software updates
There are no effects. Hiding the agent UI and Software updates are independent features. You can provide a software update prompt when an agent UI is not present.
Queries
When there is no agent UI present, there are no query user pop-up boxes displayed. The default is immediately taken on all query user rules and heuristics that are present in the assigned polices. (Note that this does not apply to cases where the end user manually exits the agent UI. Only the administrator controlled agent UI rule can affect query pop-up displays on the end user system.)
Unavailable end user features
•No messages to inform user that actions have been denied and why.
•No ability to clear cache or re-enable logging.
•No fast polling ability.
•No end user contact information can be sent to CSA MC.
Hidden agent UI feature notes
If a host belongs to multiple groups with multiple policies, having a visible agent UI setting, if present in any group for which the host is a member, takes precedence over a no user interaction agent UI setting.
Whether or not an end user system is going to have a visible agent UI or a hidden one, the end user (or administrator) must download and install the agent kit on the system. The initial installation of an agent kit cannot be done automatically (unless you have written your own script to do so, see Scripted Agent Installations, page 3-17).
When there is no agent UI present, there are no query user pop-up boxes displayed. The default is immediately taken on all query user rules and heuristics that are present in the assigned polices.
If an end user system already has an agent UI installed, when you unselect the Allow user interaction checkbox and generate rules, the agent UI disappears when the new rules are downloaded.
Figure 6-2 Agent UI Control Rule
Application Control
Use Application control rules to control what applications can run on designated agent systems. This rule type does not control what application can access what resources as do other access control rules. This rule type can stop selected applications from running on systems. If you deny an application class (in total) in this rule, users cannot use any application in that class.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Application Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•If you want to control an application (allow or deny) running on a system no matter how it is in invoked, allow "All Applications" to remain selected by default. (Then you will select the application you want to control from the second Application class list.) If you want to control which application(s) can invoke other applications, select one or more preconfigured application classes here to indicate the application that is doing the invoking (such as Network Applications).
You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application classes.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 attempt to run
•New applications in any (or all) of the following selected classes—Select the application you want to control if an attempt is being made to run it by the application defined by the Applications in any (or all) of the following selected classes field.
If you choose New applications in any of the following selected classes the rule will control an application that is a member of one of the selected application classes.
If you choose New applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
If you selected "All Applications" in the top application field, you cannot select All Applications in this second field. If you did so, all applications would be completely prevented from running on systems if this is a deny rule.
•But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
Note Creating dynamic application classes from the Application control rule is a bit different than creating them from other rule types. Because this rule has two application class fields, you can choose to add the current application to the dynamic class or choose to add the new application that is invoked by the first application to the dynamic class.
Note Most dynamic application classes are not available in this second application class inclusion field.
Step 10 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 11 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-3 Application Control Rule
Connection Rate Limit
Use the connection rate limit rule to control the number of network connections that can be sent or received by applications within a specified time frame. This is useful in preventing attacks aimed at bringing down system services, e.g. denial of service attacks (server connection rate limiting). This is also useful in preventing the propagation of denial of service attacks (client connection rate limiting).
Note Multiple instances of the same application are counted together with respect to this rule. For example: If a machine has several instances of Apache web server running, all Apache connections are counted together when applying this rule.
Note These instructions are a continuation of Configuring Rule Modules, page 5-2.
Step 1 To add rules to your module, expand the rules area of the rule module and click the Add button. A pop-up list of the available rule types appears.
Step 2 Select the Connection rate limit rule. This takes you to the configuration view for this rule type.
Step 3 Enter the following information for the rule:
•Description—Enter a description of this rule.
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.)
By not selecting this checkbox, you can save this rule, but it will not be active in the module and it will not be distributed to groups.
•Log—Use this checkbox to enable logging within the module.
Step 4 Take the following action—Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Options and Precedence, page 5-13. (Note that you cannot configure Query User Connection rate limit rules. Also note that if you select the Set action for marking a host as untrusted, you can only configure the rule for servers and for specific hosts.)
Step 5 When Applications in any of the following selected classes
Select one or more preconfigured application classes here to indicate the application(s) whose connection rate access you want to exercise control over.
Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes. For application class configuration details, see Chapter 9, "Using Application Classes".
But not in the following class—Optionally, selection application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 6 Attempt to act as a—Select server, client, or "client or server"
From the pulldown menu, select server, client, or client or server depending on the direction of the connection you are controlling.
If you are limiting a server's connection limit, select server here. If you are limiting a client connection, select client here.
Step 7 Communicating with—Select specific hosts, different hosts, or all hosts
When the rate limit set here is reached, you can determine whether all subsequent service requests are dropped or only those received or sent by a specific host. If you select a "specific" host, this indicates that the host in question exceeded the rate limit. If you select all hosts, this indicates that the sum total of to and from all hosts exceeds the limit and all hosts are blocked. Selecting the "different" hosts option would be beneficial for controlling outgoing connections. For example, if a system on your network has been infected by a network worm, you could control the worm replication by tracking how many different hosts the infected system is trying to connect to and setting a limit to those connections. If you only tracked all host connections in this case, you may cut the system off from legitimate server access, for example.
Step 8 hosts having addresses - Type in a literal network address or a reference to a network address set variable (preceded by a dollar sign). See Using the Correct Syntax, page 2-29 for a full description of proper IPv4 and IPv6 address syntax.
You can also click the Insert Network Address Set link to access a list of pre-configured network address sets. From the Insert Network Address Set link, click the New "shortcut" item to create a new network address set variable without leaving the rule page.
Note IPv6 addresses can only be used by a rule associated with a Linux or Vista rule module.
Note You can use the "short hand" symbol @local to indicate all local addresses on the agent system. Use @remote to indicate all address that are not on the local agent system. Refer to Using the Correct Syntax, page 2-29 for more information and additional shorthand symbols.
Step 9 Using these local interfaces - The default entry here is <all>, indicating all addresses. Generally, you should not have to change this. Note that you cannot enter a "literal" in this field. You must select a preconfigured variable from the Insert Network Interfaces Set link if you want to change the default here.If you want to define a local interface using a combination of interface type and network address, create a network interface set that specifies that combination.
Note <All> is the only valid setting for UNIX, Solaris, or Linux platforms.
Step 10 Over/Under a limit <100> network connections in <5> minutes
Reasonable values are entered into these fields by default. They define the number of connections that can normally be expected during a time frame from either specific hosts or all hosts.
–If you select an action type of "deny" or "terminate", and the limit is exceeded (Over) in this time frame (abnormal amount of connections that could represent an attack of the system), subsequent connection requests are dropped. (The dropped connections can be those received to/from individual "specific" hosts or to/from all hosts. This setting is configured at the bottom of the page.)
–If you configure this as an "allow" rule, you are setting a limit Under which the number of connections must remain for the subsequent connections to be explicitly allowed.
Step 11 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 12 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-4 Connection Rate Limit Rule
Data Access Control
Data access control rules are used for these purposes:
•Protecting web servers
•Protecting MSRPC and LPC interfaces
See also, Creating Data Access Control Rules
Protecting web servers
Use data access control rules on Web servers to detect clients making malformed web server requests where such requests could crash or hang the server. A malformed request could also be an attempt by an outside client to retrieve configuration information from the web server or to run exploited code on the server. This rule detects and stops such web server attacks by examining the URI portion of the HTTP request.
Note Data access control rules specifying HTTP protocol data sets are not supported for desktop versions of Windows operating systems.
An HTTP request consists of:
•the request method (a "get" or a "post")
•the request URI (Uniform Resource Identifier—This includes the URL and related request parameters and arguments)
•the HTTP version (for example, HTTP/1.0)
•the HTTP header
The Data access control rule examines patterns in the URI portion of the HTTP request. The pre-configured Data sets (see Data Sets, page 8-6) group patterns to match based upon
•functional associations of meta-characters (e.g. "(" and ")")
•examples of known classes of attacks
•Web server specific exploits
Use the data access control rule to allow or deny specified underlying network data requests for the following web servers and platforms:
•Microsoft IIS (Windows platforms, version 4.0 or higher)
•Apache (Windows and UNIX, versions 1.3, 2.0, 2.2)
Caution On Windows platforms, if you install Web server software (IIS or Apache) after you install the Cisco Security Agent on the server system, or if you have installed the Web server in a directory other than the default, you must manually install the Cisco Security Agent data filter in order to use Data access control rules on the system in question.
For Windows Vista, if you want to install Internet Information Services (IIS), you need to make sure that the
IIS Metabase and IIS 6 configuration compatibility and
ISAPI Filters features are included in the installation.
If your Web server software is already installed (in its default directory) when you install the agent on Windows, the server software is detected by the agent and the data filter capability is automatically installed with the agent.
On Solaris (Apache servers) and Linux (Apache servers), in order to use Data access control rules you must install the data filter manually after you install the Cisco Security Agent. Unlike Windows, the Solaris and Linux installations do not detect Web server software and do not install the data filter with the agent. You must always manually install it.
See
Manual Agent Data Filter Installation, page 12-8 for instructions.
Protecting MSRPC and LPC interfaces
Once the CSA MC has collected and correlated enough malicious payloads from attacks on MSRPC or LPC interfaces, it creates a signature representing the attack. The signature is associated with the @signatures token. After the signature has been distributed to the agent on a host, if a payload matches the attack signature, a data access control rule prevents the application from processing it and the attack fails.
If an MSRPC or LPC interface has been attacked numerous times and a signature can not be generated, the payloads associated with the interface under attack are associated with the @highrisk_signatures token. If a new payload is received and it is matched to the payload tags associated with the @highrisk_signatures token, a data access control rule prevents the application from processing the payload and the attack fails.
See Chapter 14, "Automatic Signature Generation" for a detailed discussion of the automatic signature generation feature.
Creating Data Access Control Rules
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as an administrator with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Data Access Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose access to data sets you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
Note If you specify an application here other than IIS, Apache, or iPlanet, this rule is ignored.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt to access these data sets: Click the Insert Data Set link to select one or more pre-configured data sets from a list. Instead of data sets, you can list the literal data strings you want to protect. (The information in this field is the same as the data you would enter in the Patterns matching field of a data set. See Data Set Pattern Matching Syntax, page 2-39 for more information.)
Step 10 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 11 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-5 Data Access Control Rule
File Access Control
Use file access control rules to limit allowable system file actions to named files or directories based on these factors:
•The action itself (Deny, Allow)
•The application performing the action (Web Browser, Mail Client)
•The operation performed (Read, Write)
Whereas file protection enforces read and write access, directory protection encompasses directory deletes, renames, and new directory creation.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select File Access Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose access to the listed files you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt the following operations —
Select either or both the Read File or Write File operations you are allowing or denying on the files named in the On any of these files box. If you want to prevent an application from opening a file for reading, select Read file. If you want to prevent an application from opening a file for writing, select Write file.
For directory protection, the "Write" actions you are allowing or denying are Create, Delete, and Rename. Refer to File and Directory Protection, page 2-34 for more information.
Caution Directory protection ignores the file portion of the specified path and only matches the directory portion of the path. If the directory portion is not well specified, the protection will be overly broad. For example, if you select to protect a directory in a deny rule and enter the directory path as follows:
**\Program Files\**Outlook.exe, then no directories can be modified under Program Files. That is an overly broad protection to specify and would likely result in system instability. If you choose to protect directories, be sure to get very specific in your path string and understand the resulting behavior.
Step 10 In the On any of these files area, click the Insert File Set link to enter a pre-configured file set here. Instead of file sets, you can list the literal files you want to protect, using the file paths (including wildcards).
For information on entering file path literals here rather than using pre-configured File Sets, see Directory and Filename Syntax Requirements, page 2-30.
For local system paths, you must specify the disk drive. You can use a wildcard designation. When protecting directory creates, in particular, you should note that directory creation applies to an exact directory path match, but directory write and rename protection applies to all directories explicitly named in a path. If a directory name is completely wildcarded \**\, no protections exist for that particular component of the directory. For example:
Windows
|
*:\Program Files\winnt\*
or @system\** (this indicates all files below the system directory)
|
UNIX
|
/etc/passwd
Caution Symbolic Links and Hard Links: For UNIX, if you create a File access control rule to protect a symbolic link, ONLY that symbolic link is protected. The underlying resource, unless also specified, is NOT protected. For example, a File access control rule written for /etc/hosts does not protect /etc/inet/hosts. Similarly, a File access control rule written for /etc/inet/hosts does not protect /etc/hosts. If you want to protect a symbolic link and its underlying resource, both must be specified in the rule. FACLs that deny users Read access have no effect on symbolic links. We purposefully ignore the option to "deny reading contents of the symbolic link" to avoid multiple error messages on commands such as "ls". Also note that on UNIX systems, if you attempt to create a hard link to an agent-protected file, that action is seen as a write attempt on the file.
|
For network machines (Windows only), enter
\\<machine name>\<share>\<path>\<filename>
For example: \\Backup_Server\finance\records\database.db
You can enter more than one file path, but each entry must appear on its own line. For File Set configuration details, see page 8-9. By default, this field has a <none> entry indicating no files. When you click inside this field, the <none> disappears so that you can enter your own file restrictions.
Caution If you are using file path literals, you should refer to Using the Correct Syntax. When entering file path literals in File access control rules, the entry
c:\winnt will allow actions on files in that directory, but it will not allow new files to be saved in the winnt directory and it will not allow file deletions. You must enter
c:\winnt\* to include the protection of existing files within that directory in rule restrictions.
Note Use @dynamic in the File set text field to indicate all files that have been quarantined by CSA MC as a result of correlated email worm events, correlated virus scanner log messages, or files that were added manually by the administrator. This list updates automatically (dynamically) as logged quarantined files are received.
To view the files that are added to the dynamically quarantined files list and to manually add files to be quarantined, click the dynamically quarantined files link on the Event Correlation page. See Manage Dynamically Quarantined Files and IP Addresses, page 7-7 for more information.
Step 11 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 12 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-6 File Access Control Rule
Network Access Control
Use network access control rules to control access to specified network services and network addresses. You can also use this rule type to listen for applications attempting to offer unknown or not sanctioned services.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Network Access Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more preconfigured application classes here to indicate the application(s) whose access to the listed services and addresses you want to exercise control over. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt to act as a < > for network service - Select server or client or both, or select listener
•From the pulldown menu, select server, client, client or server, or listener (see page 22 for more information on the listener option) depending on the direction or type of connection you are controlling or listening for.
If you are limiting a server's contact with clients, select server here and enter the client(s) address in the host addresses field. If you are limiting a client's contact with a server, select client here and enter the server(s) address in the host addresses field.
•for network services
Enter the literal protocol/port number combination for the service you want to control access to or click the Insert Network Service link to enter a pre-configured network service variable here. When you click this link, a list of the Network Service Variables you've configured appears here, allowing you to select one or more. See Network Services Syntax, page 2-37 for more information about entering protocol/port number combinations.
This field refers to either a server providing this service or a client accessing this service. For Network Service configuration details, see page 8-17.
Step 10 Communicating with host addresses
Enter the literal network address(es) for the client/servers you want to control access to or click the Insert Network Address Set link to enter a pre-configured network address set variable here. See Network Address Set Syntax Requirements, page 2-35 for a full description of proper IPv4 and IPv6 address syntax.
If you selected server in the previous pulldown list, you enter client addresses here. If you select client in the previous pulldown list, you enter server addresses here. Note that you can use Network Address Set variables.
Note A NACL rule must be associated with a Vista or Linux rule module to accept IPv6 address literals and network address sets including IPv6 addresses.
You also use the @local token in Network Address Sets and in Network Access Control rules to indicate all local addresses on the agent system in question. You would want to use this if you are allowing different applications on a single system to talk to each other without opening these applications up to network access. Refer to Token notation for network address sets, page 2-37 for more valid tokens that can be used in this rule type.
Step 11 Using these local interfaces
The default entry here is <all>, indicating all addresses. Generally, you should not have to change this. Note that you cannot enter a "literal" in this field. Otherwise, you can click the Insert Network Interfaces Set link to enter a pre-configured network interface set variable here. Note that you cannot enter a "literal" network interface value in this field. You must select a pre-configured variable from the Insert Network Interfaces Set link if you want to change the default value. If you want to define a local interface using a combination of interface type and network address, create a network interface set that specifies that combination.
Note <All> is the only valid setting for UNIX, Solaris, or Linux platforms.
Step 12 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 13 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Note No network access control rule denial events are logged for any UDP port resulting from multicast packet signals. (If a collection of hosts have the same network access control rule and a broadcast such as UDP/138 were denied, then event messages would inundate CSA MC.)
Note When the system accepts a network connection on behalf on an application, the system requires an immediate answer to allow or deny the connection. Therefore, resource requests which trigger network access control server queries will immediately choose the query default. The user is still queried and the response will be cached for future connections.
What is the "listener" option for?
You can use the listener option in a Network access control rule to indicate what applications have the ability to be a server before they are allowed to accept a server connection. This is in contrast to the "server" option which offers real-time per connection control. The listener option can be used in a monitoring capacity to reveal any applications that are attempting to offer a network service. For example, if a system is already infected with a Trojan, that Trojan may be listening on a high numbered port for a network server connection. A NACL listener rule would detect this occurring before a server connection is achieved. You could then craft a subsequent NACL rule to deny the server connection.
Figure 6-7 Network Access Control Rule
Network Shield Rule
The Network shield rule provides network protocol stack hardening capabilities.
Note The information provided in this manual, in this section especially, assumes a basic knowledge of TCP/IP. A good source for further reading on the topic is the book Internetworking with TCP/IP, Douglas R. Comer and David L. Stevens, Prentice Hall, Inc.
Note Network shield rules are not enforced for agents using IPv6 addresses except where noted.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Network Shield from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action—(Note that only Priority Deny, Priority Allow, Deny, Monitor, and Set action types are available for this rule. You can choose to add the system process to the Processes communicating with Untrusted Hosts application class which causes the remote host IP address to be sent to the MC for global correlation. This may result in the address being added to the @dynamic address list for quarantining. Also see Correlation, page 7-5 for details on quarantining IP addresses.)
Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Options and Precedence, page 5-13.
Note Because IP addresses can be spoofed, we don't recommend using this capability for this rule type. It is more applicable for NACL-based rules where you are sure you are communicating with the address. (i.e. an established TCP connection.)
Step 7 and
•Log—Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules—Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works. See Rules: Manipulating Precedence, page 5-16 for details.
Step 8 when detecting
(Select one or more of the checkboxes described here. Please note any address and/or state condition restrictions that are called out beside each check.)
Caution You cannot use network shield rules in rule modules that have user state conditions set. If you attempt to attach a user state to a rule module that contains a network shield rule, you will be notified of a configuration error.
IP Security checks
•Invalid IP header
Enabling this feature causes the Cisco Security Agent to perform an integrity check on the IP packet header. This includes performing a consistency check on the IP header, on the length of the IP header, and on the number of bytes in the packet. If you configure this as a Deny rule, the following occurs: if any of these checks fail, the packet is dropped, if an IP checksum fails, the packet is dropped, IP options and IP fragments are validated as well and dropped if they are found to be invalid. (This defeats attacks such as Teardrop, Boink, and Ping of Death.)
•Invalid IP address
IP addresses are determined to be invalid for several reasons: if the source address is a multicast address, if the TCP connection is to a broadcast address. You can select this checkbox as part of a Deny rule to protect against these types of attacks.
•Source routed packet
This detects IP options which control explicit routing instructions for packets. With IP source routing (an IP header option) the originator of a packet can try to partially or completely control the path through the network to the destination.
•Trace route
This detects the mapping of network topology via trace route.
•IPv6 packets on <Operating System>
CSA provides IPv6 support for Network Access Control rules on Linux and Vista. We do not support IPv6 Network Access Control rules for Solaris, Windows 2000, Windows XP, and Windows 2003 platforms. Until these platforms do support IPv6 Network Access Control rules, this feature provides an administrator with a control to prevent end users from communicating with IPv6 addresses.
If you configure this rule with a Deny enforcement action, IPv6 traffic to Solaris, Windows 2000, Windows XP, and Windows 2003 platforms is dropped. This rule option is not enforced for all other operating systems.
Transport Security checks
•Invalid TCP/UDP/ICMP header
This check ensures that transport headers are the proper length and that they are consistent (have enough data in the packet for them to fit). This includes verifying that certain fields have valid values and that certain combinations of TCP flags are legal. This defeats attacks such as a Christmas Tree scan.
•TCP SYN floods
SYN flooding is a type of denial of service attack. It occurs when a TCP/IP connection request is received from a return address that is not in use (i.e. a non-existent host for a spoofed address) resulting in a half open connection. An abundance of half open states on a server can prevent legitimate connections from being established. Detecting and preventing SYN floods stops this attack from succeeding.
Servers that are external to your network and not protected by a firewall should be protected against SYN floods. Firewalls generally provide this protection.
Note If you enable the "TCP SYN floods" and the "TCP blind session spoofing attempts" checkboxes, you cannot enter address restrictions into the address field for this rule. You must use all addresses.
•TCP blind session spoofing attempts
If you configure this as a Deny rule, this check causes agents to make TCP sequence numbers unpredictable.
A server accepting connections using predictable TCP sequence numbers may be tricked into accepting a connection from a malicious source that is spoofing a trusted host. This prevents that vulnerability.
Note This rule option is not available for UNIX policies as the UNIX OS already provides this protection.
Note This rule option is not available for Windows Vista.
Note If you make any changes to the "TCP blind session spoofing attempts" feature, these changes are not enforced until after the agent system(s) is rebooted.
•TCP/UDP port scan
Port scanning is a common method for finding weaknesses at a site by determining what network services are being run. An attacker attempts to connect to port after port on a target system, mapping ports to identify network services and machine type vulnerabilities. Configure this rule to log an event when an attempt is made to scan the system for an open port. Information is also gathered on the number of different source IP addresses perpetrating the scan and it reveals the source. In most cases, you should apply port scan detection to servers and end-user systems in your enterprise.
Configure this rule as a Deny rule to prevent unauthorized port scans, effectively cloaking a system on the network. Denying port scans causes a system to not respond to connectivity tests and to not respond to service requests with connectivity error messages.
A system generally sends out error messages when a remote machine sends a request for a service which is not running on the system. Often, this is how remote machines locate other systems and obtain network information about the system in an attempt to target it for an attack. By not responding, this prevents both UDP and TCP-based port scans of the system and basically hides it on the network.
If you are running an allowed service on a system and you are denying port scans, connection requests to this service are honored and your machine is viewable for the service you're offering.
Note If you select the network scans correlation checkbox in the Global Event Correlation page (see Correlation, page 7-5), when scans are detected and denied across several machines, CSA MC correlates these events and generates an additional event to warn of this correlation. Note that this correlation only occurs when Deny rules are triggered.
•ICMP ping message
This check works similar to the TCP/UDP port scan feature, but for ping scans. See the port scan description for information.
•ICMP configuration message
If you configure this rule as a Deny, this feature restricts messages which can change the configuration of a machine. For example, a redirect can be used to cause routing tables to be updated.
•ICMP information message
Some ICMP messages may be used to gather information about a machine in an attempt to attack it. This data, when obtained, can be used to gather system information which can be used to exploit the system. If you configure this rule as a Deny, this feature restricts messages which report back on system or network configuration.
•ICMP covert channel
Configuring this rule as a Deny, causes agents to drop unsolicited echo responses.
The Cisco Security Agent validates that the echo response data matches the echo request data. This way, ping cannot be used as a transport for communications.
•Malicious packet
Configuring this rule as a Deny causes agents to block packets which are technically legal but are known exploits against protocol stacks (e.g. UDP packet storm or RF poison).
•TCP Chimney Offload
Disables the Microsoft TCP Chimney Offload feature if it is in use. This allows CSA to enforce the following network shield options.
–IP Security Checks
–Invalid TCP Header
–TCP blind session spoofing attempt
–Malicious packet
Note If you make any changes to the "TCP Chimney Offload" feature, these changes are not enforced until after the agent system(s) is rebooted.
System Startup Security checks
•Unrestricted network connectivity during boot
This rule option is not available for UNIX policies. This rule option is available for agents running on Vista communicating with IPv4 and IPv6 addresses. The rule option is available for Windows 2000, Windows XP, and Windows 2003 operating systems communicating with IPv4 addresses.
Configuring this feature as a Deny, prevents non-essential network connections during system startup. This check is automatically disabled when the agent service starts and policies (including those which govern allowed network connections) are enforced. This protects the system from network-based attacks at boot-time before the agent service has started.
Note If you enable the Unrestricted network connectivity during boot checkbox, you cannot enter address restrictions into the address field for this rule. You must use all addresses.
Note You cannot use a rule that has the Unrestricted network connectivity during boot checkbox selected in policies with rule modules that have system and/or user state conditions set.
Step 9 and Communicating with host addresses - Type in a literal network address or a reference to a network address set variable (preceded by a dollar sign). See Network Address Set Syntax Requirements, page 2-35 for a full description of proper IPv4 and IPv6 address syntax.
You can also click the Insert Network Address Set link to access a list of pre-configured network address sets. From the Insert Network Address Set link, click the New "shortcut" item to create a new network address set variable without leaving the rule page.
Note IPv6 addresses can only be used by a rule associated with a Vista or Linux rule module.
Note You can use the "short hand" symbol @local to indicate all local addresses on the agent system. Use @remote to indicate all address that are not on the local agent system. Refer to Token notation for network address sets, page 2-37 for more information and additional shorthand symbols.
Step 10 Using these local interfaces
By default, this field indicates all local addresses on the agent system. You would want to use this to identify specific network interfaces, if necessary. Note that you cannot enter a "literal" in this field. You must select a preconfigured variable from the Insert Network Interfaces Set link if you want to change the default here. If you want to define a local interface using a combination of interface type and network address, create a network interface set that specifies that combination.
Note <All> is the only valid setting for UNIX, Solaris, or Linux platforms.
Step 11 Click Save when finished.
Figure 6-8 Network Shield Rule
Windows Only Rules
The following rules are only available for Windows Rule Modules.
Clipboard Access Control
Use the clipboard access control rule to configure permissions for which applications can access information that is written to the clipboard by other applications. When writing security policies, you may want to protect clipboard information from being accessed by other applications or network processes. To fully protect this information, you must consider preventing other applications from accessing protected information that may have been written to the clipboard.
This rule works in the following manner. When a process belonging to an application class specified in a clipboard rule writes to the clipboard, only processes which match the second specified application classes are allowed to read that data from the clipboard.
Note You should note that when you're writing clipboard rules for applications, if a process writes to the clipboard and then exits, the clipboard data written by that process becomes inaccessible to all applications. The initial process writing to the clipboard must not exit for the clipboard data to be accessible to other applications per the clipboard access control rule. This rule type is implemented in this way to prevent certain types of data loss from occurring.
One scenario in which you may want to use this rule is as follows. You could prevent applications from accessing clipboard data that is written by applications which are categorized as "sensitive data applications."
These instructions are a continuation of Configuring Rule Modules, page 5-2.
Step 1 To add rules to your module, expand the rules area of the rule module and click the Add button. A pop-up list of the available rule types appears.
Step 2 Select the Clipboard access control rule. This takes you to the configuration view for this rule type. See Figure 6-9.
Step 3 Enter the following information for the rule:
•Description—Enter a description of this rule. This description appears in the list view for the module.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the module and it will not be distributed to groups
Step 4 Take the following action—Select an action type from the pulldown list.
For further details on rule action types, see Rules: Action Options and Precedence, page 5-13.
Step 5 and
•Log—Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules—Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works. See Rules: Manipulating Precedence, page 5-16 for details.
Step 6 When
•Applications in any of the following selected classes—Select one or more preconfigured application classes here to indicate the application(s) whose data you want to exercise control over. Note that the entry <All Applications> is selected by default. You can use this default or you can unselect it and create your own application classes.
When your rule is configured, currently selected application classes appear at the top of the list.
•But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. For example, if you only want a subset of applications in the selected application class to apply to this rule (i.e. dynamic or behavioral based tags that may get widely applied via a dynamic application class builder rules) you would use the But not field to select those application exclusions. Note that the entry <None> is selected by default.
Step 7 attempt to read clipboard data written by:
•Applications in any of the following selected classes—This second applications field indicates the application classes that you do not want to read clipboard data which has been written by selected applications above.
If you selected "All Applications" in the top application field, you cannot select All Applications in this second field.
•But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
Step 8 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 9 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Note There is a built-in application class that accessible to only the Clipboard access control rule. Processes performing a Print Screen is a pre-configured application class intended to identify processes performing screen captures. You could use this application class to include print screen applications in a rule preventing clipboard access of print screen data.
Figure 6-9 Clipboard Access Control Rule
COM Component Access Control
Use COM component access control rules to allow or deny applications from accessing specified COM components. COM is the Microsoft Component Object Model, the technology that allows objects to interact across process and machine boundaries as easily as within a single process. Each of the Microsoft Office applications (Word, Excel, Powerpoint, etc.) exposes an "Application" COM component which can be used to create macros or utility scripts. While this is useful functionality, it can be used maliciously by an inadvertently downloaded Visual Basic script.
An example would be the Mydoom virus, which propagated by using the "Outlook.Application" COM component to send itself to each entry in the local address book. Using the COM component access control rule, you can protect specific COM components. For example, you could create a rule which limits access to Office components (Word.*, Outlook.*, Excel.*, etc.)only to the Office applications themselves. Non-Office applications (such as the Visual Basic scripting engine) would therefore be denied access to these components.
Note CSA MC provides a COM component import utility which installs with each Cisco Security Agent. Running this utility extracts all COM component PROGID's and CLSID's for software running on the system in question. See Using the COM Extract Utility, page 12-8 for information.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select COM component access control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose access to the COM Component(s) you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt to access a COM component....matching any of the following component sets
Click the Insert COM Component link to select one or more pre-configured COM component sets for this rule. If you do not want to use a COM component set variable, using the correct syntax, enter a literal PROGID or CLSID (one per line) here. CSA MC provides a utility for extracting PROGID and CLSID information from systems running agent software. See Using the COM Extract Utility, page 12-8 for instructions.
PROGID's, use the following syntax:
When entering CLSID's (uppercase hexadecimals) using the following syntax, you must include the brackets shown here:
{000209FF-0000-0000-C000-000000000046}
Step 10 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 11 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-10 COM Component Access Control Rule
File Version Control
Use the File version control rule to control the software versions of applications users can run on their systems. For example, if there is a known security hole in one or more versions of a particular application, this rule would prevent those specific versions from running, but would allow any versions not included in this rule to run unimpeded.
One particular example where this type of rule would be beneficial is in the case of Microsoft Security Bulletin (MS01-020). This bulletin states the following: "Because HTML e-mail messages are Web pages, Internet Explorer can render them and open binary attachments in a way that is appropriate to their MIME type. However, there is a flaw in the type of processing that is specified for certain unusual MIME types. If a malicious user creates an HTML e-mail message that contains an attachment that can be run and then modifies the MIME header information to specify that the attachment is one of the unusual MIME types that Internet Explorer handles incorrectly, Internet Explorer may run the attachment automatically when it renders the e-mail message."
Microsoft has a patch to correct this security problem, but the patch is only available for Internet Explorer 5.01 Service Pack 1 and IE 5.5. If users are running an earlier version of IE, they must upgrade to 5.01 or 5.5 and install the correct service packs and patches to correct the problem. Therefore, earlier versions of IE contain an unfixable security problem and you will want to prevent users from running these versions. The following configuration information uses the IE security bulletin as an example.
Note Users can get around a File version control rule by copying the file in question to a different file name. Therefore you must assume that users are working in cooperation with you for these rule types to be successful. You could also create a File access control rule to prevent users from changing the application file name in question.
n only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select File Version Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose access to the defined file you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt execution of the following
Enter the File you are prohibiting (You will enter the exact version in the next field.) This field accepts file entries for Outlook.Application
, {000209FF-0000-0000-C000-000000000046}
, and .exe files. Enter just the file name here. No path is required.
For example: .dll
You cannot use wildcard entries in this field.
Step 10 with version within these Version ranges
Enter the version or version range (using a dash to indicate range) of the file you entered in the previous field.
For example: .ocx
You can enter multiple, nonconsecutive ranges by entering versions on separate lines in this field.
To locate the version of a file (*.exe, *.dll, or *.ocx), select the file and right click. Select Properties. Click the Version tab. The File version is normally 4 values separated by dots.
Note When entering version numbers for Microsoft applications, refer to the Microsoft web site. Application version numbers accessible from the application itself sometimes correspond to slightly different version numbers in Microsoft version charts. For example, Microsoft Article number Q164539 was used to determine the version numbers for this File version control rule.
Step 11 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 12 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-11 File Version Control Rule
Kernel Protection
Use the Kernel protection rule to prevent unauthorized access to the operating system. In effect, this rule prevents drivers from dynamically loading after system startup. You can specify exceptions to this rule for authorized drivers that you are allowing to load any time after the system is finished booting.
You can also use this rule to only detect unauthorized access to or modification of the operating system at any time. This rule also detects if a system was booted in a non-standard, insecure manner.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Kernel Protection from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 when
•Modules load after system startup
The default here is <none>. You can use this rule type to prevent drivers from dynamically loading after system startup. You can also specify exceptions to this rule for authorized drivers that you are allowing to load any time after the system is finished booting.
•Modules modify kernel functionality
You should only create Allow exceptions for actions you believe are safe. For example, virus-scanners and kernel debuggers might legitimately trigger this rule. Enter module data in the following edit fields:
–Included Module hashes
By default, this field contains <all>. Enter hashes and/or drivers that identify kernel modules (e.g. drivers) into this field in the following format: 20 character hash\file system path\driver name. You can use wildcards for entries, as well. You can also use the wizard from the event in question to enter the module hash and driver information here. Some examples of valid entries are as follows:
*\**\system32\Drivers\uphcleanhlp.sys
ae45e23b45093dffa899\**\uphcleanhlp.sys
–Included Code patterns
By default, this field contains <all> . The wizard enters code patterns (not inside any module) into this field.
•The previous detected boot was insecure
When a system has previously booted in a non-standard manner, selecting this checkbox causes a message to be sent to the event log. A boot is considered standard if the system was booted from the primary hard disk. Any other boot type, for example, booting from a peripheral device (CD ROM) or a hard disk that is not the primary, is considered non-standard. A non-standard boot may be considered suspicious. (e.g., This is one way of circumventing the Cisco Security Agent and introducing a Trojan to a system.)
This check box works in conjunction with a particular type of compatible BIOS on compliant systems. The compatible BIOS detects a non-standard boot and, on the next normal boot, if you have this checkbox selected, a message is sent to the MC which logs the insecure boot detection. (If a Host is running a BIOS that supports this insecure boot detection feature, the individual Host details page will indicate this. From the CSA MC menu bar, click Systems>Hosts. Then click on the link for an individual host.The Host Status section includes a category named "BIOS supported boot detection".)
Note A Safe Mode boot also falls into this insecure boot category since the Cisco Security Agent provides no security in Safe Mode. Compatible BIOS is not required for a Safe Mode boot detection.
–Included boot patterns
By default, this field contains <all> . You can use provided tokens here to only detect certain boot types as insecure or to exclude a particular boot type from the detection. Available tokens are:
@fixed - This indicates a fixed hard disk that is not the primary disk. (Compatible BIOS is required to detect this.)
@network - This indicates all network shares. (Compatible BIOS is required to detect this.)
@removable - This indicates all removable media. That includes, floppies, CDs, zip drives, etc. (Compatible BIOS is required to detect this.)
@safemode - This indicates the detection of a system having booted in any debug mode in which the agent does not load. (Detecting this is not BIOS dependent.)
•Any application reads a file classified as a virus during system startup
This option allows the system to be protected if an application reads a file classified as a virus during boot time. CSA may have classified a file with a virus based on a virus signature or on its behavior. Being able to turn the option "on" or "off" allows you to see how the rule would protect your system while running in test mode.
Step 9 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 10 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Note Certain types of keystroke loggers deploy kernel level drivers. When this is the case, the Kernel protection rule will catch this type of keystroke logger. Additionally, you should use the System API Control Rule to catch other types of keystroke loggers.
Figure 6-12 Kernel Protection Rule
NT Event Log
Use the NT Event log rule to have specified NT Event Log items appear in the CSA MC Event Log for selected groups.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select NT Event Log from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Log events from the event log
•Include events matching the following—Select this radio button to specify the criteria for NT Event Log entries which you want to appear in the CSA MC Event Log.
•Include all events except those matching the following—Select this radio button to specify the criteria for NT Event Log entries which you do not want to appear in the CSA MC Event Log. (All criteria not specified here will appear in the CSA MC Event Log.)
Note You can configure CSA MC to correlate NT event types logged across multiple systems. You can also correlate NT events received from virus scanners running on agent systems and quarantine contaminated files.
Step 7 Criteria (You should select at least one for the rule to have any effect.)
•Event Log Type—Select one or more checkboxes here to indicate which NT Event Log entries you want to appear (first radio button above) or which entries you want to not appear (second radio button above) in CSA MC Event Logs.
The choices are—System, Application, Security
•Event Source—In the text field, enter (one per line) event source parameters you want to filter by.
The event source is the software that logged the event, which can be either an application name, such as iexplore.exe, or a component of the system or of a large application, such as a driver name. For example, 0-5.00.3314.2100
5.00.3314.2100-5.50.4522.1800 indicates the EtherLink II driver.
•Event Severity (Type)—Select one or more checkboxes to filter the viewing of events according to severity. If you select no checkboxes, all severity levels are included in the rule.
The choices are—Information, Warning, Error, Audit Success, Audit Failure
•Event Code (Event ID)—In the text field, enter (one per line) event code parameters you want to filter by.
The event code is the number identifying the particular event type. For example, 6005 is the ID of the event that occurs when the Event log service is started. You can find the event IDs for Windows security events by searching for the following articles on the Microsoft web site: Q174074, Q299475, Q301677, and Q947226.
Step 8 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Note To receive messages logged by Norton AntiVirus and for global correlation, select the Application checkbox and enter SQL Server in the Event Source edit box.
Figure 6-13 NT Event Log Rule
Printer access control
Use this rule type to control which applications are allowed to send data to the printer. For example, you can use this rule to prevent applications categorized as "sensitive data applications" from printing.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Printer Access Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose ability to print you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
•Attempt to print.
Step 9 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 10 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-14 Printer Access Control rule
Registry Access Control
Use registry access control rules to allow or deny applications from writing to specified registry keys.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Registry Access Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose access to the Windows registry you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt to write to any of these registry entries
Click the Insert Registry Set link to select one or more pre-configured registry sets for this rule. See Included Registry Sets, page 8-27 for details on included operating system registry values.
Note You cannot enter registry literals here. You must create a registry set variable if you are not using pre-configured registry sets.
Step 10 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 11 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-15 Registry Access Control Rule
Scan Event Log
Scan Event log rules can be triggered after CSA performs data scans, virus scans, or digital signature checks. Here are examples of how scan event log rules can be used:
Data Scans and Virus Scans
1. An application has performed some action that triggered a virus scan or data scan; for example, an application has opened or closed a file.
2. As a result of the virus or data scan, a file is tagged with a data scan or virus scan tag.
3. As a result of gaining a data tag or virus tag, the scan event log rule takes some action.
Digital Signature Checks
1. An application has performed some action that triggered a digital signature check; for example, the application has just been downloaded over a network connection and it is being opened for reading. This is common when downloading and installing applications from the Internet.
2. CSA extracts the digital signature from the application and tags the application with the digital signature.
3. As a result of gaining a digital signature tag, the scan event log rule takes some action.
Here are some of the actions that the scan event log rule could take and an example of how that action could be used. There are many other uses for the actions listed here.
•A Monitoring action will send an event to the CSA MC. You could use a monitor to ensure that there is an event to include in a report.
•A Notify User action sends a message to users. The message could be used to inform users that they are working with sensitive data. It may also be used to require them to justify their actions. Data Justification Details reports are derived from Notify User events.
•A Set action could be used to delete a file infected with a virus or mark a downloaded file as "trusted" if the digital signature is from a trusted source.
•The Add or Remove an Application from an Application Class action could be used to identify an application that has read proprietary information.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Scan Event Log Rule from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more application classes here to indicate the application(s) that perform some action that causes a data scan or antivirus scan. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
Note When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Perform an operation causing a: You can select any or all of these checkboxes: Data Scan, Virus Scan, or Digital Signature Check.
Step 10 Where the scan results match any of these file sets:
As a result of the virus or data scan, a file was tagged and represented by the file set that you specify here.
Click the Insert File Set link to specify one or more pre-configured file sets from the menu that appears. You can also click the blue New link, in the Insert File Set list box, in order to create a new File set for this rule.
The file sets you select or create should specify a particular data scanning tag or virus scanning tag, or specify <all> tags in the Content Matching field of the file set.
Step 11 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 12 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-16 Scan Event Log
Service Restart
Use the Service restart rule to have the agent restart Windows services that have gone down on a system or are simply not responding to service requests.
Note System Restart rules ignore system states. They are triggered regardless of system state or change in system state.
Note The Service Restart rule is different from the Windows configurable restart service. Windows only restarts processes that have gone away. The agent restarts a process that experiences a failure of any kind.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Service Restart from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
•Log—Enable this checkbox to turn logging on for this rule.
Step 6 Restart the following service
Enter a service here you want the agent to automatically restart should it go down for any reason. When entering services here, use the syntax found in the following locations:
•On Windows Vista, Windows XP, Windows 2003 and 2000: Start>Settings>Control Panel>Administrative Tools>Services "Name" field
Step 7 When
Select one or both of the following checkboxes.
•Not responding to Service Control Manager: The Windows Service Control Manager checks the status of system services and recognizes when a service is not responding. Selecting this checkbox causes the Cisco Security Agent to restart the specified service when it does not respond to the Windows Service Control Manager.
•Not responding to network requests for service: Select this checkbox and then choose a network service (such as HTTP) from the available pulldown list. The Cisco Security Agent will monitor whether the system is responding to network requests for the protocols in the network service. If not, it will restart the Windows service specified in this rule.
Step 8 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-17 Service Restart Rule
Sniffer and Protocol Detection
Note Sniffer and protocol detection is not supported for agents running on Windows Vista systems.
Use the Sniffer and protocol detection rule to cause an event to be logged when non-IP protocols and packet sniffer programs are detected running on systems.
Non-IP protocols, such as IPX, AppleTalk, and NetBEUI, are used to provide distributed computing workgroup functions between server and clients and/or sharing between peer clients.
A packet sniffer (also controlled by this rule type) is a program that monitors and analyzes network traffic. Using this information, a network manager can troubleshoot network problems. A sniffer can also be used illegitimately to capture data being transmitted on a network. Sensitive information such as login names and passwords can be extracted from this data and used to break into systems.
The Sniffer and protocol detection rule is a monitoring tool. By adding this rule to a policy, you are causing an event to be logged when any non-IP protocols and packet sniffer programs are detected running on systems which receive this rule.
Note You can use the Sniffer and protocol detection rule page to configure exceptions to this monitoring rule. If you select any non-IP protocols or enter any packet sniffer programs here, you are allowing them to run on systems without generating events. Only non-IP protocols and packet sniffer programs which you explicitly exclude as part of the rule will not cause events to be logged. Otherwise, all are monitored when you add this rule to a policy.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Sniffer and Protocol Detection from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Select one or more preconfigured Standard protocols here to be excluded as part of this rule. The protocols you select here are the only non-IP protocols that will not generate events when they are detected.
If the non-IP protocol(s) you want to exclude are not included in the Standard Protocols list, enter your own in the Non-standard protocols and packet sniffers text field. By default, TCP/IP Protocol is already excluded.
This is also where you should enter any packet sniffer programs you want to exclude from this rule. (Find the names for these programs in Cisco Security Agent log files or in system registries.) For example, enter:
Elnkii
In this example, Windump is the application. The libcap packet capture driver registers using the name PacketDriver.
Step 7 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Note If you have multiple sniffer and protocol detection rules, the exceptions are combined.
Figure 6-18 Sniffer and Protocol Detection Rule
System API Control Rule
The System API control rule detects several forms of malicious programming code that is installed on a system by an unsuspecting user either thinking that he or she is running some other type of program, or as a result of some other activity such as reading an attachment to an email message. Once installed, these malicious programs (for example, Trojans) may allow others to access and virtually take over a system across the network. Other errant programs may be set up to automatically send mail messages or other types of network traffic (including system passwords) while the system owner is unaware of what is occurring. See Figure 6-19.
Note This rule type is not available for UNIX policies. Refer to the Buffer overflow rule information on page 59 for similar UNIX functionality.
It could be useful, especially in the case of server systems, to use a service restart rule in conjunction with a System API control rule. This way, if you are forced to press the Terminate button if queried by a triggered rule and you subsequently terminate the application in question, a service restart rule will cause the application to automatically restart. See Service Restart for more information.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select System API Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more preconfigured application classes here to indicate the application(s) whose access to the listed services and addresses you want to exercise control over. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 targeting (where applicable)
The "targeting" application class selections are only applicable to following checkbox items on this page: Inject code into other applications; Write memory owned by other applications. A targeting option is available for these items because these actions (injecting code and writing memory) involve two or more parties. These parties include the one that is initiating the action and the process(es) being affected. Providing an optional targeting selection in these cases for choosing particular application classes allows for further configuration granularity.
Step 10 In the Attempt the following operations area, select the checkbox next to action you want to regulate.
System Information Checks
–Access local configuration information
Detect applications that attempt to read system registry settings.
–Access Security Account Manager
Detect applications that attempt to steal local system passwords.
System Monitoring Checks
–Trap keystrokes
Detect applications that attempt to capture system keystrokes.
See Kernel Protection for additional information.
–Monitor media devices
This checkbox lets you control which applications can monitor media devices on the system. Media device "inputs" can be exploited by Trojans which can, for example, turn on the microphone on a system and covertly listen to a conversation.
Patterns to be included: Use the Wizard from the Event log message in question to include particular devices in a System API "allow" rule. You must specify media devices as "device\port". For example, Norton AntiVirus.
Note Monitor media devices is not supported for parallel port media devices on any operating system.
Note A System API Control rule that allows or denies applications from monitoring media devices is supported for Windows Vista. The Vista operating system passes all audio device access through one process: audiodg.exe. Therefore, any System API Control rule, written to control media device access becomes a blanket allow or a blanket deny for all audio processes because CSA is only able to enforce the rule on "audiodg.exe."
System Modification Checks
–Access physical memory
Detect applications that attempt to directly access physical memory while bypassing virtual memory restrictions.
–Download and invoke ActiveX controls
Detect applications that download ActiveX controls and immediately attempt to execute them.
This functionality limits applications from downloading ActiveX controls (signed and unsigned). This type of behavior is generally typical of a web browser and sites that require the downloading of ActiveX can trigger this rule. Note that this rule may be unnecessary if system web browser settings are configured with a "High" security level that would restrict the downloading of ActiveX controls.
–Inject code into other applications
Detect applications that are attempting to write code to space owned by other applications. e.g. injecting a malicious .dll into a privileged process.
–Write memory owned by other applications
Detect applications that attempt to interfere with the memory space of other applications or detect Trojans attempting to hide in another executable to escape detection and gain permissions to access other resources.
Atypical System Behavior Checks
–Access system functions from code executing in data or stack space
Although this behavior is sometimes exhibited by downloaded/executable content (e.g. license checking software), this may be symptomatic of a buffer overflow attack.
Additionally, you can use this Access system functions checkbox in combination with a "Set - Data Payload" action type to generate signatures to catch buffer overflow based attacks.
Patterns to be included: Use the Wizard from the Event log message in question to include a particular pattern in a System API "allow" rule when you are seeing buffer overflow events you believe are harmless.
–Handle exceptions
Detect processes running exception handling routines. This typically occurs due to bugs in the application software. But this may be a sign of an attack if this occurs with an application that does not generally exhibit this behavior.
Additionally, you can use this Handle exceptions checkbox in combination with a "Set - Data Payload" action type to catch MSRPC or LPC attacks and generating a signature from that attack type.
Patterns to be included: Use the Wizard from the Event log message in question to create an exception to exclude a particular pattern in a System API "allow" rule when you are seeing exception handling events that you think are benign. Entering patterns here for exclusion will prevent CSA MC from logging further messages for this pattern.
–Invoke unusual system calls
Use this checkbox to detect processes invoking system calls that are rarely used. In normal system operation, many system calls are either never used or may only be used infrequently by a specific system application performing a service. Attempting to exploit undetected flaws in these unusual system calls is common attack vector for malware.
Patterns to be included: Use the Wizard from the Event log message in question to include a particular module in a System API "allow" rule when you are seeing events you believe are harmless.
Step 11 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 12 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-19 System API Control Rule
UNIX Only Rules
The following rules are only available for UNIX Rule Modules.
Buffer Overflow Rule
A buffer overflow is what happens when two conditions are met: Firstly, an application is coded in a manner such that it trusts that all users of that application will provide the application with reasonable and expected data. Secondly, the application is provided larger quantities of data than it is capable of correctly handling. When these events come together, an application can behave in unexpected and unintentional ways.
For applications with special privileges, this can result in external users gaining access to machine resources and privileges which they normally would not be able to acquire. In other words, a hostile, network-based attack on a privileged, trusted application via buffer overflows can result in undesirable parties gaining access to your system.
In the case of UNIX operating systems, there are three distinct types of buffer overruns which can occur, based upon the type of memory space involved: stack, data, and heap.
•Stack space is used to store data and information which is local to the piece of code currently being executed in an application, and contains stored away control flow information for the application.
•Data space is used to store data with fixed sizes which needs to be shared among different parts of an application. Often, content in data space has been given initial values.
•Heap space is dynamically given out to applications, with the intent that it is relatively short-lived, of varying size based upon the input datasets, and is frequently visible to numerous sub-components of an application.
Note This rule is UNIX specific. Some corresponding Windows functionality is available from the System API control rule page.
Configure the Buffer overflow rule as follows.
Step 1 To add rules to your module, expand the rules area of the rule module and click the Add button. A pop-up list of the available rule types appears.
Step 2 Select the Buffer overflow rule. This takes you to the configuration view for this rule type (Figure 6-20).
Step 3 In the Buffer overflow rule configuration view, enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the module and it will not be distributed to groups.
Step 4 Take the following action—Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Options and Precedence, page 5-13. (Note that Priority Deny and Deny actions are not available for this rule.)
Step 5 and
•Log—Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules—Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works. See Rules: Manipulating Precedence, page 5-16 for details.
Step 6 when
Applications in any of the following selected classes
Select one or more preconfigured application classes here.
Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes. For application class configuration details, see Chapter 9, "Using Application Classes".
But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
Step 7 Select one or more of the following checkboxes to prevent the associated buffer overflow attack from occurring.
•Attempted buffer overflow detected
Enable this checkbox to detect buffer overflow conditions which occur in UNIX executables. This feature provides protection from stack buffer overflows to a number of commonly used libc routines. As a large number of attacks on UNIX systems are based upon buffer overflow attacks, it is recommended that you enable this feature.
•Executing a system call in an unsafe context
Use this checkbox to prevent certain system calls (e.g. those which grant extra privileges or start new processes) from occurring if they are invoked in an unsafe manner, or if they appear to have come from a corrupted or invalid context.
•Processes terminated by operating system due to executing code in stack space
This checkbox enables the "noexec_user_stack" system variable for all processes or for processes added to the <*Processes requiring OS Stack Execution Protection>. See Built-in Configurable Application Classes, page 9-5 for details. This checkbox monitors the execution of instructions from stack memory. This only provides logging.
•Process terminated due to signal or internal error
Processes can be killed on a system by either another process or by an internal error occurring on the system. This checkbox causes the agent to monitor when this occurs. The only action type available when this checkbox is enabled is Monitor.
•Use of an unsafe format in a printf call
Use this checkbox to prevent the usage of the '%n' *printf() format qualifier. Numerous attacks utilize the '%n' format on *printf() routines to gain access to program control flow information.
You also have the ability to select specific application classes to exclude from the various Buffer overflow types you designate. If you select an application in the available list beside a checkbox rule, that rule does not apply to the selected application class. If you have multiple, similar Buffer overflow rules, the application class exceptions are combined.
Step 8 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 9 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-20 Buffer Overflow Rule
Network Interface Control
Use the Network interface control rule to specify whether applications can open a device and act as a sniffer (promiscuous mode). A packet sniffer is a program that monitors and analyzes network traffic. Using this information, a network manager can troubleshoot network problems. A sniffer can also be used illegitimately to capture data being transmitted on a network. Sensitive information such as login names and passwords can be extracted from this data and used to break into systems.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Network Interface Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
Select one or more pre-configured application classes here to indicate the application(s) whose access to the NIC you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application cases.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
Step 9 Attempt the following operations
Select one or more of the following checkboxes:
•Open a stream connection to the NIC driver
•Put the NIC into promiscuous mode
For Linux systems, the Open a stream connection to the NIC driver only applies to modification of the interface characteristics, e.g. using ifconfig to modify an interface's network mask. This does not apply to simply reading the interface characteristics.
If the rule is configured to take any allow action, when you select to "Put the NIC into promiscuous mode", the "Open a stream connection to the NIC driver" checkbox is also automatically selected. It must be enabled for promiscuous mode to work.
If the rule is configured to take any deny or terminate action, when you select the "Open a stream connection to the NIC driver" checkbox, the "Put the NIC into promiscuous mode" checkbox is also automatically selected. If you deny one, the other is automatically denied as well.
Note If you are using remote management tools and you are configuring a Network interface control rule to deny "all applications" from opening a stream connection to the NIC and operating in promiscuous mode, you may want to make an exception for the remote management application (if you want to run snoop).
Step 10 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 11 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group and then downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. Clicking the down arrow, expands the menu. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-21 Network Interface Control Rule
Resource Access Control
Use the Resource access control rule to protect systems from symbolic link attacks. In this type of attack, an attacker attempts to determine the name of a temporary file prior to its creation by a known application. If the name is determined correctly, the attacker could then create a symbolic link to the target file for which the user of the application has write permissions. The application process would then overwrite the contents of the target file with its own output when it tries to write the named temporary file.
For example, a directory such as /tmp is writable by everyone. An attacker could create a symbolic link in this directory to a protected file such as /etc/shadow. A superuser process may then unwittingly write to or copy from /etc/shadow. This would then grant the attacker access to this sensitive information via a symbolic link from the /tmp directory.
By enabling the resource access control rule, you can prevent "suspicious" symbolic links from being followed. A suspicious symbolic link is one that meets all of the following criteria:
•The parent directory is a temporary directory such as /tmp and /usr/tmp
•The symbolic link's owner is different from the parent directory's owner
•The symbolic link's owner is different from the effective UID of the process
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Resource Access Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Select the Symbolic Link Protection checkbox to turn on that functionality.
Step 7 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Caution Symbolic Links: If you create a File access control rule to protect a symbolic link, ONLY that symbolic link is protected. The underlying resource, unless also specified, is NOT protected. For example, a File access control rule written for
PacketDriver does not protect
plantronics\microphone. Similarly, a File access control rule written for
/etc/hosts does not protect
/etc/inet/hosts. If you want to protect a symbolic link and its underlying resource, both must be specified in the rule.
FACLs that deny users Read access have no effect on symbolic links. We purposefully ignore the option to "deny reading contents of the symbolic link" to avoid multiple error messages on commands such as "ls".
Figure 6-22 Resource Access Control Rule
Rootkit / kernel Protection
Use the Rootkit / kernel protection rule to control unauthorized access to the operating system. In effect, this rule controls drivers attempting to dynamically load after boot time. You can use to this rule to specify authorized drivers that you are allowing to load any time after the system is finished booting.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Rootkit/Kernel protection from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Take the following action — Select an action type from the pulldown list. For further details on rule action types, see Rules: Action Definitions, page 5-14.
Step 7 Under and, specify logging and precedence preferences:
•Log — Enable this checkbox to turn logging on for this rule. Generally, you will want to turn logging on for all deny rules. This means that the denied system action in question is logged and sent to the server at regular time intervals.
•Take precedence over other <action type> rules — Enable this checkbox to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this checkbox. Do not use it without understanding how it works, see Rules: Action Options and Precedence, page 5-13 and Rules: Manipulating Precedence, page 5-16 for more information.
Step 8 When - Applications in any (or all) of the following selected classes
•Select one or more pre-configured application classes here to indicate the application(s) whose access to the operating system you want to control. Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes by clicking the blue New link next to the application class list box. See Configuring Static Application Classes, page 9-6 or Configuring Dynamic Application Classes, page 9-8 for configuration details.
If you choose Applications in any of the following selected classes the rule will affect an application that is a member of one of the selected application classes.
If you choose Applications in all of the following selected classes, the rule will affect an application that is a member of every application class you select.
•But not in the following class: Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default. You may also create a new application class by clicking the blue New link next to the application class list box.
When your rule is configured, currently selected application classes appear at the top of the list.
Step 9 Attempt to load the following modules
By default, this field contains <none> which indicates no specified drivers. Enter the names of drivers you want to specify for this the rule and therefore allow, deny, or monitor the loading of at any time.
Caution If you enter file sets which use "content-matching" constraints, via the Insert File Set link, the content-matching constraints are ignored.
•The previous detected boot was insecure
When a system has previously booted in a non-standard manner, selecting this checkbox causes a message to be sent to the event log. A boot is considered standard if the system was booted from the primary hard disk. Any other boot type, for example, booting from a peripheral device (CD ROM) or a hard disk that is not the primary, is considered non-standard. A non-standard boot may be considered suspicious. (e.g., This is one way of circumventing the Cisco Security Agent and introducing a Trojan to a system.)
The insecure boot detection this checkbox enables works in conjunction with a particular type of compatible BIOS on compliant systems. The compatible BIOS detects a non-standard boot and on the next normal boot, if you have this checkbox selected, a message is sent to the MC which logs this insecure boot detection. (If a Host is running a BIOS that supports this insecure boot detection feature, the individual Host details page will indicate this. From the CSA MC menu bar, click Systems>Hosts. Then click on the link for an individual host. The Host Status section includes a category named "BIOS supported boot detection".)
–Included boot patterns
By default, this field contains <all>. You can use provided tokens here to only detect certain boot types as insecure or to exclude a particular boot type from the detection. Available tokens are:
@fixed - This indicates a fixed hard disk that is not the primary disk. (Compatible BIOS is required to detect this.)
@network - This indicates all network shares. (Compatible BIOS is required to detect this.)
@removable - This indicates all removable media. That includes, floppies, CDs, zip drives, etc. (Compatible BIOS is required to detect this.)
Step 10 (For rules with detection actions) In the And area specify the enforcement action CSA took when the application attempted the operation. Indicating Allow by default or Allow if triggered by a rule indicates that CSA allowed the operation. Indicating Terminated or Denied by rule indicates that CSA prevented the application from performing the operation.
Step 11 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Figure 6-23 Rootkit / kernel Protection Rule
Syslog Control
Use the Syslog control rule to have specified Solaris and Linux Syslog items appear in the CSA MC Event Log for selected groups.
Rules can only be added to existing rule modules. See Configuring Rule Modules, page 5-2, to create a new rule module, or Adding Rules to a Rule Module, page 5-4 for more information.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 Open the rule module to which you want to add this rule.
Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.
Step 4 Select Syslog Control from the list of rules. This takes you to the configuration view for this rule type.
Step 5 Enter the following information:
•Description—Enter a description of this rule. This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.
•Enabled—Use this checkbox to enable this rule within the module. (It is enabled by default.) By not selecting this checkbox, you can save this rule, but it will not be active in the policy and it will not be distributed to groups.
Step 6 Log events from syslog
•Include events matching the following—Select this radio button to specify the criteria for Syslog entries which you want to appear in the CSA MC Event Log.
•Include all events except those matching the following—Select this radio button to specify the criteria for Syslog entries which you do not want to appear in the CSA MC Event Log. (All criteria not specified here will appear in the CSA MC Event Log.)
Note You can configure CSA MC to correlate Syslog events logged across multiple systems.
Step 7 Criteria (You should select at least one for the rule to have any effect.)
•Event Source—In the text field, enter (one per line) event source parameters you want to filter by.
The event source is the software that logged the event, which can be an application name such as /etc/inet/hosts, a kernel level driver module such as /etc/hosts, or the /sbin/dhcpagent kernel itself.
•Facility—Select one or more items from the list box you want to appear (first radio button above) or which entries you want to not appear (second radio button above) in CSA MC Event Logs.
•Priority—Select one more checkboxes by which to filter the viewing of events according to priority. If you select no checkboxes, all priorities are included in the rule.
•Message Pattern—In the text field, enter (one per line) message patterns you want to match and filter by. To match, the string you enter must literally appear somewhere within the message.
Step 8 Click Save. This rule is now part of your rule module. It takes effect when the policy is attached to a group, rules are generated, and the updated policy is downloaded by an agent on the network.
Tip There is a red Tasks menu in the upper right corner of the page. This menu provides quick links to common tasks that are relevant to this rule.
Note On Linux platforms, the default syslogd does not embed the facility or priority level in the syslog messages. Using a different syslogd, such as syslog-ng, with correct message formatting, it is possible to use the facility and/or priority levels to report these events. Therefore, if syslog-ng is used, the message template must take the following form:
template("$DATE $HOST $PROGRAM: [ID 0 $FACILITY.$LEVEL] $MSG\n")
For example, the entry for content recorded into /var/log/messages would appear as follows: scsi
General Syslog rule configuration examples
For Example:
Configure a syslog rule to log warning messages such as the one listed here:
Apr 29 13:46:35 myhost /sbin/dhcpagent[39]: [ID 929444 daemon.warning]
configure_if: no IP broadcast specified for eri0
To get every message of category "warning" from the
/sbin/dhcpagent daemon, you would configure your syslog rule in the following manner (See Figure 6-24):
Select the "Include events matching the following" radio button and enter:
•Facility: daemon
•Event Source: /sbin/dhcpagent
•Priority: Warning checkbox
•Message Pattern: <all>
For Example:
Configure a syslog rule to log failed su root attempts such as the one listed here:
Apr 29 13:49:23 myhost su: [ID 810491 auth.crit] 'su root' failed for haxor on
/dev/pts/4
To get messages for failed su root attempts, you would configure your syslog rule in the following manner:
Select the "Include events matching the following" radio button and enter:
•Facility: auth
•Event Source: su
•Priority: Alert and Above checkbox
•Message Pattern: root
For Example:
Configure a syslog rule to include all events but exclude all lockstat-related messages such as the one listed here:
Apr 29 13:46:43 myhost genunix: [ID 936769 kern.info] lockstat0 is
/pseudo/lockstat@0
To log all events except for lockstat-related messages, configure your rule in the following manner:
Select the "Include events except those matching the following" radio button and enter:
•Facility: kern
•Event Source: <all>
•Priority: all checkboxes
•Message Pattern: lockstat
Figure 6-24 Syslog Control Rule
