I. The Tool

Symhelp is a new version of the troubleshooting tool that replaces the legacy Symantec Support Tool.

You will find the tool on the SEP 12.1 RU2 Installation CD – the included here version is 2.1.1.74. The latest available version from Symantec at the time of this article release is 2.1.7.95. The revisions of the Symhelp tool are updated quite often (even several times a month) - if possible use the latest available from Symantec. You can download the tool either going to the following link: http://www.symantec.com/docs/TECH170752 or from the SEP Client GUI - by going into Help -> Download Support tool -> this redirects directly to the Symantec Article mentioned in the reference.

The tool is used to troubleshoot SEP Clients and SEPM Server but not only – it supports as well following Symantec programs:

Note: You can you Symhelp on SEP 12.1 RU2 installation and as well all previous versions. The old Symantec Support Tool is compatible only with all SEP 11.x version and the 12.1 versions prior to RU2 – if you try to run it on SEP 12.1 RU2 installation it will fail with the following error:

If your machine has connection to the internet every time you run the tool it will check for an update from Symantec – if such is available it will be downloaded automatically and will replace the SymHelp.exe executable. The tool will require as well the .NET installed already on the machine – for Windows 8 or Windows Server 2012 the version of .NET 3 or higher will be required. If .NET is not installed tool will prompt for this installation.

II. The Options

After accepting the EULA you will see the Home page of the SymHelp tool. From here we can select the type of Symantec Products we want the report run for and the type of the scan as well.

Main SymHelp GUI provides us with additional Support Resources:

- Search Knowledge Base - here we have a general selection for all product that will takes us to the product selection page (http://www.symantec.com/business/support/index?page=products) or we can specify a certain product at this stage.

- Browse Forums - here as well we can opt for all products that will takes us to home page of Symantec connect (https://www-secure.symantec.com/connect), or we can choose a specific product forum

- Open a Case Online - this selection takes us to the logon page of the MySymantec portal:

https://my.symantec.com/webapp/faces/login?appParam=support

- Contact Technical support - opens http://www.symantec.com/support/techsupp_contact_phone.jsp

- Contact Customer care - http://www.symantec.com/support/assistance_care.jsp

Additionally for reference there is a System Usage section that gives us information about current Memory and CPU utilisation as well as shows how much disk space is free on either local or networked drives.

Before running the tool we need to select product scan type, this can be one or more of the following:

- Health check - scan of installed products, will try to identify known issues

- Best practices - scan of the configuration in scope of the compliance with the best practices guidelines

- Pre-install check - scan of system readiness for product installations including the check of system requirements

- Full data collection for support

There are 2 more independent selections available under the"Run Threat Analysis Tools" section - this refers to tools used for identifying suspicious files and threats:

•  Symantec Power Eraser

The tool is aimed at the detection and clean-up of "zero-day" threats as well as other threats which may have infected the user’s system.

SEP Power Eraser GUI gives us following options:

- Scan for Risks - additionally available for selection is "Include a Rootkit Scan" - this will require a reboot

- History - where we can check results of previous Power Eraser sessions, you can as well recover from here files that were previously detected

- Settings - enables to selected "Include a Rootkit Scan" option and set up a network configuration.

Reference:

http://www.symantec.com/theme.jsp?themeid=spe-user-guide

•  Symantec Load Point Analysis

Load Point Analysis examines files that launch from known and specific locations on the drive and in the registry (according to the OS) in order to find out which files are likely to be not a genuine executable and possibly may pose a threat to the system. Those are then checked within the online Symantec Reputation database and given a score that may classify them as unknown files or a potential threat.

SymHelp gives us here some options for scan setting:

- Scan Load Points, Running processes and Common Directories -> this is selected by default

- Scan Program File Directories

- Scan additional files and directories

We can select this additional locations from Symantec Load Point Analysis -> Settings -> Options menu. Here we will find as well several options for Network configuration either through Automatic configuration from IE or configuration script or specified proxy server.

After the Load Point scan is finished we will be presented with final report on following:

- Amount of files the analysis was performed on

- Amount of files verified as good using their digital signature

- Amount of files verified as good using the Symantec Reputation Database

- Amount of files verified as bad using Symantec Reputation database

- Amount of files that needed additional check

* The report will show the amount of files that should be manualy verified by sending them to Symantec Security response -> here we have as well an option to copy these files to a local folder

* The files tab will as well contain the listing of files for manual verification. The Processes tab shows all running processes alongside with their reputation score and path to the file.

* Load Point Analysis will by default check for any existing autorun.inf files on the local or networked drives.

Reference:

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

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

--- Few notes and considerations to the SymHelp selection types:

* Health check and Best Practice scans can be only chosen for already installed products. If you have chosen a Symantec Product not yet installed these 2 options will be greyed-out from selection

* Pre-install check will scan the system only checking for the installation requirements in scope of SEP 12.1 Client for Local and Remote installation. The results of the scan will be then displayed in the reports section of:

- System meets the requirements for SEP 12.1: Local install

- System meets the requirements for SEP 12.1: Remote install

* If asked for Symhelp tool report by Symantec Support please run the report with option "Full data collection for support" - this will include all necessary information alongside with SEP/SEPM logs needed for investigation/troubleshooting. Providing Symantec support with only Health Check or best practices scan will give only a initial insight in the configuration but may prove not enough for the scope of troubleshooting purposes.

* When collecting the Load Point Analysis data for support, remember to check the option "Collect SEP data for Symantec Support Case" as well.

--- Saving the report:

After all the scans are completed we can save the report from the "Save" tab. There is currently no possibility to change the name of the report file - by default it will by computername_date_time.sdbz. We can however take a target directory for saving of our choosing. There is as well an option "Save and send to Symantec Support" - please note that using this option do not automatically open any case with Symantec Support. When saving the report this way please always inform the support team that the report has been sent using this option.

III. Additional switches / SymHelp from command prompt

SymHelp tool execution is possible as well directly from command prompt. There are as well several switches available for additional debugging and user visibility. These are the available symhelp.exe switches:

* SymHelp with advanced debugging:

Starting the Symhelp tool from command line with the -wizprod switch will give us some more options for setting up advanced debugging and issue reproduction during the report is being collected.

We can enable the default debug level by simply selecting Debug - Enabled - this can be executed by the command line switch as well. By choosing the Advanced Debug option from the selection tool will present a new windows with additional selection available - this will include:

- SNAC debugging

- SEP Debug

- SEP sylink debugging

- WPP logging

...after clicking "Next" the tool will inform that the debug has been enabled (in registry) and we can reproduce the issue - after that click "Next" for the debug to be turned off and report to be collected.

[Note]: the –deepdata switch used previously in the Symantec Support Tool for gathering of the advanced WPP debugging is no longer existing in the SymHelp. WPP Debug can be collected by going into symhelp.exe –wizprod and enabling that kind of debugging from the GUI.

IV. The Report

Depending on the selected scans it will take a couple or more minutes to generate the report. (Please note that for the purpose of this article I will focus mainly on the information gathered when troubleshooting SEP and SEPM installation without including several other products that can be scanned with SymHelp). After report is completed we will be given following tabs for preview:

1. Home - general information about the Scan Status and selected product information - the screen shown will be here a bit different depending on if we open the tab directly after scan was finished or if we open a previously saved report from drive. When opening a previously saved report - the option for new scan run will not be available at this point anymore - restart of the tool will be necessary to scan again.

2. Report - this section is split on 5 different tabs as follows:

- Error - "This tab displays reports that resulted in an error status. An error status indicates that an issue has been detected and requires further examination and/or action."

- Warning - "This tab displays reports that resulted in a warning status. A warning status indicates that a possible issue exists. Further action may or may not be required depending on factors that the report cannot determine."

- Missing data - "This tab displays reports that could not examine all the data needed in order to yield a report status. If one test failed to access required data this will determine the status of the report as Missing data."

- Ok - "This tab displays reports that resulted in a status of Ok. An Ok status indicates that the issue being tested for was not found and no action is required."

- All - "This tab displays all the reports for a given product regardless of status. If a specific report is known and its results sought after, it may be quicker to find the report under this tab rather than to look under each of the status specific tabs."

We can adjust the selection of product on the left side of the GUI in case several product were chosen to generate the SymHelp report and we want to see only the results applying to one specified product at this point.

The reports will contain both text and hyperlinks to Symantec KB Articles if such are available for the encountered problems. You will find more details to each report by expanding the details section.

Some of the examples for most common reports that we can find in the reports section:

• SEP Client examples:

• Symantec Endpoint Protection drivers and services need attention

Reference for solution:

Are the Symantec Endpoint Protection drivers loaded and services running?

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

• Security advisories for Symantec Endpoint Protection Client

• The latest version of Symantec Endpoint Protection Client is installed – in case of not the latest version installed the links provided will include the newer revisions than the one installed.

Reference for solution:

Obtaining the latest version of Symantec Endpoint Protection or Symantec Network Access Control

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

Release Notes for Symantec Endpoint Protection, Symantec Endpoint Protection Small Business Edition, Symantec Network Access Control 12.1

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

• Client to Manager communications are [not] working

Reference for solution:

Symantec Endpoint Protection: Troubleshooting Client/Server Connectivity

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

• Windows Firewall Configuration

Reference for solution:

Symantec Endpoint Protection clients do not communicate properly with the Symantec Endpoint Protection Manager

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

• Definitions corruption checks – report about the currently used revision, check performed for corrupted definition files and missing definition files.

• SEP 12.1 Virus Definitions are not corrupt
• SEP 12.1 BASH Definitions are not corrupt
• SEP 12.1 Submission Control Data Definitions are not corrupt
• SEP 12.1 IPS Definitions are not corrupt
• SEP 12.1 Iron Revocation Definitions are not corrupt
• SEP 12.1 Iron Settings Definitions are not corrupt
• SEP 12.1 Iron White List Definitions are not corrupt
• SEP 12.1.2000+ Extended File Attributes Verify Trust Definitions are not corrupt
• SEP 12.1.2000+ SRT SP Settings Definitions are not corrupt

Reference for solution:

Potential Symantec Endpoint Protection content definition corruption

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

• System meets the requirements for Symantec Endpoint Protection 12.1: Local install

Reference for the included links from the detailed view:

Does the computer need to be restarted?

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

Does the current user have local administrator rights?

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

Is the Windows Installer service disabled?

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

Reference for solution:

System Requirements for Symantec Endpoint Protection, Enterprise and Small Business Editions, and Network Access Control 12.1

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

• System meets the requirements for Symantec Endpoint Protection 12.1: Remote install

Reference for the included links from the detailed view:

Is the Remote Registry Service enabled?

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

Is the Server service started?

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

Are the C$, ADMIN$, and IPC$ shares available?

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

About the Find Unmanaged Computers function in Symantec Endpoint Protection Manager

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

Error: "No Network Provider accepted the given the network path"

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

Is the Microsoft Windows Firewall blocking port 445?

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

Does the computer need to be restarted?

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

Is the local security setting 'Sharing and security model for local accounts' set to Guest Only?

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

Is User Account Control enabled on the client?

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

Does the Administrator account have a password?

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

Is the Windows Installer service disabled?

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

Reference for solution:

Best practices for upgrading to Symantec Endpoint Protection 12.1.2

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

• SEPM  Server examples:

• Symantec Embedded Database service needs attention

Reference for solution:

Is the embedded database service running?

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

• The Symantec Endpoint Protection Console is [not] using its configured ports

Reference for solution:

Which Communications Ports does Symantec Endpoint Protection use?

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

• System does [not] meet the recommendations for Symantec Endpoint Protection Manager 12.1

Reference for the included links from the detailed view:

Is the local security setting 'Sharing and security model for local accounts' set to Guest Only?

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

Does the current user have local administrator rights?

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

Is User Account Control enabled on the client?

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

Is the Windows Installer service disabled?

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

Which communications ports does Symantec Endpoint Protection use?

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

Reference for solution:

System Requirements for Symantec Endpoint Protection, Enterprise and Small Business Editions, and Network Access Control 12.1

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

• The latest version of Symantec Endpoint Protection Manager is [not] installed

Reference for solution:

Obtaining the latest version of Endpoint Protection or Network Access Control

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

Release notes for Symantec Endpoint Protection 12.1.x

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

• Symantec Endpoint Protection Manager drivers and services are [not] running

Reference for solution:

Are the Symantec Endpoint Protection drivers loaded and services running?

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

• Security advisories for Symantec Endpoint Protection

Reference for solution:

Depending on the advisories found

• The Symantec Endpoint Protection Manager communications tests have all passed

Reference for solution to:

Symantec Endpoint Protection: Troubleshooting Client/Server Connectivity

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

• There is no client install package configuration issue detected

3. SPE (SEP Power Eraser) - if the SPE scan was previously run

4. LPA - Load Point Analysis - in case this scan was run previously

5. Information - the information section will present us with the following data:

* General:

a) Summary - general information about the system, we will find here general information about the date and time of log collection, timezon, user and domain, physical memory on the machine, CPU model, IPv4 and IPv6 configuration as well as local drives informations

b) Customer - Customer information as provided when saving the report. This section included the issue description - this is as well provided on the tab for report save

c) Installed Symantec Products

* SEP Client specific information:

a) SEP Client Summary:

- Version of the SEP client

- Type of the SEP Software (Enterprise/Small Business)

- Install date of SEP software

- Servers according to sylink.xml - provides of full listing the SEPM servers available for the SEP client

b) Policy:

- Client Group as per policy

- Location

- Location awareness -> if enabled =1, if disabled =0

- Client Control mode -> Server (1) for Server control mode; Server (0) for Client Control Mode

- Policy Serial Number

c) Communications:

- Last heartbeat

- Heartbeat result

- Connection status to SEPM

- Last attempted connection

- Last successful connection

d) Exceptions -> listing of configured centralized and user exceptions

e) File Versions -> contains information about version of some of the SEP file systems like Symevent, Auto-Protect User Mode Interface or Liveupdate.

f) Definitions -> lists installed definitions with revision date information. Following definitions will be covered:

Virus Definitions 12.1.x -> SRTSP      

Proactive Threat Protection -> BASH

Intrusion Prevention -> Internet Security

Insight -> ccSubSDK_SCD

Insight -> IronRevocation

Insight -> IronSettings

Insight -> IronWhitelist

Extended File Attributes -> SymEFA

SRT SP Settings     -> SRTSPSettings

g) Features -> listing of installed/enabled features alongside with MSI Feature name and install state:

• example:

Application and Device Control                         DCMain                  Installed

Firewall Protection                                               Firewall                  Installed

Intrusion Protection                                             ITPMain                 Installed

Network Threat Protection                                  NTPMain                Installed

Notes Scanner                                                       NotesSnapin          Installed

Outlook Scanner                                                   OutlookSnapin     Installed

Pop3/SMTP Scanner                                            Pop3Smtp              NotInstalled

Proactive Theat Protection Truscan                      PTPMain                Installed

Sonar Protection                                                   TruScan                  Installed

Virus and Spyware Protection                            SAVMain                Installed

Download Insight                                                                                 Installed

* SEPM Manager specific information:

a) SEPM Summary will give us information about used SEPM Version.

b) Database configurations - information about the DB type, host and username

c) Ports - list of ports used by SEPM communications, alongside with port current state:

6. Best practices - according to the Best Practices scan type - report splits on following tabs:

- Not recommended -"This tab displays reports that resulted in a Not Recommended status. A Not Recommended indicates that the system's configuration is counter to best practice standards and will likely have consequences that should be considered."

- Not compliant - "This tab displays reports that resulted in a Not Compliant status. A Not Compliant status indicates that the system's configuration is not according to best practice and might potentially have unwanted consequences. This status is less severe than a status of Not Recommended."

- Missing data - "This tab displays reports that could not examine all the data needed in order to yield a report status. If one test failed to access required data this will determine the status of the report as Missing data."

- Compliant - "This tab displays reports that resulted in a status of Compliant. A Compliant status indicates that the system is configured according to best practice standards."

- All - "This tab displays all the reports for a given product regardless of status. If a specific report is known and its results sought after, it may be quicker to find the report under this tab rather than to look under each of the status specific tabs."

Some of the common examples we can find in the best practices section:

V. References:

1. Symantec Support Tool:

• About the Load Point Analysis feature in the Symantec Endpoint Protection Support Tool

Article: TECH96291           http://www.symantec.com/docs/TECH96291

• The Symantec Endpoint Protection Support Tool

Article: TECH105414        http://www.symantec.com/docs/TECH105414

• About the Symantec Endpoint Protection Support Tool

Article: TECH91280           http://www.symantec.com/docs/TECH91280

• How to run the Symantec Endpoint Protection Support Tool remotely

Article: HOWTO72599     http://www.symantec.com/docs/HOWTO72599

• https://www-secure.symantec.com/connect/articles/u...

2. SymHelp Tool:

• About Symantec Help (SymHelp)

Article: TECH170735        http://www.symantec.com/docs/TECH170735

• Symantec Help (SymHelp)

Article: TECH170752        http://www.symantec.com/docs/TECH170752

• What command-line parameters are available for use with Symantec Help (SymHelp)?

Article: TECH170732        http://www.symantec.com/docs/TECH170732

• Load Point Analysis and Symantec Power Eraser are not available in SymHelp

Article: TECH201415        http://www.symantec.com/docs/TECH201415

• Unable to launch or view SymHelp

Article: HOWTO75989     http://www.symantec.com/docs/HOWTO75989

I have come across lot of customers who have Symantec Network Access Control License but they are not using it. It is part of the Symantec Protection Suite 3 or 4 that you might have.

The simple reason could be either they find it complicated to configure or do not understand how it can fit to their organizational goals or simply they are not aware of Self-Enforcement, i.e. SNAC HI policy enforcement without any Hardware or DHCP plug-in enforcer.

So here I would like to present an example where you can block Clients with Older Definition unless they are either updated through other sources or manually attended.

At today’s date protecting your endpoints with only Signature based protection is not enough, On top of that if the Virus Definitions are Outdated/ Old then it defeats the purpose of using Antivirus on your endpoints.

Many organizations view Virus Definition Compliance as major security concern however they do not understand how to tackle with these machines/Assets having older definitions.

So here is how SNAC can help you tackle this problem.

The best part is this requires no Hardware enforcers or DHCP software plug-in to be configured.

Pre-requisites:

1.       Make sure your SEPM is SNAC ready that is you see Host Integrity Policy option in Policies Tab if not you can add SNAC.xml file to the License folder in SEPM.

2.       You should have Network Threat Protection installed on the clients.

3.       Even though we normally do have Servers and Desktops in different groups, still would confirm if they are in different groups as you will not like your Servers getting Quarantined due to Old Definitions and interrupting your business operations.

4.       You understand that by blocking the clients you will be interrupting their day to day work, so you have your management by your side to justify the cause.

5.       Most importantly you understand how critical it is to have machines with updated definitions and while blocking clients with older definitions you not set the bar very high. For example if you have 20% clients with older than 3 days of definitions then you should keep the number of days on higher side to start with and then as Compliance improves you reduce the number of days.

Now to the simple part of Configuring the Policy:

1.       Edit Host Integrity Policy and under Requirement Click Add and Select “Antivirus Requirement”

2.       Give it any name that suits the policy requirement, then Start Antivirus if not running on the client is optional but you can still enable it and give the command to start the Service.

3.       Under Antivirus Signature File checking, make sure you select the right number of days, also make sure it is days and not definition revision. Additionally you can give an option from a location from where the definition can be downloaded it can be any location. Click OK and you are done with configuring the requirement.

4.       Now Under Advance Settings, It is highly recommended to set Notification for each type of Notifications selected, just so that the users are well aware what is happening on their machine and why. They should panic that their machines have been hacked.

5.       Now Assign the Host Integrity Policy on all the groups on which you want this policy to be activated. To start with it should be a pilot batch of few clients and then probably after gaining confidence you can increase the number of groups.

6.       Go to Policy Tab, Firewall Policy and create a new Firewall Policy, name it Quarantine or SNAC or any other name which can be related to policy.

7.       Select All the Default rules and Delete them.

8.       Click Add Rule, Name it Allow Basic then Click Next Select Allow Connection click Next till you reach Network Services then Add DNS,DHCP, LDAP, FTP and/or your Email application and ports.

Note: You can build your allow list which can include applications like cmd.exe or your business application (under Applications), or any specific port or additional service or if you want few machines which these clients should be allowed to connect like your Ticketing System etc.

9.       Below this rule add another Rule to Block All communications. NOTE: Do not assign this policy on Any group

10.       After assigning the policy, under the Clients Tab select the group in which you have applied the SNAC HI policy and go the Policies tab on the Top.

11.       Under Quarantine Policies when Host Integrity Fails click on Add Policy

12.       Select Quarantine Firewall Policy, Click Next Select Existing Shared policy and select the policy created above. Then do the same for other groups in which you want this policy to be applied.

13.       Now once the client is blocked the user will either call helpdesk or will manually update the definitions, once the definition is updated the HI Status will change to Approved and the client will run normally with existing normal policies.

14.       Other than blocking the Client machines using Firewall you can also put a Quarantine Liveupdate Policy with which you can guide the client machine to directly connect to internet or LUA (if you already have one) or Directly connect to SEPM bypassing GUP.

15.       Most importantly you can also view logs and reports of the machines where HI Compliance failed.

The Story So Far....

This is the fourth in an informal series of articles intended to help admins make the best use of Symantec AntiVirus for Linux (SAV for Linux, or SAVFL), keeping those boxes protected from today's many emerging threats without killing the CPU or the network bandwidth.

• SAV for Linux Scanning Best Practices: A (Somewhat) Illustrated Guide covers the importance of auto-protect scanning, necessary scan exclusions and how to test them
• SAV for Linux: A (Somewhat) Illustrated Guide Part 2 provides examples of the various different ways in which SAVFL can be configured (by command line, by GRC.DAT and by xsymcfg).
• SAV for Linux: A (Somewhat) Illustrated Guide Part 3 focused on how to keep SAV for Linux up-to-date.

By popular demand, this new installment will focus on how to get some data and events from those isolated, unmanaged SAVFL clients into the Symantec AV's central management and reporting tool, the Symantec Endpoint Protection Manager (SEPM).  This is possible through an optional tool called SAVFL Reporter.

A Reporter?  Like Clark Kent?

SAVFL Reporter is an optional component that can forward certain system events and data to another computer, so that the information from the Linux machine will be displayed in the SEPM's reports.  It's not anything to do with a newspaper reporter.

(If you wish to press for an analogy even weirder than when I compared LiveUpdate Administrator 2.x to a refrigerator, then think of SAVFL as Peter Parker rather than a Clark Kent.... )

So: SAVFL with SAVFL Reporter is not the same as a managed SEP for Linux client.

Installing SAVFL and SAVFL Reporter will not cause the Linux machines to be displayed on the SEPM's clients tab.  They will not be able to roll out policies to the Linux clients from the SEPM or install the SAVFL client to unmanaged Linux boxes remotely.  All those limitations are by design: SAVFL was originally written to be a stand-alone, unmanaged program. Peter Parker (to pay one last visit to our analogy) is really just a kid under that superhero suit.  In due course he will grow and mature.  Please vote on the following proposed enhancement request to express your support for that day.

Managed SEP client for Linux
https://www-secure.symantec.com/connect/ideas/managed-sep-client-linux

OK, Close the Comic Books.  What Data does SAVFL Reporter Document?

The following data will be forwarded to the Symantec Endpoint Protection Manager:

• Inventory (Computer Status) logs, which include Parent Server Name, Server Group Name, Client Name, Client Group, Product Version, ScanEngine Version, Last Check-in Time, User Name, Virus Definition Date, Virus Definition Sequence, Virus Definition Revision, Virus Definition Version, IsInfected, IP Address, Running Status, AutoProtect On/Off, TimeZone.
• Scan logs, which are generated by SAV for Linux as logging events.
• Virus (Risk) logs, which are generated by SAV for Linux as logging events.

Here's an example of how this Linux machine info appears in the SEPM's logs:

Using various filters, it is possible to generate a list of all the Linux machines that are configured to report in to this SEPM, view their definitions date (as illustrated, above), see when they have been scanned, what threats were found, and so on. 

It's also possible to configure notifications which can be triggered by the incoming SAVFL Reporter data.  So if there's an outbreak on your Linux file server, the admin's smartphone can get a "Alert!!" email from the SEPM, enabling her to grab her cape, spring into action and save the day. 

Here's a configuration of a Single Risk Event that will act upon events from a SAVFL client.....

Enough Comic Book References, OK?

Sorry about that.  I like superheroes.

Here's an example "Single Risk Event" that I generated. Note that it's letting me know about an infected file quarantined on an Ubuntu machine,

Looks Good.  I'm Not Seeing Anything Here, Though.

SAVFL Reporter is not automatically installed when SAVFL is installed.  It's a separate, optional tool on the install CD/ .iso.

How to get SAVFL Reporter Working?

Make sure that your SAVFL version is MR10 or above, and that you have Perl in place on the Linux machine.  Then just follow the documents to install and configure it on each Linux box.  Here's the official details:  

Symantec AntiVirus for Linux (SAVFL) Reporter 1.0.10 Release Notes
Article URL http://www.symantec.com/docs/DOC3474 
 

Once installed, configure the SEPM details, frequency, and so forth in the /etc/reporterd.ini configuration file.

One important point: the SEPM needs to be configured to accept these legacy logs.  This only needs to be done once:

How to enable the 12.1 Symantec Endpoint Protection Manager (SEPM) to receive logging from legacy clients.
Article URL http://www.symantec.com/docs/TECH157463 
 

Also see:

Symantec Antivirus for Linux (SAVFL) with SAVFL Reporter is not able to upload the logs to the Symantec Endpoint Protection Manager (SEPM).
Article URL http://www.symantec.com/docs/TECH164020 
 

Run a few eicar test files on the Linux box, once you have it set up!  A search of your SEPM's Risk report should show the detection, a few minutes later.  Quickly reacting to attempted infections on your non-Windows servers can soon make you the hero of your corporate IT department.

Final Notes

Many thanks for reading!  Please do add comments and feedback below.

Hello,

The Symantec Power Eraser is aimed at the detection and clean-up of "zero-day" threats as well as other threats which may have infected the user’s system. Zero-day threats are those that take advantage of a newly discovered hole in a program or operating system before the developers have made a fix available – or before they are even aware that a hole exists.

NOTE: It is recommended to have an Internet connection when using SymHelp and Symantec Power Eraser. This would assist in downloading the Latest Version of SymHelp and Latest Power Eraser Definitions when running Symantec Power Eraser. Incase, there is no Interent connection, Power Eraser would use the default definitions which are available with the SymHelp Tool.

To Remove a Threat Using Symantec Power Eraser

To Undo a Change Threat Using Symantec Power Eraser

Symantec News and Discussions

Symantec Security Response Blog Feed

View below or link to full Security Response blog.

Malware and the State of the Internet

Whenever a company Implements  SSIM or a similar product , the security department deploys it on a large number of Servers,devices and databases and monitor them for a while .Meanwhile  the IT team launches their upgrade projects and start replacing or upgrading  the monitored devices to latest versions .Sometimes they involve the security department in the process and sometimes it doesn't happen .Mostly these activities are done during weekends and it is possible that your configuration on monitored device is lost during the upgrade and you may or may not  get alert that a certain device is not sending logs .So if you miss that alert , you never know the Problem until one day you wants to check for a specific day logs and you don’t find it .When check around ,you find that the Server was upgraded a month ago and the log collection is not working since then .The objective of this article is to alarm you whenever a certain device stops sending the Logs  .

In order to know when a particular device stops sending Alerts ,you can use System State Monitor .In order to configure this ,

Go to Rules | Monitors | System Monitors | System State Monitor

Define the threshold as per your company’s policy .

Define priority and Severity ID .

Under Action ,update the Description .

Assign it to a User Or configure an Email Alert for a certain Team

And they will get an email like this . Once email is received ,the operator can check the status .The same will also be saved as an Alert on SSIM Incidents Tab  so if your staff missed the email ,they should still see the daily Alerts and handle them accordingly .

In Part 2 , we will discuss an Alternate way of monitoring in case if you are under staffed  and  and need a quick way to Know that your Key Assets are Logging or not .

In Part-1 we discussed the use of System State Monitor .Now we will look at another Option which will provide you a quick feedback whenever one of your Critical Server stops sending Logs . For this article ,we will take example of Active Directory .In order to track all of your Windows 2008 Servers and esp. the Domain Controllers , here is what you do .

From System | Product Configuration ,go to Microsoft Windows Vista (R) Event Collector and create a new Configuration .(This article assumes that you know how to configure sensor settings for a Windows 2008 Server .If not ,you need to look up some other relevant forum posts )

Add the Windows Servers one by one .It is preferrable to use one SSIM Agent and collect events remotely from all of your Servers .If you have a large number of Serves than you can divide the load between SSIM Agents .

The Sensor Name on the right side shows under SSIM field Collector Sensor .DC stands for Domain Controller and FS stands for file Server .

Now we need to make a query .

Go to Events | My Queries | Run Query Wizard

Click Next .

Pick a number based on how many Servers you are covering .If you have a large number of Servers say 100 plus than it is better to create this rule for Critical Servers only  Or Top 20 Servers .

Click Next and click on Preview .Also give it a Proper name .If you use the option of Show legend ,it will provide you the Server name and Count of events sent by it in last 30 minutes .

Click on next to finish this . Now open this Query on your Dashboard and configure the Dashboard to  Auto refresh after every 30 minutes .Every 30 minutes ,this chart will be refreshed and you will immediately know if one of your Critical Servers disappears from the list .

Based on personal experience ,file Servers and Domain controllers are very noisy and send a large number of events so if any of them stops sending the logs ,you can easily find out by looking at the chart .

This article will discuss how to combine SEP and DLP data within IT Analytics by leveraging Microsoft Report Builder to create and publish a SQL Server Reporting Services report. For the purposes of this exercise, we will utilize some of the out-of-the-box functions in Report Builder to link data from multiple cubes into one report.

Report Builder is a component of SQL Server Reporting Services that allows ad-hoc reporting functionality, enabling end users to build their own reports and charts. Users can then publish these reports into Reporting Services where they can be accessed, viewed and incorporated back into IT Analytics alongside existing reporting.

NOTE: To complete this exercise, you should have IT Analytics already installed and configured, with both the Symantec Endpoint Protection and Data Loss Prevention Content Packs. Also, note that while the output produced by Report Builder is integrated with IT Analytics, the tools and subsequent query language behind it are separate Microsoft entities and are thereby outside the default capabilities of the IT Analytics product itself.

Creating a Matrix Report 

1. Within the Symantec Management Platform console, navigate to: Settings > Notification Server > IT Analytics, then click on Reports in the left menu tree.
2.  Click the Report Builder tab and then the Launch Report Builder button. 

3. Allow a few minutes for the application to load. Note that depending on which version of SQL Server you have, you may have a different version of Report Builder. This example covers Report Builder 3.0, which comes standard with SQL Server 2008 SP2 or higher. Note that while SQL Server 2005 meets the minimum prerequisites for installation of IT Analytics, it will only include Report Builder 1.0. If possible, Symantec strongly recommends using SQL Server 2008 SP2 or higher to take advantage of new features included in Report Builder 3.0 for a more robust custom report authoring experience. 

4. From the Getting Started screen, select Table or Matrix Wizard to create a new report.

5. In the next step you will be prompted to choose a dataset. Make sure the Create a dataset radio button is selected and click Next.

6. The next step will prompt you to choose a connection to a data source. A data source is the repository where the data for the report is stored. In the case of IT Analytics, the data is stored in the Microsoft Analysis Services Database specified when IT Analytics was installed. To create a new data source, click the Browse button.

7. Navigate to the ReportServer/IT Analytics folder on the server that houses SQL Reporting Services. Within that folder there will be a data source called ITAnalytics. Select this as the data source for the report and click Open.

8. Verify that the data source you just browsed to is displayed on the next screen of the wizard.

9. Ensure the connection to the data source is valid by clicking the Test Connection button in the lower right of the wizard. You should see a popup message that says the test succeeded.
10. Click Next and you will be prompted to design a query, which will make up the data set for the report. 

11. Click the  button toward the top of the window and select the DLP Agent Status cube.

12. Expand Measures and Agents, then drag the Incidents Count into the main query window.

13. Expand the DLP Agent attribute and drag Agent – Name and Agent - Version into the query window. Then expand the DLP Agent Last Connection Date attribute and drag DLP Agent Last Connection Date – Date into the window.

14. Click Next to complete the creation of the data set.
15. The next step will prompt you to arrange the fields to display properly in the table. Drag Incidents_Count to the Values window and drag Agent___Name, Agent___Version and DLP_Agent_Last_Connection_Date___Date to the Row Groups window. When completed, click Next.

16. The next step will prompt you to choose the layout of the report. Uncheck the Show subtotals and grand totals box and click Next.

17. The next step will prompt you to select a style for the report. Choose a color scheme you prefer and click Finish.

18. You should see a sample table on the report canvas. The data source and data set that display on the left navigation have already been created for you via the wizard. Rename the title of the report to DLP Incidents and SEP Alerts by Version.

19. Resize the font of the title so that it fits within the given area. Also, widen the columns of the table so that you can read the column headers. You can do this in the same way you would with Excel, simply click on the line between the columns, and when a grey bar appears at the top of the table, then expand by dragging the columns.

20. Expand the Datasets folder and right-click on DataSet1 which was created automatically by the wizard (this displays in the Report Data pane on the far left) and then click on Dataset Properties.
21. Rename the dataset as “DLPIncidents” which will help to differentiate it from the new data set we will create next to pull in the SEP Data. Also notice the query for the dataset which has been written entirely in the background by going through the wizard. Click OK to close the dataset properties window.

22. We will now create a new dataset to pull in SEP data. Right-click on Datasets in the Report Data pane and select Add Dataset.

23. In the Dataset Properties window, name the dataset “SEPVersion” and select to Use a dataset embedded in my report, then select ITAnalytics in the Data source dropdown.

24. Click the Query Designer button and the query designer window will appear. Change the cube to create a query on by clicking the  button toward the top of the window and select the SEP Clients cube.

25. Expand the Measures group and then the Client folder. Drag Client Count to the main window.

26. Expand the Computer attribute and drag the Computer – Computer Name field into the query window. Then expand the Virus Definition attribute and drag the Virus Definition - Version field into the window. Finally, expand the Last Checkin Date attribute and drag the Last Checkin Date – Date field into the window.

27. Click OK to close the Query Designer window and click OK again to close the Dataset Properties window. You should see both datasets listed in the Report Date pane.

28. Place your cursor over the right edge of the report canvas and stretch the width of the white area out to about 8 inches.
29. We now need to create two additional columns in our table to display the virus definition version and last checkin date for each computer. To add a column, right-click the grey column header that appears when you click into the DLP Agent Last Connection Date field, then select: Insert Column > Inside Group - Right.

30. Click into the new column header and type “Virus Definition Version” then add another column to the right and label that one SEP Client Last Checkin Date.

31. Right-click on the data cell below Virus Definition Version header and select Expression. 

32. Report Builder has several pre-defined functions built into it that can be leveraged to form an expression and extend report functionality. This works much the same way functions work in Excel, where users need to understand the format of specific functions and the arguments expected to be able to use them accordingly. For this example, we will utilize the Lookup function to tie data from the two datasets together. In the Category column, expand Common Functions and click Miscellaneous, then in the Item column that appears select Lookup.

33. Notice the description and example provided on the right hand side for the Lookup function. To tie the datasets together we need a common identifier that resides in both sets. In this example, “Agent - Name” (from the DLP Agents cube) and “Computer – Computer Name” (from the SEP Clients cube) will be used to signify the 1-to-1 relationship. Once that is established we can then add in the virus definition version for each computer to display in the report. To set the expression value for the Lookup function, type the following into the field above:

34. You should see an abbreviated place holder in that cell within the table, which represents the expression.

35. We now need to add the next column for SEP client last checkin date. To do so, repeat steps 32 – 34 above. For the lookup expression value, we will match on computer name as we did in the previous column, and this time we will pull the Virus Definition – Version field. Once the expression window looks consistent with the string and screenshot below, click OK to close the expression window:

=Lookup(Fields!Agent___Name.Value,Fields!Computer___Computer_Name.Value,Fields!Last_Checkin_Date___Date.Value, "SEPVersion")

36. Before we run the report, we need to remove grouping that gets added by default to the matrix. If the grouping section does not already appear at the bottom of Report Builder, click the View tab and check the Grouping box.

37. In the Row Groups section at the bottom, click on the downward facing triangle next to the DLP Agent Last Connection - Date field and select Delete Group, then opt to Delete group only. Do the same for Agent - Version.

38. Finally, select all data cells (not headers) except for Agent Name and apply no color to them.

39. We are now ready to preview the report and ensure the data has been tied together correctly. To preview the report, click the Run button at the top left.

40. You should see virus definition version and SEP client last checkin date populated alongside the DLP data. Note that for computers where SEP information is missing, this reveals they do not have a SEP agent installed.

Adding a Measure and Linking the Report to the Console

1. Select the Design button to go back to the Design view.

2. Save this report in the IT Analytics folder and name it DLP Incidents and SEP Alerts by Version.
3. We now need to add in SEP alert information, which resides in a different cube. Similarly to the previous topic, we will have to create another dataset for the alert information and add it to the matrix report. Repeat Steps 23 – 27 above to create another dataset called SEPAlerts. Use the SEP Alerts cube and drag in Alerts as the measure and Computer – Computer Name as the dimension.

4. Click on the Incidents Count column header, then right-click on the grey bar that appears above and add a column to the right. Name that new column Alerts Count.
5. Right-click on the data cell below the Alerts Count header and select Expression.
6. We will once again use the Lookup function to tie the datasets together. For the common identifier use “Agent - Name” (from the DLP Agents cube) and “Computer – Computer Name” (from the SEP Alerts cube). To set the expression value for the Lookup function, type the following into the field above:

=Lookup(Fields!Agent___Name.Value,Fields!Computer___Computer_Name.Value,Fields!Alerts.Value, "SEPAlerts")

7. Click the Run button again to view the report with live data.
8. Verify that Alerts Count now displays with data. Note that some computers/agents may not have triggered SEP alerts, and therefore don’t display data.

9. Go back into Design mode and click the Save button to finalize the report.
10. To link this report into the Symantec Management Platform console open the console then navigate to the Reports > IT Analytics > Reports folder.
11. Right-click on the Reports folder and select New > IT Analytics Report.

12. In the Report Type dropdown box, select Report and then in the Report Name dropdown select the DLP Incidents and SEP Alerts by Version report. Then click the Add Report button.

13. You should see a message saying that the report was added successfully.
14. Refresh your browser and expand the Reports folder.
15. Locate and select the report you just added and verify it displays as expected.

The directory C:\ProgramData\Symantec\Symantec should average between 1GB-2GB in size depending on the SEP client version 11 or 12.1, where the older version of SEP client consumes larger disk space.

• There are some known issues in SEP11 where the client sometimes overuse the disk space of the machine, it is recommended to upgrade those machines to version 12.1 to solve those issues.
• Please note that C:\ProgramData\Symantec\ might hold directories for other Symantec software, and this analysis was done for SEP client directory only (Version 12.1.671.4971).

A typical C:\ProgramData\Symantec\Symantec Endpoint Protection should contain the following folders:

This directory usually holds the folders for the current and previous versions of SEP, it is safe to delete old directories of old versions after confirming the current running version through SEP Client by following these steps:

SEP Client Main Screen -> Click on Help -> Click on About -> Check the version from the screen.

Clicking on the “CurrentVersion” shortcut will directly take you to the current version files, where that directory will hold the following:

The two folders inbox and SRTSP should not consume much space and they should not be deleted, however, must of the disk space problems comes from the folder “Data”.

A typical “Data” folder should reflect the following:

“Data” Folder Detailed Directory Analysis

1. APTemp - This directory should be clean be default.
2. BadPatts - This directory should be clean be default.
3. BASH - average file size should be around ~6.10MB. It is advised to not delete the contents inside the folder.
4. Cached Installs - the size of this file varies from machine to machine, deleting the contents of this file will only replace them again with the same contents. it is not advised to delete anything from this file according to Symantec tech support.
   Reference: http://www.symantec.com/connect/forums/sep-cached-installs
5. CmnClnt - This folder is reported to seize high capacity as it is responsible to check the reputation of the files with Symantec servers. Folders inside this directory usually sends the files to Symantec for checking if the machine has no access to the internet then this folder will increase in size rapidly. A solution to this problem could be found here: http://www.symantec.com/connect/forums/folder-12xxxdatacmnclntccsubsdk-has-large-size
6. Config - a vital file that should not be deleted.
7. ContentCache - This directory should be clean if there are no active processes in SEP.
8. DB - There is no information available in Symantec knowledge base regarding this folder. However, database files by common technological sense should not be deleted as the client operationally relies on it.
9. DecTemp - This folder should be clean by default. incase this file holds large files, then the machine should be restarted into safe mode to delete all files under DecTemp/i2_ldvp.tmp/
   Reference: http://www.symantec.com/business/support/index?page=content&id=TECH97520
10. Definitions - This folder should be 2GB in size for SEP 11 or around 900MBs for SEP 12+.
    Reference: http://www.symantec.com/business/support/index?page=content&id=TECH141811
11. FeatureState - This directory should be clean be default.
12. I2_LDVP.VDB - This directory should be clean be default.
13. Install - this folder usually holds the install logs. In my machine this folder is ~5MB in size. It is not recommended to delete this folder contents for future troubleshooting purposes.
14. IPS - This folder should not be consuming lots of space. SEP will replace this folder if deleted. It is not recommended to delete this file.
15. IPSFFPlgn - It is not recommended to delete this folder’s contents. Average size ~400KB.
16. IRON - folder for the IRON definition DB, this folder should not be tampered with.
17. Logs - This folder will increase in time depending on its age this file varies in size, technically it is not recommended to delete this folder.
18. Lue - this folder should not consume much space. ~1MB max.
19. Quarantine - AV quarantine directory. this folder should be cleaned up automatically depending on the Antivirus and and AntiSpyware policy.
    Reference: http://www.symantec.com/business/support/index?page=content&id=TECH106443
20. SPManifests - This folder is important for remote client installation through SEPM.
21. SRTSP - It is not recommended to delete the contents of this folder as it might impact the operation of SEP client.
22. State - Important for the communication between SEP client and SEPM. Should not be deleted.
23. SymDS - Should be empty by default if there are no operations in process.
24. symnetdrv - This folder holds important files, should not be deleted. Avg size 16-80Kb.
25. xfer, xfer_tmp - should be empty by default. there are reports with problems in SEP11, where the folder will increase in size rapidly. in that case the only solution to the problem is to completely re-install SEP.
    Reference: http://www.symantec.com/connect/forums/tmp-files-issue-xfer-folder

Finally, I would like to extend my appreciation and gratitude to Mr. Shahzad Subhan and Bank Albilad ISMC Team for their guidance and aid while writing this brief analysis.

Disclaimer:  Follow these steps at your own risk.  This lot worked for me, I can't guarantee the same for you (or even that it won't break your SEPM), but hopefully it will help someone out 

Background: What is on offer by default

SEP12.1 includes, by default, a self-sgned certificate for use with client communications.  This is enough for most circumstances and customer, as using it will encrypt the client communications correctly.  The below article describes how to use this inbuilt self-signed cert:

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

However, some customers mandate the use of certificates signed by 3rd party CAs.  In this case, follow the below steps to create and use such a certificate.

These steps assume you have already followed the parts of the article to enable sslForClients.conf and have a MSL ready to tell clients to communicate over HTTPS (which will be able to use the "Verify Certificate..." option after the certificate swap is complete).

Step 1: Creating a Certificate Signing Request

In order to create a signed cerrt, we first need the CSR to submit to the 3rd party CA.

This is done by opening a command prompt and navigating to the directory: "%\ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\bin" and entering the command below:

openssl req -config ..\conf\ssl\openssl.cnf -new -out newcertificate.csr -key ..\conf\ssl\server.key

On running this command, you will be prompted for the usual certificate details (Common Name, Organisation Name, blah, blah blah )

This results in a CSR file called "newcertificate.csr" in the "%ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\bin" directory.  This command uses SEP's inbuilt private key for the generation of this request.

Step 2: 3rd Party CA Signing

Hand this "newcertificate.csr" to your 3rd Party CA, who should come back to you with a signed certificate.  The resultant certificate file should end with the ".crt" file extension.

Step 3: Making SEPM use the new certificate

This is generally quite easy and is just the renaming of a couple of files.  Copy the brand new certificate into the "%ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\conf\ssl" directory.  Locate the old self-signed certificate server.crt and rename it to "server.crt.backup" (or whatever you like) and rename the new certificate to "server.crt".

Restart the SEPM Webserver Service (and by extension the SEPM service too) and you're away!

Notes:

Step 1 - While it is possible to create a new private key as well during this stage, I found it easier to use the existing one because it does not require a password, and I've not found an easy way to supply a password for starting Apache/OpenSSL/SEPM WebServer Service (the builtin method is meant to prompt, but doesn't in my testing).

Step 2 - If you have an internal CA, I'd recommend testing out the CSR so you know everything is entered correctly.

Step 3 - The reason we are renaming the certificate files is because the client comms aren't the only parts using the cert.  Access to the Reporting component of the SEPM (https://<SEPM>:8445/reporting/index.php) is also protected with this certificate, so it's easier all round to change a couple of file names than messing with the .conf files.  If you'd prefer to change entries within the .conf files, then you need to look for the below files:

• ssl.conf (used to manage the Reporting part of the SEPM)
• sslforclients.conf (used for the client communications)

And find the below entries within these files:

• SSLCertificateFile "conf/ssl/server.crt"
• SSLCertificateKeyFile conf/ssl.server.key

And change these to use the new certificate file(s); or even just update one of the .conf files to use the new certificate if you want.

Rolling back - If you encounter any issues, it's just a matter of changing the file names or (file changes) back around to use the original self-signed cert.

Addendum: Using an Existing Certificate

Some of you may already have a trusted and signed 3rd party certificate that you want to reuse for SEP.  If so, you can use the below steps to split a .pfx file into the two files required by the SEPM (.crt and .key).  Obviously, if using an existing cert, it's up to you to make sure the address in the MSL matches the name on the cert.

Step 1: Generating the Certificate files

First up, open a command prompt and navigate to the directory: "%\ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\bin", then enter the two separate commands below:

Just replace <path> with the directory where your .pfx file resides and where you want the new files to be saved.

On hitting <ENTER> after each command, you should be asked to provide the password protecting the .pfx file.

Step 2: Making SEPM use the new certificate and key

Now that we have the certificate files in the correct format, we just need to get the SEPM to use them.  This step is very similar to "Step 3: Making SEPM use the new certificate" above, but as we have a new private key (the output.key file) we have to changes the filenames of both files involved.

Copy the output.crt and output.key certificate files into the "%ProgramFiles%\Symantec\Symantec Endpoint Protection Manager\apache\conf\ssl" directory.  Locate the old self-signed certificate server.crt and rename it to "server.crt.backup" (or whatever you like) and rename output.crt to "server.crt", then do the same to server.key (i.e. rename to server.key.backup and rename output.key to server.key).

Restart the SEPM WebServer Service to get it to take effect.

De-Militarized Zone or the DMZ is the portion of the network which has two main specifications:

1-      Contains servers and services which are accessible from outside of the network.

2-      Any access to these servers and transaction with them should be thoroughly secured, risk free and logged and monitored best.

Hence usually the most restricted and toughest security policies are applied on this zone due to the criticality level of what the DMZ contains and how it is accessed. However the term DMZ most of the time brings the idea of “Gateway designing” and how to plan and manage the firewall and other security systems on the DNZ Gateway. Although the gateway is highly important, however the endpoint protection systems on the servers are as much important as the gateway security is, and in case of attack or intrusion, the endpoint protection system can role as a very strong defensive line. In this article we will see how to configure the Symantec Endpoint Protection to protect the servers in DMZ best.

In order to configure the “DMZ Protection Policy”, first of all you should have a very specified and distinct group and policy for the DMZ zone and usual policies are never enough.

Take into consideration the following hints for each section of policies and note that same as all you have in your network, security policies should be managed and surveyed on regular basis too, while “security is a trend, not a destination”

Antivirus

There are two important parts about the Antivirus policies:

1-      Scanning

You should have two very different planned scanning policies.

First is the regular scan which should be wisely planned. Even if the data of the server is not changing very often, as in webserver, you still should create tough regular Full Scan. The reason is that if by any chance the hacker or the malware successfully had infiltrated into the server and spawned a Trojan or infected the server, the risk should be eliminated AS SOON AS POSSIBLE. And hence, create a daily Full Scan on midnight or any time out of the peak time, so that you can be sure that any infection will not be carried to the next day. In addition to a daily scan, you’d better add a “Quick Scan” every 4 hours and when new definition is downloaded in order to check certain folders and locations.

The second part of scanning is the Auto Protect. Note that benefiting from “File Cache”, you shouldn’t be worried about making the auto protect tough. The file cache technology helps the SEP Clients avoids checking the files which haven’t been changed since the last scan. Therefore even if you apply the toughest auto protect policies, the unchanged files will not be engaged with the policy.

In the auto protection policy, turn on the “File cache” and the “Risk tracer”. Risk tracer will log the source of the attack or the malware origination point so that if any security risk occurs, you may be able to trace the risk and have the log for remediating or blocking the attacker host. Then for the “Startup and Shutdown” instead of “Symantec Endpoint Protection Starts” put the option on “Computer Start”, so that SEP Client will start prior to all the services and startup applications and if the system is infected by an auto-start malware or service, then Symantec will be ready before all. Note that killing some running applications or services can be a very severe task which in some cases you have to boot the windows in safe mode.

2-      SONAR

The SONAR system is the artificial intelligence of the Symantec endpoint protection system. If by any reason the antivirus is unable to detect the malware or the threat as a previously known one, the next step of checking process will be the SONAR. SONAR examines the suspicious file using intelligent Heuristic scan (Dynamic, Static and Insight) to ensure it cannot be a risk in future.

More than simply enabling the SONAR for the DMZ group, you’d better enable the “DNS Change detection” and “Host file change detection” as well. Modifying the DNS or the Host file are very simple methods that a hacker uses to monitor the server transactions or infiltrate in it. By changing the IP address of the DNS server or the Host File of the server, the name resolving query of the server will be misled and forwarded to the hacker’s computer. Then for example instead of the IP address of the google.com website, the hacker will reply its own server IP address, or at least the hacker will obtain the list of accessed URLs. But since we rarely change the DNS or the Host File configuration of the DMZ servers, it is a good idea to block these alteration.

The next configuration which will increase the servers’ security, is to adjust the “Detecting Commercial Application” in the “TruScan legacy Client Settings”. This option will define which action should the SONAR take if it detects a known commercial key logger or remote control application. Now a days hackers have access to many cracked versions of commercial applications, furthermore you know the applications running on the server specifically such risky software. Therefore you’d better set this feature as block and instead, in case of need add an exception rule for your known key logger or remote control application.

Firewall

It is very important to wisely configure the Firewall of the endpoint protection system installed on the DMZ servers. Since this firewall is functioning locally on the server (and not on the gateway), you are able to create drilled down firewall rules which spending a short while for each, will significantly improve your servers hardening.

Below are some consideration about the Symantec endpoint protection Firewall for the DMZ zone:

1-      DMZ Rules

Same as what we configure on the gateway security systems, we should have dedicated rules for the endpoint protection systems on the servers. In order to create such a firewall policy for example for a webserver, you should first allow only HTTP protocol and block the rest of traffic, and of course enable the logging system. After a while, you will consider the list of ports, protocols and services you should allow and block the rest, in order to make it function securely.

2-      The Blue Line

The blue line in the middle of the rules of a firewall policy defines that rules above the line will proceed the below ones. Benefitting from this simple feature, you’d better put the DMZ firewall rules all above the blue line so that you will always be sure that no rule will be merged with them.

3-      Additional security features

The traffic and process’ of the servers in the DMZ zone are not same as the other servers in the network. Therefore it is necessary to inspect the network traffic flow to and from these servers more sensitively. Hence, enable the below features in the Protection and Stealth setting:

a.       Enable Port Scan Detection: So if the hacker tries to capture the open ports, Symantec will detect and block the attempt. Compromising the list of open ports is usually of the first steps of attacks.

b.      Enable denial of service detection: Although this is not a very intelligent feature and in order to block such an attack you need a complex security system, however this feature will block any unknown signature and pattern to block DOS attempts.

c.       Enable anti-MAC spoofing: to block MAC-Spoofing or ARP Poisoning attack, using this feature Symantec blocks any unrequested ARP Reply which by default are accepted by the system. This is a defensive system against MITM (Man in the middle)

Notification

Although many of the administrators know the difference the Reports and Notifications, but in configuration they mostly concentrate on reporting rather than the notification.

One of the most effective items in the notification section, is the “Risk outbreak”. This feature will monitor the security events on the server, and if the number exceeds a certain level, it triggers an action which can be an email to the administrator and even executing a script. For instance if the number of infected files found in an hour on the SQL server passes over 200, Symantec sends an email to the administrator or executes a script. Hence you will be always be informed if your server is at risk.

This was an example for Notifications. There are many other notification conditions which by setting them wisely, you will be immediately noticed on any event or incident.

Farzad Ghafourian

March 15, 2013

1 Introduction

Smartphones have been widely adopted by organisations for day to day business and operational use, and employees can often access their work related data by connecting to corporate networks using their Smartphones. Many organisations have corporate policies for acceptable usage of computer equipment, which are now being extended to the use of Smartphones, for example the mandatory usage of antivirus software to prevent data loss or corruption. This article first highlights some differences between traditional computer and Smartphone operating systems (OS) and considers various security features provided by Smartphone OS. The article then calls into question the effectiveness of Smartphone antivirus software by presenting an effective malware attack as a practical proof of concept.

2 Comparison of Smartphone and Traditional Computer OS

The architecture of Smartphone operating systems like Google Android and Apple iOS are different to the traditional computer OS. Some characteristics and flaws are discussed in the following sections.

2.1 Traditional Computer OS

The security architecture of a traditional computer operating system has a number of rings. For example, the x86 architecture has four rings [1]; ring 0 is used for kernel, ring 1 is used for device drivers, ring 2 is used for System services and APIs and ring 3 is used for user applications. However, some major operating systems including Microsoft Windows [2] and Linux only implement two rings. Ring 0 is used for kernel and device drivers whereas ring 3 is used for user applications. The potential risk of such an implementation is that, if a malicious application manages to compromise a device driver, it could also compromise the kernel and in turn the whole OS. This leads to the serious situation whereby a rogue application might get root or kernel access [3]. Another potential weakness is that an OS may not isolate applications based on users. This is illustrated in Figure 1 in which the task manager shows applications sharing common usernames 'User1' and 'SYSTEM'. There may be security risks if all user applications have the same rights as that of the logged in user and if applications can share each other’s resources.

Figure 1 Windows Task Manager shows applications sharing 'User Name'

2.2 Smartphone OS

Smartphone operating systems, such as Android and iOS, implement a kind of ring (or layered) architecture. For example, Figure 2 shows the Android structure [4].

Figure 2 Android Architecture

The basic principle is that user applications run in the application layer and only Android OS services should get system level access and be able to run as ‘root’. This is true for normal non “jail-broken” phones. A jail-broken phone is a phone that bypasses limitations imposed by the OS so that users can install custom applications and even get root access. Clearly the practical feasibility of jail-breaking Smartphones and then misusing privileges is a major security concern and a related experiment is described in section 4.

Typically a Smartphone records the permitted access to system resources when the application is installed by the user. A unique user identifier (ID) is created for every application at the time of installation. The OS maintains the details of the access rights for every user ID [5]. The username for an installed application can be different for the same application on different phones. The OS should not allow access to resources unless the user has granted permission. Android and iOS implement process isolation whereby each application runs in its own sandbox so that an application should not be able to access resources of other applications [6]. If an application is compromised, the damage should then be limited to the application and the resources it has access to. However, if the rogue application is somehow given root access then the potential for damage is great.

3 Comparison of Computer Antivirus with Smartphone Antivirus Software

If a company is concerned about IT security risks then its security policy may mandate the use of computer antivirus software to protect against threats such as a virus, Trojan, malware, malicious code, root kits, intrusion and web content. Enterprise antivirus solutions provide additional features including system lock-down, application and device control, application white listing and blacklisting, host integrity and network access control. Smartphone antivirus products typically support antivirus, web content filtering, anti-theft, parental control and call/text blocking.

The architecture of a traditional computer operating system allows an antivirus application to gain kernel or root access. Figure 3 shows that Symantec antivirus, ‘Smc.exe’ is running as ‘SYSTEM’. The user ‘SYSTEM’ is used by the OS.

Figure 3 Symantec Antivirus (Smc.exe) Running as 'SYSTEM'

However, a very important difference for Smartphone antivirus is that it does not have root or kernel access. In fact an antivirus on a Smartphone is just like any other user application. Figure 4 illustrates that Symantec Mobile security is running on an Android phone as user ‘app_39’.

Figure 4 Symantec Mobile Security Running as user 'app_39'

4 Proof of Concept Exploit Against Smartphone Security

An experiment was carried out in order to assess the practicality of bypassing Smartphone control of security privileges and also the security products which are meant to provide protection. The first stage of the process was to jailbreak the phone by using CyanogenMod. The phone in question was a HTC G1 Android phone, but other phones including iPhones could have been targeted with a similar type of approach. The processes for jail-breaking are described on the Internet [7] and when successfully executed provide unrestricted application download and root access to the OS. There is a terminal for direct access or the privileges can be granted to user applications. Whilst the development of a jail-breaking strategy/utility requires expertise, to use the utility is relatively simple. A user just needs to follow a sequence of steps, and importantly this is no longer considered as an illegal activity.

A proof of concept malware ‘safebot’ [8] was loaded onto the phone. The malware actually deleted SMS messages soon after reception by the phone, without them ever reaching the application layer or alerting the user to any activity. Smartphone antivirus products i.e. Norton Mobile security and McAfee Mobile Security were loaded in turn to try and address this problem. Unfortunately neither product could detect the presence or operation of the malware. This means that an attacker could potentially introduce a rogue layer (root kit) in the security architecture which can effectively eavesdrop, modify, delete and generate data between the connecting layers. The reason for this can be seen in Figure 5; the malware is running with 'root' access whereas the antivirus is running at the application layer.

Figure 5 Proof of Concept 'Safebot' Malware Running as 'Root' on a rooted Android phone.

5 Conclusions and Suggestions

From a security perspective it is clear that traditional computer platforms are far from perfect, however their problems are reasonably well understood and there are third party products such as antivirus software that can help add protection. Our investigations have shown that commonly used Smartphone platforms have significant differences to traditional computers and cannot be compromised easily. Evidence from experiment shows that malware may be installed with root access on 'jail-broken' smartphones and yet remain invisible to commercial anti virus products that are restricted to the application layer. Malware that has root privilege has access to all the system resources and can potentially exfiltrate data such as files, contacts, browsing history, web form data and other user sensitive information without the users consent. It is the ability for applications to get root access that is the main concern and security policy should certainly forbid use of jail-broken Smartphones for corporate use. Organizations should consider using tools like 'Mobile Device Management' and 'Network Access Control' for smartphones.

Author: Vikas Rajole (vikas.rajole@gmail.com) M.Sc. Information Security from Royal Holloway, University of London.

Co-authors: Dr. Keith Mayes (Keith.mayes@rhul.ac.uk) Director, Smart Card Center, Royal Holloway University of London.

http://www.scc.rhul.ac.uk/people.php

and

Kostantinos Markantonakis (K.Markantonakis@rhul.ac.uk) Professor at Royal Holloway, University of London.

http://www.isg.rhul.ac.uk/~kostasm/

References:

[1] X86 Ring Architecture http://en.wikipedia.org/wiki/Ring_(computer_security)

[2] Windows Architecture http://technet.microsoft.com/en-us/library/cc76812...

[3] White Paper: Symantec Security Response – Windows Rootkit Overview http://www.symantec.com/avcenter/reference/windows... Page 5

[4] Android Architecture http://developer.android.com/guide/basics/what-is-...

[5] Android Application Sandbox http://source.android.com/tech/security/index.html

[6] Whitepaper by Symantec – “A Window Into Mobile Device Security”, http://www.symantec.com/content/en/us/about/media/...

[7] YouTube video link on "How To Root T-Mobile G1 with Android 1.6"

http://www.youtube.com/watch?v=u8F7FVISb7w

http://www.youtube.com/watch?v=H00kN2K2Q_8

[8] Georgia Weidman's website that provides the download link for "Proof of Concept" safebot malware, http://www.grmn00bs.com/2011/07/11/more-Android-sm...

This article describes how Symantec Endpoint Protection Small Business Edition can consume a large amount of hard drive space in a Windows operating system partition and details one method for recovering that space.  As with any procedure that is “home-grown,” I recommend that you test this on a purpose-built (i.e., non-production) server before you implement it.

When you install Symantec Endpoint Protection Small Business Edition, the product places a huge demand for space on the operating system partition.  In some cases, even with adequate planning, the cumulative effects of a growing database, its corresponding back-ups, not to mention the intra-day and mid-month signature files, can take up between 8 and 20 GB of space.

The Symantec Endpoint Protection Small Business Edition Implementation Guide states:

Symantec recommends that you back up the database at least weekly. You should store the backup file on another computer.

The backup file is saved in the following folder, by default: Drive:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\backup.

The backups are placed in a .zip file. By default, the backup database file is named date_timestamp.zip, the date on which the backup occurs.

Note: Avoid saving the backup file in the product installation directory. Otherwise, the backup file is removed when the product is uninstalled.

If you want to follow this advice, you are going to have to manually back-up your database, wait for the task to complete, and then manually copy the resulting file (several gigabytes of data) either to another computer or another external drive.

For server administrators or technicians who use StorageCraft’s ShadowProtect to back-up their Windows Servers, one of the cautions that StorageCraft issues is to make sure you are not backing up back-up files.  In this case, their concern is noted – and, according to Symantec, it appears to be unavoidable.

And that bothered me.  After all, if Symantec says that the back-up should be placed on another computer – and that it should not remain in the Program Files folder – then why don’t they offer a mechanism for specifying the output folder when the back-up is begun?  That request has been posed, and not answered, for several versions of the product.

I decided that I would try something different to help a client’s server whose primary partition was going to run short on space if something wasn’t done soon.  In this case, I was going to permanently move the Symantec database back-up file to another drive.

To do this, I utilized the built-in functionality of the Windows NTFS system and created a symbolic link to the database back-up folder and physically moved the contents to another drive.

First, I stopped the two key Symantec services:

• Symantec Endpoint Protection Manager
• Symantec Endpoint Protection Manager Web Server

Next, I opened up a command prompt, and running as Administrator, issued the following command (all on one line in the command prompt, but split here for readability):

robocopy
"C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\backup"
"F:\Symantec\SEPM_DB\Backup" /copyall /mir /xj /dcopy:T

This command created a new folder on the F:\ drive – one that is not backed up by ShadowProtect – based on the original folder on the C:\ drive.  All of the contents were copied, including the folder date/time stamps.

Then, I issued the following command:

mklink /j
"C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\backup"
"F:\Symantec\SEPM_DB\Backup"

This created the symbolic link between the C:\ drive folder and the F:\ drive folder

Then I issued the final command:

rmdir /s /q
"C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\backup"

This cleared out the contents and deleted the original directory.

I then closed the command prompt.

Finally, I restarted the Symantec Endpoint Protection Manager service, which automatically started the Symantec Endpoint Protection Manager Web Server

To test this new folder construct, I ran a back-up of the database by clicking the Start menu, selecting All Programs > Symantec Endpoint Protection Manager > Symantec Endpoint Protection Manager Tools > Database Back Up and Restore.

After the back-up was complete, I opened Windows Explorer and navigated to the C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\backup folder.  When I clicked in the address bar, I saw that the reference was F:\Symantec\SEPM_DB\Backup.

So, after less than half an hour, I managed to save my client more than 4 GB of space on their operating system partition.  I now have peace of mind knowing that the database is on a drive that I can manage and back-up as needed, and that it is not taking up unnecessary space in the daily system backups.

How to Troubleshoot in scenarios where the Bindview schedules fail.

Scope:

This technical article is applicable to the following items which are scheduled:

- Queries in RMS (Windows, Unix, Oracle, SQL, Exchange)

- Tasklists in RMS (Windows, Unix, Oracle, SQL, Exchange)

Significance:

In the data collection tool for Control Compliance Suite – also popularly known by its legacy name – BindView RMS, the users can schedule queries and task lists (group of queries and/or baseline queries). Upon completion, the user can then have the reports exported to various locations or mailboxes of the intended recipients.

However, the notification feature – where the recipients and the administrator of the scheduled queries are notified in case of events when the schedules fail is not  present. 

At the later point in time, after finding that the schedules have failed to run, most of the Windows queries can be run back in time. However, most of the database and Unix servers and files queries cannot be ran back in time.

This is way it is important to review the status of the scheduled queries or task list items on a daily basis. By doing this, the administrator can re-run the missing schedule reports on the same day or when desired.

Process:

Location of the logs for scheduled queries or tasklists:

The logs for the RMS schedules (queries and tasklists) are in text format. The logs can be found at the following location on the machine where the BindView Information Server BVIS is installed.

By default the logs are located on C: drive at the location:

\Program Files (x86)\Symantec\RMS\data\<User Name>\ScheduleLogs

Or at the location given above on the drive on which the RMS directory resides.

Note that the name of each log file corresponds to the name of the schedule in RMS.

For instance the schedule job name – there will be a corresponding log file. At any given point in time, there will be only one log file for one RMS schedule for its latest run.

Technical details:

This log file will be created at the time the windows schedule finishes.

The way RMS schedules work is as follows:

After a user creates schedules from task list or query items or baselines, the schedules are visible in the RMS console “Schedules” folder. These schedules in turn point to the task list or query items or baselines which are selected at the time when the RMS schedule is created. For the date and time part of the schedule where the creator of the schedule specifies the date and time when the schedule should actually run, BindView leverages the Windows Scheduler.

You will notice that for each schedule which is seen in the RMS console, there is a windows schedule job which is present in the windows scheduler. You can see this by going to the BindView Information server under Control Panel, go to Schedule Tasks. This will open the Task Scheduler window. You will notice the BindView jobs inside the Task scheduler Library. You will also be able to see the status of the jobs, the time when the job last ran, the next run time of the job and whether it was a one time only schedule.

These log files are automatically overwritten by the new log files after the respective schedule re-runs.

At the schedule logs location\Program Files (x86)\Symantec\RMS\data\<User Name>\ScheduleLogs

You will see that at any given point in time, one schedule in RMS has a corresponding one schedule log file from its latest run.

As soon as the schedule starts its next run for any particular job, its corresponding existing file is replaced by a new, latest schedule log file.

A typical schedule log file for a schedule which fails to run may have any of the following error messages:

Error Message 1:

Export Grid: Excel 97-2003 export to Exchange mailbox - Failed.

Unable to decrypt password. Reason Error 0x80090005 during CE::SetEncryptionKey call to ::CryptImportKey!.  This error can occur if the BindView Information Server machine's default (unnamed) machine-wide RSA keyring has been changed since you last saved (encrypted) your export credential, or if you have moved your 'BV' database over from a different BVIS machine.  You must re-enter your export credential using User Manager.

OR

Error Message 2:

Export Grid: MS SQL Server export to ADO Data Provider; Table name=ContactsReportwithemail - Failed.

Failed to logon user (User_Name) because either the user does not exist or the password is incorrect.

OR

Error Message 3:

Export Grid: Excel 97-2003 export to Disk file; Export filename=<location> - Failed.

Error in Exporting: Unable to export to (<Location>).  Either the destination path does not exist or you don't have sufficient permissions.  Please verify your export credentials in the Export Settings tab inside User Manager.  Additional diagnostic information may be present in the following error text from the export format: Unable to open a record-set from the result-set database (User_name\Data\BVT_4852d4eg99e6859286a1c8f456f7b96b) due to error (Can't open recordset: Syntax error in ORDER BY clause.).  The query-string used was (SELECT * FROM Table1 order b).

Schedule logs will give you detailed information on why the schedule failed - whether the failure is related to export, whether it is due to failed credentials or whether it is caused due to any other factor.

Thank you for taking time and reading through this technical article.

Hello,

The Symantec Endpoint Recovery Tool (SERT) is a bootable CD that can scan and remove malware from an infected computer. SERT is useful in situations where computers are too heavily infected for the Symantec Endpoint Protection client installed upon them to clean effectively. It is also necessary against specific threats which have the ability to completely hide from Windows, or that have techniques that manipulate Windows into protecting the malicious process against Symantec Endpoint Protection's scanning and remediation components.

Symantec Technical Support can provide guidance on when it is recommended to use SERT.

Current Version : Symantec Endpoint Recovery Tool 2.0.24

New functionality:

• SERT no longer downloads new virus definitions automatically on launch, instead it waits until you start a scan. If you have already provided updated definitions on a USB stick, it does not initiate the download
• SERT now includes PCAnywhere ThinClient to enable remote control of the machine to be scanned
• SERT now includes support for Symantec Endpoint Encryption 8.0 and earlier
• SERT now has better rootkit remediation capabilities

To use the Symantec Endpoint Recovery Tool

1) On a computer that is not infected, and that has a CD burner, go to FileConnect and download the Symantec Endpoint Recovery Tool.iso file.

2) Burn the image onto a CD or DVD.

For full details, read: Symantec Endpoint Recovery Tool (SERT) download comes as an ISO (disk image), How do I use this?

3) Download the latest virus definition .jdb file from Symantec Security Response.

There are two types of virus definitions you can download: Daily Certified Definitions and Rapid Release Definitions. The links to both definitions are listed below.

• Daily Certified Definitions are standard virus definitions. They are the default set of definitions, which is distributed normally to clients. Certified definitions have been through the full QA process for false positives or other issues. http://www.symantec.com/business/security_response/definitions.jsp
   

• Rapid Release definitions contain newer, more up-to-date definitions than Daily Certified Definitions. They are generally recommended in cases of virus infections. Rapid Release definitions are typically used on a case-by-case basis and are not recommended for everyday use across the entire environment. Rapid Release definitions have not been tested as thoroughly as Daily Certified Definitions. http://www.symantec.com/business/security_response/definitions/download/detail.jsp?gid=rr

4) Using an unzipping utility, unzip the .jdb file into a new folder.

Note: It is possible to use the built-in Windows unzip utility to unzip the .jdb file. To do so, change the file extension on the .jdb file to .zip, right-click the file, and click "Extract All...".

5) After the .jdb is uncompressed, place the folder on a removable storage device or in at the root of the infected computer's hard drive so that the Symantec Endpoint Recovery Tool can access the definitions.

6) Confirm that the infected computer boots from CD or removable media first. Please refer to the computer's manual for information on configuring the computer appropriately.

7) Boot the infected computer from the SERT disc created in step 2.

8) Click Continue loading Endpoint Recovery Tool

9) Select a language and click OK

.

10) When presented with the Symantec Software License Agreement, Insert the PIN and click I Agree. 

NOTE: Symantec customers with a valid support contract may contact Technical Support for the necessary PIN.

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

11) If a network connection is not available, you can use the "Browse for Virus Definitions" in the lower right. The Step 3, 4 and 5 explains how to download the .jdb file and extract the files on the USB drive. SERT no longer downloads new virus definitions automatically on launch; instead it waits until you start a scan.

If you have already provided updated definitions on a USB stick, it does not initiate the download. (Definitions included with 2.0.24 are dated 25 March 2013. Some of these images were taken without a network connection.)

12) Verify that the virus definitions have been loaded by looking in the lower right-hand corner of the screen. Virus definitions current as of should reflect the current date.

13) Make sure that Save scan session information is checked.

Saving the scan session allows you to undo any modifications made by the tool.

If needed, you can change the location where the scan session information will be stored. To do so, click  Change location and select the preferred location.

14) Click Start Scan.

15) This is the interface you see when the scan is running.

Menu options:

Advanced: includes only "Launch Command Prompt":

About: Shows the following:

To undo a previous scan

Warning: This action will also restore any threats and other security risks removed during the scan.

1. If you need to undo the actions of a previous scan, in the main screen, click Undo.
2. Select the session you want to restore, and click Undo.

NOTE: Security administrators interesting in enhancing the capabilities of SERT may be interested in the Connect Forum article on 

How to Customize Symantec Endpoint Recovery Tool (3rd Party Utility Integration)

https://www-secure.symantec.com/connect/articles/how-customize-symantec-endpoint-recovery-tool-3rd-party-utility-integration

The above document contains detailed instructions about how to boot SERT from a USB, how to add additional third-party functionality, and how to update SERT's definitions.  

Please do note that this white paper is unsupported and Symantec Technical Support cannot offer assistance on those steps.

For convenience, here are links to Symantec's brief articles containing the supported steps:

System Requirements documentation for the Symantec Endpoint Recovery Tool (SERT) 

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

Symantec Endpoint Recovery Tool (SERT) download comes as an ISO (disk image). How do I use this? 

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

How to make the Symantec Endpoint Recovery Tool boot from a USB memory stick

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

What does the full scan from the Symantec Endpoint Recovery Tool (SERT) CD scan ? 

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

How To Use the Symantec Endpoint Recovery Tool with the Latest Virus Definitions

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

VIDEO: 

Symantec Endpoint Recovery Tool (SERT)

https://www-secure.symantec.com/connect/videos/symantec-endpoint-recovery-tool-sert

Symantec AntiVirus for Linux（SAV for Linux）は、Linux 用のウイルス対策製品です。この資料では、インストールや運用、設定などについて解説しています。SAV for Linux は、Symantec Endpoint Protection（SEP）のライセンスに含まれていますので、ライセンスの台数内で Windows、Mac、Linux でマルウェア対策を実施いただくことができます。

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

Symantec Endpoint Protection 12（SEP12）は、ネットワークの不正侵入防止に加え、ブラウザ上のスクリプトをリアルタイムで評価し、攻撃を防止するブラウザプロテクションが標準で動作しています。この動画では、その防御の仕組みの説明とデモをご覧いただけます。

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

Firstly, please let me clarify that this article refers to “Vulnerability Scanning”. I wouldn’t want you to read this with the wrong expectations.

Secondly, I need to outline that there is information in this article that can help in certain situations. These situations, that I will clarify later, are NOT recommended as an initial design, nor supported (when using the Symantec technologies and perhaps others). The information helps in the unfortunate event in which architectures can change and cost prohibits the positioning of a VS solution, leaving it in a less than ideal place (behind firewalls and other security devices).

Right, now that’s out of the way… Vulnerability scanning! I love vulnerability scanners. Over the past several years they have come on leaps and bounds in helping us automate the time consuming task of finding known vulnerabilities. The discovery of assets, enumeration of ports and services, evaluation  (and consequently the marrying of know vulnerabilities against service versions) has been bolstered with web scanning, database scanning, policy compliance scanning and several other scanning methods that improve our visibility and therefore risk within organisations. We are even presented the opportunity for unsafe scanning that allows vulnerability conformation by exploitation to improve the accuracy of information. However, this article is not to describe the ins and outs of Vulnerability Scanners, but to help with a particular situation of the architecture and design.

Vulnerability scanners are most accurate and provide better results, when their connections are not blocked or interfered with by other security technologies. Firewalls and IDP systems are designed to block unwanted and unnecessary traffic from entering (and leaving) particular areas of a network. It is quite unusual, therefore, to design vulnerability scanners to sit on the ‘wrong’ side of these devices. However, in some situations, it is unavoidable and in my particular example, was unforeseen.

Before I continue, I must mention (again) that most vendors won’t offer support in these types of situations (including Symantec). There are technologies at play that vendors can’t support and can be the reason for the scanning process not functioning in the way it is designed. So why do I continue? As part of the TSS (Technical Sales and Services) team at Symantec, I am a techie at heart. I find it personally rewarding to be as innovative and helpful as possible in ‘techie’ situations. I worked something out and wanted to share it, just in case anyone was having the same problem. I thrive on techie knowledge and understanding, however, I digress. So, on to the situation…

A VS solution was put in place to monitor several areas of a network. These were logically separated areas and each area was on a boundary with a firewall device. The original solution included scan engines in the relevant areas, to avoid scanning through the perimeter devices. A change in network architecture meant that these logical areas were subsequently sub-divided, meaning that traffic from one to another, had to go through a routing device. These, for budget reasons, were the perimeter firewalls. So, not only were the firewalls responsible for filtering the traffic between particular areas, they were now acting as routing devices in smaller segments of those networks. I know, I asked about layer 3 switching capability too, but it was not available. What can one do?! So the problem now was; When a scan was being run for a segment, a greater number of allocations in the firewalls state tables were being used to route the traffic. As a brief overview of state tables, they provide (amongst other functions) a way in which we can monitor and manage connections between two devices. They support a simple network rule that allows Computer A to connect to Computer B on a given port (or ports). The state maintained means that we do not need to write the reverse rules for these communications. This I HUGELY beneficial for the firewall admin teams. Now, during the asset discovery and service discovery phases of the scan, we connect to one, if not many, ports on a destination asset at the same time. For the purposes of speed we typically connect using only the SYN part of the three-way-handshake for statefull protocols like TCP. What does this mean? Well, for every port on every computer we connect to (through the firewall), the firewall maintains a state for it. Because we focus on speed (and usually there are no firewalls in the way) we only use the SYN and do not response to the SYN/ACK response. If we get that response, we can determine if the port is open or not and move on swiftly. This means that there are many ports left open, in the state tables of the poor firewall we are scanning through. Now, firewalls have also advanced in both function and performance. However, state tables can only be filled up so far before they are exhausted. This exhaustion is what typically contributes to a DDoS (Distributed Denial of Service) attack. What’s the last thing we want to do when testing and trying to improve security? Yep, that’s right, we don’t really want to take down segments of the network or firewalls in the process.

So here was my result; a formula that allowed a company to determine how many devices and ports could be scanned at the same time, without exceeding a defined number of connections through a firewall. This defined number of concurrent connections through the firewall could be based on what the firewall could handle (a maximum), or a number defined by a policy. For example: “There must be no more than ‘x’ ports open, at any one time, by the vulnerability scanner through this firewall.” In my particular case, it was the latter. Now, firewalls aren’t stupid. They know when something’s not being used and can close open ports and remove entries in state tables after a period of time. So this is something I needed to take into consideration. Also, vulnerability scanners today have a plethora of performance tuning options, including ‘Packets per second’, ‘Delay between scanning hosts’, ‘Connection time outs’, ‘Number of retries per port’ to name but a few. If the scanner your using doesn’t, then perhaps take a look at Symantec Control Compliance Suite Vulnerability Manager, it does! (OK, that is the first and last sales reference in this article, I promise). So, all considered here is the formula… drum-role please…

Where:

C = Maximum of concurrent connections allowed on a firewall

RT = Time (seconds) after a stale connection is reset

CP = Number of concurrent ports scanned on a target system

TP = Time (seconds) taken to scan and complete 1 port on a target system

S = Number of concurrent targets that can be scanned at the same time

In my particular case, the firewall was not allowed to consume more than 10,000 open ports at any given time, it reset stale ports after 15 seconds, we were scanning 23 ports concurrently per host and it took 3 seconds to scan each port. Let’s work that out..

((10,000 \ 15) \ (23 \ 3)) = S

(666.67 \ 7.67) = S

S = 86.9

S = 86

So, we are scanning 86 hosts at a time, each with 23 ports being scanned at a time and taking 3 seconds to scan each port. Therefore every second, 659.34 ports would be open. After 15 seconds, 9890 ports would be open before the firewall started closing down stale ports, resulting in no more than 10,000 ports being open at any given time.

This equation can also be re-arranged to work out how many ports to scan per host if you are scanning ‘S’ number of hosts, which might be more suited towards a situation.

There are also some limits on how many hosts and also ports can be scanned at any given time by vulnerability scanners. These limits with the firewall limits might not present a problem for concurrent connections, but it’s always nice to be sure.

If anyone else has run into similar situations and devised a work-around, I’d love to hear about it. We can share ‘techie’ thoughts on helping to fix these awkward situations together. Thank you to anyone who made it to the end of the article without falling asleep.

The Network Activity Tool in SEP is a very simple, yet extremely helpful tool. The purpose of this tool is simply to show the incoming/outgoing traffic of the applications running on the system. In order to use it, you need to have the NTP component installed and a firewall policy assigned to the client. Also, to get the most benefit from it, the client should be in Mixed mode. To set the client to Mixed mode, login to the SEPM and go to the Clients tab. Select the group the client is in. Click on the Policies tab. Under Location-specific Policies and Settings, click the + sign next to Location-specific Settings. To the right of Client User Interface Control Settings, click Tasks >> Edit Settings. Check the radio button for Mixed Mode than click Customize. For the purposes of this article, I have set all radio buttons to Client. This is not recommended as it gives the end users full control. I only did this for ease of use in writing the article. Once finished, Click OK to save the changes and let the policy update take affect on the client.

In order to access the Network Activity Tool, open the SEP GUI. Next to Network Threat Protection, click Options and select View Network Activity...

You will than be presented with the Network Activity screen

An overview of the total amount of incoming/outgoing traffic is shown along with the applications that are currently running and the amount of traffic they're generating.

If you click on the View menu, you will have a few more options to adjust what you would like to see:

Clicking on the Tools menu will also give you some helpful options:

If you select View Firewall Rules... it will bring up a list of all rules, the action, and who it was created by:

This can very helpful when troubleshooting issues suspected to be caused by the firewall. This option is only available when in Mixed mode as already mentioned.

You also have the option to test your network security. This option runs the Norton Security Scan against the client, testing for security holes.

Block All Traffic will immediately stop all traffic. Be careful with this option.

This tool can also be very helpful in looking for suspicious processes that may be running. See this HOWTO to guide you:

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

Overall, this is a great tool and I suggest you spend some time exploring its features as it may benefit you greatly.