SCSP 5 2 8 MP2 Release Notes

Release Notes for Symantec Critical System Protection Version 5.2.
8 MP2
Contents
Chapter 1
Release 5.2.8 MP2 ................................................................ 7

About Symantec Critical System Protection ........................................ 7 What's new in release 5.2.8 MP2 ....................................................... 8 Additional platform support ...................................................... 8 Targeted prevention policy ........................................................ 8 About the Duplicate Agent Registration settings .......................... 16 Disabling duplicate agent registration ........................................ 16 Resolved issues ............................................................................ 17 Systems with heavy network load experienced higher CPU usage ............................................................................. 17 The System_Failed_Access_Status policy now records the login failure for batch job .......................................................... 17 Root level failed telnet logon is now recorded by Symantec Critical System Protection ................................................. 17 The continuous file change alerts do not occur when you upgrade the Symantec Critical System Protection 5.2.6 MP2 agent to any new agent version ...................................................... 18 Symantec Critical System Protection detection service start or restart triggered excessive filewatch events .......................... 18 The Windows_template_policy allowed adding identical value and comment entries in the filewatch list ............................. 18 Blue screen error no longer occurs ............................................ 18 Symantec Critical System Protection policies now retain the policy values after export and import .................................. 19 User Name information for Windows Event Log events no longer appear blank ................................................................... 19 Windows Detection Policy now provides the flexibility to add date and time restrictions to each rule in System Audit Tampering ...................................................................... 19 Timeout dialog box now displays the console name it is connected to .................................................................................. 20 Symantec Critical System Protection now displays the correct count of registered agents in the System Summary query result ............................................................................. 20 Known issues .............................................................................. 20
Contents
Cannot use an optional user name reference in a network rule ............................................................................... 20 Successful FTP logons by root are not recorded by Symantec Critical System Protection ................................................. 21
Chapter 2
Release 5.2.8 MP1 .............................................................. 23

What's new in version 5.2.8 MP1 ..................................................... 23 IDS features .......................................................................... 23
Chapter 3
Release 5.2 RU8 .................................................................. 25

What's new in release 5.2.RU8 ........................................................ IDS and IPS features ............................................................... IPS features .......................................................................... Additional release information ....................................................... Logging of previous user ID to track privilege escalation on IPS events ............................................................................ Use of Tomcat 5.5.33 .............................................................. Restart required .................................................................... You must upgrade Solaris x86 agents before you upgrade your Symantec Critical System Protection management servers to release 5.2 RU8 ............................................................ Microsoft SQL Server 2000 is no longer supported ....................... About the minimum agent version numbers ................................ What you need to know before you install or upgrade your software ............................................................................... Resolved issues ............................................................................ Network-related memory leak in Windows 2008 R2 agents has been fixed ....................................................................... Custom program child processes can now be assigned to other custom application process sets .......................................... Console timeout now works as expected ..................................... The Policy Viewer is no longer grayed out on the console Detection tab ................................................................... User names are no longer empty or incorrectly displayed as root ............................................................................... IDS agent now modifies the /etc/syslog-ng.conf file ...................... The sisidsdaemon no longer stops if the FileWatch.dat file becomes corrupted ........................................................... Policy name field now appears in data exported from the Event Search feature ................................................................. An event search now resets the event count and page after every search ............................................................................ 25 25 40 51 51 52 52
52 52 53 53 55 55 55 56 56 56 56 57 57 57
Contents
Console is no longer unresponsive when an illegal character is entered into the Custom Rule Identifier field ........................ File and directory permissions for UNIX agents ........................... Java script error no longer occurs .............................................. Bulk log file size no longer increases past the value set for maximum log size ............................................................ Documentation correction: UNIX Baseline Policy Reference Guide ............................................................................. Documentation correction: Windows Baseline Policy Reference Guide ............................................................................. Legal Notice ................................................................................
57 58 58 58 58 58 59
Contents
Chapter
Release 5.2.8 MP2

This chapter includes the following topics:

About Symantec Critical System Protection What's new in release 5.2.8 MP2 Resolved issues Known issues
About Symantec Critical System Protection

Welcome to Symantec Critical System Protection, a flexible, multi-layer security solution for servers that detects abnormal system activities. Symantec Critical System Protection prevents and blocks viruses and worms, hacking attacks, and zero-day vulnerability attacks. Symantec Critical System Protection also hardens systems, enforcing behavior-based security policies on clients and servers. Symantec Critical System Protection includes a management console and server components, and agent components that enforce policies on computers. The management server and management console run on Windows operating systems. The agent runs on Windows and UNIX operating systems. Among Symantec Critical System Protection's key features are:

Predefined application policies for common Microsoft interactive applications Out-of-the-box policies that continuously lock down the operating system, high-risk applications, and databases to prevent unauthorized executables from 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
Release 5.2.8 MP2 What's new in release 5.2.8 MP2
Offers protection against buffer overflow and memory-based attacks Helps to maintain compliance with security policies by providing granular control over programs and data
What's new in release 5.2.8 MP2

Additional platform support
The 5.2.8 MP2 release adds support for the following platforms:
The Symantec Critical System Protection now supports the IDS features on computers that run Red Hat Enterprise Linux 5.7 operating systems. It does not load any kernel driver.
Note: If you upgrade from RHEL 5.6 to RHEL 5.7 with agent installed and you have enabled prevention, then you must uninstall the agent and reinstall the release 5.2.8 MP2 agent.
Targeted prevention policy

About the Targeted prevention policy
The Targeted prevention policy lets you define a set of baseline controls for the entire system. For example, you can apply buffer overflow protection to the entire system and no other prevention. The Targeted prevention policy allows access to all resources by default and lets you block access or modifications to resources that you have configured in the policy options. It also provides you the ability to customize the policy according to your need by adding custom programs in the policy. Policy file name for Windows operating systems:
sym_win_targeted_prevention_sbp
Policy file name for UNIX operating systems: sym_unix_targeted_prevention_sbp The Targeted prevention policy includes an SCSP self protection option. When the SCSP self protection option is selected, it protects against a user or a process tampering with the Symantec Critical System Protection configuration data or program data. For example, the following configuration data is protected as the write access is blocked 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:

Global Policy options Provides a set of global options that applies to all the processes in the system. When you apply global options in the policy, it is applied to all the PSETs in the policy. Built-In PSET options Provides a set of options to configure the Built-In PSETs. The Windows Targeted prevention policy contains four built-in PSETs to handle Kernel Driver controls, Remote File Access controls, Symantec Critical System Protection Agent and Server controls. The Targeted prevention policy always routes these processes to the built-in PSETs. You cannot override these built-in PSETs. The Targeted prevention policy routes all processes to the Default PSET with the exception of Built-In PSETs. You can configure all protection features in the Default PSET. My Custom Programs Define one or more custom program within the policy to override the security settings in the Default PSET. Additionally, you can also define custom lists which can be referenced elsewhere in the policy.
Default PSET options
Note: If you set Disable Prevention at a global level, then Symantec Critical System Protection disables prevention for all PSETs. You cannot enable prevention in a Custom PSET or a Default PSET.
10
See How the Targeted prevention policy works on page 10. See About using custom lists with the Targeted prevention policy on page 12. See About using custom programs with the Targeted prevention policy on page 10.
How the Targeted prevention policy works

The Targeted prevention policy includes a set of Built-In PSETs to control access to the kernel and Symantec Critical System Protection processes. You cannot override a Built-In PSET. However, you can configure the Built-In PSETs by using the policy options. With the exception of the Built-in PSETs, the Targeted prevention policy routes all processes to the Default PSET. All protection features are configurable in the Default PSET. However, the Default PSET can be overridden by adding a custom program to the policy. One or more custom programs can be defined within the policy which will override the security settings in the Default PSET. See About the Targeted prevention policy on page 8. See About using custom lists with the Targeted prevention policy on page 12. See About using custom programs with the Targeted prevention policy on page 10.
About using custom programs with the Targeted prevention policy

The Targeted prevention policy lets you create custom programs based on the following templates:
Fully open template Use the fully open custom program template to build-up security protections. By default, it has no security restrictions. All processes assigned to the fully open custom program have no default resource restriction defined. Moreover, protection features such as buffer overflow detection, thread injection are also disabled. See Creating custom programs based on the fully open template on page 12.
11
Fully closed template
Use the fully closed custom program template to relax security protections. All processes assigned to the fully closed custom program are denied access to all resources and all protection features are enabled by default. The protection features such as buffer overflow detection, thread injection are also enabled by default. See About using the fully closed custom program template on page 11. See Creating custom programs based on the fully closed template on page 14.
See About using custom lists with the Targeted prevention policy on page 12. See About the Targeted prevention policy on page 8.
About using the fully closed custom program template

You 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 closed custom program and route the program to this custom program PSET. Note: This method does allow the program to run, although the program is blocked from accessing any file, registry, or network resources. If you want to strictly limit a program regarding the resources it can access, you can create a fully closed custom program. You must configure the custom program and allow write access to only the resources this program needs access to, while allowing read access to all resources on the system.
By default, the fully closed custom program denies access to all resources and logs 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 the program attempts to access. Symantec recommends you to configure the custom program to allow read access to all resources on the system, and to only allow write access to the resources as required by this custom program. To determine what resources the custom program needs write access to
Edit the file and registry rules in the custom program and place a wildcard in the Read-only Resource Lists:
Block modifications to these files
12
Block modifications to these Registry keys
2 3
Enable logging of trivial policy violations in the custom program under General Settings. Disable prevention in the custom program.
Apply this policy to the agent, and then execute the custom program. The trivial events generated will show what resources the program is accessing for write access. You can use these events to configure the custom program and allow write access to the appropriate resources. Once you have determined the specific resources the program needs write access to, you can then enable the prevention in the custom program. See About using custom programs with the Targeted prevention policy on page 10. See Creating custom programs based on the fully closed template on page 14.
About using custom lists with the Targeted prevention policy

The Targeted prevention policy lets you create generic program lists and generic string lists. You can refer to these custom lists in other parts of the policy. You can access these custom lists by editing the Targeted prevention policy in the management console.
Generic Program list The generic program list contains a list of programs. In the management console, the generic program list appears as set of applications to be referenced later.
Generic String list The generic string list contains a list of users, groups, network addresses, or network ports. In the management console, the generic string list appears as list of items to be referenced later.
See About using custom programs with the Targeted prevention policy on page 10. See About the Targeted prevention policy on page 8.
Creating custom programs based on the fully open template

The Symantec Critical System Protection Targeted prevention policy lets you create custom programs based on the fully open template.
13
To create a custom program based on the fully open template
1 2 3 4
In the management console, click Prevention View. On the Policies page, click the Symantec folder and then in the workspace pane, double-click sym_win_targeted_prevention_sbp. In the policy editor dialog box, click My Custom Programs, and then click New. In the New Custom Control Wizard dialog box, specify the following information:
Display Name Type a descriptive name. Example: Notepad Category Select This Custom Program PSET is fully open, it has no default security restrictions. Type a name that the policy uses internally. The identifier must not include spaces or special characters. Example: NotepadID Group Tags Description Type a group tag name. Type a full description.
Identifier
5 6 7
Click Finish. In the policy editor dialog box, click My Custom Programs > Notepad > Settings. In the Notepad Settings pane, double-click Notepad[cust_Notepad_ps] and do the following:
Check and expand This Custom Program PSET is fully open, it has no default security restrictions, and then click List of programs to route to this 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.
In the policy editor dialog box, double-click Resource Lists > Read-only Resource Lists and do the following:
Check and expand Block modifications to these files, and then click List of files that should not be modofied.
14
In the List of files that should not be modified section, click Add, and then add the file path that you do not want to be modified. For example, test.txt.
Click OK and apply the policy on the agent.
10 On the agent computer, open the test.txt file and verify the following events:
The Notepad.exe getting PPST,655,2011-09-09 20:02:38.919 Z-0400 assigned to the custom ,I,,,b3218cab450cde2dde92d225489f4ee0, pset cust_notepad_ps 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,, Denied File Access Event when the test.txt is accessed by using notepad PFIL,656,2011-09-09 20:02:38.593 Z-0400, W,,R,b3218cab450cde2dde92d225 489f4ee0,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,,
See About using custom programs with the Targeted prevention policy on page 10. See Creating custom programs based on the fully closed template on page 14.
Creating custom programs based on the fully closed template

The Symantec Critical System Protection Targeted prevention policy lets you create custom programs based on the fully closed template. To create a custom program based on the fully closed template
1 2 3
In the management console, click Prevention View. On the Policies page, click the Symantec folder and then in the workspace pane, double-click sym_win_targeted_prevention_sbp. In the policy editor dialog box, click My Custom Programs, and then click New.
15
In the New Custom Control Wizard dialog box, specify the following information:
Display Name Type a descriptive name. Example: Services Category Select This Custom Program PSET is fully closed and locked down by default. Type a name that the policy uses internally. Example: Services Group Tags Description Type a group tag name. Type a full description.
Identifier
5 6
Click Finish. In the policy editor dialog box, check Services[cust_Services_ps], and do the following:
Check and expand This Custom Program is fully closed and locked down by default, and then click List of programs to route to this custom PSET. 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. Check Enable Thread Injection Detection.
7 8
Click OK and apply the policy on the agent. Open the log file from the following path: C:\Program File(x86)\Symantec\Critical System Protection\Agent\IPS\scsplog
Verify that tlntsvr.exe is routed to the defined Custom PSET, cust_Services_ps and remaining processes are routed to the Default PSET.
See Creating custom programs based on the fully open template on page 12. See About using the fully closed custom program template on page 11. See About using custom programs with the Targeted prevention policy on page 10.
16
About the Duplicate Agent Registration settings

You can disable the registration of duplicate agents with the management server. By default, Symantec Critical System Protection lets you register duplicate agents based on some common attributes such as IP address, agent name etc. When Symantec Critical System Protection recognizes a duplicate agent, it updates the existing agent record in the database with the new agent data and flags the agent for policies. Symantec Critical System Protection evaluates the uniqueness of each agent based on 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 16.
Disabling duplicate agent registration

Symantec Critical System Protection enables you to prevent registration of duplicate agents. To disable duplicate agent registration
1 2 3 4 5 6
In the management console, click Prevention View or Detection View. In the Prevention view or Detection view, click Admin. On the Admin page, in the Admin pane, click System Settings. In the System Settings page, click Agent settings tab. Check Detect Duplicate Agent Registration. Check attributes under Primary Agent Attributes for Duplicate Agent Identification and Secondary Agent Attributes for Duplicate Agent Identification. You must select at least one primary attribute and zero or more secondary attributes.
Click Save.
Release 5.2.8 MP2 Resolved issues
17
See About the Duplicate Agent Registration settings on page 16.
Resolved issues
Systems with heavy network load experienced higher CPU usage
The issue that caused the Active Directory servers to carry heavy network load, experience 100 percent CPU utilization caused by Symantec Critical System Protection sisidsservice and network driver, is fixed now. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: Release 5.2.8 and earlier
The System_Failed_Access_Status policy now records the login failure for batch job
Initially, the System_Failed_Access_Status policy did not record event 529 with Logon type: 4, which occurs when you specify invalid credentials for creating a batch job. Now, the policy has been updated to record the batch job login failures. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: Release 5.2.8 and earlier Policies affected: System_Failed_Access_Status, Windows Baseline policy
Root level failed telnet logon is now recorded by Symantec Critical System Protection
Symantec Critical System Protection now records the failed root logon event setup by Kerberos telnet. The Unix baseline policy and the agent are updated to record the failed root logons. Affected operating systems: All Linux and UNIX operating systems Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection Policies affected: Unix Baseline policy
18
The continuous file change alerts do not occur when you upgrade the Symantec Critical System Protection 5.2.6 MP2 agent to any new agent version
The issue that caused continuous file change alerts when you updated the 5.2.6 MP2 agent to any new agent version is fixed now. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: Release 5.2 RU8
Symantec Critical System Protection detection service start or restart triggered excessive filewatch events
In the previous version, if you started or restarted Symantec Critical System Protection detection service that resulted into incorrect filewatch events being found. Now when you perform Symantec Critical System Protection detection service start or restart, no incorrect filewatch events are generated. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: Release 5.2 RU8
The Windows_template_policy allowed adding identical value and comment entries in the filewatch list
In the previous version, you were able to add identical value and comment entries in 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 Symantec Critical System Protection console Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection Policies affected: Windows_template_policy
Blue screen error no longer occurs

The issue that caused a blue screen error to occur in Windows Server (with Anywhere USB product installed) with Symantec Critical System Protection agent installed has been fixed. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection
19
Symantec Critical System Protection policies now retain the policy values after export and import
When you export a policy, its default parameters are exported in the option-settings.sbp file. When you import a policy, the Parameter values in option-settings.sbp and those in the compiled policy settings are merged. Hence, when a merged parameter from option-settings.sbp matches a parameter already in the compiled policy, the parameter from the compiled policy is overwritten. Now, when you import the policy, the Import option deletes the matching parameter in compiled policy settings resulting in policy values retention during export and import. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection
User Name information for Windows Event Log events no longer appear blank
The Event Viewer now displays the User Name information for Windows Event Log events correctly for User and Group Change Monitor rule. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection
Windows Detection Policy now provides the flexibility to add date and time restrictions to each rule in System Audit Tampering
In the previous version, you were able to add the date and time restrictions in System Audit Tampering globally. Now, the Windows Baseline policy has been updated to let you add date and time restrictions to individual rule under System Audit Tampering. This allows granularity in case you want to specify different date and time values for different rules. For example, if you do not want Symantec Critical System Protection to alert when security events from Windows Event Viewer are cleared during a specific time period, you can enable the date time restriction under Security Log Events Deleted. Now, this date time restriction won't affect other rules under System Audit Tampering. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: Release 5.2.6 Policies affected: Windows_Baseline_Detection
20
Release 5.2.8 MP2 Known issues
Timeout dialog box now displays the console name it is connected to

In the previous versions, when multiple consoles were connected to different management servers with timeout console feature activated for all consoles, it was difficult to identify which timeout dialog box was associated with which console. Now, the timeout dialog box title displays the console name it is associated to. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection
Symantec Critical System Protection now displays the correct count of registered agents in the System Summary query result
In the previous version, if you run the System Summary query, the Total Registered Agents count and Count by OS field appeared blank. Now, this issue is fixed and Symantec Critical System Protection displays the correct count of registered agents and agents count based on their specific operating system. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: All versions of Symantec Critical System Protection
Known issues
Cannot use an optional user name reference in a network rule
If any optional field in a network rule is undefined or defined but empty, the entire rule is removed from the policy for that agent. For example, if a rule references an optional list for remote IP address and an optional list for remote port, and if the remote IP list is defined but the remote port list is not defined, then the rule will be removed. The workaround for this issue is to add an asterisk (*) in the Program path field in the rule. This causes the user name field to be obeyed. Affected operating systems: Windows operating systems Affected Symantec Critical System Protection versions: Release 5.2.8
21
Successful FTP logons by root are not recorded by Symantec Critical System Protection
Symantec Critical System Protection does not record the successful FTP logons by root. The successful FTP logon information is maintained in the syslog file. The workaround for this issue involves you to manually find the FTP logon information in the /var/syslog file. You must configure the VSFTPD service to log the FTP connection information in the syslog file. Affected operating systems: RHEL 6.1(64-bit) Affected Symantec Critical System Protection versions: Release 5.2.8
22
Chapter
Release 5.2.8 MP1

What's new in version 5.2.8 MP1
What's new in version 5.2.8 MP1

This 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 support
The Symantec Critical System Protection now supports the IDS features on computers that run AIX 7.1 operating systems. The Unix Baseline Detection policy provides you all the IDS features on AIX 7.1 operating system. For example, file monitoring in polling mode, logon or logoff and failed logon monitoring, user or group configuration monitoring etc. Note: Real-time file integrity monitoring and IPS are currently not supported on AIX 7.1.
Real-time file integrity monitoring for AIX

The Real-time file integrity monitoring is supported on the following versions of AIX operating system:
AIX 6.1
24
Release 5.2.8 MP1 What's new in version 5.2.8 MP1
AIX 5.3 (64-bit kernel)
Each time you change the policies, Symantec Critical System Protection agent decides whether to use real-time file integrity monitoring or more traditional poling-based file integrity monitoring. You use the real-time file integrity monitoring to monitor all files except for the following:
File systems that are mounted from remote servers. For example, NFS or SMB file systems exported by remote systems and mounted on the AIX system. If any policy monitors the files on the remote file systems, then those files are monitored by using polling-based file integrity monitoring. Portions of local file systems that have been exported via NFS. The Symantec Critical System Protection agent uses the exportfs v command to determine what is being exported. All directories exported via NFS are monitored using polling-based file integrity monitoring. Rest of the portion of the local file systems are monitored using real-time file integrity monitoring.
Note: The Symantec Critical System Protection agent executes the exportfs v command only when the IDS daemon starts or when new detection policies are applied to the system. If the system administrator modifies the list of exports when the system is running, the Symantec Critical System Protection agent will not notice the change. The administrator should manually restart the IDS daemon after making any changes to the exported NFS configuration to ensure the Symantec Critical System Protection agent is using the updated information.
Chapter
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 Resolved issues Legal Notice
What's new in release 5.2.RU8

IDS and IPS features
Additional platform and feature support
The 5.2.RU8 release adds support for the following platforms:
The Symantec Critical System Protection agent now supports the IDS features on computers that run Red Hat Enterprise Linux 6.0 and 6.1 operating systems (64-bit only). The Symantec Critical System Protection agent now supports both the IDS features and the IPS features on computers that run SUSE Linux Enterprise Server 10 SP4. The Symantec Critical System Protection manager, console, and agent (both for IDS and IPS) now run on computers that run Windows Server 2008 R2 SP1. The use of an optional user in a policy, which was made available for computers that run Linux and AIX in release 5.2 RU7, is now supported on computers that run Windows and Solaris.
26
Release 5.2 RU8 What's new in release 5.2.RU8
User and group names in policy options can be marked as optional. If the translator cannot look up the user or group, it is omitted from the policy rather than resulting in a translation error. You enter an optional user name or group name in prevention policies by adding a dash (-) before the user name or group name. For example, you would use -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 you use administrator (with no dash) instead, the presence of the administrator name is mandatory, and the policy fails to apply if it is not available. This syntax can be used even if the user names or group names are in environment variables or registry keys. Note: This feature is implemented in the agent, so it is only available on Solaris when you use release 5.2 RU8 and later agents. Many of the IDS and IPS policy enhancements included in previous releases for other operating systems are now available on computers that run Solaris operating systems.
The agent for computers that run Solaris 9 and 10 now includes the following IDS and 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
Note: This feature is implemented in the agent, so it is only available on Solaris when you use release 5.2 RU8 and later agents. Custom IPS Policies You can now define custom program definitions in a separate policy. This feature provides flexibility in sharing those definitions among several groups of assets and in combining them with other custom policies or base prevention policies. IPS option consistency Options that let you specify a file and a process that can use that file are available in all resource lists in the IPS policy.
27
IPS translator options

Wildcards and netmasks in IP addresses Local subnet translator functions
Note: This feature is implemented in the agent, so it is only available on Solaris when you use release 5.2 RU8 and later agents.
Note: Real-time file integrity monitoring is not currently supported on Solaris.
Support for syslog-ng

Symantec Critical System Protection now supports syslog-ng on computers that run Solaris 9 and 10 operating systems.
Configuring syslog-ng and rsyslog for use with the Symantec Critical System Protection IDS agent
The Symantec Critical System Protection IDS agent supports the syslogd, syslog-ng, and rsyslog system logging daemons. The standard UNIX system logging daemon should work without any additional user configuration. If syslog-ng and rsyslog were installed with their configuration and their start scripts in nonstandard locations, then you may need to perform additional configuration steps to get the Symantec Critical System Protection IDS agent to work properly with them. We provide the following information about the Symantec Critical System Protection IDS agent's assumptions regarding the system logging daemon so that you can adjust your configuration to conform to these assumptions. For the latest information on this topic, see the following URL: Additional configuration steps may be required for the Symantec Critical System Protection IDS Agent to work properly with syslog-ng and rsyslog logging daemons
About system logging daemon selection

You can explicitly configure the Symantec Critical System Protection IDS agent to make use of a particular logging system. You can use Syslog Daemon key in the System Collector section of the LocalAgent.ini file for this purpose. Any changes to this setting do not take effect until the sisidssaemon is restarted. The relevant section of the LocalAgent.ini file is as follows:
28
[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 System Protection IDS agent attempts to configure and make use of that type of system logger. The installed logger must conform to the assumptions that are outlined in the following topics: See About system logging daemon configuration on page 28. See About the system logging daemon script on page 29. If the Symantec Critical System Protection IDS agent fails to configure and start the system logger that is specified in the LocalAgent.ini file, or if a system logger type is not explicitly specified, then the IDS agent attempts to detect the logging daemon in use by querying the running process list and looking for the process names in the following order:

syslogd syslog-ng rsyslogd
If the IDS agent does not find one of those processes, it then attempts to start the logging daemons in the following order:

syslogd syslog-ng rsyslogd
See About the system logging daemon script on page 29.
About system logging daemon configuration

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

syslogd: /etc/syslog.conf syslog-ng: /etc/syslog-ng/syslog-ng.conf rsyslogd: /etc/rsyslog.conf
29
If the configuration files are not located at their assumed locations, then you must create a symlink from the assumed path to the actual path. For example, on RHEL 5.4, syslog-ng installs its configuration at /usr/local/etc/syslog-ng.conf, but it can be located anywhere, depending upon the build configuration options that were used when the package was created. For example, you might use the following to create a link:
ln -s /etc/syslog-ng.conf /usr/local/etc/syslog-ng.conf
About the system logging daemon script

The Symantec Critical System Protection IDS agent uses the following commands to 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 Protection on Solaris 10

The Symantec Critical System Protection agent requires the configuration file to be located at /etc/syslog-ng/syslog-ng.conf. It also requires that the SMF service
30
name be the same as syslogd: svc:/system/system-log. If you need to use an existing configuration, 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 must rename them to system-log. Note: You must start the syslog-ng daemon in background process mode rather than the default foreground mode. Starting it in foreground mode makes it appear that two instances are running. The Symantec Critical System Protection agent is 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 downloaded and installed all syslog-ng packages and any software on which it depends from sunfreeware.com. To configure syslog-ng to work with Symantec Critical System Protection on Solaris 10
Create the /etc/syslog-ng directory. For example, you can use the following commands:
cd /etc mkdir /etc/syslog-ng chmod 755 /etc/syslog-ng chown root:sys /etc/syslog-ng
Depending on your configuration, perform one of the following tasks:
If you use the default configuration file that is provided by the SMCsyslng package, 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 /etc/syslog-ng/syslog-ng.conf
If you used an existing configuration, then create a symlink to the existing configuration file, /etc/syslog-ng.conf. For example, you can use the following command:
ln -s /etc/syslog-ng.conf /etc/syslog-ng/syslog-ng.conf
31
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 from syslog-ng: Conversion from character set '646' to 'UTF-8' is not supported, then create or add the following line to the /usr/local/lib/charset.alias file: 646 ISO-8859-1
Disable syslogd and remove the original syslogd SMF service manifest from the database. For example, you can use the following commands:
svcadm disable svc: /system/system-log svccfg svc:> delete system-log* svc:> quit
Save a copy of the original syslogd SMF manifest and method files. For example, 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
Copy or modify the syslog-ng service manifest and method files to the following 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 the SMCsyslng 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'
32
--> name='system/system-log' 68c68 < exec='/lib/svc/method/syslog-ng %m' --> exec='/lib/svc/method/system-log %m' 78c78 < exec='/lib/svc/method/syslog-ng %m' --> exec='/lib/svc/method/system-log %m' 88c88 < exec='/lib/svc/method/syslog-ng %m' --> exec='/lib/svc/method/system-log %m'
# 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
33
Validate and import the syslog-ng SMF manifest, 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
Verify that only one instance of syslog-ng is running and that it matches the PIDFILE, /var/run/syslog-ng.pid. If syslog-ng is not running, check the SMF svc log, /var/svc/log/system-system-log\:default.log by using the following command:
ps -ef |grep syslog-ng
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 similar to the following line:
Oct 27 15:16:40 local@scsp-sol10 root: [ID 702911 daemon.crit] syslog-ng test
34
Configuring Symantec Critical System Protection to work with syslog-ng on Solaris 10

To configure Symantec Critical System Protection to work with syslog-ng on Solaris 10
Stop the Symantec Critical System Protection IDS agent by using the following command:
/etc/init.d/sisidsagent stop
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 to SYSLOGNG. Make very sure that the Syslog NG Source option is correct for your configuration. For example, the [Syslog Collector] section should look similar 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 the value.
Start the Symantec Critical System Protection IDS agent by using the following command:
/etc/init.d/sisidsagent start
Verify that the following lines were added to the /etc/syslog-ng/syslog-ng.conf file:
# 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); };
Generate some syslog messages, for example log on and log out with the appropriate policy applied. Verify that an event is generated as expected.
35
Configuring syslog-ng to work with Symantec Critical System Protection on Solaris 8 and Solaris 9
For Solaris 8 and Solaris 9, the Symantec Critical System Protection IDS agent requires that the configuration file be /etc/syslog-ng/syslog-ng.conf, and the startup script be /etc/init.d/syslog. If you have already set up syslog-ng with different startup or configuration scripts, make sure that there are symlinks pointing to the existing startup and configuration files. Note: You must start the syslog-ng daemon in background process mode rather than the default foreground mode. Starting it in foreground mode makes it appear that two instances are running. The Symantec Critical System Protection agent is 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 downloaded and installed all syslog-ng packages and any software on which it depends from sunfreeware.com. To configure syslog-ng to work with Symantec Critical System Protection on Solaris 8 and Solaris 9
cd /etc mkdir /etc/syslog-ng chmod 755 /etc/syslog-ng chown root:sys /etc/syslog-ng
Perform one of the following tasks:
If you use the default configuration file provided by the SMCsyslng package, copy the configuration file into /etc/syslog-ng by using 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 /etc/syslog-ng/syslog-ng.conf
If you use an existing configuration, create a symlink to the existing configuration file, /etc/syslog-ng.conf, by using the following command:
ln -s /etc/syslog-ng.conf /etc/syslog-ng/syslog-ng.conf
36
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
Copy the startup script into /etc/init.d and modify it by using the following commands:
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
If you use the startup script from the SMCsyslng package, you must make some 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
Shut down the syslogd process by using the following command:

/etc/init.d/syslog.orig stop
37
Start syslogd-ng by using the following command:

/etc/init.d/syslog start
Verify that only one instance of syslog-ng is running and that it matches the PID in the /etc/syslog-ng/syslog-ng.pid file by using the following command:
ps -ef |grep syslog-ng
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 is similar 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-ng on Solaris 8 and Solaris 9
To configure Symantec Critical System Protection to work with syslog-ng on Solaris 8 and Solaris 9
38
# 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); };
Generate some syslog messages, for example, log on and log out with the appropriate policy applied. Verify that an event is generated as expected.
Configuring syslog-ng 3.x to work with Symantec Critical System Protection on RHEL 5.4
The Symantec Critical System Protection IDS agent requires that the configuration file be /etc/syslog-ng/syslog-ng.conf, and the startup script be /etc/init.d/syslog. If you have already set up syslog-ng with different startup or configuration scripts, make sure that there are symlinks pointing to the existing startup and configuration files. Note: You must start the syslog-ng daemon in background process mode rather than the default foreground mode. Starting it in foreground mode makes it appear that two instances are running. The Symantec Critical System Protection agent is 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 downloaded and installed all syslog-ng packages and any software on which it depends from www.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
39
To configure syslog-ng to work with Symantec Critical System Protection on RHEL 5.4
cd /etc mkdir /etc/syslog-ng chmod 755 /etc/syslog-ng chown root:root /etc/syslog-ng
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 /etc/syslog-ng/syslog-ng.conf
Rename the legacy syslog startup script and rename the syslog-ng startup script 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
Edit the /etc/init.d/syslog startup script to add the --process-mode switch to the SYSLOGNG_OPTION. For example, it should look similar to the following text:
case "$OS" in Linux) SYSLOGNG_OPTIONS="--no-caps --process-mode=background" ;; esac
40
# 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(s_local); filter(scsp_filter); destination(scsp_dest); };
Generate some syslog messages, for example, log on and log out with the appropriate policy applied. Verify that an event is generated as expected.
IPS features
Root accountability
Before release 5.2 RU8, there was no simple way to monitor users who escalated their privileges to root. If multiple users simultaneously su'ed to root, their root
41
actions were logged, but you could not connect a particular log entry to a particular user's non-root user ID. In all prevention events that contain user name information, Symantec Critical System Protection now records the immediately previous user name in addition to the current user name. Now, when UNIX or Linux users use the su command to escalate to superuser privilege, this escalation is logged with the users' original login IDs. Users can now be monitored and held accountable for their actions while they have different privileges. The immediately previous user name is the effective user name at the time of the setid call. Symantec Critical System Protection does not record the effective user name and real user name of the process after the setid call, since the real user name is generally set to be the same as the effective user name, even after an su. Note: Symantec Critical System Protection records only the immediately previous user name. It does not record an arbitrary chain of user names. The root accountability feature is available only on UNIX or Linux operating systems that support Symantec Critical System Protection Intrusion Prevention (IPS). For a simple scenario, such as the case where an administrator logs onto a computer and switches to user1, Symantec Critical System Protection now shows the full picture. The logs of the administrators activity while logged on as user1 show both the user1 name and the administrator name in the events. For chained su use cases as where an administrator logs onto a computer, switches to user1, and then switches to user2, Symantec Critical System Protection now shows part of the picture. Activity while the administrator is logged on as user2 shows the user2 name and user1 name, but does not record the administrator name in the logs for these events.
Event data
The previous user name data is recorded as an additional field in all existing UNIX-related prevention events. The following possibilities exist for this additional field:
It can be empty. An empty field means that the process has never had a user name different from the current one. It can have a single user name. A single user name means that the process has had only one other user name than the current one.
42
It can have two user names. Two user names means that the process has had at least two different user names before the current one.
In the Comma Separated Value (CSV) files stored on the agents, the previous user name data appears in field 30 of the event. In the example events shown, the previous user name is in the last field of each entry.
PPST,17213,2011-04-06 01:29:22.000 Z0700,I,,G,073adb47013fc4e3cf7d7d37300a4df3,,,,jeff,0,/bin/ps,12797,, ps -elf --forest,exec,int_rootpriv_ps,12614,,,,/bin/bash,,,,0,,,root PFIL,17297,2011-04-06 01:30:49.000 Z0700,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 data appears as an additional field in the Details section of the display.
SOURCE Agent Name Host Name Host IP Address User Name Agent Version OS Type OS Version Agent Type EVENT Event Type Event Category Operation Event Severity Event Priority Event Date Post Date Post Delay Event Count Event ID File Access Real Time - Prevention open Warning 45 05-Apr-2011 18:30:49 PDT 05-Apr-2011 18:35:00 PDT 00:04:11 1 2744180 gbvm-rhel5 gbvm-rhel5 10.180.246.110 jeff 5.2.8.76 Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 (x86_64) CSP Native Agent
43
DETAILS Description Policy Name Process File Name Agent State Disposition Process Set Operation OS Result SCSP Result Permissions Requested Process ID Thread ID Previous User Names File Write Allowed for touch on /home/jeff/file.noaccess policy_unix_5.2.8 /bin/touch /home/jeff/file.noaccess Prevention Globally Disabled Allow int_rootpriv_ps open 00000000 (SUCCESS) 00000000 (SUCCESS) 0000000a (write, create) 12845 0 root
About multiple previous usernames

Some events record two previous user names in the data. When this occurs, the user names are separated by a colon and the most immediately previous user name is listed first. For example, consider an event that contains the following user name information:
User Name Previous User Names
root jeff:root
The following information applies to this event:
The processs current effective user name is root. This name is located in the User Name field. The current process came from a process that most recently had the user name jeff. 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 name root. root is the second user name listed in the Previous User Names field.
At times the second user name listed in the Previous User Names field is not very relevant. It can be the user name of the daemon that created the login shell or of the su command. At other times it can be relevant. It can be the user name of an su session or login session the human user was in before becoming the current user name.
44
Examples User jeff logs on

In this scenario, once user jeff logs in, events display the Previous User Name of 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 person logging in never had a root shell. The following examples show the CSV events. Process assignment event when sshd changes user to jeff:
PPST,16898,2011-04-06 01:24:20.000 Z0700,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 line arguments, run by user jeff:
PPST,17213,2011-04-06 01:29:22.000 Z0700,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 Z0700,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 name as root. The following text show how the same file access event displays on the console.
SOURCE Agent Name Host Name Host IP Address User Name Agent Version OS Type OS Version Agent Type gbvm-rhel5 gbvm-rhel5 10.180.246.110 jeff 5.2.8.76 Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 (x86_64) CSP Native Agent
45
EVENT Event Type Event Category Operation Event Severity Event Priority Event Date Post Date Post Delay Event Count Event ID DETAILS Description Policy Name Process File Name Agent State Disposition Process Set Operation OS Result SCSP Result Permissions Requested Process ID Thread ID Previous User Names File Write Allowed for touch on /home/jeff/file.noaccess policy_unix_5.2.8 /bin/touch /home/jeff/file.noaccess Prevention Globally Disabled Allow int_rootpriv_ps open 00000000 (SUCCESS) 00000000 (SUCCESS) 0000000a (write, create) 12845 0 root File Access Real Time - Prevention open Warning 45 05-Apr-2011 18:30:49 PDT 05-Apr-2011 18:35:00 PDT 00:04:11 1 2744180
User jeff su's to root

When user jeff sus to root, the previous user name data shows the current user name of the process as root, and the previous user name data has both jeff and root:
jeff is the immediately previous user name, reflecting the fact that jeff
logged 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.
46
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 shows jeff:root, indicating that the user name jeff is the immediately previous user name.
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
Process assignment event showing a ps command with command line arguments, run by root. You can compare this with the event for the same ps command run previously 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
The following text show how the same file access event displays on the console.
SOURCE Agent Name Host Name Host IP Address User Name Agent Version OS Type OS Version Agent Type EVENT Event Type Event Category Operation Event Severity File Access Real Time - Prevention lstat Warning gbvm-rhel5 gbvm-rhel5 10.180.246.110 root 5.2.8.76 Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 (x86_64) CSP Native Agent
47
Event Priority Event Date Post Date Post Delay Event Count Event ID DETAILS Description Policy Name Process File Name Agent State Disposition Process Set Operation OS Result SCSP Result Permissions Requested Process ID Thread ID Previous User Names
45 05-Apr-2011 18:33:07 PDT 05-Apr-2011 18:37:19 PDT 00:04:12 1 2744185
File Read Allowed for ls on /home/jeff/file.noaccess policy_unix_5.2.8 /bin/ls /home/jeff/file.noaccess Prevention Globally Disabled Allow int_rootpriv_ps lstat 00000000 (SUCCESS) 00000000 (SUCCESS) 00004000 (stat) 12973 0 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 jeff simply logs on. Refer to the first example for the events related to the first stage. See User jeff logs on on page 44. The second stage of this scenario shows user jeff su'ing directly to user bob. The following example events represent the second stage of this scenario. Note: The Previous User Names field lists root, and then jeff. The root user name reflects the su program being run by jeff. su is a setuid root program, and thus the root user name is inserted into the Previous User Names field. This behavior is the same on Solaris and Linux operating systems, but is not the same on AIX operating systems. In this scenario, the first previous user name is not very relevant, since it only indicates that the su program itself momentarily became root in order to
48
accomplish the identity change to bob. Contrast this with the final scenario where user jeff logs on, su's to root, and then su's to become user bob. The following examples show the CSV events. 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, ,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. The example shows running the ps command in the root shell. This is identical to Use Case 1a above. The second stage of the user case is running the su command again, from the root shell, to become the user bob. Compare the two events below for the user bob with the corresponding two events from the previous scenario where user jeff logs on and then su's to bob. You see that the events look identical. Specifically, the previous user name data in both sets of events is the same. The fact that in the previous scenario where user jeff logs on and then su's to bob, there was no root shell involved while in this scenario there was a root shell involved is not apparent from the single events shown. To determine 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. The following examples show the CSV events. Process assignment event showing a ps command, along with command line arguments, 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
49
Process assignment event showing a ps command, along with command line arguments, run by bob. See that the previous user name info has pushed jeff to the 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
The following text show how the same file access event displays on the console.
SOURCE Agent Name Host Name Host IP Address User Name Agent Version OS Type OS Version Agent Type EVENT Event Type Event Category Operation Event Severity Event Priority Event Date Post Date Post Delay Event Count Event ID DETAILS File Access Real Time - Prevention stat Warning 45 05-Apr-2011 00:08:44 PDT 05-Apr-2011 00:12:58 PDT 00:04:14 1 2744212 gbvm-rhel5 gbvm-rhel5 10.180.246.110 bob 5.2.8.76 Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 (x86_64) CSP Native Agent
50
Description Policy Name Process File Name Agent State Disposition Process Set Operation OS Result SCSP Result Permissions Requested Process ID Thread ID Previous User Names
File Read Allowed for ls on /home/jeff/file.noaccess policy_unix_5.2.8 /bin/ls /home/jeff/file.noaccess Prevention Globally Disabled Allow int_rootpriv_ps stat 00000000 (SUCCESS) 00000000 (SUCCESS) 00004000 (stat) 23750 0 root:jeff
Child processes of custom applications can be assigned to another custom application process set
The initial implementation of the custom program feature assigned the child processes of a custom program to its parent process set. Now when you define a custom program, any processes that the custom application launches can be reassigned to other custom application process sets that were defined in another custom program.
Importing a file list

Symantec Critical System Protection now provides a new policy function, ImportFileList, that can reference a text file on the agent and import strings from that file into the policy. You can use the new function anywhere in the policy that you can enter strings, for example, anywhere you can enter file paths, registry paths, user names, and so on. When the policy is applied to an agent, the agent then retrieves a list of strings from the referenced file and substitutes them into the 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 in the console. For example, a file can contain strings such as file paths, Windows registry entries, user names, group names, or IP addresses. Only one string must appear on each line of the file.
Release 5.2 RU8 Additional release information
51
You can use Unicode or ASCII file format. Each file must contain no more than 100 lines. If the number of lines exceeds 100, then Symantec Critical System Protection returns an error and the file is not used in the policy. Begin the import file function with a percent question mark (%?) and end it with a question mark percent (?%). An example that imports a file list that is named privuserlist.txt is %?ImportFileList(c:\mydir\privuserlist.txt)?% A file can be made optional by adding a dash (-) after the prefix and before the function. An example that imports an optional file list that is named privuserlist.txt is %?-ImportFileList(c:\mydir\privuserlist.txt)?% When optional, the policy is still applied even if the file is not available on the system. Place the file on the computer that runs the Symantec Critical System Protection agent. The file is read at the time that the policy is applied.
Importing a list of strings into a policy from a file

To import a list of strings into a policy from a file
1 2 3
Open policy in the console. Open the parameter that you want to populate from a list of strings in a file. Type the following input into the parameter field:
To populate a parameter where the policy is not applied if the file is available on the system: %?ImportFileList(filepath)?% To populate a parameter where the policy is still applied even if the file is 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 events
Symantec Critical System Protection now provides root accountability. It logs a user's previous UID as well as the current UID for each logged IPS event.
52
Release 5.2 RU8 Additional release information
See Root accountability on page 40.
Use of Tomcat 5.5.33

Symantec Critical System Protection now uses Apache Tomcat version 5.5.33.
Restart required
When the Symantec Critical System Protection prevention feature is enabled, you must restart all Windows agent computers after an installation or upgrade. As of release 5.2 RU6, when Real-time File Integrity Monitoring became available, all Windows agents must be restarted after an installation or upgrade, even if the Symantec Critical System Protection prevention feature is not enabled. A restart is required so that the Real Time File Integrity Monitoring feature works properly for all Windows agents. This feature is enabled by default on all supported Windows operating systems. Operating systems affected: Windows, all supported versions
You must upgrade Solaris x86 agents before you upgrade your Symantec Critical System Protection management servers to release 5.2 RU8
Solaris x86 5.2 RU7 and older agents cannot communicate at all with the 5.2 RU8 management server. You must upgrade all Solaris x86 agents to 5.2 RU8 before you upgrade your management server to 5.2 RU8. Note: This issue affects only the Solaris x86 agents; there is no issue with Solaris SPARC agents or agents on any other operating system.
Microsoft SQL Server 2000 is no longer supported

As of release 5.2 RU6, you can no longer use Microsoft SQL Server 2000 as the database for Symantec Critical System Protection. If you upgrade Microsoft SQL Server 2000 to a later version, you must ensure that the database compatibility level of the SCSPDB database is set to level 80 or higher. To check or modify the SCSDB compatibility level
1 2
Open the SQL Server Management Studio. Use the sa user name to log in to the Microsoft SQL Server database.
Release 5.2 RU8 What you need to know before you install or upgrade your software
53
3 4
Under Databases, right-click SCSPDB, and then select Properties > Options > Select Compatibility level. Check the compatibility level. If it is lower than 80, change it to be 80 or higher.
About the minimum agent version numbers

The minimum agent version number that appears in the Symantec Critical System Protection console reflects the oldest version of the agent that supports that policy. The policy is supported on all newer versions of the agent as well.
What you need to know before you install or upgrade your software
The Symantec Critical System Protection Implementation Guide contains detailed information about how to install the Symantec Critical System Protection components. 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 and most complete information about the release and known issues and workarounds, refer to the readme file that accompanies this release. For information about Symantec Critical System Protection features and platforms, see the Platform and Feature Matrix located in the docs folder on the product disc that contains this release. Table 3-1 Step
1
Overview of an installation Description

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

Action
Plan the installation
Network architecture and policy distribution Firewalls Name resolution IP routing
Review the system requirements
All the computers on which you install Symantec Critical System Protection should meet or exceed the recommended operating system and hardware requirements.
Decide on the You can install the management console and management server on the same computers to install the computer or on separate computers. You can install agents on any computer. software components All computers must run a supported operating system.
54
Release 5.2 RU8 What you need to know before you install or upgrade your software
Table 3-1 Step

4
Overview of an installation (continued) Description

You can install the following management server installation types: An evaluation installation that runs SQL Server 2005 Express on the local system An evaluation installation that uses an existing MS SQL instance

Action
Decide on the management server installation type
A production installation with Tomcat and the database schema The Tomcat component only
Configure the TEMP environment variable
The installation packages unpack installation files into the directory that is specified by the TEMP environment variable. The volume that contains this directory must have at least 200 MB of available disk space. If this volume does not have the required disk space, you must change your TEMP environment variable.
Install the management You begin the installation by installing the management server. server Management server installation prompts you to enter a series of values consisting of port numbers, user names, passwords, and so on. Each database that you can install uses different default settings and options for the management server and database. Install the management Install the management console after you install the management server. console The management console installation also installs the authoring environment. The management console installation does not prompt you to enter port numbers or server names. You enter this information after installation, when you configure the management console.
Configure the management console
Management console configuration prompts you to enter a series of values consisting of port numbers, passwords, and a server name. In a few instances, the port numbers must match the port numbers that were specified during management server installation. Install the agents after you install the management server, and after you install and configure the management console. The agent installation prompts you to enter a series of agent values consisting of port numbers, management server name, etc.
Install the agents
Release 5.2 RU8 Resolved issues
55
Resolved issues
Network-related memory leak in Windows 2008 R2 agents has been fixed
The issue that caused a memory leak in the IPS drivers in the Windows 2008 R2 agent has been fixed. This issue appeared when a computer that had software that listened for incoming network connections, repeatedly stopped and restarted itself. A memory leak of approximately 4k occurred in the IPS driver every time a program that listened on the network, that is, a network server-side program, stopped. On Windows, many network services start up, listen on the network, and continue to run for the life of the system. This behavior does not result in a memory leak. However, if a program is designed to repeatedly stop and restart on a schedule as a result of closing a network connection, or for any other reason, the leak occurred. The speed of the leak depended on the frequency at which the listening program or programs stopped and restarted. At this point, Symantec has not seen any standard Microsoft software behave in the problematic fashion. The following conditions are required for the issue to manifest itself:
The computer runs the Windows 2008 R2 operating system. Older Windows versions and all UNIX/Linux versions do not exhibit this issue. The Symantec Critical System Protection Prevention feature is enabled. The Prevention feature is enabled by default, but if you have disabled the Prevention feature by using the command line switch at installation or by using the sisipsconfig -i command at a later time, the issue does not occur.
Affected operating systems: Windows 2008 R2 Affected Symantec Critical System Protection versions: releases 5.2.6 and 5.2.7
Custom program child processes can now be assigned to other custom application process sets
The initial implementation of the custom program feature assigned the child processes of a custom program to its parent process set. Now when you define a custom program, any processes that the custom application launches can be reassigned to other custom application process sets that were defined in another custom program. Affected operating systems: All supported management server OSs
56
Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older management servers
Console timeout now works as expected

The console no longer hangs and requires a user to stop the console.exe process when it times out. Affected operating systems: All supported console OSs Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older consoles
The Policy Viewer is no longer grayed out on the console Detection tab
You no longer have to restart the console to make the Policy Viewer an active choice on the console Detection tab. Affected operating systems: All supported console OSs Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older consoles
User names are no longer empty or incorrectly displayed as root

The agent was not properly parsing some syslog messages from the Fsecure sshd2 program. As a result, some events from this program had empty user names or had an incorrect user name of root. The agent has been updated to properly parse syslog messages from this program. Affected operating systems: all supported versions of RedHat Linux, SUSE Linux, Solaris, AIX, and HP-UX Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older consoles
IDS agent now modifies the /etc/syslog-ng.conf file

The issued that caused the IDS agent to be unable to modify the /etc/syslog-ng.conf file on computers that run Red Hat Enterprise Linux 5.5 has been fixed. Affected operating systems: RedHat Linux 5 Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older agents
57
The sisidsdaemon no longer stops if the FileWatch.dat file becomes corrupted

The issue that caused the sisidsdaemon to stop after the FileWatch.dat file became corrupted has been fixed.
Policy name field now appears in data exported from the Event Search feature
When you export the data from a search to a CSV file, the exported data now includes the name of the policy. Affected operating systems: All supported console OSs Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older consoles
An event search now resets the event count and page after every search
In previous versions, if you conducted a second event search that resulted in no events being found, the results table still displayed the data from the previous search. Now when you perform an event search, the table data and event count are reset even if the search results are empty. Affected operating systems: All supported console OSs Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older consoles
Console is no longer unresponsive when an illegal character is entered into the Custom Rule Identifier field
If you entered an illegal character, such as a dash (-), into the Identifier Type field of either a Custom Rule in a Detection policy or a Custom Program in a Prevention policy, the console would become unresponsive. The only solution was to kill the console and launch it again. The validation for the Identifier field has been fixed so that invalid characters are identified and the console remains responsive. Affected operating systems: All supported console OSs Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older consoles
58
File and directory permissions for UNIX agents

The permissions on several internal Symantec Critical System Protection UNIX agent files and directories have been changed to 600.
Java script error no longer occurs

The issue that caused a Java script error to occur when trying to change a detection policy setting from a Web console has been fixed. Affected operating systems: All supported management server OSs Affected Symantec Critical System Protection versions: Symantec Critical System Protection 5.2 RU7 and older management servers
Bulk log file size no longer increases past the value set for maximum log size
Previously, bulk log file size could increases past the value set for maximum log size when a computer that ran Windows 2008 or 2008 R2 was very busy. The agent query for the log file size was not getting up-to-date size information, which resulted in the log file rollover not being triggered. The agent has been updated to get the correct, current log file size even when the system is very busy. Affected operating systems: Windows 2008, Windows 2008 R2 Affected Symantec Critical System Protection versions: 5.2 RU7 and older agents
Documentation correction: UNIX Baseline Policy Reference Guide

The system attack detection option group entries for Stack execution denied and System time changed should be ignored. They are still separate policies and have not been merged into the UNIX Baseline policy. The UNIX Baseline Policy Reference Guide has been updated to reflect this policy change.
Documentation correction: Windows Baseline Policy Reference Guide

The options to monitor when USB devices are connected and disconnected have been removed from the Windows Baseline Detection policy. The entries that describe these options in the Windows Baseline Policy Reference Guide should be ignored. The Windows Baseline Policy Reference Guide has been updated to reflect this policy change.
Release 5.2 RU8 Legal Notice
59
Legal Notice
Copyright 2011 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, Bloodhound, Confidence Online, Digital Immune System, LiveUpdate, Norton, Sygate, and TruScan are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This Symantec product may contain third party software for which Symantec is required to provide attribution to the third party (Third Party Programs). Some of the Third Party Programs are available under open source or free software licenses. The License Agreement accompanying the Software does not alter any rights or obligations you may have under those open source or free software licenses. Please see the Third Party Legal Notice Appendix to this Documentation or TPIP ReadMe File accompanying this Symantec product for more information on the Third Party Programs. The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19 "Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in Commercial Computer Software or Commercial Computer Software Documentation", as applicable, and any successor regulations. Any use, modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government shall be solely in accordance with the terms of this Agreement.
60
Release 5.2 RU8 Legal Notice
Symantec Corporation 350 Ellis Street Mountain View, CA 94043 http://www.symantec.com

SCSP 5 2 8 MP2 Release Notes

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SCSP 5 2 8 MP2 Release Notes

Încărcat de

Drepturi de autor:

Formate disponibile

Release Notes for Symantec Critical System Protection Version 5.2.

Release 5.2.8 MP2 ................................................................ 7

Release 5.2.8 MP1 .............................................................. 23

Release 5.2 RU8 .................................................................. 25

Release 5.2.8 MP2

About Symantec Critical System Protection

Among Symantec Critical System Protection's key benefits are:

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

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

What's new in release 5.2.8 MP2

Targeted prevention policy

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

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

The following directories are protected against being renamed:

The agent install directory The agent log directory

The Targeted prevention policy provides the following options:

Default PSET options

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

How the Targeted prevention policy works

About using custom programs with the Targeted prevention policy

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

Fully closed template

About using the fully closed custom program template

Block modifications to these files

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

Block modifications to these Registry keys

About using custom lists with the Targeted prevention policy

Creating custom programs based on the fully open template

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

To create a custom program based on the fully open template

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

Click OK and apply the policy on the agent.

Creating custom programs based on the fully closed template

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

Release 5.2.8 MP2 What's new in release 5.2.8 MP2

About the Duplicate Agent Registration settings

Agent name Host name IP address

Domain name Operating system type

See Disabling duplicate agent registration on page 16.

Disabling duplicate agent registration

Release 5.2.8 MP2 Resolved issues

See About the Duplicate Agent Registration settings on page 16.

Release 5.2.8 MP2 Resolved issues

Blue screen error no longer occurs

Release 5.2.8 MP2 Resolved issues

Release 5.2.8 MP2 Known issues

Timeout dialog box now displays the console name it is connected to

Release 5.2.8 MP2 Known issues

Release 5.2.8 MP2 Known issues

Release 5.2.8 MP1

What's new in version 5.2.8 MP1

What's new in version 5.2.8 MP1

Real-time file integrity monitoring for AIX

Release 5.2.8 MP1 What's new in version 5.2.8 MP1

AIX 5.3 (64-bit kernel)

Release 5.2 RU8

What's new in release 5.2.RU8

Release 5.2 RU8 What's new in release 5.2.RU8

Release 5.2 RU8 What's new in release 5.2.RU8

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-ng