Instead of typing in a password, you can generate an encrypted key pair that is used to authenticate you when logging in. The server will look to see if you have this key file on your computer instead. There is a good little overview of the process from cPanel here.

This is a great security measure to implement as it allows you to control which systems can access your server. You can also turn password authentication off and your server will be immune to SSH password attacks. This is major step in security hardening and is highly advised.

Generating the Keys

To get started, we are going to need to generate a Key pair on your computer (the public and private key). Load up a terminal and run:

ssh-keygen -t rsa

It will ask where to save the key file. You can leave it at the default location.

Enter file in which to save the key (/Users/user/.ssh/id_rsa): id_rsa

Next, it will ask for a passphrase.

Enter passphrase (empty for no passphrase):

You can leave this blank if you simply want to leave the private key unlocked. This will make logins quite easy as you won’t have to type anything in and you will “auto-login”. However, for an added layer of security, you can set a password to unlock the private key.

It will ask for the passphrase again. Press ener to leave it blank.

Enter same passphrase again:

Finally, it will output confirmation of the keys’ location and the fingerprint:

Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
7b:2d:25:c2:2e:2a:1a:ea:76:3a:96:ed:1a:29:8b:9b

Copying the Public Key

Now you will need to get a copy of the public key you just made. Simply cat the file:

cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwsIU0uzZVu6uf2GgM9B4Z7sNn5jMEs1yDrjvdI4ChXrkADegfltv0CESXknoU4NI57Dw0kyc3eJ7bADyI0uBH0PxDTZAOSKKyogsnRtgXbFLKHXpOOyiG51M9tjobObNo6SDmzbeVD5GzlmnPpgMMUoqpjYe3P45g6ouw/3Gcwt+BwZG5loSknk9lkndbyTmhb5gc4jAMYIQ3QAWCtPES04jyUWMFZ/oUn5bMaTKG2aHCgn0wTYR8ih3Ewptp0XV2z77WUmGnJV6t5wE1kZqltdh52aHTeRLoYAFoFWPt4i6sUjhFPufjeyxdXsSR5dsdqUFZRX1dsCJkGWZzfLb3w== user@computer.local

Importing Key to the Server

We’ll add the key to the server and authorize it (we have to tell the server that this particular key is allowed to access the server). Log into WHM and navigate to: Main >> Security Center >> Manage root’s SSH Keys. Click on ‘Import Key’

On the next screen, you will want to scroll down and look for the last box that says “Paste the Public Key in this box:”. Paste your public key into that box. Leave the other boxes blank. It will automatically fill in the name. Hit ‘Import’.

On the next screen it will tell you the import was successful. Click on “Return to SSH Manager”. This brings you back to the Key management screen. You will click on “Manage Authorization”

Finally, click on the button for “Authorize”.

You are done! Try logging into SSH and it should look for your key.

Server Hardening – Disable Password Authentication

Now, you can take your security one step further and completely disable password logins for SSH. You will have no more fears of hackers trying to guess your SSH passwords.

To set this up, while still in WHM, navigate to: Main >> Security Center >> SSH Password Authorization Tweak. Click on “Disable Password Auth”

And that is that. As cPanel so eloquently puts it: Now, sit back and relax as hackers will no longer be able to gain ssh access through password cracking. They will, instead, receive errors like:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Notes

The encryption method used for this was ‘RSA’. RSA is natively implemented in more places (it is the default key type on most generators and commercial RSA certificates are much more widely deployed) and it defaults to 2048 bit key length. At the time of this writing, for DSA to be compliant, it has to be exactly 1024 bit, which is less secure. The general consensus is that both DSA and RSA are pretty equal in security quality and speed when used merely for authentication. Either you choose will be fine as long as you follow safe security practices: use higher bit key encryption, only use SSH v2, keep your software up to date, and protect your private key.

References:
http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys/5100#5100

http://encryptme.wordpress.com/2011/05/25/ssh-keys-rsa-vs-dsa/

http://www.linuxforums.org/forum/security/48093-openssh-user-host-authentication-rsa-versus-dsa-provides-stronger-security.html#post498142

Note about this article

This article is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. Used with permission.

Today I am going to show you something pretty nifty: how to forward a copy of all incoming and outgoing mail for a particular email user. If you are the cautious type, or simply the email hoarding type like myself , this can be really handy for easy archival of all your mail. Exim can be configured so that your server will automatically (and quietly) send a copy of every message you send and receive over to another email address. This is all done without you noticing anything extra in the ‘To’ or ‘CC’ fields. Silent and effective.

This could also be used to secretly keep track of your users’ emails and monitoring what they do. I had a friend of mine recently ask me to help him set this up for him on a new Sales employee he had. He wanted to make sure they were taking care of the clients properly. While I may not personally agree with the privacy concerns of spying on another person’s email, I acknowledge that it can be used in this purpose and there are those out there who have no problem implementing it for this reason.

However, that is an argument of principles best saved for another time. I personally believe that all knowledge is power and people will do with their lives as they feel is best. I will show you the tech side of how to set this up; you can do with it as you please.

*Note: You will need SSH root access to make the following changes

Find the Exim System Filter file

The changes we are making will be to the ‘System Filter File’. Obviously, we’re gonna need to know where it is located. It could be different on your cPanel box, so be sure to look it up.

Log into WHM and navigate to the section: Main >> Service Configuration >> Exim Configuration Manager. Alternatively, you can simply type ‘Exim’ into the search bar and it will be the first result.

Next, scroll down and locate the “System Filter File” section. It should list the default location. On my server, it is:

/etc/cpanel_exim_system_filter

Leave WHM open for now because we will be coming back to it shortly.

Edit the Exim System Filter file

One thing I must note is that you will not actually be directly editing the system filter file. cPanel staff has stated that if you do, the changes will get overwritten during cPanel updates. Instead, we are going to make a copy of it and make our changes to the new custom file. cPanel updates will not change your custom file.

*Note: Exim version changes, however, WILL overwrite custom files. When cPanel 11.34 comes out, Exim is likely to get a version change. Make sure you back up this file ahead of time.

Let’s get started. Log into SSH and copy the system filter file:

cp /etc/cpanel_exim_system_filter /etc/cpanel_exim_system_filter_custom

Next, edit the newly made file:

nano /etc/cpanel_exim_system_filter_custom

And place the following template at the very bottom:

### FORWARD ALL INCOMING AND OUTGOING MAIL FOR A USER ###

if ("$h_to:, $h_cc:, $h_bcc" contains "user@domain.com")
   or ("$h_from:" contains "user@domain.com")
then
   unseen deliver "archive-address@domain.com"
endif

The code above will send a copy of any email that is sent “To”, “CC”, and even “BCC” to your address. It will also send a copy for all outgoing mail. Be sure to replace the example addresses above with your actual email addresses. Save and exit the file.

Reconfigure & Restart Exim

Now, you need to go back to WHM and change the system filter file location. Basically, we’re going to reconfigured Exim to use that new file we made instead of the default one. Copy and paste the full path to your new file into the 3rd field:

Scroll down and hit ‘Save’. Finally, all you need to do now is restart Exim:

service exim restart

And that is that! Your server will now start archiving all your email to the address you specified. You’re going to start getting a lot of extra mail at that address so be sure you have some automatic message organization setup such as User level filtering in cPanel or Message filters in your email client to sort them all the messages into folders. If not, you may have a little bit of a messy inbox next time you log in

References

Special thanks goes out to cPanel Tristan. You always know your stuff and are great at helping! I really enjoy getting you in the ticket system and then also finding fixes in the forums that happen to be posted by you as well. It makes my day every time. Research for this article found on the cPanel forums here

Also, thanks goes to Vinayak on the cPanel forums here

Someday soon, I’ll have to post the pictures from my first session with light painting. For now, enjoy fun times #2:

[Show as slideshow]

This sprint commercial was my original inspiration for trying light painting. Check it out:

If you wanted to override the actual IP address of a site, you could ‘trick’ your computer by manually setting the IP address for a website and telling it where to go to find a website. This is extremely common and useful to do when testing a website that you are transferring to a new serer.

Imagine you are moving your website to a new powerful system. However, you do not want the existing site to go down; you want it to stay up at all times. You can copy the site and all it’s contents to the new server, but how do you test it without changing the DNS? You want to make sure that the site is going to work on the new server without any errors before you start sending traffic over to it. The best method to do this is to change your computer’s hosts file. You can send only your computer to the new server without affecting the live site at all.

The process for modifying the hosts file varies depending on what Operating System you are running. With the help of my good buddy Colin, we have developed a handy utility that will tell you how to modify your hosts file no matter you are running Linux, Mac, or Windows. The following section of this page will detect your OS and print instruction specific to you. Hope you enjoy!

Note about this article

This utility is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. They are using the utility with my permission.

That’s right, its an April Fool’s day prank! Anibal and I worked on the visual effects and they used my house for all the Girl gamer party shots (as well as the table crash). It was a ton of fun making it and a lot of work to pump out in only a few short weeks.

Starring: The Frag Dolls

What is the document root?

When you visit a web site, you are accessing a particular folder on the web server. The server knows to only serve up those files located at that folder to incoming visitors. The location of that web folder is called the “Document Root”.

It is similar to using a coat check. You present your ticket to the attendant and they fetch it from the back room.
In this metaphor, the coat is the site you want to visit and the attendant is the web server. The visitor doesn’t know the exact location where the coat is stored, but the coat does reside at a specific location.

For example, when you visit johns-carpentry.com, the server is pulling up the files at: /home/johnc/public_html. The document root is set by the Apache configuration.

What we are going to discuss today is what if you wanted to change that location? You would need to change the ‘Document root’ for the domain. cPanel’s default location may not serve your needs or you simply want to reorganize. In any case, I’ll show you how to make that change on cPanel.

Changing Addon Domains

There are two types of domains on a cPanel box that can have document roots: Main (primary) domains and Addon domains. Addon domains are easy to change the document root. Simply log into your cPanel and navigate to: Domains >> Addon domains

Next, edit the Addon domain path. To do so, simply click the edit icon next to the path, and type in your new path.

It’s that simple!

Changing Primary domains

For changing the main/primary domain, you will need to have root SSH access. Edit the following (replacing your user & domain info):

/var/cpanel/userdata/USERNAME/DOMAIN.COM

Look for the following line:

documentroot: /home/USERNAME/public_html

Modify it according to your needs. Save it and exit. Then, rebuild the Apache conf and restart Apache:

/scripts/rebuildhttpdconf
service httpd restart

The change will be immediate. Simply clear your browser cache and force refresh the page!

Note about this article

This article is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. Used with permission.

What is PHP memcache?

In my previous article, I showed you how to install Memcached, the service daemon. Now, if you would like your PHP software to interface with that daemon, you will want to install a PHP extension for it.

There are actually two separate implementations of a PHP Client that wraps the memcached (daemon); both are provided via the PECL library. One is called ‘memcache’ and the other is called ‘memcached’. I know that it is a little confusing that ‘memcached’ shares the same name as the daemon itself, but it IS a separate PHP wrapper.

This article will focus on installing ‘memcache’ as it is the most commonly used. You can use the information to install ‘memcached’ as well; the installation steps are the same. The main difference is that ‘memcached’ requires the libMemcached library. You can see a comparison of the two different PHP clients here: http://code.google.com/p/memcached/wiki/PHPClientComparison

Installation, the quick method

The easiest method is to simply use PECL’s ‘install’ command. This will grab the latest stable release, configure it with the default options, and add it to the server’s php.ini:

pecl install memcache

*Note: Un-installation is just as easy:

pecl uninstall memcache

Installation, the manual method

The quick ‘install’ method uses the default configuration options and should serve most peoples’ purposes. However, if you need more control over the installation options, you can manually install from source and add it flags as you need.

Download the source package via PECL:

cd /usr/local/src/
pecl download memcache

Unpack the tar and enter into the newly extracted directory (be sure to replace the X’s with your downloaded version):

tar -xvzf memcache-X.X.X.tgz
cd memcache-X.X.X

Configure and install:

phpize
./configure && make && make install

Verify the install

Verify the installation by displaying all the installed PHP modules. See if ‘memcache’ is listed:

php -m
memcache

Problems with manual installation

The ‘make install’ should load the module into your server’s extension directory automatically. However, if you do not see memcache listed in a ‘php -m’, you will need to add the module manually

First, you’ll want to very the location of your server’s extensions directory:

grep extension_dir /usr/local/lib/php.ini

It should return something similar to the following:

extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"

Next, copy the memcache module into that directory (be sure to replace the path with the one found on your server):

cp modules/memcache.so /usr/local/lib/php/extensions/no-debug-non-zts-20060613

Finally, add the module to your php.ini:

echo 'extension=memcache.so' >> /usr/local/lib/php.ini

Thoughts

It used to be a common issue that the quick ‘install’ method could not be used for servers where the /tmp partition was mounted ‘noexec’. The problem was that the ‘configure’ process could not execute because the PECL client downloaded the module into in /tmp. When /tmp is mounted ‘noexec’, servers cannot execute scripts from /tmp.

However, PECL now downloads and executes the script from /root/tmp. No need to worry about compiler errors with /tmp. You can use the ‘install’ method even with a secured /tmp.

Note about this article

This article is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. Used with permission.

This guide will help you setup Memcached on a CentOS server.

What is caching

Before diving into Memcache specifically, let’s take a step back. What is caching? Why should you care and why should you use it? Caching is used for two very important reasons: to speed up the delivery of the pages and to alleviate system resources. Caching is used to speed up dynamic sites; database driven sites will benefit most form caching. Think about a WordPress site. Each page you visit is not an actually file, but rather an amalgamation of the theme, widgets, posts, footers, headers, etc… Each time a page is accessed, PHP will generate the page requested on the fly from the database. It takes time to query the database to create the page. These database queries put a strain on the resources of your server.

However, what if instead of continually generating a new page, the same page, for every visitor, you were to turn those pages into static HTML files? No database querying is needed for the new visitors. A static file can be served up much faster and with significantly less resource consumption. Your visitors see their requested page sooner, and you save on CPU cycles. Everyone is happy. This is what caching does.

What is Memcached

Memcached is a general-purpose distributed memory caching system. It is one of the most popular caching tools and is used in such popular sites as: YouTube, Reddit, Zynga, Facebook, and Twitter.

According to Memcached’s official site, Memcached is defined as: Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

In simpler terms, it decreases database load by storing objects in memory.

Installing Memcached (daemon)

The quickest and easiest method would be to install via Yum. First, you must grab the RPM that matches your OS:

CentOS 6 (64 bit):

su -c 'rpm -Uvh http://mirrors.kernel.org/fedora-epel/6/x86_64/epel-release-6-5.noarch.rpm'

CentOS 6 (32 bit):

su -c 'rpm -Uvh http://mirrors.kernel.org/fedora-epel/6/i386/epel-release-6-5.noarch.rpm'

CentOS 5 (64 bit):

su -c 'rpm -Uvh http://mirrors.kernel.org/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm'

CentOS 5 (32 bit):

su -c 'rpm -Uvh http://mirrors.kernel.org/fedora-epel/5/i386/epel-release-5-4.noarch.rpm'

CentOS 4 (32 bit):

su -c 'rpm -Uvh http://mirrors.kernel.org/fedora-epel/4/i386/epel-release-4-10.noarch.rpm'

Now, to install it with Yum:

yum install memcached

Start the memcached service:

/etc/init.d/memcached start

Configure the memcached service to start when the server boots:

chkconfig memcached on

Finally, disable the RPM so that it is not used for future Yum functions:

perl -pi -e "s/enabled=1/enabled=0/g;" /etc/yum.repos.d/epel.repo

PHP memcache

For information on how to install the PHP extension so that your PHP software can interface with memcached (daemon), see my article here: How to install PHP memcache

Note about this article

This article is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. Used with permission.

In the last 24 hours, I have seen a large scale attack on the admin logins for thousands of WordPress sites. The attackers are using the User Agent ‘Bingbot’. Bingbot certainly is NOT the culprit in these attacks, but is, unfortunately, being spoofed. These spoofing bots are attacking the wp-admin page. So far, I have only seen this affect WP Mage and Mage Monster users.

A brute force attack on any login is certainly undesirable; you obviously don’t want any unauthorized person accessing your admin area. However, the real problem comes from the CPU strain this is putting on the hosting server. These constant requests to hundreds of websites on the server will drive up the CPU load, effectively tying up the resources. The server will not be able to serve up pages to legitimate traffic or legitimate search engine bots that are trying to crawl the sites.

There is a solution you can use to combat this problem. The solution is to block the Bingbot user agent from accessing your these admin pages. An IP based firewall block would do no good as the source IP’s have no common denominator; the IP’s are too spread out and come from many different geographical locations.

By implementing the following fix, you can reduce the loads back to normal operating levels allowing your site’s pages to load once again and you will not affect your rank with Bing. After a couple of days, the attack should have subsided and you should be able to safely reverse the changes. However, per Duane Forrester of Bing’s webmaster tools, you do not have to undo the block. There is no harm in permanently preventing your admin pages from being indexed (for reference, see his comment here).

Are you affected?

You can run a quick check to see if your sites are being hit with this spoofed Bingbot attack. Check your sites’ domlogs and look for any Bingbot User Agent requests that are hitting WordPress admin pages:

grep bingbot /usr/local/apache/domlogs/* | grep wp-login

If you receive numerous results from running that, especially from various IP addresses, it means that you are being affected. If you see many ‘POST’ commands in there, it means they are also trying to log into WordPress.

Example:

/usr/local/apache/domlogs/domain.com:24.153.219.159 - - [01/Feb/2012:15:27:18 -0500] "GET /wp-login.php?redirect_to=http%3A%2F%2FDOMAIN.COM%2Fwp-admin%2F&reauth=1 HTTP/1.1" 200 2206 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
/usr/local/apache/domlogs/domain.com:24.153.219.159 - - [01/Feb/2012:15:27:18 -0500] "POST /wp-login.php HTTP/1.1" 200 3084 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

How to block them

Now that you’ve verified that this directly affects you, time to block them and restore your server’s vitality.

#1 – Edit the pre-virtual host conf

We need to tell the server what is a “bad bot”. In this case, it is Bingbot. Then, we tell it to block it:

nano /usr/local/apache/conf/includes/pre_virtualhost_global.conf

At the bottom of the file add:

SetEnvIfNoCase User-Agent ".*bingbot" badbingbot

<Files wp-login.php>
	order allow,deny
	allow from all
	Deny from env=badbingbot
</Files>

If you do not want to block Bingbot on every domain and would rather only block it on a few particular affected domains, you can, instead, make the change to each domains’ virtual host via an include file. For more information, see cPanel’s documentation here: http://docs.cpanel.net/twiki/bin/view/EasyApache3/InsideVHost

#2 – Restart Apache

Now it is time to restart Apache so that our changes can take effect:

service httpd restart

Test it

Which Apache restarted, you should see your CPU load start dropping immediately. You will want to test it to make sure that bingbot is successfully blocked. Do what the attackers are doing, access your page while spoofing your User agent as Bingbot:

wget -U "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" http://domain.com/wp-login.php

Be sure to change ‘domain.com’ with your actual domain name. You should receive a 403 Forbidden error. If not, the file that is downloaded should be completely empty, meaning no content was served up.

Animation: Brian & Chris Pennington w/ DUO Media Productions
Writers: Christian Dawson, Thomas Wilson, and myself
Sound: DUO Media & Sean Richwine
Directed by: Me (Boom Shadow)

Pirate ship icon now available as a fun sticker!
.
.
.