> Thank you for all the responses, I figure I have alot of work to be

done this weekend, to "tidy" up all the loose ends on my side.

>
> Johan Fourie
> <http://www.cq.co.za>

Johan,

Assuming you have already read Geoff Worboys paper, here are some
ideas, I might get around to documenting all this at some time. The
following is really windows specific because that is my experience,
but most of the concepts are just as relevant to a linux install.

Firebird can be made as secure as most other databases are. There are
a number of things that are meant by secure.

1. How to prevent unauthorised access to data
2. How to prevent unauthorised use of database resources
3. How to protect data "over the wire" from packet sniffers etc
4. How to audit activity within the database (who did what when and why)
5. How to prevent nosey users from snooping around
6. How to protect internal data from eyes of dbas etc.

Most people only think of problem 1. They mistakenly think that their
database is bullet proof because it contains some mechanism to prevent
unauthorised access to the data.

Security is relative to the data you are trying to protect. Obviously
it is more of a problem when the data contained is something that
hackers (or people who would employ hackers) care about, so some of
these suggestions are overkill for some situations.

Must Haves:

1. An OS with reasonable security. That means NOT Win95/98/ME. I
personally recommend either a Linux server or win2003 server.

2. Running on trusted hardware. Unless the volume itself is encrypted,
it is quite easy to turn off the database server and mount any FAT32,
NTFS or EXT3 Filesystem on another computer and physically copy the
database file(s) to another machine. If using windows, you can use
Terminal Services to host your customers database on a server not
physically present at the "untrustable" sites.

3. NOT embedded. Firebird Embedded server is great for databases where
security is no issue, but it disregards the passwords so any user can
connect as SYSDBA making it a poor choice for sensitive data. Use
Classic or SuperServer.

4. Firewall. The only port that needs to be open to connect to a
Firebird server is 3050 (or whatever you change this to). A better
solution though is to use an n-tier architecture, and have a data
abstraction layer sitting on the database server. This way, you do not
have to have Firebird listening to the internet. If you do not have a
choice and must listen on the internet, then only allow connections
from known domains. We deliver our program over terminal services, so
we only need 3389 open for the rdp client, no remote access to Firebird.

5. File System security. Disable all access to all users (including
backup operators) to the folder that contains your fdb file(s). There
is no "safe" way to do a file system copy of a fdb that is in use, so
there is no reason that any user needs access to this folder. Assuming
that Firebird is running as a particular user, then grant that user
full access to this folder (obviously). Also, do the same with the
firebird folder itself, except you may want to allow some users
permissions to aliases.conf and the udf folder. The reason this works
is simple. Unlike desktop databases, Firebird is like a mediator
between the users and the database file. With say Paradox, if a user
wanted to insert a record, the user would open the file that table was
in, do whatever was required to insert a record, save the changes and
close the file. Firebird works differently, instead, the user asks
Firebird to insert the record, and Firebird does it on their behalf.
Therefore the user can insert records etc into a database for which
they have no file system access. This is good. It also means they can
not "rename" the security database which is one your your concerns.

6. If using Terminal Services, you can set an environment program.
This launches a particular program instead of explorer, and when that
program exits, the user is automatically logged off. Remember, the
less the user is able to "stuff around", the less likely your system
will be compromised. Be careful though as the users still have access
to task manager through ctrl alt del or ctrl shift esc, and from there
they can launch whatever program they have permissions to. We have a
group set up to deny permissions to the database folders (point 5)
that all of our users are a part of. That group also has deny execute
to things like taskmgr, mmc, explorer, iexplore, regedit, cmd and a
couple of others that escape me just now. The long and the short is
that the users can only run what I say they can run, which is a far
better place to start with security.

7. Use aliases. The less the hacker knows about your file system, the
harder their job will be.

Now we are up to problem 2

"2. How to prevent unauthorised use of database resources"
(in case you forgot)

In short, unless you specifically prevent arbitrary user defined SQL
from being run, you have no chance. The user can insert records until
the volume runs out of space, or run a really poor select causing
massive resources to be allocated and starving the real users from
CPU, memory and bandwidth.

The easiest way to control this is to write a wrapper for the user
password management, and instead of sending off the password they
type, send off SHA-1/MD5(the password they type + something random).
Then the user doesn't actually know their "real" password, so they can
not download an external tool and start playing around.

3. How to protect data "over the wire" from packet sniffers etc

On a roll now, this is beyond the scope of Firebird in particular,
check out Zebedee (google)

4. How to audit activity within the database (who did what when and why)

Firebird currently provides no mechanism for this. (Hint check
Roadmap). You can obviously use triggers and add information to
external tables (which do not get rolled back). There are also tools
on the market now (IBLogManager etc) that do this for you.

5. How to prevent nosey users from snooping around

Well if you have implemented most of these ideas, then they will not
know their password, not have access to the windows tools that might
be useful for snooping, cant download the tools onto the database
server, cant connect to firebird on the database server remotely, and
they have the knowledge that they may have to account for every query
they attempt to run.

So there you go, not bullet proof, but not a walk in the park either.

6. How to protect internal data from eyes of dbas etc.

You may need to store things like credit card numbers or passwords in
the database. DBAs have full access to the database, and may need it,
but you don't want them to know this information. If you need to get
the information back out, then use encryption (blowfish etc) and store
the encrypted data only. If it is only a comparison, use a hash (SHA-1
etc) and store the hash of the information plus some random "salt" to
prevent brute force attacks). Obviously the DBA must be trustable, but
I am happy that when I looking at an employee record and I can see
their password, it is 45 HEX characters that mean nothing to me. I am
happy about this because I bet that at least 10% of them use the same
password for email and online banking as they do for our product.


Adam