Hello everyone, first of all excuse me for click-bait title - stay with me!
We are long-time Check Point users and are pretty happy with the solutions they provide.
However, this specific point bothers us a lot, especially my management.
Some Background
We are a big institution (50k users) and at the edge (internet facing) we use a cluster of CP 16000-T with all the Next-Gen blade activated (currently in R80.30 last JHF).
The specitify that we have compared to some other clients might be that we own, for historical reasons, a full /16 of IPv4 public address (+ some other ranges aswel), and also a /29 of public IPv6 address (we are considered a Local Internet Registry depending on RIPE-NCC).
As everyone, we are constanly scanned by a sh**load of bots in the world. But with that much public IPs, this can represent a HUGE number of con/sec and thus might as some point be considered as small (D)DoS, especially for internal firewalls (about ~50) which are way smaller.
In addition of security concerns that it repesents, it can actually break stuff.
So obviously, this kind of basic attacks/scans/dos are expected to be blocked right at the edge by our 16000-T cluster.
The main type of attack concerned here is "Sweep Scans".
The issue
Before using Check Point at the edge, we had some Palo Alto firewalls for 10 years that were doing this job perfectly (with the Zone Protection feature).
We also had at some point some Fortinet firewalls which were also doing the job (DDoS policies).
However, with Check Point, it looks like to me that is simply impossible to block these type of scans.
I already did post a message 2 years back with the details of the investigation at this time, but I have new information since then : https://community.checkpoint.com/t5/Threat-Prevention/IPS-Sweep-Scan-issue-a-LOT-of-scans-are-not-be...
First of all, the IPS signature for Sweep Scans can only be configured in "Detect" Mode, not Prevent.
There is an SK (sk110873) explaining how handle this by configuring custom User Alert combined with sam_alert to generate a SAM rule and block the source IP of a given scan.
To further improve this, we did configure the Penalty Box for this malicious source IP to be dropped ASAP and not consume unnecessary ressources on the gateways.
Looks complicated compared to the other major players (PA, Forti), but whatever : looks good for us.
Except that... it doesn't work.
Some scans were blocked correctly using this method, but the vast majority were still accepted and reaching the internal network.
A case was of course opened : 6-0001785477
The case was handled correctly, we had a lot of contact with R&D, but the conclusion was the Good Old "it's working by design" (not blaming, everyone does that ;-)).
Here is what R&D told us after some code reviews :
[...]
Following R&D investigation and testing the 'Sweep Scan' protection, The Design is as follows:
1. The protection is not designed for blocking Sweep Scan malicious IPs. It has the setting of 'detect / accept' or 'inactive'.
2. The protection will count attempts for certain port only until it reaches the threshold defined in the protection. After that, Until the timeout will expire it will not proceed counting additional sources attempting to attack same port (even if different destinations).
3. The protection will count each source reaching 5% or above the defined threshold, until the accumulated threshold has been reached. After that, Until the timeout will expire it will not proceed counting additional sources attempting to attack same port (even if different destinations).
4. Additional sources from point 2 will be displayed in the ‘more sources’ field in the logs.
[...]
The important thing to note here is point n° 4.
If multiple sources do scans on the same dst.port, only the first one will get his "own log entry", thus triggering the custom User Alert, then triggering the SAM Rule and ultimately ending in the Penalty Box.
The following sources are simply being added in the same log entry under a "More sources" field, but these ones will never generate any alert/sam_rules and will never get blocked.
In our case, this is a huge issue.
The scans are sometimes that huge that it might break things, and by not being blocked properly (for example by ending in the Penalty Box) it basically consumes up to 20% on the 16000-T CPUs (!!!).
I'am pretty sure if it was handled correctly that wouldn't even be noticed (again please remember that this is working perfectly with all the other major players).
An RFE was opened back at that time, but nothing moved since then.
I'am still being told that I'am the only client to ask for such feature (again, I'am used to hear that with every vendors... :-)).
How could it be possible that no one faces that?
The conclusion
So what we had to do to protect the edge Check Point gateways (sad to say that this way...) is installing a Snort and spanning all the edge trafic to it.
When the Snort detects too much scanning from a source IP it blocks it on some Cisco edge router (with some scripts to maintain this list correctly).
My management is asking me time to time why we have to maintain an Open Source Snort after spending triple digits thousands € on a pro' solution. For once, I'am kind of aligned with what they ask.
They are of course very aware that we didn't have a single issue regarding this for the 15 years before using Check Point NGFWs, neither with PA nor Forti.
So, what are you all thinking about that?
I'am especially interested in the forums experts and Check Point interns point of view.
Don't you think that Check Point firewalls misses a piece of Unified-Infinity-EasyToUse protection regarding Scans and DoS?
Every other vendors does support <10clicks config to handle that : PA, Forti, Cisco, and even some Open Source software like Snort.
Is there ANY possibility that I could have missed to handle this correctly on my gateways?
Is there any improvements coming regarding this?
Again, I might look angry and sarcastic but I'am NOT (well, maybe just a bit 😋).
I'am really doing that in an improvement optic (either on my side or CP's side).
.png "Wolfgang"){kind=avatar}
