Heartbleed Schwachstelle in allen Systemen: Vorgehensweise

    Also ich habe heute Früh auch mein Zertifikat austauschen lassen, doch habe immer noch kein neues.


    Jetzt meine Frage(n):


    Ich habe das Update installiert (ich hatte nur eines) und anschließend alle Dienste neugestartet. Die selbstsignierten Zertifikate habe ich bereits erneuert. Ich nutze die Zertifikate "nur" für den Mailserver und den Webmail-Login. Das selbstsignierte für FTP.


    Was muss ich noch beachten? Wie sieht es mit SSH aus? Sollten vorsorglich alle Kunden die Passwörter ändern (speziell bei Mail und FTP)? Danke schon mal!

    Zitat von junkpad92

    Ich habe das Update installiert (ich hatte nur eines) und anschließend alle Dienste neugestartet. Die selbstsignierten Zertifikate habe ich bereits erneuert. Ich nutze die Zertifikate "nur" für den Mailserver und den Webmail-Login. Das selbstsignierte für FTP.

    Wichtig ist auch, dass man das libssl Update auch installiert, denn das ist die eigentlich Bibliothek, die von den Anwendungen benutzt wird! Auch von OpenSSL!
    Bitte überprüfe ob du das Update eingespielt hast, denn sonst bleibt das Problem weiterhin bestehen.


    Bei Debian ist es jedenfalls so, dass die Abhängigkeit nicht genau angegeben wurden, sodass bei einem Update das libssl1.0.0 Paket nicht zwingend erneuert wird!
    Wenn du das vergessen haben solltest, kann es sein, dass deine neu generierten Zertifikate bzw. Private-Keys (erneut) entwendet wurden!


    Was SSH betrifft:
    Hier musst du dir keine Sorgen machen.


    Viele Grüße
    Marcel Luckas

    junkpad: in meinem bugtracker sammle ich apticron mails. Darin steht folgendes:


    The following packages are currently pending an upgrade:


    libssl1.0.0 1.0.1e-2+deb7u5
    libssl-dev 1.0.1e-2+deb7u5
    libssl-doc 1.0.1e-2+deb7u5
    openssl 1.0.1e-2+deb7u5


    Wenn wir von den selben Updates reden, dann war die libssl dabei (war die erste Runde).


    Passwörter sollten quasi alle geändert werden. Da der RAM ausgelesen werden konnte. Es gibt ein paar Ausnahmen wie SSH mit KeyAuthentifizierung (da liegt auf dem Server der öffentliche Teil, wenn das im RAM ist, ist es nicht weiter wild).
    Bei anderen Sachen bin ich mir nicht sicher. Passwort ändern kann aber nicht schaden.


    Die zweite Runde habe ich nicht im Bugtracker, da ich schneller als apticron war.


    Moment: ich glaube mich zu erinnern, dass nur RAM ausgelesen wurde, der mit SSL besetzt wurde. Also quasi alle Passwörter, die verschlüsselt versendet werden können. Naja und unverschlüsselt gesendete Passwörter kann man dabei gleich mit ändern.

    Danke, Mainboarder!


    Meinst du nur Passwörter, die im Browser eingegeben und übermittelt worden sind, oder auch Passwörter, die über andere Wege übermittelt worden sind? Also z. B. Mailserver, SSH-Kennwort, FTP, etc.

    Zitat

    Passwörter sollten quasi alle geändert werden. Da der RAM ausgelesen werden konnte.

    Trotz Ernst der Situation, sollte man jetzt nicht alles als unsicher ansehen. Es konnte der RAM ausgelesen werden, den OpenSSL belegt hat. Darüber hinaus konnte nach den heutigen Erkenntnissen kein RAM ausgelesen werden.

    Ich habe jetzt trotzdem vorsorglich alle Passwörter auf dem Server geändert. Selbst die, die nur intern verwendet wurden.


    Ich finde es nur bedenklich, dass das jederzeit wieder passieren kann - und wir sind machtlos dagegen ...

    Zitat von [netcup] Felix

    Es konnte der RAM ausgelesen werden, den OpenSSL belegt hat. Darüber hinaus konnte nach den heutigen Erkenntnissen kein RAM ausgelesen werden.


    Und das heißt im Detail: Den gesamten Ram des Prozesses, der die OpenSSL-Libs verwendet! 8o


    Reales Beispiel einer meiner Serversysteme: Ich konnte HTTP-Traffic (nicht HTTPS!) anderer User sehen. Diese Daten gingen niemals durch OpenSSL hindurch! Der Webserver (Nginx) war allerdings für andere Zwecke über SSL erreichbar. Die ausgespähten Daten waren allerdings immer unverschlüsselt und kamen von FastCGI. Somit ist die Panik definitiv begründet und man sollte alle übertragenen Daten der letzten zwei Jahre als potentiell kompromittiert ansehen. Klingt hart, ist aber so…



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Bedeutet also jetzt, dass Kunden, die keine Mail erhalten haben, nicht betroffen waren?


    Maßnahmen können ja sowieso nur Server-Kunden selbst durchführen. Für die Hosting-Pakete dürfte also wahrscheinlich gelten, dass diese im Wesentlichen nicht betroffen waren (hier läuft ja auch teils CentOs)? Also könnte ich die Mail von meinem SSL-Anbieter bzgl. der Erneuerung des Zertifikats ignorieren?


    Danke schon mal für eine Antwort :)


    PS: Jetzt sehe ich auch, dass dieser Thread im Server-Forum ist... Ich bin da einfach nicht sehr geschickt in der Themenzuordnung :D Vielleicht kann mir trotzdem jemand meine Vermutungen bestätigen?

    Zitat von te-online

    Bedeutet also jetzt, dass Kunden, die keine Mail erhalten haben, nicht betroffen waren?


    Nicht unbedingt, Netcup hat (vermutlich) nur die häufig benutzten Ports geprüft. Andere Dienste können durchaus noch betroffen sein (weil kein Neustart gemacht wurde oder der Dienst eine eigene OpenSSL-Bibliothek verwendet oder ... oder ...).

    Wie geschrieben, haben wir nur Port 443 geprüft. Andere haben wir nicht geprüft.


    Bei Servern mit Management oder Webhosting haben wir uns um den Austausch der Zertifikate bemüht, sofern erforderlich.



    Mit freundlichen Grüßen


    Felix Preuß

    Zitat von [netcup] Felix

    Bei Servern mit Management oder Webhosting haben wir uns um den Austausch der Zertifikate bemüht, sofern erforderlich.


    Prima, als Webhosting-Kunde kann ich mich dann also zurücklehnen, da mein Zertifikat nicht ausgetauscht wurde ("nicht erforderlich").


    Danke für die Auskunft und schöne Ostertage :)