Release Notes for Symantec Critical System Protection Version 5.2.8 MP3… · 2012-05-14 ·...

Release Notes for SymantecCritical System ProtectionVersion 5.2.8 MP3

Revision Date: May 10, 2011

Chapter 1 Release 5.2.8 MP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

About the Release Notes for Symantec Critical SystemProtection .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

About Symantec Critical System Protection .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7What's new in release 5.2.8 MP3 .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Additional platform support ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8About copying alerts ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Kill any process with Symantec Critical System Protection new

detection policy ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Tightened thread injection rules in the Windows policies ... . . . . . . . . . . . 10Option added in the template policies to record certain number

of events generated in a specified time interval ... . . . . . . . . . . . . . . . . . . 10Resolved issues ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

SISIDSRegDrv.sys blue screen error ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Policy updated .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Windowssystemperformancedegradationwithcirculardirectory

symbolic links ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Updated monitored file lists in the Unix Baseline policy ... . . . . . . . . . . . . . 11Continuous system restart or system startup failure ... . . . . . . . . . . . . . . . . . . 12Incorrect processing of alert filter with wildcard .... . . . . . . . . . . . . . . . . . . . . . . 12Incorrect parameter label in the Baseline detection policy ... . . . . . . . . . . 12Silent installation works as expected .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Support for optional modifier reference in a network rule ... . . . . . . . . . . 13Degraded systemperformance on systems running a significant

number of processes while Symantec Critical SystemProtection agent is installed .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Known issues ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Symantec Critical System Protection does not record SU

operations logoff events ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Local port parameter does not work for network outbound TCP

connection control ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 2 Release 5.2.8 MP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

What's new in release 5.2.8 MP2 .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Additional platform support ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Contents

Targeted prevention policy ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16About the duplicate agent registration settings ... . . . . . . . . . . . . . . . . . . . . . . . . . 23Disabling duplicate agent registration .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Resolved issues ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Systems with heavy network load experienced higher CPU

usage .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24The System_Failed_Access_Status policy now records the login

failure for batch job .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Root level failed telnet logon is now recorded by Symantec

Critical System Protection .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25The continuous file change alerts donot occurwhenyouupgrade

the Symantec Critical SystemProtection 5.2.6MP2 agent toany new agent version .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

The Windows_template_policy allowed adding identical valueand comment entries in the filewatch list ... . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Symantec Critical System Protection detection service start orrestart triggered excessive filewatch events ... . . . . . . . . . . . . . . . . . . . . . . . 25

Blue screen error no longer occurs ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Symantec Critical System Protection policies now retain the

policy values after export and import ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26UserName information forWindowsEvent Log events no longer

appear blank .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Windows Detection Policy now provides the flexibility to add

date and time restrictions to each rule in System AuditTampering .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Timeout dialog boxnowdisplays the console name it is connectedto .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Symantec Critical System Protection now displays the correctcount of registered agents in the System Summary queryresult ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Known issues ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Cannot use an optional user name reference in a network

rule ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Successful FTP logons by root are not recorded by Symantec

Critical System Protection .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapter 3 Release 5.2.8 MP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

What's new in release 5.2.8 MP1 .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29IDS features ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Contents4

Chapter 4 Release 5.2 RU8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

What's new in release 5.2.RU8 .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31IDS and IPS features ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31IPS features ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Additional release information .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Logging of previous user ID to track privilege escalation on IPS

events ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Use of Tomcat 5.5.33 .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Restart required .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61You must upgrade Solaris x86 agents before you upgrade your

Symantec Critical System Protection management serversto release 5.2 RU8 .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Microsoft SQL Server 2000 is no longer supported .... . . . . . . . . . . . . . . . . . . . 62Build ID version numbers are now synchronized .... . . . . . . . . . . . . . . . . . . . . . . 62

What you need to know before you install or upgrade yoursoftware .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Legal Notice ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5Contents

Contents6

Release 5.2.8 MP3

This chapter includes the following topics:

■ About the Release Notes for Symantec Critical System Protection

■ About Symantec Critical System Protection

■ What's new in release 5.2.8 MP3

■ Resolved issues

■ Known issues

About theReleaseNotes for SymantecCritical SystemProtection

This document may be revised between releases, as new information becomesavailable. You can view the latest information by clicking the following link tothe Release Notes PDF:

http://www.symantec.com/business/support/index?page=content&id=DOC547&key=52463&actp=LIST

Review the Release Notes in their entirety before you install or deploy SymantecCritical ProtectionSystem, or call for technical support . This document describesknown issues and provides additional information that is not included in thestandard documentation or the online help.

About Symantec Critical System ProtectionWelcome to Symantec Critical System Protection, a flexible, multi-layer securitysolution for servers that detects abnormal system activities. Symantec CriticalSystem Protection prevents and blocks viruses and worms, hacking attacks, and

1Chapter



zero-day vulnerability attacks. Symantec Critical SystemProtection also hardenssystems, enforcing behavior-based security policies on clients and servers.

Symantec Critical System Protection includes a management console and servercomponents, and agent components that enforce policies on computers. Themanagement server andmanagement console runonWindowsoperating systems.The agent runs on Windows and UNIX operating systems.

Among Symantec Critical System Protection's key features are:

■ Predefined application policies for commonMicrosoft interactive applications

■ Out-of-the-box policies that continuously lock down the operating system,high-risk applications, and databases to prevent unauthorized executablesfrom being introduced and run

■ Microsoft Windows, Sun Solaris, IBM AIX, and Linux platform support

Among Symantec Critical System Protection's key benefits are:

■ Provides proactive, host-based security against day-zero attacks

■ Offers protection against buffer overflow and memory-based attacks

■ Helps to maintain compliance with security policies by providing granularcontrol over programs and data

What's new in release 5.2.8 MP3

Additional platform supportThe 5.2.8 MP3 release adds support for the following platforms:

Support for IPSSupport for IDSPlatform

YesYesSolaris 10 U10

YesYesRed Hat Enterprise Linux 5.7/5.8

-YesSolaris 11

About copying alertsSymantec Critical System Protection Copy Alerts function lets you create copiesof alerts. For example, if there are existing alerts with complex filters and youwant to create another alert with similar filters and some additional filters, youcan copy an existing alert and add the required filter to it instead of creating analert from the start.

Release 5.2.8 MP3What's new in release 5.2.8 MP3

8

The copied alert appears in the formatCopyof_Alertname. For example, a copiedalert for an existing alert named ALERT1 would appear as Copy of_ALERT1.

Creating copies of alertTo create copies of alert

1 Log on to the management console.

2 Click the Monitors tab.

3 Click Alerts.

4 In the AlertsConfiguration pane, right-click an alert and select CopyAlert.

Kill any process with Symantec Critical System Protection newdetection policy

ThisWindows detection policy attempts to kill any process that acts as an injecteeor an injector. The Kill_Prevention_PSET policy is used in combination with theprevention policies. When Kill_Prevention_PSET policy is applied to an agent,all processes routed to thread_injectee_nopriv_ps or thread_injector_nopriv_psare killed by using the taskkill.exe application.

Note: The processes are routed to thread_injectee_nopriv_ps orthread_injector_nopriv_psPSETsonlywhenyouapply the IPSpolicy andconfigurethe policy to detect thread injection. By default, the thread injection is enabled inthe core, strict, and limited execution prevention policies.

Following are the Kill_Prevention_PSET policy options:

The prevention policy applies this option only when it finds thatthe unauthorized code is injected into a specific process.

Kill all thread injecteeprocesses

The prevention policy applies this option only when it finds thatthe process has injected the code into another process against thepolicy restrictions.

Kill all thread injectorprocesses

It kills any process that is routed to it.

To enable this option, check Show advanced options.

Kill New Processes in aSpecific PSET

9Release 5.2.8 MP3What's new in release 5.2.8 MP3

Tightened thread injection rules in the Windows policiesSymantec Critical System Protection has tightened the injection rule. Now, ondetection of thread injection, it blocks the whole injectee process instead ofblocking the injectee thread.

Symantec Critical System Protection now provides additional option to confinethe injected process. To enable this option:

1 Edit any Windows prevention policy.

2 Under Settings > Global Policy Options > Additional parameter Settings,check If a thread injection is detected , confine the injected process to a NoPrivilege PSET.

Option added in the template policies to record certain number ofevents generated in a specified time interval

Symantec Critical System Protection enables you to record the number of eventsgenerated for a specific time interval. For example, you can track the number oflogon failures for a specific time interval. You can enable the Number of Eventsin an Interval option in the Windows and Unix template policies. Once you haveenabled this option, the logon failure information is captured in the customapplication log file.

Resolved issues

SISIDSRegDrv.sys blue screen errorOn Windows systems with Symantec Critical System Protection installed, youexperienced blue screen errorwhenyou configured the detectionpolicy tomonitorregistry changes. This issue is uncommon, but it can occur with the out-of-boxWindowsBaselineDetectionpolicy or anyother detectionpolicy that you configureto monitor the registry values. The Windows agent software has been updated tofix this issue.

Affected operating systems: Windows operating systems

Affected Symantec Critical System Protection versions: Release 5.2.8 and earlier

Affected Symantec Critical System Protection policy: Not Applicable

Release 5.2.8 MP3Resolved issues

10

Policy updatedESX protection policy (revision 198) was released with Symantec Critical SystemProtection version 5.2 RU7 MP3. An older version of the ESX protection policy(revision number 192) was erroneously included in 5.2 RU8 and later releases. Anupdated version of the ESX protection policy (revision number 199) is includedin this release.

Affected operating systems: ESX 4.X

Affected Symantec Critical SystemProtection versions: Release 5.2 RU8, 5.2 RU8MP2

Affected Symantec Critical System Protection policy: ESX protection policy

Windows system performance degradation with circular directorysymbolic links

Fix ID: 2773303

There is degradation in system performance for Symantec Critical SystemProtection installed on the Windows operating systems. This issue occurs if youconfigure the Symantec Critical SystemProtection tomonitor files and directoriesby using either an IPS driver (even with a null policy) or Real-Time File IntegrityMonitoring on a system that has directory symbolic links referencing in a circularmanner. The Windows agent software has been updated to fix this issue.

Affected operating systems: Windows 2008/2003/XP(32-bit and 64-bit)



Updated monitored file lists in the Unix Baseline policyIn the Unix Baseline Detection policy, the List of Core System Files is updated toinclude correct files and directories in the monitored file list. Also, the ignore listis updated to contain only the subset of monitored file list.

Affected operating systems: Linux and UNIX operating systems

Affected Symantec Critical System Protection versions: Release 5.2 RU7, 5.2RU8

Affected Symantec Critical System Protection policy: Unix Baseline Detectionpolicy

11Release 5.2.8 MP3Resolved issues

Continuous system restart or system startup failureWhen you enable the prevention features on Windows systems with SymantecCritical System Protection installed, creation of symbolic registry links is highlyrestricted. Since the Windows prevention policy does not provide control ofregistry symbolic link creation explicitly, it is possible to configure the preventionpolicy in such a way that it can unintentionally deny legitimate registry symboliclinks during the system startup. In this case, the system would not bootsuccessfully or can fail with a blue screen error based on the processes that wereaffected. The Windows prevention policy has been updated to allow creation ofregistry symbolic links for registry resources that are writable.



AffectedSymantecCritical SystemProtectionpolicy:Windowspreventionpolicies

Incorrect processing of alert filter with wildcardWhen you use an alert filter operator Not Contain with the wildcard character *in an alert filter configuration to generate email alerts, incorrect filtering occurredwith unexpected results. This issue is fixed now.

Affected operating systems: All operating systems



Incorrect parameter label in the Baseline detection policyIn the previous versions, Symantec Critical System ProtectionWindows Baselinedetectionpolicy contained incorrect labels forEventID(s) fields andweredisplayedin the detection policy editor dialog and console.

TheWindows baseline policy has been updated to display correct labelEventID(s)in the detection policy editor dialog and console.


Affected Symantec Critical System Protection versions: Release 5.2 RU6 through5.2 RU8

Affected Symantec Critical System Protection policy: Windows Baseline policy


12

Silent installation works as expectedWhena command line or anunattended installation fails on theWindowsplatformdue to incorrect parameters, it also fails to remove the temporary folders used bythe installer. Once this failure occurs, subsequent installation also fails until thetemporary folders are removedmanually. TheWindows Installer has beenupdatedto remove the temporary folders upon installation failures to allow successfulinstallations.




Support for optional modifier reference in a network ruleIn the previous versions, if an optional modifier was used in a network rule andif the parameter was undefined or defined but empty, the prevention policyapplication failed with policy translation error.

Symantec Critical System Protection now lets you add an optional modifierreference (- ) in a network rule. For example, you can add the optional modifierreference (-) in a network rule such as %-port_list%, where the port_list is notrequired to be defined or can be empty. If the optional parameter is not present,the specific network rule is omitted during policy processing and the rest ofprevention policy content is applied.

Affected operating systems:Windows, RedHat Enterprise Linux, Suse EnterpriseLinux and Solaris


Affected Symantec Critical System Protection policy: Prevention policies

Degraded systemperformanceon systems runninga significant numberof processes while Symantec Critical System Protection agent isinstalled

When installing Symantec Critical System Protection agent on systems withprevention feature enabled, system performance degrades noticeably when thesystem has a large number of active processes. This can happen with anyprevention policy including the null policy. Symantec Critical System Protectionmaintains a data structure that contains information about all the active processesand dead processes whose children are active. For every file system access call,the Symantec Critical System Protection kernel driver traverses this list ofinformation. The traversal time of linked lists increaseswith the number of active


processes in the system, leading to system-wide performance degradation. Thefix replaces the linked listwith ahashed list, allowing formuchhigherperformanceduring information lookup. This fix reduces the access time to the data structureresulting in improved performance.

Affected operating systems: All supported operating systems with prevention(IPS) feature

Affected Symantec Critical System Protection versions: Release 5.2.8 MP2 andearlier


Known issues

Symantec Critical System Protection does not record SU operationslogoff events

If youhave enabled the SUoperations option in theUnixBaselineDetectionpolicy,SU logoff events are not captured.

Affected operating systems: Solaris 10 and 11

Affected Symantec Critical System Protection versions: Release 5.2.8

Affected Symantec Critical System Protection policy: UNIX Baseline Detectionpolicy

Local port parameter does not work for network outbound TCPconnection control

The use of local port to control outbound TCP network connection does not workon Windows 2003 (64-bit).

Affected operating systems: Window 2003 (64-bit)

Affected Symantec Critical System Protection versions: All versions

Affected Symantec Critical System Protection policy: All versions

Release 5.2.8 MP3Known issues

14

Release 5.2.8 MP2



■ Resolved issues

■ Known issues

What's new in release 5.2.8 MP2

Additional platform supportThe 5.2.8 MP2 release adds support for the following platforms:

■ The Symantec Critical System Protection now supports the IDS features onthe computers that run Red Hat Enterprise Linux 6.2 operating systems.

■ The Symantec Critical System Protection now supports the IDS features onthe computers that run Red Hat Enterprise Linux 5.7 operating systems. Itdoes not load any kernel driver.

Note: If youupgrade fromRHEL5.6 toRHEL5.7with agent installed and youhaveenabled prevention, then you must uninstall the agent and reinstall the release5.2.8 MP2 agent.

2Chapter

Targeted prevention policy

About the Targeted prevention policyThe Targeted prevention policy lets you define a set of baseline controls for theentire system. For example, you can apply buffer overflowprotection to the entiresystem and no other prevention.

The Targeted prevention policy allows access to all resources by default and letsyou block access or modifications to resources that you have configured in thepolicy options. It also provides you the ability to customize the policy accordingto your need by adding custom programs in the policy.

Policy file name for Windows operating systems:sym_win_targeted_prevention_sbp

Policy filename forUNIXoperating systems:sym_unix_targeted_prevention_sbp

The Targeted prevention policy includes an SCSP self protection option. Whenthe SCSP self protection option is selected, it protects against a user or a processtampering with the Symantec Critical System Protection configuration data orprogram data.

For example, the following configuration data is protected as the write access isblocked and logged whereas the read access is blocked but not logged:

■ The Certificate files on server, console, and agent

■ The server configuration file tomcat\conf\server.xml

■ The IPS agent configuration file IPS\agent.ini

■ The IDS agent configuration file IDS\agent.ini

The following configuration data and program data is protected as read-only:

■ All files under the agent install directory

■ All files under the agent log directory

■ All Symantec Critical System Protection driver files

The following directories are protected against being renamed:

■ The agent install directory

■ The agent log directory

The Targeted prevention policy provides the following options:


16

Provides a set of global options that applies to all the processesin the system.

When you apply global options in the policy, it is applied toall the PSETs in the policy.

Global Policyoptions

Provides a set of options to configure the Built-In PSETs.

TheWindowsTargetedpreventionpolicy contains fourbuilt-inPSETs to handle Kernel Driver controls, Remote File Accesscontrols, Symantec Critical System Protection Agent andServer controls. TheTargetedpreventionpolicy always routesthese processes to the built-in PSETs. You cannot overridethese built-in PSETs.

Built-In PSEToptions

The Targeted prevention policy routes all processes to theDefault PSET with the exception of Built-In PSETs.

You can configure all protection features in theDefault PSET.

Default PSEToptions

Define one or more custom program within the policy tooverride the security settings in the Default PSET.

Additionally, you can also define custom lists which can bereferenced elsewhere in the policy.

My CustomPrograms

Note: If you setDisable Prevention at a global level, then Symantec Critical SystemProtection disables prevention for all PSETs. You cannot enable prevention in aCustom PSET or a Default PSET.

See “How the Targeted prevention policy works” on page 17.

See “About using custom lists with the Targeted prevention policy” on page 19.

See “About using custom programs with the Targeted prevention policy”on page 18.

How the Targeted prevention policy worksThe Targeted prevention policy includes a set of Built-In PSETs to control accessto the kernel and Symantec Critical System Protection processes. You cannotoverride a Built-In PSET. However, you can configure the Built-In PSETs by usingthe policy options.

With the exception of the Built-in PSETs, the Targeted prevention policy routesall processes to the Default PSET. All protection features are configurable in theDefault PSET. However, the Default PSET can be overridden by adding a customprogram to the policy. One or more custom programs can be defined within thepolicy which will override the security settings in the Default PSET.


See “About the Targeted prevention policy” on page 16.



About using custom programs with the Targeted preventionpolicyThe Targeted prevention policy lets you create custom programs based on thefollowing templates:

Use the fully open custom program template to build-up securityprotections. By default, it has no security restrictions. All processesassigned to the fully open custom program have no default resourcerestrictiondefined.Moreover, protection features suchasbuffer overflowdetection, thread injection are also disabled.

See “Creating custom programs based on the fully open template”on page 20.

Fully opentemplate

Use the fully closed custom program template to relax securityprotections. All processes assigned to the fully closed custom programare denied access to all resources and all protection features are enabledby default. The protection features such as buffer overflow detection,thread injection are also enabled by default.

See “About using the fully closed customprogram template” onpage 18.

See “Creating custom programs based on the fully closed template”on page 22.

Fully closedtemplate



About using the fully closed custom program templateYou can use the fully closed custom program template in the following ways:

■ If you do not want a program to run at all, then you can create a fully closedcustom program and route the program to this custom program PSET.

Note: This method does allow the program to run, although the program isblocked from accessing any file, registry, or network resources.


18

■ If you want to strictly limit a program regarding the resources it can access,you can create a fully closed custom program. Youmust configure the customprogramandallowwrite access to only the resources this programneeds accessto, while allowing read access to all resources on the system.

By default, the fully closed custom program denies access to all resources andlogs all access attempts as trivial. Since, all access attempts are logged as trivial,you can enable trivial logging for this custom program to see what resources theprogram attempts to access.

Symantec recommends you to configure the customprogram to allow read accessto all resources on the system, and to only allow write access to the resources asrequired by this custom program.

To determine what resources the custom program needs write access to

1 Edit the file and registry rules in the custom program and place a wildcardin the Read-only Resource Lists:

■ Block modifications to these files

■ Block modifications to these Registry keys

2 Enable logging of trivial policy violations in the custom program underGeneral Settings.

3 Disable prevention in the custom program.

Apply this policy to the agent, and then execute the custom program. The trivialevents generated will show what resources the program is accessing for writeaccess. You canuse these events to configure the customprogramand allowwriteaccess to the appropriate resources. Once you have determined the specificresources the program needs write access to, you can then enable the preventionin the custom program.


See “Creating custom programs based on the fully closed template” on page 22.

About using custom lists with the Targeted prevention policyThe Targeted prevention policy lets you create generic program lists and genericstring lists. You can refer to these custom lists in other parts of the policy. Youcan access these custom lists by editing the Targeted prevention policy in themanagement console.


The generic program list contains a list of programs.

In themanagement console, the generic program list appearsas set of applications to be referenced later.

Generic Programlist

The generic string list contains a list of users, groups, networkaddresses, or network ports.

In themanagement console, the generic string list appears aslist of items to be referenced later.

Generic String list



Creating custom programs based on the fully open templateThe Symantec Critical System Protection Targeted prevention policy lets youcreate custom programs based on the fully open template.

To create a custom program based on the fully open template

1 In the management console, click Prevention View.

2 On the Policies page, click the Symantec folder and then in the workspacepane, double-click sym_win_targeted_prevention_sbp.

3 In the policy editor dialog box, click My Custom Programs, and then clickNew.

4 In the New Custom Control Wizard dialog box, specify the followinginformation:

Type a descriptive name.

Example: Notepad

Display Name

SelectThisCustomProgramPSETis fullyopen, ithasnodefault security restrictions.

Category

Type aname that the policy uses internally. The identifiermust not include spaces or special characters.

Example: NotepadID

Identifier

Type a full description.Description

5 Click Finish.


20

6 In the policy editor dialog box, click My Custom Programs > Notepad >Settings.

7 In the Notepad Settings pane, double-click Notepad[cust_Notepad_ps] anddo the following:

■ Check and expand This Custom Program PSET is fully open, it has nodefault security restrictions, and then click List of programs to route tothis custom PSET .

■ In the List of programs to route to this custom PSET section, click Add,and then add the following path:C:\Windows\system32\notepad.exe

■ Check Enable SCSP Self Protection.

8 In the policy editor dialog box, double-click Resource Lists > Read-onlyResource Lists and do the following:

■ Check and expand Block modifications to these files, and then click Listof files that should not be modified.

■ In the List of files that should not be modified section, click Add, andthen add the file path that you do not want to be modified. For example,test.txt.

9 Click OK and apply the policy on the agent.

10 On the agent computer, open the test.txt file and verify the following events:

PPST,655,2011-09-09 20:02:38.919 Z-0400,I,,,b3218cab450cde2dde92d225489f4ee0,e,,,WIN2K8-R2\Administrator,0,C:\Windows\system32\NOTEPAD.EXE,3844,,"& quot 1;C:\Windows\system32\NOTEPAD.EXE & quot 1

C:\temp\test.txt",create,cust_notepad_ps,2360,,,,C:\Windows\Explorer.EXE,,,\WINDOWS\SYSTEM32\SHLWAPI.DLL,3464,,

The Notepad.exe gettingassigned to the custompset cust_notepad_ps

PFIL,656,2011-09-09 20:02:38.593 Z-0400,W,,R,b3218cab450cde2dde92d225489f4ee0,e,,,WIN2K8-R2\Administrator,0,C:\Windows\system32\NOTEPAD.EXE,3844,D,

C:\temp\test.txt,NtCreateFile, cust_notepad_ps, ffffffff,c0000022,00120089,,,,00000001,\WINDOWS\SYSTEM32\KERNELBASE.DLL,3464,,

Denied File Access Eventwhen the test.txt isaccessed by usingnotepad



See “Creating custom programs based on the fully closed template” on page 22.

Creating custom programs based on the fully closed templateThe Symantec Critical System Protection Targeted prevention policy lets youcreate custom programs based on the fully closed template.

To create a custom program based on the fully closed template

1 In the management console, click Prevention View.

2 On the Policies page, click the Symantec folder and then in the workspacepane, double-click sym_win_targeted_prevention_sbp.

3 In the policy editor dialog box, click My Custom Programs, and then clickNew.

4 In the New Custom Control Wizard dialog box, specify the followinginformation:

Type a descriptive name.

Example: Services

Display Name

Select This Custom Program PSET is fully closed and locked down bydefault.

Category

Type a name that the policy uses internally.

Example: Services

Identifier

Type a full description.Description

5 Click Finish.

6 In the policy editor dialog box, check Services[cust_Services_ps], and do thefollowing:

■ Check and expand ThisCustomProgramis fullyclosedandlockeddownbydefault, and then click List ofprograms to route to this customPSET.

■ In the List of programs to route to this custom PSET section, click Add,add the following path:C:\Windows\system32\tlntsvr.exe

■ Check Child processes remain in this custom PSET.

■ Check Enable Buffer Overflow Protection.


22

■ Check Enable Thread Injection Detection.

7 Click OK and apply the policy on the agent.

8 Open the log file from the following path:

C:\ProgramFile(x86)\Symantec\Critical SystemProtection\Agent\IPS\scsplog

9 Verify that tlntsvr.exe is routed to the definedCustomPSET, cust_Services_psand remaining processes are routed to the Default PSET.

See “Creating custom programs based on the fully open template” on page 20.

See “About using the fully closed custom program template” on page 18.


About the duplicate agent registration settingsYou can disable the registration of duplicate agents with themanagement server.By default, Symantec Critical SystemProtection lets you register duplicate agentsbased on some common attributes such as IP address, agent name, and so on.WhenSymantecCritical SystemProtection recognizes aduplicate agent, it updatesthe existing agent record in the database with the new agent data and flags theagent for policies and configs.

SymantecCritical SystemProtection evaluates the uniqueness of each agent basedon the following attributes:

■ Primary attributes

■ Agent name

■ Host name

■ IP address

■ Secondary attributes

■ Domain name

■ Operating system type

See “Disabling duplicate agent registration” on page 23.

Disabling duplicate agent registrationSymantec Critical System Protection enables you to prevent registration ofduplicate agents.


To disable duplicate agent registration

1 In the management console, click Prevention View or Detection View.

2 Click Admin.

3 Click System Settings.

4 Click Agent settings.

5 Check Detect Duplicate Agent Registration.

6 Check attributes under Primary Agent Attributes for Duplicate AgentIdentification and Secondary Agent Attributes for Duplicate AgentIdentification.

You must select at least one primary attribute.

7 Click Save.

See “About the duplicate agent registration settings” on page 23.

Resolved issues

Systems with heavy network load experienced higher CPU usageThe issue that caused the Active Directory servers to carry heavy network load,experience 100 percent CPU utilization caused by Symantec Critical SystemProtection sisidsservice and network driver, is fixed now.




The System_Failed_Access_Status policy now records the login failurefor batch job

Initially, the System_Failed_Access_Status policy did not record event 529 withLogon type: 4, which occurs when you specify invalid credentials for creating abatch job. Now, the policy is updated to record the batch job login failures.



AffectedSymantecCriticalSystemProtectionpolicy: System_Failed_Access_Status,Windows Baseline policy


24

Root level failed telnet logon is now recorded by Symantec CriticalSystem Protection

Symantec Critical SystemProtectionnow records the failed root logon event setupby Kerberos telnet. The Unix Baseline policy and the agent are updated to recordthe failed root logons.

Affected operating systems: All Linux and UNIX operating systems

Affected Symantec Critical System Protection versions: All versions of SymantecCritical System Protection

Affected Symantec Critical System Protection policy: Unix Baseline policy

The continuous file change alerts do not occur when you upgrade theSymantec Critical System Protection 5.2.6 MP2 agent to any new agentversion

The issue that caused continuous file change alerts when you updated the 5.2.6MP2 agent to any new agent version is fixed now.


Affected Symantec Critical System Protection versions: Release 5.2 RU8


The Windows_template_policy allowed adding identical value andcomment entries in the filewatch list

In the previous version, youwere able to add identical value and comment entriesin the filewatch list. Now, if you try to add identical value and comment entries,an error message appears.

Affected operating systems: All supported operating systems for the SymantecCritical System Protection console


Affected Symantec Critical System Protection policy: Windows_template_policy

Symantec Critical System Protection detection service start or restarttriggered excessive filewatch events

In the previous version, if you started or restarted Symantec Critical SystemProtection detection service that resulted into incorrect filewatch events being


found. Now when you perform Symantec Critical System Protection detectionservice start or restart, no incorrect filewatch events generate.


Affected Symantec Critical System Protection versions: Release 5.2 RU8


Blue screen error no longer occursThe issue that caused a blue screen error to occur in Windows Server (withAnywhereUSBproduct installed)with Symantec Critical SystemProtection agentinstalled has been fixed.




Symantec Critical System Protection policies now retain the policyvalues after export and import

When you export a policy, its default parameters are exported in theoption-settings.sbp file. When you import a policy, the Parameter values inoption-settings.sbp and those in the compiled policy settings are merged. Hence,when amerged parameter fromoption-settings.sbpmatches a parameter alreadyin the compiled policy, the parameter from the compiled policy is overwritten.

Now, when you import the policy, the Import option deletes the matchingparameter in compiled policy settings resulting in policy values retention duringexport and import.




User Name information for Windows Event Log events no longer appearblank

The Event Viewer now displays the User Name information for Windows EventLog events correctly for User and Group Change Monitor rule.



26



Windows Detection Policy now provides the flexibility to add date andtime restrictions to each rule in System Audit Tampering

In the previous version, you were able to add the date and time restrictions inSystem Audit Tampering globally. Now, the Windows Baseline policy is updatedto let you add date and time restrictions to individual rule under System AuditTampering. This allows granularity in case youwant to specify different date andtime values for different rules. For example, if you do not want Symantec CriticalSystem Protection to alert when security events from Windows Event Viewer arecleared during a specific time period, you can enable the date time restrictionunder Security Log Events Deleted. Now, this date time restriction won't affectother rules under System Audit Tampering.



AffectedSymantecCritical SystemProtectionpolicy:Windows_Baseline_Detection

Timeout dialog box now displays the console name it is connected toIn the previous versions, when multiple consoles were connected to differentmanagement servers with timeout console feature activated for all consoles, itwas difficult to identify which timeout dialog box was associated with whichconsole. Now, the timeout dialog box title displays the console name it is associatedto.




Symantec Critical System Protection now displays the correct countof registered agents in the System Summary query result

In the previous version, if you run the System Summary query, the TotalRegistered Agents count and Count by OS field appeared blank. Now, this issueis fixed and Symantec Critical System Protection displays the correct count ofregistered agents and agents count based on their specific operating system.





Known issues

Cannot use an optional user name reference in a network ruleIf any optional field in a network rule is undefined or defined but empty, the entirerule is removed from the policy for that agent. For example, if a rule referencesan optional list for remote IP address and an optional list for remote port, and ifthe remote IP list is defined but the remote port list is not defined, then the rulewill be removed.

The workaround for this issue is to add an asterisk (*) in the Program path fieldin the rule. This causes the user name field to be obeyed.



Successful FTP logons by root are not recorded by Symantec CriticalSystem Protection

Symantec Critical System Protection does not record the successful FTP logonsby root. The successful FTP logon information is maintained in the syslog file.

The workaround for this issue involves you to manually find the FTP logoninformation in the /var/syslog file. Youmust configure the VSFTPD service to logthe FTP connection information in the syslog file.

Affected operating systems: RHEL 6.1(64-bit)


Release 5.2.8 MP2Known issues

28

Release 5.2.8 MP1



What's new in release 5.2.8 MP1This release contains the following notable features:

■ IDS support for AIX 7.1

■ Real-time file integrity monitoring on AIX 5.3 and 6.1

IDS features

AIX 7.1 supportThe Symantec Critical System Protection now supports the IDS features oncomputers that run AIX 7.1 operating systems.

The Unix Baseline Detection policy provides you all the IDS features on AIX 7.1operating system. For example, file monitoring in polling mode, logon or logoffand failed logon monitoring, user or group configuration monitoring etc.

Note: Real-time file integrity monitoring and IPS are currently not supported onAIX 7.1.

Real-time file integrity monitoring for AIXThe Real-time file integrity monitoring is supported on the following versions ofAIX operating system:

■ AIX 6.1

3Chapter

■ AIX 5.3 (64-bit kernel)

Each time you change the policies, Symantec Critical System Protection agentdecides whether to use real-time file integrity monitoring or more traditionalpoling-based file integrity monitoring.

You use the real-time file integrity monitoring to monitor all files except for thefollowing:

■ File systems that aremounted from remote servers. For example, NFS or SMBfile systems exported by remote systems and mounted on the AIX system.If any policymonitors the files on the remote file systems, then those files aremonitored by using polling-based file integrity monitoring.

■ Portions of local file systems that have been exported via NFS.TheSymantecCritical SystemProtection agent uses the ‘exportfs –v’ commandto determine what is being exported. All directories exported via NFS aremonitored using polling-based file integrity monitoring. Rest of the portionof the local file systems aremonitoredusing real-time file integritymonitoring.

Note: The Symantec Critical System Protection agent executes the ‘exportfs –v’command only when the IDS daemon starts or when new detection policies areapplied to the system. If the system administrator modifies the list of exportswhen the system is running, the Symantec Critical System Protection agent willnot notice the change. The administrator shouldmanually restart the IDSdaemonafter making any changes to the exported NFS configuration to ensure theSymantec Critical System Protection agent is using the updated information.


30

Release 5.2 RU8


■ What's new in release 5.2.RU8

■ Additional release information

■ What you need to know before you install or upgrade your software

■ Legal Notice

What's new in release 5.2.RU8

IDS and IPS features

Additional platform and feature supportThe 5.2.RU8 release adds support for the following platforms:

■ TheSymantec Critical SystemProtection agent now supports the IDS featureson computers that runRedHat Enterprise Linux 6.0 and 6.1 operating systems(64-bit only).

■ The Symantec Critical System Protection agent now supports both the IDSfeatures and the IPS features on computers that run SUSE Linux EnterpriseServer 10 SP4.

■ The Symantec Critical System Protection manager, console, and agent (bothfor IDS and IPS) now run on computers that runWindows Server 2008R2 SP1.

■ Theuse of an optional user in a policy,whichwasmade available for computersthat run Linux and AIX in release 5.2 RU7, is now supported on computersthat run Windows and Solaris.

4Chapter

User and group names in policy options can be marked as optional. If thetranslator cannot look up the user or group, it is omitted from the policy ratherthan resulting in a translation error.You enter an optional user name or group name in prevention policies byadding a dash (-) before the user name or group name. For example, youwoulduse -administrator tomake the administrator user nameoptional. In this case,the policy is applied even if the user name is not available in the system. If youuse administrator (with no dash) instead, the presence of the administratorname is mandatory, and the policy fails to apply if it is not available. Thissyntax can be used even if the user names or group names are in environmentvariables or registry keys.

Note:This feature is implemented in the agent, so it is only available on Solariswhen you use release 5.2 RU8 and later agents.

■ Many of the IDS and IPS policy enhancements included in previous releasesfor other operating systems are now available on computers that run Solarisoperating systems.

The agent for computers that run Solaris 9 and 10 now includes the following IDSand IPS policy enhancement support:

■ UNIX Baseline Detection policy

■ The following IDS file integrity monitoring features:

■ SHA-256 hashing

■ File hash checking on every update

■ Text log monitoring supports Unicode


■ Custom IPS PoliciesYou can now define custom program definitions in a separate policy. Thisfeature provides flexibility in sharing those definitions among several groupsof assets and in combining themwith other custompolicies or base preventionpolicies.

■ IPS option consistencyOptions that let you specify a file and a process that can use that file areavailable in all resource lists in the IPS policy.

Release 5.2 RU8What's new in release 5.2.RU8

32

■ IPS translator options

■ Wildcards and netmasks in IP addresses

■ Local subnet translator functions


Note: Real-time file integrity monitoring is not currently supported on Solaris.

Support for syslog-ngSymantec Critical System Protection now supports syslog-ng on computers thatrun Solaris 9 and 10 operating systems.

Configuring syslog-ng and rsyslog for usewith theSymantecCritical SystemProtection IDS agent

TheSymantecCritical SystemProtection IDSagent supports the syslogd, syslog-ng,and rsyslog system logging daemons. The standardUNIX system logging daemonshould work without any additional user configuration.

If syslog-ng and rsyslog were installed with their configuration and their startscripts in nonstandard locations, then you may need to perform additionalconfiguration steps to get the Symantec Critical System Protection IDS agent towork properly with them. We provide the following information about theSymantec Critical System Protection IDS agent's assumptions regarding thesystem logging daemon so that you can adjust your configuration to conform tothese assumptions.

For the latest information on this topic, see the following URL:

Additional configuration stepsmay be required for the Symantec Critical SystemProtection IDSAgent toworkproperlywith syslog-ng and rsyslog loggingdaemons

About system logging daemon selection

You can explicitly configure the Symantec Critical System Protection IDS agenttomake use of a particular logging system. You can use Syslog Daemon key in theSystem Collector section of the LocalAgent.ini file for this purpose. Any changesto this setting do not take effect until the sisidssaemon is restarted.

The relevant section of the LocalAgent.ini file is as follows:

33Release 5.2 RU8What's new in release 5.2.RU8

http://clientui-kb.symantec.com/kb/index?page=content&id=HOWTO54685

http://clientui-kb.symantec.com/kb/index?page=content&id=HOWTO54685

[Syslog Collector]

#Syslog Daemon=DEFAULT

The valid values for the Syslog Daemon key are as follows:

■ DEFAULT

■ SYSLOGD

■ SYSLOGNG

■ RSYSLOGD

When you specify any value other than DEFAULT, the Symantec Critical SystemProtection IDS agent attempts to configure and make use of that type of systemlogger. The installed logger must conform to the assumptions that are outlinedin the following topics:

See “About system logging daemon configuration” on page 34.

See “About the system logging daemon script ” on page 35.

If the Symantec Critical System Protection IDS agent fails to configure and startthe system logger that is specified in the LocalAgent.ini file, or if a system loggertype is not explicitly specified, then the IDS agent attempts to detect the loggingdaemon in use by querying the running process list and looking for the processnames in the following order:

■ syslogd

■ syslog-ng

■ rsyslogd

If the IDS agent does not find one of those processes, it then attempts to start thelogging daemons in the following order:

■ syslogd

■ syslog-ng

■ rsyslogd

See “About the system logging daemon script ” on page 35.

About system logging daemon configuration

The Symantec Critical System Protection IDS agent assumes that the systemlogging daemon configuration files are in the following locations:

■ syslogd: /etc/syslog.conf

■ syslog-ng: /etc/syslog-ng/syslog-ng.conf

■ rsyslogd: /etc/rsyslog.conf


34

If the configuration files are not located at their assumed locations, then youmustcreate a symlink from the assumed path to the actual path. For example, on RHEL5.4, syslog-ng installs its configuration at /usr/local/etc/syslog-ng.conf, but it canbe located anywhere, depending upon the build configuration options that wereused when the package was created. For example, you might use the following tocreate a link:

ln -s /etc/syslog-ng.conf /usr/local/etc/syslog-ng.conf

About the system logging daemon script

TheSymantecCritical SystemProtection IDSagent uses the following commandsto start the system logging daemons:

On Linux/Solaris 9:

■ syslogd: /etc/init.d/syslog start

■ syslog-ng: /etc/init.d/syslog start

■ rsyslogd: /etc/init.d/rsyslog start

On Solaris 10:

■ syslogd: /usr/sbin/svcadm enable svc:/system/system-log

■ syslog-ng: /usr/sbin/svcadm enable svc:/system/system-log

■ rsyslogd: /usr/sbin/svcadm enable svc:/network/rsyslog

On HP-UX:

■ syslogd: /sbin/init.d/syslogd start

■ syslog-ng: /sbin/init.d/syslog-ng start

■ rsyslogd: /sbin/init.d/rsyslogd start

On AIX:

■ syslogd: /usr/bin/startsrc -s syslogd

■ syslog-ng: /usr/bin/startsrc -s syslog-ng

■ rsyslogd: /usr/bin/startsrc -s rsyslogd

On Tru-64:

syslogd: /usr/sbin/syslogd -e

Configuring syslog-ng to work with Symantec Critical System Protectionon Solaris 10

The Symantec Critical System Protection agent requires the configuration file tobe located at /etc/syslog-ng/syslog-ng.conf. It also requires that the SMF service


namebe the sameas syslogd: svc:/system/system-log. If youneed touse an existingconfiguration, you should symlink it.

For information about creating a symlink to an existing configuration, see step 2

If syslog-ng is already set up with different SMF configuration names, you mustrename them to system-log.

Note: You must start the syslog-ng daemon in background process mode ratherthan the default foregroundmode. Starting it in foregroundmodemakes it appearthat two instances are running. The Symantec Critical System Protection agentis not able to monitor if two instances are running. You should add the--process-mode=background line to the syslog-ng startup script.

Before performing the following procedure, you should already have downloadedand installed all syslog-ng packages and any software on which it depends fromsunfreeware.com.

To configure syslog-ng toworkwith Symantec Critical SystemProtection on Solaris10

1 Create the /etc/syslog-ng directory. For example, you can use the followingcommands:

cd /etc

mkdir /etc/syslog-ng

chmod 755 /etc/syslog-ng

chown root:sys /etc/syslog-ng

2 Depending on your configuration, perform one of the following tasks:

■ If you use the default configuration file that is provided by the SMCsyslngpackage, then copy configuration file into /etc/syslog-ng. For example,you can use the following commands:cp /usr/local/doc/syslogng/doc/examples/syslog-ng.conf.solaris

/etc/syslog-ng/syslog-ng.conf

chmod 644 /etc/syslog-ng/syslog-ng.conf && chown root:sys


■ If you used an existing configuration, then create a symlink to the existingconfiguration file, /etc/syslog-ng.conf. For example, you can use thefollowing command:ln -s /etc/syslog-ng.conf /etc/syslog-ng/syslog-ng.conf


36

3 Check the correctness of the configuration by using the following command:

/usr/local/sbin/syslog-ng -v -s -f /etc/syslog-ng/syslog-ng.conf

Note: If you get the following error fromsyslog-ng: Conversion fromcharacterset '646' to 'UTF-8' is not supported, then create or add the following line tothe /usr/local/lib/charset.alias file:

646 ISO-8859-1

4 Disable syslogd and remove the original syslogd SMF service manifest fromthe database. For example, you can use the following commands:

svcadm disable svc: /system/system-log

svccfg

svc:> delete system-log*

svc:> quit

5 Save a copy of the original syslogd SMF manifest and method files. Forexample, you can use the following commands:

cp /lib/svc/method/system-log /lib/svc/method/system-log.orig

cp /var/svc/manifest/system/system-log.xml

/var/svc/manifest/system/system-log.xml.orig

6 Copy or modify the syslog-ng service manifest and method files to thefollowing locations:

■ /var/svc/manifest/system/system-log.xml

■ /lib/svc/method/system-log

If you use the manifest files and method files that are provided with theSMCsyslng package, then you need to change the following options:

■ the service name

■ the method file name

■ the daemon

Following are example diffs of the changes that you need to make:

# diff /usr/local/doc/syslogng/contrib/solaris-packaging/

syslog-ng.example.xml /var/svc/manifest/system/system-log.xml

7c7

< name='system/syslog-ng'


---

> name='system/system-log'

68c68

< exec='/lib/svc/method/syslog-ng %m'

---

> exec='/lib/svc/method/system-log %m'

78c78


---


88c88


---


# diff /usr/local/doc/syslogng/contrib/solaris-packaging/

syslog-ng.method

/lib/svc/method/system-log

12c12

< SYSLOGNG_PREFIX=/opt/syslog-ng

---

> SYSLOGNG_PREFIX=/usr/local

14,15c14,15

< CONFFILE=$SYSLOGNG_PREFIX/etc/syslog-ng.conf

< PIDFILE=$SYSLOGNG_PREFIX/var/run/syslog-ng.pid

---

> CONFFILE=/etc/syslog-ng/syslog-ng.conf

> PIDFILE=/var/run/syslog-ng.pid

18c18

< OPTIONS=

---

> OPTIONS="-f $CONFFILE -p $PIDFILE --process-mode=background"

27c27

< ${SYSLOGNG} --syntax-only

---

> ${SYSLOGNG} -f $CONFFILE --syntax-only


38

7 Validate and import the syslog-ng SMFmanifest, and then enable the service.For example, you can use the following commands:

svccfg

svc:> validate /var/svc/manifest/system/system-log.xml

svc:> import /var/svc/manifest/system/system-log.xml

svc:> quit

svcadm -v enable system-log

8 Verify that only one instance of syslog-ng is running and that it matches thePIDFILE, /var/run/syslog-ng.pid. If syslog-ng is not running, check the SMFsvc log, /var/svc/log/system-system-log\:default.log by using the followingcommand:

ps -ef |grep syslog-ng

9 Send a test message to syslog-ng by using the logger command:

logger -p daemon.crit syslog-ng test

Check the tail of the /var/adm/messages file. It should contain a line similarto the following line:

Oct 27 15:16:40 local@scsp-sol10 root: [ID 702911 daemon.crit]

syslog-ng test


Configuring Symantec Critical System Protection to work with syslog-ngon Solaris 10

To configure Symantec Critical SystemProtection toworkwith syslog-ng on Solaris10

1 Stop theSymantecCritical SystemProtection IDSagent byusing the followingcommand:

/etc/init.d/sisidsagent stop

2 Switch to use syslog-ng in the IDS LocalAgent.ini file by editing the/opt/Symantec/scspagent/IDS/system/LocalAgent.ini file.

In the [Syslog Collector] section, switch Syslog Daemon from DEFAULT toSYSLOGNG. Make very sure that the Syslog NG Source option is correct foryour configuration. For example, the [Syslog Collector] section should looksimilar to this:

[Syslog Collector]

#Derive Virtual Agents=0

Syslog Daemon=SYSLOGNG

Syslog NG Source=local # name in the config for internal and

/dev/log sources (aka 'src' or 's_sys', etc)

#Syslog NG Filter=scsp_filter

Note: Be sure that you remove the comment marker (#) when you change thevalue.

3 Start theSymantecCritical SystemProtection IDSagent byusing the followingcommand:

/etc/init.d/sisidsagent start

4 Verify that the following lineswere added to the /etc/syslog-ng/syslog-ng.conffile:

# The following is required for Symantec Host IDS - Do not edit

or remove

destination scsp_dest { pipe("/opt/Symantec/scspagent/IDS/system

/ids_syslog.pipe" group(sisips) perm(0600)); };

filter scsp_filter { level(info..emerg) and not ( facility(mail)

and level(debug..warn) ); };

log { source(local); filter(scsp_filter); destination(scsp_dest); };

5 Generate some syslog messages, for example log on and log out with theappropriate policy applied. Verify that an event is generated as expected.


40

Configuring syslog-ng to work with Symantec Critical System Protectionon Solaris 8 and Solaris 9

For Solaris 8 and Solaris 9, the Symantec Critical System Protection IDS agentrequires that the configuration file be /etc/syslog-ng/syslog-ng.conf, and thestartup script be /etc/init.d/syslog. If you have already set up syslog-ng withdifferent startup or configuration scripts, make sure that there are symlinkspointing to the existing startup and configuration files.


Before performing the following procedure, you should already have downloadedand installed all syslog-ng packages and any software on which it depends fromsunfreeware.com.

To configure syslog-ng toworkwith Symantec Critical SystemProtection on Solaris8 and Solaris 9


cd /etc



chown root:sys /etc/syslog-ng

2 Perform one of the following tasks:

■ If you use the default configuration file provided by the SMCsyslngpackage, copy the configuration file into /etc/syslog-ng by using thefollowing commands:cp /usr/local/doc/syslogng/doc/examples/syslog-ng.conf.solaris


chmod 644 /etc/syslog-ng/syslog-ng.conf && chown root:sys


■ If you use an existing configuration, create a symlink to the existingconfiguration file, /etc/syslog-ng.conf, by using the following command:ln -s /etc/syslog-ng.conf /etc/syslog-ng/syslog-ng.conf


3 Check the correctness of the configuration by using the following command:

/usr/local/sbin/syslog-ng -v -s -f /etc/syslog-ng/syslog-ng.conf

4 Copy the startup script into /etc/init.d and modify it by using the followingcommands:

cp /etc/init.d/syslog /etc/init.d/syslog.orig

cp /usr/local/doc/syslogng/contrib/init.d.solaris

/etc/init.d/syslog

chmod 744 /etc/init.d/syslog && chown root:sys /etc/init.d/syslog

5 If you use the startup script from the SMCsyslng package, you must makesome changes in the script.

Following are example diffs of the changes that you need to make:

< OPTIONS="-f /etc/syslog-ng/syslog-ng.conf"

---

> PID_FILE=/var/run/syslog-ng.pid

> CONF_FILE=/etc/syslog-ng/syslog-ng.conf

> OPTIONS="-f $CONF_FILE -p $PID_FILE --process-mode=background"

16c18

< if [ -f /etc/syslog-ng/syslog-ng.conf -a -f /usr/local/sbin

/syslog-ng ]; then

---

> if [ -f $CONF_FILE -a -f $DAEMON ]; then

28c30

< $DAEMON $OPTIONS -p /etc/syslog-ng/syslog-ng.pid

---

> $DAEMON $OPTIONS

33,35c35,37

< if [ -f /etc/syslog-ng/syslog-ng.pid ]; then

< syspid=`/usr/bin/cat /etc/syslog-ng/syslog-ng.pid`

< [ "$syspid" -gt 0 ] && kill -15 $syspid && rm

/etc/syslog-ng/syslog-ng.pid

---

> if [ -f $PID_FILE ]; then

> syspid=`/usr/bin/cat $PID_FILE`

> [ "$syspid" -gt 0 ] && kill -15 $syspid && rm -f $PID_FILE

6 Shut down the syslogd process by using the following command:

/etc/init.d/syslog.orig stop


42

7 Start syslogd-ng by using the following command:

/etc/init.d/syslog start

8 Verify that only one instance of syslog-ng is running and that it matches thePID in the /etc/syslog-ng/syslog-ng.pid file by using the following command:

ps -ef |grep syslog-ng

9 Send a test message by using the following command:

logger -p daemon.crit syslog-ng test

Check tail of the /var/adm/messages file. It should contain an entry that issimilar to the following line:

Oct 28 12:08:30 local@scsp-sol9 root: [ID 702911 daemon.crit]

syslog-ng test

Configuring Symantec Critical System Protection to work with syslog-ngon Solaris 8 and Solaris 9

To configure Symantec Critical SystemProtection toworkwith syslog-ng on Solaris8 and Solaris 9





[Syslog Collector]












or remove

destination scsp_dest { pipe("/opt/Symantec/scspagent/IDS/system/

ids_syslog.pipe" group(sisips) perm(0600)); };



log { source(local); filter(scsp_filter); destination(scsp_dest); };

5 Generate some syslog messages, for example, log on and log out with theappropriate policy applied. Verify that an event is generated as expected.

Configuring syslog-ng 3.x toworkwith Symantec Critical SystemProtectionon RHEL 5.4

TheSymantecCritical SystemProtection IDSagent requires that the configurationfile be /etc/syslog-ng/syslog-ng.conf, and the startup script be /etc/init.d/syslog.If youhave already set up syslog-ngwith different startup or configuration scripts,make sure that there are symlinks pointing to the existing startup andconfiguration files.


Before performing the following procedure, you should already have downloadedand installed all syslog-ng packages and any software on which it depends fromwww.balabit.com. For example, you might use the following URL:

http://www.balabit.com/downloads/files?path=/syslog-ng/sources/3.2.4/setups/linux-glibc2.3.6-i386


44

To configure syslog-ng to work with Symantec Critical System Protection on RHEL5.4


cd /etc



chown root:root /etc/syslog-ng

2 Create a symlink to the existing configuration file,/opt/syslog-ng/etc/syslog-ng.conf, by using the following command:

ln -s /opt/syslog-ng/etc/syslog-ng.conf


3 Rename the legacy syslog startup script and rename the syslog-ng startupscript by using the following commands:

mv /etc/init.d/syslog /etc/init.d/syslog.orig

chmod -x /etc/init.d/syslog.orig

mv /etc/init.d/syslog-ng /etc/init.d/syslog

4 Edit the /etc/init.d/syslog startup script to add the --process-mode switch tothe SYSLOGNG_OPTION. For example, it should look similar to the followingtext:

case "$OS" in

Linux)

SYSLOGNG_OPTIONS="--no-caps --process-mode=background"

;;

esac






[Syslog Collector]











or remove

destination scsp_dest { pipe("/opt/Symantec/scspagent/IDS/system/

ids_syslog.pipe" group(sisips) perm(0600)); };



log { source(s_local); filter(scsp_filter); destination(scsp_dest); };

9 Generate some syslog messages, for example, log on and log out with theappropriate policy applied. Verify that an event is generated as expected.

You can now make user and group names optional in policiesUsers can enter an optional user name or group name in a policy by adding a dash(-) before the user name or group name. The policy is then applied even if the username or group name is not available on the system. If the name is not optional,and name is not available on the system, then the policy is not applied.


46

IPS features

Optional user names and group names in IPS policiesThis featurewas available in release 5.2 RU7 andnow is available for all supportedoperating systems.

You can now enter an optional user name or group name in prevention policiesby adding a dash (-) before the user name or group name. For example, you woulduse -administrator to make the administrator user name optional. In this case,the policy is applied even if the user name is not available in the system. If youuse administrator (with no dash) instead, the presence of the administrator nameis mandatory, and the policy fails to apply if it is not available. This syntax canbe used even if the user names or group names are in environment variables orregistry keys.

Note: This feature is implemented in the agent, so it is only available when youuse release 5.2 RU7 and later agents.

Logging of privilege escalation to superuser or a different userThe UNIX Prevention policy now logs the original user ID for users who escalatetheir privileges to root or a user with different privileges. This new feature isavailable on all supported AIX, Red Hat Enterprise Linux, and SUSE Linuxplatforms.

Now, when UNIX or Linux users use the su command to escalate to superuserprivilege, this escalation is logged with the users' original login IDs. Users cannowbemonitored andheld accountable for their actionswhile they have differentprivileges.

Root accountabilityBefore release 5.2 RU8, there was no simple way to monitor users who escalatedtheir privileges to root. If multiple users simultaneously su'ed to root, their rootactionswere logged, but you couldnot connect a particular log entry to a particularuser's non-root user ID.

In all prevention events that contain user name information, Symantec CriticalSystem Protection now records the immediately previous user name in additionto the current user name. Now, when UNIX or Linux users use the su commandto escalate to superuser privilege, this escalation is loggedwith the users' originallogin IDs. Users can now be monitored and held accountable for their actionswhile they have different privileges.


The “immediately previous user name” is the effective user name at the time ofthe setid call. Symantec Critical System Protection does not record the effectiveuser name and real user name of the process after the setid call, since the realuser name is generally set to be the same as the effective user name, even afteran su.

Note:Symantec Critical SystemProtection records only the immediately previoususer name. It does not record an arbitrary chain of user names.

The root accountability feature is available only on UNIX or Linux operatingsystems that support Symantec Critical System Protection Intrusion Prevention(IPS).

For a simple scenario, such as the case where an administrator logs onto acomputer and switches to user1, Symantec Critical SystemProtection now showsthe full picture. The logs of the administrator’s activity while logged on as user1show both the user1 name and the administrator name in the events.

For chained suuse cases aswhere an administrator logs onto a computer, switchesto user1, and then switches to user2, Symantec Critical System Protection nowshows part of the picture. Activity while the administrator is logged on as user2shows the user2 name and user1 name, but does not record the administratorname in the logs for these events.

Event data

The previous user name data is recorded as an additional field in all existingUNIX-relatedprevention events. The followingpossibilities exist for this additionalfield:

■ It can be empty. An empty field means that the process has never had a username different from the current one.

■ It can have a single user name. A single user namemeans that the process hashad only one other user name than the current one.

■ It can have two user names. Two user names means that the process has hadat least two different user names before the current one.

In the Comma Separated Value (CSV) files stored on the agents, the previous username data appears in field 30 of the event. In the example events shown, theprevious user name is in the last field of each entry.

PPST,17213,2011-04-06 01:29:22.000 Z-

0700,I,,G,073adb47013fc4e3cf7d7d37300a4df3,,,,jeff,0,/bin/ps,12797,,

ps -elf --forest,exec,int_rootpriv_ps,12614,,,,/bin/bash,,,,0,,,root


48

PFIL,17297,2011-04-06 01:30:49.000 Z-

0700,W,,GR,073adb47013fc4e3cf7d7d37300a4df3,e,,,jeff,0,/bin/touch,12845,A,

/home/jeff/file.noaccess,open,int_rootpriv_ps,00000000,00000000,0000000a,

,,,00000000,,0,,,root

In the Symantec Critical System Protection console, the previous user name dataappears as an additional field in the Details section of the display.

SOURCE

Agent Name gbvm-rhel5

Host Name gbvm-rhel5

Host IP Address 10.180.246.110

User Name jeff

Agent Version 5.2.8.76

OS Type Linux

OS Version 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39

EDT 2010 (x86_64)

Agent Type CSP Native Agent

EVENT

Event Type File Access

Event Category Real Time - Prevention

Operation open

Event Severity Warning

Event Priority 45

Event Date 05-Apr-2011 18:30:49 PDT

Post Date 05-Apr-2011 18:35:00 PDT

Post Delay 00:04:11

Event Count 1

Event ID 2744180

DETAILS

Description File Write Allowed for touch on

/home/jeff/file.noaccess

Policy Name policy_unix_5.2.8

Process /bin/touch

File Name /home/jeff/file.noaccess

Agent State Prevention Globally Disabled

Disposition Allow

Process Set int_rootpriv_ps


Operation open

OS Result 00000000 (SUCCESS)

SCSP Result 00000000 (SUCCESS)

Permissions Requested 0000000a (write, create)

Process ID 12845

Thread ID 0

Previous User Names root

About multiple previous usernames

Some events record two previous user names in the data. When this occurs, theuser names are separated by a colon and the most immediately previous username is listed first. For example, consider an event that contains the followinguser name information:

User Name root

Previous User Names jeff:root

The following information applies to this event:

■ The process’s current effective user name is root. This name is located in theUser Name field.

■ The current process came fromaprocess thatmost recently had the user namejeff. jeff is the first user name listed in the Previous User Names field.

■ Prior to being jeff, the process ancestry had a process with the user nameroot. root is the second user name listed in the Previous User Names field.

At times the second user name listed in thePreviousUserNames field is not veryrelevant. It can be the user name of the daemon that created the login shell or ofthe su command. At other times it can be relevant. It can be the user name of ansu session or login session the human user was in before becoming the currentuser name.

Examples

User jeff logs on

In this scenario, once user jeff logs in, events display the Previous User Nameof root, which reflects the root user from the sshd parent process. In this scenario,the previous user name, root, is not particularly relevant because the personlogging in never had a root shell. The following examples show the CSV events.

Process assignment event when sshd changes user to jeff:


50

PPST,16898,2011-04-06 01:24:20.000 Z-

0700,I,,G,073adb47013fc4e3cf7d7d37300a4df3,,,,jeff,0,/usr/sbin/sshd,

12613,,sshd: jeff [priv],setid,int_gateway_ps,12611,,,,/usr/sbin/sshd

,,,,0,,,root

Process assignment event showing a ps command, along with command linearguments, run by user jeff:

PPST,17213,2011-04-06 01:29:22.000 Z-

0700,I,,G,073adb47013fc4e3cf7d7d37300a4df3,,,,jeff,0,/bin/ps,12797,,

ps -elf --forest,exec,int_rootpriv_ps,12614,,,,/bin/bash,,,,0,,,root

File access event shows user jeff attempting to open a file:

PFIL,17297,2011-04-06 01:30:49.000 Z-

0700,W,,GR,073adb47013fc4e3cf7d7d37300a4df3,e,,,jeff,0,/bin/touch,1

2845,A,/home/jeff/file.noaccess,open,int_rootpriv_ps,

00000000,00000000,0000000a,,,,00000000,,0,,,root

All three events show the current user name as jeff and the previous user nameas root.

The following text show how the same file access event displays on the console.

SOURCE




User Name jeff


OS Type Linux


EDT 2010 (x86_64)


EVENT



Operation open


Event Priority 45




Post Delay 00:04:11

Event Count 1

Event ID 2744180

DETAILS

Description File Write Allowed for touch on



Process /bin/touch



Disposition Allow


Operation open



Permissions Requested 0000000a (write, create)

Process ID 12845

Thread ID 0

Previous User Names root

User jeff su's to root

When user jeff su’s to root, the previous user name data shows the current username of the process as root, and the previous user name data has both jeff androot:

■ jeff is the immediately previous user name, reflecting the fact that jefflogged in to the system.

■ root is the user name before jeff, and reflects the sshd process user name.

The following examples show the CSV events.

Process assignment event when the su program changes user from jeff to root.Note that the previous user name data at the end of the event now showsjeff:root, indicating that the user name jeff is the immediately previous username.

PPST,17520,2011-04-06 01:33:05.000 Z-0700,I,,G,

073adb47013fc4e3cf7d7d37300a4df3,,,,root,0,/bin/su,12959,

,su,setid,int_rootpriv_ps,12955,,,,/bin/su,,,,0,,,jeff:root


52

Process assignment event showing a ps commandwith command line arguments,run by root. You can compare this with the event for the same ps command runpreviously by jeff.

PPST,17604,2011-04-06 01:34:04.000

Z-0700,I,,G,073adb47013fc4e3cf7d7d37300a4df3,,,,root,0,/bin/ps,13008,

,ps -elf --forest,exec,int_rootpriv_ps,12959,,,,/bin/bash,,,,0,,,jeff:root

File access event showing root attempting to open a file.

PFIL,17544,2011-04-06 01:33:07.000 Z-0700,W,,GR,

073adb47013fc4e3cf7d7d37300a4df3,e,,,root,0,/bin/ls,12973,A,

/home/jeff/file.noaccess,lstat,int_rootpriv_ps,00000000,00000000,

00004000,,,,00000000,,0,,,jeff:root


SOURCE




User Name root


OS Type Linux


EDT 2010 (x86_64)


EVENT



Operation lstat


Event Priority 45



Post Delay 00:04:12

Event Count 1

Event ID 2744185

DETAILS


Description File Read Allowed for ls on



Process /bin/ls



Disposition Allow


Operation lstat



Permissions Requested 00004000 (stat)

Process ID 12973

Thread ID 0

Previous User Names jeff:root

User jeff logs on and then su's to bob

The initial stage of this scenario is identical to the first scenario where user jeffsimply logs on. Refer to the first example for the events related to the first stage.

See “User jeff logs on” on page 50.

The second stage of this scenario shows user jeff su'ing directly to user bob. Thefollowing example events represent the second stage of this scenario.

Note: The Previous User Names field lists root, and then jeff. The root username reflects the su program being run by jeff. su is a setuid root program, andthus the root user name is inserted into the Previous User Names field. Thisbehavior is the same on Solaris and Linux operating systems, but is not the sameon AIX operating systems.

In this scenario, the first previous user name is not very relevant, since it onlyindicates that the su program itself momentarily became root in order toaccomplish the identity change to bob. Contrast thiswith the final scenariowhereuser jeff logs on, su's to root, and then su's to become user bob.


Process assignment event when the su program changes user from jeff to bob:

PPST,35165,2011-04-06 06:54:22.000 Z-0700,I,,G,

073adb47013fc4e3cf7d7d37300a4df3,,,,bob,0,/bin/ps,23239,


54

,ps -elf --forest,exec,int_rootpriv_ps,23221,,,,

/bin/bash,,,,0,,,root:jeff

File access event showing bob attempting to open a file:

PFIL,35421,2011-04-06 06:58:32.000 Z-0700,W,,GR,

073adb47013fc4e3cf7d7d37300a4df3,e,,,bob,0,/bin/ls,23385,A,

/home/jeff/file.noaccess,stat,int_rootpriv_ps,fffffff3,00000000,

00004000,,,,00000000,,0,,,root:jeff

User jeff logs on, su's to root, and then su's to bob

The first stage of the use case is for jeff to su to root and get a root shell. Theexample shows running the ps command in the root shell. This is identical to UseCase 1a above.

The second stage of the user case is running the su command again, from the rootshell, to become the user bob.

Compare the two events below for the user bobwith the corresponding two eventsfrom the previous scenario where user jeff logs on and then su's to bob. You seethat the events look identical. Specifically, the previous user name data in bothsets of events is the same. The fact that in the previous scenario where user jefflogs on and then su's to bob, therewasno root shell involvedwhile in this scenariothere was a root shell involved is not apparent from the single events shown. Todetermine whether a root shell was involved in getting to the bob login session,you have to look at the full sequence of process assignment events.


Process assignment event showing a ps command, along with command linearguments, run by user root:

PPST,35641,2011-04-06 07:01:46.000 Z-0700,I,,G,

073adb47013fc4e3cf7d7d37300a4df3,,,,root,0,/bin/ps,23504,

,ps -elf --forest,exec,int_rootpriv_ps,23490,,,,/bin/bash

,,,,0,,,jeff:root

Process assignment event showing a ps command, along with command linearguments, run by bob. See that the previous user name info has pushed jeff tothe second most recent user name, with root being the most recent user name:

PPST,36046,2011-04-06 07:08:10.000 Z-0700,I,,G,

073adb47013fc4e3cf7d7d37300a4df3,,,,bob,0,/bin/ps,23733,

,ps -elf --forest,exec,int_rootpriv_ps,23697,,,,/bin/bash

,,,,0,,,root:jeff


File access event showing user bob attempting to open a file:

PFIL,36076,2011-04-06 07:08:44.000 Z-0700,W,,GR,

073adb47013fc4e3cf7d7d37300a4df3,e,,,bob,0,/bin/ls,2375

0,A,/home/jeff/file.noaccess,stat,int_rootpriv_ps,fffffff3,

00000000,00004000,,,,00000000,,0,,,root:jeff


SOURCE




User Name bob


OS Type Linux


EDT 2010 (x86_64)


EVENT



Operation stat


Event Priority 45



Post Delay 00:04:14

Event Count 1

Event ID 2744212

DETAILS

Description File Read Allowed for ls on



Process /bin/ls



Disposition Allow



56

Operation stat



Permissions Requested 00004000 (stat)

Process ID 23750

Thread ID 0

Previous User Names root:jeff

Child processes of custom applications can be assigned toanother custom application process setThe initial implementation of the custom program feature assigned the childprocesses of a custom program to its parent process set. Now when you define acustom program, any processes that the custom application launches can bereassigned to other custom application process sets that were defined in anothercustom program.

Importing a file list

Syntax for using variables, registry values, and function calls

References to variables, registry values, and function calls cannot be nested, sincenesting can result in ambiguous strings. For instance, in%myvarpart1%insidevar%myvarpart2%, it is not clear whether the secondpercent sign ends the first variable reference or begins a nested reference.

Table 4-1

SyntaxType

%[modifier]parameter%Simple parameter

%[modifier]parameter:field%Compound parameter

%[modifier]shortcut%Shortcut

%[modifier]environmentvariable%Environment variable

%%[modifier][redirectionspec]registrypath%%Registry value

%?[modifier]function(parameters)?%Function

Variables

TheVariables that you can use are parameters, compound parameters, shortcuts,and environment variables. A compound parameter contains an added sequence


to identify a field. If more than one type of variable exists with the same name,the software uses the first one that exists from the following ordered list:

■ Parameter

■ Shortcut

■ Environment variable

Simple parameter

A parameter is a variable defined by a parameter element in a policy. A simpleparameter has one list of values; a compound parameter has a set of lists. Thesoftware replaces the parameter reference with the values or values. Parameternames are case sensitive.

Compound parameter

A compound parameter is also a variable defined by a parameter element. Butinstead of one list, it contains a list of sets of values. Each set contains assignmentsfor one or more fields. For example, a compound parameter may contain valuesfor fields such as prog, cmdline, id, and value. For each type of parameter list,there is a specific set of fields that can be used. For a compound parameter, youmust prefix field names with a colon. For example, you might use%myparameter:prog%. Parameter and field name are case sensitive.

In most instances, compound parameter references are optional. The exceptionsto this rule are as follows:

■ The value attribute anywhere other than in a <newproc>

■ The value attribute inside a <newproc> if the element has a type attributewith a value of prog

■ The prog attribute inside an <overflow> section

Shortcut

A shortcut is a type of variable where the value is typically listed in theshortcuts.txt file in theSymantecCritical SystemProtectionbindirectory. Shortcutnames are case sensitive on UNIX, and case insensitive on Windows.

Environment variable

You can use an operating system environment variable as a variable in a policy.Environment variable names follow the operating system’s normal conventionsfor case sensitivity, so they are case sensitive on UNIX and case insensitive onWindows.


58

Registry value

For registry references, the software looks up the given value in the registry andreplaces the reference with the data that the value contains. The data must beone of the following types:

■ REG_SZ (string)

■ REG_EXPAND_SZ (stringwith environment variables that should be expanded)

■ REG_MULTI_SZ (list of strings)

■ REG_DWORD (32-bit integer)

■ REG_QWORD (64-bit integer)

The software expands an environment variable's REG_EXPAND_SZ valuesimmediately, before it processes the resulting string. For REG_MULTI_SZ values,the reference expands to the list of strings.

On 64-bit versions of Windows, you can prefix registry paths with an optionalredirection specification. This redirection specification specifies how registryredirection should be used when looking up the path. The valid redirectionspecifications are as follows:

■ 32:

■ 64:

■ 6432:

■ 3264:

For the values of 64: and 32:, redirection is turned off or on to give a 64-bitprogram’s view of the registry or a 32-bit program’s view, respectively. For 6432:and 3264:, the lookup is tried with both redirection off and with redirection on.6432: looks in the 64-bit view of the registry first, and then if that fails, looks inthe 32-bit view. The value 3264: looks in the 32-bit view of the registry first.

Function

A function reference provides a way to call an extension function from within apolicy. The software replaces the function reference with the return value or listof return values of the function. Extension functions are defined in Windows dllsor in the UNIX shared objects that are located in the IPS/extensions directoryunder the agent installation root directory.


Note: In a function reference such as%?function(parameters)?%, the parametersmay contain any characters, even special characters, except that youmust escapea close parenthesis ( ) ). The function parameters are not processed, so if theycontain a reference themselves, the text of the reference is passed to the function.For example, %myvar% is passed rather than myvar's value after evaluation.However, if a function’s return value contains a reference, the reference issubsequently evaluated.

Importing a file listSymantec Critical System Protection now provides a new policy function,ImportFileList, that can reference a text file on the agent and import strings fromthat file into the policy. You can use the new function anywhere in the policy thatyou can enter strings, for example, anywhere you can enter file paths, registrypaths, user names, and so on. When the policy is applied to an agent, the agentthen retrieves a list of strings from the referenced file and substitutes them intothe parameter in the policy.

This feature is available on all supported platforms.

The following guidelines apply:

■ You can use any string in the file that you can enter into a parameter value inthe console.For example, a file can contain strings such as file paths, Windows registryentries, user names, group names, or IP addresses.

■ Only one string must appear on each line of the file.

■ You can use Unicode or ASCII file format.

■ Each file must contain no more than 100 lines. If the number of lines exceeds100, then Symantec Critical System Protection returns an error and the file isnot used in the policy.

■ Begin the import file function with a percent question mark (%?) and end itwith a question mark percent (?%). An example that imports a file list that isnamed privuserlist.txt is %?ImportFileList(c:\mydir\privuserlist.txt)?%

■ A file can be made optional by adding a dash (-) after the prefix and before thefunction. An example that imports an optional file list that is namedprivuserlist.txt is %?-ImportFileList(c:\mydir\privuserlist.txt)?%When optional, the policy is still applied even if the file is not available on thesystem.

■ Place the file on the computer that runs the Symantec Critical SystemProtection agent.The file is read at the time that the policy is applied.


60

Importing a list of strings into a policy from a file

To import a list of strings into a policy from a file

1 Open policy in the console.

2 Open the parameter that you want to populate from a list of strings in a file.

3 Type the following input into the parameter field:

■ To populate a parameter where the policy is not applied if the file isavailable on the system:%?ImportFileList(filepath)?%

■ To populate a parameter where the policy is still applied even if the fileis not available on the system:%?-ImportFileList(filepath)?%

Note: The filepath variable is mandatory.

Additional release information

Logging of previous user ID to track privilege escalation on IPS eventsSymantec Critical System Protection now provides root accountability. It logs auser's previous UID as well as the current UID for each logged IPS event.

See “Root accountability ” on page 47.

Use of Tomcat 5.5.33Symantec Critical System Protection now uses Apache Tomcat version 5.5.33.

Restart requiredWhen theSymantecCritical SystemProtectionprevention feature is enabled, youmust restart all Windows agent computers after an installation or upgrade. As ofrelease 5.2 RU6, when Real-time File Integrity Monitoring became available, allWindows agents must be restarted after an installation or upgrade, even if theSymantec Critical System Protection prevention feature is not enabled. A restartis required so that theReal TimeFile IntegrityMonitoring featureworks properlyfor all Windows agents. This feature is enabled by default on all supportedWindows operating systems.

Operating systems affected: Windows, all supported versions

61Release 5.2 RU8Additional release information

You must upgrade Solaris x86 agents before you upgrade yourSymantec Critical System Protection management servers to release5.2 RU8

Solaris x86 5.2 RU7 and older agents cannot communicate at all with the 5.2 RU8management server. You must upgrade all Solaris x86 agents to 5.2 RU8 beforeyou upgrade your management server to 5.2 RU8.

Note: This issue affects only the Solaris x86 agents; there is no issue with SolarisSPARC agents or agents on any other operating system.

Microsoft SQL Server 2000 is no longer supportedAs of release 5.2 RU6, you can no longer use Microsoft SQL Server 2000 as thedatabase for Symantec Critical System Protection. If you upgrade Microsoft SQLServer 2000 to a later version, you must ensure that the database compatibilitylevel of the SCSPDB database is set to level 80 or higher.

To check or modify the SCSDB compatibility level

1 Open the SQL Server Management Studio.

2 Use the sa user name to log in to the Microsoft SQL Server database.

3 Under Databases, right-click SCSPDB, and then select Properties>Options> Select Compatibility level.

4 Check the compatibility level. If it is lower than 80, change it to be 80 orhigher.

Build ID version numbers are now synchronizedThe version numbers of the individual components in this Symantec CriticalSystem Protection release are now the same for all components. The versionnumber is updated regardless of whether the component was changed for therelease.

Note: HP-UX is the exception. The individual component version numbers forHP-UX in this release have been updated only if the component was changed forthe release.

Release 5.2 RU8Additional release information

62

What you need to know before you install or upgradeyour software

The Symantec Critical System Protection Implementation Guide contains detailedinformation about how to install the Symantec Critical System Protectioncomponents. If you are installing for the first-time, you should install, configure,and test Symantec Critical System Protection in a test environment.

For the latest andmost complete information about the release and known issuesand workarounds, refer to the readme file that accompanies this release.

For informationaboutSymantecCritical SystemProtection features andplatforms,see the Platform and FeatureMatrix located in the docs folder on the product discthat contains this release.

Table 4-2 Overview of an installation

DescriptionActionStep

When planning your installation, you may need to consider the following:

■ Network architecture and policy distribution

■ Firewalls

■ Name resolution

■ IP routing

Plan the installation1

All the computers on which you install Symantec Critical System Protectionshould meet or exceed the recommended operating system and hardwarerequirements.

Review the systemrequirements

2

You can install the management console and management server on the samecomputer or on separate computers. You can install agents on any computer.All computers must run a supported operating system.

Decide on thecomputers to install thesoftware components

3

You can install the following management server installation types:

■ An evaluation installation that runs SQL Server 2005 Express on the localsystem

■ An evaluation installation that uses an existing MS SQL instance

■ A production installation with Tomcat and the database schema

■ The Tomcat component only

Decide on themanagement serverinstallation type

4

The installation packages unpack installation files into the directory that isspecified by the TEMP environment variable. The volume that contains thisdirectory must have at least 200 MB of available disk space. If this volume doesnot have the required disk space, you must change your TEMP environmentvariable.

Configure the TEMPenvironment variable

5

63Release 5.2 RU8What you need to know before you install or upgrade your software

Table 4-2 Overview of an installation (continued)

DescriptionActionStep

You begin the installation by installing the management server.

Management server installationpromptsyou to enter a series of values consistingof port numbers, user names, passwords, and so on. Each database that you caninstall uses different default settings and options for the management serverand database.

Install themanagementserver

6

Install the management console after you install the management server.

The management console installation also installs the authoring environment.

Themanagement console installationdoesnot promptyou to enter port numbersor server names. You enter this information after installation, when youconfigure the management console.

Install themanagementconsole

7

Management console configuration prompts you to enter a series of valuesconsisting of port numbers, passwords, and a server name. In a few instances,the port numbers must match the port numbers that were specified duringmanagement server installation.

Configure themanagement console

8

Install the agents after you install themanagement server, and after you installand configure the management console.

The agent installation prompts you to enter a series of agent values consistingof port numbers, management server name, etc.

Install the agents9

Legal NoticeCopyright © 2012 Symantec Corporation. All rights reserved.

Symantec and the Symantec Logo are trademarks or registered trademarks ofSymantec Corporation or its affiliates in theU.S. and other countries. Other namesmay be trademarks of their respective owners.

This Symantec product may contain third party software for which Symantec isrequired to provide attribution to the third party (“Third Party Programs”). Someof the Third Party Programs are available under open source or free softwarelicenses. The License Agreement accompanying the Software does not alter anyrights or obligations you may have under those open source or free softwarelicenses. Please see the Third Party Legal Notice Appendix to this Documentationor TPIP ReadMe File accompanying this Symantec product for more informationon the Third Party Programs.

The product described in this document is distributed under licenses restrictingits use, copying, distribution, and decompilation/reverse engineering. No part of

Release 5.2 RU8Legal Notice

64

this documentmay be reproduced in any formby anymeanswithout priorwrittenauthorization of Symantec Corporation and its licensors, if any.

THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIEDCONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANYIMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSEORNON-INFRINGEMENT,AREDISCLAIMED,EXCEPTTOTHEEXTENTTHAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTECCORPORATIONSHALLNOTBE LIABLE FOR INCIDENTALORCONSEQUENTIALDAMAGES IN CONNECTIONWITHTHE FURNISHING, PERFORMANCE, ORUSEOF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THISDOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.

TheLicensedSoftware andDocumentationaredeemed tobe commercial computersoftware as defined in FAR 12.212 and subject to restricted rights as defined inFAR Section 52.227-19 "Commercial Computer Software - Restricted Rights" andDFARS 227.7202, "Rights in Commercial Computer Software or CommercialComputer SoftwareDocumentation", as applicable, and any successor regulations.Any use, modification, reproduction release, performance, display or disclosureof the Licensed Software and Documentation by the U.S. Government shall besolely in accordance with the terms of this Agreement.

Symantec Corporation350 Ellis StreetMountain View, CA 94043

http://www.symantec.com

Printed in the United States of America.

10 9 8 7 6 5 4 3 2 1

65Release 5.2 RU8Legal Notice

http://www.symantec.com

Release 5.2 RU8Legal Notice

66

Release Notes for Symantec Critical System Protection Version 5.2.8 MP3… · 2012-05-14 ·...

Documents

Transcript of Release Notes for Symantec Critical System Protection Version 5.2.8 MP3… · 2012-05-14 ·...