![]() |
IBPhoenix Development |
![]() ![]() |
Securing your Firebird/InterBase Installation |
By Mark O'Donohue 21st January 2001OverviewFirebird/InterBase works in three modes, direct file access, classic client server and the more recent superserver model. Before we look at security it is important to determine which mode or modes you are going to use and allow Firebird/InterBase to be used. In the following discussion I use the term "Firebird/InterBase system files" these refer to the files such as the user database isc4.gdb, isc_event1.<hostname>, isc_init1.<hostname> and isc_lock1.<hostname> all of which in the Linux world are generally found in /opt/interbase. It should be borne in mind that this discussion is primarily aimed at Linux/Unix platforms, although most of the material will also be relevant to Win32. Direct File AccessThe most efficient method is direct file access to the database file, in this mode the database access engine runs with the privileges of the current user executing the program. A by-product of the direct access approach is that the running user has to have read and write access to all the Firebird/InterBase system files and to the database. Classic ServerThe Firebird/InterBase Classic Server registers itself as a unix service, each client process that makes a network connection to the server machine using port 3050 forks off its own child server process (in some cases running under the unix uid/gid of the requesting client process). Each spawned server process services requests from one specific remote client. A single server machine can support many separate client processes, by creating separate processes each of which run concurrently (multitasking). All of the unix user names used on the server processes (including those forked processes running as their own unix users) need to have access to FB/IB system files. Depending upon the number and variety of your users that could be one person, a few - perhaps enough to put into a unix group or it could be everyone. The bottom line is that all of the unix users under which the server process (and its setuid child processes) will run have to have read and write access to the sensitive FB/IB system files. This is currently the model I run on Linux and is also considered the most simple and stable in a Unix environment, since it has been around for quite a while. (It is also possible to use both classic server access and direct access modes at the same time, say remote users, and some server tasks connecting directly. The locking and other contention issues will be automatically managed by the database engine). SuperServerMore recently a multi-threaded architecture has been implemented where all of the separate server tasks share the same address space, and where possible multiple threads can be used in a single client request. In this mode the server runs as a privileged user (usually as either a root/firebird/interbase or interbas user) and only that privileged user needs to have access to the Firebird/Interbase system files. SuperServer has been around since v4.2 in the win32 environment. It has been available since V5 under Solaris, but has only been available under Linux since InterBase V6.0. Configuration SuggestionsThe following suggestions apply mainly to both the server versions of Firebird (classic and super) . Here's my recommendation list so far: 1. Ensure UDF definitions can only be made by trusted users.
2. Ensure that tables that map to files can only be made by trusted users.
3. Ensure that machines that run the client processes are trusted, and that every user with access to the client machine is trusted.
4. If running a web server or n-tier application process then ensure that non empty username/ password are enforced.
5. The specific locksmith user problems and qatest problems have been removed via patch or new version.
6. Don't run server as root user.
7. Change the sysdba password from it's default value.
8. Passwords are restricted to 8 chars so are susceptible to brute force attack. Ensure isc4.gdb is only visible to appropriate users and put a procedure in place to monitor and lockout repeated logon attempts.
9. Change passwords regularly and keep them secure.
10. Restrict client <-> server network communication to trusted network.
11. Keep the server behind a firewall.
12. Keep the CLIENT process behind a firewall.
13. Buffer Overruns - Checking lengths of user entered fields.
14. Restrict access to system files for direct connect mode to the runtime users.
So what can be considered secure?For instance - a web server that connect to the FB/IB server, where the database server and the web server are pretty well protected using firewalls and the web server is locked down, is quite likely to be secure, particularly if your web server code (asp or jsp) checks the length of code variables passed into the FB/IB client software (perhaps even by checking the length of the resulting sql statement). Here the potential for exploitation is fairly minimal. If you are running FB/IB behind a firewall on a local network with one (or more) servers and many client user machines then you need to trust those local lan users that they will at least run the client software as expected. Simple things like tracing all the database ip traffic is likely to give you some sensitive user information, and the potential exists for someone to send a bucket load of rubbish down the 3050 port to try and kill the server or try some buffer overflow exploit. This is pretty much the state of play for a lot of local lan applications at the moment, so FireBird/Interbase is not alone there (this is not an excuse mind you, and there is certainly room for improvement). Solutions and ImprovementsMuch can be done to improve the security aspects of FB/IB, these are however a topic for another discussion. Many of the smaller issues, such as upgrading the password hash algorithm (it should probably now be SHA1 or MD5 of the string "salt+ username + password"), and making the default installation on Linux not one that runs as unix root user, are fairly easy and need to picked up fairly soon. The big picture issue here, relating to user authentication and secure client-server communication is not unique, and many good solutions already exist in other opensource projects. My preference is to use a Public Key Infrastructure (PKI) solution for authentication and SSL where appropriate for secure communications. Fortunately most of this is available in the OPENSSL project, and even more fortunately some of us have some coding experience with it's predecessor project SSLEAY. In ConclusionAt Firebird the security audit continues, but we believe that we have fairly clear design solutions to the current limitations/problems that will make Firebird a more secure and robust product suitable for use in the untrusted internet world of today. However it will be a while before all of this work can be done, since we are all here in our spare time, and have our day jobs and real lives to contend with as well. In addition, aided by the recent problems, it is likely some of the script kiddies will be now looking through the code, and it's safer to assume they will find any exploits in the areas mentioned above. So until we finish it is important that people that are going to use FB/IB have good information about how to set up and run their installation securely. In addition to the points suggested here, and looking at the documentation available, it is probably a good time to keep an eye on a few extra newsgroups/newslists and sites, for a while anyway, since if any further information is found it is likely to first appear in these newsgroups. Firebird-devel and ib-architect are no longer available through the mers newsserver although we hope to find an alternative news-server soon. Any further problems we (at Firebird) find are likely to flow through the same information path as the previous problem. This includes notifying Borland, notifying CERT (IBPhoenix will be aware of it since Ann Harrison is on the Firebird project) and participating in producing a patch/update for the problem. I have no idea how Borland or IBPhoenix will respond to a future security alert, but suspect that the recent alert is probably a good guide and hopefully lessons have also been learnt. So joining CERT or monitoring some technical FB/IB newsgroups is a good idea. If it is critical you get the information ASAP then establishing a relationship with IBPhoenix (or possibly Borland) is also a good idea. |