Archiv verlassen und diese Seite im Standarddesign anzeigen : Heartbleed?
Gibt es seitens der IT eine Aussage ob die Forumssoftware vom OpenSSL Problem betroffen war, ob man also vorsorglich seine PW aendern sollte?
edit ddd:
Der Forenserver verwendet KEIN SSL und ist daher NICHT von der sogenannten heartbleed-Lücke betroffen. Auch alle anderen von aussen erreichbaren Dienste auf dem Server sind NICHT betroffen.
Gibt es seitens der IT eine Aussage ob die Forumssoftware vom OpenSSL Problem betroffen war, ob man also vorsorglich seine PW aendern sollte?
... und die "Passwortdiebe" tun dann hier was?
Dreamdancer77
11.04.2014, 22:18
Da das Forum nicht über SSL-Verbindungen läuft (https://) dürfte es nicht betroffen sein.
Da das Forum nicht über SSL-Verbindungen läuft (https://) dürfte es nicht betroffen sein.
Wenn das Leben immer so einfach wäre....:roll: betroffen sind auch SSH und SFTP Implementierungen. Ob das Forum solche verwendet, entzieht sich wohl unserer allgemeinen Kenntnis und kann nur vom OPS-Team beantwortet werden.
meshua
Kann man checken.
http://filippo.io/Heartbleed/
.
Der Check sagt ja nur etwas über den Status zum Zeitpunkt des Checks aus (also eventuell nach Update), nichts aber was davor war.
@Oldy: Passwörter können an anderer Stelle missbraucht werden falls sie doppelt vergeben wurden (was nicht gut wäre aber sehr oft gemacht wird). Mindestens ist aber eventuell die Internet-Identität geklaut.
Ich kann nur sagen - habe Mittwoch Abend meinen Provider angerufen, und siehe da - er hat bei einigen Linux-Servern (nicht bei unserem) Updates eingespielt. Auf Arbeit haben wir eine Liste welche Logins definitiv betroffen waren und die PW zu ändern sind (z.B. Amazon, Facebook, GOOGLE, YAHOO ...).
Wer ne Synology NAS betreibt sollte auch das Update von Freitag früh einspielen. Und mit Opera browsen ist erst mal passé...
Dreamdancer77
12.04.2014, 07:03
Allerdings sollten Synology Nutzer mit einer DS112j, DS211j oder RS214 erstmal auf das Update verzichten, Synology hat einen mächtigen Bug eingebaut. http://www.golem.de/news/synology-dsm-5-0-update-2-heartbleed-bugfix-legt-einige-nas-systeme-lahm-1404-105796.html
Habe nochmal nachgefragt. Also: Es genügt, wenn irgendeine https: - Kommunikation des Forum-Servers stattgefunden hat.
Das Eine ist die Verbindung des Forumsmitglieds mit dem Server, da ist http: unschädlich. Der Server wäre praktisch "infiziert" wenn er nur irgendwo anders hin https: kommuniziert; das kann z.B. im Rahmen von IT-Servicemaßnahmen der Fall gewesen sein.
Woher wohl bekommen Datendiebe Millionen E-Mail Adressen wenn nicht von "undichten" / gehackten Servern?
Möchte deshalb die IT-Verantwortlichen dieses Forums um Auskunft bitten: War die betreffende Softwareversion im Einsatz?
Schranzie
12.04.2014, 22:52
Sinnvoll wäre es vielleicht vorsorglich alle Passwörter zu ändern anstatt zu lamentieren und lange nachzuforschen. So ein Wahnsinns Akt ist ist das nicht.
Oh Mann, ihr kennt euch aber echt gut aus Jungs, was?
Jetzt werft ihr mal Google an und informiert euch über den Unterschied von SSL zu MD5! Mit MD5 werden eure Passwörter in der Forums Datenbank gespeichert, zusätzlich erhalten sie einen Salt. SSL war/ist in Teilen unsicher, das betrifft in diesem Forum aber die SSH Sitzung des Administrators und die sFTP Übertragung. Selbst wenn da die Userdatenbank abgezogen worden wäre, ständen die Passwörter in MD5 mit Salt drin.
So, und in der Zeit in der ihr euch hier "Sorgen" macht hätte jeder schon dreimal sein Passwort ändern können, oder nicht?
Basti
leministredupoudre
13.04.2014, 12:35
Oh Mann, ihr kennt euch aber echt gut aus Jungs, was?
:roll:
SSL war/ist in Teilen unsicher, das betrifft in diesem Forum aber die SSH Sitzung des Administrators und die sFTP Übertragung.
ssh ist nicht betroffen, da es nicht die heartbeat-Funktion benutzt, wie es in SSL/TLS der Fall ist, also unkritisch. ssh hat einen eigenen keep-alive Mechanismus.
solange auf dem Server nicht noch irgendwo ein mit OpenSSL-verschlüsseltes Administrations-Webinterface läuft, sehe ich hier bzgl heartbleed null Probleme. Und selbst wenn auf dem Server OpenSSL in der betroffenen Version läuft, ist es nicht gesagt, dass der Server bzw des Zertifikat selber anfällig ist. Aus Performance-Grunden stehen vor Web-Servern oft SSL-Konzentratoren/-Beschleuniger, von denen nicht wenige nicht auf OpenSSL basieren. Außerdem sind die Bedingungen, bzgl der Informationen, die ausgelesen werden können auch sehr unterschiedlich. D.h. je nach Web-Server und OpenSSL Kombination stellt sich das Problem etwas anders dar.
Ich will das Problem nicht verharmlosen, dafür ist es zu gravierend, aber man sollte nicht direkt in Panik verfallen, v.a. wenn man nicht alle Fakten kennt.
moin zusammen.
Wie man sehr leicht feststellen kann, verwendet das SonyUserforum kein SSL.
Daher gibt es auch keine Lücke infolge CVE-2014-0160 aka "heartbleed".
Andere Protokolle wie ssh sind nicht betroffen. Manche Implementierungen nutzen zwar die openssl-Bibliothek für Verschlüsselung und Schlüsselerzeugung, verwenden aber nicht das betroffene TLS-Protokoll und auch nicht die für die Lücke verantwortliche Hearbeat-Erweiterung von TLS nach RFC6520.
Auf unserem Server läuft nur der Webserver und ein besonders geschützter Administrator-Zugang. Andere Dienste wie ftp, ftps usw. oder irgendwelche hübschen, aber leicht zu knackende Freizeitadmin-Tools und -Oberflächen gibt es nicht.
Ich habe einen Hinweis im Startpost eingefügt, damit der Status sofort für jeden Interessierten sichtbar ist.
-thomas
ps: da es mangels verwundbarem Protokoll gar keinen Anlass gab sich mit dem Problem hier bzgl des Forenservers zu befassen, hat dieser Hinweis etwas gedauert. Andere Systeme, für die ich verantwortlich bin, sind leider betroffen und erforderten vorrangige Aufmerksamkeit.
cicollus
14.04.2014, 00:18
Wenn das Leben immer so einfach wäre....:roll: betroffen sind auch SSH und SFTP Implementierungen. Ob das Forum solche verwendet, entzieht sich wohl unserer allgemeinen Kenntnis und kann nur vom OPS-Team beantwortet werden.
meshua
Woher stammt denn nun wieder diese Information?
Es ist der TLS-Implementierung von SSL betroffen, die hat nichts mit SSH zu tun.
Und FTP via SSL nennt sich FTPs.
moin zusammen.
Wie man sehr leicht feststellen kann, verwendet das SonyUserforum kein SSL.
Daher gibt es auch keine Lücke infolge CVE-2014-0160 aka "heartbleed".
Andere Protokolle wie ssh sind nicht betroffen. Manche Implementierungen nutzen zwar die openssl-Bibliothek für Verschlüsselung und Schlüsselerzeugung, verwenden aber nicht das betroffene TLS-Protokoll und auch nicht die für die Lücke verantwortliche Hearbeat-Erweiterung von TLS nach RFC6520.
Auf unserem Server läuft nur der Webserver und ein besonders geschützter Administrator-Zugang. Andere Dienste wie ftp, ftps usw. oder irgendwelche hübschen, aber leicht zu knackende Freizeitadmin-Tools und -Oberflächen gibt es nicht.
Ich habe einen Hinweis im Startpost eingefügt, damit der Status sofort für jeden Interessierten sichtbar ist.
-thomas
ps: da es mangels verwundbarem Protokoll gar keinen Anlass gab sich mit dem Problem hier bzgl des Forenservers zu befassen, hat dieser Hinweis etwas gedauert. Andere Systeme, für die ich verantwortlich bin, sind leider betroffen und erforderten vorrangige Aufmerksamkeit.
Danke für die qualifizierte Information. Ein Server weniger beim Ändern von Passwörtern!
Viel Erfolg mit Deinen anderen Systeme! Herzlicher Gruss aus Dresden.
Erlanger
14.04.2014, 18:09
Oh Mann, ihr kennt euch aber echt gut aus Jungs, was?
Das Problem ist, dass die Medien nicht gerade hilfreich waren... in den vergangen Tagen wurden da m.E. ziemlich oberflächliche Informationen gestreut, die den durchschnittlichen User mehr verunsichern als helfen... und die technischen Details sind ja auch nicht ganz trivial... ;)
Nach der Lektüre einiger Seiten bei heise.de und heartbleed.com habe ich den Bug weitgehend verstanden.
Was mir noch nicht klar ist:
Muss ein Datendieb selber eine gesicherte Verbindung zu einem Server aufbauen und diesem dann während einer aktiven Verbindung "gefälschte" Heartbeat Pakete unterjubeln, um an die Datenhäppchen zu kommen?
Oder kann er direkt diese "gefälschten" Heartbeat Pakete jederzeit an einen Server schicken und dieser antwortet dann (sofern von dem Bug betroffen)?
So gut kenne ich mich mit den Protokollen leider dann doch nicht aus...