Security of backups

As you have seen above anyone, with a valid username and password, can restore a gbak database dump file provided that they are not overwriting an existing database. This means that your precious data can be stolen and used by nefarious characters on their own servers, to create a copy of your database and see what your sales figures, for example, are like.

To try and prevent this from happening, you are advised to take precautions. You should also try and prevent backups from being accidentally overwritten before they have expired. Some precautions you can take are:

• Always set the dump file to be read-only after the backup is complete. This helps prevent the file from being overwritten.
• Alternatively, incorporate the date (and time?) in your backup filenames.
• Keep backups in a safe location on the server. Storing backups in a location with restricted access helps reduce the chances of your backup files 'escaping' into the wild.
• Keep tape copies of your backups very secure. A locked safe or off-site location with good security is advisable. The off-site location will also be of use after a total disaster as the backups are stored in a separate location to the server they are required on.
• Backup to a partition or disk that has encryption enabled.
• Make sure that only authorised staff have access to areas where backups are kept.
• Always test your backups by cloning a database from a recent backup.

In Firebird 2.1, there is an additional security feature built into gbak and all the other command-line utilities. This new feature automatically hides the password if it is supplied on the command line using the -password switch. gbak replaces the password with spaces - one for each character in the password. This prevents other users on the system, who could run the ps command and view your command line and parameters, from viewing any supplied password. In this manner, unauthorised users are unable to obtain the supplied password.

tux> gbak -b -user SYSDBA -passw secret employee /backups/employee.fbk

tux> ps efx| grep -i gba[k]
20724 ... gbak -backup -user SYSDBA -passw employee employee.fbk
... (lots more data here)

You can see from the above that the password doesn't show up under Firebird 2.1 as each character is replaced by a single space. This does mean that it is possible for someone to work out how long the password could be and that might be enough of a clue to a dedicated cracker. Knowing the length of the required password does make things a little easier, so for best results use a random number of spaces between -passw and the actual password. The more difficult you make things for the bad people on your network, the better.