Mapping Parsers to Hosts

[DavidEagen]

Any suggestions on how to get NetWitness to correctly map parsers to hosts? It keeps mapping F5 Big IP and ciscorouter parsers to our RedHat instances. When opened a case with support but so far the answer they give is to manually map each of our 24,000 event sources by clicking through the web UI. That's just not acceptable. There must be a better way. Without correct parser mapping NetWitness is unusable as it can't figure out what a message is.

[Anonymous]

Hi David,

NetWitness discovers and parses each log individually, unless it is mapped.  Some individual logs are ambiguous and cannot be discovered and we added the ability to map addresses to parsers to handle these occasional mis-discoveries.  Feedback has been that it is a small percentage of logs, though we'd like to get all logs correctly parsed out of the box.

In 11.2 we've added the ability for NetWitness automatically map addresses to parsers based on previous logs received from an address.  This should alleviate the need for you to manually map parsers, though that ability is still there in case you need to override what has been discovered.

Thanks,

Guy Williams

[DavidEagen]

Interesting, I’d like to see if that resolves the problem. Where can I download 11.2? I only see 11.1 listed on the Logs & Network version list.

[EricPartington]

11.2 will be released shortly

what is your current version?

in 10.6.x on each decoder the UI creates an csv file that is used to map the IP to a device(s)

if you create one mapping (maybe one that represents the mapping that you will be doing for a bulk of IP addresses) and then export that file

if you open the file you get something like this

"192.168.254.12","rhlinux,apache"
"192.168.254.17","rhlinux"
"192.168.254.142","rsasecurityanalytics,rhlinux"

with a little notepad++ or excel foo you can create a mapping file for your 24,000 assets (locate the devices in investigator, click the triangle to the left of the metakey name and select view as csv to quickly export the values of that key to use here) that you need to map the same (say set them all to rhlinux)

Then import back into the decoder(s) and you are mapped.

As always reduce your enabled parsers to just what is needed to avoid misparsing due to generic headers.

If you have multiple device types per device IP then make sure both are listed in the list for that ip and that systems that have the same mapping are in the same order (or you may have some odd parsing occur between two similar devices)

[DavidEagen]

We're using 11.1.

[DavidEagen]

When will 11.2 be released? Is it soon as in next week or soon as in 4th quarter 2018?

When it is released, will this eliminate the need to use outside products like Notepadd++ and Excel to configure NetWitness?

[VishamRawat]

Hi Eric,

Just to be clear, you stated

in 10.6.x on each decoder the UI creates an csv file that is used to map the IP to a device(s)

...

if you open the file you get something like this

"192.168.254.12","rhlinux,apache"

...

We get the option to export our forced-mappings via csv - that's what you meant right? I just wanna make sure I'm not missing something.

Also, in this example you present a case where somebody's force-mapped an IP to 2 device types - "192.168.254.12","rhlinux,apache".

Again, why would that be? and which one takes precedence, and how?

Please help elaborate on this further.

[EricPartington]

Yes you can export the mappings created, or you can use export to create additional entries if you are bulk mapping the same parser(s) to many IP addresses.

First parser takes precedence if there are similar or identical headers

In this case it's a rhlinux system (Centos7) running apache so I have both logs coming from the same IP to the same log decoder. So I chose to map both to the device IP to demonstrate how it looks.

Also in this case the parsers are different enough that order isn't that important but its good practice to keep the order the same between systems that have the same parsers mapped to make sure that they are consistent in case one message could fall on one side of the line or the other.  I have seen edge cases where one device was ordered differently in a list of many and that one had a few odd parsing choices, setting the order the same as the others resolved the issue.