Endpoint Protection

Hi,

I have a distributed SEP management environment with multiple SEPM servers. On each SEPM server I have configured external logging to an external syslog server. We then receive alarms and email / sms notifications when a particular Syslog message is received (in this case a virus)

This works for some of our SEPM servers, for the servers that are working properly the syslog message source is the IP address of the SEPM server: e.g.

 

Source	Facility	Severity	Message	Received
192.168.0.22              line printer subsystem                ERROR       site: mysite Server: SERVER01: Virus Found                              Tue Jan 29 17:32

For the SEPM syslogs that are not working the source is listed as SymantecServer and not the IP address, in turn our syslog server cannot process the syslog into an alarm as the source does not match any of our servernames:

 

Source	Facility	Severity	Message	Received
SymantecServer         line printer subsystem                ERROR       site: mysite Server: SERVER01: Virus Found                              Tue Jan 29 17:32

Anyone know where the Source is configured? There must be some difference in the SEPM servers as some are listed as the IP address where others just send messages as a generic SymantecServer? Or maybe there is another reason I am missing?

Any ideas are greatly appreciated.

What version of 11.x are you running?

Found this in the knowledgebase, not sure it completely applies but wondering if you're on an older version

Syslog events show Source IP address as 0.0.0.0 when SEPM risk events are forwarded

Article:TECH132755

|

Created: 2010-01-27

|

Updated: 2011-07-05

|

Article URL http://www.symantec.com/docs/TECH132755

 

Did this issue just start?

Hi, We have updated to 11.0.7300.1294 (the latest version). I have already read that KB and unfortunately it is not relevant to us as the source IP address is shown correctly in the syslog message :( Thanks.

Unfortunately, I haven't been able to find much else. I would suggest opening a case so they can determine if it is a bug in the latest version of 11.x.

Have you observed this issue prior to upgrade to RU7 MP3? What version have you been using before?

I wasn't using syslog prior to the upgrade so cannot say if it happened previously... only thing that I cannot figure is that some SEPM servers send the source correctly as the IP address whereas others use what looks like to be a default name of "SymantecServer" hence why I thought that this has got to be a configurable option somewhere?

I could not find any such option out of the SEPM GUI - I am afraid it may be hardcoded now like that. After quick check on some other forums it seems 12.1 gives the same source name now.

I am not that familiar with Syslog but is there any option maybe to use the name "SymantecServer" as name that the Syslog server could recognize and process as any other hostname or IP address?

Hi,

I have now resolved this issue and can confirm that it was a software bug in our syslog servers that were not parsing the syslog packets correctly. Many thanks for your assistance...

I have come across another issue however with the syslog messages whereby when each SEPM server replicates with another server the risk logs are also replicated, these are then sent out as duplicate syslogs from the server that has received the replicated logs.

For example: CLIENTA detects a virus and SEPMSERVERA (central SEPM server) gets notification of this. The external logging sends this syslog message to our monitoring system which in turn sends out an email / sms notification. This works great.

However when SEPMSERVERA replicates with SEPMSERVERB (branch SEPM server) the syslogs are sent out again this time from SEPMSERVERB meaning we get duplicate messages every time replication occurs (every 24 hours). We do relicate both the database as well as the logs as we need to ensure our central server can produce reports for our whole network not just itself. Maybe if I configure logs to be replicated in an upward direction will I be able to avoid these duplicate syslog messages from being generated?