This is How to Fix OpenSSL Heartbleed for Server admin
Over the past few days, we have received an overwhelming number of
questions about the OpenSSL Heartbleed bug and how cPanel system
administrators should be handling this.
First of all, if you haven’t read Codenomicon’s write-up on the bug, which thoroughly explains what it is, you should look visit heartbleed.com.
Because their website already covers just about everything you need to
know, I don’t feel the need to rehash all the nitty-gritty details here.
I’m only going to address how you, a cPanel administrator, should
address this on your server.
Only CentOS 6.5 is vulnerable to this bug. Obviously this affects
other OS’s as well, but as a cPanel administrator you’re only dealing
with CentOS (and perhaps FreeBSD). If you use a version of CentOS older
than 6.5, read no further – you’re not affected and can rest easy.
You can test whether you’re vulnerable by using this tool against a website on your server that has an SSL certificate installed.
To clear this up real quick: OpenSSL is a vendor-supplied package that, in your case, is provided by CentOS. It is not supplied by cPanel,
so there’s no point in asking them to “fix” this. There is nothing for
them to fix. However, if you have system package upgrades enabled for
cpupdate, and cPanel updates run automatically on your server, chances
are the OpenSSL updates have already been installed. To configure your
cPanel update settings, check out this link, or go to WHM -> Update Preferences.
Check to see if you’re running the latest version as so:
root@server [~]# rpm -qa |grep -i openssl
openssl-1.0.1e-16.el6_5.7.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64
At this point you’re looking for version 1.0.1e or newer (at the time
of this writing, 1.0.1e is the latest). This update does not
necessarily fix the bug in question, but rather disables the TLS heartbeat extensions
that are vulnerable. A later version will likely fix the problem
altogether, but such is not available yet because RHEL has not released a
fix.
You also use this command to update Openssl:
yum update openssl
After OpenSSL is updated, you need to restart services. This is
necessary whether you updated OpenSSL yourself, or let cPanel do it
during its update process. The following services should be restarted:
- cPanel
- Apache
- Exim
- Dovecot/Courier
- Pure-ftpd/Proftp
- MySQL
- any other services that use SSL (Tip: you can use the following command to find a list of services to restart)
lsof -n | grep ssl | grep DEL | awk ‘{print $1}’ | sort | uniq
OR REBOOT for quickest way
Once this is done, you should be good to go. It is recommended,
however, that you re-key your SSL certificates and have then re-issued
and re-installed to prevent security problems resulting from a
compromised private key.
Revoking and Reissuing your SSL Certs/Keys
If you have purchased an SSL certificate from a provider and you have
updated your OpenSSL packages on your server, you will need to revoke
your old keys and you'll have to reissue new keys. This is a process
known as "rekeying".
This process is very dependent upon the SSL service that issued your
initial certificate, but you should search their administration
interface for an option that is similar to "rekey" or "reissue keys".
Most SSL issuers will revoke your former key when you rekey, but you can
usually also do this explicitly using their administrative interface.
Follow the directions that your SSL provider gives you. They may
give you very specific instructions for how to regenerate a CSR, or they
may not.
If they do not provide you with the specific openssl commands that they would like you to use, you can generate your new SSL CSR by typing something like this. Again, add sudo if you are not root:
openssl req -new -newkey rsa:2048 -nodes -keyout hostname.key -out hostname.csr
You will need to copy your generated CSR into your provider's web
interface after generation in order to rekey your server. You will then
need to download the new certificate from the web interface.
You will have to install the new keys to the same location that your
old keys and certificates were kept. The path that you'll need to use
for your certificate and keys will vary by distribution and how you
configured your web server. For instance, some are kept in /etc/ssl/certs while others may be kept in locations provided by your web server.
For example, if you are using the Apache web server, you should see a
line in your main Apache configuration file, a virtualhost file, or a
separately sourced configuration file that points to the location where
it looks for your SSL information:
SSLEngine on
SSLCertificateFile /path/to/your_domain.crt
SSLCertificateKeyFile /path/to/your_key.key
SSLCertificateChainFile /path/to/CA.crt
These may look different, but they should point you in the correct direction to find your SSL certificate location.
If you are using Nginx, you'll find similar directives that point to
your server's SSL certificate and key. They might look something like
this:
server {
. . .
ssl_certificate /path/to/your_domain.crt;
ssl_certificate_key /path/to/your_key.key;
. . .
}
Another option is to check your distribution's documentation or check
your server's filesystem to find out where your certificates are
stored.
When you are finished, you should restart your web server to use the
new keys. The method of doing this will vary by distribution and
server.
On Debian or Ubuntu, you can restart your web server by typing:
sudo service apache2 restart # For Apache web server
sudo service nginx restart # For Nginx web server
On CentOS or Fedora, you can restart by typing:
sudo service httpd restart # For Apache web server
sudo service nginx restart # For Nginx web server
For Arch Linux you should use something like:
sudo systemctl restart httpd.service
sudo systemctl restart nginx.service
This should allow your web server to pick up your new certificate changes.
Additional Considerations from a Client's Perspective
Because of the widespread nature of this bug, there are other
considerations that you should take into account as well. As a consumer
of web services and sites, you should also react quickly to try to
minimize the potential damage to your accounts and information.
You should consider any communication that you secured by SSL
previously to have been compromised by this bug. This means any kind of
interaction with secure websites were open to snooping.
A good first step is to change your password on every site that you use, after
you have verified that they have updated their OpenSSL versions to
patch this vulnerability. If you change your password prior to the
remote site patching their SSL version, your new password is just as
vulnerable as your old one.
One consideration that is of high importance is to secure any VPN
instances that you have set up. There are a few different ways that VPN
connections are implemented, but SSL is one of the most popular. For
instance, OpenVPN uses SSL. Any certificates required to connect to
your server should be regenerated to ensure that they are secured.
Another good measure is to remove all session keys and cookies. This
means regenerate API keys, clear cookies that are stored in your
browser, etc. This may be a massive inconvenience, but the cost of not
going through these pains now is that your accounts are basically wide
open and communication with remote servers that have not updated their
OpenSSL should be considered no more secure than plain-text.
