Archiv für die Kategorie: ISPConfig

Unsere Managed-Server verschicken unter verschiedenen Voraussetzungen Mails. Der wohl wichtigste Teil sind die Benachrichtigungen zum verbrauchten Speicherplatz.

System Mails verwalten

Du kannst diese Nachrichten individuell anpassen und neue Sprachen hinzufügen. Dazu wählst Du im Bereich „System“ links unten „System Mails“.

System Mails anpassen

Um eine Nachricht nach Deinen Wünschen anzupassen, wählst Du die entsprechende Mail aus:

Du kannst den Betreff und den Text der Nachricht individuell anpassen.

Wichtig Nachrichten mit der Sprache „en“ können weder gelöscht noch deaktiviert werden, da diese immer dann verwendet werden, wenn keine andere Vorlage gefunden wird.

System Mails hinzufügen

Wenn Du bei  Nachricht rechts auf das + Symbol klickst, kannst Du die entsprechende Nachricht in einer anderen Sprache anlegen.

System Mails benutzen

Wenn der Server eine Benachrichtigung verschickt (z.B. Quota-Benachrichtigungen), wird die entsprechende Vorlage in folgender Reihenfolge ermittelt:

• Vorlage die zur Sprache des Kunden (siehe Kunden / Sprache) passt und aktiv ist
• Vorlage die zur Sprache Englisch passt

Was ist HSTS?

HTTP Strict Transport Security (HSTS) ist eine Anweisung des Webservers, das den Web-Browser (oder ein anderes Programm) darüber informiert, wie die Verbindung zwischen Server und Web-Browser gehandhabt werden soll. Diese Information wird gleich am Anfang im sogenannten „Response Header“ gesendet.

Eine einfache Umleitung von HTTP auf HTTPS kann immer noch umgangen werden. Der „Strict-Transport-Security“ Parameter zwingt den Web-Browser, die Verbindung verschlüsselt über HTTPS aufzubauen und ignoriert dabei jedes Skript, das Ressourcen der Domain über HTTP laden will. Damit können z.B. weder Cookies oder Session IDs der Webseite gesammelt noch die Webseite auf eine Phishing-Seite umgeleitet werden.

Warum HSTS?

• HSTS ist eine Möglichkeit, die Sicherheit der Verbindung zu Deiner Webseite zu erhöhen.
• Die erhöhte Sicherheit kann sich auch positive auf das Ranking von Google auswirken.

Welche Voraussetzungen müssen für HSTS erfüllt sein?

• gültiges SSL-Zertifikat für die Webseite und alle weiteren Subdomains
• Umleitung aller Anfragen von HTTP auf HTTPS
• HSTS max-age muss mindestens 1 Jahr betragen
• HSTS includeSubDomains muss aktiviert sein
• HSTS preload muss aktiviert sein

Was bedeuten die einzelnen Werte für HSTS?

HSTS max-age

Zeit in Sekunden, während der der Web-Browser die Webseite als Known HSTS Host betrachtet und keine Verbindungen über HTTP aufbaut.

HSTS includeSubDomains

Stellt sicher, dass die HSTS-Richtlinie nicht nur für die Domain, sondern auch für alle Sub-Domains angewendet wird, z. B. example.de und www.example.de.

HSTS preload

Ob die Webseite in die von Chrome geführte (und von Firefox und Safari, IE 11 und Edge verwendete) HSTS-Preload-Liste aufgenommen werden soll. Wenn HSTS preload aktiv ist, wird der Web-Browser gezwungen, die Seite über HTTPS aufzurufen, da dem Web-Browser schon im Vorfeld bekannt ist, dass diese Seite nur über HTTPS zu erreichen ist.
Das Senden der Preload-Direktive kann Probleme verursachen und Benutzer daran hindern, auf die Webseite und ihre Subdomains zuzugreifen, wenn Du die Seite auf HTTP zurückstellst.
Wenn HSTS preload aktiv ist, kannst Du Deine Webseite unter https://hstspreload.org zu der von Chrome geführten Liste hinzufügen.

HSTS mit einer Webseite testen

Ehe Du HSTS für Deine Webseite „scharf schaltest“, solltest Du Deine Seite erst einmal mit HSTS testen. Für einen Test müssen folgende Voraussetzungen erfüllt sein:

• gültiges SSL-Zertifikat für die Webseite und alle weiteren Subdomains
• Umleitung aller Anfragen von HTTP auf HTTPS

Auf unseren Managed Servern kannst Du HSTS nur aktivieren, wenn Du für die Webseite auch ein gültiges SSL-Zertifikat eingerichtet hast. Andere Voraussetzungen werden automatisch mit angepasst, sobald Du HSTS aktivierst.

Wenn Du HSTS aktiviert hast, setzt Du zu Testzwecken zunächst „HSTS max-age“ auf eine Woche, um etwaige Probleme erkennen zu können. Wenn die Testphase erfolgreich und ohne Probleme verlaufen ist, kannst Du „HSTS max-age“ auf einen Monat setzen und Deine Tests verlängern, oder Du aktivierst HSTS gleich vollständig.

HSTS für eine Webseite aktivieren

Wenn Deine Webseite ein gültiges SSL-Zertifikat hat, kannst Du HSTS aktivieren. Melde Dich in ISPConfig an und öffne die entsprechende Webseite. Unter „Erweitert“ findest Du die passenden Optionen:

Diese Anleitung gilt nicht für eine Nextcloud-Installation, die Du über den Wizard angelegt hast – der Wizard erstellt die entsprechende Datei automatisch.

Wenn Du als „limitierter“ Shell-User (Chrooted Shell = Jailkit) den Befehel ‚php occ …‘ ausführen willst, musst Du zwei Änderungen an der Nextcloud-Konfiguration vornehmen. Wir verwenden dafür eine eigene Konfiguration, die bei einem Update nicht überschrieben wird und automatisch erkennt, ob ein Aufruf über die Shell oder die Webseite erfolgt.

Auf unseren Managed-Servern kannst Du Dir die custom.config.php direkt in ISPConfig für die jeweilige Webseite anzeigen lassen und kannst diese direkt in den config-Ordner per FTP hochladen.

In dieser Anleitung steht zwar nur Shell, das gilt aber auch alles für Cron-Jobs, die ‚Chrooted‘ ausgeführt werden.

Um den Modus zu finden, in dem ein Cron-Job ausgeführt wird, öffnest Du in ISPConfig den entsprechenden Cron-Job:

Im folgenden Beispiel ist unsere Webseite mit der Nextcloud-Installation im Verzeichnis /var/www/clients/client3/web1602/web installiert. Das Verzeichnis findest Du übrigens in ISPConfig bei einer Webseite im ersten Teil von „Abweichendes Document Root“, wenn Du den Bereich „Erweitert“ aufklappst.

Werte in der Nextcloud-Konfiguration anpassen

1. datadirectory
   Ein Chrooted Shell-User kann nicht auf den kompletten Pfad der Webseite /var/www/clients/client3/web1602/web zugreifen. Daher muss das datadirectory „umgeschrieben“ werden, wenn Du über die Shell „php occ“ ausführen willst. Wir verwenden dazu einfach eine custom.config.php.
2. dbhost
   Beim dbhost kannst Du nicht localhost verwenden. PHP verwendet bei localhost eine Verbindung über das Socket-File, da eine solche Verbindung am schnellsten ist. In einer Chrooted-Shell steht das Socket-File aber nicht zur Verfügung und Du bekommst den Fehler „Doctrine\DBAL\Exception: Failed to connect to the database“. Entweder stellst Du in der config.php den ‚dbhost‘ von ‚localhost‘ auf ‚127.0.0.1‘ um (dann erfolgt die Verbindung immer über TCP/IP ist langsamer) oder Du verwendest einfach unsere custom.config.php.

custom.config.php anlegen

Im config-Verzeichnis der Nextcloud-Installation legst Du die Datei custom.config.php an bzw. erstellst diese auf Deinem PC und lädst die erstellte Datei dann per FTP in das config-Verzeichnis.

Du musst in der custom.config.php nur zwei Stellen für Deine Nextcloud-Installation anpassen:

• $basedir – hier trägst Du den Pfad zu Deiner Webseite an, wie sie in ISPConfig angezeigt wird und lässt nur ‚/web‘ am Ende weg.
• $dir – darüber wird das data-Verzeichnis von Nextcloud gesetzt. Bei den meisten Installation liegt das data-Verzeichnis mit im Document-Root der Webseite. Wenn Du Dich per FTP anmeldest, kannst Du das Verzeichnis leicht finden:

Die custom.config.php sieht in unserem Beispiel so aus:

<?php
$basedir = '/var/www/clients/client3/web1601';
$dbhost = null;
if(php_sapi_name() != 'cli') {
  $dir = $basedir;
} else {
  $dbhost = '127.0.0.1';
  $dir = (!is_dir($basedir)) ? '' : $basedir;
}
$dir .= '/web/data';
$CONFIG['datadirectory'] = $dir;
if($dbhost !== null) $CONFIG['dbhost'] = $dbhost;

Wenn Du einen unserer Managed Server mit nginx verwendest, kannst Du Deine Webseiten auch mit HTTP/3 ausliefern lassen.

Das Prinzip von HTTP/3

Bei HTTP/3 handelt es nicht um eine Weiterentwicklung von HTTP/2 (SPDY). HTTP/3 unterscheidet sich deutlich von den anderen HTTP-Verfahren und kombiniert die Eigenschaften von HTTP/2 mit User Datagram Protocol (UDP). UDP wird z.B. für die Abfragen des DNS eingesetzt. Die übrigen Funktionen von HTTP/2 bleiben dabei vollständig erhalten (z.B. paralleles Streamen von Daten verschiedener Herkunft).

Unterschiede zwischen HTTP/2 und HTTP/3

Im Gegensatz zu HTTP/2 nutzt das neue Protokoll HTTP/3 zur Auslieferung der Webseiten nicht das TCP, sondern das UDP Protokoll und ist damit wesentlich schneller.

Bei TCP erfolgen immer mehrstufige Handshakes zwischen Server und Browser. UDP und das darauf basierende QUIC agieren hingegen verbindungslos. An Stelle der Kontrolle einer erfolgreiche Zustellung wird bei Bedarf lediglich die Integrität des Pakets und der Übertragung durch eine Checksumme validiert. Dadurch entfällt das sogenannte Head-of-line-Blocking (Datenstau) und dadurch das erneute Anfordern fehlender Pakete. Die Auslieferung Deiner Seite wird erheblich schneller.

Die Übertragung erfolgt nicht mehr über die IP-Adresse, sondern durch eine individuelle ID. Wenn der Besucher auf seinem Gerät eine neue IP-Adresse erhält (z.B. beim Wechsel von mobilen Daten ins WLAN) kann HTTP/3 den Download ohne Unterbrechung oder eine erneute Verbindung fortsetzen.

HTTP/3 aktivieren

Öffne die entsprechende Webseite in ISPConfig. Unter „Erweitert“ kannst Du dann direkt HTTP/3 aktivieren:

QUIC und HTTP/3 verlangen zwingenden HTTPS über TLS 1.3. Wenn Du bei „Minimum TLS-Version“ eine kleinere Version eingestellt hast, bedeutet das übrigens nicht, dass HTTP/3 dann nicht funktioniert (das nennt sich ja auch nicht max. TLS-Version). Wird die Seite über HTTP/3 angefordert, wird die Verschlüsselung automatisch auf TLS v1.3 hochgesetzt.

Clientseitige Voraussetzungen

Der Browser muss HTTP/3 unterstützen, damit der Besucher Deiner Seite von den Vorteilen profitieren kann. Unterstützt der Browser HTTP/3 nicht oder nicht vollständig, wird Deine Seite ganz normal über HTTP/2 ausgeliefert.

Die gängigen (aktuellen) Browser unterstützen übrigens HTTP/3 schon jetzt. Sporadisch kommt es aber zu einem seltsamen Problem: der Browser beschließen, QUIC und HTTP/3 zu ignorieren.

aktueller Status

Momentan befindet sich HTTP/3 noch in der Entwicklung und nicht zu 100% stabil. Es kann bei einzelnen Webseiten durchaus vorkommen, dass diese mit HTTP/3 nicht richtig funktioniern. Alle aktuellen CMS laufen nach unseren Beobachtungen aber komplett problemlos.

Wir haben vor einige Zeit auf unseren Servern den Webmailer Roundcube durch RainLoop ersetzt.

Roundcube gehört definitiv zu den besten OpenSouce-Lösungen im Bereich Webmail, wir haben uns aber am Ende für die Umstellung RainLoop entschieden, da dies Software weit weniger Resourcen benötigt, „out-of-the-box“ zahlreiche Features hat die bei Roundcube nur über Plugings zu lösen sind und bei einer Installation mehrere Mailserver nutzen kann.

RainLoop und Domains

Damit bei RainLoop eine Anmeldung für ein Postfach möglich ist, muss erst die entsprechende Domain im Admin Panel angelegt werden. Auf unseren Managed Servern passiert das ganz automatisch für Deine Maildomains, wenn bei einer Maildomain eine RainLoop Installation ausgewählt ist.

Wenn eine Domain (z.B. gmail.com) durch den Admin zugelassen ist, kann der Benutzer seine Email-Adresse bei dieser Domain mit anlegen und kann dann direkt zwischen verschiedenen Postfächern wechseln (oder in verschienenden Tabs im Browser öffnen), ohne sich bei verschiedenen Webmailern anmelden zu müssen.

Zusätzliche Authentifizierungsmöglichkeiten

Statt einer Anmeldung mit der Email-Adresse und dem Passwort, kann der Admin auch eine Authentifizierung über Google, Facebook oder Twitter erlauben.

Kontakte

Neben dem Speicher der Kontakte in einer lokalen Datenbank kann jeder Nutzer auch CardDAV nutzen und kann damit seine Kontakte auf zahlreichen Geräten synchron nutzen.

Wenn Du von Roundcube auf RainLoop wechseln möchtest, musst Du die gespeicherten Kontakte manuell umziehen. Wie das geht, haben wir unter Kontakte von Roundcube zu RainLoop übertragen beschrieben.