To connect to your server via SSH, simply type:

ssh -l(username) hostname_or_ip

It will prompt you for a password. Type your password, and you should be connected. Some web hosts may use a different port for SSH, other than the default port (22). If so, you will need to specify it, for example:

ssh -p 2222 -lmyname webserver.com

Normal Linux/Unix shell commands apply, once you are logged into the server. When you are finished, simply type “exit”.

You can accomplish basic optimization of database tables from within your web-based control panel or in phpMyAdmin. You should do this routinely. But there are also ways you can optimize the server itself to serve databases faster and more securely. Over the remainder of this week, I will show you a few tips to optimize your MySQL server. Today, I will just point you to the right file.

To begin configuring your MySQL server, you will need to locate the configuration file. This will differ, depending on your operating system and even from one Linux distribution to another. Most commonly, it will be in a directory like /etc/mysql, and the file will be called my.cnf. You will need to edit it as root:

# nano /etc/mysql/my.cnf

Tomorrow, we will start to plow through this file for optimization tweaks.

Answer: The truth is that having root logins enabled is not in itself a security risk. The real risk comes from having an easily hacked root password or non-secure web applications on your server that allow hackers to decipher the root password. Disabling root login gives those hackers one less avenue to exploit, and if you do not need to login directly as root through SSH, there is really no reason to have it enabled.

Actually disabling the root login is not nearly as complicated as my above explanation. Just follow these steps:

1. Login to your server via SSH
2. Become root:
su
3. Edit /etc/ssh/ssh_config
4. Add the following line:
PermitRootLogin no
5. Save and exit

Photo Source: Flickr

There are certain practices you can use to make your passwords more secure:

• Use a mixture of letters and numbers
• Mix lowercase and uppercase letters
• Make the password at least 8 characters long
• Change default passwords given to you
• Do not use a real dictionary word in any language
• Do not use acronyms that are easily deciphered
• Never give your password to anyone, even someone claiming to be a web host or system administrator
• Do not use the same password you use for other things
• Do not use letters or numbers that relate to personal information (birthdays, names, etc.)
• Change your password often.

If you need help creating a password, consider using a password generator. PC Tools has a free online password generator that will allow you to specify length, types of characters, and similarities. Best of all, it will allow you to create multiple passwords at once. Now you have no excuses left for having a password that is easy to guess.

When a web browser connects to a site without a valid certificate, the user will receive a nasty warning about the site not being trusted. This increases the chances that a user may not stay on the site, and if you are a business, it means that customers may be unwilling to proceed with sales transactions. In some cases, you may even have a self-signed certificate with perfectly secure encryption, but the user’s web browser will stay say it is untrusted.

Purchasing a certificate is only the beginning of the process. You will need to setup your server correctly to use it. Each secure HTTPS site will require a unique IP address and correct certificate authority information that matches the certificate. If anything does not match (such as the domain name – common problem with domain CNAME aliases), web browsers will still spit out errors. Be mindful of all these factors as you choose the right certificate for you.

Photo Source: Flickr

Because the attack exploits user error rather than an actual bug in the WordPress code, it is important to make sure that yours or your customers’ WordPress-based sites are secure. The first thing you can do is to chmod wp-config.php to 640, which means any outside site visitors will be completely denied.

chmod 650 wp-config.php

The second is to deny access using your .htaccess file, since no one who accesses the webserver will actually need access to the file under any circumstances.

# to protect wp-config.php

order allow,deny
deny from all


That is essentially all it takes and is actually more than is probably necessary to keep everything secure.
Warning: Some web hosting providers provide automated scripts to install WordPress for you. Do not assume that those installations are automatically secure.

Photo Source: Wikimedia Commons

There are benefits and drawbacks to each. With “su”, root is a true separate user, and some administrators find it more useful to be able to log in as root and run several commands. With “sudo” only commands with those words in front of it will be administrative preventing the user from accidentally running a dangerous command as root.

There are security benefits to each, and the argument over which is better can get heated. Suffice it is to say that it ultimately depends on the preference of the system administrator. Does he/she want to deal with one password or two? Technically, an administrator can decide to use both on the same server and use the one that is most beneficial at the time. It can also be useful if you have multiple users who need various permissions.

Photo Source: Flickr

Windows 2008 server relies on IIS to serve websites to users, and in order to configure a Windows server for SSL, you need to enable it in IIS.

“The implementation of SSL has changed from IIS 6.0 to IIS 7.0.  On Windows Server 2003, all SSL configuration was stored in the IIS metabase and encryption/decryption happened in user mode (required a lot of kernel/user mode transitions).  On Windows Vista and Windows Server® 2008, HTTP.sys handles SSL encryption/decryption in kernel mode, resulting in up to 20% better performance for secure connections.  “

Read the rest at Learn IIS

Photo: stock.xchng

If you decide you need it, you can find more information about making it secure at Crypt.Gen.NZ. To disable dynamic updates, edit the named.conf file and edit each domain zone, setting “allow-update” to “note”

zone "globberific.net" IN {
....
allow-update { none; };
...
}

That is all it takes, although it is probably wise to do this before you end up with a lot of entries and have to go through each one and painstakingly remove all dynamic updates. Regardless, getting it done will give you a little more peace of mind.

Source: nixCraft
Photo: Flickr

Answer: There are both pros and cons to securing an entire site with SSL, but most seem to agree that the cons outweigh the pros. The advantage is that your users know from the beginning that they are working with a secure site. If your website happens to be for a financial institution, this may add to users’ comfort when they are entering login data.

The disadvantages are that a site will mostly like run slower when it has to authenticate encrypted data. The larger your site, the more data it will have to encrypt. Also, if a browser ever has issues with the certificate, a user will be locked out from your site completely or will have to click through unnecessary confirmations. This may prevent them from even getting to a contact form to tell you something is wrong.

Generally speaking, there is simply no need to encrypt general pages of information. Login forms should point to encrypted script URLs, and all shopping cart data, personal information, and financial information should be under HTTPS. If that is all you have (i.e. you only have those private forms on your site and nothing else), then complete HTTPS might be a good idea.

Source: webhostingtalk.com
Photo: Flickr