Security Management Server exposed to the internet due to implied rule – warning

[imamuzic]

Hi everyone,

I’d like to share an observation that I believe is critical for anyone using a Check Point Security Management Server (SMS), especially in distributed environments where gateways connect to the SMS over the Internet if you enable Static NAT on the Management Server object and you check the box "Apply for Security Gateway control connections".

This is due to implied rules. This often goes unnoticed because implied rules are not shown in the rulebase, and many administrators are unaware that their Management Server is being exposed.

This all together creates a situation where your Management Server is reachable from any IP on the internet.

Is there any option besides disabling "Accept control connections" in Implied policy?

[the_rock]

Wait...are you saying your mgmt if it has public IP is accessible like that by default?

Andy

[imamuzic]

Yes, and we were not aware about this until last night when we observed IPS events trigered by expolit attempts over port 18264 against SMS from the Internet. We have option for static NAT of Management server to be able to accept connections from Azuire gateways over the Internet. We didn't wanted to use Azure VPN gateway or any other 3rd party device to protect this communication as we had a rule on the on premise Internet firewall to allow management traffic only from Azure gateway public IP, but we didn't been aware that Implied rules will override this rule by permitting access from any IP address. We implemented a quick fix with access-list on border router, but this only protects SMS from the Internet, but we are now aware that our SMS is exposed from any extranet segment, because the entire network is protected by Check Point firewalls under the same SMS 🙂 and now obviously we have to redesign access to SMS entirely. 

[the_rock]

That would explain it, so has to be limited access with the actual rules.

Andy

[Lesley]

Hi,

This is considered OK. If you really want to move from implied rules to explicit rules you can follow this SK:

https://support.checkpoint.com/results/sk/sk179346

Here to get better understanding about implied rules and how to log them (if not already one)

https://support.checkpoint.com/results/sk/sk110218

Here an example that 18264 is OK:

Symptoms

• Security scan against port 18264 reveals "Check Point SVN Foundation"

Solution

This server disclosure of "Check Point SVN Foundation" on port 18264 is expected behavior.

Stated in: https://support.checkpoint.com/results/sk/sk99076

Here are the other 2 services documented:

https://support.checkpoint.com/results/sk/sk17745

It is also possible to make explicit rules visible in your normal rulebase. 

[imamuzic]

That is all fine, I was aware of implied rules, but never examined them thoroughly, so wasn't aware that there is 'any' in several source columns.

Anyway, I think this is a poor design from Check Point to have these implied rules hidden on Smart Console and yet highly permissive, because obviously, administrators could easily forget they exist and create a security hole like I did. I would expect to be able to see at a glance all possible rules on my firewall. At least, a warning pop-up message on Smart Console when adding a new gateway and especially when you activate NAT option for SMS informing you that the SMS is possible accessible from any network would bring awareness about the issue. Not good from the company claiming to have the best security that we deserve 😉

[Lesley]

I understand. From my point of view an open port is not a security hole. Could it be abused in the future, yes but for now there are no open CVE's / vulnerabilities possible on those open ports. But if you don't use it I also prefer to close it. 

[imamuzic]

It is not a vulnerability, don't take me literally now because I'm really mad on Check Point right now and obviously not precise in wording, but it is a risk in the same range as having a default admin password on the device exposed on the Internet. If the port is open it means that the exploitation is plausible. So, any kind of open port about which we are unaware is a risk to me. Look, our big Check Point customer which is a bank was woken up last night by SoC because IPS reported that someone is attacking central firewall management from China and this was assumed to be shut according to firewall rules audit, but it is not. Of course, I feel responsible because I neglected implied rules during ruleset design, but just because these rules are hidden. And this is just a tip of an iceberg of issues we had with Check Point (IKEv2, ARP proxy in manual NAT rules, VSX "funny IP" I'm looking at you:) ). It is a 21st century. I deal with firewalls for more then a 2 decades every day on a consultant level (Palo Alto, Cisco and last 5 years with Check Point). The amount of issues and complexity is outrageous here, although it is still a best firewall interface for daily operations and troubleshooting + check point people are great (and these are only reasons we are still partner), but man, such an amount of unnecessary complexity is madness, especially nowadays when network firewalls are almost market commodity.  

[CaseyB]

Having an open port is not in the same realm as exposing a device with default credentials, if it was, you would have been compromised.

[imamuzic]

In a technical way, definitely agree with you, but in financial sector in EU which is highly regulated having an unreported (by audit) open port trough the perimeter firewall towards central firewall management system popping up IPS alarms in the SoC is an issue that must be addressed urgently as the SMS is declared as high value asset and that causes some kind of a panic in C suite guys who are not tech savy enough.

Take a look on IPS logs from the "incident"- it is obviously to us who works with these firewalls that this is a ordinary web vulnerability scan tool in action, but to the SoC team and management this is a incident (although minor) that came trough unreported open communication and they shift blame to the 3rd party auditor and the auditor says "I was asked for firewall rules and didn't noticed that this was open (Tufin tool also does not see Implied rules) as these are some kind of hidden rules. I cannot recommend using these firewalls anymore, because who knows what else they are hiding from you. I never had such an issue with other manufacturers in other banks." This guy tells that to the C level exec who is struggling with hypertension. Then this guy says screw that CP and their tech I will seek another vendor who will cause me less stress or he can blame the partner (me) accusing me that I didn't had enough knowledge to report that to the auditor. Then me as a partner think, OK I will loose the valued customer because Check Point complexity. I will not resell them anymore 🙂 So, you see this is more about political issue for us, not real technical.

My only complaint here is about unnecessary complexity in a security device management. This complexity could be remedied by the Smart Console Policy window showing implied rules together with regular firewall rules in default view or at least having a  warning message that the firewall will allow communication to the SMS from any source by the Implied policy, but that this should not be a concern, similar as described in sk99076.

[PhoneBoy]

Flagging @Tomer_Noy for visibility.
I know there is a larger project going on to simplify several aspects of our management.
Not sure if Implied Rules are part of that effort or not. 

[the_rock]

Personally, I dont think its fair to say that, but just my opinion. Its always our responsibility to make sure access is blocked where its supposed to be.

Andy

[imamuzic]

On, for example, Palo Alto something like this is impossible because all rules are visible to administrator in GUI. Even rules governing communication with Panorama (central firewall management). Actually, you have to create them.

[the_rock]

Been some time since I worked on Panorama, but below rules are set as default on CP.

Andy

[Duane_Toler]

This sort of thing comes up every few years as folks become users of Check Point products, or become more aware of the inner workings.

Communication with all of the Check Point products are secured by their TLS-wrapped connections with certificates issued from the management server's private PKI internal CA.  Various ports must be open to the management server because gateways (and other products) could be, and often are, deployed widely on various external networks.

While these ports are "listening", connections to them are controlled by the application services which will only allow known gateways (or other management products) to establish a connection.  Attempts to further establish a connection (beyond the SYN/SYN-ACK/ACK open port) will fail if the remote host is not a previously-registered host (including remote VPN peers, for gateway implied rules).

Once a port connection is made, the first packet is a TLS negotiation (for management services) and that's where the connection will fail if the host cannot present a valid cryptographically-signed certificate.  For remote VPN peers, IPsec Phase 1 requires the peer IP and shared secret (dynamic peers must use a certificate).

As Lesley noted, a port simply being open means little-to-nothing if a connection cannot be established.

As for seeing the list of implied management rules, this option has been visible in SmartConsole, SmartDashboard, and previous product iterations for over 25 years now.  This is nothing new.  Disabling the implied rules will lead to trouble one day when you forget allow some access, or use a different product feature and not have management access open, or (worse) when someone else has to come behind you to work on something that you've disabled but they don't know about it.  Leave the implied rules as they are (minus some rare exceptions).

For your border router ACLs, you absolutely DO NOT want to do this.  This is completely invisible to you and your security management. Even if you write this on a sticky note attached to your screen, or tattoo it on your arm, you will forget about this one day (or the person who comes in behind you will have no awareness, especially when you take a nice 4-day vacation overseas). 

For your SoC team alerts, this is a Teachable Moment.  They need more insight for the products they are monitoring.  Quantify vs. Qualify.  Hitting the Big Red Button(tm) at 3am for port scans and TLS cipher probes dilutes the value of their service and contributes to desensitization of security alerts.

Be sure you read the product documentation completely, search other posts here on these forums for prior discussions, and (if you have access) search SecureKnowledge for your topic.  You'll almost always find prior discussions in some form.

Your other issues (IKEv2, ARP, etc.) aren't relevant to the implied rules and should be discussed separately.  These likely stem from a lack of product configuration and understanding.  Each vendor has their own quirks and none of them are perfect.  Remember that networking technology is well over 50 years old now, and a lot of tricks and techniques were "made up as we went along".  These tricks tend to become sticky over time and eventually fossilize.

There are some things we wouldn't do today if we had to do them over again (hence some of the jarring changes in cloud networks).  We all know NAT is Evil and we hate it; but 8-bit IP subnets were handed out like Pez in the 1970s and 1980s.  Other vendor disinformation in the late-1990s didn't help matters, either.

For documentation corrections, you can submit feedback for product documentation as either a TAC case or feedback within the documentation's SK article.

Let us know if you still have questions.

[imamuzic]

So, you are actually advising that the SoC ignores these alarms in future instead the product be able to protect itself by simple IP filtering in a recommended and supported way and turning off implied rules is obviously not that way? I mean, I worked with other manufacturers and I know that if you have for example remote access SSL VPN which is usually accompanied with web portal widely exposed on the Internet is a standard nowadays. But on these other vendors either you do not have internal ICA (which is shame) or it is hosted on the perimeter firewall or in a CA reverse proxy mode (even better), so you do not have to expose internal central firewall management system to the wild Internet.

I know this is off topic, but other issues like IKEv2, NAT ARP proxy that I mentioned are something that you do not deal with or even think about it on other vendors (especially Palo). You know, I was thrilled by Check Point 5 years ago, I was even a speaker on a Check Mates conference comparing Palo with Check Point (since I work with Palo since they were a startup) and I found a lot of features where Check Point excels comparing to Palo, but the issues and amount of support cases (for which TAC didn't had a solution right away) I opened to the CP support slowly diminishes advantages over time. As someone who is a passioned presales engineer, I can tell you it is very hard to sell Check Point firewall nowadays and I really like them because of tiny details that out smile on my face (like cpview -t, cpview top connections consuming CPU most, open server, etc, fw ctl zdebug + drop, TCP RST when connection is about to expire - this is a really buggy one). These are wonderful features  other vendors do not have, but on the other hand there is a lot of gotchas on Check Point that requires real dedication to master. That complexity often delays projects. Maybe this was cool years ago, but now when you have other vendors that are more simpler to use it is really hard to sell this one.

[Alex-]

Out of curiosity, which kind of issues did you experience with Proxy ARP and IKEv2? I'm asking because these are the features which I typically didn't have to think much about and would just work. For instance, we migrated a bunch of existing IKEv1 to IKEv2 without a sweat. Proxy ARP was never a real complex issue I could think of, maybe on VSX in specific configurations.

[imamuzic]

Proxy ARP: when you have manual NAT rules that translates source addresses in a subnet directly connected to the firewall, then the firewall does not automatically works as an ARP proxy for these IP addresses. In order to enable proxy ARP there are several options, but we prefer https://support.checkpoint.com/results/sk/sk114395 since we usually migrate big Cisco ASA configurations to Check Point with a lot of conditional NAT rules. The solution works great, but it does not survive upgrade, so you have to take it into account. IKEv2: https://community.checkpoint.com/t5/Remote-Access-VPN/How-do-I-change-the-local-id-for-an-IKEv2-IPse... and after this is solved then this: https://community.checkpoint.com/t5/General-Topics/ESP-packets-are-sourced-from-wrong-interface/m-p/... 

[Duane_Toler]

This may be entering the realm of "splitting hairs", and I expect this won't end in unanimous agreement...

But this looks like it's a matter of differences of interpretation of the same evidence.  Many of us would see this IPS log, with Prevent action, as nothing more newsworthy than a summary report to the customer on the weekly Tuesday 10am review as "the IPS did its job, you're getting value out of your product. next slide, please."

Some may see this as "clearly traffic was being allowed to pass through, necessitating further inspection. please remove this access.".

However, is this newsworthy for a "3am panic attack"?  That's the grey (gray?) area and is a matter of someone's personal preference.  We won't get universal agreement here.  Someone (you?) will need to decide, and perhaps adjust this policy preference as you go along.  This is where a conversation should happen with all parties involved, that will hopefully result in improvements to both policy and response.

I would suggest a larger discussion with the customer to get their take on it.  Explain to them the reality of the situation (IPS did its job, but this service is open, but these are the reasons why).  Suggest the pros and cons of any changes, both short-term and long-term, and get their approval.  I've done this with all of my customers and they've always appreciated the engagement for discussion.  They've always had some useful input that made future situations much easier, and they're often incredibly reasonable, even those in high-stress industries.

Be sure you bring an open and objective-as-possible understanding of the product when you have this discussion.  I've worked with customers who had a terrible opinion of Check Point because the prior admins-in-command didn't have sufficient understanding of the product.  They were using some archaic, rather brute-force, configuration techniques that were unnecessary which complicated matters.  It took a long time to get their mess straightened out, but it eventually happened and opinions have improved.  This was all because of a lack of understanding (I'd use the word "ignorance", but that carries to much negative connotation even though I would mean it as the proper definition, rather than the pejorative it is).

If you're the decision-maker, then be sure you get enough buy-in and backing from any other Powers That Be in case someone else "forgets" things 3 weeks, or 3 years, from now.  Be sure you review all possible mitigation options, such as Geo-IP policy and access rule Geolocation Updatable Objects.  Do you even want automatic NAT for management control connections?  Weigh the options carefully.  "Measure twice, cut once."

However, if you choose to make a major config change, you need to put this on your calendar for 6, or 12, months from now to review this.  A major config change that affects the core fundamentals of the product WILL bite you one day.  Don't lose a hand or finger (or your job!) over this.

All of us here will be glad to help offer some suggestions for any of these items, but we'll need to this to be a more objective discussion.  You're in a vendor-specific forum, too, so you're gonna get vendor-biased responses.  We'll be glad to discuss objective criticisms, however, as these do lead to product improvements.  You're welcome to open a new thread for any of these if you wish, to have a fresh start.

[imamuzic]

I agree with you, IPS did it's job this time, but the customer asks why the solution is designed in a way that SMS must be exposed on the Internet on the firewall. Of course, the system is protected by other means or layers, like certificate authentication and IPS obviously, but IMHO layered authentication should start by blocking unnecessary  communication at the firewall level. Only if firewall needs to allow it, then other measures such as IPS, authentication, etc. provide protection. So, in my opinion Check Point should not design SMS to be exposed in a such a way. Perimeter firewall should be able to control access to it (even if SMS iz NATed).

[the_rock]

Thats the thing, SMS is NOT exposed by default to the Internet. If it has to be, thats another story, that would not be delegated, if you will, by implied rules.

Andy

[the_rock]

Very well said @Duane_Toler 

[PhoneBoy]

If you're doing Site-to-Site VPNs and/or Remote Access with certificates signed by the ICA, then Internet connectivity to the management is actually mandatory (specifically so endpoints can retrieve the CRL from the ICA).
Be aware of this if you're filtering access to it.

[Nik_Bloemers]

As you said in your original post: you manually set NAT enabled on the management server and even saw the check box for 'Apply for control connections'. So it's not open from the web by default, you configured it to be open. You cannot blame Check Point for not reading what that function does when you enable it. It would be the same as creating a NAT rule and then saying 'Oh no now this port is open from the internet! Boo Check Point'. That doesn't seem fair.

Also, in the access control policy, you can click Action -> Implied Rules and you get a complete overview of all implied rules, plus options to set them more granularly.

Furthermore I agree with the assessment of others that an open port in and of itself does not constitute a vulnerability. Without any open ports, the internet would be pretty useless after all 🙂

[the_rock]

I could have not said it better myself, 100% agree.

[Duane_Toler]

Hah, indeed!  But just think how "cool" it would be if every app and protocol had its own form of "secret handshake" .. like some sort of "negotiation" .... oh..

..wait...

i see.   nevermind. 😂

[imamuzic]

Apply for control connections does not imply that this will be wide open. And as I wrote before, I think Implied rules should be clearly visible when you open security policy in Smart Console. I'm not running away from my responsibility. It is like I hit a huge pothole with a car on a road without clear traffic warning sign about it. From my perspective road maintenance service is responsible by not putting a sign and the driver is responsible by nod adopting his driving according to the road conditions. Road maintanance is Check Point and I'm the driver. I used to drive on German Autobahn (firewalls I worked before) and now I have to drive on more demanding roads (Check Point), so I have to be more careful. 

While I agree with you that open ports are necessity on the Internet, I also mean that requirement to expose SMS directly to the Internet to any source address (in order to avoid using 3rd party VPN) is not a clever product design. ICA proxy or kind of SMS proxy should be implemented on perimeter firewall to protect it. Even decades ago we were securing Internet access to important servers with reverse proxies.

[the_rock]

I do agree with you, it would be nice if those rules were visible. I would submit an RFE for that.

Andy

[imamuzic]

RFE just filed 😉

[the_rock]

awesome!