-
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
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 8, "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 12-11 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 6-10 COM Component Access Control Rule
File Version Control
Use the File version control rule to control the software versions of applications users can run on their systems. For example, if there is a known security hole in one or more versions of a particular application, this rule would prevent those specific versions from running, but would allow any versions not included in this rule to run unimpeded.
One particular example where this type of rule would be beneficial is in the case of Microsoft Security Bulletin (MS01-020). This bulletin states the following: "Because HTML e-mail messages are Web pages, Internet Explorer can render them and open binary attachments in a way that is appropriate to their MIME type. However, there is a flaw in the type of processing that is specified for certain unusual MIME types. If a malicious user creates an HTML e-mail message that contains an attachment that can be run and then modifies the MIME header information to specify that the attachment is one of the unusual MIME types that Internet Explorer handles incorrectly, Internet Explorer may run the attachment automatically when it renders the e-mail message."
Microsoft has a patch to correct this security problem, but the patch is only available for Internet Explorer 5.01 Service Pack 1 and IE 5.5. If users are running an earlier version of IE, they must upgrade to 5.01 or 5.5 and install the correct service packs and patches to correct the problem. Therefore, earlier versions of IE contain an unfixable security problem and you will want to prevent users from running these versions. The following configuration information uses the IE security bulletin as an example.
Note
Note
Step 1
Step 2
Step 3
•
•
Step 4
Step 5
•
•
Step 6
Select one or more preconfigured application classes here to indicate the application(s) whose access to the file(s) 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
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 8
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 9
Figure 6-11 File Version Control Rule
Kernel Protection
Use the Kernel protection rule to prevent unauthorized access to the operating system. In effect, this rule prevents drivers from dynamically loading after system startup. You can specify exceptions to this rule for authorized drivers that you are allowing to load any time after the system is finished booting.
You can also use this rule to only detect unauthorized access to or modification of the operating system at any time. This rule also detects if a system was booted in a non-standard, insecure manner.
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.
•
When a system has previously booted in a non-standard manner, selecting this checkbox causes a message to be sent to the event log. A boot is considered standard if the system was booted from the primary hard disk. Any other boot type, for example, booting from a peripheral device (CD ROM) or a hard disk that is not the primary, is considered non-standard. A non-standard boot may be considered suspicious. (e.g., This is one way of circumventing the Cisco Security Agent and introducing a Trojan to a system.)
The insecure boot detection this checkbox enables works in conjunction with a particular type of compatible BIOS on compliant systems. The compatible BIOS detects a non-standard boot and on the next normal boot, if you have this checkbox selected, a message is sent to the MC which logs this insecure boot detection. (If a Host is running a BIOS that supports this insecure boot detection feature, the individual Host details page will indicate this. From the CSA MC menu bar, click Systems>Hosts. Then click on the link for an individual host. The Host Status section includes a category named "BIOS supported boot detection".)
Note
–
By default, this field contains <all> . You can use provided tokens here to only detect certain boot types as insecure or to exclude a particular boot type from the detection. Available tokens are:
@fixed - This indicates a fixed hard disk that is not the primary disk. (Compatible BIOS is required to detect this.)
@network - This indicates all network shares. (Compatible BIOS is required to detect this.)
@removable - This indicates all removable media. That includes, floppies, CDs, zip drives, etc. (Compatible BIOS is required to detect this.)
@safemode - This indicates the detection of a system having booted in any debug mode in which the agent does not load. (Detecting this is not BIOS dependent.)
Step 7
Figure 6-12 Kernel Protection Rule
NT Event Log
Use the NT Event log rule to have specified NT Event Log items appear in the CSA MC Event Log for selected groups.
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 7-4 for more information.Figure 6-13 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, page 5-38.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 8, "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 9-27 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 6-14 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.
•
•
Step 6
Note
Figure 6-15 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, 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
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 6-16 Sniffer and Protocol Detection Rule
System API Control Rule
The System API control rule detects several forms of malicious programming code that is installed on a system by an unsuspecting user either thinking that he or she is running some other type of program, or as a result of some other activity such as reading an attachment to an email message. Once installed, these malicious programs (for example, Trojans) may allow others to access and virtually take over a system across the network. Other errant programs may be set up to automatically send mail messages or other types of network traffic (including system passwords) while the system owner is unaware of what is occurring.
Note
It could be useful, especially in the case of server systems, to use a service restart rule in conjunction with a System API control rule. This way, if you are forced to press the Terminate button if queried by a triggered rule and you subsequently terminate the application in question, a service restart rule will cause the application to automatically restart.
Use the System API control rule in a policy to detect and prevent errant programs from performing malicious acts on individual systems and networks. The included System API control rule lets you enable several different types of system detection. See Figure 6-17. To configure a System API rule, do the following:
Step 1
Step 2
•
•
Step 3
For further details on rule action types, see Rules: Action Options and Precedence, page 5-38.Step 4
•
•
Step 5
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".•
targeting (where applicable)
The "targeting" application class selections are only applicable to following checkbox items on this page: Inject code into other applications; Write memory owned by other applications. A targeting option is available for these items because these actions (injecting code and writing memory) involve two or more parties. These parties include the one that is initiating the action and the process(es) being affected. Providing an optional targeting selection in these cases for choosing particular application classes allows for further configuration granularity.
Step 6
Use this field to indicate applications that may be targeted for code injection or memory writing.
•
attempt the following operations:
System Information Checks
•
Detect applications that attempt to read system registry settings.
•
Detect applications that attempt to steal local system passwords.
System Monitoring Checks
•
Detect applications that attempt to capture system keystrokes.
•
This checkbox lets you control which applications can monitor media devices on the system. Media device "inputs" can be exploited by Trojans which can, for example, turn on the microphone on a system and covertly listen to a conversation.
Patterns to be included: Use the Wizard from the Event log message in question to include particular devices in a System API "allow" rule. You must specify media devices as "device\port". For example,
iexplore.exe.
Note
System Modification Checks
•
Detect applications that attempt to directly access physical memory while bypassing virtual memory restrictions.
•
Detect applications that download ActiveX controls and immediately attempt to execute them.
This functionality limits applications from downloading ActiveX controls (signed and unsigned). This type of behavior is generally typical of a web browser and sites that require the downloading of ActiveX can trigger this rule. Note that this rule may be unnecessary if system web browser settings are configured with a "High" security level that would restrict the downloading of ActiveX controls.•
Detect applications that are attempting to write code to space owned by other applications. e.g. injecting a malicious .dll into a privileged process.
•
Detect applications that attempt to interfere with the memory space of other applications or detect Trojans attempting to hide in another executable to escape detection and gain permissions to access other resources.
Atypical System Behavior Checks
•
Although this behavior is sometimes exhibited by downloaded/executable content (e.g. license checking software), this may be symptomatic of a buffer overflow attack.
–
•
Detect processes running exception handling routines. This typically occurs due to bugs in the application software. But this may be a sign of an attack if this occurs with an application that does not generally exhibit this behavior.
•
Use this checkbox to detect processes invoking system calls that are rarely used. In normal system operation, many system calls are either never used or may only be used infrequently by a specific system application performing a service. Attempting to exploit undetected flaws in these unusual system calls is common attack vector for malware.
–
You also have the ability to select specific application classes to exclude from the various System API control rules you designate. For example, in some cases, debuggers may perform actions that can be misconstrued as malicious behavior. Therefore, you would want to create an application class, and select it as an exclusion to one or more System API control rule features.
Figure 6-17 System API Control Rule
Replicate Feature
When you make rule changes and click the Save button for rule types that contain multiple checkboxes, such as System API control rule (Network shield and Buffer overflow rules also provide this feature) a "replicate" link appears beside the "Saved changes" message at the top of the rule page. Click on replicate to access a pop-up box. From this box, you select other policies that contain System API control rules and choose to propagate the same change(s) you made on the current page to System API control rule pages in other policies. If the change you make to one System API control rule page is a change you need to make to all System API control rules in all your policies, this is a quick way to propagate those changes on a wide or even global scale.
UNIX Only Rules
The following rules are only available for UNIX Rule Modules.
Buffer Overflow Rule
A buffer overflow is what happens when two conditions are met: Firstly, an application is coded in a manner such that it trusts that all users of that application will provide the application with reasonable and expected data. Secondly, the application is provided larger quantities of data than it is capable of correctly handling. When these events come together, an application can behave in unexpected and unintentional ways.
For applications with special privileges, this can result in external users gaining access to machine resources and privileges which they normally would not be able to acquire. In other words, a hostile, network-based attack on a privileged, trusted application via buffer overflows can result in undesirable parties gaining access to your system.
In the case of UNIX operating systems, there are three distinct types of
buffer overruns which can occur, based upon the type of memory space involved: stack, data, and heap.•
•
•
Note
Configure the Buffer overflow rule as follows.
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 here.
Note that the entry, <All Applications>, is selected by default. You can use this default or you can unselect it and create your own application classes. For application class configuration details, see Chapter 8, "Using Application Classes".But not in the following class—Optionally, select application classes here to exclude from the application class(es) you've selected in the included applications field. Note that the entry <None> is selected by default.
Step 7
•
Enable this checkbox to detect buffer overflow conditions which occur in UNIX executables. This feature provides protection from stack buffer overflows to a number of commonly used libc routines. As a large number of attacks on UNIX systems are based upon buffer overflow attacks, it is recommended that you enable this feature. Processes terminated by operating system due to executing code in stack space.
•
Use this checkbox to prevent certain system calls (e.g. those which grant extra privileges or start new processes) from occurring if they are invoked in an unsafe manner, or if they appear to have come from a corrupted or invalid context.
•
This checkbox enables the "noexec_user_stack" system variable for all processes or for processes added to the <*Processes requiring OS Stack Execution Protection>. See Built-in Configurable Application Classes, page 8-7 for details. This checkbox monitors the execution of instructions from stack memory. This only provides logging.
•
Processes can be killed on a system by either another process or by an internal error occurring on the system. This checkbox causes the agent to monitor when this occurs. The only action type available when this checkbox is enabled is Monitor.
•
Use this checkbox to prevent the usage of the '%n' *printf() format qualifier. Numerous attacks utilize the '%n' format on *printf() routines to gain access to program control flow information.
You also have the ability to select specific application classes to exclude from the various Buffer overflow types you designate. If you select an application in the available list beside a checkbox rule, that rule does not apply to the selected application class. If you have multiple, similar Buffer overflow rules, the application class exceptions are combined.
Note
Figure 6-18 Buffer Overflow Rule
Network Interface Control
Use the Network interface control rule to specify whether applications can open a device and act as a sniffer (promiscuous mode). A packet sniffer is a program that monitors and analyzes network traffic. Using this information, a network manager can troubleshoot network problems. A sniffer can also be used illegitimately to capture data being transmitted on a network. Sensitive information such as login names and passwords can be extracted from this data and used to break into systems.
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 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 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 8, "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 6-19 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, 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 module and it will not be distributed to groups.Step 4
Step 5
Caution0-5.00.3314.2100does not protect5.00.3314.2100-5.50.4522.1800. Similarly, a File access control rule written forSQL Serverdoes not protectElnkii. If you want to protect a symbolic link and its underlying resource, both must be specified in the rule.
Figure 6-20 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, page 5-38.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 8, "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
•
When a system has previously booted in a non-standard manner, selecting this checkbox causes a message to be sent to the event log. A boot is considered standard if the system was booted from the primary hard disk. Any other boot type, for example, booting from a peripheral device (CD ROM) or a hard disk that is not the primary, is considered non-standard. A non-standard boot may be considered suspicious. (e.g., This is one way of circumventing the Cisco Security Agent and introducing a Trojan to a system.)
The insecure boot detection this checkbox enables works in conjunction with a particular type of compatible BIOS on compliant systems. The compatible BIOS detects a non-standard boot and on the next normal boot, if you have this checkbox selected, a message is sent to the MC which logs this insecure boot detection. (If a Host is running a BIOS that supports this insecure boot detection feature, the individual Host details page will indicate this. From the CSA MC menu bar, click Systems>Hosts. Then click on the link for an individual host. The Host Status section includes a category named "BIOS supported boot detection".)
–
By default, this field contains <all>. You can use provided tokens here to only detect certain boot types as insecure or to exclude a particular boot type from the detection. Available tokens are:
@fixed - This indicates a fixed hard disk that is not the primary disk. (Compatible BIOS is required to detect this.)
@network - This indicates all network shares. (Compatible BIOS is required to detect this.)
@removable - This indicates all removable media. That includes, floppies, CDs, zip drives, etc. (Compatible BIOS is required to detect this.)
Step 8
Figure 6-21 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 asNorton AntiVirus, a kernel level driver module such asPacketDriver, or theplantronics\microphonekernel 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 6-22):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 6-22 Syslog Control Rule
