Platform-Based Protection - Firebird

The degree of platform-based protection you are able to apply to your database server installation depends on two general factors: how well the operating system platform and its filesystem can protect your system (software as well as data) and how secure your system has to be. The second may well be prescriptive for choosing the first.

Unless you have overpowering reasons to do otherwise, you should run the Firebird server as a service.

If possible, use a special user account to start the Firebird service. In Firebird 1.5, this is implemented by default on Linux and some other POSIX builds. On Windows, and for Firebird 1.0.x, it will be necessary to set it up yourself.

Restrict Operating System Logins

Require passwords for all logins and disable login caching on Windows servers and workstations. On networks, disable the ability for users and groups to change their own login settings. Require strong passwords. Enforce account lockout on all servers and workstations that connect to databases.

Enforce the use of ordinary accounts for normal work. Restrict root or Administrator logins to administrative sessions. Eliminate “guest,” “world,” and “everyone” accounts.

Monitor failed logins, failures to log out, failed file and program object accesses, failed user privileges, unusual shutdowns, and boot-ups.


Linux, UNIX, and other POSIX-compliant platforms are preferable to Windows when security is a major concern. The technologies for securing these platforms are mature and widely understood by implementers. Filesystem security and trusted access are inherent in design requirements that are determined by public standards. That is not to imply that merely installing a database server on a POSIX-conformant platform is a guarantee of security. It says that the elements needed for setting up secure systems that are reliably secure are present and capable of being implemented.

Microsoft Windows Platforms

Windows server installations are so infamously hard to secure that intense security requirements may simply rule out Windows altogether as a deployment platform for database servers where on-site security expertise and monitoring are not available.

In a lab presentation entitled “Hardening Windows 2000,” network security guru Philip Cox of SystemExperts Corporation begins by outlining “Four Steps to Practical Win2K Security” as follows:

  1. Locate Windows system.
  2. Insert *nix CD.
  3. Reboot.
  4. Follow installation prompts.

Yes, they were words spoken in jest, accompanied by the obligatory “smiley.” Cox’s paper provides a seriously useful outline for system administrators for whom running Windows servers is the only option. He is the primary author of an authoritative and engagingly frank book about Windows server security titled Windows 2000 Security Handbook. Microsoft itself publishes a number of free white papers with detailed, practical instructions for implementing security on its server platforms and keeping abreast of its frequent security patches.

Windows NT/2000 and XP

On Windows NT/2000 or XP systems, services are available to remote clients even when no user is logged in at the server—the correct condition in which to leave an unattended server.

When running as a service, Firebird, like most Windows services, runs under the localsystem account. Localsystem is a built-in account that, on NT 4 and lower server versions, had few powers. On later Windows server platforms, localsystem was vested with an extraordinary level of access privileges for local system resources, including privileges that cannot be granted even to members of the Administrators group.

By contrast, applications are run from regular user accounts and require the user to be logged into the server host. Any standard Windows user can start the Firebird server as an application.

File Protection

On Windows, restricting the directory (folder) locations where database files and server artifacts live and protecting access to them are strongly recommended. Implement both object and share permissions on every file that network users can potentially reach. To be capable of protection, the directories and files must be on NTFS partitions, in trees dedicated to the purpose, and made readable only by a suitably privileged account or group.

When read access is thus restricted, remote clients must connect to the server through the TCP/IP protocol, not through Windows Networking (often referred to as NetBEUI).

Additionally, from Firebird 1.5 onward, you can (and should) restrict the locations from which the server may read database files, by configuring the DatabaseAccess parameter in firebird.conf.

Windows 95/98 and ME

When security is an issue, Windows 95/98 and ME systems should not be considered for use as Firebird hosts. They lack support for either services or file-level security. Anyone with access to the filesystem can readily make a duplicate copy of the database with a file-copying or archiving command, or simply use the GUI features (drag and drop, copy and paste, etc.) to steal a Firebird database.

The Firebird 1.5 feature to configure the DatabaseAccess restriction in firebird.conf is available to these “non-server” platforms. At least it will restrict the directory locations from which the server is allowed to read database files. However, the FAT32 filesystem is open to the world and offers no protection from accidental or malicious overwriting of databases, external function code, or other Firebird-related files.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Firebird Topics