- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
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,
SMS is published on internet using automatic NAT on the SMS object.
We defined firewall policy rules to allow trafic to SMS from some IPs (remotes gateways) and deny it from everywhere else.
Today, we found out some ports are accessible from ANY IP from internet.
So every attacker can bypass our firewall policy rules to access some ports on the SMS.
We are afraid attackers could try to exploit SMS over these ports.
We found several vulnerable customers.
We found logs saying trafic is matching implied rules.
The relevant implied rule seems to be located in "Global Properties" > Firewall > "Accept control connections".
It's a GLOBAL setting that control firewalling for gateway<->SMS trafic, as well as RAVPN_CLIENT->Gateway trafic, as well as S2S VPN IKE trafic, as well as specific CheckPoint "hacks" (need editing user.def) for specific services...
- https://support.checkpoint.com/results/sk/sk179346
- https://support.checkpoint.com/results/sk/sk17745
This setting is enabled by DEFAULT.
We wanted to disable it but are afraid of the impact it might have.
Sk179346 says "Warning - We recommend to configure and use the Implied Rules in SmartConsole and not disable them.".
Indeed, when looking at everything that needs to be done to replace this setting (firewall policy rules, user.def, S2SVPN exluded services...) we are afraid we miss something or something is missing in the SK.
So here are our questions:
1. Does someone here has already done this setup?
2. Does someone knows if these implied rules can be disabled ONLY for the SMS and not GLOBALLY?
3. Does someone knows if there is a way to disable this setting ONLY for MANAGEMENT services and not for VPN related services?
Thank you.
1. Yes
2 & 3, I don't know, but I don't think so.
4. Don't do it. Ask your SE for all the reasons why not to and how to explain them to the auditors.
Seriously, disabling implied rules has always come back to bite me and my customers over the years (and that's a lot of them). All communication over the management ports is encrypted and authenticated (via SIC).
I totally agree with that. I would NOT disable implied rules (ever), UNLESS TAC says it so in email through an official case. I find its way too risky and can lead to really bad problems...been there, done that.
Andy
+1 @Chillyjim
+1 @the_rock
Don't do this. In olden days you could, and get away with it, but now.. don't. I used to disable them myself, but now it's too easy to cause problems fast. Don't do it.
While these ports may be open, the management server is smart enough to not accept full connections from just anywhere for these management services. The server internally checks for valid sources that "should" be connecting to these services. These are also protected by Check Point's "Secure Internal Communication" (SIC) protocol which is a TLS-wrapped connection requiring X.509 certificates. The certificates are issued, and managed, by the management server itself. That's how the server "knows" what should be connecting.
I only ever had 2 customer ask me about it and I told them without any hesitation I would not do it, unless TAC specifies the reason via the case and its 100% clear why we are doing it, thats it.
Luckily, we did not have to do it at tne end. I am with you @Duane_Toler when you say its easy to cause problems now in doing so, absolutely true.
And even worse than that, sometimes coming back from those problems is not as easy as reverting the changes.
Andy
I checked at several customers and there's one that is not "vulnerable", the one that use manual NAT to publish the SMS.
I think these ports are published because of the 1:1 NAT of AutoNAT and they could be "unpublished" using manual NAT.
So I came to this idea to workaround implied rules while keeping AutoNAT:
What do you guys think about it? Could it work? Could it break something?
Personally, I would say its okay to modify those nat rules as a test in maintenance window, but if you plan to modify implied rules, I would 100% check with TAC.
Andy
The Automatic NAT rules are needed if your management is behind NAT and you have gateways you are managing over the Internet.
If you're just concerned about blocking SmartConsole access, you can use rate limiting rules on the relevant gateways.
This doesn't require hacking .def files and will apply before the Implied Rules.
SmartConsole uses TCP ports 18190 and 19009 (and HTTPS).
https://support.checkpoint.com/results/sk/sk112454
"SMS is published on internet using automatic NAT on the SMS object.
We defined firewall policy rules to allow trafic to SMS from some IPs (remotes gateways) and deny it from everywhere else."
What bother me is that anyone can try to login using SmartConsole.
Yes, there is an admin lockout, but customers might disable it (I just checked and guess what...), and there is also weak passwords some customers are using.
Not talking about unknown vulnerabilities and their exploits...
I feel like Check Point rob my customers a security layer.
Edit: Not talking about user "admin" using "OS password" with password max length of 8...
Remember you still have to define GUI client and Host access IP ranges so unless you've made those overly broad what is your concern?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
12 | |
12 | |
11 | |
7 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY