In order to help a client meet a compliance requirement I worked on a project to bring the Watchguard Firewall configuration under the version control.
The client had an existing oxidized installation that was backing up their routers and switches. The missing piece were the Watchguard firewalls.
I found that Watchguard devices were already supported by oxidized, and the only challenge at the time was that the Watchguards run SSH on port 4118, as opposed to default SSH port 22.
I quickly found that this could be addressed in oxidized.conf as follows:
source: default: csv csv: [...] vars_map: ssh_port: 4
and then in the router.db we declare the device in fashion similar to the below snippet:
Unfortunately, having set that up I learned that oxidized could not connect to WatchGuard devices because my client uses the logon disclaimers that had to be accepted by typing “yes”.
This functionality wasn’t implemented in oxidized, so I added the logon disclaimers support, and was really amazed how fast the PR was merged in the upstream.
The last piece of the puzzle was the requirement to run the config retrieval as a non-privileged user (in spirit of the least privilege) so another PR went upstream to implement that.
Now the configs are being properly backed up to oxidized, and the client confirmed that they were able to successfully test the restore of a config from oxidized to a device by simply loading the xml in oxidized into the XTM Policy Manager and saving that to the device.
Here is a screenshot of what it looks like in oxidized:
The client had a failure of one of the their Watchguard firewalls and it was replaced by the vendor. They had loaded the configs from oxidized and found that that the certificates were invalid.
I had opened a case with watchguard for this and it’s been confirmed to me that the command that oxidized uses to retrieve the config (
export config to console), does not backup the following:
* admin/status passwords
* feature keys
Fortunately, the client keeps the certificates in a separate offline repository, so they were able to restore them swiftly, but you’ve been warned.
Here is a quote from my ticket with Watchguard that explains this and the alternative in detail:
When you restore using the Configuration file (.xml file), the password and certificates are not restored. Those are only restored only if you use the backup image (.fxi file).
A backup image is an encrypted and saved copy of the disk image from the Firebox local memory. A Firebox backup image includes:
- Fireware OS
- Configuration file
- Feature keys
You can run a backup image from the CLI (SSH interface) to either a USB or an FTP server:
backup image (password) to [location | usb filename]
Unfortunately, a scheduled backup is not possible, it has to be done manually.