Frequently Asked Questions

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

• Choose *NIX: Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
• Use Secure FTP: Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

• Set PHP register_globals OFF: The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

• Seek PHP flexibility: Choose a host that allows you to use either PHP4 or PHP5.

• Stay up-to-date: Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and scripting languages.

• Avoid cheap shared servers: Be sure users on your shared server can't view each other's files and databases, for example through shell accounts and cpanels.

• Proactive server management: Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

• Require raw log access: Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

• Performance matters: Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

• Data center: Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

• Know your neighbors: Check that your host is not at risk of having its IP addresses blocked because it hosts porn or SMAM sites.

• Consider Recommendations: Check this list of recommended hosts.

• Grow with your site: As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include,

1. Dedicated servers offer the best possible security and performance, but at the highest expense
2. Virtual servers offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

Sites can be hosted at your location or at CommunityGrove.

Our systems usually require the latest stable versions of the Linux or BSD operating system, MySQL database, Apache Web server, and PHP interpreter. The vast majority of hosting providers offer this arrangement.

We use several hosting providers, but we prefer Rochen due to their absolute dedication to high-performance, high-reliability, high-security, and fast, expert technical support.

We can work with you to choose the optimal hosting arrangement for your site, and can manage transfers of DNS, site content, and dataabases.

CommunityGrove provides consulting, training, application development, and website management using best-of-breed GNU/Open Source solutions, such as Drupal, Joomla!, WordPress, and Moodle.

Consulting: Determine the best solution for your needs and budget.

Support: Customized training , and multi-format documentation. Private support forums, newsletters, alert systems, and emergency phone and email support.

Application Development: Industry-leading technologies, such as GNU/Linux, Apache, MySQL, PHP and Javascript. The best Open Source projects, such as Joomla, Drupal, PHPBB, WordPress, and Moodle. Our solutions conform to open industry standards.

Designs and Themes: Custom design services. A large and growing collection of professionally designed, ready-to-use themes.

Managed Hosting: Multiple top-tier Internet service providers. Highest quality servers. Continuous system monitoring, daily off-site backups, and regular application upgrades.

Contact Us Today!

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

Resources

1. Text Unescape Utility
2. HTML URL-encoding Reference

Check the active processes

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

Check crontab

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

Check for hidden files or directories

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

This is the general process we follow when recovering a compromised site. Following all the steps takes more time, but ensures that the site was fully recovered. We take nothing for granted and asume that the entire site is exposed.

1. Change all relevant passwords: Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
2. Check raw logs: Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
3. List recently modified files: Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
4. Note suspicious newly-created files: Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
5. Note suspicious recently-modified files: Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
6. Check for bogus CRON Jobs: Hacked cron jobs can be setup to reinfect your site over and over again.
7. Coordinate with your host: If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
8. Delete the entire public_html directory: This is the best way to guarantee that every potential vulnerability in that directory is removed.
9. Delete related database records: This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
10. Reinstall everything: Use pre-attack backups. If you don't have good backups, go on to step 10.
11. Reset critical passwords again: You must reset your passwards again now that your server is finally cleaned of all possible hidden trojan horses.
12. Rebuild site: If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
13. Review security processes: Follow standard security precautions for all installed applications.
14. Review and test the backup process: If you don't already have one, add a dependable backup and recovery process to your administration practices. Don't forget to test the entire backup and recovery process.
15. Stay watchful: Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.Add other security measures as appropriate.

Overview

Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one execption to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

From the official PHP site

"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now." More Information

1. Official PHP Manual: PHP Security and Safe Mode Configuration Directives
2. Official PHP Manual: PHP Functions restricted/disabled by safe mode

Might as well get it from the horse's mouth. In Do you PHP?, Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."

Caveats

1. Your server must allow .htaccess files for this technique to work.
2. If you do not have a .htaccess file in your root directory, see the related FAQ first.
3. Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
4. Hot linked images can only be replaced by other images, not with HTML pages.
5. As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

Directions

1. Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
2. Place the following code in the .htaccess file of your root directory.

Explanation

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "No Case", which means, match upper and lower case characters. The third line allows empty referrals. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image. Block hot linking from specific domains

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

Display a 403 forbidden code

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

Introduction

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

Directions

1. First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
2. Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
3. Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
4. Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

More Information

• Official PHP Manual: How to change configuration settings
• Official PHP Manual: List of PHP INI directives

Overview

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

Directions

1. In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
2. Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

• Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

• Optional: You can add multiple addresses by separating them with comma's.

Overview

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

Caveat (From Apache.org)

Basic authentication should not be considered secure for any particularly rigorous definition of secure. Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

Directions

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first. Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you can not use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

.htaccess Generator: http://www.webmaster-toolkit.com/htaccess-generator.shtml

Overview

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

IMPORTANT CAVEAT: One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

Requirements

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host. 2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host. 3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

Directions

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

Introduction

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

Directions

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

Overview

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box usually works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

Resources

1. Official ModSecurity Site
2. ModSecurity and Apache

Using the UNIX shell

Note: The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

Notes:

1. Test all third party extensions after changing permissions.
2. You may need to reset write permissions to install more extensions.

One common challenge with PHP applications is ensuring that PHP files in public_html that contain executable code or confidential data are protected from direct Internet access.

There are various ways to protect such files, but most are not optimal. Many users and developer groups, such as Gallery2 and Apache.org strongly recommend against keeping vulnerable files and confidential data inside public_html.

The following method seems to be the simplest and most elegant way to protect read-only files that, for whatever reason, must be stored in public_html. In this example, we protect configuration.php, perhaps the most confidential file of any Joomla! site.The same general method can be used for confidential Drupal files.

Note: Using this method, even if the Web server somehow delivers the contents of PHP files, for example due to a misconfiguration, nobody can see the contents of the real configuration file.

Directions

1. Move configuration.php to a safe directory outside of public_html and rename it whatever you want. We use the name joomla.conf in this example.

2. Create a new configuration.php file containing only the following code:

Important!

Do not include blank lines or any characters (including blank spaces) before the php start tag or after the php end tag. If you make this mistake, you very likely see the following error.

Warning: Cannot modify header information - headers already sent by (output started at /home/xxxxx/public_html/configuration.php:2) in /home/xxxxx/public_html/index.php on line 250

3. Make sure the new configuration.php file is not writable, so that it can not be overwritten by the Joomla! Web admin interface.

4. If you need to change configuration settings, do so manually in the relocated joomla.conf.

See also How to adjust Joomla 1.5 defines

Short answer

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

Long answer

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include andrequire. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

The incredible lightness of living outside the fence

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

CMS defense

Despite their apparently vulnerable location, Joomla!, Drupal, and other well-written PHP applications use various effective methods for blocking exploits.

Joomla! addis a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has the correct code added. One vulnerable file exposes the whole site.

Drupal uses the .htaccess file for more finegrained control.

The challenge

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you can not forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:

1. First allow all access, then deny any username/password combination that DOES NOT match the approved list.
2. First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

The good news

1. In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
2. Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
3. Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

1. Login to your Joomla! sites Administration site
2. From the menu, select Extensions -> Module Manager
3. From within the Module Manager, select Administrator
4. From the Icon Menu (top right), select New
5. From the choices available, select Feeds Display
6. At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
7. Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
8. Select cpanel as the position
9. Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
10. Select Save from the Icon Menu (top right)
11. Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time thy log in to the Back End, they'll see your latest news.

Overview

Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

Directions

• Level 5 (Public) - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

• Level 4 (Webmaster) - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

• Level 3 (Webmaster) - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

• Level 2 (Personal Data Access) - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

• Level 1 (Banking!) - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

There are three traditional backup types--full, cumulative and differential.

Full Backups

A complete backup of all associated files at a known point in time.

Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

Cumulative Backups

This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

Incremental Backups

This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly can not be recreated or is too costly to recreate, once a night or more may be more effective.

If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

Data Protection Best Practice says

1. You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
2. A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
3. A good backup practice is to store backups away from the current data location, preferably off site.
4. Dynamic data should be backed up offline or hot to avoid fuzzy backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

• Choose *NIX: Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
• Use Secure FTP: Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

• Set PHP register_globals OFF: The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

• Seek PHP flexibility: Choose a host that allows you to use either PHP4 or PHP5.

• Stay up-to-date: Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and scripting languages.

• Avoid cheap shared servers: Be sure users on your shared server can't view each other's files and databases, for example through shell accounts and cpanels.

• Proactive server management: Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

• Require raw log access: Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

• Performance matters: Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

• Data center: Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

• Know your neighbors: Check that your host is not at risk of having its IP addresses blocked because it hosts porn or SMAM sites.

• Consider Recommendations: Check this list of recommended hosts.

• Grow with your site: As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include,

1. Dedicated servers offer the best possible security and performance, but at the highest expense
2. Virtual servers offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

Drupal is our preferred application framework and content management system (CMS) for more advanced Web sites. Drupal is open-source software distributed under the GPL ("GNU General Public License") and is maintained and developed by a community of thousands of users and developers including the staff at CommunityGrove. You can learn more about Drupal here.

If you forget your email password, contact customer support to request a new one. We will reset your password for you.

To block SPAM, some Internet Service Providers (ISPs) block Port 25 which is the standard port for outgoing email. They expect their customers to use their own outgoing servers to send email. There is a way around this. We provide an alternate port. It is port 1025.

You can change the port number in your email client. (Usually found under "Advanced Settings"). If you need help with this please make a support request.

Webmail offers a way to access your email from anywhere on the Internet. To use Webmail, you must enter your email address and password at the following URL.

webmail.1and1.com

One advantage of Webmail is that you can access the mail from any computer on the Internet, and you don't have to configure anything.

1. Point your browser to: www.YOUR_DOMAIN.com/webmail
   Be sure to replace, YOUR_DOMAIN in this example with your actual domain.

Horde: www.horde.org

Squirrel Mail: www.squirrelmail.org.

Wikipedia Web Mail: en.wikipedia.org/wiki/Webmail.

1. Click on New on the taskbar. The window „Write new e-mail“ will open.
2. Insert the recipient’s e-mail address in the To field. In case of several recipients, use a comma to separate the e-mail addresses.
   If this recipient is already in your address book, proceed as follows:
   • Click on To. The window "Choose e-mail adress" shall open.
   • Check the box next to the recipient.
   • Click on OK to confirm.
3. Insert your e-mail’s topic in the Subject field.
4. Set your e-mail’s priority, by choosing either "low", "normal" or "high" in the drop-down menu.
5. Write your message in the Text field.
6. Click on Send on the taskbar to send your e-mail.

While logged into Webmail, select the menu item Settings > Change password

1. Insert your old password in the first field.
2. Now insert your new password in the second field. The password should at least be 7 characters long.
3. Repeat the new password in the next field.
4. Confirm by clicking OK. Your new password is instantly valid.

Version: 1.0
Last revision: Feb, 21, 2007

This document contains information on configuring and using email with CommunityGrove sites. It is updated as often as needed and should be your best and most current source of information.

{mospagebreak title=WebMail}

One advantage of Webmail is that you can access the mail from any computer on the Internet, and you don't have to configure anything.

1. Point your browser to: www.YOUR_DOMAIN.com/webmail
   Be sure to replace, YOUR_DOMAIN in this example with your actual domain.

Additional Information
 

• Horde: www.horde.org
• Squirrel Mail: www.squirrelmail.org
• Wikipedia Web Mail: en.wikipedia.org/wiki/Webmail

{mospagebreak title=MS Outlook}

Here are the email settings for Outlook and other email applications. If you don't know if you want POP3 or IMAP, choose POP3. That is what most people use. The main difference is that POP3 will download all new email to your local computer while IMAP leaves the messages on the remote servers. IMAP can be helpful if you travel a lot and need to access email from many different computers.

Note: In the following examples, replace YOUR_DOMAIN with your actual domain.

• POP3 or IMAP Server: mail.YOUR_DOMAIN.org
• SMTP Server: mail.YOUR_DOMAIN.org
• User: Your_Account@YOUR_DOMAIN.org
• Password: Your_Password

Important: Check the box: 'My outgoing server requires authentication.'

Here is an online video tutorial that shows how to configure Outlook 2003.

Incoming Mail Protocols: POP3, POP3S (SSL/TLS), IMAP, IMAPS (SSL/TLS)
Outgoing Mail Protocols: SMTP, SMTPS (SSL/TLS)

Should you use POP3 or IMAP?

If you don't know which you prefer, choose POP3. That is what most people use and are comfortable with. The difference is that POP3 will download all new email to your local computer while IMAP gives you the option of leaving the messages on the remote email server.

IMAP is helpful if you travel a lot and need to access your email from different locations. POP3 is preferred if you primarily work in one location or if you want to be sure that all your email is stored on your local computer.

In the following example, please replace account with your email user name, and school.org with your domain name. 

Account Settings Window

Account Name: account@school.org
Your Name: account
Email Address: account@school.org
Reply-to Address:  account@school.org
Outgoing Server:  mail.school.org
Other settings in this window are optional

Server Settings Window

Server Type: IMAP
Server Name: mail.school.org
User Name: account@school.org
Use secure connection: Never
Other settings in this window are optional

Outgoing Mail Server

mail.school.org  (server requires authentication)
Important: Check the box: 'My outgoing server requires authentication.'

• Outlook 2003 Settings Tutorial.
• Thunderbird Settings Tutorial.

Note: The following settings are for sites hosted at 1and1.

Enter the following settings in your email application (Mozilla Thunderbird, Microsoft Outlook, Outlook Express, etc.). Note that our email server is compatible with both POP3 and IMAP protocols. If you don't know which one you want, choose POP3. The main difference between them is that the POP3 protocol will download all new email to your computer while the IMAP protocol leaves the email on the remote server.

POP3 Configuration

To configure an e-mail client, such as Outlook, for POP3 protocol, you will need the
following information:

Server Type: POP3
Incoming Server: pop.1and1.com
Outgoing Server: smtp.1and1.com

E-mail Address: Your e-mail address
User Name: The email address can be used
Password: Your e-mail password

Note: The outgoing server needs to be authenticated with username and password.

IMAP Configuration
Email Address: <enter the email address assigned to you>
Account Name: <enter the email address assigned to you>
Password: <enter the password assigned to you>
Incoming server (IMAP): imap.1and1.com
Outgoing server (SMTP): smtp.1and1.com

Example

The following is only an example. Do not use these exact settings.

Email Address: yourname@organization.org
Account Name: yourname@organization.org
Password: yourPassword
Incoming server (POP): pop.1and1.com
Outgoing server (SMTP): smtp.1and1.com

Note: You can also access your email from anywhere on the Internet by pointing a Web browser to:
http://webmail.1and1.com

1. Ask your Site Coordinator to send a request for a new email address. Include the user name you wish to use and a temporary password.
2. As soon as we receive the request, we will create the new email address with the temporary password.
3. The new user should then log into their account using the Webmail interface at webmail.1and1.com and change the temporary password to one of their choice.
4. The user adjusts the email settings on their local computer as required.

Note: The Webmail system allows users to access their email from anywhere on the Internet. In Webmail they can read and print their email, store email in folders, change their password, setup a forwarding address, and adjust spam settings.

Go to your site and add '/webmail' to the end of the URL. In the following example, be sure to replace 'example' with your actual web site address.

http://www.example.org/webmail

Right here!

This can occur when the eQuotes text file is saved using the wrong line ending format. Be sure to save your file using the correct file format for your production (live) Web server. In most cases this will be the UNIX file format.

Yes, Each element (quote marks, quote, author, and source) can be individually styled using the site templete's CSS file. Here is a set of example tags. You can also add HTML tags withing the text of the quotation.

Sure. Here's a short example.

eQuotes file format is designed for ease of use. It uses a cvs-style file format. Be sure to save your file with the line ending required by your Web server. The field order is critical, and follow the following pattern:

quote | author | source | keywords, more keywords, and finally this, word

Only the quote field is required. All other fields are optional and will not display if empty. You do not need to add extra bars around blank fields unless they are followed by fields that do contain data. In the following example the first record contains unnecessary separators, which are ignored. The two records are essentially identical.

My cute random quote. |||

My cute random quote.

Blank lines are ignored; they will not result in blank quotes. In the interest of keeping the files quick and easy to edit, comment lines are NOT supported. Please note that although you can add keywords, this feature is not yet implemented.

The component integrates with the Joomla database and thus provides additional management features, such as the ability to Publish and Unpublish individual quotes, and the ability to add new quotations via the Back-end Web interface. The optional eQuotes Search plugin only works with quotations stored in the database.

The module is set to work as soon as it is installed and published. After installing the eQuotes module, you must 'Publish' it in an active template position.

Well, it's not perfect. It was built to scratch one person's itch, but it has proven popular among many site owners, and is currently one of the most popular extensions in its category. There are many ways eQuotes can be improved and development is continuing. You can view the code or join the project on the Joomla! forge.

eQuotes is a popular and highly-rated Joomla! extension released under the GNU/GPL license that provides comprehensive administration and display of quotations.

eQuotes is derived from DailyQuotes and Random Quotes. While each of these extensions does one thing well, the goal for eQuotes is to grow into a full-featured quotes extension. This is done by trying to combine the best features of each along with additional features.

eQuotes is currently available for Joomla 1.0x, but another version for Joomla! 1.5 with significant new features will be released by the summer of 2008. For more information, see the eQuotes Roadmap.

There is a known bug in one version of the calender which causes all events on the same day to display the information from the most recently edited event. There is a simple patch to fix this. the patch has been applied to all sites.

This is done using the JCalPro Latest Events Mambot, which places the upcoming events inside a content item. Output options may be configured similar to the Latest Events module. The core component and the latest events module (published or unpublished) are required for the proper operation of this mambot. Following installation, publish the mambot and change any parameters as required. To place the output in a content item, copy the following markup into the appropriate location in your content item text:

{jcal_latest}0{/jcal_latest}

0 (zero) = the event category ID or comma-separated list of category IDs you want displayed in the content item. Use "0" or blank to display events from all categories.

Examples:

Display all published events is all calendar categories:

{jcal_latest}0{/jcal_latest}

or

{jcal_latest}{/jcal_latest}

Display all published events for the calendar category with the ID of 1:

{jcal_latest}1{/jcal_latest}

Display all published events for the calendar categories with the IDs 1, 2 and 5:

{jcal_latest}1,2,5{/jcal_latest}

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

Resources

1. Text Unescape Utility
2. HTML URL-encoding Reference

Check the active processes

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

Check crontab

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

Check for hidden files or directories

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

Introduction Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

Joomla! 1.0.13 Enhanced Password SystemInitial tests indicate that the method described here also works with Joomla! 1.0.13 salt-enhanced passwords. This is because Joomla! automatically updates password data from earlier versions to the 1.0.13 format.

Directions

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account.

4. Copy and paste a known MD5 hash, such as one of the samples provided with this FAQ, into the password field. Warning: You must paste the password's hash value, not the password itself. You can use any of the following password = hash pairs, or create your own using one of the tools listed below.

5. Save the record.

6. Point your browser to your site and log as the administrator using your new password.

7. Once logged in, you should change the password again to one that only you know.

Generating your own MD5 hash from a password of your choice

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

Online MD5 hash creation tools

• JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
• MD5er - http://www.md5er.com/

Free MD5 utilities for download

• MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
• SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

Other MD5 tools

• There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

This is the general process we follow when recovering a compromised site. Following all the steps takes more time, but ensures that the site was fully recovered. We take nothing for granted and asume that the entire site is exposed.

1. Change all relevant passwords: Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
2. Check raw logs: Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
3. List recently modified files: Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
4. Note suspicious newly-created files: Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
5. Note suspicious recently-modified files: Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
6. Check for bogus CRON Jobs: Hacked cron jobs can be setup to reinfect your site over and over again.
7. Coordinate with your host: If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
8. Delete the entire public_html directory: This is the best way to guarantee that every potential vulnerability in that directory is removed.
9. Delete related database records: This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
10. Reinstall everything: Use pre-attack backups. If you don't have good backups, go on to step 10.
11. Reset critical passwords again: You must reset your passwards again now that your server is finally cleaned of all possible hidden trojan horses.
12. Rebuild site: If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
13. Review security processes: Follow standard security precautions for all installed applications.
14. Review and test the backup process: If you don't already have one, add a dependable backup and recovery process to your administration practices. Don't forget to test the entire backup and recovery process.
15. Stay watchful: Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.Add other security measures as appropriate.

Overview

Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one execption to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

From the official PHP site

"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now." More Information

1. Official PHP Manual: PHP Security and Safe Mode Configuration Directives
2. Official PHP Manual: PHP Functions restricted/disabled by safe mode

Might as well get it from the horse's mouth. In Do you PHP?, Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."

Caveats

1. Your server must allow .htaccess files for this technique to work.
2. If you do not have a .htaccess file in your root directory, see the related FAQ first.
3. Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
4. Hot linked images can only be replaced by other images, not with HTML pages.
5. As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

Directions

1. Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
2. Place the following code in the .htaccess file of your root directory.

Explanation

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "No Case", which means, match upper and lower case characters. The third line allows empty referrals. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image. Block hot linking from specific domains

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

Display a 403 forbidden code

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

Introduction

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

Directions

1. First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
2. Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
3. Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
4. Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

More Information

• Official PHP Manual: How to change configuration settings
• Official PHP Manual: List of PHP INI directives

Overview

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

Directions

1. In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
2. Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

• Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

• Optional: You can add multiple addresses by separating them with comma's.

Overview

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

Caveat (From Apache.org)

Basic authentication should not be considered secure for any particularly rigorous definition of secure. Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

Directions

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first. Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you can not use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

.htaccess Generator: http://www.webmaster-toolkit.com/htaccess-generator.shtml

Overview

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

IMPORTANT CAVEAT: One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

Requirements

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host. 2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host. 3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

Directions

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file.

4. Point your browser to: http://www.mysite.com/joomla.html

(Replace 'mysite.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a sub-domain, for example "test" you need to modify .htaccess as follows:

Introduction

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

Directions

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

Overview

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box usually works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

Resources

1. Official ModSecurity Site
2. ModSecurity and Apache

Using the UNIX shell

Note: The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a