[Sommaire] [Imprimer]

   1  ======================
   2   Horde Security Notes
   3  ======================
   4  
   5  :Last update:   $Date: 2004/09/26 23:33:07 $
   6  :Revision:      $Revision: 1.9 $
   7  :Contact:       horde@lists.horde.org
   8  
   9  .. contents:: Contents
  10  .. section-numbering::
  11  
  12  
  13  Temporary files
  14  ===============
  15  
  16  Horde applications make extensive use of temporary files.  In order to make
  17  sure these files are secure, you should make sure your installation meets the
  18  following criteria.
  19  
  20  Sites may gain increased security by defining a temporary directory in the
  21  Horde configuration which is writable by the web server, but not writable by
  22  other users.  Since the temporary files may contain sensitive information it
  23  is best to also make these file unreadable by other users.  That is, they can
  24  be made readable and writable only by the web server user.
  25  
  26  
  27  PHP Sessions
  28  ============
  29  
  30  For the most security, you should enable PHP session cookies by enabling the
  31  php setting ``session.use_cookies``.  When doing so, be sure to set an
  32  appropriate ``session.cookie_path`` and ``session.cookie_domain`` also to
  33  secure your cookies.
  34  
  35  If PHP sessions are set to use the ``files`` save_handler, then these files
  36  should be secured properly.  Sites can increase security by setting the php
  37  setting ``session.save_path`` to a directory that is only readable and
  38  writable by the web server process.
  39  
  40  Sites with a large user base should consider setting the
  41  ``session.entropy_file`` and ``session.entropy_length`` to appropriate values.
  42  
  43  Horde will encrypt the user credentials before storing them in the session.
  44  However, this encryption can be improved if you have and enable the php
  45  extension "mcrypt" which allows for stronger encryption than is otherwise
  46  provided by Horde.
  47  
  48  
  49  Default database passwords
  50  ==========================
  51  
  52  The Horde documentation and sample database creation scripts create a default
  53  user and password for accessing the horde database.  Using this password in a
  54  production environment is a security hole, since an attacker will easily guess
  55  it.
  56  
  57  It is very important that sites change at least the password to something
  58  secure.
  59  
  60  
  61  Prevent configuration file reading and writing 
  62  ==============================================
  63  
  64  The configuration files may contain sensitive data (such as database
  65  passwords) that should not be read or written by local system users or remote
  66  web users.
  67  
  68  If you use a Unix system, one way to make the configuration files and
  69  directories accessible only to the web server is as follows.  Here we assume
  70  that the web server runs as the user ``apache`` and the files are located in
  71  ``/home/httpd/html`` -- substitute the correct user or file path if needed::
  72  
  73  $ chown -R apache /home/httpd/html/horde/config
  74  $ chown -R apache /home/httpd/html/horde/*/config
  75  $ chmod -R go-rwx /home/httpd/html/horde/config
  76  $ chmod -R go-rwx /home/httpd/html/horde/*/config
  77  
  78  For completely fascist permissions, you can make the entire Horde tree
  79  inaccessible by anyone except the web server user (and root)::
  80  
  81  $ chown -R apache /home/httpd/html/horde
  82  $ chmod -R go-rwx  /home/httpd/html/horde
  83  $ chmod -R a-w   /home/httpd/html/horde/
  84  
  85  Note that the last line makes all files unwritable by any user (only root can
  86  override this).  This makes the site secure, but may make it more difficult to
  87  administrate.  In particular, it will defeat the Horde administrative
  88  configuration interface, forcing you to update the Horde configuration files
  89  manually (as per the INSTALL_ instructions).
  90  
  91  The above will not secure the files if other user's on the same machine can
  92  run scripts as the apache user.  If you need to protect against this you
  93  should make other user's scripts run under their own account with some
  94  facility such as apache's suexec module.  You need to watch out not only for
  95  cgi scripts, but also for other modules like mod_php, mod_perl, mod_python,
  96  etc. that may be in use on your server.
  97  
  98  .. _INSTALL: ?f=INSTALL.html
  99  
 100  
 101  Restricting test.php files
 102  ==========================
 103  
 104  The ``test.php`` files provide a wealth of information that can be used
 105  against the site by attackers.  One you have confirmed that everything is
 106  working, you should disable access to the test.php files.  You can do this via
 107  the web server, or via system file permissions.  On a unix system, you might
 108  issue a command such as::
 109  
 110  $ chmod a-rwx /home/httpd/html/horde/test.php
 111  $ chmod a-rwx /home/httpd/html/horde/*/test.php
 112  
 113  
 114  Preventing Apache from serving configuration and source files
 115  ==============================================================
 116  
 117  The Horde configuration files may contain sensitive data (such as database
 118  passwords) that should not be served by the web server. Other directories
 119  contain PHP source code that isn't intended for viewing by end-users. The
 120  Horde group has provided ``.htaccess`` files in various directories to help
 121  protect these files.  However, that depends on your web server honoring
 122  ``.htacess`` files (which is a performance hit, and may not be available in
 123  all web servers).
 124  
 125  An Apache site can also prevent the web server from serving these
 126  files by adding sections to ``httpd.conf`` such as the following::
 127  
 128     <Directory "/home/httpd/html/horde/config">
 129         order deny,allow
 130         deny from all
 131     </Directory>
 132     <Directory "/home/httpd/html/horde/lib">
 133         order deny,allow
 134         deny from all
 135     </Directory>
 136     <Directory "/home/httpd/html/horde/locale">
 137         order deny,allow
 138         deny from all
 139     </Directory>
 140     <Directory "/home/httpd/html/horde/po">
 141         order deny,allow
 142         deny from all
 143     </Directory>
 144     <Directory "/home/httpd/html/horde/scripts">
 145         order deny,allow
 146         deny from all
 147     </Directory>
 148     <Directory "/home/httpd/html/horde/templates">
 149         order deny,allow
 150         deny from all
 151     </Directory>
 152  
 153  Repeat this pattern for each Horde application.  For example, for IMP you
 154  would then add::
 155  
 156     <Directory "/home/httpd/html/horde/imp/config">
 157         order deny,allow
 158         deny from all
 159     </Directory>
 160     <Directory "/home/httpd/html/horde/imp/lib">
 161         order deny,allow
 162         deny from all
 163     </Directory>
 164     <Directory "/home/httpd/html/horde/imp/locale">
 165         order deny,allow
 166         deny from all
 167     </Directory>
 168     <Directory "/home/httpd/html/horde/imp/po">
 169         order deny,allow
 170         deny from all
 171     </Directory>
 172     <Directory "/home/httpd/html/horde/imp/scripts">
 173         order deny,allow
 174         deny from all
 175     </Directory>
 176     <Directory "/home/httpd/html/horde/imp/templates">
 177         order deny,allow
 178         deny from all
 179     </Directory>
 180  
 181  
 182  Setup scripts
 183  =============
 184  
 185  There are various scripts use to setup or configure Horde.  If you allow other
 186  users on the web server machine, you should protect these files from being
 187  accessed by them.  On a unix system, you might restrict these files to root
 188  access by using the following type of commands::
 189  
 190  $ chown -R root /home/httpd/html/horde/scripts
 191  $ chown -R root /home/httpd/html/horde/*/scripts
 192  $ chmod -R go-rwx /home/httpd/html/horde/scripts
 193  $ chmod -R go-rwx /home/httpd/html/horde/*/scripts
 194  
 195  
 196  Using a chroot web server setup
 197  ===============================
 198  
 199  Unix users may want to consider using a chroot environment for their web
 200  server.  How to do this is beyond the scope of this document, but sufficient
 201  information exists on the world wide web and/or in your server documentation
 202  to complete this task.
 203  
 204  
 205  Hiding PHP info from the user
 206  =============================
 207  
 208  You should consider setting the following PHP variables in your ``php.ini``
 209  file to prevent information leak to the user, or global insertion by the
 210  user::
 211  
 212     expose_php = Off
 213     display_errors = Off
 214     log_errors = On
 215     register_globals = Off
 216  
 217  You should also set up error logging (using the PHP ``error_log`` variable)
 218  to log to a file, syslog, or other log destination.
 219  
 220  
 221  Using a secure web server
 222  =========================
 223  
 224  Horde depends on passing sensitive information (such as passwords and session
 225  information) between the web server and the web client.  Using a secure
 226  (SSL-enabled) web server will help protect this information as it traversing
 227  the network.
 228  
 229  
 230  Using a secure POP3/IMAP server
 231  ===============================
 232  
 233  If you are using a POP3/IMAP server with Horde (e.g. for authentication or for
 234  IMP) then Horde is passing the user's login credentials between the web server
 235  and the mail server.
 236  
 237  If your web server and IMAP server are on the same host, you can increase
 238  security by forcing all traffic over the loopback or localhost interface so
 239  that it is not exposed to your network.
 240  
 241  In cases where that is not possible, we recommend using a secure mail
 242  connection such as IMAP-SSL or POP3-SSL to ensure that passwords remain safe.
 243  
 244  
 245  LDAP Security
 246  =============
 247  
 248  LDAP security is similar to the above POP3/IMAP server security issue.  If you
 249  are using LDAP, you should make sure that you are not exposing ldap passwords
 250  or any sensitive data in your LDAP database.
 251  
 252  
 253  Database socket security
 254  ========================
 255  
 256  If your database (e.g. MySQL or PostgreSQL) is on the same host as your web
 257  server, you may use unix sockets rather than tcp connections to help improve
 258  your security (and performance).  If it doesn't support unix sockets, you can
 259  achieve some better security by restricting the tcp support to the loopback or
 260  localhost interface.
 261  
 262  If the database keeps its socket file (e.g. ``mysql.sock``) in a directory
 263  like ``/tmp`` or ``/var/tmp``, you should set permissions carefully to ensure
 264  that local users (if you have any) can't delete the socket.  The unix "sticky"
 265  bit should already be sent on the temporary directory itself, but you also
 266  need to make sure the socket itself isn't writable by "other" or users can
 267  delete it.
 268  
 269  You might consider moving the socket file to another location such as
 270  ``/var/run`` or the top-level directory of your database program (e.g.
 271  ``/var/lib/mysql`` or ``/var/lib/pgsql``).
 272  
 273  
 274  Sendmail or SMTP considerations
 275  ===============================
 276  
 277  In some cases, you can increase security by sending mail via the local
 278  command-line sendmail program on your web server, rather than using SMTP.
 279  However, there may be reasons to use SMTP instead, such as if your smtp server
 280  does spam or virus checking which would be skipped using the local sendmail
 281  program.
 282  
 283  
 284  Additional Notes
 285  ================
 286  
 287  This is by far not a complete security HOWTO. This is just a compiled list of
 288  what people have contributed so far. If you have tips, ideas, suggestions or
 289  anything else that you think could help others in securing their Horde
 290  installation, please let us know.