Log Filtering Issues

[MrSaintz]

Hi everyone,

I'd like to post this query before I move to support, maybe I'm doing/assuming something wrong here.

So a very simple log filter query "domain"

Searching shows a lot of information...

Now let's use "domain-udp"

comparing domain with domain-udp, domain-udp is, to me, more specific than just domain, right? ...Wrong?

I would say, this is a typical WTF?! question, but as I said above, maybe I'm doing/assuming something wrong with this search filter.

I narrowed down the time to get the highlighted dropped domain-udp sessions from the previous search.

The only difference I notice is the log type: the geo drops are marked as "log" were as for the matched rules are type: connection, but still we have a drop in the middle that hits the clean-up rule 180.

Can anyone explain to me, or is this really a support issue?

Best regards,

Carlos

[Vladimir]

May have something to do with the word "domain" contained in the "description" field:

If you want to have more accurate results, search with "service:" prefix:

[MrSaintz]

Thank you Vladimir,

That was my assumption, but if you look at the screen shots, searching for domain matches much less records then searching for domain-udp, not the other way around...

Searching for specific fields, yes I understand, and it does narrow down to some degree, however it can narrow down too much for troubleshooting, consider asymmetric routing, we want to search for specific traffic on the service, and on the source port, one good trick I confidently used until now was, not specifying the fields in which I want to search for the flow, and hoped it would match more records than big query strings using 'or'/'and' for specific fields.

Rick Lin‌,

Thank you for the input around the "port:" field,  I did use the help to check for the query language the problem in the help file is that you always mention fields attached to a query string, however you also allow a simple string query.

My clarification request from this point on is:

What fields are used in a log filter search, when not field is specified? And can anyone explain to me how can "domain" match less then "domain-udp" in such scenario?

Best regards,

Carlos Santos

[_Val_ · Accepted solution]

Did you try domain* instead of just domain? Might do the trick. But of course it seems there is a minor issue with the search tool

[MrSaintz]

It does help Valeri, thank you for the heads-up, i guess i need to use more wildcard options from now on.

In the end the purpose of a log filter search is to to troubleshoot for specific flow conditions, if one cannot feel confident on the search results, troubleshooting is limited right from the start.

[RickLin]

Hi Carlos

I also notice the SmartLog search function are not perfect, I found some field data can't be searched.

So I only use the field what I known how to use to search.

Because it is not perfect, so we need to suggest CheckPoint to improve it.

[MrSaintz]

Thank you Rick, to be true nothing is that "perfect", but one needs to feel confident of the used tools in hand to help your customers, right?

[Vladimir]

Carlos,

This may be an issue with implied delimiter: In the screen caps in my previous post, the OU=Domain is probably being recognized as a standalone "domain" in search string, whereas "domain*" will read "domain-udp".

Searching with prefix "service" using "domain" returns nothing:

While doing same with "domain*" actually yields results containing "domain-udp":

So this reflects the results discrepancy you are seeing.

[MrSaintz]

I think you narrowed down to issue, it does seem to implied delimiter, I only thought that "-" should affect it the same way (as a delimiter) maybe we need to figure out what is forcefully excluded in any search, but then again wildcard does perform very well.

[RickLin]

At the same time.

If you know the service port number what you looking for, you can use "port:".

You also can reference the CheckPoint SmartConsole online help about SmartView query language. 

SmartConsole R80.10 Help