- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hello colleagues,
We have been experiencing a massive distributed attack against our Endpoint VPN access over the last few weeks. Login attempts are being made from various source IP addresses. Even known usernames are being used. caseyb describes this attack here https://community.checkpoint.com/t5/General-Topics/R81-20-Jumbo-Hotfix-Accumulator-take-96-has-been-..., which I also see here.
Unfortunately, the technical defense measures are limited, as the attacker tries different user accounts from one IP. We need a solution that blocks failed login attempts with different user accounts from the same IP.
Question to the community: Do you also see failed login attempts in your logs, for example from the IP 138.124.184.205?
Greetings
Juergen
What about using certificate authentication ? Username/PW is rather very old-fashioned...
No, we had that in the past. The administrative effort is too high. Security also depends on how passwords are composed.
I see.
We have not really explored certificate authentication for the Endpoint VPN, I would like to imagine administrative overhead issues with that as well, but I could be mistaken.
We do have MFA on the VPN, so I'm not as concerned.
@Juergen_Blumens how about using SmartEvent ? You can define as an example an action to block the source IP for the next hour.
This is absolutely the right way, though I would lower the number of events and time period in your case. In the automatic reactions section you can block the connections for a time period. The SmartEvent server will then issue a SAM (suspicious activity monitor) block for that time period to all of your gateways. SAM blocks happen before any other inspection (packet sanity checks might occur before, I don't remember.)
If you know the IP does not change, I would use SAM rule to block it, its instant and you dont even need to install policy.
Andy
The problem is that it is a distributed attack from around 60 different IP addresses that are distributed worldwide. It's not easy to detect the attacker in the logs at first, then I have to configure the drop afterwards. Until then, the attacker comes from other IPs. That's why I want to request the new feature from sk182087 not only on a user-specific basis, but also to block the Source IP in the event of several unsuccessful login attempts within a short period of time.
At first I thought this was just an attack against us, but after CaseyB's screenshot I can see that the same attacker is trying it on other Checkpoint firewalls at the same time. Can you take a look on your logs, do you also see failed login attempts from the IP 138.124.184.205?
I understand what you mean. Just checked, dont see anything for that IP for the last year.
Andy
Based on https://support.checkpoint.com/results/sk/sk182087 this behavior is by design.
Specifically: "The main motivation behind not to remember only a public IP address is to avoid collective DoS attacks that might block multiple Remote Access VPN users, who may connect from behind the same NAT device."
You're right about that. However, it should still be possible to select for incorrect login attempts within a narrowly defined period. Real users do not have so many failed attempts.
Hey @Juergen_Blumens
Just curious, does this involve IPs from different countries? Because if so, maybe you can try do geo blocking by using updatable objects.
Andy
Our users are spread all over the world. Even if we exclude countries without our own branch, we could still have travelers there.
The attack against us used dozens of source IP addresses. And they came from several countries. Even large countries were involved.
That really makes it tough then 😞
Seems a reasonable ask...I'll ask R&D about it.
It might also be worth a TAC case.
While I understand the concern, it would be ideal to have the flexibility to just block the IP with multiple failed logins. I would be curious to know the statistics behind that concern, for our end-users, they would have a better chance at winning the lottery than connecting from a network that is also performing a DoS attack against our firewall. I feel like other organizations are in the same boat.
Use this filter to quickly see failed login attempts in the logs:
login NOT blade:"Identity Awareness" AND action:"Failed Log In"
+ uploaded template that you can import in Smartview, it will give an overview of failed logins.
You can change it and also add for example source IP colum, etc.
Unpack the zip and import the file!
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
Wed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksWed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY