- 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!
Hey everyone,
Just sharing a quick note on running the script from SK182336 to determine if any of your gateways are vulnerable. When running the script, some users have reported an error similar to: "Failed to collect Domains".
If you come across this, just double-check that you have the management server object highlighted when running your script. This error is a little ambiguous, but in SMS environments it may return simply because a gateway was highlighted instead of the management.
Hopefully, this little tidbit will save someone some time.
Regards,
100% true! I tested your theory and thats exactly it.
Andy
Thank you very much for pointing this out and sharing with the community.
We will take this feedback, and try to give a clearer message if we release another version of the script.
Hey
I run the script from the Script repository on a single stand alone management server R81.10 T139, Smart Console R81.10.9600.423
After clicking on details of the Task I get the pop up from Smart console "Requested log record was not found"
Get the same results with "check-for-local-users-with-password-only-authentication-v5" and "VPNcheck_v3"
is this good, bad or indifferent?
In your environment, do you see other logs?
The task running the script creates a log that represents the task's status. It's possible that there is a delay in indexing in your environment, or indexing is deactivated, therefore you cannot open the task details.
I suggest to try a little bit later, or run the script manually by connecting to the Management/Standalone machine's console.
I am getting logs fine
Ran it manually from Home directory, on the management server.
chmod u+x VPNcheck.sh
chmod u+x check-for-local-users-with-password-only-authentication.sh
./VPNcheck.sh
No Local accounts with Password Authentication method found. No further action required.
./check-for-local-users-with-password-only-authentication.sh
No Local accounts with Password Authentication method found. No further action required.
I am asumming that "No Local accounts with Password Authentication method found. No further action required." is a good thing 🙂
You may want to double-check to see if you have the correct script for the the vulnerability check. When I download it from the SK182336 I get a file named "check-for-CVE-2024-24919.sh" not "VPNcheck.sh". The initial scripts released only validated whether or not local users exist with password auth and VPN access, the newer CVE script is running checks to see if the vulnerability is present. (Important Note: it is possible to not have any local users present and still be vulnerable)
Ran that one all good 🙂
still adding the Hot fix regardless, 5 more clusters to go, taking longer to sort out change windows.
Looks at Checkpoint where do I send the bill for my wifes flowers, that is our weekend wrecked.
I just re read this, we have a separate events server, wonders what difference this would make? if any
We found that the script ran succesfully, but a patched R81.00 cluster is identified as vulnerable:
ALERT: Number of vulnerable Remote Access gateway(s) identified: 1
Recommendation: Install Hotfix to mitigate CVE-2024-24919 according to sk182336.
- cluster.name
EDIT: We used the check-for-CVE-2024-24919-v2.zip with check-for-CVE-2024-24919.sh in it.
Hi,
Thank you for the feedback. The script automates checking whether Mobile Access blade (MAB) is activated or the gateway belongs to the Remote Access VPN community. These are the manual instructions we give to customer to check potential vulnerability.
To keep things simple, we did not invoke APIs or scripts to the gateways themselves to see if the HF was installed. The outcome of the script is whether it's important to install the HF.
We will check if we can improve the text to be clearer, in case we release an updated script.
A little bit confusing, but that explains it. Thank you very much!
We just released an updated script that will iterate over potentially vulnerable gateways and will run commands to check for relevant HF or JHF fix installation.
The updated script will no longer mark patched gateways as vulnerable.
Thank you for the community feedback!
Awesome, will test in later and report back.
Andy
Not sure if this is expected (I assume not), but here is what I experienced. Before upgrade of my cluster, it was on R81.20 jumbo 53 and I upgraded to jumbo 65, but I get below when running script from the mgmt for the cve check. I attached 2 screenshots, first worked fine BEFORE the upgrade and 2nd I get the error seen.
Thoughts?
Best,
Andy
Is this a multi-domain environment, or Security Management Server?
On what did you install JHF 65? On the gateway or management server?
The error message seems to indicate a problem in fetching data on the management, so upgrading the gateway/cluster should not have done this.
Can you try again?
Just regular SMS
I even rebooted the mgmt, same issue. Let me install jumbo 65 on the mgmt server, not sure if that will make a difference, but will let you know.
Andy
No joy 😞
I upgraded mgmt to take 65, rebooted, even deleted and re-added the script, exact same problem, except now it shows same for both gateways, not just the backup.
Super odd...
Andy
Anyway @Tomer_Noy , honestly, not a biggie, as they say, I copied the script to the mgmt via winscp and showed correct output. I want to THANK you and everyone else, @FuzzyLogic , @PhoneBoy , @_Val_ , and all the other people (hard to remember everyone now) who worked very hard on this. I know what Val meant when he said recently people are working around the clock for this issue and its most likely true. Super important to be on top of things like this, so I can say we appreciate, and Im sure I speak for others as well.
Best regards mate.
Andy
Output from the lab mgmt:
[Expert@CP-management:0]# cd /var/log/scripts/
[Expert@CP-management:0]# chmod 777 *
[Expert@CP-management:0]# ./check-for-CVE-2024-24919.sh
All gateways are not vulnerable to CVE-2024-24919. No further action required.
[Expert@CP-management:0]#
Just to update quick, @Omer_Kleinstern reached out to me directly about the script, I ended up rebooting the mgmt again, ran it all good. Thanks so much guys, I truly value and am grateful for how quickly you responded and are on top of this
Andy
👍✌️👌
This might be a little ironic @the_rock , but it's possible that the errors you got were not related to installing JHF or rebooting the Management.
The original post in this thread by @FuzzyLogic was to make people aware that they need to select the Management object, otherwise they will get an error "Failed to collect (get) domains". That's the error that you got, so it's highly possible that you simply selected a gateway object when you ran the script, instead of the management.
Thanks @Omer_Kleinstern for pointing out that possibility.
@Tomer_Noy You are 100% CORRECT! Thats exactly what I was doing...layer 8 iussue HAHAHA
Thanks mate!
Andy
The script in sk182336 has gotten an update.
Now, it specifically tells you if the patch is installed or not as part of it's checks.
For gateway types where we cannot check this easily, we identify them and suggest manually checking and confirming if the patch is needed.
If you happen to be running cccd (not enabled by default), the script now tests for this as well.
Maybe not updated yet? Just ran it, but got same as yesterday...
Andy
Not sure if this is expected when running script on standalone?
Andy
I cant seem to find exactly where that setting is...never mind, ended up rebooting, good now, though still does NOT show anything for cccd
Did you explicitly enable cccd?
It's not enabled by default.
Definitely not, its brand new install.
That's why you didn't get anything about cccd then 🙂
lol...I thought even if its disabled it would tell you, but guess not 🙂
Even when enabled, does not seem to matter...
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 | |
4 |
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