-
Using Management Center for Cisco Security Agents 4.5.1
-
Title
-
Preface
-
Product Overview
-
Management Center for Cisco Security Agents Administration
-
Configuring Groups and Managing Hosts
-
Building Policies
-
Using System Correlation Rules
-
Using Application Classes
-
Configuring Variables
-
Event Logging and Alerts
-
Generating Reports
-
Using Management Center for Cisco Security Agents Utilities
-
Using Cisco Security Agent Analysis
-
Policy Definition Guidelines
-
Third Party Product Integration
-
Cisco Security Agent Overview
-
System Components
-
Open Source License Acknowledgements
-
Table Of Contents
Providing Safe Access to Required Resources
Rules: Action Options and Precedence
Rules: Manipulating Precedence
Query Rule Priority Information
Building Policies and Rule Modules
Merging or Copying Rule Modules
Rules Common to Windows and UNIX
Sniffer and Protocol Detection
General Syslog rule configuration examples
Attaching Rule Modules to Policies
Building Policies
Overview
The policies you create on the Management Center for Cisco Security Agents should reflect a well-planned, enterprise-wide security policy. If your corporate enterprise already has security guidelines in place, the rules that form your policies should reflect those guidelines.
It is important that you spend time charting out your security needs in advance rather than attempting to backfill holes as they are discovered. Because both networks and network security are dynamic entities, it is expected that you will need to adjust policies to meet the changing and growing needs of your enterprise. A well thought-out security plan is certain to save you time in the end.
This section contains the following topics.
•
Rules: Action Options and Precedence
•
•
•
•
•
•
•
•
Developing a Security Policy
If you are crafting your own policies, please refer to Chapter 12, "Policy Definition Guidelines," for information.
Caution
Note that each pre-configured rule, rule module, policy, and group page has data in the expandable +Detailed description field explaining the item in question. Read the information in these fields to learn about the items described and to determine if the item in question meets your needs for usage.
A corporate security policy should temper business concerns with security concerns. It should allow the user community to access required resources, while protecting that community from the dangers those resources can introduce. To achieve this goal, it is crucial to have a carefully planned network security policy in place to safeguard valuable organizational resources and information.
Before configuring your policies, it is important to understand exactly what network resources and services you want to protect and what threats you are most concerned about. The first step in planning a security policy is identifying the resources your user community requires to do business. That could include specific applications, protocols, network servers and web servers. Collect this information and use it to design the main features of your policy.
Providing Safe Access to Required Resources
As you determine the network resources that are required by your user community, you can identify some of the threats posed against those resources. For example, while putting together a security plan, you might find it beneficial to limit access to some resources based on various parameters such as traffic direction and allowed file types.
Upon examining past breaches of security, you could determine that email attachments and Internet file downloads pose the greatest threat to your network. In this case, you would want to develop policies to diminish the danger of accessing these particular resources. Your security plan should then incorporate policies for commonly used services such as Web, email, and instant messengers.
You could take a couple of approaches to enforcing your security plan depending upon the immediacy of any perceived threats and your basic corporate philosophy toward security. Both approaches are equally valid. On the one hand, you might choose to allow most activities and selectively add targeted restrictions. This would be a more permissive security model. This approach facilitates uptime, but may be less secure. Conversely, you could decide to shut everything down and then slowly add targeted permissions. This approach is far more restrictive and some legitimate requests could be rejected, but this may be suitable for highly secured environments. You could use both approaches for different groups.
As your security plan evolves, you can refine your policies, making them more or less granular to keep pace with your user community's needs. Your network system security depends on your implementing security policies carefully, and checking to see that they work as intended.
Figure 4-1 Protecting Information
About Rules
Rules are the foundation of your security policies. CSA MC lets you create several rule types. Each rule type requires you to enter varying combinations of information using a specific syntax. Most Policies and Rule Modules use a combination of Enforce and Detect rules. Enforce rules are primarily access control rules that allow, deny, or terminate a process. Detect rules are monitoring, and tagging rules. In rule display lists, enforce rules are shown at the top of the list and detect rules are shown at the bottom. These rule types work together to monitor actions, build application classes, and protect systems.
For example, the following basic enforcement rules require information as follows:
Use file access control rules to allow or deny what operations(read, write) selected applications can perform on files and directories according to:
•
•
•
Use network access control rules to control access to specified network services according to:
•
•
•
•
•
Use registry access control rules (Windows only) to allow or deny selected applications from writing to specified registry keys according to:
•
•
•
Use COM component access control rules (Windows only) to allow or deny selected applications from accessing specified COM components according to:
•
•
Other types of enforcement rules shipped with CSA MC provide event correlation and heuristic features which can be enabled on a per group basis, like portscan detection, SYN flood protection, the prevention of predictable TCP sequence numbers, and the blocking of malformed IP packets. (These features are located on the Network shield rule page.) This is especially useful for network servers. (See Chapter 5, "Using System Correlation Rules" for more information.)
The following basic detection rules work as follows:
Use various tagging rule types with "Add process to application class" or "Remove process from application class" selected to build application classes based on process behavior rather than executable name. Once applications are built or "tagged" they are used in other enforcement rules.
Use rules such as NT Event log and Sniffer and protocol detection to log designated event types when they occur.
By tying together the controlling and monitoring of various system functions and by operating under the direction of assigned policy rules, agents provide overall system protection,
Combining Policies
You can attach multiple rule modules to single policies and you can attach multiple policies to a single group. Moreover, a host can belong to multiple groups and inherit policies from all of them. For example, a desktop can belong to the Desktop-All types group and inherit the Systems-Test Mode policy. It can also belong to the All group through which it receives the Remote Systems Policy.
When more than one policy is associated with a host, the rules modules in the individual policies are merged as though they were all defined within a single policy. In particular, the rules in the policy are ordered in the same sequence as they would be within a single module. See the section on Rules: Action Options and Precedence for priority order information.
Figure 4-2 displays the relationship between host, group, policy, and rule module configuration items. In the diagram, you can see that the policy level is the common ground by which host groups acquire the rules that make up their security policy.
Note
Figure 4-2 Host, Group, Policy, Rule Module Associations
Policy Components
The following sections describe the various components you must configure as part of rules modules that will form your policies.
Rules: Action Options and Precedence
When you configure certain rule types, you select an action for that rule (allow, deny, etc.). When you add your rule modules to policies, CSA MC orders individual rules from multiple modules according to action, in the following manner within each policy.
The priority listings beside each item indicate the manner in which CSA processes rules. All priority 1 enforcement rules (High Priority Terminate Process) are checked first and priority 8 enforcement rules (Deny) are checked last and that is only if no other higher priority rules have already been triggered by a system action. Detection rules, such as priority 12 Monitor rules, are always checked, even in the presence of a higher priority enforcement rule which governs the same resources triggering first.
Note
Rules: Action Definitions
When you configure your access control rules, you must select an action for that rule. The following is a description of all possible action types. You should note that not all action types are available for all rules.
Enforcement Actions
•
•
•
•
•
•
Text used to query user—If you are configuring a Query User rule, you must also configure query settings. The text you type into the query settings field is the same text that will appear in the Query User pop-up box to explain what is occurring on the system to the user.
•
•
Detection Actions
Note that Detection rules, such as priority 12 Monitor rules, are always checked, even in the presence of a higher priority enforcement rule which governs the same resources triggering first.
•
•
Note
Note
•
For every rule module you configure, the default action of that rule is Allow. All rule modules allow all system actions until you write a rule denying a specific action. Following that logic, it is unlikely that you would write allow rules unless they are to make exceptions to deny rules you are writing within a module or for monitoring purposes (see Monitoring Access). If you do write a stand-alone allow rule, because the default action is allow, the allow rule itself is then essentially irrelevant.
A good model for configuring rules within modules would be to take the priority levels into account and work from the bottom up, lowest priority to highest priority. Before you even add a single parameter to a rule, by default, it allows all system actions. First, write a deny rule and then if you want to make any exceptions to that particular deny, write an allow rule. Next consider using query rules for access controls that allowing the user to decide if an action should be allowed or denied. Lastly write any high priority rules you might need.
Rules: Manipulating Precedence
In addition to using the selected "action" type to order rules within a policy, CSA MC uses the selected logging type as a way to suborder similar rules within a policy. Logging automatically takes precedence over disabled logging if the action type is the same for multiple rules in a policy. Therefore, for rules of a given priority, e.g. Allow, a Log rule will be evaluated before a No Log rule.
For most policies, this automatic ordering and subordering of rules provides the desired effect when policies are combined and deployed. However, there are cases when the CSA MC ordering scheme causes policies to behave in an undesired manner. For this reason, most rule types provide a checkbox that allows you to manipulate how similar rule types are subordered within a policy. This checkbox, called Take precedence over other <similar action> rules, is located in the rule configuration page. A rule with this precedence checkbox selected is evaluated before similar rules that do not have this checkbox selected.
Here is an example of two rules within the same policy which do not behave as expected due to automatic rule ordering. There are two Network access control rules in the same policy as follows:
•
for TCP/1-65000•
for TCP/1900The rule that involves connections on TCP/1900 would be denied and logged despite the fact that logging is not selected for that rule. This is because the rule involving connections on TCP/1-65000 would be evaluated within the policy first and connections made on TCP/1900 would go to the event log even though the rule did not have logging selected.
In this example, using the Take precedence over other <action> rules checkbox in the TCP/1900 rule would allow you to designate its precedence as higher than other deny rules in the policy, giving you the ability to suppress log messages for actions you want to be denied but for which you do not want to be continually notified due to another rule within the policy.
Caution
* Action type
* Precedence checkbox On/Off
* Log checkbox On/Off
Note
Monitoring Access
Most rule types provide a "Monitor" action. You may want to write monitor rules to produce events for certain resource accesses without having to write an explicit allow or deny rule about that resource. You can also write monitor rules in the presence of other similar rules dictating the availability (allow, deny, etc.) of a resource. For example, you can write a monitor rule for a resource and if the monitor rule is triggered, any subsequent rules about the resource in question will trigger as well. This allows you to configure general alerts about resources regardless whether the resource access action is an allow or a deny.
Making a Policy Mandatory
CSA MC provides three auto-enrollment architectural groups (Windows, Solaris, Linux) that are mandatory for all hosts of a given OS architecture. By providing group auto-enrollment for hosts, any policies you attach to these groups also become mandatory by association. You might want to use these mandatory groups to apply policies which prevent some critical service from being inadvertently banned. For example, you could attach policies to prevent DNS or DHCP from being disabled by an overly restrictive rule.
Querying the User
When you create access control rules, beyond simply allowing or denying a specific action, you can select to query the user when an action triggers the rule in question. The user can then decide to allow the action, deny it, or terminate the process at that time. When you select to query the user, you are also crafting explanation text to display to the user and whether to allow, deny, or terminate the action by default if the query is not answered within 5 minutes. If the user is not logged in to the system, the default action is taken immediately.
Query configurations are a Variable setting which allows you to decide which radio button options are displayed in the pop-up query box, which action is the default, whether the answer given by the user is to be remembered, and what the query text to be displayed will be.
For a Query setting, the response to the query is relevant to the question, not the resource. For example, if a File access control rule queries the user for a response and that identical query is also configured for a Network access control rule, the user is not queried again when the Network access control rule triggers. The query response from the previous File access control rule is automatically taken.
See Query Settings, page 7-25 for configuration details.
Caution
For Windows and Linux agents, agent settings (including user queries) are configurable by the administrator. If the agent UI is hidden for the group, 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.
When an action is attempted on a system where a query user rule is triggered, a pop-up box appears on the system where the resource is located.
Figure 4-3 Query User Pop-up Box
From the Query Settings page, accessible from the Configuration>Variables menu, you configure the query text and the query radio buttons that appear in the pop-up box the end user will see. In the Query pop-up box, the user reads the information given on the attempted action and selects one of the following possible choices and clicks Apply:
•
•
•
Default Action—You chose one of the radio buttons displayed in the query pop-up to be the Default action. If the query is not answered by the user within 5 minutes or if the user is not logged in to the system, the default action is taken immediately.
Don't ask me again—In addition to the button s that will appear on the query box, you can decide to also display a Don't ask me again checkbox so that the user's query response is remembered. If the user selects that checkbox when he/she responds to the query, and the same query is triggered, the remembered response is automatically taken and the user is not queried again.
Query challenge—For added security, you can issue a query challenge on the query pop-up box. If the default answer is not selected by the user and the selected answer is weaker than the default, a challenge will appear. This ensures that the user sitting in front of the system is answering the query rather than a malicious remote user or program attempting to respond. To pass the challenge, the user enters the information displayed in a graphic on the pop-up box itself.
(See Query Settings, page 7-25.)
When you configure your query settings for the rule, the text you type into the Query Setting page's Text used to query user field is the same text that will appear in the Query User pop-up box to explain what is occurring on the system to the user. Therefore, making this information descriptive of the system action that triggered the pop-up is important.
Caution
Caching Responses
When users are queried, the agent can remember the response permanently or temporarily. This way, if the same rule is triggered again, the action is allowed, denied, or terminated based on what answer was given previously with no pop-up query box appearing again either permanently or for some period of time.
For example, if a user is queried as to whether an application can talk on the network and the user responds by selecting the Yes radio button and clicking a Don't ask again checkbox, the Yes response is remembered permanently and that response appears in the edit field in the agent UI query response window. But if the user is queried as whether setup.exe can install software on the system and the user responds by selecting the Yes radio button, but there is no Don't ask again checkbox or it is there but the user does not select it, this response is remembered temporarily and it does not appear in the agent UI query response window.
If the user response is only cached temporarily (for approximately an hour) the user can click the Clear button in this window to delete all temporarily cached responses. To clear permanent responses listed in the edit field, the user must select the response in the edit field and press the Delete key.
Note
Query Rule Priority Information
You should note how CSA MC manages rule priority if there are multiple similar query rules which need to be evaluated.
Base Priority: Action=Allow, Deny Terminate/no challenge/no don't ask again/no logging.
Relative priorities for query options that are turned on are as follows (top to bottom):
•
•
•
•
•
•
Building Policies and Rule Modules
When you configure a policy, you are combining multiple rule modules under a common name. That policy name is then attached to a group of hosts and it uses the rules that comprise the policy to control the actions that are allowed and denied on those hosts. You can have several different types of rules in a rule module and consequently within one policy.
The policy level is the common ground by which host groups acquire the rules that make up their security policy. If you are configuring your own policies, you should begin by understanding the purpose of your policy and how you must build your rule modules to meet your needs. It's recommended that you build your policies from the top down. In other words, configure items in the following manner:
a.
b.
c.
Configure a Policy
Generally, when you configure a policy, you are combining multiple rule modules under a common name. That policy name is then attached to a group of hosts and it uses the rules that comprise the policy to control the actions that are allowed and denied on those hosts. You can have several different types of rules in a rule module and consequently within one policy.
The policy level is the common ground by which host groups acquire the rules that make up their security policy. You can attach rule modules of differing architectures to the same policy. This way, you can configure task-specific, self-contained, inclusive policies across all supported architectures (Windows, Solaris, Linux) for software that is supported on all platforms.
Note
To configure a policy, do the following.
Step 1
Step 2
Step 3
•
•
Step 4
Step 5
This policy is empty until you attach configured rule modules to it.
Figure 4-4 New Policy
Configuring Rule Modules
Rule modules are the building blocks for your policies. Modules are made of several different types of rules. See Chapter 5, "Using System Correlation Rules" for information on event correlation and heuristic rules such as System API control.
Note
Caution
To configure a rule module, do the following.
Step 1
Step 2
Tip
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Refer to the following sections for details on adding, copying, and configuring rules.
Step 9
Figure 4-5 New Rule Module
Setting State Conditions
System State and User State conditions let you write conditional rules based on the state of a system or the user of the system. Therefore, rules are only applied if the configured conditional settings are met.
System State Sets
System state parameters let you dictate conditions based on detected machine settings. When a machine is operating an agent with a configured system state, the rules associated with that state apply only when the state parameters are met. They are conditional rules. For example, if you apply a system state to a rule module, you can dynamically "activate" and "deactivate" rules modules based on the changing state of a system. For example, you can apply special boot time rules that apply only at boot time. After booting is complete, normal operation rule modules are applied. Also, for example, you can apply a looser set of rules if an installation is occurring on a system. Once the installation is complete, a more stringent, normal operating set of rule modules are applied.
Note
For a more detailed description of system state setting options, read the configuration instructions here.
Configure a System State Set by doing the following:
Step 1
Step 2
Step 3
Step 4
Step 5
Note
The Cisco Trust Agent checks the status of a system and reports this status back to the Cisco Secure Access Control Server (ACS). Based on this status check, ACS returns a "posture state" that the Cisco Security Agent can act upon.
For example, if a machine is running anti-virus software that is not up-to-date or is disabled, the Cisco Trust Agent can report this status to ACS which can then return an "Unknown" or a "Quarantine" state. The Cisco Security Agent will then take action based on that posture state and enforce a stricter policy to protect that system or even quarantine the system from the network. Refer to your ACS documentation for information on posture states and what they mean. Possible posture states are:
•
•
•
•
•
•
•
•
Step 6
Step 7
Step 8
Step 9
•
•
•
•
•
Step 10
Note
Caution
Figure 4-6 System State Conditions
User State Sets
User state parameters let you dictate conditions based on detected user and/or group settings. When a machine is operating an agent with a configured user state, the rules associated with that state apply only when the state parameters are met. They are conditional rules. Keep this in mind when assigning a user set to a rule module.
You should also keep in mind that the process of checking user states is an expensive one for the system. You should use these settings judiciously.
An example of when you might want to employ a user state is as a restriction dictating who can alter web server pages. The web server application itself should only serve pages, not edit them. You could use a setting here to ensure that only authenticated administrators using a specific application (e.g. FrontPage) are allowed to alter web server content.
Another example of appropriate user state setting usage is a situation where groups of users are restricted from performing certain tasks that you only want to allow administrators to perform, such as suspending agent security.
Configure a User State Set by doing the following:
Step 1
Step 2
Step 3
Step 4
Step 5
•
Domain_Accounting\AdministratorThis represents the administrator in the Windows domain "Domain_Accounting."•
W2K-jefe\AdministratorThis represents user "Administrator" defined locally on the computer "W2K-jefe."•
*\AdministratorThis represents any user administrator.•
Domain_Accounting\*This represents all users in the domain "Domain_Accounting".You can use wildcards in the Users matching/but not fields.
Step 6
Step 7
•
NT AUTHORITY\SYSTEM•
Domain_Accounting\AdministratorsFor Windows, you can also enter SID (Security Identifier) numerical classifications into the Group matching field. Using a SID rather than a group name is useful when writing states that will apply across international versions of operating systems. Group names may be different across languages, but a SID classification is always the same.
You cannot use wildcards in the Groups matching/but not fields. If users belong to multiple groups, they only need to match one named group to meet the criteria of the user state.
Note
Step 8
Step 9
Figure 4-7 User State Conditions
Adding Rules to a Rule Module
First, click the Modify rules link at the top of the Rule Module page to go to the Rules page. See Figure 4-8.
To add rules to this policy, click the Add rule link in the Rules page. A menu list of the available rule types appears. Click on one to select it. This takes you to the configuration view for this rule type. Note that this rule contains no parameters until you create them.
Figure 4-8 Rule Module, Modify Rules
Note
Use the Enable and Disable buttons in the rule module configuration view to enable or disable rules within a module without having to navigate to the configuration view for that particular rule. Select the checkbox for the rule you want to enable or disable and click the corresponding button. See Figure 4-9.
The ID column in the Rules section is the rule ID number assigned to the particular rule in question. This number increments each time a new rule is created. It is only used as an identifier for the rule. This ID is referenced in Event Log messages and can help you refer back to a particular rule.
The Events column in the Rules section (see Figure 4-10) displays the number of events generated by the rule in the last 24 hours. Clicking this number link takes you to a list of the events themselves.
Figure 4-9 Rules List
Filtering the Rules Display
The Groups configuration page, Policy configuration page, and the Rules configuration page each display a table listing either the rules attached to the group or the rules included in the module (see Figure 4-10). On all of these pages, there is a View All rules item above the table. Clicking the All link here lets you filter your view of this rule list by selected rule type. When you click All, a pop-up appears listing the rule types present in the module or modules. Select a rule type from the pop-up, and that is now the only rule type displayed in the table. You can also select to view only enabled rules by selecting the show enabled rules only checkbox and then select the rule type you wish to view.
Note
This filtering feature is useful when lists of rules grow extensive and you want to pare down your view to specific rule types.
If you have user or system states applied to rule modules, you can also filter the display based on those settings. This is useful to view which rules are applied when particular states are active.
Copying Rules between Modules
Use the Copy button in conjunction with the pulldown lists at the bottom of the Rule Module page to copy selected rules to another rule module that you designate. Copying rules across modules works similar to the way cloning configurations works. (You can also clone rules within policies using the Copy button that will be described in this section.)
To copy selected rules from one module to another module, do the following:
Step 1
Step 2
Step 3
All checked rules are copied to the selected module.
To clone rules within a module, repeat step 1 above. Then, rather than selecting another module in the rule module pulldown list, select the current module you are in from that same pulldown. Selected rules are cloned within the same module when you click the Copy button.
Select from in the pulldown menu beside the Copy button to copy ALL the rules from the selected module (in the rule module pulldown list) to the current module.
Figure 4-10 Copy Rules between Modules
Comparing Configurations
When you select the checkbox next to 2 items (you cannot compare more than 2 configurations at a time) and click the Compare button, CSA MC displays the configurations side by side and highlights the differences in red (see Figure 4-11). Once you've examined how the configurations compare, you can select to merge specific rules, to copy rules to another module, or to copy rules to a new module. Additionally, you can attach and detach groups and policies. (You can compare application classes and variables, but you can only copy and merge rules from the compare page.)
The purpose of this compare tool is to assist you after you've imported configurations or upgraded CSA MC. These processes can cause you to have duplicate or very similar configuration items. Comparing and merging configurations can help you to more easily consolidate duplicate items. This Compare utility is also available for Groups, Policies, Application Classes, and Variables.
Feature notes:
•
•
•
Figure 4-11 Compare Rule Modules
Merging or Copying Rule Modules
Merge or copy rules by selecting the available checkbox above the rule or rules in question. When you click the Copy button in the bottom frame, a pop-up window appears. From this window, you select to do one of the following:
•
•
•
Figure 4-12 Copy Rule Module Pop-up Box
View Change History
At the top of each rule page, there is a View change history link. Click this link to go to a page which lists all the changes that have been made to this rule. This View change history link is also available for Application classes, Variables, Rule Modules, and Policies.
Explanation of Rules
CSA MC provides an explanation, in paragraph form, of the policy in question, describing each rule and its role in the policy. Clicking the Explain rules link in the Groups, Host, Rule Modules, or Policy page, takes you to this paragraph explanation. See Figure 4-13.
Figure 4-13 Rule Explanation Page
Consistency Check
The main rule module page provides an OS consistency check for variables that are part of the rule. For example, it makes sure that Linux applications classes are attached to a UNIX module that has Linux or All UNIX as its target OS. If the rule module has a target OS of Solaris, the consistency check will fail if the application class is marked as Linux.
This consistency check also ensures that modules of a specified OS type are attached to similar OS policies. You are allowed to save modules that do not pass the consistency check so that you can clone items or make multiple policy edits, but you are not allowed to attach and deploy inconsistent items.
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 10, "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
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.
Step 1
Step 2
Step 3
•
•
Step 4
Step 5
•
•
Step 6
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 6, "Using Application Classes".
Note
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.
•
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 stopon UNIX.
Note
•
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 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.
Step 7
Figure 4-14 Agent Service Control Rule (Windows)
Agent UI Control
Note
Also note that 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 Figure 4-15. 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. Optional controls are as follows:
•
•
Add one or more additional controls as follows:
–
–
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.)–
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
•
•
•
•
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 Installs and Uninstalls, page 3-18).
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 4-15 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.
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
Step 1
Step 2
Step 3
•
•
Step 4
Note
Step 5
•
•
Step 6
•
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).
(When your rule is configured, currently selected application classes appear at the top of the list. See Configuring Static Application Classes, page 6-9 for configuration details.)
•
attempt to run
•
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.
•
Note
Step 7
Figure 4-16 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 rating limiting). This is also useful in preventing the propagation of denial of service attacks (client connection rate limiting).
Note
Note
Click the Modify rules link at the top of the Rule Module page to go to the Rules page.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
Step 5
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 6, "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
Step 6
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
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.
Step 8
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.
–
–
Step 9
Figure 4-17 Connection Rate Limit Rule
Data Access Control
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.
An HTTP request consists of:
•
•
•
•
The Data access control rule examines patterns in the URI portion of the HTTP request. The pre-configured Data sets (see Data Sets, page 7-7) group patterns to match based upon
•
•
•
Use the data access control rule to allow or deny specified underlying network data requests for the following web servers and platforms:
•
•
•
Caution
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 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.
See Manual Agent Data Filter Installation, page 10-10 for instructions.
Note
Click the Modify rules link at the top of the Rule Module page to go to the Rules page.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the listed data sets 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 6, "Using Application Classes".•
Note
Step 7
Click the Insert Data Set link to enter a pre-configured data set here. When you click this link, a list of the Data Sets you've configured appears here, allowing you to select 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 configuring Data Sets, see page 7-6.
Step 8
Note
Figure 4-18 Data Access Control Rule
File Access Control
Use file access control rules to allow or deny what operations (read, write) selected applications can perform on files. You should understand that file protection encompasses read/write access. Directory protection encompasses directory deletes, renames, and new directory creation.
Note
Click the Modify rules link at the top of the Policy page to go to the Rules page.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the listed files 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 6, "Using Application Classes".•
Note
Step 7
Select the operations Read and/or Write you are allowing/denying on the files named in the Files field. For directory protection, the actions you are allowing/denying are Create, Delete, and Rename. Refer to File and Directory protection in Using the Correct Syntax, page 2-28.
Caution**\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 8
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've configured appears here, allowing you to select one or more. 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 Using the Correct Syntax, page 2-28.
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
For network machines (Windows only), enter\\<machine name>\<share>\<path>\<filename>For example:
*:\Program Files\winnt\*You can enter more than one file path, but each entry must appear on its own line. For File Set configuration details, see page 7-10.
Caution
/etc/hosts. If you want to protect a symbolic link and its underlying resource, both must be specified in the rule.
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
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. See Manage Dynamically Quarantined Files and IP Addresses, page 5-23 for more information.Step 9
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.
Caution
Figure 4-19 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.
Note
Step 1
Step 2
Step 3
•
•
Step 4
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
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. For application class configuration details, see Chapter 6, "Using Application Classes".•
Step 7
From the pulldown menu, select server, client, client or server, or listener (see page 70 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.Step 8
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.
This field refers to either a server providing this service or a client accessing this service. For Network Service configuration details, see page 7-18.Step 9
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.
If you select 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.•
Use @local to indicate all local addresses on the agent system. 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 Using the Correct Syntax, page 2-28 for more valid @ entries that can be used in this rule type.
Step 10
Enter the literal network address(es) for the local system addresses you want to control (i.e. control clients making connections from or control servers making connections to). You can also click the Insert Network Address Set link to enter a pre-configured network address set variable here.
The addresses or address ranges you enter here can be used to control the host initiating the network connection. For example, you could write a Network access control rule which would only allow laptop users to connect to an internal network database if their connection is coming through a VPN (i.e. machine using an allowed/disallowed address to make a connection, incoming or outgoing). If the connection attempt comes in through an ISP-assigned address that is not part of this rule, it would not be allowed.
You could also use this field to impose a restriction that only trusted addresses can read an internal server. If the connection is received from an internal system or via a VPN from a fixed, trusted address, it is allowed.
Use @dynamic in the Addresses set field to indicate untrusted hosts that have been quarantined by CSA MC. Addresses are added to this list when they are seen as an untrusted host. (The built-in "Processes Communicating with Untrusted Hosts" is triggered in a rule.) This list updates automatically (dynamically) as logged quarantined addresses are received.
Step 11
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. You should note that new rules only apply to new connections. See Preserving Application Process Classes, page 6-8 for details.
Caution
Note
Note
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 4-20 Network Access Control Rule
Windows Only Rules
The following rules are only available for Windows Rule Modules.
Clipboard Access Control
Use the clipboard access control rule to dictate which applications can access information that is written to the clipboard. When writing security policies, you may want to protect 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, the data is marked as protected. Only processes which also match the specified application classes are allowed to read the data from the clipboard. When a process that does not belong to the application class specified writes to the clipboard, the data is marked as unprotected. Any process is allowed to read from the clipboard then.
For example, if Microsoft Excel (which is part of the Microsoft Office application class) saves data to the clipboard, other Microsoft Office applications will be able to read the clipboard data to allow cut and paste functionality between Office applications. Non-Office applications would be prevented from reading this clipboard data.
These instructions are a continuation of Configuring Rule Modules.
Step 1
Step 2
Step 3
•
•
Step 4
•
When your rule is configured, currently selected application classes appear at the top of the list.
•
Step 5
Note
Figure 4-21 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
These instructions are a continuation of Configuring Rule Modules.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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 4
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the selected COM components 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 6, "Using Application Classes".•
Step 7
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 10-9 for instructions.
PROGID's, use the following syntax:
Outlook.ApplicationWhen entering CLSID's (uppercase hexadecimals) using the following syntax, you must include the brackets shown here:
{000209FF-0000-0000-C000-000000000046}Step 8
Figure 4-22 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
Note
Step 1
Step 2
Step 3
•
•
Step 4
Step 5
•
•
Step 6
Enter the File you are prohibiting (You will enter the exact version in the next field.) This field accepts file entries for
@system\**,/etc/passwd, and\\<machine name>\<share>\<path>\<filename>files. Enter just the file name here. No path is required.For example:
\\Backup_Server\finance\records\database.dbYou cannot use wildcard entries in this field.
Step 7
Enter the version or version range (using a dash to indicate range) of the file you entered in the previous field.
For example:
Outlook.Application{000209FF-0000-0000-C000-000000000046}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
Step 8
Figure 4-23 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.
Note
Step 1
Step 2
Step 3
•
•
Step 4
Step 5
•
•
Step 6
•
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.
Caution
•
When modules are detected modifying the system, selecting this checkbox causes the system in question to log this event. You can use this detection to create dynamic rootkit application classes and to change the system state to a state that enforces a more restrictive policy.
You should only create Allow exceptions for actions you believe are safe. For example, virus-scanners and kernel debuggers might legitimately trigger this rule. Enters module data in the following edit fields:
–
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.sysae45e23b45093dffa899\**ae45e23b45093dffa899\**\uphcleanhlp.sys–
By default, this field contains <all> . The wizard enters code patterns (not inside any module) into this field.
Step 7
Figure 4-24 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.
Note
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
•
•
Note
Step 5
•
The choices are—System, Application, Security
•
The event source is the software that logged the event, which can be either an application name, such as.exe, or a component of the system or of a large application, such as a driver name. For example,.dllindicates the EtherLink II driver.•
The choices are—Information, Warning, Error, Audit Success, Audit Failure
•
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, and Q301677.Step 6
Note
.ocxin the Event Source edit box. See Installation Applications Policy, page 5-19 for more information.Figure 4-25 NT Event Log Rule
Registry Access Control
Use registry access control rules to allow or deny applications from writing to specified registry keys.
Note
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the selected registry keys 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 6, "Using Application Classes".•
Step 7
Click the Insert Registry Set link to select one or more pre-configured registry sets for this rule. See Included Registry Sets, page 7-23 for details on included operating system registry values.
Note
Step 8
This rule is now part of your rule module. It takes effect when the policy to which it is associated is attached to a group and then downloaded by an agent on the network.
Caution
Figure 4-26 Registry Access Control Rule
Service Restart
Use the Service restart rule to have the agent restart Windows NT services that have gone down on a system or are simply not responding to service requests.
Note
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
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:
•
•
Step 5
Select one or both of the following checkboxes.
•
•
Caution
Step 6
Note
Figure 4-27 Service Restart Rule
Sniffer and Protocol Detection
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
These instructions are a continuation of Configuring Rule Modules.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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 4
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:
PacketDriverIn this example, Windump is the application. The libcap packet capture driver registers using the name PacketDriver.
Step 5
Note
Figure 4-28 Sniffer and Protocol Detection Rule
UNIX Only Rules
The following rules are only available for UNIX Rule Modules.
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.
These instructions are a continuation of Configuring Rule Modules.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the selected resource(s) 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 6, "Using Application Classes".Step 7
Select one or more of the following checkboxes:
•
Note
•
Note
Conversely, if you have selected a Deny radio button, 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.Step 8
Note
Figure 4-29 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:
•
•
•
These instructions are a continuation of Configuring Rule Modules.
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
Step 5
Cautioniexplore.exedoes not protect0-5.00.3314.2100. Similarly, a File access control rule written for5.00.3314.2100-5.50.4522.1800does not protectSQL Server. If you want to protect a symbolic link and its underlying resource, both must be specified in the rule.
Figure 4-30 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.
Note
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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 4
For further details on rule action types, see Rules: Action Options and Precedence.Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the selected resource(s) 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 6, "Using Application Classes".•
Step 7
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
Step 8
Figure 4-31 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.
Note
Step 1
Step 2
Step 3
•
This description appears in the list view for the module. Optionally, expand the +Detailed field to enter a longer description.•
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
•
•
Note
Step 5
•
The event source is the software that logged the event, which can be an application name such asElnkii, a kernel level driver module such asNorton AntiVirus, or thePacketDriverkernel itself.•
•
•
Step 6
Note
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:/etc/hosts
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 eri0To get every message of category "warning" from the
/sbin/dhcpagent daemon, you would configure your syslog rule in the following manner (See Figure 4-32):Select the "Include events matching the following" radio button and enter:
•
•
•
•
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/4To 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:
•
•
•
•
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@0To 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:
•
•
•
•
Figure 4-32 Syslog Control Rule
Attaching Rule Modules to Policies
When you configure a rule module, you are combining access control rules and/or tagging and monitoring rules under a common name. That rule module name is then attached to a policy. That policy uses the rules that comprise the module to control the actions that are allowed and denied on hosts. See Configuring Rule Modules.
CSA MC gives you the option of attaching a rule module to a policy using the Modify policy associations link in the Rule Module configuration page or attaching a policy to a rule module using the Modify rule module associations link in the Policy list view page.
To attach a rule module or rule modules to an existing policy using the Modify policy associations link in the rule module configuration page, do the following.
Step 1
Step 2
Step 3
Step 4
Note
Caution
Figure 4-33 Rule Module Associations
Attaching Policies to Groups
When you configure a policy, you are combining configured rule modules under a common name. That policy name is then attached to a group of hosts and it uses the rules that comprise the policy to control the actions that are allowed and denied on those hosts. See Configuring Rule Modules.
CSA MC gives you the option of attaching a policy to a group using the Modify policy associations link in the Group configuration page or attaching a group to a policy using the Modify group associations link in the Policy list view page. (You can use the Modify policy associations link to attach multiple policies to a group and use the Modify group association link to attach one policy to multiple groups.)
To attach a policy or policies to an existing group using the Modify policy associations link in the Group configuration page, do the following.
Step 1
Step 2
Step 3
Step 4
Note
Figure 4-34 Attaching Policies
Note
Using Test Mode
Test Mode is useful when you are installing a new host or are modifying a host configuration and want to understand the ramifications without actually impacting host operation. When operating in test mode, the agent will not deny any action or operation even if an associated policy says it should be denied. Instead, the agent will allow the action but log an event if a deny or query rule is triggered (if logging is enabled for the rule) and log an event when an allow rule with logging enabled is triggered. This helps you to understand the impact of deploying a policy on a host before enforcing it. If examining the logs shows you that the policy is working as intended on a group, you can then remove the Test Mode designation.
When using Group test mode, you'll likely also want to enable Verbose Logging mode. This way, the agent will not suppress any log messages as it normally does when several of the same log messages are received.
When an agent running in test mode sends events to CSA MC, event log messages are preceded with the words "Test mode". There are some exceptions to this. For example, event log messages related to detected events such as port scans and malformed packets are not preceded by the words "Test mode." Event detection (not prevention) messages appear the same in the event log regardless if test mode is on or off.
Group Test Mode
You can turn on test mode in two places within the MC. If it is enabled on the group level (see Figure 4-35), all rules on hosts within test mode groups are in test mode.
If a host belongs to a group with test mode selected, all policies associated with that host are in test mode (even if the host is part of another group that does not have test mode selected), not just the policies applied to the test group. Therefore, test mode applies to the host as a whole, not to specific policies.
Figure 4-35 Group Test Mode
Rule Module Test Mode
You can also use test mode on the rule module level (see Figure 4-36). This way, you can have the rules within the test mode module operating in test mode while rules from other modules assigned to the same host are operating in a live mode. This is useful for testing new rule modules or changes to existing modules without having to turn off all protections for the hosts in question.
Caution
Figure 4-36 Rule Module Test Mode
Generating Rule Programs
Caution
The Generate rule programs view displays the status of all non-distributed database items with the name of the administrator who made the configuration changes. A Details link appears beside each edited configuration item. Click this link to view what modifications were made to the configuration in question.
Note
Figure 4-37 Generate Configuration
