Heartbleed Vulnerability and You – A Patch Guide

Recently, the Heartbleed Bug (CVE-2014-0160), a serious vulnerability in the popular OpenSSL cryptographic software library was discovered. This is a very serious vulnerability which captures all SSL/TLS encrypted information, such as login details, email correspondence, instant messages, etc. It affected servers all over the world including huge international companies. More information about it can be found using the links below:

Heartbleed Bug
You can also Test your server for Heartbleed (CVE-2014-0160).

Status of different versions:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

It is strongly recommended to check your VDS and dedicated servers. If it is determined that you do have the vulnerability, fear not. We have steps below that you can follow to remove the heartbleed vulnerability.

How to Fix the Heartbleed Vulnerability

To begin, you will first need to access your server via SSH. Once logged in, perform the following commands:
yum clean all
yum update openssl openssl-devel
yum reinstall keyutils-libs* openssh* -y
/etc/init.d/httpd restart

This will update the packages that contained the vulnerability and restart the HTTP service. Once this is done, we also recommend that you restart all services that use openssl by doing the following:

/scripts/restartsrv_sshd && /scripts/restartsrv_mailman && 
/scripts/restartsrv_cpdavd && /scripts/restartsrv_cpsrvd && 
/scripts/restartsrv_httpd && /scripts/restartsrv_exim && 
/scripts/restartsrv_named && /scripts/restartsrv_dovecot && 
/scripts/restartsrv_courier && /scripts/restartsrv_pureftpd && 
/scripts/restartsrv_proftpd && /etc/init.d/cups restart

After all services have restarted successfully you can check the result by performing this one last command and confirming you have this fix in your changelog:

rpm -q --changelog openssl | grep CVE-2014-0160
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

As long as you receive the return line described above, you’re all set. If you have any issues, please don’t hesitate to open a support ticket.

We’d love to hear from you how we’re doing on our articles. Please feel free to leave a comment below!

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to FriendFeed Post to LinkedIn Post to Ping.fm Post to Reddit Post to Slashdot Post to Squidoo Post to StumbleUpon Post to Technorati

Share or Bookmark on other sites...

Do you ever see that little lock symbol in the address bar of your browser and wonder exactly what it’s doing? How does this “SSL” protect your data? I’m going to tell you a little story that will help understanding Secure Sockets Layer encryption a little easier.

Let’s say you have something you want to send the server over the internet that you don’t want prying eyes to have – a credit card number for example. If you just send it in plain text, anyone sitting out there with a packet sniffer monitoring traffic can find it, read it, and buy that new 50” LED TV they’ve been wanting… compliments of you! That’s where SSL comes in to play.

SSL requires a few things to work. First – there’s the box. This box will serve as the vessesslkeysl to transport your secure data back and forth. But sending stuff in a box won’t make any difference if it’s not locked! To fix that, both the server and yourself generate two keys that can either unlock or lock the box: a private key and a public key. In order to get the ball rolling, you and the server trade public keys. The trick here? The public key is only used to lock the box, so we aren’t concerned with the bad guys getting it. The only way to unlock the box is with our private keys, which never touch the network.

An SSL Transmission in Pictures

Once you and the server have each other’s public key, the transfer can begin! Don’t forget, even if the bad guy gets your public key, it’s fine! That only allows them to lock the box.

1. The server places a message in the box requesting your credit card, locks it with your public key, and sends you the box.


2. You unlock the box using your private key, and read the message. You then put your credit card information inside the box, lock it using the server’s public key, and send it back.


3. The bad guy received a copy of the box! Oh no! But wait…it’s locked with SSL encryption. He can’t get in because he doesn’t have a key to unlock the box. He can only lock it again with the public key.


4. The server receives the box which has been locked with it’s own public key. It can now use it’s private key to unlock the box and get your credit card data securely.


This is the idea behind SSL in a nutshell. There are many other features that are used to ensure the data you send is safe. These include randomizing the transmission of packets so that if some of your data is obtained, the thief has no way of knowing in which order it belongs. Most encrypted connections also have a very small window before a timeout is issued to prevent them from jumping in line with data of their own. An example of this would be entering a password. If a thief intercepts the password packet entirely, takes the time to hack it, and then sends it to the server themselves, it’s too late! The server has already closed the request.

Privacy is a very serious concern in this technological age. With an SSL certificate from GlowHost you can be sure that your account is providing the utmost security for your visitors, especially those that need to send sensitive information.

While this article is a narrow focus compared to SSL in general, this hopefully gave you an idea of exactly how SSL works.

Questions? Comments? Be sure to post below and let us know what you think!

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to FriendFeed Post to LinkedIn Post to Ping.fm Post to Reddit Post to Slashdot Post to Squidoo Post to StumbleUpon Post to Technorati

Setting up SSH access using keys for cPanel and WHM

The internet has become an extremely unsafe place. Numerous methods of attack are public access and anyone can try them. At the same time, new common vulnerabilities are discovered almost daily. Software developers do their best to close all new vulnerabilities, but it is next to impossible to keep. Bots, bots and more bots are scanning servers for different security holes and once they find one on your server, believe me, they will use 100% of it. Your server will work for proxy, spam sending or even bitcoin mining…maybe even without your knowledge.

GlowHost does it’s best to prevent attacks. We have been providing hosting for many years and have skilled professionals in this area.

Also, GlowHost is working in partnership with security firms and runs daily scans of all servers in order to find suspicious software. We do this day in and day out, constantly, and we are not going to stop. We do our best to secure our customers, because we care.

The latest issue we have noticed floating around the Interwebs is that the SSH service can be easily hacked if password authentication is enabled. At the time of this writing, most hosting companies know about this problem, but are being very quiet about it as there is no known fix other than forced key access, and how the attackers are able to do this is not 100% clear. Because the service has vulnerabilities, we had to close that feature in order to protect our customers. In order to keep this security measure in place, but still allow a secure connection, you can use an SSH key. Below I will describe how to set up SSH access using keys and gain access to the server.

Creating SSH keys

First of all, you need to login to WHM (login details are in your welcome letter from GlowHost). In the search field type “Key” (1 in the image example below) to filter the menu options and click on “Manage root’s SSH Keys” (2).

If you don’t have WHM access, you can do the same from cPanel -> SSH/Shell Access. Functions are the same as in WHM.

Now you will see keys set up on your server. Please do not remove keys belonging to the GlowHost technical team. If you do, we won’t be able to access your server and provide you with managed service.

Click on the “Generate a new key” link (3).

Creating keys

Now you will see fields to generate a new key pair. Enter the following information in the respective text box:

Name: Just the name of the key. Usually used to identify the owner.
Key Password: You can keep it blank, but we do advise strongly to create a password so nobody else can access the server using your key.
Key Type: RSA
Key length: No less than 2048 bits for RSA.


Click the Generate button. Keys will be created.

That’s it! You have now keys. Go back to “Manage root’s SSH Keys” section. There you will see that your key has been created.

You need to click on “Manage Authorization” and at the new page click “Authorize” in order to make the public key work.

Authorize key

Now you need to get the private key to your PC and keep it in a safe place. The public key will remain on the server. You can use one public key on different servers, like the lock you have on your home or your car, while your private key is the only one you can use to access the server (or open your locks).

In the same “Manage root’s SSH Keys” area, you will see the newly generated private key. Click on “View/Download key” button near the key that you have created before.

You will see two options. In case you are a Mac/Ubuntu/Other Linux user – just copy the text from the window to a file on your PC. You can name it key.ppk.

Download the key

If you are a Windows user, you will need to enter the passphrase you used while creating the key and convert the key to a format that Windows software (generally PuTTY) understands. Now copy the key in key.ppk file to your machine.

Using the key to access your server in MacOS.

1. Find the “Terminal” application in launchpad and start it.

2. Copy the key from your browser as described above.

3. Run the following command in your machine. Replace “USERNAME” with your username on your local computer:

vim /Users/USERNAME/.ssh/mykey.ppk

You will see the text editor appear. Press “shift” and “A” simultaneously.

Press “Command” and “V” simultaneously to paste the key.

Press “ESC”, then type :wq (including the colon) and press enter. This will save the key.

Now you are ready to connect to the server via SSH! Just run this command from the terminal window (replace USERNAME with your actual username on your local computer):

ssh -i /Users/USERNAME/.ssh/mykey.ppk root@ -p

The IP address and Port should be in your welcome letter. The system will also ask you for the passphrase.

Using the key to access your server in Windows.

1. While MacOS has an integrated terminal, you will need special software on Windows. Please download “Putty.exe.”

2. Run PuTTy. Expand the “SSH” node in the left bottom and click “Auth”. Now you need to show PuTTy the way to the downloaded private key by using the Browse button. It can have *.ppk extention or even *.txt – both will work.


3. Click on “Session” in the top left. Enter the “IP”, “Port” (both are in your welcome letter) and “Saved Sessions” (Which is a custom name for you to save this information) fields. Click on the “Save” button. You now have the session saved and don’t need to add the key again.


4. That’s it. Click “Open”, and the server will ask you for the passphrase you have used. Enter that and you will connect to the server.

We love to hear feedback and comments. Please post below to tell us what you think!


Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to FriendFeed Post to LinkedIn Post to Ping.fm Post to Reddit Post to Slashdot Post to Squidoo Post to StumbleUpon Post to Technorati