This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Odd traffic showing up in LEM

So i'm seeing traffic in my LEM show up that doesn't make sense.

Here's the log entry..

Event Name: ServiceInfo 

EventInfo: x.x.x.x [worker] - new_mail: aefc01fbd4f0c23ff5f022771583f1e4 1443132340 <HealthMailbox5d57ec28a15a476093363e5fbf6eccf9@somewhere.com> healthmailbox5d57ec28a15a476093363e5fbf6eccf9@somewhere.com 0 internal 5334 4096  InsertionIP: LEMserver  Manager: lemserver  DetectionIP: tubes.pl  InsertionTime: 14:05:03 Thu Sep 24 2015  DetectionTime: 14:05:03 Thu Sep 24 2015  Severity: 4  ToolAlias: Tippingpoint Connector Discovery  InferenceRule:   ProviderSID: 1022  ExtraneousInfo:   ServiceName:   SourceAccount:   SourceDomain:   InfoMessage: x.x.x.x [worker] - new_mail: aefc01fbd4f0c23ff5f022771583f1e4 1443132340 <HealthMailbox5d57ec28a15a476093363e5fbf6eccf9@somewhere.com> healthmailbox5d57ec28a15a476093363e5fbf6eccf9@somewhere.com 0 internal 5334 4096

I've changed references to systems on my network as well as addresses. 

So The detectionIP makes no sense.. we don't use any service called tubes.pl for email.

Also we do not have any tipping point devices...  

We do use barracuda spam services but thats not tubes.pl  

When I brought this up to support they had me delete this node (tubes.pl) and wait for a bit to ensure it didnt show back up.. Well it came back mysteriously.

Just deleting it again doesn't make sense to me, not that it made sense the first time either but i thought they 'should' know what they are doing.

I need to find out why the heck this keeps appearing as a node when it does not exist on my network..

The ip address it assigns is 185.53.178.6 which is some company in germany.

So either SLEM is broke or my network has been hacked.  This seemed to start sometime around updating to version 6.2 so maybe there is a problem with this release.??

  • Based on the connector name 'Tippingpoint Connector Discovery', someone must have clicked on 'Scan for new nodes' from the web console at some point which would have enabled this connector. I would first go to the Manage , Appliance section of the web console and search the list of enabled connectors to see while file the 'Tippingpoint Connector Discovery' connector is reading


    From the  cmc console, you can then run the appliance, then exportsyslog command to export the logs corresponding the facility in question to search through the raw logs that is triggering this event.


    If you really have a Tippingpoint device, then leave the connector as-is. If not, you can safely delete the connector



  • You are correct in that someone clicked on scan for new nodes.. I did however that shouldn't have added an ip address as a node for a system that is not on my network should it?

    I mean it is only supposed to add nodes that existing on my network should it not?.  (unless we have a tunnel of some sort to this outside node)

    Deleting the node was what support had me do before and they didn't really give me an answer as to why the node showed up in the first place. If the product is broken or bugged fine let me know that... if my network has been compromised I need to know that as well... if this is how the product works (which seems extremely unlikely because this never ever happened before the update no matter how many times I scanned for new nodes), than let me know that as well.

    Again I have no tipping point devices on my network.

    I will do as you suggest and go through the logs and find out what the heck is going on because this is troubling.

    I worked with support and we removed tipping point from the connectors and this removed the unknown node..  However this has just made things much worse for everything else.

    I have some new nodes, (barracuda message archiver and meraki wireless access pionts) that are all being misidentified as tipping point connections.  When i try to manually add them the LEM says nope these are tipping point connections.. I have spoken with both vendors and they have assured me that they have not suddenly changed their logging or connectors to tipping point so the problem is with the way lem see's these logs and misidentifies everything now as tipping point.

    Followup:

    Worked with support again and it appears the connectors might be the cause of the mis-identification.  Support is checking to see if the devs can either point to the correct connector or update the connector setttings.

  • As a note, when you're doing a checklogs command and looking at a syslog facility, you can enter a forward slash ("/") and then an IP to search the syslog entries to see where the IP appears.

    It sounds like some device you do have puts an IP where the Tipping Point connector expects to see a source IP address.  Every unique source IP adds a node to the LEM console and takes a license, and this is one way that having the wrong connectors setup can be trouble.

    When you click "Scan For New Nodes" the LEM begins looking through all the syslog facilities to see if any of the data lines match patterns in the connectors, and then it configures ALL THE CONNECTORS that come back as potential matches.  Again, it sounds like a device that you do have is close enough to the Tipping Point format for the LEM to think there's the possibility of a match, but not close enough to avoid bogus nodes.

  • Curtisi,

    Im working with support to get an update for the connector that is causing the issue.  I'll update this once that has happened.

    Just for FYI, this is being caused by the Barracuda Email Archiver.  For whatever reason the connector changed sometime between the latest release and just before it because prior to this the connector correctly identified the Barracuda Email Archiver and didn't try and id it as a tipping point connector/device.