Default implied policy expose SMS services to attackers on internet

[fdhfdshs5454]

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.

[Chillyjim]

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). 

[the_rock]

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

[Duane_Toler]

+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.

[the_rock]

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

[fdhfdshs5454]

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?

[the_rock]

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

[PhoneBoy]

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 

[fdhfdshs5454]

"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."

[fdhfdshs5454]

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...

[Chris_Atkinson]

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?

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/GUI-Cli...

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/Host-Ac...

[fdhfdshs5454]

I did know about "GUI client" but not about "Host access". I just tested and it prevents me to login.

But that's still a lot of bidirectional communications susceptible to vulnerabilities compared to a simple firewall drop.