{"id":702,"date":"2012-01-29T17:46:24","date_gmt":"2012-01-29T17:46:24","guid":{"rendered":"https:\/\/noi3.org\/site\/?p=702"},"modified":"2012-01-29T17:46:24","modified_gmt":"2012-01-29T17:46:24","slug":"joomla-how-to-site-security","status":"publish","type":"post","link":"https:\/\/site.noi3.org\/?p=702","title":{"rendered":"Joomla How To: Site Security"},"content":{"rendered":"

\tSecurity matters
\t <\/p>\n

\tInternet security is a fast moving challenge and ever present threat. There is no one right way to secure a website, and all security methods are subject to instant obsolescence, incremental improvement, constant revision. All public facing website are open to constant attack. Are you willing and able to invest the time it takes to administer a dynamic, 24×7, world-accessible, database-driven, interactive, user-authenticated website? Do you have the time and resources to respond to the constant flow of new Internet security issues?<\/p>\n

\tThe Top 10 Stupidest Administrator Tricks<\/a> is a comic\/tragic look at what can go wrong. Don't learn these tricks the hard way! Depending on your own experience, reading the Stupidest Tricks<\/em> will either make you laugh or cry. Luckily, there are some well-established principles upon which to base your defensive plans. The following checklists point you toward current best practices for Joomla security.<\/p>\n

<\/p>\n

\tSecurity matters
\t <\/p>\n

\tInternet security is a fast moving challenge and ever present threat. There is no one right way to secure a website, and all security methods are subject to instant obsolescence, incremental improvement, constant revision. All public facing website are open to constant attack. Are you willing and able to invest the time it takes to administer a dynamic, 24×7, world-accessible, database-driven, interactive, user-authenticated website? Do you have the time and resources to respond to the constant flow of new Internet security issues?<\/p>\n

\tThe Top 10 Stupidest Administrator Tricks<\/a> is a comic\/tragic look at what can go wrong. Don't learn these tricks the hard way! Depending on your own experience, reading the Stupidest Tricks<\/em> will either make you laugh or cry. Luckily, there are some well-established principles upon which to base your defensive plans. The following checklists point you toward current best practices for Joomla security.<\/p>\n

\tThe most important guidelines<\/h3>\n
\n
\t\tThese checklists are long and growing because the full plot is thick, complex, and expanding, but don't despair! Here are a few essential guidelines for securing any website. Following them will protect you from most catastrophes.<\/dd>\n<\/dl>\n
    \n
  1. \t\tBackup early and often:<\/strong> Setup (and use and test) a regular backup and recovery process. When done well, this ensures that you can recover from almost any imaginable disaster.<\/li>\n
  2. \t\tUpdate early and often:<\/strong> Promptly update to the latest stable<\/em> version of Joomla! and any installed third-party extensions. This ensures that your site is protected from the newest vulnerabilities as soon as a fix is released and from the latest attack methods as soon as a defense is developed.<\/li>\n
  3. \t\tUse a secure host<\/strong> Use a high-quality Web host. Do not be fooled by offers of 'unlimited bandwidth, unlimited hard drive space, unlimited databases, etc.<\/li>\n
  4. \t\tUse the community<\/strong> Don't forget the truism, "If a deal is too good to be true, it is." It seems that nothing on Earth is unlimited–except perhaps the gullibility of fools and the greed of those who prey upon them. Consider hiring professional assistance if you have inadequate experience or knowledge in this area. One of the advantages of GNU software is that user support is free. Take good advantage of this by asking good questions within the Joomla! Forums<\/a>. When doing so, be sure to use the the most appropriate board, such as Installation, Migration and Updating, Administration.<\/li>\n<\/ol>\n

    \tThe bad news<\/h3>\n
      \n
    1. \t\tThere is no perfect security on the Web!<\/strong> As economists would say, "There's no free lunch." Don't be fooled by Joomla's award winning ease-of-use. Maintaining a secure Web site on the open Internet is not easy. Maintaining adequate security requires a wide and ever-growing range of skills and knowledge, constant watchfulness, and a robust backup and recovery process.<\/li>\n
    2. \t\tThere's no one right way!<\/strong> Due to the variety and complexity of modern web systems, security issues can't be resolved with simple, one-size-fits-all solutions. You (or someone you trust) must learn enough about your server infrastructure to make valid security decisions. Strong security is a moving target. Today's expert might be tomorrow's victim. Welcome to the game…<\/li>\n
    3. \t\tThere's no substitute for experience!<\/strong> To secure your Web site, you must gain real experience (some of which will be bitter), or get experienced help from others. If you haven't invested the considerable time it takes to learn how to maintain a secure Web site, be sure you can consult with someone who has. Read this tongue-in-cheek description of the Top 10 Stupidest Administrator Tricks<\/a> which illustrates typical, blow-by-blow examples of how to learn Web security the hard way.<\/li>\n<\/ol>\n
      \n

      \tChoose a Qualified Hosting Provider<\/h2>\n

      \t<\/a><\/p>\n

      \tThe most important decision<\/h3>\n
      \n
      \t\tProbably no decision is more critical to site security than the choice of hosts and servers. However, due to the wide variety of hosting options and configurations, it's not possible to provide a complete list for all situations. Check this unbiased list of recommended hosts<\/a>who fully meet the security requirements of a typical Joomla site. (FAQ<\/a>)<\/dd>\n<\/dl>\n

      \t<\/a><\/p>\n

      \tShared server risks<\/h3>\n
      \n
      \t\tIf you are on a tight budget and your site does not process highly confidential data, you can probably get by with a shared server, but you must understand the unavoidable risks. Most of the tips listed below are appropriate for securing sites on shared server environments.<\/dd>\n<\/dl>\n

      \t<\/a><\/p>\n

      \tAvoid sloppy server configurations<\/h3>\n
      \n
      \t\tFor a real eye-opener, read this report<\/a> on thousands of sites that allowed Google to index the results of phpinfo(). Don't make this mistake on your site! The report includes alarming statistics on the percentage of sites that use depreciated settings such as register_globals ON or that don't have open_basedir set at all: By the way, if phpini<\/em> and register_globals<\/em> are unfamiliar terms you are probably not ready to securely manage your own site.<\/dd>\n
      \n
      \n<\/dd>\n<\/dl>\n

      \t<\/a><\/p>\n

      \tConfiguring Apache<\/h2>\n

      \t<\/a><\/p>\n

      \tUse Apache .htaccess<\/h3>\n

      \tSee also .htaccess examples<\/a><\/em><\/p>\n

      \n
      \t\tBlock typical exploit attempts with local Apache .htaccess<\/em> files. This option is not enabled on all servers. Check with your host if you run into problems. Using .htaccess<\/em>, you can password protect sensitive directories, such as administrator, restrict access to sensitive directories by IP Address, and depending on your server's configuration, you may be able to increase security by switching from PHP4 to PHP5.<\/dd>\n<\/dl>\n
      \n
      \t\tJoomla ships with a preconfigured .htaccess<\/a> file, but *you* need to choose to use it. The file is called htaccess.txt; to use it rename it to .htaccess and place it in the root of your webpage.<\/dd>\n<\/dl>\n
      \n
      \t\tConsider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)<\/dd>\n<\/dl>\n

      \t<\/a><\/p>\n

      \tUse Apache mod_security<\/h3>\n
      \n
      \t\tConfigure Apache mod_security and mod_rewrite filters to block PHP attacks. See Google search for mod_security<\/a> and Google search for mod_rewrite<\/a>. (Note: These are advanced methods that usually require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)<\/dd>\n<\/dl>\n

      \t<\/a><\/p>\n

      \n

      \t <\/p>\n

      \t <\/p>\n

      \tConfiguring MySQL<\/h2>\n

      \tSecure the database<\/h3>\n
      \n
      \t\tBe sure MySQL accounts are set with limited access. The initial install of MySQL is insecure and careful configuration is required. (See the MySQL Manuals<\/a>) Note: This item applies only to those administering their own servers, such as dedicated servers. Users of shared servers are dependent on their hosting provider to set proper database security.)<\/dd>\n<\/dl>\n

      \tConfiguring PHP<\/h2>\n

      \tUnderstand how PHP works<\/h3>\n
      \n
      \t\tUnderstand how to work with the php.ini file, and how PHP configurations are controlled. Study the Official List of php.ini Directives<\/a> at http:\/\/www.php.net<\/a>, and the well-documented default php.ini file included with every PHP install. Here is the latest default php.ini file<\/a> on the official PHP site.<\/dd>\n<\/dl>\n

      \tUse PHP5<\/h3>\n
      \n
      \t\tCurrently, both PHP4 and PHP5 are maintained, and both are often available on servers. Before PHP4 becomes obsolete, upgrade your custom scripts to PHP5. Don't worry about core Joomla code; all current versions are PHP5 compatible. (See PHP News<\/a>)<\/dd>\n<\/dl>\n

      \tUse local php.ini files<\/h3>\n
      \n
      \t\tOn shared servers you can't edit the main php.ini file, but you may be able to add custom, local php.ini files. If so, you'll need to copy the php.ini files to every sub-directory that requires custom settings. Luckily a set of scripts at B & T Scripts and Tips<\/a> can do the hard work for you.<\/dd>\n<\/dl>\n
      \n
      \t\tThere are a few important things to keep in mind.<\/strong><\/dd>\n<\/dl>\n
        \n
      1. \t\tLocal php.ini<\/em> files only<\/strong><\/em> have an effect if your server is configured to use them. This includes a php.ini<\/em> file in your http_root<\/em> directory. You can test whether or not these file affect your site by setting an obvious directive in the local php.ini<\/em> file to see if it affects your site.<\/li>\n
      2. \t\tLocal php.ini<\/em> files only effect .php<\/em> files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a php.ini<\/em> file. They are your http_root<\/em>(your actual directory name may vary), which is where Joomla's Front-end index.php<\/em> file is located, and the Joomla! administrator<\/em> directory, which is where the Back-end administrator index.php<\/em> file is located. Other directories that don't have files called via the Web do not need local php.ini<\/em> files.<\/li>\n
      3. \t\tIf you have a php.ini<\/em> file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the php.ini<\/em> files in http_root<\/em> and the administrator<\/em> directories.<\/li>\n<\/ol>\n

        \tUse PHP disable_functions<\/h3>\n
        \n
        \t\tUse disable_functions<\/em> to disable dangerous PHP functions that are not needed by your site. Here is a typical setup for a Joomla! site:<\/dd>\n<\/dl>\n
              disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open<\/pre>\n
         \tUse PHP open_basedir<\/h3>\n
        \n
         \t\topen_basedir<\/em> should be enabled and correctly configured. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.<\/dd>\n<\/dl>\n
        \n
         \t\tThe restriction specified with open_basedir is a prefix, not a directory name. This means that open_basedir = \/dir\/incl<\/em> allows access to \/dir\/include<\/em> and \/dir\/incls<\/em> if they exist. To restrict access to only the specified directory, end with a slash. For more information, see PHP Security and Safe Mode Configuration Directives<\/a>.<\/dd>\n<\/dl>\n
             open_basedir = \/home\/users\/you\/public_html<\/pre>\n
        \n
         \t\tIn some system configurations, at least with PHP 4.4.8, the use of the trailing slash to restrict the access to only the specified directory may cause Joomla to warn JFolder::create: Infinite loop detected<\/em> when saving the Back-End Global Configuration. This warning is triggered because PHP file_exists()<\/em> function fails, for example, when asked if \/home\/user\/public_html\/joomla_demo<\/em> exists and open_basedir<\/em> is set to \/home\/user\/public_html\/joomla_demo\/<\/em> (see the trailing slash).<\/dd>\n<\/dl>\n
        \n
         \t\tAdditionally, if open_basedir<\/em> is set it may be necessary to set PHP upload_tmp_dir<\/em> configuration directive to a path that falls within the scope of open_basedir<\/em> or, alternatively, add the upload_tmp_dir<\/em> path to open_basedir<\/em> using the appropriate path separator for the host system.<\/dd>\n<\/dl>\n
             open_basedir = \/home\/users\/you\/public_html:\/tmp<\/pre>\n
        \n
         \t\tPHP will use the system's temporary directory when upload_tmp_dir<\/em> is not set or when it is set but the directory does not exist, therefore it may be necessary to add it to open_basedir<\/em> as above to avoid uploading errors within Joomla.<\/dd>\n<\/dl>\n
         \tAdjust magic_quotes_gpc<\/h3>\n
        \n
         \t\tAdjust the magic_quotes_gpc<\/em> directive as needed for your site. The recommended setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions. The safest method is to turn magic_quotes_gpc<\/em> off and avoid all poorly-written extensions, period.<\/dd>\n<\/dl>\n
        \n
         \t\tJoomla! 1.5 ignores this setting and works fine either way.<\/dd>\n<\/dl>\n
         \tFor more information, see either Magic quotes and security<\/a> or PHP Manual, Chapter 31. Magic Quotes<\/a>.<\/p>\n
              magic_quotes_gpc = 1<\/pre>\n
         \tDon't use PHP safe_mode<\/h3>\n
        \n
         \t\tAvoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper problem and provides a false sense of security. See the official PHP site for an explanation of this issue.<\/dd>\n<\/dl>\n
              safe_mode = 0<\/pre>\n
         \tDon't use PHP register_globals<\/h3>\n
        \n
         \t\tAutomatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have depreciated this 'feature'.<\/dd>\n<\/dl>\n
        \n
         \t\tIf your site is on a shared server with a hosting provider that insists register_globals<\/em> must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server. For more information, see ZEND Chapter 29. Using Register Globals<\/a>.<\/dd>\n<\/dl>\n
              register_globals = 0<\/pre>\n
         \tDon't use PHP allow_url_fopen<\/h3>\n
        \n
         \t\tDon't use PHP allow_url_fopen<\/em>. This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers. Note: This can only be set in php.ini due to security reasons.<\/dd>\n<\/dl>\n
              allow_url_fopen = 0<\/pre>\n
         \tSetup a backup and recovery process<\/h2>\n
         \tThe most important rule:<\/h3>\n
        \n
         \t\tThou shalt at all time be able to return your site to a previous working state through regular use of a strong, off-site backup and recovery process. Be sure your backup and recovery process is in place and tested BEFORE you go live. This is the single best way (and often the only way) to recover from such inevitable catastrophes as:<\/dd>\n<\/dl>\n
          \n
        1.  \t\tA compromised\/cracked site.<\/li>\n
        2.  \t\tBroken site due to a faulty upgrade.<\/li>\n
        3.  \t\tHardware failure, such as dead hard drives, power failures, server theft, etc.<\/li>\n
        4.  \t\tAuthoritarian government intervention. (More common than some think.)<\/li>\n
        5.  \t\tNeeding to quickly relocate to a new server or hosting provider.<\/li>\n<\/ol>\n
          \n
           \tSite Administration<\/h2>\n
           \tUse well-formed passwords<\/h3>\n
          \n
           \t\tChange passwords regularly and keep them unique. A strong password has a random combination of letters, numbers, or symbols. Avoid using single names or words found in a dictionary. Never use the names of your relatives, pets, etc. Search the forums for a script supplied by Wizzie that automatically changes passwords. This is a great tool for administrators or multiple sites. There are numerous handy websites that have strong password generators<\/a>.<\/dd>\n<\/dl>\n
           \tFollow a password leveling scheme<\/h3>\n
          \n
           \t\tMost users may not need more than three levels of passwords and webmasters no more than five. Each level must be completely unrelated to the others in terms of which usernames and passwords are used. Learn how to do this: How do you setup a powerful password scheme?<\/a><\/dd>\n<\/dl>\n
           \tMaintain a strong site backup process<\/h3>\n
          \n
           \t\tNever rely on others' backups. Take responsibility for your backup procedures. Many ISPs state in their contract that you can not rely solely on their backups.<\/dd>\n<\/dl>\n
           \tMonitor crack attempts<\/h3>\n
          \n
           \t\tVPS and dedicated server users can run TripWire or SAMHAIN. These applications provide exhaustive file checking and reporting functionality, and can be installed in a stealthy manner to help protect themselves in the event of a serious infiltration. (Note: Users of shared servers can not use this technique.)<\/dd>\n<\/dl>\n
           \tPerform automated intrusion detection<\/h3>\n
          \n
           \t\tUse an Intrusion Prevention\/Detection Systems to block\/alert on malicious HTTP requests.<\/dd>\n<\/dl>\n