Mon serveur est toujours vulnérable au cœur même après avoir mis à jour OpenSSL
J'ai un serveur Ubuntu 12.04. J'ai mis à jour le package OpenSSL afin de corriger la vulnérabilité Heartbleed. Mais je suis toujours vulnérable même si j'ai redémarré le serveur Web, et même l'ensemble du serveur.
Pour vérifier ma vulnérabilité, j'ai utilisé:
dpkg donne:
dpkg -l |grep openssl
ii openssl 1.0.1-4ubuntu5.12 Secure Socket Layer (SSL) binary and related cryptographic tools
(launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12)
Assurez-vous que le libssl1.0.0 le package a également été mis à jour (ce package contient la bibliothèque réelle, le package openssl contient les outils) et tous les services utilisant la bibliothèque ont été redémarrés après la mise à niveau.
Vous devez redémarrer tous les services en utilisant openssl (service Apache restart).
Il est possible vous êtes un faux positif, selon la FAQ :
Je reçois des faux positifs (rouge)!
Soyez prudent, à moins que vous n'ayez glitché le site en martelant le bouton, il n'y a aucun moyen que je puisse penser qu'un rouge n'est pas un rouge.
Vérifiez le vidage de la mémoire, s'il est là, l'outil l'a obtenu de quelque part.
Disons que je suis certain à 99% que vous devriez mieux regarder si vous redémarrez tous les processus après une mise à jour correcte.
Mise à jour: toujours, je reçois régulièrement des rapports de versions non affectées devenant rouges. Veuillez venir commenter le problème si vous êtes concerné. Je cherche 3 choses: des vidages de mémoire (pour savoir d'où ils viennent), des horodatages (aussi précis que possible, essayez avec l'onglet Réseau), une description complète de ce que vous avez cliqué et tapé.
Vous pouvez tester votre site en utilisant un autre outil comme SSLLabs , et voir si vous êtes toujours signalé comme vulnérable.
Vous devez également signaler le problème avec le testeur http://filippo.io/Heartbleed comme décrit ci-dessus.
Il est possible que vous rencontriez le bogue répertorié sur la page FAQ . Il semble que dans certaines circonstances, vous pouvez obtenir une notification vulnérable même sur un système corrigé.
Je reçois des faux positifs (rouge)!
Soyez prudent, à moins que vous n'ayez glitché le site en martelant le bouton, il n'y a aucun moyen que je puisse penser qu'un rouge n'est pas un rouge. Vérifiez le vidage de la mémoire, s'il est là, l'outil l'a obtenu de quelque part. Disons que je suis certain à 99% que vous devriez mieux regarder si vous redémarrez tous les processus après une mise à jour correcte.
Mise à jour: toujours, je reçois régulièrement des rapports de versions non affectées devenant rouges. Veuillez commenter le problème si vous êtes concerné. Je cherche 3 choses: des vidages de mémoire (pour savoir d'où ils viennent), des horodatages (aussi précis que possible, essayez avec l'onglet Réseau), une description complète de ce que vous avez cliqué et tapé.
Je suggère de tester avec un autre test tel que Qualys pour confirmer que votre système n'est plus vulnérable. Si ce n'est pas le cas, rendez-vous sur Github et signalez-le.
Il est toujours cassé
Quel est? Le "serveur" dont vous parlez peut avoir une bibliothèque OpenSSl liée statique. Cela signifie que même si vous avez mis à jour votre système, votre application est toujours en danger! Vous devez parler immédiatement au fournisseur du logiciel pour obtenir un correctif ou désactiver le service jusqu'à ce que vous le fassiez.
Dois-je vraiment désactiver le service jusqu'à ce que le patch soit sorti?
Oui, la gestion d'un service vulnérable est extrêmement dangereuse au point de la négligence possible! Vous pourriez divulguer des données que le serveur déchiffre lors du transport et ne même pas le savoir!
Vous avez probablement un programme d'écoute sur 443 qui a une bibliothèque openssl liée de manière statique. Cela signifie que le programme a son propre openssl emballé avec lui - mettez également à jour ce programme! Si vous n'êtes pas disponible, informez le vendeur immédiatement et suspendez cette application si possible!
Si vous utilisez mod_spdy, assurez-vous de mettre à jour votre installation de mod_spdy. Voir https://groups.google.com/forum/#!topic/mod-spdy-discuss/EwCowyS1KT pour plus de détails. Vous devrez soit mettre à niveau le deb mod_spdy, soit supprimer complètement la version précédente.
Assurez-vous que votre nginx utilise la bibliothèque système: http://nginx.com/blog/nginx-and-the-heartbleed-vulnerability/
Ceci est très possible si l'application exécutée sur 443 utilise une bibliothèque statique pour OpenSSL. Si tel est le cas, vous devez mettre à jour l'application that pour ne plus être vulnérable.
J'ai finalement pu résoudre mon problème qui était similaire à OP. Mon serveur est une pile LAMP de Bitnami. En suivant ces instructions:
wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1g- 1-linux-x64-installer.run
chmod 755 bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run
./bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run --forcefix 1 --forcelegacy 1
http://community.bitnami.com/t/Apache-error-after-the-recommended-heartbleed-patch/23530/9