A suspicious traffic log was observed during monitoring

[jack_723]

Hi Experts,

"After an internal user attempted to connect to Microsoft Outlook, we observed in the logs that a Microsoft public IP accessed the external interface of the Internet firewall using port 443.

Could you please explain why this is happening? Thank you.

[_Val_]

It is hard to say exactly from the logs you showed, what it is, without some additional date.

The log says "Accept", but does it show a rule number?

Considering the source port is SSL, this looks like Server to client traffic. It is very likely someone is using O365, and this is either an orphan server to client communication, or part of legitimate data from MS, to a client NAT-ed behind your Internet FW IP address. 

I would look for the policy rule number and for NAT parameters of that specific log entry, to drill down, before jumping to any conclusion.

[jack_723]

Thank you for your reply.

First, I tried querying the destination IP: 40.104.21.66, but found no log records. In my production environment, it appears that no internal user is initiating connections to this Microsoft IP.
However, in reality,  connecting to Outlook will trigger this log entry.
When I queried the source IP: 40.104.21.66, there were log entries—just like the image I previously provided.
The rule name shows: CPNotEnoughDataForRuleMatch, and there are no other logs related to this IP.

I’ve also reviewed SK113479 and looked into similar cases reported by other users in the forums where this rule was triggered.
However, I haven’t seen anyone experiencing the same situation as in my production environment — specifically, an external IP initiating a connection to the firewall’s external interface over port 443.

Based on what I’ve seen from other users and my own lab testing, this CPNotEnoughDataForRuleMatch rule more commonly appears when an internal user connects to a public IP over port 443, and there are usually related logs as well. But in my production environment, the situation appears to be the opposite.

The following image is from my lab environment, and the situation is very similar to what other users have reported in the forums. 

Thank you.

[PhoneBoy]

The reason this message occurs is because the first rule that potentially matches traffic going to the gateway's external IP is an Application Control signature, not a simple TCP service.
Potential match rules are those where a rule contains the source, destination, and service (in the TCP/UDP sense).
Whatever connection is being initiated to the gateway is being terminated before we can determine what rule SHOULD have accepted the traffic.
That's basically what https://support.checkpoint.com/results/sk/sk113479 says, and it's expected behavior.

Why the connection occurs in the first place is a separate question, of course.
Eliminating this type of log entry means modifying the rulebase.