As mentioned in the article Revisions Management in R80.x, I do have an informal writeup I use when teaching CCSA R80.10 that helps summarize how R80+ Change Control and Revisions are handled for the inevitable questions that arise in class. This document is a sprucing up of those notes complete with some new screenshots.
Absolutely no way this document would have been possible without the incredible contributions of Tomer Sole and in particular these articles with content contributed by him:
What follows is merely a roll-up of Tomer's content from an operational perspective, with some new screenshots I have put together. I hope you find it useful.
Part 1: What are you about to do?
You are in the process of making changes in the SmartConsole and are unsure (or have lost track of) what you have done due to one of your coworkers constantly interrupting you. If still in an unpublished session, you can see what changes are pending by enabling the Session Pane (only available in R80.10+ management) like this:
This will create a new pane on the far right of the SmartConsole where you can see pending unpublished changes:
This information can be very helpful when deciding to publish or discard a session. Another way to find pending unpublished rule changes in your current session is to look for "Edited" Access Control rules, indicated by default using a purple line in the Smart Scrollbar:
Note that the colored lines in the Smart Scrollbar will also by default show rule locks currently held by other administrators (dark grey) and search results (yellow) by default. You can even make section titles (light grey) and a selected/highlighted rule (blue) show up as well:
For more information about the Smart Scrollbar and some other great tips for efficiently navigating a large rulebase in the SmartConsole, see this post:
So you have now published your session and think you are ready to install policy to the gateway. A very good habit to get into prior to installation is looking at how many changes you are about to make:
Along the top of the screen, you should ALWAYS look at how many sessions and by how many administrators will be part of what you are about to deploy on the gateway. Note that this is the total number of changes made in the SMS config since policy was last installed to this particular gateway, and not every change counted here is necessarily part of this gateway's security configuration or will impact how it operates. If you see sessions and changes that are unfamiliar or unexpected though, it is a very good idea to hit the View Changes button to see exactly what will be included:
Along the top of the screen is a summary of all the different published sessions whose changes will be included if you install policy to the gateway. As shown above you can highlight one of those sessions, and then select the Audit Logs tab to see a very detailed list of exactly what changes were made in that particular highlighted session.
Let's assume that everything looks OK and you proceed to install policy to the gateway.
Part 2: The Panic Button
Your phone is ringing nonstop, people are pounding on your door, and it has all gone horribly wrong! Some very bad change got implemented when you pushed policy to the gateway at the end of the last section and it is impacting production traffic. You need to fix what you did RIGHT NOW. Thankfully the Installation History screen will be your savior in this case:
The first Installation Date shown above (1/15/2018) represents the most recent policy push (which is probably what messed everything up), just highlight one of the older installations below it, then click Install Specific Version like this:
When you hit Install, a previously installed known-good copy of the firewall policy will be installed and hopefully undo whatever bad change was installed to the gateway. Note that doing this does not change any configurations shown to you in the SmartConsole, it ONLY changes what is installed on the gateway back to a good config that was previously installed. If you hit the Install Specific Version "panic button", install the older policy to the gateway, then reinstall the current security policy again, you will be right back in the "panic" situation again!
So hopefully you have been able to halt the endless door pounding and phone ringing by hitting the "panic" button as shown. You have bought yourself some time to now figure what boneheaded change was made by one of your coworkers (or you!) that caused this unfortunate situation to occur.
Part 3: The Investigation
While the Installation History screen is typically associated with "panic" reverts of gateway policies as shown in the last section, the View Installed Changes button on that same screen can be very handy for examining the specific changes in a suspect revision that came after the one you reverted to in the prior section:
To see even more information about a certain session, hit the View button which will bring up a read-only copy of the SmartConsole showing the exact state of the configuration after that particular highlighted session was published:
By this time you may have some suspicions that a certain policy layer and its rules may have been changed in a way that caused the "panic" situation to occur. If so select the policy layer in question, then select Actions...History:
A nice concise list of all changes made in that policy layer in the various sessions is presented. If you want to see the history of only a specific rule that you suspect is the culprit, simply highlight the rule and click its History tab:
You can also view all changes on the screen below if you aren't sure exactly where to look:
Suppose you have now identified a specific policy layer that was messed with and caused the panic situation to occur. If there were a multitude of changes made and you don't want to manually back all of them out, you can Revert the policy layer configuration back to a specific point in time, thus discarding the changes made in one or more revisions like this:
In our example above we will be removing (or undo'ing) a total of 5 changes made in the two published sessions just above the one we selected.
Part 4: Your Final Option
If you still can't determine what changes caused the problem, your last ditch effort is to look at the raw system-wide Audit logs like this:
This technique was also possible in R77.30 with the Audit/Management tab of the SmartView Tracker. The SmartWorkflow product also has some nice change reports in that version.
Hopefully you found this writeup useful, please let me know if you have any other change control techniques that were missed and I'll be happy to add them. Thanks again to Tomer Sole!
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com