Continue with the Best Practices Series for Citrix ...

Symptoms

XEN Virtual Desktop Infrastructure desktop clients register multiple times in the Symantec Endpoint Protection Manager

Best Practices

• Choose one of the following :
  • Instead of  Standard Image Mode (read only)
    • Use the third vDisk mode ("Difference Disk Image") on the provisioned clients. SEPM registration, definition updates and such are saved in between reboots. The base vDisk is still not changed—changes that are made by a client computer are saved in a linked cache. Any undesired changes will be purged the next time you update the underlying vDisk
  • Use a startup script to set a fixed HardwareID at boot 

It is possible in these cases to use a script to set the HardwareID to a fixed unique value during system startup. This must be done during the startup process before the Symantec service starts, otherwise the old ID is used if present or a random one is generated. Note that this startup script helps only with problems caused by random or duplicate HardwareIDs; virus definition updates must be addressed separately.

 The following instructions are provided as an example of using a startup script to set a HardwareID based on the machine's MAC address.  Please note that the script provided here is intended as an example only for the customer's convenience.  The customer is responsible for its implementation and Symantec can offer only limited support in the event that the script does not work as expected.

 Disable Tamper Protection on the SEP client; this must be done to allow the file and registry changes in steps below.

 Close any open SEP Client GUIs, go to the command line, navigate to the Symantec Endpoint Protection program files directory and stop the SEP Smc service

 smc -stop

 Set SEP service to start manually.

 In SEP 12.1, set HKLM\SYSTEM\CurrentControlSet\services\SepMasterService\Start=3

 In SEP 11.x, set HKLM\SYSTEM\CurrentControlSet\services\SmcService\Start=3

 On the base disk image for the provisioned clients, create startup batch file "c:\sephwid.bat". This startup script will clear any existing SEP hardware identifiers, set a fixed Hardware ID based on the first available MAC address on the machine, and start the SEP service. Note that this must be a machine startup script, not a login script, so that it runs before any logon. Use the following example, edit/comment/uncomment as appropriate, and be aware of line wrapping:

 rem ### Check If Computer Is Running A 32 Bit or 64 Bit Operating System:

rem ### http://support.microsoft.com/kb/556009

rem ###

rem ### registry commands must use "/reg:64" switch on 64-bit OS

rem ### this switch is supported in Server 2008 & Win7,

rem ### but a hotfix is necessary for older 64-bit systems:

rem ### http://support.microsoft.com/kb/948698

 set reg64switch=

reg query "HKLM\Hardware\Description\System\CentralProcessor\0" | find "x86"

if errorlevel 1 set reg64switch=/reg:64

 rem ### registry location for SEP HardwareID--this is the same on 32- or 64-bit systems

set hwidkey="HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink"

rem ### delete any current SEP hardware identifiers, various possible locations

rem ### ref: How to prepare SEP 12.1 client for cloning: www.symantec.com/docs/HOWTO54706

for /d %%d in (

"C:\Program Files\Common Files\Symantec Shared\HWID"

"C:\Documents and Settings\All Users\Application Data\Symantec\Symantec Endpoint Protection\PersistedData"

"C:\ProgramData\Symantec\Symantec Endpoint Protection\PersistedData"

"C:\Windows\Temp"

) do del /f "%%~d\sephwid.xml"

for /d %%d in (

"C:\Documents and Settings\*"

"C:\Users\*"

) do (

del /f "%%~d\Local Settings\Temp\sephwid.xml"

del /f "%%~d\Local Settings\Temp\communicator.dat"

)

reg delete %hwidkey% /v ForceHardwareKey /f %reg64switch%

reg delete %hwidkey% /v HardwareID /f %reg64switch%

reg delete %hwidkey% /v HostGUID /f %reg64switch%

rem ### set HardwareID prefix

rem ### this can be any 20-digit hexadecimal string (using digits 0-9,A-F) in all CAPS

set myprefix=00000000000000000000

rem ### get first MAC address from "getmac" command

for /f "tokens=1" %%a in ('"getmac /nh"') do (

set addr=%%a

goto :endfor

)

:endfor

rem ### if "getmac" fails, try exchanging the line below into the for loop above

rem ### for /f "tokens=12" %%a in ('"ipconfig /all | find "Physical""') do (

rem ### remove hyphens from MAC addr

set addr=%addr:-=%  

rem ### for HardwareID, concatenate MAC addr to end of custom prefix

rem ### hwid must be a 32-digit hexadecimal string (using digits 0-9,A-F)

set hwid=%myprefix%%addr%

rem ### Set SEP HardwareID in registry

reg add %hwidkey% /v HardwareID /d %hwid% /f %reg64switch%

rem ### start SEP services

sc start SepMasterService

sc start SmcService

sephwid.bat can be debugged by calling it from a second script which simply calls the first and redirects stderr/stdout to a log file. For example--

debug.bat:

c:\sephwid.bat >c:\sephwid.log 2>&1

It is not necessary to prepare the base image for cloning, since sephwid.bat will automatically remove any previous SEP hardware identifiers every time the machine starts. The SEP client on the base image should be assigned to a SEP Manager group that has a short heartbeat and/or "push" communication so that provisioned clients can quickly re-establish a connection with the SEP Manager. When the provisioned client shuts down, the SyLink LastServer and RegCSN values will revert to those of the base image. This may cause a delay of up to two heartbeats when the provisioned client starts up again and the SEP Manager reconciles its saved CSN value with those of the client. After the provisioned client checks in it can receive new policy (including a longer heartbeat) according to its hardware ID and group membership or location awareness.

• • Configure the purge time of Citrix
  • With the SEPM Domain that you created in Part 1 go to Admin> Domains><Your Citrix Domain>
    • Edit Domain Properties
    • Delete non-persistent VDI clients that have not connected for specified time> 1 day
    • Delete clients that have not connected for specified time  Configurarlo a  1 day

Information Sources :

• http://support.citrix.com/article/CTX124185
• http://www.symantec.com/business/support/index?page=content&id=TECH123419
• http://support.citrix.com/servlet/KbServlet/download/19042-102-19576/
• http://www.symantec.com/connect/blogs/configuring-sep-121-virtual-environments
• Virtual Image Exception :
  
  • http://www.symantec.com/connect/forums/virtual-image-exception-tool
  • http://www.symantec.com/business/support/index?page=content&id=TECH172218

 Virtualization Best Practices

http://www.symantec.com/business/support/index?page=content&id=HOWTO81060

http://www.symantec.com/business/support/index?page=content&id=TECH173650

https://www-secure.symantec.com/connect/sites/default/files/Virtualization_Best_Practices.pdf

In Symantec Critical System Protection, you can use command line arguments to assign executables to their own Custom Process Sets and to activate certain rules or exceptions. 

This purpose of this document is to lay out the command line matching process, the syntax of the wildcards, and how to troubleshoot an apparent mismatch in the argument.

The command line matching process is fairly straightforward; the IPS driver reads arguments as they are passed and attempts to match them with argument statements that are entered into a process binding rule or policy rule.  The driver breaks apart the argument into pattern tokens by parsing for spaces.  For instance, the argument:

                //d srrstr.dll,ExecuteScheduledSPPCreation

Will be parsed and broken into the following two pattern tokens,

                //d
                srrstr.dll,ExecuteScheduledSPPCreation

Wildcards

Wildcards can be used.  There are two wildcards, the asterisk and the question mark.

The asterisk (*) has two uses.  When it is used without any spaces around it, it will match one or more characters in the argument. For instance,

                //d srrstr.dll,*

Will match

                //d srrstr.dll,ExecuteScheduledSPPCreation

And in another example,

                //d srrstr.dll,*xecuteScheduledSPPCreation

Matches

                //d srrstr.dll,ExecuteScheduledSPPCreation

The asterisk, when used with spaces, means that one or more pattern tokens of the argument are wildcarded.  For instance:

                * srrstr.dll,ExecuteScheduledSPPCreation

Will match

                //d srrstr.dll,ExecuteScheduledSPPCreation       

The question mark (?) is another wildcard.  Its purpose is to wildcard a single character.  This is useful for arguments that have certain patterns to match.  For instance,

                {F5078F35-C551-????-????-????????????}

Will match

    {F5078F35-C551-11D3-89B9-0000F81FE221}

Case Sensitivity

Arguments, in both Windows and -ix clients, are case sensitive by default.  File paths are not case sensitive in Windows, and are case sensitive in –ix clients.

Use can use the case insensitivity switch &ci; to turn off case sensitivity.  Use &cs; to turn on case sensitivity. A space must be placed between the case sensitivity switch and the argument for it to be registered by the driver.   For example,

&ci; //d srrstr.dll,executescheduledsppcreation                &cs; /V

Matches

//d srrstr.dll,ExecuteScheduledSPPCreation /V

Escape Characters

There are two escape characters, \ for Windows and / for –ix based agents.

The reason to use an escape character is because the driver will remove the leading \ or / from the argument when parsing it.  If you need the \ or / then add another slash. This is especially handy when calling cmd.exe /c.   For instance the argument:

        cmd /c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

Needs to be entered in the arguments section in the CSP policy as

        cmd //c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

Quotes

Use single quotation marks when there is a space in the argument, to prevent the driver from parsing it incorrectly

For instance, if the argument was entered like this in the policy, the driver would think that C:\Program is one token and Files\Symantec\Critical was another, and so on:

         cmd //c C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat

The correct way to enter this argument in the policy is:

        cmd //c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

When a batch file is double clicked in Windows, the OS adds a double quote at the beginning of any parts of arguments that have a space, and a quote-space-quote at the end of the argument.  The CSP driver recognizes this, and will treat these as single quotes.  For instance, this is what the driver will see from the OS:

      cmd //c ““C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat” “

However, when parsed, the driver will treat the argument as this:

      cmd //c “C:\Program Files\Symantec\Critical System Protection\Agent\IPS\tools\getagentinfo.bat”

Troubleshooting Command Line Matching Issues

Sometimes, a match is not found, so the process does not get assigned to the correct PSET.  When looking over the Command Line matches, it appears that it should match, but for some reason, the driver does not agree.

The first thing to do is to look for a uppercase/lower case mismatch.  This is the #1 cause of mismatches.

After confirming that case is not an issue, then start wildcarding parts of the argument, or all of it, and get a match.  Then add the specific arguments back in the argument string one at a time until you locate the mismatch.

The cmdmatchv2.exe tool can be used from the command line to see how the driver is parsing the information.  

Here is a screenshot of the tool.  This shows you how both the pattern entered into the policy and the command line arguments are parsed, and then gives you the output of the matching logic. 

Using this tool can help you figure out where an asterisk or question mark may need to be placed to get an argument to match.

You can get the tool from the downloads section of Connect here

Context

This article seeks to go over the details of configuring an AWS Virtual Private Cloud (VPC) to enable the use of centralized gateway IDS/IPS solutions in the cloud as we do today in the virualization world. 

As a part of this research, several security solutions available in the AWS marketplace were analyzed to identify existing techniques that implement some form of a centralized network IDS/IPS system. Below are some of the popular findings:

• Sophos UTM 9: Provides host based security support software with the following features:
  - Web Server Protection
  - Web Protection
  - VPN support

• CohesiveFT: The VNS-3 (Virtual Network Server) is available at the AWS Marketplace that facilitates in the creation of an overlay network to gain control of addressing, topology, protocols and encrypted communication between virtual infrastructure and cloud computing centers. Also provides support for IPSec tunneling similar to site to site VPN to ensure single LAN connectivity between environments.
  - Their solutions are mainly catered towards making clouds and virtual environment interoperable.
  - The centralized IDS can be ensured by routing all traffic to on-prem via the IPSec tunnel and use existing gateway solutions to monitor threats and attacks.

• Cisco ASA: Cisco’s ASA series of routers are designed to provide point to point VPN access to individual compute instances in the cloud. Taking the scenario of a VPC deployment, establishing centralized security in this case implies setting up VPN tunnels to the corporate network of the org from AWS and this has to be done on a per instance basis.

While products such as above provide capabilities like VPN/IPSec and single notion of the network topology across clouds, we do not see capabilities provided for a centralized IDS/IPS solution within AWS cloud analogous to the on-premise solutions like VMWare. 

In order to determine the feasibility of the solution in AWS VPC, a prototype was developed with a VPC containing two subnets. Further details are discussed below.

Prototype Setup

A centralized NIDS solution must have all traffic run through it to ensure efficient enforcements of policies and detecting attacks and malicious traffic. Within the AWS infrastructure, a VPC with the following configuration was deployed.

The configuration can easily be deployed using the standard VPC starup wizard in AWS. 

In this design a VPC configuration with 1 public and 1 private subnet is deployed. The public subnet has a compute instance with an associated elastic IP which serves as a 'router' for the rest of the internal deployments. 

The internet gateway as such today is fairly limited in its functionality and does not have an capabilities that are required to support an IDS/IPS system.

The route table is modified to ensure that the private subnet cannot talk to the outside world without going through the public subnet. In essence the Snort instance acts as a NAT for rest of the network inside the VPC thus making this the ideal place to deploy NIDS capabilities.

The instances in the private subnet have lighttpd installed on them with a test page deployed on port 80. For this prototype we assume the following:

• Analyze only port 80 traffic i.e. HTTP traffic
• Only one web server is set up in the private subnet with lighttpd. 

IPTables Configuration

AWS NAT instance supports the outbound connections from the private subnets to the internet via the Internet Gateway (IGW). Out of the box, it does not allow inbound connections from the outside world into the private subnet. In order to have the NAT instance monitor all traffic we would need to convert the NAT capabilities to support both inbound and outbound connections. 

For this prototype we have the following two scenarios from the NAT instance:

• Inbound
  The end user should be able to make a HTTP request to the EIP of the NAT instance. The NAT instance should automatically route it to the web server and establish a session with the response from the server being routed back to the user. 
• Outbound
  The private subnet running the web server instance should be able to access the internet through the NAT as before without being redirected or blocked. 

In order to support this we need to make changes to the iptable rules. 

Default Setting

Once the VPC is setup, the NAT instance will have the following iptable configuration supporting the NAT behavior. 

$> sudo service iptables status
.....
.....
.....
Chain OUTPUT (policy ACCEPT)

num  target     prot opt source               destination


Chain POSTROUTING (policy ACCEPT)

num  target     prot opt source               destination

1    MASQUERADE  all  --  10.0.0.0/16          0.0.0.0/0

Inbound connection forwarding

We add another rule to this configuration to support inbound connections to be routed to the web server that is deployed in the private subnet. (IP: 10.0.1.113:80)

$> sudo iptables -t nat -A PREROUTING -p tcp \! -s 10.0.0.0/16  --dport 80 -j DNAT --to-destination 10.0.1.113:80

[ec2-user@ip-10-0-0-58 ~]$ sudo service iptables status

Table: filter

Chain INPUT (policy ACCEPT)

num  target     prot opt source               destination


Chain FORWARD (policy ACCEPT)

num  target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)

num  target     prot opt source               destination


Table: nat

Chain PREROUTING (policy ACCEPT)

num  target     prot opt source               destination

1    DNAT       tcp  -- !10.0.0.0/16          0.0.0.0/0            tcp dpt:80 to :10.0.1.113:80


Chain OUTPUT (policy ACCEPT)

num  target     prot opt source               destination


Chain POSTROUTING (policy ACCEPT)

num  target     prot opt source               destination

1    MASQUERADE  all  --  10.0.0.0/16          0.0.0.0/0

Result

With this set up, we would now be able to deploy an IDS/IPS at the NAT instance to tap into all traffic coming in and out of the VPC. Next steps would be to deploy Snort on this instance and configure it to behave like a simple IDS system. 

Some of the questions that come up as a result of this research are as follows:

• How do cloud infrastructure service consumers utilize resources in AWS or other similar clouds to deploy their multi-tier applications? Is there a need for centralized network IDS/IPS solutions today?
• How is this trend going to change in the coming years? Is the lack of a centralized network security solution forming a hurdle today for customers to migrate from virtual infrastructure solutions to the cloud?
• Today we can implement a network IDS/IPS solution by enforcing a VPN tunnel to the VPC in AWS cloud ensuring all traffic is monitored by the corporate network via the VPN. This would enable organizations to set up IDS/IPS monitoring solutions in the traditional way in front of their internet gateway. Does this model scale well in today? Would this scale in environments where large workloads would be moved to the cloud tomorrow? 

この記事の各資料には、Symantec Endpoint Protection 12 において、必ず確認した方がよい設定や、よく使われる設定がまとめられています。使用環境や運用方法に応じて定義ファイルを何日分保持したらよいのか、通信の設定や定時スキャンの設定などについて詳しく解説しています。

『SEP マネージャ構築時の注意事項 1 マネージャの HDD 容量の見積もり方法』
SEPM の HDD を消費するのは、SEPM のプログラムと日々ダウンロードし、蓄積するウイルス定義ファイルです。SEPM に保存するウイルス定義ファイルの保存世代数は、SEP クライアントへ配信する差分ファイルと関連します。これらの点を踏まえて、SEPM の HDD の容量の見積もり方法について解説します。

『SEP マネージャ構築時の注意事項 2 ネットワーク負荷を軽減させる方法』
SEPM と SEP クライアントの間で最も大きなトラフィックは、ウイルス定義ファイルです。ウイルス定義ファイルの配信によるネットワーク負荷を軽減する考慮点について解説します。

『SEP マネージャ構築時の注意事項 3 アンチウイルスポリシー設定方法』
SEP のセキュリティポリシーは、インストール時に自動で設定されたものが推奨ポリシーとなっています。導入する会社の規模や組織により、適用するセキュリティポリシーを変更する必要がある場合があります。セキュリティポリシーの作成、変更に関する考慮点について解説します。

『SEP マネージャ構築時の注意事項 4 アプリやファイルをスキャンから除外する方法』
SEP では、特定のファイルやフォルダ、アプリケーションをウイルススキャンの対象から除外することができます。誤検知を防ぐ設定方法について解説します。

* 「セキュリティ」コミュニティの記事のリストページで、投稿者メニューからプルダウンして［日本 SE チーム］を選ぶと、すべての記事が一覧表示されます。

Hello Everyone

Today we will see how to use Symantec Offline Image Scanner tool (SOIS).

Hello Everyone,

Today we will see how to use Sylinkdrop tool.

This tool is effective to replace Sylink.xml file on single machine, it can not be used to replace on multiple machines in one go. To replace on multiple machines will hvae to use Sylink replacer tool.

To learn more about Sylink replacer tool check this article:

https://www-secure.symantec.com/connect/downloads/sylinkreplacer-tool-connecting-sep-clients-sepm

Before that it's important to know what is Sylink.xml.

Sylink.xml stores the global communication settings. This file is for internal use only and should not be edited. It contains settings from the Symantec Endpoint Protection Manager. If you edit this file, most settings will be overwritten by the settings from the management server the next time the client connects to the management server.

Sylink file is an XML file containing communication settings and following  files :-

A list of SEPM servers to connect to

The public SEPM certificate for all servers.

The KCS, or encryption key.

The DomainID that the client belongs to.

PUSH/Pull connection setting

Various log settings

If the clients have lost the communication with a management server, you must replace the old Sylink.xml file with a new Sylink.xml file. The SylinkDrop tool automatically replaces the Sylink.xml file on the client computer with a new Sylink.xml file.

• Migrates or moves clients to a new domain or management server.

• Restores the communication breakages to the client that cannot be corrected on the management server.

• Moves a client from one server to another server that is not a replication partner.

• Moves a client from one domain to another.

• Converts an unmanaged client to a managed client.

• Converts a managed client to an unmanaged client.

1. From https://symantec.flexnetoperations.com download the archive Symantec_Endpoint_Protection_12.1_Tools_and_Documents_EN.exe

 

2. Launch the Symantec_Endpoint_Protection_12.1_Tools_and_Documents_EN.exe and give a destination path

 

You will see SylinkDrop folder.

 

This tool is also available at the following location.

 

On the computer that runs the management server, locate drive:\Program Files (x86)\Symantec\Symantec Endpoint Protection\Version.Number\Bin\SylinkDrop.exe

 

 

 

Hello Everyone,

Today we will see how we can block the clients connection to the specified group which they were assigned in the client installation package.

We can set up client installation packages with their group membership If you define a group in the package, the client automatically is added to the appropriate group. The client is added the first time it makes a connection to the management server.

We can turn on blocking if you do not want clients to be added automatically to a specific group when they connect to the network.

Let's see how to make it turn on.

Select the Specific group or groups, Right click on the group name, Click on Properties

At the bottom of Group Propertis you will see the option 'Block New Clients'. By default it's uncheck.

Even you can check in right pane under 'Details'

The blocking option prevents users from automatically being added to a group.

You can block a new client from being added to the group to which they were assigned in the client installation package. In this case, the client gets added to the default group. You can manually move a computer to any group.

This is helpful if you don't want clients to report to their respective group after connected to the SEPM first time.

Hello,

This is Part 2 of the "How to Series...", you can find the Part 1 here.

Here are few popular "How to..." which would be assistance to the Symantec Endpoint Protection Users.

Series 2 contains the following "How to..."

1) How to Deploy the Communication Settings to the SEP 12.1 RU2 clients.

2) How to Enable Anti-MAC spoofing

3) How to export MSI Package to deploy the SEP clients.

4) How to verify what type of database is used for SEPM ?

=========================================================================================================

1) How to ... Deploy the Communication Settings to the SEP 12.1 RU2 clients.

If the client-server communications breaks, you can quickly restore communications by replacing the Sylink.xml file on the client computer. You can replace the sylink.xml file by redeploying a client installation package. Use this method for a large number of computers, for the computers that you cannot physically access easily, or the computers that require administrative access.

Here are the steps:

1)  Login into SEPM console

2)  Go to Clients Tab

3)  Select the Group in which you would like to see the offline clients

4)  Right click on the group and click on “Add Client”

5)  Now please follow the Screenshot as mentioned below:

6)  You will get “Client Deployment Wizard”

7)  Select “ Communication Update Package Deployment” Option

8)  Click Next

9)  Select the group in which you would like to see the client

10) Leave it on “Computer mode”

11) Click Next

12) Select Remote Push

13) Click Next

14) Browse your network and add the computers to the list

15) Click Next

16) Authenticate the User

17) Click Next

18) Click Send

19) Click Finish

20) Please check the SEP client status in the SEPM, it should now show in the SEPM\Clients

Check these Articles:

Restoring client-server communications with Communication Update Package Deployment

http://www.symantec.com/docs/HOWTO81109

SEP 12.1 RU2 and Reset Client Communication

https://www-secure.symantec.com/connect/articles/sep-121-ru2-and-reset-client-communication

=========================================================================================================

2) How to... Enable Anti-MAC spoofing

1)      Login into SEPM Console.

2)      Go to “Policies”

3)      Edit the Firewall Policy

4)      Go to “Protection and Stealth”

5)      ENABLE  Anti-MAC Spoofing

1)      Microsoft SQL Database

2)      Embedded database

====================================================================================

Hello,

This article will demonstrate hot to configure liveupdate to run client updates.

Some time customers may get confuse with these settings, they may feel these settings are applicable for SEP client and SEP Manager communication but it's not true.

It's very important to go through the following note which is available at the start of the page.

Important note: Enable the scheduling of automatic downloads from liveupdate servers. The schedule settings do not control downloads from the default management server, from Group Update Providers, or from third party content management tools. Downloads from the default management server depends upon heartbeat interval and selected mode. (Push mode or Pull mode)

1) Enable Liveupdate Scheduling:

1. Click Policies and then click LiveUpdate.

2. On the LiveUpdate Settings tab, right-click the policy that you want, and then click Edit.

3. Under Windows Settings, click Schedule.

4. Check Enable LiveUpdate Scheduling.

5. Specify the frequency

You can select this option as per business requirement, By default it's set to every 4 hours.

2) Retry Window:

Set the maximum retry allowed after a failed schedule update. If the maximum time is reached before the update has run, the computer will wait for hthe next scheduled time to try again.

If you select any frequency other than Continuously, specify the Retry Window.

3) Download Randomization Option:

If you selected Continuously or Every "XX" hours then this option is grayed out by default.

Check the screen-shot.

If you selected Daily or Weekly option then you can configure download randomization options.

For Daily you set it to minimum 1 days & maximum 12 days

For Weekly you can set it to minimum 1 days & maximum 3 days

Your network might experience traffic congestion when multiple client computers attempt to download content from a LiveUpdate server. You can configure the update schedule to include a randomization window. Each client computer attempts to download content at a random time that occurs within that window

4. Idle Detection:

To ease client computer performance issues, you can configure content downloads to run when client computers are idle. This setting is on by default. Several criteria, such as user, CPU, and disc actions, are used to determine when the computer is idle.

If Idle Detection is enabled, once an update is due, the following conditions can delay the session.

After one hour, the blocking set is reduced to CPU busy, Disk I/O busy, or no network connection exists. Once the scheduled update is overdue for two hours, as long as a network connection exists, the scheduled LiveUpdate runs regardless of idle status

To configure client updates to run when client computers are idle

To configure client updates to run when client computers are idle.

1. Click Policies.

2. Under Policies, click LiveUpdate.

3. On the LiveUpdate Settings tab, right-click the policy that you want to edit, and then click Edit.

4. Under Windows Settings, click Schedule.

5. Check Delay scheduled LiveUpdate until the computer is idle. Overdue sessions will run unconditionally.

Reference: http://www.symantec.com/docs/HOWTO55289

5. Options for skipping liveupdate:

To save bandwidth, Symantec Endpoint Protection clients can be configured to only run scheduled LiveUpdates from the Symantec LiveUpdate server if one of the following conditions is met

• Virus and spyware definitions on a client computer are more than two days old. Maximum duration can be 31 days.

• A client computer is disconnected from Symantec Endpoint Protection Manager for more than eight hours.  Maximum hours can be 24 hours

Following KB's can be helpful as well:

Configuring the LiveUpdate download schedule for client computers

http://www.symantec.com/docs/HOWTO55287

Randomizing content downloads from a LiveUpdate server

http://www.symantec.com/docs/HOWTO55174

Configuring the LiveUpdate download schedule for client computers

http://www.symantec.com/docs/HOWTO55287

Configuring client updates to run when definitions are old or the computer has been disconnected

http://www.symantec.com/docs/HOWTO55293

Configuring client updates to run when client computers are idle

http://www.symantec.com/docs/HOWTO55289

Hello,

In the previous article we seen how to configure liveupdate on SEP client computers.

Here is the link for that: https://www-secure.symantec.com/connect/articles/configure-liveupdate-run-client-computers

This article will demonstarte step by step guide to configure liveupdate settings on Symantec Endpoint Protection Manager (SEPM).

You can adjust the schedule that Symantec Endpoint Protection Manager uses to download content updates from LiveUpdate to the management server. For example, you can change the default server schedule frequency from hourly to daily to save bandwidth.

To configure the schedule for LiveUpdate downloads to Symantec Endpoint Protection Manager

1. In the console, click Admin.

2. On the Admin page, click Servers.

3. Select the site, then under Tasks, click Edit Site Properties.

      4. In the Server Properties dialog box, on the LiveUpdate tab, click Edit Source Servers.

Liveupdate Source Server

By default Symnatec liveupdate server is selected. If you have configured Internal liveupdate server then need to add that server details manually. Need

to click on Add and enter the required details.

\

Following article can help to "Setting up an internal LiveUpdate server"

http://www.symantec.com/docs/HOWTO55180

For downloads from the default management server or a Group Update Provider, you configure the randomization settings in the Communication Settings dialog box for the selected group. The settings are not part of the LiveUpdate Settings policy.

The Symantec Endpoint Protection Manager supports randomization of simultaneous content downloads to your clients from the default management server or a Group Update Provider. It also supports the randomization of the content downloads from a LiveUpdate server to your clients. Randomization reduces peak network traffic and is on by default.

You can enable or disable the randomization function. The default setting is enabled. You can also configure a randomization window. The management server uses the randomization window to stagger the timing of the content downloads. Typically, you should not need to change the default randomization settings.

In some cases, however, you might want to increase the randomization window value. For example, you might run the Symantec Endpoint Protection client on multiple virtual machines on the same physical computer that runs the management server. The higher randomization value improves the performance of the server but delays content updates to the virtual machines.

You also might want to increase the randomization window when you have many physical client computers that connect to a single server that runs the management server. In general, the higher the client-to-server ratio, the higher you might want to set the randomization window. The higher randomization value decreases the peak load on the server but delays content updates to the client computers.

In a scenario where you have very few clients and want rapid content delivery, you can set the randomization window to a lower value. The lower randomization value increases the peak load on the server but provides faster content delivery to the clients.

Reference: http://www.symantec.com/docs/HOWTO55173

Hello All,

It is sometime necessary to list all the Device Ids which are added in the Application and Device Control policy.

This is not possible with the default SEPM reports.

Here are the steps to export all the manually added Device IDs:

1. Open Application and Device control policy

2) Right Click on the policy and select export

3) The file will be exported with .dat extension. Save the file

4) Rename the file as .zip file

5) Once renamed we need to extract the file using winzip. Right click on the .Zip file and extract it

6) Once the file is extracted you will find a single file named Main.xml. All the information are stored in this .XML file. Lets open this

 file in excel.

7) Open Excel

      a. Click on File -Click on Open

      b. Select the Main.xml saved in Step 6

8) Excel will prompt "How would you like to open this file". Select the first option "As an XML Table"

9) Click Ok for the message

10) Now do a search for DeviceClassGuid.

11) Device IDs will be way down the column so , lets Sort the DeviceClassGuid Column I sorted from A-Z

12) These are the Device IDs - 

Hope this was helpful.

Hello,

This is Part 3 of the "How to Series...", you can find the Part 1 here and Part 2 here.

Here are few popular "How to..." which would be assistance to the Symantec Endpoint Protection Users.

Series 3 contains the following "How to..."

1) How to create a GUP (Group Updater Provider) in SEP 12.1 RU2

2) How to Export a log report in Symantec Endpoint Protection Manager in .csv format

3) How to disable the "Active Scan on Startup" whenever different users log into a single computer on an unmanaged client.

4) How to Export SEP Client Package in SEP 12.1

======================================================================================================

1) How to create a GUP (Group Updater Provider) in SEP 12.1 RU2

Step1. Go to the Policies of that Group where that Systems are Stored in Symantec Console.

Step2. Click on Live Update Setting Policy (Fig-1)

Step3. Live Update Policy Screen Display. Choose the Server Setting (Fig-2)

                 (Figure-2)

Step4. There three option displays

a)                  Internal & External Live Update Setting

b)                 Group Updater Provider

c)                  Third Party Management

Step5. Check on the Use of Group Updater Provider. Now Group Updater Provider is Enable. Click on it.

Step6. Group Updater Provider Box Display. Fig (3)

                 (Figure-3)

Step7. Two options are available in Group Updater Provider

a)                  Group Updater Provider Selection for Clients.

b)                 Group Update Provider Setting

Step8. In the Group Updater Provider Selection for Clients, Two options Display Single Group Updater and Multiple Group Updater.

a)   Single Group Update Provider: A single Group Update Provider is a dedicated client computer that provides content for one or more groups of clients. A single Group Update Provider can be a client computer in any group. To configure a single Group Update Provider, you specify the IP address or host name of the client computer that you want to designate as the Group Update Provider.

b)  Multiple Group Update Provider: Multiple Group Update Providers use a set of rules, or criteria, to elect themselves to serve groups of clients across subnets. To configure multiple Group Update Providers, you specify the criteria that client computers must meet to qualify as a Group Update Provider. If a client computer meets the criteria, the Symantec Endpoint Protection Manager adds the client to its list of Group Update Providers. Symantec Endpoint Protection Manager then makes the list available to all the clients in your network. Clients check the list and choose the Group Update Provider that is located in their subnet. You can also configure a single, dedicated Group Update Provider to distribute content to clients when the local Group Update Provider is not available.

c) 

Step9. Choose Single Group Update Provider / Multiple Group Update Providers as per required and Update the Hostname/IP of Group Updater System.

Step10. Click Ok.

Notes- 1000 systems can be updated with Single GUP.

Think about: running the DLP Solution for about one year, and find out that there are no more tablespace of the DLP Oracle to store the new incidents.

Then, you need to expand the tablespace, or, add new data file to the tablespace. Install and use the Enterprise Manager (EM) is the best choice.

On the other hand, by using EM, the administrator can monitor the usage and performance of the Oracle, and check the error message.

Here are the steps to install and use EM:

1. From Start menu, choose 'Oracle - OraDb11g_home' --> 'Configuration Assistant for Windows' --> 'Database Configuration Assistant':

2. Click Next:

3. Select 'Configure Database Options':

4. Select 'Protect' and click Next:

5. Select 'Configure Enterprise Manager' and click Next:

6. Keep default, and click Next:

7. Select 'Use the Same Administrative Password for All Accounts', and input the password for sys:

8. Select 'Dedicated Server Mode' and click Next:

9. Click OK to start the configuration:

10. The configuration running:

11. After the configuration, there will be a 'Database Control - protect' link added to the Oracle manu:

12. After click to run the 'Database Control - protect', the browser will open the console of the EM.

Input the User Name as sys and select the Connect As SYSDBA:

13. From the EM console, the admin can monitor the performance and usage of the protect database.

The admin can also add more data files to the tablespaces.

Click 'Server' and select 'Tablespaces':

14. Select the tablespaces name and choose 'Add Datafile' from the 'Actions' list:

The EM is not installed defaultly during the configuration of protect database. So, if you want to add more data files to the tablespaces, you need to run sql query by sqlplus.

As the installation of the EM doesn't need to stop the Oracle Database, it's a good choice to configure EM for DLP.

If you want to have pre installtion check,Health checkup, recommendations and collect logs for support. Then please go through the document so that you can learn how to run a Sym help tool

There is a new feature on DLP 12.0: Content Root Enumeration. 

The Content Root Enumeration is a function about Auto-discovery of servers and shares.

Content Root Enumeration enables you to locate servers and shares within a domain and filter them by IP range or server name. Share discovery works only for CIFS-compliant file servers, including those with DFS file shares.

Content Root Enumeration scans produce a list of servers and shares that you can use directly in file system targets for Discover scanning, or export to a CSV file. A Content Root Enumeration scan does not scan the content of the servers and shares it discovers, but it enables you to find servers and shares in your domain and configure automated scanning of them.

Here are the steps to configure the Content Root Enumeration on DLP 12.0:

1. From Enforce Console, choose 'System' --> 'Settings' --> 'Directory Connections', click 'Create New Connection':

2. Fill in the nessary information to create the directory connection:

3. Select 'Manage' --> 'Discover Scanning' --> 'Content Root Enumeration':

4. From the drop-down list of 'Directory Connection', select the directory connection which added on step2:

5. Fill in the IP range that need to discover:

6. After the save the configuration, click 'Start':

7. After the scan, the file servers and share folder will be discovered:

8. Click the link to check the result:

Note:

You need to set up the DNS server on the DLP Enforce Server in order to resolve the FQDN of the file server.

And, you need a Domain User credential at least to finish the auto-discovery.

Please find knowledgebase articles available for SymantecLiveupdate Administrator (LUA) - current version available is 2.3.2.99. Articles are split in several catagories to allow you fast browsing and search for interesting topics. Both Symantec official KB resources and Symantec Connects resources included. Please look for a smiley - with it I have marked articles with specific relevance. As attachments you can find the .pdf documents of the Symantec LiveUpdate™ Administrator User's Guide.  I will be updating this "knowledgebase" as soon as any new articles regarding LUA are being published or any new version of this software is released.

About LiveUpdate Administrator (from Symantec LiveUpdate™ Administrator User's Guide)
LiveUpdate Administrator is an enterprise Web application that allows you to manage updates on multiple internal Central Update servers, called Distribution Centers. Using LiveUpdate Administrator, you download updates to the Manage Updates folder, and then send the updates to production distribution servers for Update clients to download, or to testing distribution centers, so that the updates can be tested before they are distributed to production. You can download and distribute updates on schedule, allowing you to create a low maintenance, reliable system that can be set up once, and then run automatically. Updates can also be manually downloaded and distributed as needed.

Updates are downloaded from an external site to an internal LiveUpdate Administrator server. From there, the updates can either be sent immediately to a production distribution center to be downloaded by Update clients, or sent to a testing center, so that the updates can be tested. Once the updates have passed your testing requirements, they are sent to the production center, on a schedule you determine.

Important notes about the product:

• LUA 2.3.0 and previous releases utilize versions of PostgreSQL which have reached end of life.  All customers using previous versions of LUA are advised to migrate to LUA 2.3.1 as soon as possible.
• Known Vulnerability in Symantec LiveUpdate Administrator Windows version 2.3.1 and prior -> Insecure File Permissions  Local Elevation of Privilege - Medium (http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=2012&suid=20120615_00) - Recommendation: Update to Symantec LiveUpdate Administrator Windows version 2.3.2
• LUA 2.3.2 includes a new feature for Enabling Automatic Symantec Product Catalog Updates - please check TECH201472 for reference
• In order allow LUA to provide your SEP 12.1 RU2/RU3 clients/SEPM with definitions please update your Product Catalog and select the definitions for SEP 12.1 RU2 (those definitions are being used as well by the RU3 product)
• When contacting Symantec Support for assistance regarding LUA please always collect following data:
  - Collect Luadebuginfo.zip using Troubleshoot link in the upper-right corner of the LUA interface (http://www.symantec.com/docs/TECH92654)
  - Export the LiveUpdate Administrator 2.x Server Event Log in .csv format (http://www.symantec.com/docs/HOWTO61146)
  - For LUA 2.3 and above always export the LUA server's Configuration Recovery File (http://www.symantec.com/docs/TECH159239)

SYMANTEC KB ARTICLES

VERSIONS / REQUIREMENTS:

How to obtain the latest version of Symantec LiveUpdate Administrator (LUA) 2.x
http://www.symantec.com/docs/TECH134809

What's new in LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH171578

System Requirements for LiveUpdate Administrator 2.1 (LUA 2.1)
http://www.symantec.com/docs/TECH105358

System Requirements for LiveUpdate Administrator 2.2 (LUA 2.2)
http://www.symantec.com/docs/TECH92719

System Requirements for LiveUpdate Administrator 2.3 (LUA 2.3)
http://www.symantec.com/docs/TECH173272

System Requirements for LiveUpdate Administrator 2.3.1 and 2.3.2
http://www.symantec.com/docs/TECH177544

LiveUpdate Administrator 2.3.x: Release Notes
http://www.symantec.com/docs/TECH155523

BEST PRACTICES:

Best Practices for LiveUpdate Administrator (LUA) 2.x
http://www.symantec.com/docs/TECH93409

When to use LiveUpdate Administrator?
http://www.symantec.com/docs/TECH154896

LiveUpdate Administrator 2.x and Symantec Endpoint Protection Manager on the same computer
http://www.symantec.com/docs/TECH105076

Is it Supported to Configure Unmanaged Symantec Endpoint Protection Clients to Update from LiveUpdate Administrator 2.x rather than the Symantec Endpoint Protection Manager?
http://www.symantec.com/docs/TECH123388

About Updating the Symantec Product Catalog in LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH201472

About Installing LiveUpdate Administrator 2.x on a Windows XP, Windows Vista or Windows 7 Operating System
http://www.symantec.com/docs/TECH152817

INSTALLATION / CONFIGURATION:

Installing and Configuring LiveUpdate Administrator (LUA)
http://www.symantec.com/docs/TECH102701

LiveUpdate Administrator 2.x installation walk through
http://www.symantec.com/docs/TECH102862

How to backup and restore LiveUpdate Administrator (LUA) configuration in LUA 2.3
http://www.symantec.com/docs/TECH159239

How much hard disk space is consumed by LiveUpdate Administrator 2.x for content updates?
http://www.symantec.com/docs/TECH90823

How To Determine the Corresponding Product for a LiveUpdate Administrator 2.x File
http://www.symantec.com/docs/TECH131177

LiveUpdate Administrator 2.x: What product selections are needed for specific versions of Symantec Endpoint Protection?
http://www.symantec.com/docs/TECH139618

Type of files and extensions associated with definitions in LiveUpdate Administrator 2.x with Symantec Endpoint Protection 12.1
http://www.symantec.com/docs/TECH166279

Configuring LiveUpdate Administrator (LUA) to download updates from another LUA Server
http://www.symantec.com/docs/TECH105741

Updating downloads in an internal LiveUpdate Administrator 2.x Server using the downloads from an external LiveUpdate Server
http://www.symantec.com/docs/TECH106254

How to distribute definition content from a LiveUpdate Administrator 2.x (LUA 2.x) server to an isolated network.
http://www.symantec.com/docs/HOWTO44060

How to configure a LiveUpdate Administrator 2.x Distribution Center to use the UNC protocol
http://www.symantec.com/docs/TECH106222

TROUBLESHOOTING:

How to Collect Troubleshooting Information from LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH92654

How to Export the LiveUpdate Administrator 2.x Server Event Log
http://www.symantec.com/docs/HOWTO61146

Exporting Client Settings for Windows and Java LiveUpdate Clients from the LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH97460

PERFORMANCE / TUNING:

LiveUpdate Administrator 2.2 Performance Tuning
http://www.symantec.com/docs/TECH96391

Tuning LiveUpdate Administrator 2.x's PostgreSQL Database
http://www.symantec.com/docs/TECH93476

UPDATING OTHER PRODUCTS VIA LUA:

Configuring Symantec Mail Security for Domino to Update from an internal LiveUpdate Administrator 2.x Server
http://www.symantec.com/docs/TECH202619

About updating Brightmail Antispam definitions from LiveUpdate Administrator 2.x or other local repository server
http://www.symantec.com/docs/TECH174535

Distributing virus definitions for Symantec Mail Security for Microsoft Exchange (SMSMSE) via LiveUpdate Administrator 2.x.
http://www.symantec.com/docs/TECH96018

How to use LiveUpdate Administrator 2.x with Symantec Security Information Manager 4.5, 4.6, 4.7 and SSIM Event Collectors
http://www.symantec.com/docs/TECH91326

Updating Symantec Mobile Security 7.2 Devices from an Internal LiveUpdate Administrator 2.x Server
http://www.symantec.com/docs/TECH192276

Updating Windows Mobile Devices from an Internal LiveUpdate Administrator 2.x Server
http://www.symantec.com/docs/TECH159934

SYMANTEC CONNECT

RECOMMENDED:

LiveUpdate Administrator 2.3 Vulnerability - Please Upgrade!
https://www-secure.symantec.com/connect/forums/liv...

Managing LiveUpdate Administrator 2.x Space Usage.
https://www-secure.symantec.com/connect/articles/m...

LiveUpdate Administrator 2.x Server Connection Recommendations
https://www-secure.symantec.com/connect/articles/l...

A Helpful LiveUpdate Administrator 2.x Analogy
https://www-secure.symantec.com/connect/articles/h...

LiveUpdate Administrator: Product Selection Guide
https://www-secure.symantec.com/connect/articles/l...

How Big are Current Symantec Endpoint Protection Definitions?
https://www-secure.symantec.com/connect/articles/h...

INSTALLATION / CONFIGURATION:

LiveUpdate Administrator: How to configure a remote Distribution Center
https://www-secure.symantec.com/connect/articles/l...

Installation and configuration of LUA
https://www-secure.symantec.com/connect/articles/i...

Configuring Distribution Center in LUA
https://www-secure.symantec.com/connect/articles/c...

Group Update Provider v/s Liveupdate Administrator
https://www-secure.symantec.com/connect/articles/g...

Using IIS Logs to Check LiveUpdate Administrator 2.x Health
https://www-secure.symantec.com/connect/articles/u...

Illustrated Guide to Configuring LiveUpdate Administrator 2.x for SMSMSE 6.5.5
https://www-secure.symantec.com/connect/articles/i...

SYMANTEC CONNECT VIDEOS

LiveUpdate Administrator: How to configure a remote Distribution Center
https://www-secure.symantec.com/connect/videos/liv...

Install LUA (Live Update Administrator) and Configure for Symantec Endpoint Protection
https://www-secure.symantec.com/connect/videos/ins...

LiveUpdate Administrator 2.3: What's New
https://www-secure.symantec.com/connect/videos/lua...

Symantec Data Loss Prevention comes with over 40 pre-configured reports to help customers manage their business. These reports allow customers to meet compliance requirements, assess business risk, provide oversight and manage remediation operations, and see trends across business units of the organization.

Symantec Data Loss Prevention offers the following pre-built reports, divided into Network, Endpoint Prevent, and Discover reports.

• Network reports provide summaries for the Data Loss Prevention for Network products.
• Endpoint Prevent reports provide summaries for Symantec Data Loss Prevention Endpoint Prevent.
• Discover reports provide summaries for the Data Loss Prevention for Storage products as well as for Symantec Data Loss Prevention Endpoint Discover.

Here is the list and description about all the pre-configured reports:

Content:

• Overview
• Installation & Configuration
• Troubleshooting

Overview

In an ESX environment, you can install a native Symantec Critical System Protection agent and apply policies to monitor and protect the local host. However, ESXi does not allow agent installation or local enforcement. Instead, a Symantec Critical System Protection observer system is used to monitor the ESXi host remotely by using VMware-supported APIs and command line tools such as vCLI. This observer system is referred to as the Symantec Critical System Protection Collector host and is similar to the VMware Management Assistant (VMA). VMA is a virtual machine that manages agents that interact with ESXi hosts. VMA is not used because it no longer supports the capture of forwarded ESXi Syslog events and the choice of deployment scenarios is limited.

Symantec recommends that the Symantec Critical System Protection Collector system should be a single-purpose system that is dedicated to monitor a set of ESXi servers. The Symantec Critical System Protection Collector system contains account and password information for the monitored ESXi servers, copies of ESXi server configuration files and logs, and VM guest configuration files. Therefore, you should limit login access to the Symantec Critical System Protection Collector system in the same way you limit login access to the ESXi servers or vCenter Servers. The ESXi credential store and other ESXi files are protected by operating system ACLs – only the root user has access to them. Symantec recommends you to use Symantec Critical System Protection Prevention and Detection policies for additional protection of the Collector host system, as you would with any other important server in the organization.

Symantec Critical System Protection Collector systems can be either SLES 10 (32-bit and 64-bit), SLES 11 (32-bit and 64-bit), or Red Hat 5.5 (32-bit and 64-bit). The Symantec Critical System Protection Collector system does not require many system resources, so configuring it as a virtual machine makes the most sense from a manageability standpoint.

The Symantec Critical System Protection Collector system includes the following components:

■ Base Linux Platform (SLES, RHEL)

■ VMware vCLI

■ Symantec Critical System Protection agent

■ Remote File Synchronization (RFS)

Installation & Configuration

Note: All the below steps require to be logged in as root user.

ESXi Host Configuration

ESXi Host Configuration from vSphere:

• ESXi Shell set to Start and stop with host:
  • Configuration tab > Software > Security Profile > Services > Properties > ESXi Shell > Options…
• ESXi clock synchronized:
  • Configuration tab > Software > Time Configuration > Properties
• Enable syslog forwarding (outgoing UDP port 514):
  • Configuration tab > Software > Security Profile > Firewall > Properties

ESXi Host Configuration:

• ESXi Host set with static IP:
  • Login locally > Configure Management Network > IP Configuration

Installation of the Collector Node Linux Based Platform

Preparing the Linux Based Platform

Setup a virtual machine for RHEL 5.5 or SLES 10/11.

• Disable the firewall
• Disable SELinux (RHEL)/AppArmore (SLES)
• Install VMware tool

Note: CentOS 5.5 is an alternative to RHEL. The configuration is the same as for RHEL.

Installing vCLI on Linux Systems with Internet Access

Before you can install the vCLI package on a Linux system with Internet access, that system must meet following prerequisites.

■ Internet access. You must have Internet access when you run the installer because the installer uses CPAN to install prerequisite Perl modules.

■ Development Tools and Libraries. You must install the Development Tools and Libraries for the Linux platform that you are working with before you install vCLI and prerequisite Perl modules.

■ Proxy settings. If your system is using a proxy for Internet access, you must set the http:// and ftp:// proxies, as follows:

export http_proxy=<proxy_server>:port

export ftp_proxy=<proxy_server>:port

Installing Required Prerequisite Software for Linux Systems with Internet Access

If required prerequisite software is not installed, the installer stops and requests that you install it. Installation of prerequisite software depends on the platform that you are using.

Installing Required Prerequisite Software

yum install openssl-devel libxml2-devel e2fsprogs-devel

 SLES 10, 64 bit. yast -i openssl-devel libxml2-devel-32bit e2fsprogs-devel-32bit

 SLES 10, 32 bit. yast -i openssl-devel libxml2-devel e2fsprogs-devel

SLES 11 64 bit. yast -i openssl-devel libuuid-devel libuuid-devel-32bit

SLES 11 32 bit. yast -i openssl-devel libuuid-devel

Installing the vCLI Package on a Linux System with Internet Access

Download vCLI 5.1 from VMware website.

Install the vCLI package and run a command to verify installation was successful.

To install vCLI

1. Untar the vCLI binary that you downloaded.

tar –zxvf VMware-vSphere-CLI-5.X.X-XXXXX.i386.tar.gz

A vmware-vsphere-vcli-distrib directory is created.

2. If your server uses a proxy to access the Internet, and if your http:// and ftp:// proxy were not set when you installed prerequisite software, set them now.

export http_proxy=<proxy_server>:port

export ftp_proxy=<proxy_server>:port

If your server does not use a proxy to access the Internet, set the http:// and ftp:// proxy as follows:

export http_proxy=

export ftp_proxy=

3. Run the installer from the vmware-vsphere-vcli-distrib directory itself.

./vmware-install.pl

4. To accept the license terms, type yes and press Enter.

The installer connects to CPAN and installs prerequisite software. Establishing a connection might take a long time.

5. On RHEL, when prompted to install precompiled Perl modules, type no and press Enter to use CPAN.

The installer connects to CPAN and installs prerequisite software. Establishing a connection might take a long time.

6. Specify an installation directory, or press Enter to accept the default, which is /usr/bin.

A complete installation process has the following result:

■ A success message appears.

■ The installer lists different version numbers for required modules (if any).

■ The prompt returns to the shell prompt.

If you accepted the defaults during installation, you can find the installed software in the following locations:

■ vCLI scripts – /usr/bin

■ vSphere SDK for Perl utility applications – /usr/lib/vmware-vcli/apps

■ vSphere SDK for Perl sample scripts – /usr/share/doc/vmware-vcli/samples

See the vSphere SDK for Perl documentation for a reference to all utility applications. After you install vCLI, you can test the installation by running a vCLI command or vSphere SDK for Perl utility application from the command prompt.

Installing the Critical System Protection Agent

1. Export the agent binary file and the agent-cert.ssl file (agent certificate) on the Collector Node Server,
   • For RHEL 5.5, 32-bit: agent-linux-rhel5.bin
   • For RHEL 5.5, 64-bit: agent64-linux-rhel5.bin
   • For SLES 10, 32-bit: agent-linux-sles10.bin
   • For SLES 10, 64-bit: agent64-linux-sles10.bin
   • For SLES 11, 32-bit: agent-linux-sles11.bin
   • For SLES 11, 64-bit: agent64-linux-sles11.bin
2. Change the permissions for the binary file.

chmod a+x <agent_binary_file>

3. Run the binary file to start the agent installation.

./agent64-linux-rhel5.bin

4. Follow the prompts until the installation completes.

Note: Make sure to enter the agent name during installation (see Troubleshooting for details).

5. Restart the computer if prevention was enabled.

That completes the installation of the agent.

Installing the Remote File Synchronization (RFS) Support Utility Tool

About the Symantec Critical System Protection ESXi Support Utility

Remote File Synchronization (RFS) is a support utility tool that is installed on the Collector host to help the Symantec Critical System Protection agent monitor multiple ESXi hosts. RFS periodically synchronizes ESXi host configuration files, Virtual Machine Configuration files (VMX files), and selected ESXi log files. The local agent computer with policies applied performs the file integrity and log monitoring activities.

The files that are available for monitoring are specifically exposed by the VMware APIs. Not all the files that are visible when you log into the ESXi host are available for monitoring purposes.

RFS performs the following functions:

■ Remote access to a designated ESXi host by using a VMware-encrypted credential store.

■ Discovery and transfer of changed ESXi host configuration files.

■ Discovery and transfer of changed ESXi host log files of interest to Symantec Critical System Protection ESXi detection policy.

■ Discovery and detection of VMs that are registered or de-registered from the ESXi host.

■ Discovery and transfer of changed Virtual Machine VMX configuration files for VMs that are registered with the ESXi host.

RFS is periodically executed based on a scheduled interval that is configured by the administrator. For example, the interval might be 10 minutes, 30 minutes, 2 hours and so on. After an initial one-time file population, only the files that are changed on the ESXi host are copied to the local Collector host.

Note: During the initial one-time file population, you may see a lot of File Create events in the console.

The ESXi Syslog log file is handled separately from RFS. Syslog configuration settings at the ESXi host are used to forward its Syslog to the Symantec Critical System Protection Collector node for monitoring purposes.

The Symantec Critical System Protection agent performs file integrity monitoring based on the mirrored files. Monitoring includes checking for changes in last modification date, size, name, and file content. The policy, as configured by the Symantec Critical System Protection console users, determines the event severity, rule name, and other parameters associated with FIM and log monitoring events.

Each ESXi host can be viewed as a virtual agent on the 5.2.9 console. All the events generated for a particular ESXi host will be available to be viewed for that virtual agent.

Installing and Setting up the ESXi Support Utility

The following Perl modules are prerequisites for the Symantec Critical System Protection ESXi support utility. You must ensure that these modules are present before you use the support utility:

■ Date::Parse

■ File::Copy

■ File::Path

■ File::Basename

■ Sys::Hostname

■ Text::CSV

■ Text::CSV_XS (optional)

To download a Perl module

Install cpanm to make installing other modules easier.

◆ Open a terminal window and run the following command:

cpan App::cpanminus

◆ Then run the following command for each module to install:

cpanm <Module>::<Name>

For example, cpanm Date::Parse

To install and set up ESXi utility

1. The ESXi Support utility is installed as a part of Symantec Critical System Protection 5.2.9 agent installation on a Linux operating system. The default directory for the ESXi support utility is:

/opt/Symantec/scspagent/IDS/bin/esxi_fim

2. When you install ESXi support utility for the first time, open a terminal window, and run the following command located in the default directory:

rfs_config.sh -setup

3. Specify a directory where you want to store the ESXi host files that are retrieved by the tool, or press Enter to accept the default, which is /fim/scspfim.

4. When prompted for the synchronization interval, type a valid interval between 3 to 60 minutes. It adds a cron job to the root user's crontab to run the RFS utility based on the specified synchronization interval.

Note: If you want to create a synchronization interval of more than 60 minutes, type 60 when you run the setup, and then manually edit the cron-tab entry /etc/crontab file to change the synchronization interval.

You can also run the setup silently by providing the above information in the following way:

rfs_config.sh -setup -fimpath <path for the root directory> -syncinterval <interval in minutes>

5. The ESXi support utility can now be configured to add, modify, delete, and list ESXi Hosts.

rfs_config.sh -addHost -server=<addr> -username=<user> -password=<passwd>

After you provide all the values, the setup script configures the following settings on the local system:

■ Updates the conf/esxi_fim_host.conf file by setting the ESXi_HOSTS entry to ESXi host name/IP address.

■ Creates a credential store under conf/esxi_fim_hostcred by using a vCLI command. It also populates the store with an entry for the ESXi host and the user account credentials.

■ Creates the CollectorNode_<hostname> directory under /fim/scspfim/ for the Collector Node.

■ Creates a directory named with the IP address of the monitored ESXi host under /fim/scspfim/.

■ If the Syslog mode is on:

■ Adds an entry in the etc/syslog-ng/syslog-ng.conf file to accept the forwarded syslogs from the ESXi host.

■ Configures the remote ESXi host to forward its events to the local collector by using a vCLI command.

When you install the ESXi support utility for the first time, you should apply the vSphere ESXi Detection Policy to start monitoring the ESXi Hosts. You can only apply the vSphere ESXi Detection Policy after you have run the setup.

6. Once the policy applied, run the first synchronization.

./rfs_config.sh –runrfs

About RFS OPTIONS parameters (rfs_config.sh)

-help

-version

-setup

■ -fimpath=<fimrootdir>

■ -syncinterval=<mins>

rfs_config.sh –setup -fimpath=<fimrootdir> -syncinterval=<mins>

-addHost

rfs_config.sh -addHost <Mandatory Options> [Optional Options]

■ -server=<IP address or host name>

■ -username=<user>

■ -password=<passwd>

■ -protocol=<protocol>

■ -port=<port>

■ -syslogon

■ -syslogoff

-modifyHost

rfs_config.sh -modifyHost <Mandatory Options> [Optional Options]

■ -server=<addr>

■ -username=<user>

■ -password=<passwd>

■ -protocol=<protocol>

■ -port=<port>

-deleteHost

rfs_config.sh -deleteHost <Mandatory Options>

■ -server=<addr>|all

■ -username=<user>

-listHost

-upgrade

-runrfs

Troubleshooting

Troubleshooting and verifying steps for RFS

RFS Setup

• If during the RFS Setup it fails to create the /fim/scspfim directory, create it manually and update the conf/esxi_fim_root with an entry that identifies the directory for the FIM root.
• If during the installation of the CSP Agent you do not enter its name, the Collector Node folder will be created as SCSPCollectorNode_ and will be reporting to the Management Server as such.

The only way to fix this is by reinstalling the CSP agent and enter its name during the installation process.

RFS Synchronization fails

• Review the rfs.log located in the /fim/scspfim/CollectorNode_<hostname> directory for errors.
• Check that the directory with the ESXi IP address is created under /fim/scspfim/.
• Enable Trace mode to get more details:
  • Edit esxi_fim_host.conf by changing the last 0 to 1 on the ESXHOST= line.

Uninstall RFS Utility

Uninstalling the RFS Utility requires to uninstall the Critical System Protection Agent.

1. Make sure no Prevention policy other than NULL is applied to the Agent,
2. Run rpm –e SYMCcsp,
3. Reboot the server to complete the uninstallation.

Troubleshooting and verifying steps for VMware vCLI & ESXi

Uninstall VMware vCLI

1. Go to to the directory where you installed vCLI (default is /usr/bin).
2. Run the vmware-uninstall-vSphere-CLI.pl script.

The command uninstalls vCLI and the vSphere SDK for Perl.

ESXi syslog settings

• Check that syslog forwarding is configured from vSphere > Configuration tab > Software > Advanced Settings > Syslog. You should see the following in the Syslog.global.logHost setting:

udp://<collectornode_IP_address>:514

References

VMware vCLI Download link

https://my.vmware.com/group/vmware/details?downloadGroup=VSP510-VCLI-510&productId=285

Vmware vCLI Documentation

http://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vcli.getstart.doc/cli_install.4.5.html

SCSP Agent Installation

https://www-secure.symantec.com/connect/articles/how-install-scsp-agent-windows-unix-and-solaris

SCSP vSphere Support Guide

https://www-secure.symantec.com/connect/articles/symantec-critical-system-protection-52-ru9-docs

CPAN

http://www.cpan.org/modules/

YUM (RHEL)

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/c1-yum.html

YaST (SLES)

http://www.novell.com/developer/yast.html

(Internal) Virtualization Policy.pdf