Passwort-Reset für Endkunden von Resellern

Bereits seit einiger Zeit lässt sich in unseren Reseller-Verträgen in den Einstellungen konfigurieren, ob die eigenen Nutzer:innen für my.securehost.de einen Passwort-Reset durchführen dürfen.

Die eigentliche Passwort-Reset-Funktion fehlte allerdings bisher noch. Sie ist inzwischen unter https://my.securehost.de/ verlinkt und führt zur Seite https://my.securehost.de/reset-password:

Dialog für den Passwort-Reset unter https://my.securehost.de/reset-password

Mit dem Ausfüllen des Formulars wird – sofern vollständig und freigeschaltet – eine E-Mail von no-reply@securehost.de verschickt. Diese E-Mail enthält einen Link, der eine Stunde lang gültig ist. Durch das Anklicken des Links wird nach einer weiteren Bestätigungsabfrage ein neues Passwort für den Kundenmenüzugang gesetzt und angezeigt.

Muster einer E-Mail, wie Sie beim Passwort-Reset an Account-Inhaber:innen verschickt wird

Phishing-Mails im Namen von Variomedia

Heute Nacht wurden massenhaft Phishing-Mails im Namen von Variomedia an bei uns gehostete Postfächer gesendet, in denen die Empfänger dazu aufgefordert werden, das Variomedia-Webmail zu aktualisieren. Auf der verlinkten Webseite werden die Zugangsdaten des Postfachs abgefragt, die dann in den Händen von Unbefugten landen.

Phishing-Mail, die an Variomedia-Kunden geschickt wurde
Phishing-Mail, die an Variomedia-Kunden geschickt wurde

Diese Mails sind relativ gut gemacht und nicht auf den ersten Blick als Fälschung zu erkennen. Falls Sie der Aufforderung nachgekommen sind, und Ihre Zugangsdaten hier eingegeben haben, sollten Sie umgehend das Passwort des betroffenen E-Mail-Postfachs ändern.

Hinweise zur Erkennung von Phishing-Mails

Echte E-Mails von Variomedia enthalten immer eine persönliche Anrede mit Ihrem Namen.

In Phishing-Mails werden häufig E-Mail-Absenderadressen und HTTP-Links genutzt, die im Beschreibungstext eine abweichende Adresse anzeigen. So wird z.B. als Absenderadresse “Variomedia” angezeigt aber nicht die tatsächliche Absenderadresse nutzt eine .ca Domain, und im Link steht “https://www.variomedia.de/mail/pakete/”, doch der tatsächliche Link verweist auf eine .at Domain.

E-Mails von Variomedia haben immer eine Absenderadresse (nach dem @) der Domain variomedia.de oder einer oder einer Sub-Domain von variomedia.de.

Falls wir Ihnen per E-Mail einen Link auf eine unserer Webseiten senden, so achten Sie bitte darauf, dass in der Adresszeile des Web-Browsers eine Webseite unter der Domain variomedia.de oder einer Sub-Domain von variomedia.de geladen wird. Nur auf diesen Webseiten können Sie gefahrlos Ihre E-Mail-Zugangsdaten eingeben.

Ursprung der E-Mail-Adressen

Wir können nicht sicher sagen, woher die Versender die E-Mail-Adressen haben. Es scheint sich um eine relativ alte Liste zu handeln, da bei uns viele Postfächer angeschrieben wurden, die es gar nicht mehr gibt. Alle von uns stichprobenhaft getesteten E-Mail-Adressen befinden sich in Listen von früheren Leaks. In welchen Leaks Ihre eigene E-Mail-Adresse auftaucht, können Sie auf der Seite https://haveibeenpwned.com/ oder beim Angebot des deutschen Hasso-Plattner-Instituts unter https://sec.hpi.de/ilc/search?lang=de testen.

Keine Gefahr durch “Log4j”-Sicherheitslücke

Am 09.12.2021 wurde unter dem Namen Log4Shell eine schwere Sicherheitslücke in der von vielen Java-Anwendungen genutzten Softwarebibliothek Log4j bekanntgegeben, die das Ausführen von beliebigem Schadcode auf betroffenen Servern ermöglicht.

Java ist eine eigentlich als sehr sicher geltende Programmiersprache, die daher häufig für Server-Dienste genutzt wird und auch bei uns für einige Dienste zum Einsatz kommt. Die Log4j- Softwarebibliothek wird von vielen Java-Anwendungen zum Schreiben von Protokolldateien (Logs) genutzt. Durch spezielle Zeichenketten (z.B. im User Agent-Header einer gewöhnlichen HTTP-Anfrage) können Angreifer das Nachladen von beliebiger Software veranlassen, sofern diese unverändert zur Protokollierung an Log4j durchgereicht werden.

Wir haben nach Bekanntwerden der Sicherheitslücke alle von uns genutzten Java-Anwendungen überprüft und bei von der Sicherheitslücke betroffenen Anwendungen umgehend die von den Log4j-Entwicklern vorgeschlagenen Gegenmaßnahmen umgesetzt. In den Log-Dateien der betroffenen Server gibt es keine Hinweise darauf, dass diese Sicherheitslücke vor der Umsetzung der Gegenmaßnahmen erfolgreich ausgenutzt wurde.

Web-Anwendungen wie WordPress, Typo3, Magento usw., die von unseren Kund:innen oder uns auf unseren Webservern installiert werden, sind nicht von dieser Sicherheitslücke betroffen, da sie kein Java nutzen.

Datenbankserver nicht mehr über öffentliche IP-Adressen erreichbar

Die meisten unserer Datenbankserver (MySQL und MariaDB) waren bisher über öffentliche IP-Adressen auch außerhalb unseres Rechenzentrums erreichbar. Dies ist aus Sicherheitsgründen nicht ideal, weshalb wir für neue Datenbankserver seit Anfang 2020 nur noch interne IP-Adressen nutzen.

Für ältere Datenbankserver werden wir nun zum 04.10.2021 ebenfalls eine Umstellung auf interne IP-Adressen vornehmen, damit alle Datenbankserver nur noch innerhalb des Rechenzentrums von unseren Webservern aus erreichbar sind. Für Zugriffe außerhalb unseres Rechenzentrums ist dann der Aufbau eines SSH-Tunnels zu einem unserer Webserver erforderlich.

Wen betrifft diese Änderung?

Diese Änderung ist nur für wenige Kunden relevant, die von ihrem Rechner über lokal installierte Clientsoftware wie HeidiSQL oder Warenwirtschaftssysteme direkt auf unsere Datenbanken zugreifen. Falls Sie unsere Datenbanken nur für Web-Anwendungen wie WordPress nutzen, und nicht von außerhalb auf die Datenbankserver zugreifen, ändert sich für Sie nichts.

Welche Datenbankserver sind betroffen?

Die Änderung betrifft folgende Datenbankserver (MySQL 5.5, 5.6, 5.7, 8.0, MariaDB 10.1 bis 10.5):

  • db1
  • db2
  • db3
  • db4
  • db5
  • db6
  • db7
  • db8
  • db9
  • db10
  • db12
  • db13
  • db15
  • db19
  • db21
  • db22
  • db26
  • db27

Alle anderen Datenbankserver sind schon von Anfang an nur über interne IP-Adressen erreichbar.

Wie funktioniert ein SSH-Tunnel?


Ein SSH-Tunnel stellt eine verschlüsselte VPN-Verbindung zu einem unserer Webserver her. Über diesen Tunnel können Sie sich dann mit unseren Datenbankservern verbinden, als würde es sich um lokale Datenbankserver handeln.

In unserem FAQ-Artikel “Wie kann ich mich verschlüsselt mit einem MySQL-Server verbinden?” beschreiben wir den Verbindungsaufbau über einen SSH-Tunnel für verschiedene Software-Clients und Betriebssysteme.

Wir haben festgestellt, dass nur auf etwa 0,6% aller Datenbanken ohne einen SSH-Tunnel zugegriffen wird. Nutzer, die mit einem lokalen SQL-Client auf die Datenbankserver zugreifen, haben hier nur einen überschaubaren Umstellungsaufwand. Aufwendiger könnte die Umstellung z.B. von Warenwirtschaftssystemen werden. Wir beraten Sie hier gern und helfen, eine pragmatische Lösung zu finden.

Wichtig ist: Nutzer, die weiterhin von außerhalb unserer Webserver auf unsere MySQL- und MariaDB-Datenbanken zugreifen möchten, müssen vor dem 04.10.2021 aktiv werden, damit dieser Zugriff auch nach der Umstellung noch funktioniert.

Wir werden alle Kunden, von denen wir aus Logdateien wissen, dass sie in den letzten Wochen entsprechende Zugriffe auf Datenbanken hatten, explizit anschreiben. Hören Sie nichts von uns, besteht mit großer Wahrscheinlichkeit auch kein Anpassungsbedarf.

Aktualisierung vom 30.09.2021: Ursprünglich sollte die Änderung am Freitag, den 01.10.2021 durchgeführt werden. Um bei eventuellen Problemen für Kunden besser erreichbar zu sein, haben wir die Umstellung auf Montag, den 04.10.2021 verschoben.

Wie sicher sind meine Daten bei Variomedia?

Der Brand eines Rechenzentrums unseres Mitbewerbers OVH und die damit verbundenen Datenverluste haben bei einigen unserer Kunden Fragen zur Sicherheit ihrer Daten bei Variomedia aufgeworfen. Wir nutzen diesen Anlass, um hier unsere Backup-Strategien zu beschreiben und die Brandschutzmaßnahmen im Rechenzentrum zu erläutern.

Was wird gesichert?

Wir führen tägliche (bzw. nächtliche) Sicherungen aller Webspace-Inhalte, MySQL-Datenbanken und E-Mail-Postfächer durch. Gesichert werden zudem alle Informationen, die in speziellen Datenbanken vorliegen, z.B. DNS-Einträge, Kalender und Kontakte in Open-Xchange und Webmail-Profile.

Eine besondere Maßnahme gibt es im besonders ausfallkritischen Bereich des E-Mail-Hostings: Alle Inhalte von Postfächern werden in Echtzeit auf einen zweiten Server synchronisiert. Dieser dient als “Hot Standby”. Fällt ein E-Mail-Backend aus, kann der zweite Server die Arbeit sofort übernehmen und es gehen keine E-Mails verloren.

Wie lange werden die Backups gespeichert?

Alle täglichen Backups stehen 30 Tage lang zur Verfügung. Zusätzlich bewahren wir ein Backup von jedem Sonntag für 6 Monate auf. Monatliche Backups von jedem ersten Sonntag im Monat halten wir für weitere 5 Monate vor. Insgesamt ist das älteste Backup daher in der Regel etwa ein Jahr alt.

Wie lassen sich Daten aus einem Backup wiederherstellen?

Auf Webspace- und MySQL-Backups können Sie selbst zugreifen. Eine Anleitung dazu finden Sie im FAQ-Artikel “Wie spiele ich ein Backup auf dem Server ein?”. Die Wiederherstellung ist auch durch uns möglich (kostenpflichtig).

Postfach-Inhalte können nur durch unsere Systemadministratoren wiederhergestellt werden. Nähere Informationen dazu finden Sie im FAQ-Artikel “Gibt es Backups meiner E-Mail-Postfächer?”.

Wohin wird gesichert?

Die täglichen Backups werden auf Servern gesichert, die im gleichen Rechenzentrum stehen, wie die Quellserver, von denen gesichert wird. Diese Backups helfen also nur bei Hardware-Fehlern oder bei selbst verursachten Datenverlusten, würden bei einem Brand im Rechenzentrum aber nichts nützen.

Aus diesem Grund betreiben wir in einem zweiten Rechenzentrum (ebenfalls in Berlin, aber geografisch getrennt) weitere Server, die als “Off-Site-Backup” dienen. Sobald die regulären, täglichen Backups erledigt sind, werden diese vom lokalen Backup-Server zum Off-Site-Backup-Server übertragen und dort für 30 Tage aufbewahrt.

Falls es also einen Brand in unserem primären Rechenzentrum geben sollte, stehen alle Daten vom Vortag im zweiten Rechenzentrum zur Verfügung und könnten von dort auf produktiv genutzte Server übertragen werden. Dieses Off-Site-Backup findet bei uns für alle auf unseren Servern gehosteten Daten statt und muss nicht kostenpflichtig gebucht werden.

Welche Brandschutzmaßnahmen werden im Rechenzentrum getroffen?

Die Server für unsere Webhosting-, Datenbanken- und E-Mail-Dienste sind in einem Rechenzentrum in Berlin untergebracht. Da es sich um ein sehr großes Rechenzentrum handelt, ist es in mehrere Gebäudebrandabschnitte mit hoher Feuerwiderstandsklasse (F 90 A) unterteilt. Die einzelnen Serverräume innerhalb des Rechenzentrums sind ebenso als Brandbekämpfungsabschnitte (F 90 A) ausgeführt. Dadurch wird verhindert, dass sich ein Brand innerhalb eines Serverraums innerhalb kurzer Zeit auf weitere Serverräume ausbreiten kann.

Um die Ausbreitung eines Brandes innerhalb der Serverräume zu erschweren, wurden für den Innenausbau ausschließlich spezielle, nicht-brennbare oder schwer entflammbare Materialien verwendet.

Die Serverräume sind mit Brandmeldern und einer automatischen Gaslöschanlage ausgerüstet: Im Falle eines Brandes wird der betroffene Serverraum automatisch mit einem speziellen Löschgas geflutet, das den Brand erstickt. Durch das Löschgas entstehen keine zusätzlichen Schäden an den Servern, wie sie etwa beim Löschen mit Wasser entstehen würden.

Zusätzlich zu konventionellen Brandmeldern sind die Serverräume mit einem Brandfrüherkennungssystem ausgestattet: Werden erste Anzeichen eines möglichen Brandes erkannt, so erfolgt eine umgehende Kontrolle durch Mitarbeiter des Rechenzentrums, die permanent vor Ort sind.

Durch diese Maßnahmen ist ein Brand des Rechenzentrums mit totalem Datenverlust sehr unwahrscheinlich.

Eigene Passwörter unter my.variomedia.de/mail

Passwörter für E-Mail-Postfächer bei uns lassen sich über drei verschiedene Wege setzen:

Bisher war es nur für Vertragsinhaber:innen und unter Verwendung der API möglich, ein Passwort frei zu wählen. Für Postfachnutzer:innen hingegen gab es nur die Möglichkeit, automatisch generierte Passwörter zu verwenden. Dies hat sich nun geändert.

Ab sofort ist es auch in den E-Mail-Einstellungen (my.variomedia.de/mail), eigene Passwörter zu wählen. Es gelten dabei strenge Richtlinien, die zu einfache Passwörter verhindern sollen. Ein gutes Passwort ist eher länger als kürzer und wird ausschließlich für einen einzigen Dienst verwendet. Wir empfehlen dringend die Nutzung eines Passwortmanagers.

Passwort-Regeln
Regeln zum Setzen eines Passworts unter https://my.variomedia.de/mail

Im Kundenmenü und per API ist es auch möglich, so genannte “Application Passwords” anzulegen. Hier handelt es sich um automatisch generierte Passwörter, die sich zusätzlich zum Haupt-Passwort eines Postfachs nutzen lassen und einer bestimmten Anwendung (z.B. Outlook oder Thunderbird) auf einem bestimmten Gerät (z.B. “Mein PC”) zugeordnet sind.

Auslaufen der Unterstützung von TLS 1.0 und TLS 1.1

HTTPS

Seit Anfang dieses Jahres haben die bekannten Web-Browser Chrome , Firefox, Safari, Internet Explorer und Edge begonnen, die Unterstützung der mittlerweile veralteten TLS-Versionen 1.0 und 1.1 einzustellen. Das TLS-Protokoll (früher SSL) wird zum verschlüsselten Webseitenabruf (HTTPS) und für den verschlüsselten Versand und Abruf von E-Mails genutzt.

Die TLS-Versionen 1.0 und 1.1 weisen diverse Sicherheitsprobleme auf und sollten nicht mehr genutzt werden. Wir werden daher die Unterstützung dieser TLS-Versionen auf unseren Webservern zum 15. Februar 2020 einstellen. Ab diesem Zeitpunkt werden für HTTPS-Verbindungen zu unseren Webservern nur noch die aktuellen und sicheren TLS-Versionen 1.2 und 1.3 unterstützt. Für E-Mail-Dienste (SMTP, POP3, IMAP) werden wir die veralteten TLS-Versionen zu einem späteren Zeitpunkt deaktivieren, da die Sicherheitsprobleme hauptsächlich HTTPS betreffen.

Mögliche Probleme

Alle modernen Web-Browser unterstützen die aktuelle TLS-Version 1.3. Die Vorgängerversion TLS 1.2 wurde bereits im Jahr 2008 vorgestellt, daher wird sie auch von etwas älteren Betriebssystemen und Web-Browsern unterstützt.

Nur bei sehr alten Browsern und Betriebssystemen (z.B. Windows XP, Android 4.3, iOS 4, OS X Yosemite) kann es durch die Deaktivierung von TLS 1.0 und 1.1 zu Problemen bei HTTPS-Verbindungen kommen.

Sie können bei ssllabs.com prüfen, ob Ihr Browser eine aktuelle TLS-Version unterstützt.

Kunden mit eigenem Webserver (Reseller.Dedicated bzw. Pro.Hosting-Paket ab Pro.B), sowie Nutzer unserer Legacy-Server für alte PHP-Versionen können auf Wunsch weiterhin TLS 1.0 und 1.1 für HTTPS nutzen, falls dies für die Kompatibilität mit älteren Browsern erforderlich sein sollte. Bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Einstellung der Unterstützung für SSH DSA Schlüssel

Mit dem anstehenden Update unserer Webserver-Plattform auf Ubuntu 18.04 geht ein Wechsel auf eine aktuellere Version der SSH Server-Software OpenSSH einher. Dadurch können jedoch keine SSH DSA-Schlüssel mehr genutzt werden, weil diese als nicht ausreichend sicher angesehen werden, und daher von aktuellen OpenSSH-Versionen nicht mehr unterstützt werden.

Falls Sie DSA-Schlüssel auf unseren Webservern für SSH oder SFTP nutzen, sollten Sie diese durch moderne Verfahren ersetzen. Sie können diese veralteten Schlüssel am Dateinamen id_dsa bzw. id_dsa.pub oder am Präfix ssh-dss in der authorized_keys-Datei erkennen.

Wir empfehlen die Nutzung von Ed25519- oder RSA-Schlüsseln, ECDSA-Schlüssel werden ebenfalls weiter unterstützt.

Application Passwords – mehrere Passwörter für ein E-Mail-Konto

Ab sofort lassen sich im Kundenmenü mehrere Passwörter für ein E-Mail-Konto einrichten. Dies ermöglicht zum Beispiel eine Zuordnung verschiedener Benutzer und / oder verschiedener Clients, die auf ein E-Mail-Konto zugreifen können.

Ansicht von Application Passwords im Kundenmenü
Ansicht von Application Passwords im Kundenmenü

Der Grundgedanke ist, dass ein Passwort niemals mehrfach verwendet werden sollte – nicht bei verschiedenen Diensten, nicht auf mehreren Geräten und nicht von mehreren Benutzern.

So können Sie bei der Einrichtung eines neuen Smartphones für genau dieses Gerät ein Passwort für das gewünschte E-Mail-Konto anlegen. Wenn jedes Gerät ein eigenes Kennwort nutzt (und speichert), müssen Sie dieses Kennwort auch nicht kennen oder selbst notieren; es kann besonders lang und damit sicher sein. Stellt sich heraus, dass sich zum Beispiel auf Ihrem Desktop-PC ein Trojaner befindet, der das im E-Mail-Programm gespeicherte Kennwort ausgelesen hat, müssen Sie nur dieses Kennwort entfernen – alle anderen Geräte oder Programme können weiterhin ihr eigenes Kennwort benutzen.

Es gibt auch weiterhin ein Hauptkennwort für ein E-Mail-Postfach. Sie können dieses Kennwort neu setzen und selbst bestimmen. Das Hauptkennwort wird zum Beispiel benötigt, um in unserem Menü für E-Mail-Einstellungen automatische Abwesenheitsmeldungen, Spam-Filter-Optionen oder zusätzliche Weiterleitungsziele einzustellen.

Anzeige des Passworts nach der Einrichtung
Anzeige des Passworts nach der Einrichtung

Application Passwords werden automatisch erstellt sind nicht änderbar. Wir möchten damit sicherstellen, dass sie individuell und sicher sind. Die Passwörter sind explizit dafür gedacht, in Geräten oder Programmen gespeichert zu werden – Sie müssen sie sich also nicht merken. Im Kundenmenü wird zudem angezeigt, wann und von wem ein Application Password erstellt oder gelöscht wurde. Auf diese Weise können Sie zum Beispiel auch einem Administrator zur Lösung eines Problems ein vorrübergehendes Kennwort einrichten, das Sie nach dem Ende der Arbeit wieder entfernen können – ohne dass Sie ein Kennwort auf verschiedenen Geräten ändern müssten.

Mit der Einführung von Application Passwords bieten wir ein Feature an, das es sonst nur bei sehr spezialisierten E-Mail-Hostern gibt. Wir würden uns über eine intensive Nutzung der Application Passwords freuen – sie tragen ganz erheblich zu mehr Sicherheit für das eigene E-Mail-Konto bei.

Deaktivierung von PHP 5.2, 5.3 und 5.5

Im April 2019 werden wir beginnen, unsere Webserver auf eine neue Linux-Distribution zu aktualisieren, um auch weiterhin den höchsten Sicherheitsstandards und Performance-Ansprüchen genügen zu können. Aufgrund von Inkompatibilitäten zwischen älteren PHP-Versionen und den von der Distribution bereitgestellten aktuellen Versionen von Standard-Softwarebibliotheken wie OpenSSL können wir auf der neuen Webserver-Plattform nur PHP-Versionen ab 5.6 anbieten.

Wir werden PHP 5.2 zum 15.04.2019, sowie PHP 5.3 und PHP 5.5 zum 15.05.2019 auf allen Webservern abschalten. Alle Kunden, die diese PHP-Versionen noch verwenden, erhalten von uns in den nächsten Tagen eine entsprechende Mitteilung mit konkreten Hinweisen, wo und wie diese Versionen noch verwendet werden.

Die Pflege der PHP-Versionen 5.2, 5.3 und 5.5 wurde durch das PHP-Entwicklerteam bereits 2012, 2014 bzw. 2016 eingestellt. Wir haben diese Versionen auf unseren Webservern nur aus Kompatibilitätsgründen mit älteren Web-Anwendungen weiterhin bereitgestellt. Dies ist nun auf der neuen Webserver-Plattform nicht mehr möglich.

Uns ist bewusst, dass es Skripte, Content-Management-Systeme und Shops gibt, die seit langer Zeit nicht aktualisiert wurden und nur mit PHP 5.2, 5.3 oder 5.5 funktionieren. Nicht immer ist eine Aktualisierung oder Anpassung mit wenig Aufwand möglich. Wir werden daher Kunden, die diese PHP-Versionen auch nach der Abschaltung benutzen müssen, einen speziell konfigurierten Webserver zur Verfügung stellen.

Da der Betrieb dieses Servers hohe Kosten verursacht, die sich auf wenige Kunden verteilen, werden wir nach einer kostenlosen Übergangsphase bis zum 15.07.2019 (PHP 5.2) bzw. 15.08.2019 (PHP 5.3/5.5) für die Nutzung einen monatlichen Aufpreis berechnen. Die Höhe des Aufpreises hängt von der Zahl der Kunden ab, die den “Legacy-Server” nach Ende der Übergangsphase noch benötigen. Wir rechnen zurzeit mit einem Preis von etwa 10,- Euro pro Monat pro Benutzeraccount.

Sollten Sie bei der Umstellung auf eine neuere Version Hilfe benötigen, lassen Sie es uns bitte wissen. Wenn sich herausstellt, dass Sie für eine bestimmte Webseite oder Anwendung zwingend weiterhin PHP 5.2, PHP 5.3 bzw. 5.5 benötigen, kontaktieren Sie uns bitte nach dem Erhalt unserer E-Mail, um die Migration auf den Legacy-Server zu koordinieren.

In unseren FAQ finden Sie einige häufige Fragen zur geplanten Abschaltung der älteren PHP-Versionen.