HTTPS Inspection logs doesn't show the fqdn when the fqdn bypass rule configured with Network Feed

[Kayhan_SAHIN]

Hello everyone,

We have a rule in the https inspection policy to bypass certain destination addresses with fqdn and non-fqdn. We created a network feed object to get the list of entries and enforce it in the rule. 

When I check the logs that hiting this rule with its rule UID, I noticed that onyl the network feed name exist in log details. I am not seeing any fqdn information in log details which the request bypassed when accessing that certain fqdn. Is there anything I can do to see this information? It is probably not included current releases but maybe there are some future enhancement requests for this spesific field. It will really increase the log visibility if the RnD add it to the next releases.

Thank you all.

[the_rock]

Are you able to send screenshot of the rule? One thing I would try is maybe enable below on top of logging and see if it helps after you push policy.

Andy

 

[Kayhan_SAHIN]

Hi @the_rock 

Sorry, I can not share the screenshot. When I check the https inspection policy track options ,there is no options for accounting.In one rule I add the domain object to destination and saw the fqdn information below the destination field of the logs. In other rule which I mentioned in my first post, I added the network feed object to destination which fetch the list of the fqdn and non-fqdn entries, but I didn't see the target fqdn name in the log's destination field. Only IP addresses and feed name is seen. 

Thanks

[the_rock]

No worries. Thats right, it does not give any accounting options in ssl inspection policy. Now, I could be mistaken when I say this, but I believe behavior you see if indeed correct and here is why. Yes, while its true that network feeds use both IPs and fqdns, when it comes to logging, you might not actually see those fqdns in the logs, but with domain object, you usually would, as its either fully qualified domain (by default) or 10 sub-domains if its non fqdn (also by default).

Again, Im not 100% sure about this, but just my logical conclusion based on my previous lab testing as well.

Andy

[Kayhan_SAHIN]

Thank you for your detailed explanation, Andy. We are using separate feeds for IP and fqdns. Actually this is not an issue with IP feed. Because when I search the IP address in the logs, I saw it clearly. But with the fqdn feed, we can not search the specific fqdn in the bypassed log. (only category-based bypass logs shows that information)

For the guys from RnD or employee reading this post, please give it a reply if the enhancements are in place for this issue in the coming releases. Because when troubleshooting an issue, it makes the analyze harder when not seeing the fqdn information on the logs. 

Thanks

[the_rock]

No no, Im not saying its an issue with anything in particular, Im saying that behavior might be by default, just my logical thinking, but again, I could be mistaken.

Anyway, hopefully someone else will confirm.

Andy

[Kayhan_SAHIN]

Hi @the_rock 

Yes, the word "issue" probably not the correct word in my response. Sorry for that. As you mentioned maybe this default behavior. But to make the troubleshoot easier, it would be perfect if we see the destination fqdn info in the log with specific field when using network feed object. That's why I share the post here.

Thanks.

[the_rock]

Thats 100% totally fair and thats why Im hoping someone else can confirm, for sure. Maybe TAC case to verify would not be a bad idea either.

Andy

[Lloyd_Braun]

Depending on the site, SNI logging might help. It is nice to enable for logging detail either way.

https://support.checkpoint.com/results/sk/sk173633

fw ctl set int up_log_ssl_report_sni 1

[Kayhan_SAHIN]

Hi @Lloyd_Braun 

Maybe SNI might help in other rules. But in my example, when using network feed object which only consists fqnd and non-fqdn (*.example.com) entries in the destination it will probably not help.

Thanks.

[PhoneBoy]

The way we determine whether an https connection matches a specific domain or not is usually via SNI.
Passive DNS may also play a factor.
Either way, enabling additional logging related to SNI may help here.

[Kayhan_SAHIN]

Hello @PhoneBoy 

I submit an RFE to the Check Point yesterday for this issue. In a parallel, we will discuss with local CP office to enable SNI logging whether it wil help us or not. I will share the result after test it.

Thanks

[the_rock]

Let us know if you do figure it out.

Andy