Find FQDNs accessed using HTTP and HTTPS through a firewall with URL Filtering and App Control

[net-harry]

Hi,

We have identified some servers that currently have full HTTP and HTTPS access to the Internet through our external Check Point security gateways.

In order to restrict the access we need to know what the servers are connecting to on the Internet. The current rule uses the firewall blade (allowing HTTP and HTTPS) and logging gives us the destination IP addresses.

We also want to know the FQDNs accessed. I therefore created an inline layer for a test source IP address (with parent rule allowing HTTP and HTTPS) with Internet as destination and enabled Detailed Log for the rule.

I thought this would help us view the FQDNs, but for most destinations I still only see IP addresses. I also tried enabled Extended Log, but with similar results.

I noticed that for some log entries that are marked as "Content Awareness", I can see the fields "TLS Server Host Name" and "Sni", which seems to give what I am looking for.

Strange thing is that Content Awareness is not even enabled on this gateway. Would someone be able to explain this and recommend how to best detect the FQDNs that are accessed?

We are running R80.20 on the security gateways and R80.40 on the management servers.

Thanks for your help!

Best regards,

Harry

[Chris_Atkinson]

Hi Harry

To confirm is this R80.20 JHF T190 or higher?

What blades are enabled for the layer?

[net-harry]

Hi Chris,

We are running R80.20 take 202.

The firewall has the following blades enabled:

[Expert@firewall:0]# enabled_blades
fw urlf appi anti_bot mon

The inline layer has the following blades enabled:

Firewall
Applications & URL Filtering

[Chris_Atkinson · Accepted solution]

Please review sk173633 and see if it helps you.

[net-harry]

Thanks for the suggestion! I assume there is no impact to make the change in the sk? In any case we will schedule a maintenance to perform it.

I just noticed another thing that perhaps could explain the missing logs. We also have two ordered layers for the policy. One is called Security and one is called Application. The Security ordered layer only has the Firewall blade enabled. The Application ordered layer only has the Applications & URL Filtering blade enabled. I am adding the new inline layers in the Security ordered layer, since we want to move away from the ordered layers. Is it required that the Security ordered layer has the Applications & URL Filtering blade enabled or is it enough that the inline layer underneath has it? 

[Wolfgang]

It will be enough to enable Applications & URL Filtering blade of the inline layer for your use case.

[net-harry]

Thanks Wolfgang for the confirmation!

In sk173633 it says:

"Important Note - Make sure the policy contains Categories/Apps. Otherwise, the connection might be matched on the SYN packet without the Light SSL flow."

Could someone explain what this note means? In our case the policy has rules with Categories/Apps, but also rules using only the firewall blade. Is there a risk for us to enable up_log_ssl_report_sni?

[Chris_Atkinson]

Should be no risk or impact other than the reboot step to apply the setting permanently, even then impact would likely be unnoticed in a clustered environment.

[net-harry]

Thanks Chris! Is there any other drawback of enabling it? Is there a reason that this is not the default setting?

[Tobias_Moritz]

Hello @Chris_Atkinson: Do you know how the expected behavior is when this new kernel parameter from sk173633  is set to 0 (default)? I ask because I see these SNI entries in log card of extended log rules matches for some log entries even when this parameter is set to 0. I do not see it for every log entry (of the same rule), though.

R80.40 JHF T139.

# fw ctl get int up_log_ssl_report_sni
up_log_ssl_report_sni = 0

Log Card example:

TLS Server Host Name: r4.res.office365.com
Sni: r4.res.office365.com
Certificate Validity: Trusted

[net-harry]

Hi @Chris_Atkinson,

We have enabled up_log_ssl_report_sni and we are now able to see the information we were looking for. Thank you very much for your help with this!

Like @Tobias_Moritz, I noticed that we already had TLS Server Host Name and SNI for some records before the change. I also noticed that the information is also available when "Detailed Log" is used (instead of "Extended Log" as mentioned in sk173633).

Would you be able to share some light on this?

Thanks for your help!

Harry

[Chris_Atkinson]

Hi Harry, Sorry I don't have the details necessary to explain the behavior as described.

If it's important I'd suggest contacting TAC or your local SE to enquire with RnD on your behalf.