Wir haben heute früh ein Update der Webserver-Software Apache auf die aktuelle Version 2.4.56 eingespielt. Seit diesem Update gibt es nun vereinzelt Probleme beim Aufruf von URLs mit Leerzeichen.
Fehlermeldung
Falls Sie eine URL mit einem Leerzeichen aufrufen, erhalten Sie unter Umständen seit heute früh die folgende Fehlermeldung:
Forbidden
You don’t have permission to access this resource.
In den Error Logs findet sich dann folgender Fehler:
Rewritten query string contains control characters or spaces
Besonders häufig betroffen sind die Content Management Systeme Drupal und MODX, die problematische Rewrite-Regeln in der automatisch generierten .htaccess-Konfigurationsdatei verwenden.
Fehlerursache
Die Ursache für den Fehler ist ein fehlendes Escaping von Sonderzeichen in den Rewrite Regeln einer .htaccess-Konfigurationsdatei. Das Escaping von Sonderzeichen in Rewrite Strings war bis Apache Version 2.4.55 optional, seit Version 2.4.56 ist es aus Sicherheitsgründen (CVE-2023-25690) verpflichtend.
Sie können das Escaping über die Flags B (bei Umleitung auf Query Strings) bzw. BNP (bei Umleitung auf Pfade) aktivieren. Weitere Informationen finden Sie in der Apache-Dokumentation.
Beispiel
Die folgende Rewrite Regel des MODX Content Management Systems erzeugt bei Leerzeichen in der URL eine Fehlermeldung:
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Um die Fehlermeldung zu beheben, muss die Regel wie folgt geändert werden:
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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ü
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
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.
