6.0.0-git
2025-01-19
Last Modified 2015-12-17 by Jan Schneider
SecurityTips

Horde Security Tips

The content of this page is mainly derived from the security-section in the Horde documentation. It is aimed at system administrators who want to add some extra security to their Horde installations (or for those who are a bit paranoid ;) )

Also see the file docs/SECURITY, available online too.

Introduction

The configuration examples here have been tested by me on a Fedora Core 3 system running Apache 2.2.3 with mod_ssl and Horde 3.1.3.
My Apache is serving most files out of /var/www/html. Thus my Horde installation lives in /var/www/html/horde. Please keep this in mind if you are applying any of these configurations on your system.

Filesystem Permissions

chown -R apache.apache /var/www/html/horde

This will change the user and the group of all files belonging to your Horde installation to the user and group of your Apache webserver. If your Apache shipps with suexec, Horde will be started with the permissions of your webserver from now on.

If you want more restrictive settings, you might try the following:

chmod -R go-rwx /var/www/html/horde/config
chmod -R go-rwx /var/www/html/horde/*/config

This will prevent any of your config-files to be accessed from the outside. If that's not enough for you, try this:
chmod -R a-w   /var/www/html/horde/

That's a bit overkill IMHO but makes all the files belonging to Horde unwritable by anyone except root. Take note that this might (and will) cause problems if you are planning to use Horde's built-in administration routines. To lift this a bit, you can restrict write-access to the only files that really need to be written by the webserver:
chmod u+w /var/www/html/horde/config/conf.php*
chmod u+w /var/www/html/horde/*/config/conf.php*

Explanation: conf.php will be your newly generated configuration file, conf.php.bak will be a backup of your old one.

Apache/PHP Configuration

The Horde documentation suggests an awful lot of <Directory> instructions to secure Horde. I've found a way to limit those to one <Directory> and one <DirectoryMatch> instruction and statisfy Horde's needs towards PHP on the fly:

<Directory "/var/www/html/horde/">
  Options none
  # Only needed if you have got safe_mode globally on
  php_admin_flag  safe_mode        off

  # /usr/share/pear is needed for PEAR. /var/www/html/horde is needed for Horde itself
  # You might want to add /usr/bin for applications like Chora that are calling external binaries
  # TODO: Set an appropriate include_path, too. Might even increase speed a bit.
  php_admin_value open_basedir     "/var/www/html/horde:/usr/share/pear" 

  # always a good idea :)
  php_admin_flag  expose_php       off

  # If you do this (recomended by the PHP documentation, btw)...
  php_admin_flag  display_errors   off

  # ... you need to set this also - otherwise you'll have no idea what's wrong if something doesn't work.
  # Don't forget to specify a logfile in your php.ini or elsewhere!
  php_admin_flag  log_errors       on
  php_admin_flag  register_globals off
</Directory>

# Deny access to files that are not served directly by the webserver
<DirectoryMatch "^/var/www/html/horde/(.*/)?(config|lib|locale|po|scripts|templates)/(.*)?">
  order deny,allow
  deny  from all
</DirectoryMatch>

# Deny access to the test.php files except from localhost
<LocationMatch "^/horde/(.*/)?test.php">
  order deny,allow
  deny  from all
  allow from localhost
</LocationMatch>

This way you can safely switch php_safe_mode globaly on and still have Horde working. Please notice that you might need to modify the open_basedir directive. It includes /var in this example because there are a lot of important things in /var on my server (i.e. the cache and the logfile for Horde),

Please take note that you need to put this into your httpd.conf because the php_admin_* instructions won't work in a .htaccess file. If you do so, don't forget to use httpd -t to check for syntax errors in your httpd.conf before you restart your Apache. Apache 2.0.x allows you to place a config file into /etc/httpd/conf.d/ so you can place the whole thing into a new file /etc/httpd/conf.d/horde.conf. If the directory /etc/httpd doesn't exist on your system, you may execute the following command on a shell to find out, what your Apache's config-directoy is:

httpd -V | grep HTTPD_ROOT
httpd -V | grep SERVER_CONFIG_FILE

Also note that I used escaped slashes in the RegEx for the <DirectoryMatch> instruction. Apache seems to cope with unescaped metacharacters. But since I'm using perl-RegEx most of the time, I'm used to escape those.

The <DirectoryMatch>-instruction is restricting access to the folders config, lib, locale, po, scripts and templates in Horde and all its applications.
<LocationMatch> prevents Horde's test.php scripts being accessed from the outside. The Horde documentation is suggesting to restrict all hosts. This example allows access from your local host so you can run the tests via lynx or a SSH tunnel.

MySQL Configuration

There's little to do. If you do not need the networking part of your MySQL installation and can rely on UNIX-sockets, you can disable it by adding the following line into your etc/my.cnf in the [mysqld] section:

skip-networking

This will also decrease the size of your mysql-threads. if you want even more free RAM, also add:
skip-innodb
skip-bdb

This will turn off the InnoDB addon and support for Berkeley Databases. You should leave InnoDB enabled if you use that type of table.

If you absolutely need TCP-connections to your MySQL server, you can specify port and IP-address in the same section:

bind-address=127.0.0.1
port=3306

This example will bind the MySQL-server to the local host at port 3306 (MySQL default).

Also make sure that your password for Horde's database is safe (even if you disabled networking support).
Hint: phpMyAdmin 2.7+ lets you generate randomized passwords consisting of all printable characters with sufficient length.

PEAR Security

There's only one thing: Keep your installation of PEAR up to date. Here's how:

pear upgrade-all

You'll want to test after upgrades to ensure that nothing has changed or broken, as packages have been known to have bugs now and then, but generally the releases are good. If you are less inclined to blindly upgrade everything, you can find out what new releases are available with:

pear list-upgrades

Then you can upgrade packages individually with:

pear upgrade package-name

Home
Usage
Recent Changes
All Pages