Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SAV for Linux: A (Somewhat) Illustrated Guide Part 4: SAVFL Reporter

Created: 25 Feb 2013 • Updated: 22 Sep 2014 | 8 comments
Language Translations
Mick2009's picture
+15 15 Votes
Login to vote
SEP 12.1 RU5 introduced a managed SEP for Linux client in September 2014.  Details can be found in New fixes and features in Symantec Endpoint Protection and Network Access Control 12.1.5 and Symantec Endpoint Protection 12.1.5 for Linux Client Guide. The use of this new, managed SEPFL client is highly recommended over the legacy SAVFL client.

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.

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.... )

Clark Kent

(Full SEP Client)

Peter Parker

(SAVFL with SAVFL Reporter)

All-powerful (many protection technologies) Mighty, but limited (AntiVirus only)
Staff member (appears in SEPM's list of official, managed clients) Freelance (intentionally unmanaged- does not appear in SEPM list of clients)
Reporter (lots of information, the full story) Photographer (can provide a picture/some information)

 

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.

 

 

 

 

 

 

Comments 8 CommentsJump to latest comment

.Brian's picture

Good stuff, keep 'em coming

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

+1
Login to vote
MeloSep's picture

Great resume Mick, as usual.

I think worth to mention that, in case SAVFL is removed/reinstalled, the configured reporting component will go away with it.
Since sometimes reinstalling is part of the troubleshooting steps for SAVFL, to avoid to reconfigure all,  do a backup of /etc/reporterd.ini before to proceed to remove the client.

This will save some time :)

+1
Login to vote
Mithun Sanghavi's picture

Wow.. part 4 !!! Super Awesome !!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

+1
Login to vote
John Santana's picture

LOL, that's pretty much make sense and hilarious Mick :-)

Kind regards,

John Santana
IT Professional

--------------------------------------------------

Please be nice to me as I'm newbie in this forum.

+1
Login to vote
raju123's picture

thanks Mick2009 for valuable and nice artical +1

+1
Login to vote
Ta-chang's picture

This information worked perfectly on our SEP environment with SAV for Linux client.

Thanks!

+1
Login to vote