Skip to content

OpenLDAP Quick Tips: Encrypt your Oracle Berkeley DB if necessary

OpenLDAPOpen SourceSuretec Hi All,

Here's the 18th tip in the "OpenLDAP Quick Tips" series:

"You need to encrypt the raw bdb files":

This might be useful various reasons:

It may actually provide some value to sites that do regular backups of their raw DB files. It may actually be useful in some cases where you provide an encryption key on separate removable media (e.g. a USB flash drive). It might actually prevent a news article down the road on how some organization lost their 5 million record customer database and now all that unprotected data is now being exploited by criminals.

I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption.




Also:

The one place where I could see using this is if one is using OpenLDAP as
the backend to a Kerberos KDC. It's considered best practice right now to
always encrypt the KDC database at rest on disk, and some sites even
require an administrator be present with a USB key to unlock the database
whenever a KDC has to be rebooted. Given the increasing interest in using
LDAP[?] as a backend store for the KDC, this may be a simpler method for
providing equivalent KDC security without encrypting various bits of data
individually


Taking this all into account, what is needed is simply adding to your slapd.conf file:

CODE:
cryptkey testing


Note: there is also a cryptfile option to store the password in a seperate file.

If you already have a directory setup, then exporting your data and importing it again is needed to encrypt the files. A basic slapd.conf file needed would be:

CODE:
include /usr/local/etc/openldap/schema/core.schema pidfile ./slapd.pid argsfile ./slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb.la database bdb suffix "dc=suretecsystems,dc=com" rootdn "cn=admin,dc=suretecsystems,dc=com" rootpw secret directory ./openldap-data cryptkey    testing index objectClass eq


Then import your data with slapadd and test with the bdb tools:

CODE:
[ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump objectClass.bdb  db_verify: Encrypted environment: no encryption key supplied [ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump -P "test" objectClass.bdb  db_verify: Invalid password [ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump -P "testing" objectClass.bdb  VERSION=3 format=bytevalue type=btree chksum=1 duplicates=1 dupsort=1 db_pagesize=4096 HEADER=END  0096defd  00000001  21d9e0af  00000001  62c4d55f  00000001 DATA=END


Things to note:

You need the bdb version that supports encryption, i.e. not the one that has NC in the package name and that the only encrypted parts of a database environment are its databases and its log files. Specifically, the shared memory regions supporting the database environment are not encrypted. For this reason, it may be possible for an attacker to read some or all of an encrypted database by reading the on-disk files that back these shared memory regions.

For more information see the slapd-bdb man page.

Thanks,

Gavin.

If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.

P.S. For direct access to this section, you can click OpenLDAP Quick Tips.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
BBCode format allowed
Pavatar, Gravatar, Favatar, MyBlogLog, Pavatar author images supported.
Form options
tweetbackcheck