Tutorial Web Hosting for Dummies Complete Part III Managing Security and Access
Managing Security and Access
In this part . . .
✓ Understand website security and what you need to do to protect your site.
✓ Master the DNS (Domain Name System) and unleash its power. ✓ Install and configure some of the advanced functions in your hosting.
✓ Manage your hosting on the go with your Internet-enabled mobile device.
Chapter 8 Taking Command of Website Security
In This Chapter
▶ Understanding your role and responsibilities in site security
▶ Knowing when and how to use SSL certificates
▶ Assessing the need for SSH access
▶ Using password-protected folders
▶ Protecting your site from viruses
Nobody likes viruses and malware, but they’re a fact of online life.
Sticking your head in the sand and pretending that the malicious elements of the online world don’t exist isn’t going to help.
In this chapter, I help you see where some of the potential security holes are and provide steps you can take to shore up your defenses before you become a victim.
Accepting That Security Is Your Responsibility
“Security! Security! Come help me, someone’s attacking my site!”
You can shout and scream all day, but no one will run to help. This is your site, your hosting plan — and you’re the head of security. If you haven’t put the security guards in place then you’ve left yourself exposed and it’s too late now.
If you are using a managed hosting service (where you have specifically paid extra for increased server management from your host) some of the security will be covered by the host, and it should be your first port of call in an emergency. Check in advance to find out what the host does and doesn’t do, though, to ensure that you don’t leave your site exposed.
Attacks come in all different shapes and sizes. Viruses, malware, Distributed Denial of Service (DDOS), phishing, creating zombies for botnets, spam sending, and data theft are just some of the types of attacks your server will face.
Attackers can be anyone from a school kid who’s trying to prove that she’s smart enough to hack a server to an organized syndicate that will use your server in any way it can to make money and cause Internet havoc. Attacks can also come from bots, which are servers that run automated programs to scour the Net and find servers so that a set of basic hacks can be tried on each one.
In the same way that there is no way to stop the most resourceful and determined burglar from getting into your house, ultimately there is no way to completely prevent hackers from gaining access to your server. However, just as you can beef up the security in your house to thwart the vast majority of would-be thieves, you can also do a great deal to secure your server and website against all but the most dedicated hackers.
You need to protect two groups of people when creating a website in your hosting space:
✓ Your visitors. People using your site need to know that any personal information they give you is secure and that browsing your site is not going to cause their computers to become infected with viruses or malware.
✓ You and anyone else on the same server as you. If you are on a shared
server, it isn’t just your site that is affected if you get hacked. Hacks often result in huge resource usage on the server, which slows everyone’s sites down. If your site is hijacked and used to send spam e-mail, the result can be that the whole server and all the sites on it are blacklisted, meaning they can no longer send e-mail.
If you don’t take steps to protect these two groups, you will eventually get hacked, and your visitors and neighbors on the server will feel the pain of it as much as you do.
Act now to build the barricades before the barbarians get in!
Protecting Your Visitors with SSL Certificates
Secure Socket Layer (SSL) certificates are easy to buy, and they give your customers the peace of mind that any personal information they send to you is encrypted and secure.
The purpose of an SSL certificate is to show that the site the visitor is looking at is trustworthy (that is, made by a legitimate person or company) and also to encrypt information as it is exchanged between the visitor and the server to prevent anyone from intercepting and stealing that data.
Recognizing when you need SSL
SSL certificates are not needed for any sites that are purely informational. You only need to install an SSL certificate if you are asking customers to supply you with personal information.
Here are a few example scenarios that illustrate when you do not need an SSL certificate:
✓ Your site simply shares news about your organization or is there to promote your business visually without taking customer feedback.
✓ You have a blog on which people leave comments including their names and e-mail addresses. For the majority of web users, a name and e-mail address are fairly impersonal. If someone steals that information, there’s not much the thief can do with the information to hurt the owner. An SSL certificate is an option for protecting comments, though, if you’re really security-conscious.
✓ You have a contact or feedback form on your site that asks for the person’s e-mail address and name. Again, these details are not sufficient to require encryption.
And here are some scenarios in which you do need an SSL certificate:
✓ You have a form on your site that requires extra information, such as a username, phone number, or ID number. Many sites request information like a phone number but do not make it mandatory. SSL certificates will help protect their visitors, but because giving the information is optional, the site is not exposing itself or its visitors to too much risk if there is no SSL certificate. If the information is required, though, you should definitely protect the transfer of that information using an SSL certificate.
✓ Your customers/clients can create an account on your site into which they enter personal details such as their addresses, birth dates, or phone numbers. If you don’t have a certificate, your visitors may as well take out an ad in the newspaper to tell everyone their personal information. The risks are simply that high.
✓ You accept payments by credit card. Although most sites that accept credit card payments already have SSL certificates because they are receiving and storing personal data, there are some sites on which you can use a credit card without creating an account. These sites need SSL encryption so that the credit card details cannot be intercepted and stolen.
Store as little customer information as possible. The more personal data you have on your server, the higher the risks and consequences to your customers if your server is hacked. Even if you accept credit cards, it’s safer for everyone when you don’t store the details.
A good rule of thumb is to consider whether the data you are taking from your customers is something you’d want to say out loud in a public place if it was your information. Your name and e-mail address are fairly inconsequential, but anything more than that you probably wouldn’t want the world to know.
If you wouldn’t say it out loud in public then you need to get an SSL certificate to protect it.
How SSL certificates work
Without getting overly technical and in-depth, your browser goes through four basic steps to ensure that the connection is secure:
1. It checks the address of the site and its IP address against the details on the certificate.
2. The server and the browser interact to determine what encryption types they can both support and agree on one to use.
3. The server and the browser supply each other with unique codes to use when encrypting and decrypting data sent between them.
4. The browser displays a confirmation in the address bar that the connection is secure, and all data is then sent encrypted.
When a connection is secured, it uses a slightly different connection protocol known as HyperText Transfer Protocol Secure (https). This replaces the standard http protocol and you will notice that the web address now starts https://. If the https:// is colored red, it means the site is attempting to use the secure protocol but the certificate is not valid or not recognized so the connection may not be secure.
Depending on the level of security you purchase, the visitor’s browser displays different confirmations in the address bar:
SSL certificates must be purchased from a recognized Certificate Authority (CA); otherwise, your visitors’ browsers will not authenticate them. There is an extensive list of trusted CAs, each of which can have multiple brands attached to it.
The three main international players in the certificate market have a number of different brands associated with them, including the following:
✓ Symantec: Equifax, Thawte, VeriSign, and Geotrust
✓ GoDaddy: GoDaddy.com and Starfield Technologies
✓ Comodo: Comodo CA and UTN-USERFirst-Hardware
Your browser can give you a list of its trusted certificate authorities. For example, in Firefox, go to Options➪Options➪Advanced➪Encryption➪View Certificates.
Choosing the right level of security
SSL certificates come with different levels of security, ranging from very basic security all the way to air-tight-no-leaks security, with prices ranging from free to hundreds of dollars per year.
Although there are some standards in place for Extended Validation (EV) security, which is the highest level of security, each company defines its own security levels for its certificates and its own prices.
One of the biggest differences between the security levels is the way that they validate who the purchaser of the domain is. The simplest form of validation is done immediately online and is essentially self-validation. The certificate issuer takes it on faith that you are who you say you are. The highest level is EV security, a level for which standards have been agreed upon between the companies that issue the certificates. Validation can take weeks because they check, among other things, whether your company physically exists and is operational, if it currently has control of its own domain name, and if you are an authorized agent of that company.
The following list includes three security levels and what they might entail so that you have an idea of how to compare the different certificates. Each level is more trustworthy than the one preceding it and thus is more expensive.
✓ Basic: Purchased with online automatic validation, no paperwork, no faxes needed. 2048-bit digital signatures and 99.9% browser recognition with a $250,000 warranty.
✓ Wildcard: Full business validation, 2048-bit keys with 128/256-bit encryption, 99.9% browser recognition, and covers all subdomains for your domain with a $1 million warranty.
✓ Extended Validation (EV): The highest level of business validation plus a green address bar and $1.5 million warranty.
As you look at the different certificates that are offered, bear in mind how big your customer base will be and how critical the data you will transfer and store is.
You may feel you need a certificate to cover a feedback form that collects a user’s name and address, but a top-of-the-line extended validation certificate is probably overkill for just those details.
Sourcing an SSL certificate
You can buy certificates from a whole host of different places, and you are free to shop around and buy your certificate from your preferred seller. Buying a certificate from your web host, though, is sometimes best because installing a certificate isn’t always easy, and your host will be able to help you with certificates purchased through it.
You can purchase SSL certificates directly from the CAs, although this is sometimes the most expensive way to do it because they often are available at discounted prices through resellers such as your host or your domain name registration provider.
There is no real advantage to buying certificates directly from a CA. Where you get your certificate is a matter of whom you prefer to do business with.
Installing an SSL certificate
Installing an SSL certificate may be one of the trickiest functions you will ever have to perform in your hosting. Depending on the level of access your host gives you, you may not even be able to install one on your server, in which case you have to request that your host do it for you.
The installation procedure is different for every CA, every brand, and every certificate level. There is justification for this because, to provide the user with the best level of security, the CA has to make it as difficult as possible for fake websites to trick browsers into believing there is a valid certificate for their fake site.
Correctly installing an SSL certificate correctly involves three required elements — and sometimes a fourth element:
✓ A Certificate Signing Request (CSR)
✓ The certificate itself
✓ A private key
✓ An intermediate CA certificate (sometimes required)
The purchase and installation procedure may or may not require you to generate the CSR and private key.
I’m sure I’m making this sound incredibly complicated, and that’s because it is. There is no way to give you a generic step-by-step guide that will work regardless of the combination of CA, server software, and certificate type you choose. You should follow the certificate provider’s instructions — and follow them to the letter; otherwise, the certificate will not work.
Firewalls
The term firewall is often used in computing without much of an explanation. In simple terms, a firewall is a digital wall protecting a computer that allows legitimate users in and repels any unwanted invaders.
I always picture it like a scene from the old Batman TV show. The Batcave had a secret door which opened in a rock wall to allow the Batcar through, which then closed again behind it. I imagine a wall of fire instead of a rock wall protecting the Batcave. In this imaginary scene, Batman and Robin are being chased by a bad guy. As they approach the firewall, Batman presses a button on a remote and for a brief moment the fire disappears to give him time to pass through unscathed. The fire then rises again and stops the bad guy from catching him.
This is in effect what happens with the computer firewall. Unfortunately though, your assailants are more resourceful than the bungling villains on Batman and, given enough time, will find a way past the defenses.
That said, firewalls are essential because they hold off any but the most determined attackers.
If you are on a shared server, your host should already have a firewall installed. There are both hardware and software firewalls, and shared hosts should automatically install both.
If you are on a Virtual Private Server (VPS) or dedicated server, your host should have provided a hardware firewall that is built in to the router. Your host may or may not have switched on a software firewall for you, so you should check with the host or examine your control panel to see if a software firewall is running.
With cPanel, you cannot install a software firewall unless you have access to the backend administration panel called Web Host Manager (WHM). You should have access to WHM if you are using cPanel on a VPS or dedicated server.
Use the following steps to check in WHM to find out if you have a firewall installed:
1. Log into WHM using the details your host provided.
2. Scroll to the bottom of the page.
3. Look for a heading named Plugins in the menu on the left.
4. Look for ConfigServer Security & Firewall (CSF) in the Plugins section. CSF is the default firewall for WHM and should be listed under Plugins
(see Figure 8-3).
It is possible that your host may have installed a different firewall program. If that is the case then that firewall should be listed under Plugins.
If your server is not running a software firewall, follow the install instructions at www.mysql-apache-php.com/csf-firewall.htm.
After CSF is installed and running, you should go back to the WHM Plugins section and click CSF (see Figure 8-4).
CSF also provides options to allow or deny certain IP addresses and to show the status of the firewall and restart it if necessary.
I have found that it is wise to tell CSF to allow access from your IP address. If you don’t allow access from your IP address, then sometimes CSF will think that you are an attacker and will lock you out. Use the following steps to quickly allow CSF access from your IP address:
1. Go to www.whatsmyip.org.
The site tells you at the top of the page what your Internet IP address is.
2. Copy the IP address.
3. Go back to the CSF manager in WHM and scroll down to Quick Allow. Refer to Figure 8-7 to see where the box is on the page.
4. Paste your IP address into the green box and press Enter.
You can do this for any IP address that you know requires access to the server. Taking this action will save headaches in the future.
A server firewall is not enough for complete security. Ensure that you have a firewall installed on any computer you use to access the server. If you have an internal network at your office, then each computer should have its own firewall to help prevent the spread of any viruses that do get through.
Protecting Your Site by Locking the SSH
Secure SHell (SSH) is a network protocol to allow secure data communication. In effect, it is like a back door into your system — one that should remain locked unless you really need to use it.
There is no point in locking and bolting the front door of your house if you’re going to leave the back door wide open. Any thieves who are thwarted by the front door will find another way in simply by walking around the outside of your house.
In fact, if a burglar sneaks in the back door, you are less likely to notice him than if he walks through the front door.
This is also very much the case online, and so backdoor security is something you really need to take seriously.
SSH enables you to create a secure connection to log in to your server remotely and to execute commands on it. If a third party gets your password, that third party will also have unrestricted access to your server.
In Chapter 16, I show how to connect to your server through SSH and give you some basic commands to use. For now, you just need to decide whether SSH is necessary for you and figure out how to switch it on and off.
Determining whether you need SSH
Most hosts do not allow SSH access on shared servers simply because it is too powerful and opens the door to too many potential abuses and risks. If you are on a shared server and require SSH access, contact your host to discuss granting you access.
If you have a VPS or dedicated server, in most instances your host allows you to decide for yourself whether you want to allow SSH access and, if so, who has access and how access is granted.
Look at the following four things when securing SSH:
✓ Does anybody need SSH access to your server? If not, then simply deny all users SSH access so nobody can use it regardless of who she is. ✓ If only certain users are to be given access, you can limit access by username so that only approved users can gain entry. If, however, hackers can discover an allowed username, this provides a potential entry point for them.
✓ You can allow only certain IP addresses SSH access. This then limits where SSH access can come from and the users would still be required to provide authentication. The disadvantage of this is that most home users do not have a fixed IP address. Although that IP address may stay the same for a long time, their Internet service providers (ISPs) can change the IP address at any time. If that happens, you would have to reconfigure SSH to allow the new IP address.
✓ SSH access can be granted by username and password or by a username and key system. Keys are generated in pairs; the server holds a public key and the user provides a private key that only allows access if it matches the public key. The public key and private key are not the same. They are like a jigsaw puzzle, and when a user tries to access the server using a private key, access is only granted if the private key and public key fit together like two pieces in a puzzle.
Configuring SSH
Naturally, exactly how you configure SSH is different on every variety of web hosting software, but as an example, here is how to configure it using cPanel.
1. Decide who, if anyone, will be allowed shell access.
Each control panel handles access slightly differently, but essentially there are three levels of shell access: Disabled, Jailed, or Normal. Disabling shell access for all users effectively means that SSH is unusable on the server. Jailed shell access allows users access but only to areas of the system. (Only advanced users should attempt to configure this as it can be more trouble than it’s worth.) Normal shell access allows full SSH access to the server to that user. As an example, here is how to configure access in cPanel.
1. Log in to WHM (if you do not have access to WHM, ask your host
to enable shell access for your user).
2. Scroll down on the left-hand side to Account Functions, under which you click Manage Shell Access.
3. Select for each user on the system whether they will have normal shell access (SSH), jailed shell access, or disabled shell access. (See Figure 8-8.) measures on your server.
2. Decide which IP addresses will be allowed to connect via SSH.
Most control panels enable you to allow access only to certain IP addresses. This adds another layer of security, but it is not foolproof. To allow SSH access to only certain IP addresses in cPanel, do the following:
1. In WHM, scroll up to the Security Center and click Host Access
Control. Here you can allow or deny specific IP addresses access to any of the services on the server.
2. Type SSHD in the box labeled Daemon.
3. Under access list, type the IP addresses which are allowed
access. You can enter multiple IP addresses or just one. Find your IP address at www.whatsmyip.org
4. In the first action box, type allow.
5. On the next line, type SSHD as the daemon, all in the access list and deny in the action. When a user requests access, the server checks their IP address and then starts at the top of the list to see whether that IP address is specified or not. If it is, it performs the action associated with that IP. If it does not find the IP address listed, it will move down the list searching every line for that IP address until it reaches a line that includes the word all. At that point it will do whatever the “all” line commands. That way, you can essentially tell the server to allow access to specific IP addresses but then deny it to all others. (See Figure 8-9.)
3. Still under the Security Center, click SSH Password Authentication Tweak. Now decide whether or not you wish to allow access via username and password or whether all allowed users will be required to use a username and key combination. The screen will tell you whether or not password authentication is currently enabled, and if it is you can click the Disable Password Auth button to disable it and vice versa. (See Figure 8-10).
4. Whether or not you have SSH password authentication enabled, you can still generate keys and use those to connect. This is a more secure method of connecting. To set the key for the root user in WHM under the Security Center, click Manage root’s SSH Keys. In here you can generate a new key. Other users must generate their own keys by logging in to cPanel as the user and under the Security section clicking SSH/Shell Access. (See Figure 8-11)
Generating SSH Keys is fairly simple in any control panel and the information required is always the same. Here’s how it’s done in cPanel and WHM:
1. In cPanel, click SSH/Shell Access, then Manage SSH Keys; in WHM, click Manage root’s SSH Keys, then Generate Key.
2. Provide a name for the key.
This name is for your benefit in the future so you know which key is which. Name it something which will be self-explanatory to you when you return in the future.
3. Type a password for your key, and then confirm it in the next box.
Using the password generator will give you a very secure password, but it will be hard for you to remember if you ever need it in the future. The password strength indicator shows you how strong your password is.
The system can be set to only allow passwords over a certain strength.
4. Now select the key type.
This is either Digital Signature Algorithm (DSA) or RSA (RSA stands for
Ron Rivest, Adi Shamir and Leonard Adleman, the original creators of
the algorithm). Both are encryption algorithms. DSA generates keys faster, but RSA is faster for verification when you log back in again. Which you choose is up to you.
5. Select your choice of Key Size from the drop-down box.
The key size can be 1024, 2048 or 4096; this is the length (in characters) of the key. The longer the key, the more secure it is. It is recommended that you use at least 2048 for RSA key types; I recommend always using the highest number possible to make the key as secure as possible.
6. Click Generate Key.
This returns you to the list of keys that have been generated. If your new key does not appear in the list, then your user has not been granted SSH access.
7. Keys must be authorized before they can be used, so under Public
Keys, click Manage Authorization in the list of keys.
8. The next screen tells you that key is not currently authorized for use to connect to this account.
Change that by clicking Authorize. Likewise, you can deauthorize a key using the same method. (See Figure 8-12.)
You can generate multiple keys for each username. If a number of people log in using the same username, you can generate a key for each person so that if any damage is done in the future, you can see which key was used to log in. Having multiple keys for each username can also be useful if you log in from multiple locations. You can generate a separate key to use at each location, so if one key is compromised you know which location is the source of the problem, and you can strengthen your security there.
9. Download your private key by clicking the View/Download key under private keys.
This will display your key.
10. You can either copy and paste the text into a file you create on your
own computer or you can click Download Key to download a text file.
Depending on how you are connecting using SSH, you may require a key in Putty Private Key (PPK) format, the format used by PuTTY to store keys. If so, type the password you used when creating the key into the box and click Convert. This generates the key in PPK format for you to copy and paste or download as necessary.
If your SSH software has generated a set of keys for you, import these keys through the key manager by clicking the Import Key button.
In some control panels — such as the latest version of WHM — you cannot directly add or delete keys for other users. You can, however, delete the keys by navigating to the .ssh directory within the user’s home directory. Deleting any files in there with a .pub extension will stop the user from being able to authenticate that key in the future. See Chapter 15 for details on how to find a user’s home directory.
You can also add security to SSH by changing the port required to connect to the server via SSH. The default port number is 22.
It may be tempting to simply disable the SSH service altogether. Although this is possible and shouldn’t damage your system, it may make your system harder to administer in the event of a failure. Very occasionally, major errors occur, and the only way to fix them is through SSH. If that is the case, there would be no way to restart the SSH service to allow you to connect: You would be completely stuck.
Securing Uploads with SSH
SSH is good for creating a secure connection through which you can remotely manage your server, and it can also be used to provide secure File Transfer Protocol (FTP) access, too.
FTP, which I explain in detail in Chapter 4, is used to transfer files to and from your server. It is a quite insecure method of transfer and can be exploited with such things as man-in-the-middle attacks to enable external users to read the data that is passing between you and the server.
Secure File Transfer Protocol (SFTP) overcomes this by creating a new FTP protocol that sits on top of the SSH protocol and derives security from the SSH protocol.
Strangely, on most hosting systems, SFTP works even if SSH has been disabled for all users. This is because SFTP allows only certain commands to be sent, which means that even though it is using SSH for security, it is not providing the exploitable access that using SSH to remotely connect normally provides.
For details on how to use SFTP, see Chapter 4.
If you want to disable SFTP then you need to edit the /etc/ssh/sshd_ config file and comment out the following line:
Subsystem sftp /usr/libexec/openssh/sftp-server
You then need to restart the Secure Shell Daemon (SSHD). In cPanel, do this by logging into WHM and scrolling down on the left to Restart Services and clicking SSH Server and then Yes. (See Figure 8-13.)
What this does is disable the SFTP subsystem. This basically means that when a user attempts to connect via SFTP the initial handshake will be done but then the connection will be closed and no commands can be sent.
If you do not wish to use SFTP you should disable the SFTP subsystem but not the SSH service. Although disabling the SSH service would have the same effect, it could cause problems in other areas and ultimately could result in your whole system being disabled.
Protecting Folders with Passwords
One of the most overlooked functions of server security is the capability to password-protect certain folders at the server level.
In the UNIX/Linux operating system, you can protect folders and files using file permissions. You can add an additional level of protection for web users, allowing them access only to the pages in a folder if they have the correct password.
Sometimes people want to protect certain areas of their websites and they do this by using a password-protection system on the site itself: This is a perfectly valid way to achieve that level of protection. However, you do not need to add the extra software to do that through the website; the server already has the facility built in.
All web servers provide this functionality, and it is activated in a similar way across-the-board. In cPanel, you complete the following steps to add password protection to files and folders:
1. Log into cPanel and scroll down to the Security section.
2. Click Password Protect Directories.
3. If a box pops up, select the domain that you want to protect.
4. Select the folder you want to protect.
In cPanel, directories can only be protected if they are directly in the
web root. Note that all subfolders of the folder you protect will also be protected by the same password.
Note that in cPanel the word Directories is often used, but in this case the term is folders. The two words can be used interchangeably. Techies tend to call them directories, but when you are viewing a directory structure using a Graphical User Interface (GUI), icons are used and the icon for a directory is a picture of a folder. Therefore, for ease of understanding for web users, the word folder is used to match the picture.
5. On the password protection page, click the Password Protect This Directory box, give the directory a name, and then click Save.
This name appears when someone tries to access the directory and is prompted for a username and password.
6. Create at least one user for the password-protected directory. Type the username and the password (twice).
7. Click Add/Modify Authorized User.
A confirmation screen appears.
8. Click Go Back and at the bottom of the screen you see the name of the authorized user you just created.
You can now add additional users if necessary. All users created for each folder have the same level of access (see Figure 8-14).
That directory is now password-protected; anyone who attempts to access it at any time will need to provide the authorized username and password.
There is no default or override password. If you forget the password you created, you need to go back into cPanel and modify it or create a new user.
The password protection does not apply to users connecting via FTP or using the file manager through cPanel. It is only for web users viewing pages within the folders.
cPanel’s password protection is created using an .htaccess file. This file is placed within the folder to be protected. Although web users cannot access this file, it can be overridden by another .htaccess file in the public_html directory. Do you think it sounds insecure? Don’t worry; the public_html directory .htaccess file may be able to override the password protection, but a hacker cannot change that file unless he already has root access in the file system. When he has root access, the password protection doesn’t apply to him anyway.
Securing Your PHP
PHP security is the nemesis of all website creators. Everyone is convinced that there must be a way to secure a PHP website against all attacks, but no matter what level of security exists, there is always a hacker somewhere who works out a way around it.
That doesn’t mean you should just throw your hands up and surrender, though. You can do plenty to protect your site, although nothing is ever foolproof.
Remember, most website hacks are done by automated systems, which are written to cruise around the web and try a series of commands for a specific known exploit. To put that in real-world terms, imagine somebody made a master key that could open any lock produced by a certain lock manufacturer during the period November 1998 to June 1999. If locks from that manufacturer were widely used by households, all the criminal would need to do (if he could get a hold of one of these master keys) is go around and try his key in every lock on every house until he found a lock that was made by the right manufacturer during the right time period.
Protecting your house against this attack would be quite easy. You simply need to update your lock, and you can be certain that the key would no longer work.
Most small websites are never going to be attacked by a hacker directly. The attacks come via automated tools that are just poking around to find a site that is vulnerable. This means that you can protect yourself against the majority of attacks by following a few simple rules:
✓ If you have your own server, keep your PHP version up-to-date. How
to do this varies by system. With a cPanel server, for example, either type /scripts/easyapache at the command line or go into WHM and select EasyApache under the Software heading.
✓ If you are writing your own PHP scripts, research how to secure your
scripts. You may not think your scripts have security holes and are vulnerable to exploits, but think again! Plentiful resources online explain how to ensure that your scripts are as secure as possible. Simply search for securing PHP scripts.
✓ If you’re running web scripts or applications such as WordPress, keep
them up-to-date, including any additional plug-ins and theme updates.
✓ Do not install any scripts or PHP modules that you don’t absolutely need. The less PHP you are using, the less chance there is of an exploit being found.
✓ Use the most restrictive file permissions possible without interrupting the normal running of your site. See Chapter 4 for details on setting and managing file permissions.
✓ Install mod_security, if you are able to. You can freely download mod_security to add a level of PHP security. You do have to configure it correctly to allow your software to run. Contact your host for advice on how to configure it.
✓ Lock down your PHP installation as much as possible. There are many configuration options for PHP that you can adjust, depending on what your website requires. A lot of available online resources can help you secure your PHP, including the PHP Security Guide from the PHP Security Consortium, which you can find at http://phpsec.org/ projects/guide/.
✓ Be proactive. Sticking your head in the sand is not a good security measure. Keep your eyes and ears open to learn about new attacks and what steps security companies recommend that you take to protect against them.
Appreciating Your Security Guard — the .htaccess File
I mention .htaccess files earlier in this chapter, but I haven’t yet mentioned how useful and powerful they can be. The .htaccess file is one of a number of files called dot files. This clever name comes from the fact that the names all start with a dot (.). This is unusual because normally the dot indicates the separation between the filename and the file extension (for example, index. php or home.htm).
Dot files are essentially hidden files. The system can access them, but they are normally hidden from view or access by general users. In Chapter 4, I explain how to view dot files using FTP or your file manager. You cannot navigate to dot files through websites, so the files can securely hold configuration information and other security-related commands and data.
The .htaccess file is one that is used to provide an additional level of security to the folder it is in. The directives in an .htaccess file also apply to any subfolders below the folder they are placed in.
Directory trees are hierarchical, and commands in .htaccess files in higher folders will override commands in .htaccess files lower down the tree. The result of this is that sometimes you can create an .htaccess file in a lower folder and find that it seems to do nothing. The first thing to do in this instance is to check higher up the tree to see if there is a command that is overriding the .htaccess file you just created.
The .htaccess file can do many things to help you with website security, such as the following:
✓ Adding authorization/authentication. As the word access in the
filename suggests, you can use the .htaccess file to passwordprotect files and folders often in conjunction with another file called .htpasswd, which stores the valid login details.
✓ Blocking users via IP address or domain name. The .htaccess file can contain a list of IP addresses, domains, spiders, bots, and referrers who are automatically locked from accessing any files in the folder. This can be a good second line of defense even if you have the same users blocked in your firewall.
✓ Controlling directory listing. If a web folder is called by a browser without specifying a filename, by default the user’s browser displays a list of files within that folder. This is sometimes useful, but there are other times that you do not want web users to see all the files in a folder; your .htaccess file can deny permission to list those files.
✓ Rewriting URLs. Due to the nature of how websites and the pages are created, sometimes filenames or the paths to files can become extremely long. The .htaccess file essentially makes a new index that enables users to use a shortened version of the file path that the server can understand and take those users to the correct place. It also can be useful if you make a change to the file structure and want to redirect incoming links to old filenames to the new filenames.
With .htaccess files you can add a level of security and perform certain functions and commands, but .htaccess files don’t always provide the fastest solution in terms of website access speeds.
Some people argue that if you have a VPS or dedicated server and have access to the httpd server config file, it is faster to use that file instead of
.htaccess. This may be true. The problem with .htaccess files is that they are read with every http request and, with each request, the server must look in every folder above the current folder in the directory tree for .htaccess files, which may have commands that override the .htaccess file in the current folder. This results in more file reads and disk searches for every web page that is viewed, slowing down the whole system.
On the other hand, given the global nature of the httpd config file, it may be safer for the novice website owner to steer clear of that file so other settings are not accidentally messed up. Also not everyone has access to the httpd config file, so .htaccess provides a more universal way for site owners to add security and make certain changes.
You can modify .htaccess files using a command-line editor, such as vi, or via the file manager or FTP.
The changes you should make depend entirely on your server setup and your website. Research what you need, including the correct commands and syntax to use for your specific application.
Some control panel functions automatically add lines to your .htaccess file. You should not remove these unless you want to disable that function. For example, when creating password-protected directories, the directory protection is set up by creating an .htaccess file in the directory you want to protect. Deleting a file or removing the lines that have been added to it will remove that protection or, even worse, stop legitimate users from being able to authenticate themselves.
Doing Your Part in Avoiding Viruses
The final necessity for becoming the king (or queen) of network security is that you do your part to avoid viruses and malware. This means doing a handful of things, which are really just common sense:
✓ Follow the suggestions I explain in this chapter on securing your site. Many hackers do not try to extract information from your site, but rather attempt to gain access so that they can place viruses or malware on your site, which will then attack your users and other servers.
✓ Be cautious about what sites you visit and what you download and install, both on your server and your own computer. Quite often, you can become infected by a virus without any warning and without knowing it happened. Increasingly, though, your browser warns you if the site you are visiting is known to harbor viruses or malware. If you continue to visit those sites and ignore the warnings then do not be surprised if you later find that your computer and your website become infected.
✓ Keep your login names and passwords as secure as possible. Do not give them out to anyone you don’t trust. You should also change passwords and even usernames on a regular basis and delete any usernames that are no longer required. Making these changes minimizes the chances of a virus or malware network getting hold of your usernames and passwords and exploiting them.
✓ Maintain updated antivirus software and firewalls on all the devices
you use to connect to your website. Computer viruses are like human viruses — they are infectious and spread on contact. Running up-todate antivirus software keeps you inoculated against all but the newest viruses and thus saves you from becoming a carrier who infects other devices.
Please remember that the web server you are hosting is on is just a computer. You may be the only user of that computer or you may be one of many. Either way, it is your responsibility to do all you can to ensure that you keep that computer safe from the viruses, malware, and hackers that will try to attack it.
Chapter 9 Decoding Domains and DNS
In This Chapter
▶ Breaking down DNS so anyone can understand it
▶ Figuring out when to buy extra domain names — and what to do with them
▶ Altering and updating DNS records
When designing the architecture of the Internet, the single most important requirement was that it had to work. By work, I mean it had to
enable anybody who connects to it to easily navigate to any resources on it. The second most important requirement was that it needed to keep working with as much resilience and redundancy as possible, while being fast enough to be useable.
To the human eye, the Internet is simply a place where you type in recognizable names and those names take you to websites; however, a lot goes on behind the scenes to make it work in computer terms and yet keep it as simple and intuitive as possible for human users.
This chapter starts by delving behind the scenes to show you how the Domain Name System (DNS) works and what it does for you. Then it shows you how to manipulate the DNS to make your website faster, more resilient, and generally more awesome.
Understanding DNS
Every device attached to the Internet has a unique Internet Protocol (IP) address, just like every house has a unique address.
Plenty of houses in the world have the number 1600 and there are probably quite a few with addresses of 1600 Pennsylvania Avenue. That said, there is definitely only one with the complete address of 1600 Pennsylvania Ave., Washington D.C.
So, while having only part of an address could lead you to the wrong place, when you have the complete address you know that you’re looking at an absolutely unique address.
You can give that address to anybody, anywhere in the world, and he or she would be able to use it to travel to and locate the building you want that person to find. IP addresses are designed to be just as unique as complete snail-mail addresses. You can give an IP address of a device anywhere in the world to any machine connected to the Internet and the device that receives that information will be able to navigate its way there due to the way the Internet is designed and the uniqueness of each IP address.
The server your website is on has an IP address, and the unique nature of this address is critical to enabling web users to find your website.
For normal use, you don’t have to type IP addresses into your browsers to find websites because the DNS maps website names to the IP addresses of the servers they’re on. So instead of saying, “I want to go to 74.125.224.103,” you can simply say, “I want to go to Google.com.”
We do the same translation in real-world addresses. You would not normally say, “I’m going to 1600 Pennsylvania Ave., Washington D.C., U.S.A.” You would simply say, “I’m going to the White House.” The only time you need to use the White House’s address is if you don’t already know where the White House is.
Remember the days when, if you wanted to know where somebody lived, you looked up his name in the local (and often cumbersome) phone book, in which his address and phone number were listed beside his name? If I wanted to go to Joe Schmoe’s house and I didn’t know where Joe Schmoe lived, I would simply open the phone book, search through the alphabetically arranged names for Joe Schmoe, and the phone book would show Joe’s address. (Okay, okay — I know sometimes addresses are unlisted even when a phone number is provided, but work with me here as I provide this generalization to help make my point.) The Internet provides a system very much like this, the DNS, albeit it’s a little larger and more complicated than a simple phone book.
Is your address fully qualified?
For the Internet to be able to give you the IP address of the exact server you need to connect to in order to visit the site you want, you need to provide a complete website address. This is called a Fully Qualified Domain Name (FQDN).
An FQDN is comprised of three parts:
✓ A hostname
✓ The domain name
✓ The extension, which is also known as the Top-Level Domain (TLD) For example, the domain www.dummies.com has the following components:
✓ The hostname is www.
✓ The domain name is dummies.
✓ The TLD is .com.
Here in the Western world, people read from left to right, but when searching for a website your computer actually reads the address from right to left — and here’s why:
The foundations on which the Internet is built are a set of servers called the Internet Root Name Servers. There are 13 root nameservers and they have a critically important job: Root nameservers deliver one fairly small file (the Root Zone File) to any computer that requests it.
The Root Zone File contains the IP addresses of another set of servers called the TLD nameservers. There are a number of types of TLD, the most common of which are the following:
✓ Country-Code Top-Level Domains (ccTLD): These are comprised of two
letters preceded by a dot and they are internationally recognized as the code for a specific country. These were set up by the International Organization for Standardization (ISO) and are known as the ISO 3166 codes. For example, .au represents Australia and .uk represents the United Kingdom.
✓ Internationalized Top-Level Domains (IDN TLD): These are ccTLDs in non-Latin character sets (for example, Greek or Chinese characters).
✓ Generic Top-Level Domains (gTLD): These domains usually include
three letters preceded by the dot (for example, .com, .org, and .net), but may contain more (for example, .info).
Each separate TLD has its own “Authoritative Nameserver” with its own unique IP address. The simplest definition of a nameserver is a server that holds a directory of domain names mapped to the IP addresses of the servers those domain names reside on.
The term Authoritative Nameserver defines a server as the one that is kept the most up-to-date. You can have secondary nameservers, which hold a copy of the records from the Authoritative Nameservers, but if there are any discrepancies, the authoritative server is treated as the correct one. Authority is defined by a Start of Authority (SOA) record.
So, for example, the Authoritative Nameserver for the TLD .com holds a list of all the .com domain names and their IP addresses, the nameserver for the
TLD .org holds a list of all the .org domain names, and so on. (See Figure 9-1.)
 |
| Figure 9-1:How domain name lookups work. |
When you type an FQDN into your browser — for example, www.google. com — your browser goes to a DNS server (normally one owned by your Internet Service Provider, or ISP) and asks if it knows the IP address of www.google.com. If the DNS server does not know the address then your browser requests a recursive search, which means the DNS server must search every resource it can for the answer and either come back with the address or a failure message.
The DNS server then starts an iterative search, which goes a little something like this:
First it goes to a Root Name Server and asks, “Do you know where I can find www.google.com? If not, can you suggest where I should look?” The Root Name Server says, “No, but I know where the .com server is; go ask the .com server.” It then supplies the DNS server with the IP address of the .com server (in the form of the Root Zone File I mention earlier).
The DNS server then goes to the .com nameserver and says, “Do you know where I can find www.google.com? If not, can you suggest where I should look?” The .com server replies, “No, but I know where the google.com server is.” It then sends the DNS server to the Authoritative Nameserver for google.com.
The Authoritative Nameservers for the domain (and there must be at least two) are the ones that hold the exact details of where to find the hostname you are searching for.
When the DNS server queries the google.com nameserver, the DNS server first checks that the nameserver is authoritative for the domain (the SOA record), and, if it is, asks, “Do you know where I can find www.google.com? If not, can you suggest where I should look?” The google.com nameserver checks its zone record for that hostname and either returns an IP address or tells the DNS server the hostname does not exist.
Confused? See Figure 9-2 to get a visual idea of the process.
Part of the iterative search is for the DNS server to be given the IP address of the next server to ask. If that IP address does not respond to the query, it returns to the previous server and says, “That server is not responding; do you know of another server I can try?” This is why there are multiple servers to try in each part of the process, so if one is down, the DNS server should, in theory, be able to find another way through.
You may think of a website address as being something like google.com or dummies.com, but, as I mention earlier, to make the name fully qualified it requires another part before the domain name, such as www., which is the hostname.
Because of the way the DNS works, this extra element, the hostname, is important. In most cases, by default, if you type a domain name into a browser and do not include a hostname, it will assume a default hostname of www.
Most websites now are built so that an empty hostname and the hostname www. both point to the same front page of the website, just to make things easier. They don’t have to, though; you can configure www. to go to a page other than the empty hostname!
The Authoritative Nameserver for the domain holds an index of all the hostnames configured for that domain and the IP addresses where those hostnames are found, called the DNS Zone File. The way the majority of websites are configured, the server that actually houses the domain name (and most or all of its hostnames) also acts as the nameserver.
This is just for simplicity and cost purposes, but it is not the most advisable way to do things.
As I mention earlier, resilience is the key to the continued functioning of the Internet and so, all the way through this process, multiple servers are actually in play. There are 13 Internet Root Nameservers; if one or two were to go down for some reason, plenty would remain that your browser could find. Actually, 13 is slightly incorrect: Each of those 13 “servers” is a cluster of servers that provide another level of resilience. Root Nameservers are physically located in more than 130 locations around the globe, and there could be multiple servers at each location for added redundancy.
Each TLD actually has multiple Authoritative Nameservers for redundancy and, as I mention earlier, each domain name requires at least two Authoritative Nameservers for the same reason.
At any stage of the iterative search if the DNS server exhausts the possible IP addresses it is provided, and then it returns an error and your browser displays that error message. The sheer size of the infrastructure behind the Internet Root Nameservers and TLD servers makes it unlikely that your browser or the DNS server will ever fail to find one of them. Normally if an error message appears, it is either because the Authoritative Nameserver for the domain could not be found or because the IP address the Authoritative Nameserver said the website is at is incorrect.
The trouble with caches
Just to make things a little more complicated, the system is actually sped up by the use of what is known as DNS caching.
There are a number of caches, the most important of which are the following:
✓ Your computer’s cache: Whenever you search for a new website, your computer stores the IP address in the computer’s local cache. This means that the next time you request to visit that website, the browser does not have to spend time redoing the search for the correct address; it simply pulls the address from its cache of stored addresses.
✓ Your browser’s cache: In addition to the cache your computer keeps, each browser you have installed on your computer (for example, Internet Explorer, Safari, Firefox, or Chrome) can keep its own cache of website IP addresses. There have been many times when different browsers on my computer have shown different results for a website because the site has moved and one of the browsers hasn’t updated its cache.
✓ Your DNS server’s cache: The configuration of the DNS ensures that, when your computer starts a search for a domain name, the search is routed through your ISP’s DNS server and is not done directly by your computer. For this reason, your ISP keeps a cache of the domain names all of its users have searched for. This reduces traffic from the Internet by lowering the number of iterative searches that are performed. If one of your neighbors has already looked up google.com, the DNS server doesn’t need to search for it again when you want to go there; it just tells you where it found google.com the last time it looked.
Other caches may be held by programs on your computer to enable them to provide faster access to places you commonly visit on the Internet. For example, if you have a mail client, such as Outlook or Thunderbird, it holds its own cache that is renewed every time the program is started.
This is why, if you have ever moved a website from one server to another, it can take a while for your browser to see the change. The ISP caches are cleared out regularly but may retain information for 48 hours or more. You can refresh your own cache fairly easily, but you can still be misdirected by your ISP for a while.
Confused? Don’t be.
Remember the example of a phone book. You look up a name in the phone book and the phone book gives you the person’s address. You then cache that address in your own memory. The next time you need that person’s address, you don’t have to look it up in the phone book because you already know it. You only look it up again if you forget it.
The phone book is also a kind of cache because, when somebody moves, the printed phone book is not automatically updated. If the address in the phone book is incorrect, you have to wait for the cache to be updated (a new phone book to be printed and delivered) before you have the correct address. You then update your personal cache (your memory) with the new address.
Obviously, it’s a little quicker to update caches and addresses on the Internet than in print, but the concept is still the same.
Manipulating Your Domain Name
You now know the basics of how the DNS works with regard to finding websites. The DNS Zone File held by the Authoritative Nameserver for a domain is actually quite extensive, and later in this chapter you find out how to manipulate it. For now, I’m going to switch to the side of the Internet visible to web users and show you how subdomains work (and can improve your website) and how using the DNS for domain parking and redirects can be useful to you.
Getting creative with subdomains
As I explain earlier, an FQDN requires a hostname as well as a domain name. This means that any domain name can actually be split into multiple subdomains.
Picture it like an apartment building — not just any old apartment building either, but a fairly swanky apartment building.
The first floor of the apartment building has an open space that has plenty of comfortable seating and refreshments available. It’s a common area that can be used by all residents of and visitors to the apartments.
If somebody told you she lived at 123 Example Street, Exampleton, then you would assume that when you arrived you simply needed to go through the front door to find her. However, in this swanky apartment building that would only get you to the communal area on the first floor. To find the actual apartment, you would need to know the specific apartment number.
So the complete address would be Apartment 45, 123 Example Street, Exampleton. After you have this correct, full address you can navigate straight to the apartment.
This is also true of websites. If you give somebody your website address with no hostname at the beginning, it is like providing your apartment address without your apartment number. That’s okay if you live in a house rather than an apartment (or, in website terms, you only require a site to have the default hostname). However, the flexibility of the DNS means that at any time you can create a subdomain by creating a new hostname, you can have a second, third, and fourth (and so on) website all underneath one domain name.
For example, you may convert the upstairs of your house into an apartment for your mother-in-law to live in. Your mother-in-law can then get her own mail and give out her own address as Apartment A, 456 Sample Street, Exampleton.
Likewise, say you’re running a website for your local football team, example footballteam.com, and the coach decides he wants to have his own blog. You can create a subdomain with its own hostname of coach, which will give him his own unique address to make his own site, still under the umbrella of examplefootballteam.com.
In this example, the FQDN of the coach’s blog would be coach.example footballteam.com.
Both coach.examplefootballteam.com and www.examplefootball team.com are FQDNs, meaning they are both unique and can therefore point to different places online.
In theory, you can have as many subdomains as you need under your domain, but some of the cheaper web hosts may limit the maximum number they allow you to create.
You can get as creative as you like with your subdomains and are limited only by your imagination and your requirements. Some people never require a subdomain, whereas others create a seemingly endless stream of them.
Just to get your creative juices flowing, the following list includes a few ideas of how you might want to use subdomains:
✓ You may have purchased the domain yourfamilyname.com and cre-
ated a personal website there. You may then want to give your children the opportunity to have their own websites and so you create a subdomain for each of them — for example, Sandra.yourfamilyname.com, Philip.yourfamilyname.com, and Alex.yourfamilyname.com.
✓ Your company’s website may be yourawesomebusiness.com, and
you may want to create another site where you give support for your products, which you could call support.yourawesomebusiness.com. You may wish to create another site where you have a forum for your customers to talk about how awesome your products are, called forum.yourawesomebusiness.com.
✓ Say your name is Gemma and you spend all your spare time doing arts
and crafts and have built a website called gemmasartsandcrafts.com to show people some of your beautiful items. Only after you started building the site did you realize that the papier-mâché models you create are really of little interest to the people interested in needlework or oil painting. You can create separate sites for each type of craft, each with its own subdomain, such as oilpainting.gemmasartsand crafts.com and needlework.gemmasartsandcrafts.com as well as having your main site at gemmasartsandcrafts.com.
Creating a new subdomain
Most control panels provide you with a simple way to create new subdomains. In the later section “Setting Up DNS Effortlessly,” I show you how to manually create a subdomain, but that’s generally more effort than it’s worth when you can do it through an automated system.
The process for setting up a subdomain is essentially the same for most control panels. As an example, here’s how you do it in cPanel:
1. Log in to cPanel with the details your host provided when you opened the account.
2. Scroll to the Domains section and click Subdomains.
3. Type the name of the new subdomain you want to create in the box.
4. Select the domain for which you want to create a subdomain.
Any add-on or parked domains you have set up will be available in the
drop-down box. See the later sections “Expanding your presence with add-on domains” and “Parking domains in your parking lot” for an explanation of add-on and parked domains.
5. If you want to, type the path to the document root of the domain.
By default, the system selects /public_html/TheSubdomainYouTyped,but you can change it if you need to. See Figure 9-3.
The subdomain shows up in the list at the bottom of the page. You can remove it by clicking Remove or, if you need to, you can redirect it (see the later section “Redirecting domains like a traffic cop” for more information on redirection).
If you need to redirect a subdomain for a domain, it must first be set up as a subdomain, either through the automatic process or manually. Otherwise the DNS does not know of its existence and the redirect does not work.
Expanding your presence with add-on domains
Sometimes subdomains just aren’t enough. There are times when a new product or project requires its own domain name with its very own website. This may mean that you need to purchase a new hosting plan for the new domain name, but if your web host allows you add-on domains you can save yourself some money by hosting multiple domain names under one hosting account. There are positives and negatives to using add-on domains rather than purchasing separate hosting packages for each domain name.
Some positive aspects of using add-on domains include the following:
✓ Cost savings. Obviously, it’s cheaper to pay for one hosting plan than two. That’s a no-brainer.
✓ A single hosting plan means you have just one control panel login to remember and you can administer all your domain names from there.
✓ Depending on your host’s configuration and which control panel it uses, add-on domains are often held in directories that are part of the main domain’s file structure. This means that when you back up the files from the main domain, you can automatically back up the files from the add-on domains with them.
Using add-on domains has some drawbacks, too. Following are some negative aspects of add-on domains:
✓ Even unlimited hosting plans normally have some limits to the amount of resources you can use. Add-on domains share resources with the main domain and so, if any or all of the domains become popular, they could use up all the resources allocated to you, thus affecting all the domains you have hosted under that one package.
✓ If your add-on domain is part of the directory tree of the main domain, viruses can potentially jump from one site to another. You also may accidentally delete files or even entire sites.
✓ Things can get messy if you want to shut down or sell one or more of your websites. You can end up having to do a lot of jiggery-pokery to extract and rehouse the domains you want to keep, particularly if your main domain is the one that you want to sell or dispose of.
It’s always a Catch-22 situation trying to decide which way is best for your domain names. I’ve had situations where I have created add-on domains and then had to move everything around within a couple of months because my business focus changed. On the other hand, I have some sites that have been running for years on separate hosting plans, and I could be saving money if I had put them together on one hosting plan because I rarely, if ever, need to move them around or do anything out of the ordinary.
Sometimes it’s just necessary to have another domain name to do something different and, if you don’t have any immediate plans to shut down your main site, using add-on domains can be an easy and cost-effective way to increase your online presence.
Each control panel has its own way of adding and handling add-on domains. Some control panels do not even have the facility to include add-on domains, in which case you need to contact your host to discuss your options for adding a second domain name.
In cPanel, you configure add-on domains using the tools on the Addon Domains page (see Figure 9-4), which you access by clicking the Addon Domains icon in the Domains section of your control panel. When you have configured an add-on domain, you’ll find that its folder tree is in a subfolder of your main domain. The subfolder’s name is the domain name of the add-on domain.
Figure 9-5 shows an add-on domain to day3tutorials.com, called day3test. com. In the figure, you are looking at the document root for www.day3 tutorials.com in the cPanel file manager, and it is showing the website files for day3tutorials.com. In there is a folder called day3test.com. That folder is the document root for the day3test.com domain so, if you go to that folder, it would then show you the website files for that domain name.
Parking domains in your parking lot
Sometimes you need a second, third, or fourth domain name, but that domain name doesn’t need its own website. What you need to do in this instance is to park the name somewhere until you need it or redirect it to somewhere else. Most hosting plans allow you to park domains in a proverbial domain name parking lot.
As discussed earlier in this chapter, every domain name requires at least two Authoritative Nameservers. When you register a domain name through your domain name registrar, you have the option of selecting what nameservers you want the domain name to point to.
You have a few options at this point:
✓ Use your domain registrar’s default nameservers. If you don’t intend to do anything with the domain name straightaway, this can be a reasonable option, but generally it means that your registrar’s nameservers point the name to a dummy site (pun not to be confused with the For Dummies brand, by the way!) that says “this domain name is currently parked here awaiting its site to be built,” or something to that effect. That dummy site often also has ads and links on it that have the potential of earning your registrar some money if anybody finds that page and clicks on the ads.
✓ Make up some fake nameservers. Some registrars don’t allow you to do this because their systems automatically check that the nameservers actually exist before allowing you to select them. If you can get away with it, though, it simply means that your domain name points to nothing, and anybody who types it into her browser gets an error.
✓ Use the nameservers of one of your current domain names and park
the domains there. This option gives you a little flexibility and the opportunity to choose what exactly happens to any traffic that tries to visit the parked domain.
If you want to set up your own dummy website for a parked domain, then you’ll probably find that your host will class that as a complete website in itself; if so, you would need to set it up either as an add-on domain or purchase a hosting package for it.
You can, however, simply park it and leave it going nowhere, or park it and redirect it using the DNS.
Some people make a lot of money through parked domains by placing advertising with affiliate links on the sites they redirect to. There is an art to g etting this right. You have to target the ads to appeal to the people who might visit that domain name, but some people buy thousands of domain names and have developed their own systems for placing the right ads under the right domain names to bring in a large, steady monthly income.
Redirecting domains like a traffic cop
Instead of parking a domain and leaving it pointing nowhere, or even worse leaving it making money for someone else, you can park it somewhere where you have the capability to modify its DNS settings. Some domain registrars allow you to do this through your domain registration control panel, or you can do it through your hosting account.
There are a number of reasons for using domain redirection and a number of different ways in which it’s used. The following examples help you see why you might want to redirect some domain names:
✓ To help people find your site it can be useful to buy different variations of your domain name. These variations include purchasing the name with different TLDs, purchasing the name with different spellings, or in some cases even purchasing different names because users might guess incorrectly what your domain name is. For example, the For Dummies brand of books has its own website, and if you were to guess what the address of the website is, it might be logical to think that it would be fordummies.com. In fact, that’s the name I normally think
of when I try to go to the website. The For Dummies website, though, is actually dummies.com, so the publisher has purchased the fordummies.com name and set it up to redirect to dummies.com so that visitors go to the right site, whichever name they type in. Perhaps the most famous example of someone who should have also bought the domain name with other extensions (TLDs) is the White House. The official website for the White House is found at whitehouse.gov. When the White House staff registered the domain name, they did not buy the name with different extensions such as .com or .org. This resulted in other individuals registering those domain names and for a number of years, the WhiteHouse.com domain hosted pornography. Many potential visitors who were trying to guess the name of the website of the White House typed in WhiteHouse.com because it was often the first thing they thought of. This resulted in quite a lot of embarrassment for the White House when web users, especially children, tried to view the White House website and ended up seeing porn instead. With a little forethought and $10 a year, the White House staff could have prevented quite a few blushes and angry letters from parents.
✓ Redirecting an old domain name. You might decide at some point to change your domain name because you come up with something better or your focus changes. You might want a domain name that better reflects your website, but still want to continue to own the previous domain name so you can redirect it to your new domain name. That way, people who know you by the old name can still find their way to your new site.
✓ Buying a domain name for a specific project. You may be running a specific project or putting on an event, or you may have a specific product that you don’t want to create an entire website for but you want to be able to direct central customers or visitors directly to the right place on your site. For example, Apple has a product called iTunes.
The correct website address for iTunes is Apple.com/itunes. A web user wanting to find out more about iTunes, though, might assume that iTunes is found at itunes.com. That’s why Apple purchased the name itunes.com and redirected it to Apple.com/itunes. Apple then did the same with itunes.org. Interestingly, it seems the company purchased the name itunes.net, but at time of writing, itunes.net is not redirected to go anywhere. Instead, it leads to a blank white page. That may be a missed opportunity for Apple.
✓ Redirecting a URL to a specific domain name. This is actually the reverse of the preceding item in the list. For example, there may come a time when Apple wants to move the iTunes website away from the Apple.com site. iTunes would then have its own site at itunes.com and Apple may want to redirect apple.com/iTunes to send people straight to that site.
✓ Domain squatting. Although domain squatting is frowned upon by many web users, there are pros and cons to both the arguments for domain squatting and against domain squatting. Most web users would argue that purchasing a domain name in the hopes that one day somebody might want to use that domain name and then buy it from them for a large amount of money is a little unethical. On the other hand, there are times when you might come up with a brilliant idea for a site, or what you think is a brilliant name, but you don’t have time to use it immediately; still, you want to register it before someone else comes up with the same brilliant idea. Whatever your reason for purchasing extra domain names, when you purchase them, redirecting them either to your main website or another site of your choice is generally a better idea than leaving them doing nothing.
You may be wondering now if I’m suggesting that you should spend all your hard-earned cash on every domain name that you can think of. Don’t worry; that’s not exactly what I’m suggesting. It is good to think about your visitors and try and put yourself in their shoes for a moment and consider whether purchasing additional domain names would be useful to both them and you. You don’t need to bankrupt yourself on just-in-case domain names, though.
Exactly how you redirect the domain name differs depending on the facilities your domain name registrar gives you. If the registrar does not give you the right facilities, it then depends which control panel is used for your hosting. As an example, I show you how to redirect domain names using cPanel and, regardless of which system you use, the basic concept is the same.
There are two ways to set up a redirection. The first is to park the domain with a blanket redirect; the second is to get a little more creative with URL redirects.
Setting up a blanket redirect
Use the following steps to park and redirect a domain name using cPanel:
1. Purchase the domain name you want to use.
During the purchase process, set the nameservers to the same as the ones for your current hosted domain.
2. Log into cPanel using the details your host gave you when you first signed up.
3. Scroll to the Domains section and click Parked Domains.
4. Type the name of the domain you want to park into the box and click Add Domain.
It is important to note that cPanel does not allow you to do this until
the domain is registered and the nameservers point to the server. If you have only just registered the domain name, it can occasionally take a little while for the registration to go through and the information to propagate around the Internet. You therefore may have to wait a couple of hours after purchasing the domain before you can park it.
5. Change the redirection, if necessary.
At this point, the domain is parked and automatically redirects to the primary domain in the hosting account. So web users who type in the domain name are automatically redirected to your primary domain. If you want the domain name to redirect somewhere other than the root of your primary domain, then click Manage Redirection. (See Figure 9-6.)
6. Type the full URL of the domain or file you wish it to redirect to in the box on the Parked Domain Redirection Page.
If you are redirecting to a file, then you need to end the URL with a trailing forward slash (/).
To remove the redirection, click Disable Redirection on the Parked Domain Redirection page. To remove the parked domain completely, click Remove on the main Parked Domains page.
URLs are case sensitive after the TLD. The FQDN is not case sensitive (www.
dummies.com is the same as www.DUMMIES.com), but the file path, which is everything that comes after the slash, is. So www.dummies.com/store.
html is a valid file, but www.dummies.com/Store.html is not. You can choose to use capital letters in your paths and filenames if you want, but remember to always capitalize them the same when referencing them or you will not be able to navigate to the correct pages.
Creating URL redirects
Sometimes you might want to get a little more creative with your redirects and set up a specific URL to redirect somewhere. I actually used this method just now as I was sitting down to write. I have a link to give people introductions
to a membership community for entrepreneurs. The link is extremely hard to remember (https://founderscard.com/membership?code=FCPETER093)
so, to make it easier for people to remember, I set up a redirect at peter pollock.com/fc, which redirects them straight to the right page. It took just a few seconds to do and yet made the URL shorter, more memorable, and easier to spell.
The following steps explain how to get more creative with redirects using cPanel:
1. Log into cPanel using the details your host gave you when you first signed up.
2. Scroll to the Domains section and click Redirects.
3. Choose the type of redirect you want.
Redirect choices are 301 and 302. These are standard numbers that the server uses to inform your browser of the redirect and give it more information so it knows what to do. A 301 redirect is a permanent redirect. This means that, as far as you know, this redirect will never change. Your browser then knows that it should update any bookmarks you have to the original URL with the details of the redirect. A 302 r edirect is only a temporary redirect, which means you’re purposefully redirecting for a short time and this may be due to some maintenance or for a shortterm project. The browser knows not to update its bookmarks because it needs to check every time you use the URL whether the redirect is still in place.
4. Choose the domain name you want to redirect from the drop-down box. The drop-down box includes your primary domain and any add-on or parked domains under the account.
5. Type the rest of the path to the file or folder you want to redirect.
For example, if you want to create a redirect so that everyone who types in yourdomain.com/myfavoritebooks gets sent to the For Dummies website, in this box you’d type myfavoritebooks. (See Figure 9-7.)
6. In the Redirects To box, type the full URL of the site, file, or page that you want to redirect to.
You also need to include the protocol for the URL, which will normally be http://.
7. Select what type of www. redirection you require.
Normally this will be redirect with or without www. As I explain earlier in this chapter, www. is normally simply the default hostname in your URL and your browser treats no hostname and www. as the same thing. It is possible to configure this differently, though, so that www. is a different page on your site. If that is the case on your site, you may need to choose one of the other www. redirection options.
8. Select the Wildcard Redirect option, if desired.
Wildcard redirects can be useful in certain circumstances, but are not
always necessary. A wildcard redirect redirects to the same filename in the destination directory. This is useful if you change your domain name, but otherwise have your directory structure the same. For example, you might have a contact form for which your old URL was yourdomain.com/contact.htm and the correct new URL might be yournewdomain.com/contact.htm. The file structure is the same; only the domain name differs. In this case, if you do not use a wildcard redirect when somebody clicks a link or types into the browser your domain.com/contact.htm, instead of being redirected to the contact form on your new domain, that person would be redirected to the main page on your new domain (yournewdomain.com). If you do select wildcard redirect, though, the visitor will be redirected straight to the new contact form. This will not work if the filenames have changed.
9. Click Add.
Your redirect appears at the bottom of the screen.
You cannot edit redirects; instead, you have to delete and re-create them.
Redirects are done using commands placed in the .htaccess file in the document root of the main domain. When you create the redirects, they are automatically entered for you by the system at the end of that file. If redirects are not working, check the .htaccess file because other software may have placed commands before them that are overriding the new redirects. For example, when you install WordPress, it creates a redirect that ensures that visitors can find the main page of the site. If this is the case, you should move your new redirects to be at the beginning of the .htaccess file because commands in that file are acted on in the order in which they are read.
You can create redirects for any path or filename within any domain you have added on or parked, and you can add and delete them any time you want. This means that you can easily redirect users for a short time when necessary and can also make shorter URLs to share with potential visitors that redirect to less memorable URLs on your website.
Setting Up DNS Effortlessly
I’m going to take you behind the scenes now and show you how things work in the background to make the DNS function so effectively. When you look at a clock, you see the face and hands; the hands move around and point where they’re supposed to point. Most of the time, that’s all you need to see; you don’t need to see what makes the hands turn or how the cogs and springs work together. If the clock didn’t have a face, maybe an expert would be able to tell what time the workings were indicating, but to the average person it wouldn’t make any sense.
The Internet has its own face, which is there to make it easy and intuitive for humans to navigate. When you have your own website, however, it’s important to see and know how it works behind the scenes so you can modify or correct things that aren’t working quite right.
Using DNS to your advantage
Your nameservers hold a series of records, called the DNS Zone Records, which tell visiting browsers where to find the various services and parts of your website. To break it down simply, your domain name covers two main services. Each has its own type of record to help speed Internet navigation. ✓ Mail exchange records: The e-mail service for any domain name requires what is known as a mail exchange, which is something like a mailroom or a post office. This mailroom can be on any server you choose, although most default setups have it running on the same server as the website. The DNS uses what are called MX records, which stands for mail exchange, to denote which records are specifically referring to where the mailroom is. See Chapter 3 for more details about hosted e-mail.
✓ Address records: Virtually all other records are designated as A records, which simply stands for Address records. These records have a hostname and an IP address to direct visitors to the right places.
There are other records, such as NS records and CNAME records, which I explain later, but the most important for most general usage are the A and MX records.
Knowing how to create and manipulate DNS records can help you add speed, versatility, and resilience to your website quickly and easily.
Here are a few ways you can use DNS to your advantage:
✓ Use an external mail server. I explain later in the chapter exactly how to configure this, but for now what you need to know is that if the server your website is on is also the server that handles your mail and your website goes down, then it is most likely that your mail will go down as well. In that case, if people try to e-mail you to tell you your website is down, those e-mails won’t get through to you.
Services like Gmail enable you to use their systems to handle your mail and keep it under your domain name even though it’s running through their system.
✓ Set up an external secondary nameserver. The default setup from many hosting providers is to have the server your website is on act as both primary and secondary nameserver. This completely defeats the object of having a secondary nameserver. If one goes down, they both go down. If you have access to another server, you can use the DNS to keep a copy of your DNS zone records on the other server and configure your nameservers with the Authoritative Nameserver for your TLD to look first at your server and then at the other server if it cannot contact your server. The best setup, in fact, is to have separate servers for your primary and secondary nameservers (you can even have a third and fourth nameserver if you want) and to have both nameservers be on entirely different servers from where your website is. In Figure 9-8, you can see the domain day3matthew.com configured with four nameservers, to provide redundancy.
 |
| Figure 9-8: Configuration of remote secondary nameservers. |
For example, if you have a support site at support.yourdomain.com, that site might provide downloads and other forms of resource-intensive assistance. You can use the DNS to point users to your primary server for your main website and then to a secondary server for your support site even though they have the same domain name.
An overview of a DNS record
A typical DNS record for a domain might look a little like what’s shown in Figure 9-9.
Each line of the record requires a domain, a time to live (TTL), and a record type.
As shown in Figure 9-9, most of the lines look essentially the same, except the first.
The first line is a special line that has the record type Start of Authority
(SOA). This line confirms that this is the authoritative DNS record for this domain name, also known as the Authoritative Nameserver. The DNS zone records may be cached elsewhere or even listed elsewhere, but the DNS system knows that this is the most up-to-date list and therefore takes precedence over all others.
The first part of the record is the domain name or hostname.
The TTL is a figure supplied to other computers that do a DNS lookup here to tell them how many seconds to store the current DNS information. In other words, it says this is how many seconds you should wait before checking back to see if the record has changed.
The default value for TTL is 86,400 seconds, which is 24 hours. And it is from this number that your host calculates the figure of 48 hours for domain propagation.
Each record in the DNS file can have its own TTL. Unless you know that you will be updating the records or an individual record frequently, you should leave the value as a fairly high number. The convention seems to be at least 14,400 seconds (4 hours) for A records and up to 86,400 seconds (24 hours) for NS and CNAME records.
Although you do have control over the TTL for each of your records, and it may be tempting to make the TTL shorter to ensure faster updates, in reality zone records are not normally updated frequently. Making the time shorter just puts a higher load on your server and the Internet in general because devices on the Internet will have to come and check for updates more frequently. Some DNS caches ignore your TTLs completely and use their own — often making it three days or more to reduce DNS queries as much as possible.
The next part of the record is the class, which is a two-digit code. In Internet DNS records, the class is almost always IN (which stands for InterNet). There are two other possible classes, CH and HS, but unless you’re a UNIX administrator or a company intranet administrator, it’s unlikely you will ever come across those.
Do not change the class unless you are absolutely certain that you need to.
The Record Type column is next and, in the first line, this cannot be changed because it must be SOA.
The contents of the next box are dependent on the record type. Sometimes it will be a domain name and sometimes it will be an IP address.
The SOA record also has certain other information. Next comes the administrator’s e-mail address. Notice that in the address a period is used instead of the @ (at) symbol. This is a constraint of the system, and you cannot change it.
The SOA then has a “serial number,” which is incremented each time the zone file is changed. This number is important because when DNS servers cache the zone record, they take note of the current serial number. When they come back at the end of the TTL, they compare the noted serial number to the current serial number provided by the DNS server. If the two serial numbers match, then the server knows to continue to store the same information for another cycle; if the numbers do not match, the servers request the updated DNS records from the server.
Next comes the “refresh time,” which is the amount of time any secondary nameservers wait before checking for changes to the zone file.
The refresh time is followed by the “retry time.” If the secondary server attempts to verify that it has the latest zone file but fails to contact the primary server, the retry time is the amount of time it will wait before trying again.
The secondary server is also given an “expire time.” This tells it, if it can’t contact the primary server, how long to continue to serve the information it already has. Note that the secondary servers do not go by the TTL but rather by the refresh time and, failing the capability to refresh, the expire time. The default expire time is 86,400 seconds, but many servers are configured with the default expire time much higher than this, often in the region of 30 days or more.
After the secondary server reaches the expire time, if it has been unable to contact the primary nameserver, it refuses to give out the DNS zone records anymore. Therefore, you do not want to make the expire time too low because if something goes wrong with the primary nameserver the secondary holds the fort until the primary is fixed. You don’t want the secondary shutting off too quickly and thus stopping people from being able to find the site. On the other hand, you don’t want to make the expire time too long because generally if the primary DNS server has a problem, the website itself also has a problem (because by default the server that houses the website is also the primary nameserver).
The last part of the SOA record is the “minimum TTL.” This should really be called the default TTL because it is the TTL that is used if for some reason a record does not have its own TTL. Calling it the minimum TTL is a bit of a misnomer because the TTL listed in any record in the DNS zone file overrides the minimum TTL, so the minimum can be shorter than what the minimum TTL suggests.
In the last sections of this chapter, I show you how to use and configure some of the different types of DNS zone records. See Figure 9-10 for a screenshot of these records.
Nameservers
When a device on the Internet is trying to find your website, it goes to the TLD nameserver and asks where the nameservers for your domain are located, but your nameservers must be listed in the zone records held on your nameservers. It can seem a little confusing because to be able to read them, most devices on the Internet have already found their way to your nameserver and don’t need to know where it is because they’re already there. However, the TLD nameservers need to be able to access that information so they can check whether your nameservers have changed it at all.
See Figure 9-11 to see how nameserver records are configured.
✓ The name is, obviously, your domain name but it must have a period at the end of it. Whether you need to physically put that period in depends on the system you’re using to edit your DNS zone records. Some do it automatically for you; some do not.
✓ The TTL is whatever you want it to be. The convention has long been to keep it at around 86,400 seconds (24 hours), but many people are going for a shorter TTL now for NS records, often nearer 300 seconds (5 minutes). The advantage of a shorter time period is if your web server goes offline, you can bring a replacement server online and quickly change the IP addresses of the nameservers for your domain to the IP addresses of the new server. With a long TTL, the new IP addresses could take a day or more to replicate around the Internet.
✓ The record type for nameservers is NS. You must have a minimum of two nameservers for your domain, and it is recommended that you do not have more than seven.
✓ By entering a record type of NS, you are required to give a hostname.
The hostname is, in effect, an FQDN, so it requires all three sections: the host followed by a period, followed by the domain name, a period, and then the TLD. If you’re creating your own custom nameservers, the host can be anything you want it to be. The common convention is to use hosts such as NS1 and NS2 to make everything clean and easy to understand.
CNAME records
Canonical Name (CNAME) records are crafty little records designed to make things quicker and easier for you in the future.
For example, you may want to set up a record for the www hostname, so that, if one of your visitors puts www at the beginning of the domain name, the server knows how to handle it. See Figure 9-12 for examples of CNAME records.
So, you make a CNAME record for www which has the following details:
✓ Name: www
✓ Type: CNAME
✓ CNAME to use: yourdomain.com
Now, when someone’s browser comes to the server, it will have a conversation like this:
Browser: Are you the Authoritative DNS server for yourdomain.com?
Server: Yes, I am. I’ll send my SOA record to prove it.
Browser: Good. Now, can you tell me where to find www.yourdomain.com? Server: Let’s see . . . yes, I have a record for www — and it is directing you to yourdomain.com.
Browser: Okay . . . where do I find yourdomain.com?
Server: I have an A record for that, which says it’s at 192.XXX.XXX.XXX.
Browser: Thank you!
Now, to be honest, the browser doesn’t really say thank you; that would just add to the Internet traffic, but that’s roughly how the conversation goes.
What you need to note is that the browser is ultimately looking for an IP address, something that the CNAME record doesn’t include. This adds an extra step to the record — but it does so for a good reason:
You may have lots of hostnames that all need to point to the same server. Quite often you’ll have records for www, mail, webmail, pop, smtp, and more, all of which go to the same IP address.
Using a CNAME record for them means you can point them all to the same CNAME, and you only need to make one record for that name with the IP address (which will be an A record).
If, in the future, you then change your IP address because you move from one server to another or you have to change the IP address for some other reason, you just have to change one record and all the CNAME records that point to it will automatically be pointing at the right place.
It may not seem like much now, but it can save a whole lot of time updating records later.
You have to find a balance between the ease of updating your DNS records and the added overhead that using CNAMES brings. When you use a CNAME, the browser has to do two DNS lookups. The first gives it the CNAME, and the second tells it what IP address the CNAME relates to. That may not be a problem for smaller sites, but when your server is being asked for IP addresses thousands or even tens of thousands of times a day, it can cause the whole server to slow down.
MX Records
Mail Exchange (MX) Records are slightly different from most other records in that they have a “priority” field. When the architecture of the Internet was created, it was decided that e-mail would be one of its very most important functions, and so a system was devised to try to ensure that e-mail would not get “lost” if there were problems with delivery.
One of the major ways to achieve this was to allow each domain name to have multiple post offices (mail servers), so if one was closed, a backup for it was already configured and open for business.
There is some debate over the real purpose of MX priorities, with very valid and good arguments on every side. However, I feel the simplest way to configure things is to have a primary mail server at the lowest MX and then backup (or secondary) servers at higher MX priorities, which are then configured to hold mail in a queue until the primary server is again ready to receive.
An MX record has five constituent parts (see Figure 9-13):
✓ Domain: This is always the domain name of the domain with the TLD and a trailing dot — for example, yourdomain.com. The trailing dot is very important.
✓ TTL: As with all TTLs, this can be set however you want it. The number 14,400 seems to be a fairly normal figure, though.
✓ Record type: The record type must always be MX for Mail Exchange records.
✓ Priority: The lowest number is the highest priority, so the system tries the servers in number order. Zero (0) is the highest possible priority.
✓ Hostname: This is the name of the server that the mail will be hosted on. A normal default setup points it to the same server as the domain name, but it can be changed to any other server that is configured to receive mail. Note that this is a name, not an IP address. A corresponding A record must be created in the zone file of the receiving server to resolve the name to an IP address.
 |
Figure 9-13:A sample MX record. |
Some people recommend that if your mail is being delivered to another server — for example, to Google for use through Gmail — that your very lowest priority MX record should point back to your server. This would mean that if Google or whoever you are using for your mail service was to go down completely, there would still be a mail server configured to accept your mail as a last resort. (See Figure 9-14.)
A Records
Last, but certainly not least, are A records. These records are the most commonly used and the simplest.
An A record must have a host, a TTL, and an IP address (see Figure 9-15):
✓ Host: The host can be a domain name or the host part of an FQDN. If it is a domain name, it must end with a trailing dot (.).
✓ TTL: The default time to live for A records is 14,400.
✓ Record type: This must be a single A.
✓ IP address: This must be a valid IP address.
 |
| Figure 9-15:A sample A record. |
Chapter 10 Configuring Advanced Functions in cPanel
In This Chapter
▶ Creating 404 pages
▶ Using automated functions
▶ Using FrontPage Extensions
This chapter shows you some of the more advanced functions within your control panel. These functions don’t have any particular natural grouping, so in different control panels they are put in different places. Wherever they are placed, though, these are some essential services that you may need at some point, and they are actually fairly easy to use when you know how.
Improving the User Experience with Error Pages
When a user requests a page from your website, one of the things that your website does is return a status code, which signals either a success or failure. As I explain in Chapter 6, the server logs each of these codes so that you can see how many pages are getting failures and how many are getting delivered as they should. Various status codes indicate errors; in addition to being logged, these codes are sent to your visitor’s browser.
Depending on the setup in your web server and the particular browser the user is using, when the user receives error codes, quite often all she sees is a page saying, “File not found,” “Webpage not found,” or “Webpage not available.” This doesn’t really tell the user too much, and it doesn’t help her in any way to find what she was looking for on your site.
You can set up custom error pages that the server will deliver to the browser in the event of an error. You can set up a different page for each error code, or you could use the same page no matter which error code is generated.
The most common error codes are 404 and 500. A 404 error code means that the page requested does not exist, so there is no page for the server to deliver to the browser. A 501 error means that the server has an error of some sort, and so it cannot deliver the website at this time.
Using cPanel as an example, this section describes how you can customize those error pages. The procedure is the same for all the different error codes. Table 10-1 shows some of the more common error codes, though there are many more than are shown in the table.
To set up an error codes custom error message within cPanel, use the following steps:
1. Log into cPanel using the login details provided by your host when you signed up.
2. Scroll to the Advanced section and click the Error Pages icon.
3. On the Error Page screen, select which error page you want to modify.(See Figure 10-1.)
4. The server displays a box with the current HTML code that is used to display the current error message. (See Figure 10-2.)
This box may be blank if you haven’t modified it previously. You can edit this information to display the page however you want. Above the Edit box are some tags you can insert. These place the appropriate data on your page wherever you insert them.
It is generally recommended that whatever page you generate for the error codes, or even if you forward users to a specific page when an error is generated, that you have some text prominently on the page to explain to the user that she was directed there because of an error. This then explains to her why she’s not seeing exactly what she was expecting to see.
What many websites do is direct users to a page that has a search facility on it. This then gives the user the option of searching the website for the information that she was looking for.
If you are creating one of the 5xx series error pages (that’s 500, 501, 502, and so on), then the error page should be as small and simple as possible and inform the user that the website is down but you are working on bringing it back up as soon as possible. If you do not have a 500 series custom web error page, when users see a 5xx error, what they see in a browser may lead them to believe your website is no longer functioning permanently rather than it being a short-term problem. Having an error page that informs visitors that the error is just a temporary thing helps to keep them coming back. After all, you don’t want them to just give up on your site.
You cannot anticipate in advance what errors your server or website might one day generate, so it is best to ensure that you have a custom error page for at least all of the common errors listed in Table 10-1.
You can create different custom error pages for each domain that you host.
The software you are using to create your website may also include the facility to make custom error pages. Software such as Joomla or WordPress may have error pages built into the themes or plug-ins you can install. You may find that these are more desirable than coding them manually in your control panel because the software enables you to create error pages that look like the other pages on your website.
Automating Functions with cron Jobs
There are times when you need to do various different things on a set schedule and the server can help you with that using what is known as the cron.
Think of cron as being short for chronology, and it will help you see that it is for jobs that are performed automatically on a fixed time schedule by the server’s internal clock. It’s like setting the timer to switch the heating on before you get up in the morning or setting your DVR to record the same show every week.
The command for a cron job basically has two parts:
✓ The command that the server should run: This means giving it the full path to the file that you need to run and any switches that are needed to perform the function. The software you run on your website should provide the correct switches to include.
✓ The exact time and schedule on which the job should be executed:
There is huge flexibility built into this system, meaning you can schedule the task to run exactly when you want on whatever schedule you want.
cPanel provides an easy configuration screen for cron jobs. Here’s how to use it:
1. Open cPanel and log in using the details your host gave you when you signed up.
2. Scroll to the Advanced section and click Cron Jobs.
3. If you want to be e-mailed every time any cron job runs, enter your e-mail address in the first box and click Update Email.
4. Select the schedule on which you wish the command to run.
There are some common settings to select from, or you can create your own schedule.
You must fill every box when setting the schedule; otherwise the cron job creation will fail.
5. Enter the command you want the server to run into the Command box.
You must add the full server path to the file you want to run in the cron job. The server cannot guess which folder the file might be in!
6. Click Add New Cron Job to create the job and add it to the cron. (See Figure 10-3 for an example cron job.)
It may take you a little while to get used to how cron jobs are scheduled because different characters do different things. Here is an explanation of them:
✓ Numbers 0-59: Which numbers you can use depends on whether you’re setting the minute, hour, day, month, or weekday. Obviously, there are not 59 hours in a day, so you can’t use 59 as an option for hours, but you can use any valid number for that time period. So if you want something to run at one minute past the hour, you put a 1 in the minute box. You can select for it to run at multiple different minutes by separating the minutes with a comma. For example, if you wanted it to run at 1, 5, 27, and 50 minutes past the hour for some reason, you would simply input 1,5,27,50 into the Minute box.
✓ Asterisk (*): An asterisk means “every,” so putting an asterisk in the Hour box means the cron job runs every hour. Putting an asterisk in the Day box means the job runs every day, and so on.
✓ Slash (/): You can use a slash after an asterisk to divide that “every” by a number. A slash always has to have a number following it. For example, if you want the job to run every month, you simply put an asterisk in the Month box. If you want it to run every three months, though, you have to type */4 — which means every month divided by 4 (or 12/4), which equals every three months. It can be a little confusing, but the cron job screen has Common Settings drop-down boxes that help explain what to do.
✓ Dash (-): You can use a dash only in the Weekday field. The Weekday
field is a special field that modifies the Day field. For instance, if you want to run the command only on the weekends, you type (0, 6) because 0 stands for Sunday and 6 stands for Saturday. You can use the dash to signify every day between two days, so for example, 1-5 signifies every day from one to five (Monday through Friday). Using 3-6 would mean Wednesday through Saturday.
You can edit or delete cron jobs at any time after you create them. Any change or deletion is immediate and stops the previously next scheduled run and replaces it with whatever you change the settings to.
You may find cron jobs extremely useful and their scheduling system is amazingly flexible, allowing you to schedule the server to run any job you want at pretty much any minute of the year you want it to.
Installing FrontPage Extensions
FrontPage is a piece of software, developed by Microsoft, that enables users to design websites on their own computers. FrontPage is a WYSIWYG editor, which stands for What You See Is What You Get. The name says it all — what you see on your screen as you are designing the site on your computer is what the users will see when they come to the site in the future. This is in stark contrast to the old system where you had to code everything by hand and then upload it to your website to see how your site looked. That’s called manual coding, which is great if you’re an expert and really know what you’re doing. WYSIWYG, however, has made site design much easier for the masses and people not too versed in software development.
Microsoft actually discontinued support for the FrontPage product in 2006 and replaced it with a new product called Expressions Web, which could still take advantage of some of the FrontPage server features. Support for Expressions Web has now also been discontinued and no new versions will be made. Microsoft is instead pushing its Visual Studio product for web design.
FrontPage is, however, still used by many smaller site owners because they know how to use it and don’t want to have to learn another program. This means that some hosts still offer FrontPage Extensions although many now don’t.
FrontPage consisted of two separate parts. One was the software which the user had on his own computer to develop the site and get it looking the way he wanted it to look; the other was some software, called FrontPage Server Extensions, which needed to be on the servers. These extensions handled special requests from sites that were made using FrontPage, such as FrontPage–specific contact forms. The last version of the Extensions actually came out in 2002, but Microsoft continued to support them until July 2006, when all FrontPage support stopped.
Originally, any FrontPage website needed to be hosted on a Windows server. This was because Microsoft developed FrontPage for its own Windows software and thus developed the Extensions for its own Windows server software. Very quickly, though, the Extensions were ported over to Linux so that they could be run on UNIX/Linux boxes.
The major problem with Windows FrontPage Extensions is that they are so far out-of-date. Microsoft ceased to develop and support them in 2006, and server software has moved on a lot since then. Server administrators and users are increasingly finding that FrontPage Extensions are no longer compatible with the latest versions of Windows Server and have several security weaknesses, which will never be fixed.
The Extensions seem to be a little more stable on Linux servers, but many web hosts are now switching off the FrontPage Extensions facility altogether because it’s more trouble than it’s worth.
If your site requires FrontPage Extensions either because you developed it using FrontPage or because you developed it using Expressions Web and use some of the FrontPage features in it, you need to ensure that your web host allows FrontPage Extensions on its servers. If so, the Extensions may already be installed, or your host may have to install them for you. However, you may have the facility to install them yourself.
Hosts that still allow FrontPage Extensions often have an icon somewhere in the control panel that’s helpfully labeled FrontPage Extensions. In cPanel, the icon is in the Advanced section (which is usually at the bottom of the page).
(See Figure 10-4.)
If you do not see the install FrontPage Extensions icon (or text link), it probably means that your host does not allow them. In this case, contact your host because it may be willing to make exceptions for certain clients.
If you require FrontPage Extensions and the FrontPage Extensions installation icon is in your control panel, click it and follow the prompts to install them. It depends which control panel you are using exactly how the FrontPage Extension installation works. Some have more facilities than others. Normally, though, it tells you whether they are installed and gives you a button to install/uninstall them (see Figure 10-5).
Click Install Extensions and it either asks you to supply a FrontPage username and password or goes ahead and installs it directly. (See Figure 10-6.)
In some installations, after FrontPage Extensions are installed, you can use a facility to reinstall or manage those Extensions. This can sometimes be useful if you’re having problems with an area of your site that requires the Extensions. Running the reinstall or cleanup rewrites all the Extensions files and most likely fixes any problems that have occurred. (See Figure 10-7.)
After you install FrontPage Extensions, go back to FrontPage on your computer; if the server asked you to supply a username and password when you installed the Extensions, use the login details you created to upload your site to the web server. If it didn’t ask for a username and password, then it either will have e-mailed them to you or will have used the same username/password combination you use to log in to cPanel.
FrontPage is old and buggy, and because it hasn’t been updated for a long time it has many known security holes. Unless you really have to use FrontPage for your website, it is best to use one of the newer tools for website creation. Several free WYSIWYG site creation tools are available, as are several paid options. My favorite tool for building websites is WordPress.
If you don’t absolutely need FrontPage Extensions, don’t install them — and remove them if they are installed!
Chapter 11 Managing Your Control Panel from a Mobile Device
In This Chapter
▶ Modifying and repairing your server on the go
▶ Understanding different mobile operating systems’ facilities
The world of smartphones and tablets has created a situation in which people increasingly have the capability to be “online” even when they’re not at their desks. When issues arise on your site or server or when you think of things you want to change, you want to make the changes immediately and have a mobile device to help you do it. You can make changes using your smartphone, although how easy it is to make changes with a mobile device depends on your web host and the control panel it uses. In this chapter, I show you briefly how to navigate inside your browser to your control panel’s normal login screen and then look at some of the apps and facilities that are available for Android, BlackBerry, iOS, and Windows Phone.
Navigating Using a Mobile Browser
To get to your control panel using a mobile browser, you simply open the browser and type in the URL of your control panel as you would normally do. For instance, with cPanel the URL is normally cPanel.yourdomainname. com. For companies like DreamHost and GoDaddy, you can go the website and log in from the front page.
Depending on which control panel you use, making adjustments can get fiddly on a mobile browser screen because the screen is so small and the control panels are designed for much bigger computer monitors. However, some companies deliver a special mobile version of the control panel. cPanel, for example, does away with icons and instead uses a text-based interface. Compare Figure 11-1, which shows the cPanel interface in a normal browser, and Figure 11-2, which shows how it looks on a smartphone.
There is no substitute to trying it yourself on your smartphone or tablet and seeing exactly how easy or difficult it is to use the control panel in the browser. That said, before you purchase any apps from the app store for your mobile device, try using the browser and see if you are able to do the things you need to do.
For the average user, using your control panel from your smartphone is not really essential because there are not that many things that go wrong or require changing that can’t wait a few hours until you’re next at your computer screen. However, if you’re the server administrator for high-volume websites or for multiple websites, particularly if you have a Virtual Private Server (VPS) or dedicated server, you may find that being able to manage the control panel from your smartphone is very useful as well as convenient.
Some of the major hosting companies, such as DreamHost, GoDaddy, and 1&1, have smartphone apps available. Some are official and some are unofficial. There are always two schools of thought about the safety of unofficial apps; some people love them whereas others are a little wary of them. If you’re uncertain about the trustworthiness of an app or its creator, it’s always safer to not install it and use one of the official apps instead.
When installing apps for your smartphone or tablet, you first need to know what operating system your device uses. If you have an iPod or an iPad, which has an Apple symbol on it, then your device uses the Apple iOS. Please skip ahead to the “Installing and Using iOS Apps” section for details on how to find the installable apps on Apple devices. If your device is not running iOS, then there’s a strong chance that it is running one of the versions of the Android operating system.
Installing and Using Android Apps
The Android operating system is written and developed by Google, which has
its own store where you can purchase and download apps, some of which are free. The Android store is called the Play Store. There should be a Play Store icon like the one shown in the margin on one of the home screens on your smartphone or tablet.
Knowing where to find apps
The best place to find apps for your Android device is in the Play Store, where both free and premium apps are downloadable over Wi-Fi or a cellular data connection.
Some control panel apps are not available in the Google Play Store. These apps are written by third-party developers who do not want to use the Play Store system to distribute the apps they write. You can find these apps by doing an Internet search for Android apps for whatever control panel you use.
Generally, the sites with these apps give you a link to download the apps and normally give you installation instructions. The installation process often requires you to go into a special section within the Android settings called the Developer settings; there you have to disable the function that requires apps to be installed from the Play Store. Google provides this function so that you are not limited to acquiring apps from only the Play Store; at your own risk, you can add your choice of apps from anyone and anywhere.
Be cautious about installing apps from sources other than the Play Store. You will often find that developers who do not upload their apps to the Play Store have not done so for a reason. Some developers do naughty things with their apps, and those things may come as a shock to you after you install the app. For example, an app may access information that you would normally expect an application to access, such as e-mail addresses, phone numbers, or phone usage information, but the app then sends the information back to the developer. Some apps may plant viruses on your device, which enable the developer to steal information such as bank login details, Social Security numbers, and dates of birth. The viruses can also hide in the system and perform other functions for the developers, such as turning your device into a machine that runs attacks on websites, such as a distributed denial-of-service (DDOS) attack or sending out spam.
Scary, huh?
That said, there are legitimate developers out there who write good applications that are trustworthy, and they might have legitimate reasons for not uploading their apps to the Google Play Store. Make it part of your search to look whether other people have experienced problems after installing thirdparty apps. If you read bad reviews, you may be warned away from malicious applications.
It is possible for something untoward to sneak its way into the Play Store, although it’s unlikely. It’s always a good idea to read reviews of the apps you get from the Play Store to make sure other people haven’t reported problems.
Installing apps with ease
You’re probably already familiar with how to install applications through the Play Store, but here’s a quick rundown of how to do it:
1. Open the Google Play Store using the icon on your home page or in the settings.
2. Use the search box at the top of the screen to search for the app you’re looking for and tap on the magnifying glass.
Google Play Store searches for the keywords that you typed and brings up a list of apps that match some or all of those keywords. Select your chosen app from the list to open it.
3. Scroll down to get more information about how much the app costs and what it does.
If you want to install the app, look for an Install button (see Figure 11-3) at the top of the screen.
4. Tap the Install button and the software downloads to and installs on your device.
The icon to access the app is placed either on one of your home screens or in your app list.
Finding the best apps
Apps are being developed all the time for various control panels — especially the major ones such as cPanel. It is always good to do a web search for something like best cPanel Android app to find what the newest and greatest recommended apps are. At the time of writing, two of the best Android apps available for cPanel are
✓ Control Panel for cPanel by 2312 Development
✓ HostCP by TechnoMac Solution
Of course, “best” is a subjective term, and what one person thinks is wonderful another person may find confusing and impossible to use. If an app has a free version, it is always a good idea to install the free version prior to buying the full version so you can test it out and find which works best on your particular device and for your needs.
Using apps to connect to your web host
Installing the app is only half of the process; you also must give the app permission to make changes to your server. Don’t worry, though; it’s easily done. All you need to do is type in the address of your website (http://myweb site.com) and your usual control panel login username and password.
It’s really that easy!
Installing and Using iOS Apps
If you are using an Apple device, such as the iPhone, iPad, or iPod, your device is running an operating system called iOS. If you aren’t using an Apple device, your device cannot run this software and you should instead refer to the section on installing and using apps for your operating system.
Knowing where to find apps
Apps for iOS are found in the Apple App Store, for which you’ll find an icon like the one shown in the margin on one of your home pages.
There may be some apps that are not available in the App Store, so to install these you first need to jail-break your phone or device. Jail-breaking can be risky, can damage your device, and will most likely void any warranty you have from Apple or the company you purchased the device from. I do not recommend jail-breaking Apple devices, but it is a matter of personal preference. If you choose to jail-break your device, you may be able to find apps for managing your web server that are not available within the App Store.
Be careful, though, because these programs have not been vetted by Apple and therefore have not been tested for malicious code. Jail-breaking your iPhone, iPad, or iPod and installing one of these apps opens you up to greater risk of viruses and malware.
Your smartphone or Internet device is your property. Although Apple or the developer of the operating system that runs on it may penalize you for jailbreaking your device, the prerogative is still yours to choose to do so. At this time, in most places, it is not illegal to jail-break your device, but the terms and conditions for most operating systems clearly state that the manufacturer will no longer support or update software on your phone in any way if your device is jail-broken. Essentially this leaves your device exposed and there is little or no liability on anybody who provides you with jail-breaking software or applications to install on jail-broken devices for any damage that may be caused.
Installing apps with ease
Installing apps on iOS devices is simple. You’ve probably already done it many times when you have installed games or applications.
Here’s a quick rundown on how to do it:
1. Tap the app store icon to open the App Store.
2. At the bottom of the App Store screen, tap the Search button. In the Search box, type the name of the app or control panel for which you are searching for an app and then tap Search.
The App Store displays a list of available apps based on the keywords you provided in the Search box.
3. Pick the app you want to install and tap it.
The application’s page opens to show you some screenshots and give you details of what the app can do for you.
4. Click the Install button at the top of the screen.
Within a few minutes, the app should be installed on your device.
The app is installed as an icon on one of your home screens. Swipe through the screens to find it and tap the icon to run the app.
Finding the best apps
Apps are being developed all the time for different control panels, especially the major ones such as cPanel. It is always good to do a web search for something like best cPanel iOS app to find the newest and greatest recommended apps. At the time of writing, two of the best iOS apps available for cPanel are
✓ CP Control Panel by Dayana Networks Ltd.
✓ HostCP by Mihir Dhandha
Of course, “best” is a subjective term, and what one person thinks is wonderful another person may find confusing and impossible to use. If an app has a free version, it is always a good idea to install the free version prior to buying the full version so you can test it out and find which works best on your particular device and for your needs.
Using apps to connect to your web host
Installing an app is only half of the process because you need to give the app permission to make changes to your server. Don’t worry, though; it’s easily done. All you will need to do is type in the address of your website (http:// mywebsite.com) and your usual control panel login username and password.
It’s really that easy!
Apps for BlackBerry and Windows Devices
At the time of writing this book, there were no apps for any of the major control panels available on BlackBerry’s BlackBerry World or the Windows Phone App Store.
Both stores are growing rapidly, though, so I expect some to be written for those devices soon.
In the meantime, both operating systems have good browsers built in, which enable you to use the mobile versions of the control panels, as I mention at the beginning of this chapter.
BlackBerry 10 also has the facility to use the browser as a normal browser instead of a mobile browser, thus displaying the full versions of the control panels.
To switch to the normal browser, do the following:
1. Open your browser on your BlackBerry device.
2. Click the Settings icon at the bottom-right corner of the screen.
3. Select Settings.
4. Select Developer Tools.
5. Slide the switch next to Desktop Mode from Off to On. (See Figure 11-4.)
0 komentar:
Posting Komentar