
Ich habe in einer unserer Entwicklungsumgebungen einen Server geerbt und sofort festgestellt, dass er nicht gepatcht war, als der Heartbleed entdeckt wurde.
Jetzt habe ich es aktualisiert – einschließlich aller SSL-Bibliotheken – und selbstsignierte Zertifikate neu generiert, aber selbst nach einem vollständigen Neustart des Servers wird es immer noch von verschiedenen Heartbleed-Checkern als anfällig angezeigt.
Das ist der Stand der Dinge. Ubuntu/Kernel-Version:
root@server:~# uname -a
Linux server.domain.com 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
root@server:~#
OpenSSL-Bibliotheksversion:
root@server:~# dpkg -l|grep ssl
ii libio-socket-ssl-perl 1.53-1 Perl module implementing object oriented interface to SSL sockets
ii libnet-ssleay-perl 1.42-1build1 Perl module for Secure Sockets Layer (SSL)
ii libssl1.0.0 1.0.1-4ubuntu5.13 SSL shared libraries
ii openssl 1.0.1-4ubuntu5.13 Secure Socket Layer (SSL) binary and related cryptographic tools
ii python-openssl 0.12-1ubuntu2.1 Python wrapper around the OpenSSL library
root@server:~#
OpenSSL-Build:
root@server:~# openssl version -b
built on: Fri May 2 20:24:44 UTC 2014
root@server:~#
/etc/issue
enthält einige Inhalte von Cloud-Sigma, wo der Server gehostet wird.
Hat jemand eine Idee, wie man hier weiter vorgehen kann?
Danke
Antwort1
Sie sollten das ldd-Skript mit der tatsächlichen Webserver-Binärdatei ausführen. Ihr Webserver, insbesondere wenn es sich um einen proprietären handelt, ist möglicherweise statisch verknüpft oder lädt Ihre Bibliotheken aus einem ungewöhnlichen Verzeichnis. Ein Beispiel zum Überprüfen von Apache unter CentOS:
# ldd /usr/sbin/httpd
[snip]
libssl.so.6 => /lib64/libssl.so.6 (0x00002b94ab034000)
# yum whatprovides libssl.so.6
Loaded plugins: dellsysid, security
openssl-0.9.8b-10.el5.i686 : The OpenSSL toolkit
Repo : base
Matched from:
Other : libssl.so.6
[snip]