Has anyone implemented sk180808?

[Cypress]

Hello.  I have some gateways that accept traffic to the gateway itself on TCP/443, despite our stealth rule that should be preventing this.  My apologies, as I see this is a frequent topic that is discussed on these forums.

We are looking at sk180808 which was presented to us as a possible solution.  I am wanting to make sure I fully understand the sk article before attempting to implement it.

- The CLI change is done on the management server, and not the gateway.. is that correct?

- The change then takes affect on a gateway after you install policy on that gateway.

-In this sense, we can look at this as a "global" change that affects all of the gateway clusters under this management server.  We may be able to install policy on only one cluster and test things out first.. but one way or another all the other clusters eventually will have to get policy install.

- reverting back, in case the results are not desirable.. would just be setting the value back to "0", cpstop;cpstart, then install policy again?  Or would "revert to previous revision and then install policy" work?

My last question: I'm wondering if there is any recommended reading on more fully understanding the "Multiportal Policy" in general.. I have a rudimentary understanding that if you activate certain different blades and features on Check Point, one or more of those features provision a "portal" interface, that may share the same IP/Port as the portals for other blades/features.. and that is why Implied Rules are used with Multiportal policy.  

What I would like a better understanding about is which features I have enabled that has put us into "multiportal mode?"  Is there a way to see which "portals" are turned on with a gateway?

Thanks for any information!

[the_rock · Accepted solution]

I had done that sk with couple customers before, no issues. One was on R81.10 and other base R81. Yes, you apply it on mgmt and then install policy on the gateway(s). To see which multi portal is there, run mpclient list and to see the status, mpclient status and then whatever portal name is.

Hope that helps.

Andy

[Cypress]

Thank you this is helpful.  Now that I see our multiportal list I have other questions too 🙂  One of mine listed is UserCheck which shows our internal users the "website is blocked" page.  I guess it never occurred to me that is also a multiportal.. Does this mean after implementing sk180808, I may need to come up with an explicit rule in the security policy to allow internal users to still hit usercheck?  or does sk180808 only have impacts for gaia portal?

[the_rock]

Questions are free 😉

Anyway, I never had to change any of that with user check page, but personally, I would ensure it shows as below.

Andy

 

[the_rock]

Btw, happy to test anything you need, I have fully working R81.20 and R82 labs going.

Andy

Have a nice weekend!

[Cypress]

Sorry to bump an old thread.. just as a brief update we finally implemented sk180808 last night on one of our gateway clusters last night.  It successfully blocked the HTTPS from public IPs, but it had an unexpected issue where it broke our Gaia web.  It may be from how we are set up originally.. the fix was I had to go to into the Cluster Object, and change Platform Portal to use port 4434 instead of port 443, and create the explicit allow rule from the firewall admins to use port 4434 instead of 443.. after this gaia web started working again.  

[the_rock]

I believe this is not really a concern in newer jumbo hotfixes for R81.20, as per sk, but yes, my bad, I forgot to mention originally web portla should be on port other than 443 in this case.

Andy