How do you rollback an old policy?

[Christian_Benit]

In previous versions, one could open the current policy, make 50 changes and then save it with a different name (usually, firewall.name.date). If there was an unforeseen issue (or management decision), one could rollback easily the old policy by installing the old version where everything was working as expected. How do you handle this situation in R80? I'm not seeing an easy way to save the current policy under another name to have a way to perform change management/revision control and restore it.

[Tomer_Sole · Accepted solution]

With the new server architecture in R80, we wanted to minimize the effect of duplicating all the policies and rules for the sake of revisions. This could make things like "where used" and "manage policies" more complex as the time goes by. There are several ways to rollback changes to a policy:

- You can view all the revisions of the system by going to Manage & Settings --> Revisions. You can log into a read-only mode of each one of the revisions in order to observe the system more deeply. You can also delete all the revisions up to the one selected by pressing the "Purge" button, although this sometimes may be a drastic move.

- When looking at a layer, you can select from the toolbar above it Actions --> History and view the history of changes that were made for this layer. You can then rollback those changes by pressing the "revert" button, however, some operations such as changing objects inside the rules will not be reverted in this case.

- The option which I think that will be the best for you, will be to go to "Installation History" under the "Access Tools" in the bottom part of the left-side navigation. This view shows the occurrences of policy installation per gateway, and it has the option to install an older revision on a gateway without modifying the database in the Management server. I would recommend this as the action to do in case an unexpected problem happens after installing a policy.

[rnbarros]

Hi,

First, congratulations and thank you, for the article...

The option to revert, is disabled for me... Do you have any idea, about this? With another cluster, in the same manager it's working fine...

[bikash]

I guess you don't have the permission. Your user id created in domain user. Other person who have the access they must have multi domain super user and they have the access to revert the revision.

[Christian_Benit]

Thanks Tomer for the details you shared. I found a workaround that seems to work better in my case for now in my lab, and consist in copying the current policy into a new one, then making changes there and pushing it. That way you have an easy rollback anyone not used to this new version can understand and deal with it, but it doesn't seem that you can easily copy the policy.

You can select all the rules and paste them into a brand new policy, unless you have section titles, if you have them, the copy feature doesn't seem to work. Is it possible to include in the next release the ability to copy/duplicate a policy into another ruleset, or at least allow to copy section titles too? My personal opinion is that this is something many companies will require, or at least will be glad to have.

[Tomer_Sole]

What did you think about the Policy Installation History as an alternative to the copying method that you did?

We are aware of this limitation of copying and pasting, and it's going to be fixed in future releases, however we wish to encourage more version-oriented policies versus clones of policies among customers.

[Christian_Benit]

I think that way is of course another quick way to do it, maybe even better if you deal with a break-fix scenario where you need to restore things fast. I didn't particularly like that every time you want to open a policy, it opens up a new read only console, maybe I'm doing something wrong, but I can't open another event in the same console.

I saw many times several pushes during a short period of time (something that was missing, or a typo, or because there was some troubleshooting in real time) and it might be a little harder to review every change this way, or knowing exactly which version was the "base policy", just my experience. I have one last question, you mentioned future releases, is there a date for that? I know R80 was just released, but maybe there is a R80.1 expected soon. Just wondering. Thank you for your help!

[Tomer_Sole]

Hotfixes will be releases monthly/quarterly with stability fixes. Currently, the next hotfixes address minor fixes, nothing that is greatly noticeable at the moment. R80.10 / R80.20 / R81 are scheduled for later this year / next year. I cannot currently commit on features per release on those.

[Maarten_Sjouw]

Instead of using copy/paste, why don't you just clone the policy? That's the same function as Save-As in R77.30:

[M_Ruszkowski]

Hi,  I see that this thread is a little old, but I wanted to see if Check Point is making any progress in getting this resolved.  It was mentioned above that this feature would be fixed on the next release.  Well when is that?

The ability to fully roll-back the entire database to the previous know good, is critical for us.  We happen to schedule what we deem as high risk changes such as deletes on a special weekend change window.  We always make a revision before performing large policy cleanups.  This way in the event that if something goes wrong we can easily roll-back the entire policy and install.  it was mentioned above from customer feedback that the use case would be to push the last policy and then go back and correct the few changes that caused the issue instead of fully rolling back the everything.  So I am not sure what type of customers you are pulling you feedback from, but I really think Check Point should broaden their scope of customers for feedback and question such a major change.  It seems to me that Check Point doesn't fully understand how their customers use their products.  Or how customers wrap internal processes and controls around certain features.

So for us and our Risk culture this feature is a must.  So here is my feedback...Put it back in!

[Tomer_Sole]

Hi Michael, thank you for this feedback. There is an ongoing work for supporting full rollbacks in the next releases, unfortunately with no verified target release that can be disclosed at this moment.

With R80 being the most major change that the Security Management Server has ever had, every feature was validated against a broad range of customers from different sizes and sectors. Especially something as major as revision management. But this doesn't mean that decisions can't be changed. So thank you for this suggestion.

Are you suggesting that you may have a case in which you delete objects and rules that seem to be not in use, install the policy, and realize that those many objects should be brought back? Did I get it right?

[Sebastien_Rho]

Hi Tomer, since there is ongoing work for supporting full rollbacks in the next releases, where are we 2 years later than that post on that matter, I would like to know where we stand on this.

You can contact me offline if you want.

Thanks

[Tomer_Sole]

Hi Sebastien,

We continue to recommend to run the Gateway-level revert by clicking "install previous revision" from the "Policy Installation History". This makes the Security Management Server silently log into that previous Management revision, collect all the data from it - including rules, objects, gateway settings, topology etc., and install that policy on the Gateway. This is a one-click revert on the gateway side. It then buys the administrator time to understand the root cause of his Management state and fix it manually.

We have an individual rollback button for IPS.

The "Revert" button, as seen at the Layer History page, only reverts rule add/remove/picking/unpicking objects in rules, and not the object operations themselves, therefore it is only recommended if the administrator is OK with these limitations. Since in most cases a rule change also consists of an object property change, it is reasonable not to use that option so frequently. The "Install previous revision" from "Policy Installation History" might be better in these cases.

At Check Point we are committed to preserving the integrity of our customer's data. This is why R80 added cross-object validations, protection of Check Point content, server-side auto-save, and granular permission profiles.

We are taking the time to introduce more features for revision rollback and will introduce them after they get the proper internal certifications. As long as they are not yet added to the release, we recommend our customers to rely on the Install Previous Revision, in addition to enjoying the operational efficiency and reliability features that we added to R80 and above.

[ilkay_akgul1]

hi Tomer,

i want just know, what is the difference between "Layer History(Action->History)" and "Installation History".

Because, i dont see all revisions under "Action->History".

Thanks a lot

[Peter_Lyndley]

Hi Tomer and all,

Is there any progress on this BIG issue for us MSPs.

e.g We are upgrading a customer from a single device to an HA cluster. We want to be able to roll back the MANAGEMENT policy, objects, rules etc

Pushing an old policy to the old gateway using Insatllation History is fine to get it up and running but how are we then meant to revert the policy to be able to move forward ? (revert to old object, all the attached policy targets etc etc)

e.g We are doing a big rulebase/database tidyup - deleting old objects.... something goes badly wrong... yes we can revert the gateway policy but how do we restore the whole policy/objects/rules/nats ?

We cannot rely on mgmt_cli or audit logs to revert a large change... it is simply not feasible.

Any update appreciated

Peter

[Jelle_Hazenberg]

Hi,

Seeing your question here i think your only solution would be a migrate export/import. This is how we prepare for "BIG" migrations.

Regards,

Jelle

[HristoGrigorov]

I just want to remind you of an usability issue when you want to view audit log for a certain revision. Because it is using log template for that it will inherit current time frame setting from it and if your revision is for say the previous day but the time frame is  set to Last Hour you won't be able to see changes. It is very annoying and I hope it gets fixed at some point.

[Timothy_Hall · Accepted solution]

Just to update this very old thread, the new "Revert to this revision" feature added in R80.40 allows full rollbacks of the configuration.  See Part 5 of my article here:

https://community.checkpoint.com/t5/Policy-Management/R80-Change-Control-A-Visual-Guide/m-p/39702