Find out if your server is affected
http://filippo.io/Heartbleed/
Run the command:
[root@austin ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
to get the version number of openssl. If the command shows e.g.:
[root@austin ~]# rpm -qa | grep openssl
openssl-1.0.1e-16.el6_5.7.x86_64
Your server might be vulnerable as the version is below 1.0.1g. But some Linux distributions patch packages, see below for instructions to find out if the package on your server has been patched.
If your server uses a 0.9.8 release like it is used on Debian squeeze, then the server is not vulnerable as the heartbeat function has been implemented in OpenSSL 1.0.1 and later versions only.
Fix the vulnerability
To fix the vulnerability, install the latest updates for your server.
Debian
apt-get update
apt-get upgrade
Ubuntu
apt-get update
apt-get upgrade
Fedora and CentOS
yum update
OpenSuSE
zypper update
Then restart all services that use OpenSSL.
On a ISPConfig 3 server, restart e.g. these services (when they are installed): sshd, apache, nginx, postfix, dovecot, courier, pure-ftpd, bind and mysql. If you want to be absolutely sure that you did not miss a service, then restart the whole server by running “reboot” on the shell.
Check if the Linux update installed the correct package
After you installed the Linux updates, check if the openssl package has been upgraded correctly. Some Linux distributions
patch packages, so “openssl version” does not always show whether the correct patch that fixes the vulnerability has been installed.
Check the package on Debian and Ubuntu:
dpkg-query -l 'openssl'
Here the output for a correctly patched Debian 7 (Wheezy) server:
dpkg-query -l ‘openssl’
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================-===============-==============-============================================
ii openssl 1.0.1e-2+deb7u5 amd64 Secure Socket Layer (SSL) binary and related
For Fedora and CentOS, use this command to find the installed package name:
rpm -qa | grep openssl
Here are the links with the release notes that contain the package names of the fixed versions:
Check Here for the packages:
https://rhn.redhat.com/errata/RHSA-2014-0376.html
Affected versions of the OpenSSL:
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.
Operating Systems
Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:
Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
CentOS 6.5, OpenSSL 1.0.1e-15
Fedora 18, OpenSSL 1.0.1e-4
OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c)
NetBSD 5.0.2 (OpenSSL 1.0.1e)
OpenSUSE 12.2 (OpenSSL 1.0.1c)
Operating system distribution with versions that are not vulnerable:
Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
SUSE Linux Enterprise Server
How to fix:
Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so latest fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS.
With regards to the openSSL heartbleed issue and resolution, should I revoke OR re-key my existing SSL cert?
Any certificate that was ever hosted on an internet-facing vulnerable version of OpenSSL should be revoked and replaced. The cost of exhaustively evaluating whether a certificate was in jeopardy is almost certainly going to be higher than the cost of simply replacing the certificate. This is also a good opportunity to make sure that your certificate key length and signature algorithms are ‘up to code.'”
Because the private key might be compromised you need to re-key the certificate instead of just renew it, e.g. use a new public/private key pair instead of renewing one. Revoking the compromised certificate need to be done too, which may be done automatically if you create the new certificate by the same CA but you should check this with the issuer (CA).
Note, that the revoking process of the current PKI structure in the browsers is bad, e.g. some don’t check, some ignore OCSP errors etc. And it is worse outside the browsers (e.g. scripts, mobile apps…). That’s why in the last big compromises or wrong behavior of CA (Comodo, DigiNotar, FGC/A …) you always got a new browser version 🙁
As noted on the Heartbleed site, appropriate reponse steps are broadly:
- Patch vulnerable systems.
- Regenerate new private keys.
- Submit new CSR to your CA.
- Obtain and install new signed certificate.