-
Using Management Center for Cisco Security Agents 5.2
-
Using Management Center for Cisco Security Agents 5.2
-
Preface
-
Overview
-
Management Center for Cisco Security Agents Administration
-
Configuring Groups and Managing Hosts
-
Building Policies
-
Rule Module Configuration
-
Available Rule Types
-
Using Global Event Correlation
-
Using Application Classes
-
Configuring Variables
-
Event Logging and Alerts
-
Generating Reports
-
Using Management Center for Cisco Security Agents Utilities
-
Using Cisco Security Agent Analysis
-
Cisco Partner and Third Party Product Integration
-
Using the Scripting Interface (CSAAPI)
-
Cisco Security Agent Overview
-
System Components
-
Open Source License Acknowledgements and Third Party Copyright Notices
-
Table Of Contents
Rules Common to Windows and UNIX
Sniffer and Protocol Detection
General Syslog rule configuration examples
Available Rule Types
Overview
Rule modules contain various types of rules. Each rule type is intended to control a different set of system resources. For example, there is a rule type that controls access to files and directories and another rule type that controls network accesses. It is through the combining of the many available rule types that a rule module provides overall security to the entire system. This chapter provides information on each rule type.
This section contains the following topics.
•
Rules Common to Windows and UNIX
•
Rules Common to Windows and UNIX
The following rule types are available for both Windows and UNIX policies.
Agent Service Control
Use the Agent service control rule to control whether administrators are allowed to stop agent security (This is via a net stop command on Windows or via /etc/init.d/ciscosec stop on UNIX. See Chapter 12, "Using Management Center for Cisco Security Agents Utilities," for details) and whether end users can disable security via the agent UI security slide bar. Stopping agent security disables all rules until security is manually resumed or the system is rebooted.
If you use this rule to deny agent service stops, the agent service cannot be stopped on the system in question and therefore agents cannot be uninstalled.
Note
You can also use this rule to monitor, terminate, or tag a process that attempts to modify the agent configuration.
These instructions are a continuation of Configuring Rule Modules, page 5-5.
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 8, "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 6-1 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 6-2. In the absence of this rule, end users have no visible agent UI. If this rule is present in a module, you can select to display the agent UI and one or more controls to the end user. These controls give the user the ability to change certain aspects of their agent security. 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-23).
When there is no agent UI present, there are no query user pop-up boxes displayed. The default is immediately taken on all query user rules and heuristics that are present in the assigned polices.
If an end user system already has an agent UI installed, when you unselect the Allow user interaction checkbox and generate rules, the agent UI disappears when the new rules are downloaded.
Figure 6-2 Agent UI Control Rule
Application Control
Use Application control rules to control what applications can run on designated agent systems. This rule type does not control what application can access what resources as do other access control rules. This rule type can stop selected applications from running on systems. If you deny an application class (in total) in this rule, users cannot use any application in that class.
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 8-8 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 6-3 Application Control Rule
Connection Rate Limit
Use the connection rate limit rule to control the number of network connections that can be sent or received by applications within a specified time frame. This is useful in preventing attacks aimed at bringing down system services, e.g. denial of service attacks (server connection 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 8, "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. Selecting the "different" hosts option would be beneficial for controlling outgoing connections. For example, if a system on your network has been infected by a network worm, you could control the worm replication by tracking how many different hosts the infected system is trying to connect to and setting a limit to those connections. If you only tracked all host connections in this case, you may cut the system off from legitimate server access, for example.
Step 8
In this field, you could select the 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). 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.
Step 9
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 10
Figure 6-4 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 9-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 servers) and Linux (Apache servers), in order to use Data access control rules you must install the data filter manually after you install the Cisco Security Agent. Unlike Windows, the Solaris and Linux installations do not detect Web server software and do not install the data filter with the agent. You must always manually install it.
See Manual Agent Data Filter Installation, page 12-12 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, page 5-38.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 8, "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 9-7.
Step 8
Note
Figure 6-5 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, page 5-38.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 8, "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-35.
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-35.
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 9-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 7-8 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 6-6 File Access Control Rule
Network Access Control
Use network access control rules to control access to specified network services and network addresses. You can also use this rule type to listen for applications attempting to offer unknown or not sanctioned services.
Note
Step 1
Step 2
Step 3
•
•
Step 4
For further details on rule action types, see Rules: Action Options and Precedence, page 5-38.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 8, "Using Application Classes".•
Step 7
From the pulldown menu, select server, client, client or server, or listener (see page 31 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 9-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-35 for more valid @ entries that can be used in this rule type.
Step 10
Step 11
In this field, you could select the 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). 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 12
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 8-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 6-7 Network Access Control Rule
Network Shield Rule
The Network shield rule provides network protocol stack hardening capabilities.
Note
Step 1
•
•
Step 2
Note
Step 3
•
•
Step 4
Caution
IP Security checks
•
Enabling this feature causes the Cisco Security Agent to perform an integrity check on the IP packet header. This includes performing a consistency check on the IP header, on the length of the IP header, and on the number of bytes in the packet. If you configure this as a Deny rule, the following occurs: if any of these checks fail, the packet is dropped, if an IP checksum fails, the packet is dropped, IP options and IP fragments are validated as well and dropped if they are found to be invalid. (This defeats attacks such as Teardrop, Boink, and Ping of Death.)
•
IP addresses are determined to be invalid for several reasons: if the source address is a multicast address, if the TCP connection is to a broadcast address. You can select this checkbox as part of a Deny rule to protect against these types of attacks.
•
This detects IP options which control explicit routing instructions for packets. With IP source routing (an IP header option) the originator of a packet can try to partially or completely control the path through the network to the destination.
•
This detects the mapping of network topology via trace route.
Transport Security checks
•
This check ensures that transport headers are the proper length and that they are consistent (have enough data in the packet for them to fit). This includes verifying that certain fields have valid values and that certain combinations of TCP flags are legal. This defeats attacks such as a Christmas Tree scan.
•
SYN flooding is a type of denial of service attack. It occurs when a TCP/IP connection request is received from a return address that is not in use (i.e. a non-existent host for a spoofed address) resulting in a half open connection. An abundance of half open states on a server can prevent legitimate connections from being established. Detecting and preventing SYN floods stops this attack from succeeding.
Servers that are external to your network and not protected by a firewall should be protected against SYN floods. Firewalls generally provide this protection.
Note
•
If you configure this as a Deny rule, this check causes agents to make TCP sequence numbers unpredictable.
A server accepting connections using predictable TCP sequence numbers may be tricked into accepting a connection from a malicious source that is spoofing a trusted host. This prevents that vulnerability.
(This rule type is not available for UNIX policies as the UNIX OS already provides this protection.)
Note
•
Port scanning is a common method for finding weaknesses at a site by determining what network services are being run. An attacker attempts to connect to port after port on a target system, mapping ports to identify network services and machine type vulnerabilities. Configure this rule to log an event when an attempt is made to scan the system for an open port. Information is also gathered on the number of different source IP addresses perpetrating the scan and it reveals the source. In most cases, you should apply port scan detection to servers and end-user systems in your enterprise.
Configure this rule as a Deny rule to prevent unauthorized port scans, effectively cloaking a system on the network. Denying port scans causes a system to not respond to connectivity tests and to not respond to service requests with connectivity error messages.
A system generally sends out error messages when a remote machine sends a request for a service which is not running on the system. Often, this is how remote machines locate other systems and obtain network information about the system in an attempt to target it for an attack. By not responding, this prevents both UDP and TCP-based port scans of the system and basically hides it on the network.
If you are running an allowed service on a system and you are denying port scans, connection requests to this service are honored and your machine is viewable for the service you're offering.
Note
•
This check works similar to the TCP/UDP port scan feature, but for ping scans. See the port scan description for information.
•
If you configure this rule as a Deny, this feature restricts messages which can change the configuration of a machine. For example, a redirect can be used to cause routing tables to be updated.
•
Some ICMP messages may be used to gather information about a machine in an attempt to attack it. This data, when obtained, can be used to gather system information which can be used to exploit the system. If you configure this rule as a Deny, this feature restricts messages which report back on system or network configuration.
•
Configuring this rule as a Deny, causes agents to drop unsolicited echo responses.
The Cisco Security Agent validates that the echo response data matches the echo request data. This way, ping cannot be used as a transport for communications.
•
Configuring this rule as a Deny causes agents to block packets which are technically legal but are known exploits against protocol stacks (e.g. UDP packet storm or RF poison).
System Startup Security checks
•
Configuring this feature as a Deny, prevents non-essential network connections during system startup. This check is automatically disabled when the agent service starts and policies (including those which govern allowed network connections) are enforced. This protects the system from network-based attacks at boot-time before the agent service has started.
(This rule type is not available for UNIX policies.)
Note
Note
Step 5
Optionally, you can enter specific addresses here for those checkbox features in this rule that support addressing parameters.
Step 6
Step 7
Step 8
Figure 6-8 Network Shield Rule
Note
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, page 5-5.
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 6-9 Clipboard Access Control Rule
COM Component Access Control
Use COM component access control rules to allow or deny applications from accessing specified COM components. COM is the Microsoft Component Object Model, the technology that allows objects to interact across process and machine boundaries as easily as within a single process. Each of the Microsoft Office applications (Word, Excel, Powerpoint, etc.)
exposes an "Application" COM component which can be used to create macros or utility scripts. While this is useful functionality, it can be used
maliciously by an inadvertently downloaded Visual Basic script.An example would be the Mydoom virus, which propagated by using the "Outlook.Application" COM component to send itself to each entry in the local address book. Using the COM component access control rule, you can protect specific COM components. For example, you could create a rule which limits access to Office components (Word.*, Outlook.*, Excel.*, etc.)only to the Office applications themselves. Non-Office applications (such as the Visual Basic scripting engine) would therefore be denied access to these components.
Note
These instructions are a continuation of Configuring Rule Modules, page 5-5.
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, page 5-38.Step 5
•
•
Step 6
