The configuration of a device can be the most important part of the system. In this video, you’ll learn about production configurations, backup configurations, and baseline configs.
Change is inevitable. And we need to have some type of process on our network to be able to manage all of these changes. There might be updates to operating systems. We may have to patch a series of devices. There might be updates to applications that we need to roll out. And of course, we have network devices, firewall configurations, new applications that need to be installed, and many other changes that will occur on our network.
Instead of simply making a change without any processes or thoughts to what may occur in the future, we need to have a formal process for managing all of these configurations. We need to know when these changes are going to occur. We need to be able to plan for those changes. And we need to inform everyone that the change is going to take place.
This documentation becomes very important if this system needs to be rebuilt, especially if there’s some type of disaster and you’re required to get that system back up and running as quickly as possible. Having some type of documentation on that leads you from the installation of that software through all of the changes that you made will be extremely important in getting that system back up and running.
When we first install a switch, a router, a firewall, and we make our initial configurations and get everything working perfectly, we now have a production configuration. This is the configuration that everyone will use when we roll out a new router. This is the configuration that will be the standard for that production system. When we install a new firewall, we have a standard production configuration for that firewall.
This is not just individual configurations inside the device. But it covers all aspects of changes to that device, including all the hardware and firmware versions, any device driver updates that need to be made, and any updates to the software, especially since there are certain versions of the software that might work better or worse than other versions. This is not something that we would usually install into production to see how it runs. We would usually do extensive testing behind the scenes, make changes to all of these aspects of the system, and then deploy that final configuration into a production environment.
Of course, not every possible scenario can be tested in our lab. So we need to have a plan if something was to happen in production, to be able to revert that back to a previous configuration. In these situations, where something does not go as designed, we need to have some type of backup that we can revert to. This applies to our firewalls, our switches, our routers, our operating systems, and anything else we might be making a change to.
The standard operating procedure is commonly to make a backup of that system before making any type of change. Once you make the change, you can then decide whether that’s something you want to keep in production. But if there’s a problem, you may need to revert back to that previous backup.
Sometimes this can be accomplished by simply copying the files that will be updated during that particular change. It might be a single configuration file. But now, we have a copy of that file prior to those changes taking place. And we can simply copy that file back if there’s any problems.
If this is a virtual machine, this process can be relatively easy. You can click a button to create a snapshot of that VM that saves everything, the files, the configuration, and everything else associated with that VM at that point in time.
If you run into a problem when you’re making a change to the VM, you can then easily revert back to that date and time of the snapshot. This is also useful if later on, you decide you would like to revert back to the previous configuration. You now have a backup that’s stored, either as a snapshot or as separate files that you can then revert to if you run into future problems.
When we’re deploying a new application, it’s usually often more than a single server and a single executable. There are usually many different components that allow that application instance to operate. This might include configurations on the user’s workstations, changes to the firewall, and of course, the application server itself.
To truly understand the scope of this application, we need to document every aspect of that application installation. This allows us to create a golden configuration that certifies that this application will work properly if all of these configurations are in place. We can also use that golden configuration as a way to verify that we are using the proper software and the correct configurations. We can create integrity checks that will compare the configuration running in production with the configuration on our baseline or golden config.
If we find there are changes between those two environments, we can make changes either to the production environment to match the golden config. Or we can update our baseline configuration so that it matches the new configuration in our production environment. Once we make those changes, we now have a new version of our baseline configuration. And we can use that as our integrity check going forward.