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.
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.
chown -R apache.apache /var/www/html/horde
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
chmod -R a-w /var/www/html/horde/
chmod u+w /var/www/html/horde/config/conf.php* chmod u+w /var/www/html/horde/*/config/conf.php*
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>
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.
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:
If you absolutely need TCP-connections to your MySQL server, you can specify port and IP-address in the same section:
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.
There's only one thing: Keep your installation of PEAR up to date. Here's how:
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:
Then you can upgrade packages individually with:
pear upgrade package-name