Kategorie: Sicherheit

Veröffentlicht am

Abschaltung der unverschlüsselten Nutzung unserer Mailserver zum 05. März 2025

Ab dem 05. März 2025 werden wir keine unverschlüsselten Verbindungen und keine Verbindungen mit den veralteten TLS-Versionen (1.0 und 1.1) zu unseren SMTP-, IMAP- und POP3-Servern mehr zulassen. Diese Maßnahme dient dazu, die Sicherheit Ihrer Daten und unserer Systeme zu erhöhen.

Warum diese Änderungen?

Unverschlüsselte Verbindungen stellen ein erhebliches Sicherheitsrisiko dar: Zugangsdaten und E-Mail-Inhalte können einfach abgefangen werden.

Die TLS-Versionen 1.0 und 1.1 gelten seit 2021 als veraltet und werden von aktuellen Betriebssystemen und E-Mail-Programmen ohnehin nicht mehr unterstützt.

Was bedeutet das für Sie?

Die meisten unserer Kundinnen und Kunden müssen nichts tun. E-Mail-Konten, die in den letzten Jahren auf einem PC oder Smartphone eingerichtet wurden, sollten automatisch mit den richtigen Einstellungen für verschlüsselte Verbindungen angelegt worden sein.

Dennoch sollten Sie dies in den Konto-Einstellungen Ihres E-Mail-Programms prüfen. Für die Verbindung zu unseren Servern muss SSL/TLS oder STARTTLS aktiviert sein. Die Standard-Ports lauten:

SMTP
smtp.variomedia.de		IMAP
imap.variomedia.de		POP3
pop3.variomedia.de
STARTTLS587, 25143110
SSL/TLS465993995

Die Nutzung von TLS 1.2 (seit 2008) und neuer wird von den meisten Systemen seit vielen Jahren unterstützt:

  • Microsoft Outlook: ab Version 2016
  • Mozilla Thunderbird: ab Version 52
  • Windows: ab Version 8
  • macOS: ab Version 10.11.6
  • iOS: ab Version 9
  • Android: ab Version 5

Problematisch könnten sehr alte E-Mail-Programme, Betriebssysteme oder IoT-Geräte (z.B. Router, Multifunktionsdrucker, Netzwerkkameras) aus der Zeit vor dem Jahr 2016 sein, die E-Mails über unsere Server verschicken oder abrufen.

Erlaubt eines Ihrer Geräte oder E-Mail-Programme keine verschlüsselten Verbindungen zu Mailservern, sollten Sie prüfen oder beim Hersteller nachfragen, ob es ein entsprechendes Update gibt.

Übergangszeit

Für eine beschränkte Übergangszeit bis zum 30.05.2025 stellen wir alternative SMTP- und IMAP/POP3-Server bereit, die noch TLS 1.0 und 1.1 und unverschlüsselte Verbindungen unterstützen:

ProtokollServername
SMTPsmtp-legacy.variomedia.de
IMAPimap-legacy.variomedia.de
POP3pop3-legacy.variomedia.de

Bei Bekanntwerden schwerwiegender Sicherheitsprobleme mit TLS 1.0 oder 1.1 kann jedoch eine frühere Abschaltung dieser TLS-Versionen erforderlich werden.

Hintergrund: Abschaltung veralteter TLS-Versionen

Transport Layer Security (TLS), auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist das am häufigsten verwendete Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Es wird beispielsweise zur verschlüsselten Übertragung von Webseiten (HTTPS) oder E-Mails (SMTPS, IMAPS, POP3S) genutzt.

Die ursprüngliche TLS-Version 1.0 wurde im Jahr 1999 vorgestellt, aktuell ist die TLS-Version 1.3 aus dem Jahr 2018. Die TLS-Versionen 1.0 und 1.1 wurden von der Internet Engineering Task Force (IETF) im März 2021 als veraltet eingestuft und sollten nicht mehr verwendet werden.

Die Unterstützung von TLS 1.0 und 1.1 bei verschlüsselten Webseiten (HTTPS) haben wir aufgrund von Sicherheitsproblemen bereits am 15. Februar 2020 eingestellt. Bei den E-Mail-Protokollen SMTP, IMAP und POP3 unterstützen wir jedoch aus Kompatibilitätsgründen bisher noch diese veralteten TLS-Versionen.

E-Mail-Programme verwenden normalerweise automatisch die aktuellste unterstützte TLS-Version, für die Nutzung einer aktuellen TLS-Version ist daher keine Konfigurationsanpassung erforderlich; es genügt ein aktuelles E-Mail-Programm zu verwenden. TLS 1.0 und 1.1 werden von aktuellen Betriebssystemen und E-Mail-Programmen nicht mehr unterstützt, diese verwenden immer TLS 1.2 oder 1.3.

Momentan können die TLS-Versionen 1.0 und 1.1 im E-Mail-Kontext mit bestimmten Schlüsselaustauschprotokollen und Verschlüsselungsalgorithmen noch ohne gravierende Sicherheitsprobleme genutzt werden, da es für diese bisher keine bekannten Schwachstellen gibt, die über die E-Mail-Protokolle ausgenutzt werden können. Einige bekannte E-Mail-Anbieter wie Google Mail unterstützen aus Kompatibilitätsgründen ebenfalls noch diese veralteten TLS-Versionen.

Im Hinblick auf mögliche Sicherheitsprobleme können wir diese veralteten TLS-Versionen jedoch nicht unbegrenzt weiter unterstützen, da es im Falle von neu entdeckten Problemen keine Updates der betroffenen TLS-Softwarebibliotheken mehr geben wird. Außerdem kann die Nutzung von veralteten TLS-Versionen durch Sicherheitsrichtlinien untersagt sein. Auch Cyberversicherungen untersagen ihren Kundinnen und Kunden vermehrt die Nutzung von Mailservern, die noch die veralteten TLS-Versionen unterstützen.

Veröffentlicht am

Neue Funktionen in der E-Mail-Verwaltung

Nutzer:innen eines Postfachs können für dieses Postfach unter https://my.variomedia.de/mail auch ohne Kundenmenü-Zugang zahlreiche Einstellungen vornehmen:

  • Änderung des Passworts
  • Setzen von automatischen Antworten mit Start- und Enddatum
  • Hinzufügen und Entfernen von zusätzlichen Empfängern
  • Konfiguration des Spamschutzes

Neu hinzugekommen sind nun zwei weitere Funktionen:

  • Anzeige des verbrauchten Speicherplatzes im Postfach (stündlich aktualisiert)
  • Anlegen von Anwendungspasswörtern

Beide Funktionen waren bisher nur im Kundenmenü verfügbar, für das in der Regel nur wenige berechtigte Personen (z.B. die Geschäftsleitung) einen Zugang haben.

Die Nutzung von Anwendungspasswörtern (auch “App-Passwords” oder “Application Passwords” genannt) ist ein deutlicher Sicherheitsgewinn bei der E-Mail-Nutzung. Anstatt für jedes Gerät und jede Anwendung, in der ein Postfach eingerichtet ist, das gleiche Kennwort zu benutzen, können Sie individuelle Passwörter für jedes Gerät anlegen. Geht ein Gerät verloren, können Sie genau dieses Passwort löschen und damit den unberechtigten Zugriff auf Ihre E-Mails verhindern. Mehr Informationen dazu finden Sie in unserem FAQ-Artikel “Wie nutze ich Application Passwords?“

Veröffentlicht am

DKIM-Signierung aller ausgehenden E-Mails

Seit einigen Wochen werden ausgehende E-Mails, die über unseren SMTP-Server verschickt werden, automatisch mit dem DKIM-Verfahren (DomainKeys Identified Mail) signiert.

Was ist DKIM?

DKIM ist ein Verfahren zur E-Mail-Authentifizierung, das ausgehende E-Mails mit einer digitalen Signatur versieht. Diese Signatur ermöglicht es dem empfangenden Mailserver zu prüfen, ob die E-Mail tatsächlich von Ihnen stammt und unterwegs nicht manipuliert wurde.

Warum ist DKIM wichtig?

DKIM erhöht die Sicherheit und Zuverlässigkeit Ihrer E-Mail-Kommunikation durch folgende Vorteile:

  • Schutz vor Fälschungen: DKIM verringert die Wahrscheinlichkeit, dass gefälschte E-Mails im Namen Ihrer Domain vom Empfänger akzeptiert werden.
  • Besseres Ansehen Ihrer E-Mails: Viele E-Mail-Provider wie Gmail oder Microsoft bevorzugen signierte E-Mails und stufen sie seltener als Spam ein.
  • Mehr Vertrauen: Empfänger können sicherer sein, dass Ihre E-Mails authentisch und tatsächlich von Ihrer Domain versendet wurden.

Mit der Einführung von DKIM stärken wir die Sicherheit und Vertrauenswürdigkeit Ihrer E-Mail-Kommunikation.

Tipps zur Nutzung von DKIM

Ausführliche Informationen zur Funktionsweise von DKIM, der Nutzung eines Postfachs als SMTP-Relay (Smarthost) sowie der Einbindung externer Domains finden Sie in unserem FAQ-Artikel „Wie kann ich DKIM zur Authentifizierung von ausgehenden E-Mails nutzen?“.

Darüber hinaus bietet DKIM die Grundlage für den Einsatz von DMARC. Mit DMARC können Sie festlegen, wie E-Mails behandelt werden sollen, die mit gefälschten Absendern verschickt wurden. Mehr dazu erfahren Sie in unserem Artikel „Wie erstelle ich eine DMARC-Richtlinie?“.

Veröffentlicht am

Probleme mit Leerzeichen in Apache Rewrite Regeln

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:

RewriteRule ^(.*)$ index.php?q=$1 [B,L,QSA]
Veröffentlicht am

Abschaltung des unverschlüsselten FTP-Zugriffs

Zum 01.06.2023 werden wir den unverschlüsselten FTP-Zugriff auf unsere Webserver deaktivieren. Der Zugang ist dann nur noch per SFTP, SSH und WebFTP möglich.

Die Änderung betrifft alle Nutzer:innen, die in ihrem FTP-Client (z.B. FileZilla, Cyberduck, FireFTP, ForkLift, Transmit oder WS_FTP) bisher den unverschlüsselten Verbindungsaufbau mit Port 21 eingerichtet haben. Bei dieser Verbindungsmethode werden sowohl die Zugangsdaten zum Webserver, als auch die Dateien selbst (inkl. Zugangsdaten zu Datenbanken, API-Keys etc.) unverschlüsselt übertragen. Dies ist ein unnötiges Sicherheitsrisiko.

Um auf das sichere SFTP-Verfahren zu wechseln, müssen Sie lediglich in den Verbindungseinstellungen das Proktokoll von “FTP” auf “SFTP” (oder “SSH File Transfer Protocol”) ändern. In manchen FTP-Clients müssen Sie zusätzlich den Port von 21 auf Port 22 ändern oder als Hostnamen anstelle von ftp://<domainname> künftig sftp://<domainname> verwenden.

Umstellung des Protokolls auf SFTP in FileZilla

Beim ersten Verbindungsaufbau per SFTP fragt der FTP-Client in der Regel danach, ob Sie dem Server vertrauen und speichert eine eindeutige Signatur des Servers auf dem PC.

Auch virtuelle Benutzer können sich künftig nur noch per SFTP mit dem Server verbinden; wie bisher ist hier Port 2222 im FTP-Client einzustellen.

Veröffentlicht am

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

Veröffentlicht am

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.

Veröffentlicht am

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.

Veröffentlicht am

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.

Veröffentlicht am

Probleme mit abgelaufenem Stammzertifikat

Am 30.05. ist ein Stammzertifikat der Firma Sectigo (ehemals Comodo) abgelaufen. Dieses Stammzertifikat wird in vielen unserer SSL-Zertifikate genutzt.

Dies sollte eigentlich kein Problem darstellen, da die Zertifikate mit einem weiteren Stammzertifikat signiert sind, das noch mehrere Jahre gültig ist. Leider unterstützen einige Anwendungen dieses sogenannte Cross-Signing nicht korrekt, und beschweren sich nun über das abgelaufene Stammzertifikat. Betroffen sind sowohl HTTPS-Verbindungen als auch IMAP, POP3 und SMTP.

Auch ältere Curl-Versionen auf unseren Legacy-Webservern unterstützen Cross-Signing nicht korrekt, dies betrifft viele PHP-Anwendungen, die Curl für HTTP-Verbindungen zu anderen Servern nutzen.

Wir haben das abgelaufene Stammzertifikat mittlerweile überall entfernt, dadurch sollte das Problem bei Verbindungen mit unseren Servern nicht mehr auftreten. Weiterhin haben wir die Liste der vertrauenswürdigen Stammzertifikate auf unseren Webservern aktualisiert, damit sollten auch keine Zertifikatsfehler bei der Nutzung von Curl auf unseren Webservern mehr auftreten.