Ich bereite mich darauf vor, meinen Server (Debian Wheezy) zu patchen, und das wird eine Qual, weil ich einen Großteil davon aus dem Quellcode erstellt habe (Apache 2.4, PHP, MySQL).
Bevor ich mit dem Patchen beginne, möchte ich besser verstehen, welche OpenSSL-Dienste anfällig für das Leck sind. Offensichtlich sind HTTP/HTTPS-Dienste anfällig. Was ist mit SMTP, IMAP und POP? SSH? Oder ist esbeliebigöffentlich zugänglicher Dienst, der die betroffenen Versionen von OpenSSL verwendet, die ich kennen sollte?
Mein Server verfügt auch über IPMI/KVM (Supermicro), das ich zur Installation meines Betriebssystems verwende. Es ist über HTTP/HTTPS auf derselben Maschine zugänglich, aber mit einer anderen IP-Adresse. Ich frage mich, ob dies auch anfällig ist. Ich bin nicht sicher, ob der integrierte Supermicro-Webserver OpenSSL verwendet. Wenn ja, werde ich meinen Serveranbieter möglicherweise bitten, Firmware-Patches anzuwenden.
Antwort1
Offensichtlich sind HTTP/HTTPS-Dienste anfällig.
Nur das spätere ;)
Was ist mit SMTP, IMAP und POP?
Es gibtonlineUndofflineTests für Mailserver (und Webserver). Wenn Sie Debian verwenden, besteht eine gute Chance, dass Ihre Software mit einer Version von OpenSSL < 1.0.1 kompiliert wurde. Dann beginnt die Sicherheitslücke. Wenn die Binärdatei also statisch kompiliert wurde (siehe unten), überprüfen Sie sie zuerst auf diese Weise, wenn Sie sich nicht die Mühe machen möchten, sie neu zu erstellen.
SSH?
SSH verwendet diese Funktion nicht und war daher nicht betroffen.
Beachten Sie, dass es unter Debian nicht ausreicht, einfach die gemeinsam genutzte Bibliothek zu ersetzen, da aus irgendeinem Grund einige Server-Dinge mit aktiviertem OpenSSL statisch verknüpft zu sein scheinen. Um dies zu überprüfen, führen Sie ldddie Binärdatei aus. Wenn Sie wissen, dass die Anwendung SSL/TLS verwendet und weder zu libssl noch zu libgnutls eine Verknüpfung angegeben ist, wurde sie einkompiliert. Wenn einer der Heartbleed-Tests fehlschlägt, muss die gesamte App neu erstellt werden.