backup and restore - why is it so difficult and how can we do it the right way ?

[gmiretzky]

Hi, 

First, please let me say, i have gone over the forum and read many posts about this issue, and i just can't find a recommended solution for CLI backups for my system.

We have some Fortigate firewalls, all are configured with VDOMs and running in a 2 device cluster (some as active/active and the other as active/passive)

Backing up the device should not be so hard. i am trying to log-in to the machine using CLI and running a backup to TFTP operation (Later, i would like also to run an automataed script , but thats the next step)

I created a user for the backup. It has a dedicated admin profile (i dont think it is a good idea to give the backup admin user a super admin permission) When i log in with that user, i cannot run the "config global" command , which makes me wonder : 1) what is the difference between running "execute backup full-configuration" from VDOM menu , and running "execute backup config " from global menu? From where should i execute the backup operation? 2) What is the difference between execute backup config / full-config / all-settings ?

One more thing that i am puzzled about, in a cluster enviurment , should i run the backup from each cluster member ? or can i run it once while connecting to the VIP address?

Final question, what kind of backup should i run in order to be able to fully restore the machine? Should the backup be encrypted in order to fully save the passwords and VPN configuration ? Or can it be without encryption?

It is very strange that fortinet are not providing easy to use backup & restore operation (not talking about scheduling, which is a all other subject) 

Thanks. 

[ede_pfau]

hi,

to clarify:

- "backup config" is the default backup, comparable to the Web GUI backup

- "backup config full-config" saves all configuration parameters, including those at default settings. Which are not saved in a normal backup.

- there are more "exec backup" commands to, for instance, backup user defined IPS signatures

- only if you password protect a backup certificates will be backup up as well (VPN, SSL)

- if you run the backup command as a regular admin, only the VDOM settings are backup up to which this admin account belongs to

- to backup the global settings as well, run the command as a 'super-admin'.

You can automate backups using scp (after enabling it). I use a python script to harvest a bunch of FGTs this way. You can then schedule this script.

HTH.

[gmiretzky]

Hi Ede, 

Thank you for your reply. 

After chat session i had with Fortinet support, i realized that you must be super admin in order to backup the full configuration (all VDOMs + global) 

I dont understand why a backup admin shouldn't have only read permission? This is a user that should have as little permission as possible in order to run backup operations. I sure hope Fortinet will fix this issue soon. 

Can you explain a little more about the SCP configuration option? After configuring SCP backup, how do i know which files i need to copy ? According to the manual, the file is fgt-config , is that the only file?  Will that file be encrypted and allow me to restore the machine? 

What do you think about the cluster? Should i backup each machine separately? or just once using the VIP ?

Can i run the SCP backup on each cluster node? or the SCP will only work using the VIP IP?  

Thanks 

[ede_pfau · Accepted solution]

IMHO ranting about given facts doesn't really help; it's a design decision - FTNT sees the backup and restore operations as being on the same security level, and of course you wouldn't grant anybody except the super-admin the right to restore the config. You can have a different view on this, but that's the way it is in FortiOS.

One more: I do a lot of debugging of FGTs, and usually start off with the config file. There's so much sensitive information in the config file alone that you have to consider it a security risk. Thus, it needs admin priviledges to access.

SCP is simply copying the config via ssh from outside. Combine the scp backup method with RSA key authentication so to avoid specifying cleartext passwords in a script.

Requesting the file 'sys_config' triggers the 'regular' (non-full) backup: "scp -P <ssh-port> -i <keyfile> user@ipaddress:sys_config target".

Not sure about supplying a password to encrypt (as I don't use that at all) but maybe you can find that info on the forums.

clusters:

of course cluster member configs are 99% identical but not 100% (hostname, system ha, system interface). Backing up from the cluster IP backs up from the master unit. You can access the slave unit(s) by configuring their mgmt ports if they have any. As the difference between master and slave unit is literally constant across the lifetime of a cluster you would only need to back the slave up once.

Cluster member access via mgmt address works across WebGUI, ssh and scp all the like.

[gmiretzky]

Hi Ede, 

Wow, thanks for the info. 

I understand your point about the permissions. Maybe my issue is that the write permission is the same as the execute permission, and given the backup user the permission to run other command but backup , is a huge overhead. Never mind, i will do it 

I also agree about the cluster , i never really thought about it like that, only backup the cluster nodes once. Excellent.

once i update the permission of my backup user to super-admin , i will use the execute backup config tftp command to backup the FW. hope it will backup all the VDOMs + system settings.

I will update.

Thanks .

[ede_pfau]

(scratch)if TFTP more secure than scp, or vice versa?

Never mind.

In fact, you only need the difference between the master's and a slave's config to fully configure a new slave (given identical firmware versions). You could well skip all of the rest, the HA integration process will copy it over anyways.

[emnoc]

Why  the super_admin priv is due to "would you want a no super_admin backing up a security appliance " and in the same breath" would you want a non super_admin restoring a security appliance"?

if you think about those two questions and scenarios, than you would understanding why the super_admin.

As far as backup, I believe the fortiOS has done a great job  with the backups/restore. I would like to figure out script backups per vdom.

Ken

[schwit]

Requiring an account that does backups to also have write access violates the security concept of least-privileges. What's needed is a dedicated, read-only account that's capable of doing backups and nothing more.

Restores should be done by a separate super-admin account. Probably the same account used for config changes.

We have a backups group and we are uncomfortable giving them super-admin credentials to our firewalls.