Join David Gassner for an in-depth discussion in this video Auditing and testing your secure servers, part of Heartbleed Tactics for Small IT Shops.
The heartbleed bug was introduced in open SSL 1.0.1 and was fixed in version 1.0.1g. It affects particular versions of Open SSL as follows. Versions of open SSL that probably include the bug include versions 1.0.1 through 1.0.1f inclusive. Older and newer versions probably don't have the bug. These include versions that were released prior to 1.0.1 and 1.01g and later.
The first thing to ask yourself is do I have secure services at all, and are my servers using a vulnerable version of openssl. If your organization's web pages are addressed with the http protocol, then there isn't a new vulnerability, since you aren't using SSL at all. Your data is already being transferred over the web unencrypted. Hopefully, you're not transferring user credentials or credit card information, or anything sensitive like that over an unencrypted connection.
But this bug won't have changed your status. But if you're pages are addressed with the https protocol, then you are using encryption and you should continue with these tests. If your site is available publicly, there are a number of tools you can use to test the site without having to dig into the server's configuration files, certificates or command line. One such tool is available at ssllabs.com/ssltest. On this web page, you can enter any domain name and it'll be tested and you can see a list of some sites that have been tested previously.
And how they turned out. If you enter a domain that's already been recently tested, you'll be taken immediately to the most recent report. For example, I'll test this site, SSLLabs.com. I'll enter it and click submit. And I see a listing of recent reports. I can then click into the report and see how the site did. You're looking for this information. Hopefully you should see the message this server is not vulnerable to the Heart Bleed attack. If you see any other information, even something that's a little bit ambiguous.
You should keep pursuing the issue and find out how your server is doing. If you're testing a server for the first time. It'll take a few minutes to generate a report. Be patient and let the process complete so you can find out your server's status. You can also evaluate your site's vulnerability based on which versions of various operating systems you're using. This is a list of operating system versions that are known to use OpenSSL. And were shipped with vulnerable versions.
Take a look at these versions and compare them to what you're using. Notice that each operating system version is accompanied by the OpenSSL version it's shipped with by default. If you've customized your operating system in any way This might not match up with your situation. And here's a list of operating system versions that were shipped with OpenSSL versions that are not vulnerable, either because they pre-date or they post-date the bug. If you have command line access to your server, you can also look at your servers SSL version directly.
From the command line use this command to just find the version number, openssl space version. Or for more verbose information. Type sudo open-S-S-L version dash-A. The sudo command requires administration access and you'll be prompted for your administrator password. But you'll be able to find out, not just the version of the OpenSSL installation, but also the date which it was built or compiled. Once you know which version of OpenSSL you're using you can figure out whether you're vulnerable.
And if you have any of the vulnerable versions, you should move onto fixing the server and evaluating what security assets you might need to update or replace.