D7net
Home
Console
Upload
information
Create File
Create Folder
About
Tools
:
/
usr
/
share
/
doc
/
cpanel-php73-horde
/
Filename :
SECURITY
back
Copy
====================== Horde Security Notes ====================== :Contact: horde@lists.horde.org .. contents:: Contents .. section-numbering:: Temporary files =============== Horde applications make extensive use of temporary files. In order to make sure these files are secure, you should make sure your installation meets the following criteria. Sites may gain increased security by defining a temporary directory in the Horde configuration which is writable by the web server, but not writable by other users. Since the temporary files may contain sensitive information it is best to also make these file unreadable by other users. That is, they can be made readable and writable only by the web server user. PHP Sessions ============ For the most security, you should enable PHP session cookies by enabling the PHP setting ``session.use_cookies``. When doing so, be sure to set an appropriate cookie path and cookie domain in the Horde configuration also to secure your cookies. You should even force session cookie usage in the Horde configuration, which is the default setting in all Horde versions now. If you want to use HTTPS connections, consider forcing users to HTTPS in the Horde configuration. This will force cookies to be sent over secure connections only and helps to prevent sidejacking. If PHP sessions are set to use the ``files`` save_handler, then these files should be secured properly. Sites can increase security by setting the PHP setting ``session.save_path`` to a directory that is only readable and writable by the web server process. Sites with a large user base should consider setting the ``session.entropy_file`` and ``session.entropy_length`` to appropriate values. Horde will encrypt the user credentials before storing them in the session. Thus, a compromised sessions will not reveal the user's stored credentials. Default database passwords ========================== The Horde documentation and sample database creation scripts create a default user and password for accessing the horde database. Using this password in a production environment is a security hole, since an attacker will easily guess it. It is very important that sites change at least the password to something secure. Prevent configuration file reading and writing ============================================== The configuration files may contain sensitive data (such as database passwords) that should not be read or written by local system users or remote web users. If you use a Unix system, one way to make the configuration files and directories accessible only to the web server is as follows. Here we assume that the web server runs as the user ``apache`` and the files are located in ``/home/httpd/html`` -- substitute the correct user or file path if needed:: $ chown -R apache /home/httpd/html/horde/config $ chown -R apache /home/httpd/html/horde/*/config $ chmod -R go-rwx /home/httpd/html/horde/config $ chmod -R go-rwx /home/httpd/html/horde/*/config For completely fascist permissions, you can make the entire Horde tree inaccessible by anyone except the web server user (and root):: $ chown -R apache /home/httpd/html/horde $ chmod -R go-rwx /home/httpd/html/horde $ chmod -R a-w /home/httpd/html/horde/ Note that the last line makes all files unwritable by any user (only root can override this). This makes the site secure, but may make it more difficult to administrate. In particular, it will defeat the Horde administrative configuration interface, forcing you to update the Horde configuration files manually (as per the INSTALL_ instructions). The above will not secure the files if other user's on the same machine can run scripts as the apache user. If you need to protect against this you should make other user's scripts run under their own account with some facility such as apache's suexec module. You need to watch out not only for cgi scripts, but also for other modules like mod_php, mod_perl, mod_python, etc. that may be in use on your server. .. _INSTALL: ?f=INSTALL.html Restricting the test script =========================== The test script (``horde/test.php``) provides a wealth of information that can be used against the site by attackers. This script is disabled by default for this reason. This script is configured via the 'testdisable' configuration option. After manually enabling the script, and once you have confirmed that everything is working, you should disable access to the test script. Preventing Apache from serving configuration and source files ============================================================== The Horde configuration files may contain sensitive data (such as database passwords) that should not be served by the web server. Other directories contain PHP source code that isn't intended for viewing by end-users. The Horde group has provided ``.htaccess`` files in various directories to help protect these files. However, that depends on your web server honoring ``.htacess`` files (which is a performance hit, and may not be available in all web servers). An Apache site can also prevent the web server from serving these files by adding sections to ``httpd.conf`` such as the following:: <Directory "/home/httpd/html/horde/config"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/lib"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/locale"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/po"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/scripts"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/templates"> order deny,allow deny from all </Directory> Repeat this pattern for each Horde application. For example, for IMP you would then add:: <Directory "/home/httpd/html/horde/imp/config"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/imp/lib"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/imp/locale"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/imp/po"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/imp/scripts"> order deny,allow deny from all </Directory> <Directory "/home/httpd/html/horde/imp/templates"> order deny,allow deny from all </Directory> Setup scripts ============= There are various scripts use to setup or configure Horde. If you allow other users on the web server machine, you should protect these files from being accessed by them. On a unix system, you might restrict these files to root access by using the following type of commands:: $ chown -R root /home/httpd/html/horde/scripts $ chown -R root /home/httpd/html/horde/*/scripts $ chmod -R go-rwx /home/httpd/html/horde/scripts $ chmod -R go-rwx /home/httpd/html/horde/*/scripts Using a chroot web server setup =============================== Unix users may want to consider using a chroot environment for their web server. How to do this is beyond the scope of this document, but sufficient information exists on the world wide web and/or in your server documentation to complete this task. Hiding PHP info from the user ============================= You should consider setting the following PHP variables in your ``php.ini`` file to prevent information leak to the user, or global insertion by the user:: expose_php = Off display_errors = Off log_errors = On register_globals = Off You should also set up error logging (using the PHP ``error_log`` variable) to log to a file, syslog, or other log destination. Using a secure web server ========================= Horde depends on passing sensitive information (such as passwords and session information) between the web server and the web client. Using a secure (SSL-enabled) web server will help protect this information as it traversing the network. Using a secure POP3/IMAP server =============================== If you are using a POP3/IMAP server with Horde (e.g. for authentication or for IMP) then Horde is passing the user's login credentials between the web server and the mail server. If your web server and IMAP server are on the same host, you can increase security by forcing all traffic over the loopback or localhost interface so that it is not exposed to your network. In cases where that is not possible, we recommend using a secure mail connection such as IMAP-SSL or POP3-SSL to ensure that passwords remain safe. LDAP Security ============= LDAP security is similar to the above POP3/IMAP server security issue. If you are using LDAP, you should make sure that you are not exposing ldap passwords or any sensitive data in your LDAP database. Database socket security ======================== If your database (e.g. MySQL or PostgreSQL) is on the same host as your web server, you may use unix sockets rather than tcp connections to help improve your security (and performance). If it doesn't support unix sockets, you can achieve some better security by restricting the tcp support to the loopback or localhost interface. If the database keeps its socket file (e.g. ``mysql.sock``) in a directory like ``/tmp`` or ``/var/tmp``, you should set permissions carefully to ensure that local users (if you have any) can't delete the socket. The unix "sticky" bit should already be sent on the temporary directory itself, but you also need to make sure the socket itself isn't writable by "other" or users can delete it. You might consider moving the socket file to another location such as ``/var/run`` or the top-level directory of your database program (e.g. ``/var/lib/mysql`` or ``/var/lib/pgsql``). Sendmail or SMTP considerations =============================== In some cases, you can increase security by sending mail via the local command-line sendmail program on your web server, rather than using SMTP. However, there may be reasons to use SMTP instead, such as if your smtp server does spam or virus checking which would be skipped using the local sendmail program. Additional Notes ================ This is by far not a complete security HOWTO. This is just a compiled list of what people have contributed so far. If you have tips, ideas, suggestions or anything else that you think could help others in securing their Horde installation, please let us know.