Gefälschte Mails über Kundenaccount

Vermutlich durch ein schwaches Kennwort wurde ein Kundenaccount kompromittiert und zum Versand von SPAM-Mails verwendet. Da das Volumen der SPAM-Mails vergleichsweise gering war wurde der Angriff erst nach einigen Stunden bemerkt und das zugehörige Konto gesperrt. Alle Nutzer werden nochmals gebeten auf sichere Kennwörter zu achten.

Webmail wieder verfügbar

Nach einiger Zeit in Wartung ist das Webmail-Interface jetzt wieder nutzbar. So lassen sich Mails auch unterwegs abrufen oder serverseitige Mailfilter setzen. Bitte beachten sie, dass der Mailabruf an fremden Rechnern immer eine Gefahr des Ausspähens von Informationen mit sich zieht.

Serverwechsel

Im Rahmen der regelmäßigen Wartungen wurde der primäre Server ausgetauscht. Nach einigen Monaten Testbetrieb wurden die Webseiten nun verlegt, Mailsysteme sollten in kürze folgen. Mehr Arbeitsspeicher, schnellere Netzwerkverbindung, SSD-gestützte Datenbank- und Webserverspeicher – alles in allem sollte die Performance deutlich gestiegen sein.

ShellShock-Infos

Vor einigen Wochen machte die Sicherheitslücke „ShellShock“ die Runde. Über eine Lücke in „Bash“ war es möglich Code in eine Sitzung einzuschleusen. Generell sind unsere Systeme abgeschottet, wird über einen solchen Fehler eine Webseite angegriffen sind andere Seiten nicht betroffen. Im vorliegenden Fall gab es keine Hinweise, dass unsere Systeme eine verwundbare Definition zuließen, die entsprechenden Patches wurden umgehend nach Freigabe eingespielt.

Austausch der Zertifikate abgeschlossen

Soeben wurden die letzten Zertifikate entsprechend der letzten Ankündigung ausgetauscht. Wir haben die Wartung ebenfalls genutzt um nun in nahezu allen Fällen Verbindungen mit Perfect Forward Secrecy zu bevorzugen. Bitte beachten sie, dass für SSL-Verbindungen mit Internet Explorer 6 (Windows XP) keine sicheren Methoden zur verfügung stehen, dieser Client kann nicht auf verschlüsselte Informationen unserer Dienste zugreifen.

Informationen zur „Heartbleed“-Lücke

Sicher ist ihnen die Nachricht nicht entgangen: Ein schwerwiegender
Programmierfehler in der weit verbreiteten Programmbibliothek „OpenSSL“
erlaubt es auf nahezu jedem System Passwörter und private Daten zu
entwenden. Unsere Systeme wurden kurz nach Bekanntgabe der Lücke
aktualisiert, die Lücke ist somit nicht mehr nutzbar. Alle zentralen
Passwörter wurden umgehend geändert, die Zertifikate werden in den
nächsten Stunden ausgetauscht. Bitte beachten sie, dass auch auf ihrer
Seite vorhandene Kennwörter geändert werden sollten. Zudem sollten sie
dringend alle Programme, welche Verschlüsselung verwenden, zeitnah gegen
nicht betroffene Versionen ausgetauschen. Die meisten Hersteller
arbeiten an entsprechenden Notfallaktualisierungen und werden diese
Zeitnah zur Verfügung stellen.

Eine Analyse des Fehlers steht auf

zur Verfügung, allgemeine Informationen finden sie auf
. Ein Online-Test ist auf
verfügbar.

Aktualisierung 18.02. – Hinweis auf anstehende Änderungen in PHP

Am 18.02 werden diverse Sicherheitsaktualisierungen durchgeführt. Während des Vormittags kann es zu kurzzeitigen Einschränkungen kommen.

Bitte beachten sie: Mit der derzeit in Entwicklung befindlichen PHP-Version 5.6 wird das System standardmäßig verschlüsselte Verbindungen nur dann annehmen, wenn diese mit einem gültigen Zertifikat versehen sind. Üblicherweise sollte dies kein Problem sein, die meisten größeren Firmen setzen Zertifikate bekannter CAs ein. Wer mit freien Projekten kommuniziert sollte prüfen, ob ggf. selbstsignierte Zertifikate zum Einsatz kommen und uns rechtzeitig informieren. Eine Kommunikation mit Behörden (z.B. Elster) wird auf Grund der mangelhaften Implementierung und Gesprächsbereitschaft der Gegenseite unsererseits nach wie vor nicht unterstützt.

Ein Datum für den offiziellen Release für PHP 5.6 steht noch nicht fest, wir empfehlen trotzdem die genannten Punkte frühzeitig zu prüfen um möglichen Problemen frühzeitig entgegenwirken zu können.

Verschlüsselung bei YotaWeb: Bereits seit langem auf hohem Niveau

Seit den Enthüllungen durch Edward Snowden arbeiten viele Internetdienste fieberhaft daran die Sicherheit ihrer Infrastruktur zu verbessern – wir nicht, denn YotaWeb setzt bereits seit Jahren auf moderne Verschlüsselungsverfahren.

Verschlüsselung als Standard: Google stellt seit 2011 alle Seiten verschlüsselt zur Verfügung, viele andere Onlinedienste immerhin die Anmeldeseiten. YotaWeb ist seit über 3 Jahren Vollverschlüsselt.

Vor 2 Tagen stellte Twitter ihre Server auf einen Schlüsseltausch mittels „Forward Secutity“ um, diese Sicherheitsmaßnahme ist bereits seit langem aus unseren Servern aktiv.

Verschlüsselte Mailverbindungen ist eine der wichtigsten Baustellen der E-Mail-Provider. Google hat es vorgemacht, Kunden von Microsoft und Apple erhielten bisher keinen Zeitplan. Deutsch Unternehmen planen die Aktivierung dieses Standards aus dem Jahr 2002 bis 2014 unter dem Begriff „E-Mail made in Germany“. Unsere Server nutzen TLS via SMTP seit 2010 wann immer möglich automatisch.

Die ersten theoretischen Angriffe kratzen am schein des Verschlüsselungsstandards TLS 1.0 – dieser wurde 1999 eingeführt und 2006 durch Version 1.1 überholt. Dienste wie Amazon oder diverse Banken setzen weiterhin auf die Ausführung aus dem letzten Jahrtausend – unsere Server stellen verschlüsselte Verbindungen nach dem aktuellen Standard TLS 1.2 zur Verfügung.

Auch in Zukunft werden wir uns nicht ausruhen oder Mehrarbeit durch scheinbar unnötige Aktualisierungen scheuen um so auch in den kommenden Jahren ein hohes Sicherheitsniveau unserer Systeme erreichen zu können. Wir danken allen Unterstützern für ihr Vertrauen und freuen uns, dass sich unsere Anstrengungen als nicht so grundlos, wie einige Kritiker behaupteten, gezeigt haben.

Änderung der Standardfehlerseiten

Im Rahmen der letzten Wartungsarbeiten wurden die standardmäßig generierten Fehlerseiten optimiert: Ab sofort bleibt bei Anzeige einer Fehlermeldung die Ursprungs-URL in der Adresszeile des Browsers stehen, es findet kein 301-Redirect mehr statt. Selbstverständlich wird weiterhin der korrekte HTTP-Error-Code ausgegeben, sodass automatische Webseitenaufrufe wie z.B. Suchmaschienen den Fehler als solchen erkennen können. Des Weiteren werden auf allen Fehlerseiten nun Kontaktdaten des Seitenbetreibers eingeblendet.

Alle Änderungen treffen natürlich nicht zu wenn sie oder ihr System z.B. per .htaccess eigene Fehlerseiten definiert haben.