1. Create strong passwords. You should change your administration password often and use a combination of upper and lowercase letters and numbers. Avoid using dictionary words, and make sure your password is at least eight characters long.

2. Monitor crack attempts. If you have your own VPS or dedicated server, you can run TripWire or SAMHAIN to frequently check for attempts to comprise your server’s security.

3. Create scripts to automate security tasks. With a busy schedule, you may forget to check for new versions of Joomla and any extensions you have installed. Setup scripts to make the process automatic.

4.. Check logs often. Many times, simply looking over access and error logs can reveal thinly-veiled attempts to intrude on your server, particularly if the attacker is trying to do so through a web application like Joomla.

5. Run checks for SQL injection vulnerabilities. There are free tools on the web that will perform these checks for you.

The important thing to remember is to always be diligent. Create a security routine and stick to it. Do not let months go by before you decide to check on your Joomla installation. You may find your site has already been comprimised.

Source: Joomla Security Checklist

When a website relies on the client’s browser or plugins to execute the script, the assumption is that the necessary plugins or features are actually installed and enabled. If the user does not have the necessary requirements or chooses not to use them, those features on the site will be unavailable. Examples of client-side scripting include Java and Adobe Flash.

With server-side scripting, everything happens internally before the user ever sees the site. By the time the user gets to the page, it is already displayed correctly, and it will be the same content for every user. They do not have to download any extra tools or plugins. Examples of server-side scripting include PHP, Perl, and ASP.

Photo Source: Wikimedia Commons

Are extensions and plugins a security risk? How can you make sure they do not hurt other users or the server? Like with any security issues, there are general precautions you can take.

1. Make sure the user has no additional privileges outside of his or her chroot environment.
2. Remind users to check the permissions on scripts so that attackers cannot use them to piggyback onto another system.
3. Do not allow root login under any circumstances.
4. Keep an eye on logs to see if any scripts are behaving unusually.
5. Disable scripts with known problems, and direct users to viable alternatives.

Absolute Paths

There are two types of absolute paths you will encounter. The first is directly related to the Web and the website’s domain name. For example, the path to myfile.html might be:

http://www.mywebsite.info/folder/folder3/myfile.html

On the server, the absolute path would be something like:

/home/user/public_html/folder/folder3/myfile.html (useful in configuring scripts)

Relative Paths

With a relative path, the server looks at where the user currently is then moves either forward deeper into a directory or goes up to any number of parent directories. For example:

folder3/myfile.html

Inside the html file, you might need to link to an image in a directory that is two steps higher:

../../images/myimage.jpg (which is the absolute path: http://www.mywebsite.info/images/myimage.jpg)

With this knowledge, you should be able to link within documents and configure scripts.

For example, a script may require write access to a temporary directory, and the instructions may call for you to chmod the directory 777. What this means is that anyone can read, write, and execute commands to the directory, including complete strangers. While such permissions might be necessary for a public repository, they are not for most web-based scenarios.

If the server or a particular authenticated user needs write access for a directory, chmod it 664. This means that the owner and the user group will be able to write to that directory, but others will only be able to read its contents. If you ever need something to be completely locked down and not readable by the outside world, make the last digit a “0”. Stay tuned to this blog for more chmodding tips in the future.

Photo Source: Flickr

Ideally, script installation should be fast, easy to use, and should be simple and direct, avoiding any hacks that make the installations incompatible with normal installations (in case the user ever needs to move their data to another server). But not all hosts are equal in these areas.

Go Daddy, for example, is a well known and highly advertised host, but their control panel scripts installation is mediocre at best. When a user sets up an installation of a script, Go Daddy’s control panel will queue it and make the user wait an undetermined amount of time before the script is actually installed. It is very slow and can be frustrating to a website owner who purchased an account expecting clean and fast script installation.

1. Use one of the gallery scripts supplied and installed by your web hosting provider (if available)
2. Download a free or commercial gallery application and install it on your server
3. Use a third-party photo sharing or gallery hosting site.

The advantage of a locally hosted gallery on your own server is that you can usually easily export your gallery and take it to another host. You also have full control over customization and features (especially if you are using an open source product). With option #1 the biggest disadvantage is that you are limited to whatever your web host provides, which may or may not be available if you switch to another host. The disadvantage of #2 is that you are responsible for updates and maintaining the security and stability of the gallery.

Option #3 eliminates the disadvantages of #1 and #2. Your gallery is maintained by another company and hosted on a remote server. You never have to worry about upgrades. The big disadvantage is that you do not have control over your own content and may not be able to easily export it and take it to another host or gallery.

Photo: Flickr

easyapache – upgrades and reinstalls Apache
addpop – adds a POP mail account
wwwacct – adds a cPanel account
suspendacct – suspends an account
runweblogs – updates statistics for a user
makecpphp – reinstalls cPanel’s internal PHP
cpbackup – backs up all accounts

Other scripts are documented on the cPanel website as well as more specific documentation about updating services. As a warning, cPanel recommends against using any other scripts not listed on their website, although your web hosting provider might install some. If you find a suspicious script, contact your web host.

Source: cPanel Documentation
Photo: Flickr

Answer: cPanel uses its own web-based frontend to make database creation very easy. Just follow these simple steps:

1. Login to cPanel
2. Under the Databases section, click “MySQL Databases”
3. Where it says “Create New Database” enter a short name for your database.
4. Click “Create Database”.

Next, you will need to have a user for the database. If you do not have any users, you will need to create one. If you do, skip to step 4.

1. Scroll down to the bottom until you see “Add New User”.
2. Enter a name and password.
3. Click “Create User”
4. Under “Add User To Database” find your user in the dropdown menu and then find the database you created in the second dropdown menu.
5. Click “Add”.

You have now created a database that will give permissions to the user you created. When you install scripts or applications, they will access the database using the username and password you specified. Therefore, make sure you remember it, but also make sure it is secure.

Answer: It is one of the most dreaded errors Apache can throw at you: the 500 Internal Server Error. When you get it, you often have no idea what caused it or why. Here are a few things you can do to troubleshoot it.

1. Check the location. Make sure you have uploaded the scripts in the right place.

2. Check the upload method. Your FTP program should upload Perl scrips in ASCII not in binary mode.

3. Make sure the file permissions are set to 755 to make the script executable.

4. Often times modifications to the script, if required to configure, can cause an error. You might have slipped in an unsupported character or made a typo.

If it still does not work, try running the script from the command line and see if it spits out an error. If you still cannot figure it out, you might want to talk to the developer. The script just might be incompatible with your server. Most importantly, don’t give up.

Photo: Flickr