| Firebird Documentation Index → Firebird 2.1 Release Notes → Security |
|
|
|
Table of Contents
In this chapter are details of the changes to Firebird security that came with the release of Firebird 2 and its successors. Further changes and enhancements introduced in V.2.1 are highlighted.
Improving security has had a lot of focus in Firebird 2.0 development. The following is a summary of the major changes.
The new security database is renamed as security2.fdb. Inside, the user
authentication table, where user names and passwords are stored, is now called RDB$USERS.
There is no longer a table named “users” but a new view over RDB$USERS that
is named “USERS”. Through this view, users can change their passwords.
For details of the new database, see New Security Database in the section about authentication later in this chapter.
For instructions on updating previous security databases, refer to the section Dealing with the New Security Database at the end of this chapter.
(V.2.1) From Firebird 2.1 onward, Windows “Trusted User” security can be applied for authenticating Firebird users on a Windows host. The Trusted User's security context is passed to the Firebird server instead of the Firebird user name and password and, if it succeeds, it is used to determine the Firebird security user name.
For details see the section below, Windows Trusted User Security.
Password encryption/decryption now uses a more secure password hash calculation algorithm.
The SYSDBA remains the keeper of the security database. However, users can now modify their own passwords.
gsec now uses the Services API. The server will refuse any access to security2.fdb except through the Services Manager.
Attempts to get access to the server using brute-force techniques on accounts and passwords are now detected and locked out.
Login with password is required from any remote client
Clients making too many wrong login attempts are blocked from further attempts for a period
Support for brute-force attack protection has been included in both the attachment functions of the Firebird API and the Services API. For more details, see Protection from Brute-force Hacking
Several known vulnerabilities in the API have been closed.
It must be noted that the restoration of the server redirection
("multi-hop") capability to Firebird 2 potentially throws up a new vulnerability.
For that reason, it is controlled by a parameter (Redirection) in
firebird.conf, which you should not enable unless you really understand its
implications.
These days, the ability to redirect requests to other servers is dangerous. Suppose you have one
carefully protected firebird server, access to which is possible from the Internet. In a situation where
this server has unrestricted access to your internal LAN, it will work as a gateway for incoming requests
like firebird.your.domain.com:internal_server:/private/database.fdb .
Knowing the name or IP address of some internal server on your LAN is enough for an intruder: he does note even need login access to the external server. Such a gateway easily overrides a firewall that is protecting your LAN from outside attack.
|
| Firebird Documentation Index → Firebird 2.1 Release Notes → Security |