Physical Security - Firebird

Keep servers and sensitive or critical client machines behind well-locked doors. If you have FAT32 partitions on servers or workstations, anyone logging into the machine locally can access anything on them. If possible, lock resources such as CD-ROM, floppy, and Zip drives, and disable ports that can accept bootable devices or set boot options in the BIOS to prevent boot-ups from removable media. Password-protect the BIOS to prevent unauthorized changes to boot options. Password-protect all servers and workstations.

The overriding factor in physical security is to protect these security -sensitive machines from any physical contact by unauthorized hands. All else is to no avail if someone can get to the machine and steal it, or if someone can open the door of the rack room and steal the hard drives attached to the server.

Use Securable Filesystems

Remote database users (client applications) do not need filesystem permissions on databases. However, they do need the appropriate permissions for using external applications to write to and read from external data files that are linked to tables. You can combine operating system permissions and the server’s ExternalFileAccess configuration to limit the risk exposure.

Users of embedded applications, including a local (Classic) connection on POSIX, do need rights to paths, the database file, and other files, such as lock files, logs, external tables, and so on. The same applies to any user account that runs a Firebird server as an application.

Protect the Firebird tree and other directories that are accessed by Firebird using the maximum possible restrictions supported by your operating system and your chosen filesystem.

Don’t store Firebird software files, databases, scripts, backups, or externally accessed data files on FAT32 partitions. On Windows, don’t allow shares to these partitions to ordinary users. Share permissions to NTFS partitions housing Firebird -related files and executables should be as limited as possible. Additionally, the most restrictive possible object permissions should be in force.

Use group accounts in preference to individual accounts. Avoid multi-group membership where possible.

Protect Backups

Back up regularly, and compress backups to transportable media and store them securely off-site.

Don’t leave backup files and database archives lying around the network where network cruisers can find them. A stolen copy of a gbak file can be restored with full visibility on any other Firebird server. That means that if you let me steal a copy of your database or you let me get your gbak file, I can restore it on my server. Because I am SYSDBA, I can open it and see everything.

Some False Assumptions

A couple of false assumptions have been known to gull DBAs into being careless about protecting database or backup files:

  • A file copy is bound to be corrupt, so it is no use to an intruder. Do not assume that a file copy of a running database will be corrupt and unusable. An illicit copy may well prove to be usable, especially if update activity on the database is relatively infrequent, or if the attacker can try copying repeatedly.
  • gbak files are not databases so they are no use to an intruder. Anybody can re-create your database from a copy of your gbak file.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics