# ls /usr/lib64/libssl.so.*
/usr/lib64/libssl.so.10 /usr/lib64/libssl.so.1.0.1e

# yum info openssl

Installed Packages
Name : openssl
Arch : x86_64
Epoch : 1
Version : 1.0.1e
Release : 42.el7_1.9
Size : 1.5 M
Repo : installed
From repo : rhel-7-server-rpms
Summary : Utilities from the general purpose cryptography library with TLS implementation
URL : http://www.openssl.org/
License : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
 : machines. OpenSSL includes a certificate management tool and shared
 : libraries which provide various cryptographic algorithms and
 : protocols.

Note “Version” is 1.0.1e. But that denotes what version Red Hat based the relesae. Since that release, Red Hat has backported many future bugfixes, security fixes, etc, exposed by the “Release” value 42.el7_1.9.
https://access.redhat.com/security/updates/backporting/

Using Heartbleed (CVE-2014-0160) as the example (https://access.redhat.com/solutions/781793)
“Red Hat Enterprise Linux 7 include OpenSSL version openssl-1.0.1e-34.el7 which includes a fix backported from openssl-1.0.1g”

Each specific CVE can be check directly on Red Hat’s site, https://access.redhat.com/security/cve/CVE-2014-0160

You can also check directly on the command line. For example, checking for Heartbleed you would use:

# yum updateinfo list installed --cve CVE-2014-0160

This will show any RPM packages installed that apply to Heartbleed. But note — nothing will return on a RHEL7 system, because the original RPM released with RHEL7 was not vulnerable, so no additiona package needed to be installed to fix it.

Logjam, though, is a little more interesting.

# yum updateinfo list installed --cve CVE-2015-4000

RHSA-2015:1229 Critical/Sec. java-1.7.0-openjdk-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHSA-2015:1229 Critical/Sec. java-1.7.0-openjdk-1:1.7.0.85-2.6.1.3.el6_6.x86_64
RHSA-2015:1229 Critical/Sec. java-1.7.0-openjdk-headless-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHSA-2015:1185 Moderate/Sec. nss-3.19.1-3.el6_6.x86_64
RHSA-2015:1185 Moderate/Sec. nss-3.19.1-3.el7_1.x86_64
RHSA-2015:1185 Moderate/Sec. nss-sysinit-3.19.1-3.el6_6.x86_64
RHSA-2015:1185 Moderate/Sec. nss-sysinit-3.19.1-3.el7_1.x86_64
RHSA-2015:1185 Moderate/Sec. nss-tools-3.19.1-3.el6_6.x86_64
RHSA-2015:1185 Moderate/Sec. nss-tools-3.19.1-3.el7_1.x86_64
RHSA-2015:1185 Moderate/Sec. nss-util-3.19.1-1.el6_6.x86_64
RHSA-2015:1185 Moderate/Sec. nss-util-3.19.1-1.el7_1.x86_64
RHSA-2015:1072 Moderate/Sec. openssl-1.0.1e-30.el6_6.9.x86_64
RHSA-2015:1072 Moderate/Sec. openssl-1:1.0.1e-42.el7_1.6.x86_64
RHSA-2015:1072 Moderate/Sec. openssl-libs-1:1.0.1e-42.el7_1.6.x86_64

Each of those RHSA’s addressed Logjam. You can get a lot more information by using:

# yum updateinfo info installed --cve CVE-2015-4000

Note the use of “installed” in these commands. This shows information only about packages that are already installed. If you remove “installed”, you will see information only about packages that /could/ be installed.

https://access.redhat.com/articles/yum-cheat-sheet

ssh -N -D 127.0.0.1:8000 <user>@<ssh server fqdn>

That command sets up a SOCKS4/SOCKS5 proxy.  Just configure your Browser/OS settings to use 127.0.0.1:8000 as a SOCKS proxy, and you can now access any site that your SSH server can reach.

As posted in multiple places around the web:

Debian

/etc/init.d/ntp stop
date `date +"%m%d%H%M%C%y.%S"`

Red Hat

/etc/init.d/ntpd stop
date `date +"%m%d%H%M%C%y.%S"`

Update:

This first manifested itself for us in our Java stacks — all of our (dual processor) Tomcat servers were running at a load of 30-40.  However, this is a known (and fixed) kernel bug:

https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Apparently, simply forcing a reset of the date is enough to fix the problem:

date -s "`date`"