Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
JulzorenSen
Contributor

IPS Sweep Scan issue : a LOT of scans are not being detected

Hi guys,

 

We replaced some Palo Alto FWs by Check Point FWs and are currently struggling with the IPS protections detecting Sweep Scans and Host Port Scans.

 

We see a LOT (I mean sometimes 100k syn/sec from a single source) not being detected.

 

The IPS protections are enabled, configured as "Accept" (because... We can not prevent scans directly from here) and followed the SK110873 to generate a User Alert when the Scans are seens and apply the relevant SAM rule to block the source IP of the scan. When this SAM rules is "hit" enough, the source IP ends up in the Penalty Box.

 

First of all, why is that so complicated to block a simple scan? This is a simple checkbox on either Palo Alto, Fortinet, Cisco, WatchGuard or even some non-serious firewalls vendors..

 

However, it works, but (of course) only when the scan is detected in the first place.

 

A lot of scans (which can be considered as (D)DoS depending on the point of view) which were blocked before are NOT blocked anymore. We've put the Sweep Scan threshold to 20 inactive ports/10 sec right now, and sometimes we can see Scans not being detected as up as few thoushands SYN per sec.

 

We can even reproduce the issue by ourselves with an external serveur using HPING3, and we noticed the following :

  • With random ports >1024, we are most of the time detected, blocked and banned for 10 min by the Penalty Box
  • With ports likes SSH, HTTP or HTTPS, the scans are NEVER detected nor seen in the logs, thus the scans can continue indefinitely, reach the SYNATK threshold and generate a lot of other issue.

We still have our Palo Alto's and also a Snort in trafic mirroring with a SPAN, everything is instantly detected by both of them.

 

And on a global scale, every scan that we can confirm (with Wireshark, Netflow, and other automated tools) are correctly seen by the PAs and Snort, but the CheckPoint misses a lot of them.

 

We have a lot of public IPs here (almost 100k) and scans are a BIG deal for us.

We need to figure this why this doesn't work and address the issue asap...

 

Any help would be appreciated.

 

EDIT : version is R80.30 3.10 JHF Take 50 for everything (Mgmt server + FW cluster of 16000T)

0 Kudos
4 Replies
G_W_Albrecht
Legend
Legend

I would suggest you better involve TAC as well as the local SE here !

CCSE CCTE CCSM SMB Specialist
0 Kudos
JulzorenSen
Contributor

Local SE is already informed and there is a TAC case opened 😉

 

But in the mean time, I'll also want some feedback from other customers : it always help.

0 Kudos
Benedikt_Weissl
Advisor

I think the keyword in the description of "Host Port Scan" is "inactive", i.e. ports with no listener. Thats why you see an alert if you scan random ports but not with well known ports. Are the protections for other scans active?


Maybe "Accelerated SYN Defender" or "SYN Attack" (sk120476) is what you are looking for.

0 Kudos
JulzorenSen
Contributor

Hi,

 

Thank you for you reply.

I'am well aware about the "inactive" ports, this is what we are looking for.

 

When I reproduce the issue, I'am scanning a full /24 of public IP address that aren't even routed inside our network, so all ports are inactives. The Sweep Scan and/or Host Port Scan should be detected there, no matter what. They are detected either with Palo Alto and Snort. We also had FortiNet fws at a time and they were doing the job aswell.

 

About Synatk, it is of course configured. But as stated in sk120476, this can have (and DO have) some side-effect when being enabled (I mean, when being under attack and enforcing). This is actually our problem.

 

The scans should be Detected (which I repeat, is the problematic part), the SAM rule should be generated to block the source IP, and if the source IP is matching the SAM rule at a predefined rate, it should ends in the Penalty Box (in this case for 10 min).

 

With this model, the SYNATK feature should activate itself in last resort, only when it's a massively distributed DDoS in which a single source IP is not generating enough trafic to be "blacklisted" by the IPS.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events