False Sweep and Host Port scans detected when policies are installed

[Diego_dg]

Hello, we have detected on several GWs with sweep and host port scan configured, that, when policies are pushed, scans with source IP the external IP of the GW are detected. This should not be possible, it is configured that only external connections should trigger this protections. We have seen this behaviour on several GWs of different customers, so, maybe it could be a general issue?. Please, has someone detected a similar behaviour? these scans are only detected at the same time policies are being pushed.

[G_W_Albrecht]

I would contact TAC and ask about this !

[Diego_dg]

Hi! yes, I have a TAC case, but without any advance at the moment

[Vladimir]

May be  I am not reading the description of the problem correctly, but I have seen similar behavior that was caused by the upstream routers with incorrect arp cache entries.

Until those were cleared or updated, the logs seem to indicate that there is a massive port scan underway.

[Diego_dg]

Sorry, I think I didn't describe the issue very well.

Host Port Scan and Sweep scan are configured to detect more that 100 inactive ports in 30 seconds, and usually it works fine: when there is a scan, 100 drops can be seen on the log and then the Host Port Scan detection appears. 

But, when policies are pushed, a Sweep Port Scan Detect alert appears on the logs just at the time of the policy installation. It says that the source of the scan is the external IP address of the GW and the service is http and/or https (port 80 and/or 443). Searching on the logs, there is not any drop coming from the external IP addres of the GW before the Sweep scan detection. So, we have not found any reason for this detection to appear.

There is no source NAT on this GW, so, internal IPs are not being hidden behind the external IP of the GW.

[Guido_Pastorino]

same problem!
but it starts after upgrade from R80.40 to R81.10.

sweep scan has as track the User Alert 1, and User Alert 1 is configured to send into SAM rule the source of the detected traffic and drop it for 5 minutes.

this cause that firewall's IP on the interface facing smart certer server will be dropped.

so at any policy install, sweep scan is detected, User Alert 1 is engaged, firewall's IP is added to SAM rule, firewall does not send logs to smart center server for 5 minutes.

there is no way to create an exclusion for firewall's IP addresses...

[Diego_dg]

Yes! this exactly the same issue that we have on several different customers. Exceptions don't work for us too.

Does your GW has also URL filtering and Application Control blades enabled? I don't see the issue on GWs that only have the IPS blade and not the other two, but maybe this is not the reason...

[Guido_Pastorino]

Yes, URL Filtering and Application Control blade are active.

I agree that removing User Alert 1 (with SAM activation) the issue disappears, but, this is the only way to limit sweep scan attach (drop source IP with the SAM rule), without the SAM rule nothing will drop/stop/limit sweep scan.... 

what am I interested in knowing that there is a sweep scan attack in progress if I cannot limit it?

[Guido_Pastorino]

and why my gateway generate by itself a sweep scan?
is it a symptom of some other issue, or is it a behaviour "as design"?
if this is "as design", check point MUST exclude this protection detection when gateway did it!

[Diego_dg]

I think is some kind of bug. Our Sweep Scan and Host Port Scan protections are configured to detect only scans coming from the internet (external), and the external IP address of the GW should never come as source address from the internet.

Apart from that, I don't see on the logs the "more than 100 drops in 30 seconds" that would trigger the sweep scan detection.

[rrbranco]

Do you see CUL messages ?

Perhaps is anything related to ClusterXL Probing mechanism ?

sk171844 - How to troubleshoot the Critical Device "Local Probing" in ClusterXL


CP_R81.10_ClusterXL_AdminGuide.pdf - "probing" 
https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_ClusterXL_AdminGuide/Search....

sk92456 - Traffic loss on different subnets when ClusterXL interface fails back after a failure, or after a cable is reconnected
"...

By design, when a cluster member does not receive CCP packets from a peer member (or not able to send its own CCP packets), cluster member uses probing mechanism in order to determine the problematic interface and the problematic member. All cluster members send series of ARP Requests and series of ICMP Requests to all hosts on the subnet.

...

"

sk92723 - Cluster flapping prevention

"...

• Cluster-member Probing

...

"

sk43984 - Interface flapping when cluster interfaces are connected through several switches

"

...

Pinging IP addresses in an interface's subnet is one of the health checks that ClusterXL mechanism performs (called 'probing').

...

"

[Diego_dg]

Thanks! I will check it.

In the meantime, I noticed that the GW IP address detected as source of the scans is the real external IP address of the active unit (these are active/standby clusters), so I checked for http/https generated by the GW itself and found that the real IP address of the GW is continously connecting to cws.checkpoint.com on akamai. It seems this traffic is related to URL Filtering and Threat Protection (maybe URL categorization updates). Maybe, for some reason, at some point during policy installation, the IPS wrongly detects this traffic as a scan?