Guest

Cisco Security Agent

Cisco Security Agent 5.0 Most Common Rule Types

Document ID: 82437

Updated: Sep 18, 2008

   Print

Introduction

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 combination 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.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco Security Agents 5.0

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Rules Common to Windows and UNIX

These 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 used with a net stop command on Windows or with /etc/init.d/ciscosec stop on UNIX and whether end users can disable security with the agent UI security slide bar. Refer to Using Management Center for Cisco Security Agents Utilities for details. When you stop agent security, it 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 as a result agents cannot be uninstalled.

Note: Although agents cannot be uninstalled by administrative users if this rule denies the stoppage of the agent service, this rule does not prevent the occurrence of agent software updates.

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.

  1. In order to add rules to your module, click the Add rule link at the bottom of the rule list. A pop-up list of the available rule types appears.

  2. Choose the agent service control rule. This takes you to the configuration view for this rule type; see the figure (Agent Service Control Rule (Windows)) for more clarification.

  3. In the agent service control rule configuration view, enter this 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 check box to enable this rule within the module. It is enabled by default. If you do not choose this check box, you can save this rule, but it is not active in the module, and itis not distributed to groups.

  4. Take this action—(Note that not all action types are available for this rule on Windows platforms.) Choose an action type from the pull-down list. For further details on rule action types, refer to Rules: Action Options and Precedence.

  5. Take these actions:

    • Log—Enable this check box to turn logging on for this rule. Generally, you 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 check box to manipulate rule precedence so that this rule is evaluated before other similar rules. Generally you must NOT require this check box. Do not use it unless you understand how it works. Refer to Rules: Manipulating Precedence.

  6. Take this action:

    For applications in any of these classes, do this: —Choose one or more preconfigured application classes. Note that the entry <All Applications> is chosen by default. You can use this default or you can unselect it and create your own application classes. For application class configuration details, refer to Using Application Classes.

    Note: On UNIX systems, anyone with root access can stop the agent service. In order to prevent this yet allow administrators to stop the agent service, you can configure an agent service control rule to deny <All Applications> from stoppage of service. Then configure another agent service control rule which allows only a UNIX Secured Management application class to stop the service.

    For applications in any of these classes, do this:—Optionally, choose application classes here to exclude from the application class(es) you have chosen in the included applications field. Note that the entry <None> is chosen by default.

    • Attempt to disable agent security

      This check box controls whether users with administrator privileges or the use of net stop Cisco Security Agent from a command prompt on Windows or via /etc/init.d/ciscosec stop on UNIX can stop the agent service from the Service Control Manager.

      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 agent service to be stopped, the Off level, if available, is ineffective. Refer to Agent UI Control for more information.

    • Attempt to modify local agent configuration

      The Cisco Security Agent has built-in global security policies that protect agent binaries and data.

      Note: This protection is only offered when the agent service is running and is not stopped or in Test 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.

  7. Click the Save button.

Agent Service Control Rule (Windows)

csa-1.gif

Agent UI Control

Note: This rule only applies to Windows and Linux platforms. The agent UI rule is not supported on Solaris systems.

Note: Test Mode does not apply to this rule type.

Use the agent UI rule to control how the agent user interface is displayed to end users. See the figure. In the absence of this rule, end users have no visible agent UI. If this rule is present in a module, you can choose 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. These are the optional controls:

  • Allow user to reset agent UI default settings—On Windows, this is available from the Star > Programs > Cisco Systems menu. On Linux, this is available from System Menu > Cisco Security Agent. With 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 various user agent permission settings can log on to the same machine.

  • Allow user interaction—The choice of this check box causes the end user to have a visible and accessible agent UI, which includes a red flag in the system tray. With no other subsequent check boxes chosen, the agent UI contains a status view, a message page with which 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 check box is not chosen, the end user has no visible agent UI. In the presence of two or more agent UI control rules, these rules are combined and chosen check boxes take precedence over unchosen check boxes.)

    Add one or more additional controls:

    • Allow user access to agent configuration and contact information: The choice of this check box allows the end users 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: The choice of this check box provides the end users with the abilities to alter their security level when they move a slidebar between Off, Low, Medium, and High (in accordance with policies) and to manage the classification of untrusted content.

      This check box 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.

      The concession of this action (when the slidebar is moved to Off) permits all users, which includes non-administrative users, to disable all rules on the agent until they are re-enabled by the user.

      Note: If there is no agent UI present, agent security cannot be turned off.

    • Allow user to modify agent personal firewall settings—The choice of this check box provides the end users 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, which network applications are not allowed to access on their system.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 choose this check box, you provide the end user with controls to which you have limited access. Firewall queries and other information do not log to the CSA MC event log.)

Hidden agent UI

When the Allow user interaction check box in this rule is not enabled, anticipate these 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, a visible agent UI setting, if present in any group of which the host is a member, takes precedence over a no user interaction agent UI setting.

    Whether or not an end user system has 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. Refer to Scripted Agent Installs and Uninstalls.

    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 check box and generate rules, the agent UI disappears when the new rules are downloaded.

csa-2.gif

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 certain applications from running on systems. If you deny an application class (in total) in this rule, users cannot use any application in that class.

With this rule, you can also prevent an application from running only if that application was invoked by another application you specify. This way, you could prevent a command prompt from running on a system if it is invoked by an application that has downloaded content from the network.

Note: These instructions are a continuation of Configuring Rule Modules.

  1. In order to add rules to your module, click the Add rule link at the bottom of the rule list. A pop-up list of the available rule types appears.

  2. Choose the Application Control rule. This takes you to the configuration view for this rule type. See the figure.

  3. In the Application control rule configuration view, enter this 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 check box to enable this rule within the module. (It is enabled by default.) If this check box is not chosen, you can save this rule, but it is not active in the policy and it is not distributed to groups

  4. Take this action—Choose an action type from the pull-down list. For further details on rule action types, refer to Rules: Action Options and Precedence.

    Note: The creation of dynamic application classes from the Application control rule is a bit different than their creation 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.

  5. Take this action:

    • Log—Enable this check box to turn logging on for this rule. Generally, you 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 check box to manipulate rule precedence so that this rule is evaluated before other similar rules. Generally you must NOT require this check box. Do not use it unless you understand how it works. Refer to Rules: Manipulating Precedence.

  6. Take this action:

    • For current applications in any of these chosen classes, do this:—If you want to control an application (allow or deny) that runs on a system, no matter how it is in invoked, allow All Applications to remain chosen by default. (Then choose the application you want to control from the second application class list.)

      If you want to control which application(s) can invoke other applications, choose one or more preconfigured application classes here to indicate the application that invokes (such as Network Applications).

      When your rule is configured, currently chosen application classes appear at the top of the list. Refer to Configuring Static Application Classes for configuration details.

    • For applications in any of these classes, do this:—Optionally, choose application classes here to exclude from the application class(es) you have chosen in the included applications field. Note that the entry <None> is chosen by default.

    • Attempt to run new applications in any of these classes:—If you control which applications can invoke other applications, this second field indicates the application class that you do not want to run when invoked by the application you chose in the top field.

      If you chose all applications in the top application field, you cannot choose all applications in this second field. If you do so, no applications can run on systems if this is a deny rule.

    • Do not attempt to run applications in these classes:—Optionally, choose application classes here to exclude from the application class(es) you have chosen in the included applications field. Note that the entry <None> is chosen by default.

      Note: Most dynamic application classes are not available in this second application class inclusion field.

  7. When you finish your application control rule configuration, click the Save button.

Application Control Rule

csa-3.gif

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 helps prevent attacks that bring down system services, for example, denial of service attacks (server connection rating limiting). This is also helps prevent 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 runs several instances of an Apache web server, all Apache connections are counted together when this rule is applied.

Note: These instructions are a continuation of Configuring Rule Modules.

Click the Modify rules link at the top of the Rule Module page to go to the Rules page.

  1. In order to add rules to your module, click the Add rule link at the bottom of the rule list. A pop-up list of the available rule types appears.

  2. Choose the Connection rate limit rule. This takes you to the configuration view for this rule type.

  3. Enter this 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 check box to enable this rule within the module. (It is enabled by default.) If you do not choose this check box, you can save this rule, but it is not active in the module, and it is not distributed to groups.

    • Log—Use this check box to enable logging within the module.

  4. Take this action>—Choose an action type from the pull-down list. For further details on rule action types, refer to Rules: Action Options and Precedence.

    Note: You cannot configure Query User Connection rate limit rules.

    Note: If you choose the Set action to market a host as untrusted, you can only configure the rule for servers and specific hosts.

  5. With applications in any of these classes, choose one or more preconfigured application classes to indicate the application(s) whose connection rate access you want to control.

    Note: The entry <All Applications> is chosen by default. You can use this default or you can create your own application classes. For application class configuration details, refer toUsing Application Classes.

    Do not attempt to run applications in these classes:—Optionally, choose application classes here to exclude from the application class(es) you have chosen in the included applications field. Note that the entry <None> is chosen by default.

    Note: When your rule is configured, currently chosen application classes appear at the top of the list.

  6. Choose the server, client, or client or server.

    From the pull-down menu, choose the server, client, or client or server dependent upon the direction of the connection you control. If you restrict the connection limit of a server, choose the server here. If you limit a client connection, choose the client here.

  7. Choose specific 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 are dropped. If you choose a specific host, this indicates that the host in question has exceeded the rate limit. If you choose all hosts, this indicates that the sum total of to and from all hosts has exceeded the limit, and all hosts are blocked.

  8. Reasonable values are entered into these fields by default: Over/Under a limit <100> network connections or in <5> minutes. They define the number of connections that can normally be expected within a time frame from either specific hosts or all hosts.

    • If you choose an action type of deny or terminate, and the limit is exceeded (Over) in this time frame (abnormal amount of connections that can 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 set a limit Under, in which the number of connections must remain for the subsequent connections to be explicitly allowed.

  9. When you finish configuration of your connection rate limit rule, click the Save button.

Connection Rate Limit Rule

csa-4.gif

Data Access Control

Use data access control rules on Web servers to detect clients that make malformed web server requests where such requests can crash or hang the server. A malformed request can also be an attempt by an outside client to retrieve configuration information from the web server or run exploited code on the server. This rule detects and stops such web server attacks when it examines the URI portion of the HTTP request.

An HTTP request consists of these:

  • The request method (a get or post)

  • The request Uniform Resource Identifier(URI) which 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 (refer to Data Sets) and group patterns to match are based upon these:

  • Functional associations of meta-characters, for example, and

  • Examples of known classes of attacks

  • Web server specific exploits

Use the data access control rule to allow or deny specified fundamental network data requests for these web servers and platforms:

  • Microsoft IIS (Windows platforms, Version 4.0 or earlier)

  • Apache (Windows and UNIX platforms, Versions 1.3, 2.0)

  • IPlanet (UNIX platforms, Version 6.0)

Note: 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. 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.

Note:  On Solaris (Apache or IPlanet 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. Refer to Manual Agent Data Filter Installation for instructions.

Note: These instructions are a continuation of Configuring Rule Modules.

  1. Click the Modify rules link at the top of the Rule Module page to go to the Rules page.

  2. In order to add rules to your module, click the Add rule link at the bottom of the rule list. A pop-up list of the available rule types appears.

  3. Choose the data access control rule. This takes you to the configuration view for this rule type.

  4. Enter this 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 check box to enable this rule within the module. (It is enabled by default.) If you do not choose this check box, you can save this rule, but it is not active in the policy and it is not distributed to groups.

  5. Choose an action type from the pull-down list. For further details on rule action types, refer to Rules: Action Options and Precedence.

  6. Take these actions:

    • Log—Enable this check box to turn logging on for this rule. Generally, you 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 check box to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this check box. Unless you understand how it works, do not use it. Refer to Rules: Manipulating Precedence.

  7. With applications in any of the these chosen classes, do this:

    Choose 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 chosen by default. You can use this default, or you can unselect it and create your own application classes. For application class configuration details, refer to Using Application Classes.

    Optionally, choose application classes here to exclude from the application class(es) you have chosen in the included applications field. Note that the entry <None> is chosen by default.

    Note: When your rule is configured, currently chosen application classes appear at the top of the list.

  8. Attempt to access these data sets.

    Click the Insert Data Set link to enter a pre-configured data set. When you click this link, a list of the data sets you have configured appears, which allows you to choose one or more. Instead of data sets, you can list the literal data strings you want to protect. You can use a wildcard designation.

    For information on configuration, refer to Data Sets.

  9. When you finish the configuration of your Network access control rule, click the Save button.

    Note: If you specify an application other than IIS, Apache, or iPlanet, this rule is ignored.

Data Access Control Rule

csa-5.gif

File Access Control

Use file access control rules to allow or deny what operations (read, write) certain applications can perform on files. You must understand that file protection encompasses read/write access. Directory protection encompasses directory deletes, renames, and new directory creation.

Note: These instructions are a continuation of Configuring Rule Modules.

  1. Click the Modify rules link at the top of the Rule Module page to go to the Rules page.

  2. In order to add rules to your module, click the Add rule link at the bottom of the rule list. A pop-up list of the available rule types appears.

  3. Choose the File access control rule. This takes you to the configuration view for this rule type.

  4. Enter this 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 check box to enable this rule within the module. It is enabled by default. If you do not choose this check box, you can save this rule, but it is not active in the policy, and it is not distributed to groups.

  5. Choose an action type from the pull-down list. For further details on rule action types, refer to Rules: Action Options and Precedence .

  6. Take these actions:

    • Log—Enable this check box to turn logging on for this rule. Generally, you 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 check box to manipulate rule precedence so that this rule is evaluated before other similar rules. You should generally NOT require this check box. Unless you understand how it works, do not use it. Refer to Rules: Manipulating Precedence.

  7. With applications in any of the these chosen classes, do this:

    Choose 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 chosen by default. You can use this default, or you can unselect it and create your own application classes. For application class configuration details, refer to Using Application Classes.

    Optionally, choose application classes here to exclude from the application class(es) you have chosen in the included applications field. Note that the entry <None> is chosen by default.

    Note: When your rule is configured, currently chosen application classes appear at the top of the list.

  8. Attempt these operations:

    Choose the operations Read and/or Write you allow/deny on the files named in the Files field. For directory protection, the actions you allow/deny are Create, Delete, and Rename. Refer to file and directory protection in Using the Correct Syntax.

    Note: 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 is overly broad. For example, if you choose to protect a directory in a deny rule and enter this directory path **\Program Files\**Outlook.exe, 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 be very specific in your path string and understand the resultant behavior.

  9. Click the Insert File Set link to enter a pre-configured file set here. When you click this link, a list of the file sets you have configured appears here, which allows you to choose one or more. Instead of file sets, you can list the literal files you want to protect with the file paths, which includes wildcards.

    For information on how to enter file path literals here rather than use pre-configured file sets, refer to Using the Correct Syntax.

    For local system paths, you must specify the disk drive. You can use a wildcard designation. When you protect directory creates, in particular, you must 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
    
    For network machines (Windows only), enter 
    
    \\<machine name>\<share>\<path>\<filename>
    

    Another example is *:\Program Files\winnt\*. You can enter more than one file path, but each entry must appear on its own line. For more details, refer to File Set configuration.

    Note: In regard to symbolic links and fard links for UNIX, if you create a file access control rule to protect a symbolic link, ONLY that symbolic link is protected. The fundamental 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 fundamental resource, both must be specified in the rule.

    Note: 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.

    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.

    Note:  In order to view the files that are added to the dynamically quarantined files list and to manually add files to be quarantined, click the Manage Dynamically Quarantined Files link on the Global Event Correlation page. Refer to Manage Dynamically Quarantined Files and IP Addresses for more information.

  10. When you finish configuration of your file access control rule, click the Save button.

    This rule is now part of your new policy. It takes effect when the policy is attached to a group and then downloaded by an agent on the network.

    Note: In order to distribute rules to the correct hosts, you must associate policies with groups and then generate rules. Refer to Generating Rule Programs for instructions.

File Access Control Rule

csa-6.gif

Troubleshoot

If you try to generate and apply new policy rules on a CSA server, the generation can fail, and you can receive this error message:

Rules for Kit: Imported_IDS_Mode_Desktop_V4.0.3.720 have complexity 7560 which exceeds the
maximum of 7500

The error occurs because of a complexity check. A complexity check reviews the number of literals and distinct rules that are applied to a particular host.

In order to resolve this issue, reduce your rule set slightly and examine it for duplicates. An easy way to examine any duplicates is to choose Configuration > Policies. Scroll down to your policy and click the policy. On the next screen, scroll past the modules and onto the section called Combined Policy Rules. In this section, you see headers, such as ID, Type, Status, Action, Log, and so forth. Click the Type heading. This sorts the rules by type.

Related Information

Updated: Sep 18, 2008
Document ID: 82437