Diese Woche haben wir weniger „sichtbare“, aber dafür genauso wichtige Änderungen vorgenommen. Mit unserer wachsenden Zahl von Kunden und Bestellungen steigt leider auch die Anzahl der betrügerischen Bestellungen und Buchungen, sei es mit gestohlenen PayPal-Accounts, Kreditkarten oder Bankverbindungen. Wir haben alleine in den letzten 4 Wochen einen Anstieg von betrügerischen Kreditkartentransaktionen um 600% (nein, da ist keine Null zu viel) verzeichnet. Tatsächlich ist das Volumen an betrügerischen und geblockten Kreditkarten-Transaktionen um ein vielfaches größer als der reguläre Umsatz (was natürlich auch daran liegt, dass die Betrüger es mehrfach versuchen). Dementsprechend haben wir momentan eine Menge mit Risk Management zu tun, was naturgemäß eine Sache ist, bei der man schlecht detailliert über Maßnahmen sprechen kann. Aber kommen wir zu dem, über das wir sprechen können:

Als große, aber schon behandelte Änderung haben wir HTTP/2 eingeführt. Zudem gab es diverse kleine und große Änderungen:

Verwaltung:

• Bugfix beim Hinzufügen von IDN-Domains in den Warenkorb, wenn die Unicode-Version verwendet wird
• Bugfix/Change: nach dem Einrichten eines PayPal-Abos für Webhosting-Pakete hat PayPal die Weiterleitung zu uns geändert. Wir bekommen die Abo-ID nicht mehr übergeben und können daher auch keine sinnvollen Informationen mehr anzeigen. Thanks, PayPal!
• Verbesserung bei der Zahlungsverarbeitung: in bestimmten Fällen wurden Rechnungen, für die SEPA-Lastschrift als Zahlungsmethode gewählt wurde, mit Guthaben verrechnet, obwohl das nicht gewünscht wurde
• Verbesserung WordPress-Toolkit: Plugins, die aktiv sind, werden nun beim Löschen automatisch deaktiviert. Vorher war ein separates Deaktivieren vor dem Löschen notwendig
• Verbesserung WordPress-Toolkit: die Konsolen-Ausgabe von Tasks (core update, theme/plugin update, activate, deactivate, uninstall, …) werden nun aufgezeichnet

Infrastruktur:

• durch die höhere Request-Parallelisierung von HTTP/2 war es für Webseiten, die viele Ressourcen einbinden (z.B. >500 Bilder) einfach möglich, Besucher durch die Firewall komplett auszusperren (inkl. IP-Bann auf dem gesamten Web-Frontend). Entsprechende Limits wurden vorsorglich erhöht
• Rate-Limiting von Web-Requests angepasst, so dass Anfragen, die wegen Überschreitungen mehrerer Limits abgelehnt werden, nicht mehr verzögert werden (die „Verzögerungstaktik“ einiger Limits erzeugt eine gleichmäßigere Auslastung in Burst-Situationen)
• Bugfix für ein Problem, bei dem Clients beim Brute-Forcing von FTP-Logins nicht gesperrt wurden

Zudem wurde in der letzten Woche einiges an Grafik, Layout und Animationen (yeah, wir bekommen Animationen auf der Webseite!) vorangebracht. Außerdem gab es noch einiges an internen Änderungen an der Build-Pipeline für unseren Frontend-Code. Unsere aktuelle Frontend-Generation (die noch nicht überall im Einsatz ist, aber immer häufiger verwendet wird) basiert auf ES6 und React.js, das von Brunch und Babel gebaut wird. Cooles Zeug! Und nun: schönes Wochenende! 🙂

HTTP/2 ist die Weiterentwicklung von HTTP, dem Web-Standard, der für die Kommunikation zwischen Browser und Server zuständig ist. Das HTTP-Protokoll wurde 1991 eingeführt und ist inzwischen etwas in die Jahre gekommen, denn das Web hat sich wesentlich verändert. Eine Webseite besteht nicht mehr aus einem, sondern aus sehr vielen Anfragen nach Bildern, CSS, Javascript, Videos uvm. Zudem wird Verschlüsselung als immer wichtiger erachtet, wobei HTTP gar keine Verschlüsselung spezifiziert, sondern dafür auf HTTPS verweist.

HTTP/2 hingegen beseitigt viele dieser Schwierigkeiten und bringt einige Features mit sich:

• HTTP/2 hat eine Möglichkeit, den Verbindungstyp (HTTP 1.0, 1.1 oder 2.0) auszuhandeln
• HTTP/2 baut nur eine einzelne Verbindung auf, auf der alle Kommunikation abgewickelt wird (Multiplexing)
• es werden dank Multiplexing weniger Verbindungen benötigt
• HTTP-Header werden komprimiert
• der Server kann per „Push“ weitere Anfragen direkt an den Browser liefern, selbst wenn der Browser sie noch nicht angefragt hat (z.B. für Vorab-Laden)

Insgesamt hat HTTP/2 eine deutlich modernere Ausrichtung als das in die Jahre gekommene HTTP 1.0/1.1. Diese Vorteile wollen wir natürlich auch unseren Kunden verschaffen.

Deshalb haben wir in den letzten 48 Stunden für alle Webseiten auf lima-city HTTP/2 ausgerollt!

Die Webseiten für Besucher per HTTPS bereitzustellen ist letztendlich die Leistung, die wir für unsere Kunden erbringen. Die Änderung ist also ganz enorm in den Auswirkungen und dem Risiko, für unsere Kunden und für uns (wir garantieren unseren Kunden Verfügbarkeit – ein Problem beim Rollout hätte uns auch wirtschaftlich enorm schaden können). Ein weiterer Blog-Post darüber, wie und unter welchen Kriterien solche Entscheidungen getroffen werden und wie unser technischer Aufbau zusammen mit der Nutzung unserer eigenen Cloud uns ermöglicht, solche Änderungen gefahrlos zu testen folgt bald! 🙂

Es tut sich einiges bei lima-city, und damit das nicht alles hinter verschlossenen Türen passiert, gibt es mal wieder ein paar Update-Infos von uns. Vor einiger Zeit hatte ich schon damit begonnen, Freitags Update-Infos zu lima-city bereitzustellen und hatte das nach einiger Zeit erst einmal wieder gestoppt. Ich greife das nun wieder auf, vielleicht etwas unregelmäßiger, aber wir werden sehen. Hier die wichtigsten Änderungen aus dieser Woche nach Themen:

Verwaltung:

• im Domain-Check ist die Registrierung und der Umzug von Premium-Domains hinzugefügt worden
• es werden die Reports des CERT-Bund nun automatisch an unsere Kunden weitergeleitet
• Bugfix SSL-Zertifikat-Verlängerung: ignoriert nun bekannt problematische Hostnamen
• Bugfix SSL-Zertifikat-Verlängerung: das bestehende Zertifikat wurde gleichzeitig zur Ausstellung des neuen Zertifikats gelöscht, dadurch war in einigen Fällen für einige Sekunden (~30s) kein SSL-Zertifikat vorhanden. Die Schritte laufen nun nacheinander ab.
• Bugfix WordPress-Toolkit: kann nun WordPress-Installationen verwalten, die „localhost“ als Datenbank-Hostnamen eingestellt haben
• Bugfix Restore-System: die Restore-Liste zeigt keinen Fehler mehr an, wenn das Backup zu einem Restore gelöscht wurde
• Bugfix/Verbesserung Restore-System: entferne Datenbank-Backups aus der Liste, die Verwirrung stiften können
• Verbesserung ADV-Vertrag: nach Vertragsschluss wird das PDF per E-Mail verschickt

Webhosting:

• Update auf Apache 2.4.29 (Premium-Webspace)
• Monitoring verbessert für Fälle, in denen Apache-Prozesse nicht korrekt beendet werden können und „hängen“ (z.B. unendliches warten auf einen Socket nach einem Segfault von PHP-FPM)
• Filter für ausgehenden Traffic an Command & Control-Server der Malware „Citadel“
• Updates an der Build-Infrastuktur zum automatischen Bauen von PHP-Paketen nach einem Release auf php.net

Wir arbeiten noch immer an dem neuen WordPress-Toolkit, das sich in großen Schritten der Fertigstellung nähert. Es sind noch zwei Punkte offen, die wir vor einem Release an alle Kunden beheben müssen und zwei weitere Verbesserungsmöglichkeiten würden wir auch noch gerne umsetzen.

Bis dahin wünschen wir ein schönes Wochenende bei dem schönen Wetter!

Noch eine Woche, dann ist Weihnachten…. erm, EU-DSGVO! Aktuell ein großes Thema, täglich bekommt man E-Mails dazu, und da dürfen wir nicht fehlen. Wir müssen unsere Kunden in diesem Fall als Auftragsdatenverarbeiter unterstützen, um ihre Webseite für die EU-DSGVO vorzubereiten. Dazu ist ein Vertrag zur Auftragsdatenverarbeitung notwendig! Aber der Reihe nach:

Viele Kunden fragen uns: was ist der Vertrag zur Auftragsdatenverarbeitung, und in welchen Fällen brauche ich ihn? Der ADV-Vertrag regelt, wie lima-city personenbezogene Daten, mit denen wir im Rahmen von Webhosting, Cloud-VPS oder E-Mail in Kontakt kommen, verarbeitet. Dieser Vertrag ist immer dann notwendig, wenn ein Kunde bei uns personenbezogene Daten verarbeitet. Verarbeiten bedeutet dabei alles, was irgendwie mit personenbezogenen Daten zu tun hat: speichern, übertragen, verändern, zusammenführen, etc. Auf dem Webspace ist ein klassischer Fall das Kontaktformular (der Absender gibt Name und E-Mail-Adresse an). Aber schon der Einsatz einer Firewall – was wir natürlich tun, sonst könnten wir u.a. nicht die Vorgaben der EU-DSGVO einhalten – beinhaltet die Nutzung von personenbezogenen Daten: die IP-Adresse wird dabei mit einer Liste von IP-Adressen, die gesperrt sind, abgeglichen – und schon ist die IP-Adresse „genutzt“ und damit werden personenbezogene Daten verarbeitet. Ein modernes Datenverarbeitungssystem mit einer Schnittstelle wie HTTP/HTTPS muss zwingend personenbezogene Daten verarbeiten, ansonsten kann es nicht sicher gestaltet werden. Die Katze beißt sich da in den Schwanz: wer ein sicheres Datenverarbeitungssystem betreiben will, muss dafür personenbezogene Daten (=IP-Adressen) verarbeiten und muss die dann wieder angemessen schützen – wozu wiederum die Verarbeitung personenbezogener Daten notwendig ist. Bei E-Mail-Postfächern ist es ebenfalls unmöglich, keine personenbezogenen Daten zu verarbeiten. Wann immer man eine E-Mail von einem „menschlichen Absender“ empfängt, sind darin personenbezogene Daten enthalten, in der Signatur, der Name des Absenders selbst ist personenbezogen, die E-Mail-Adresse häufig ebenfalls, etc.

Zusammengefasst: Wenn man ein E-Mail-Postfach auf unseren E-Mail-Servern benutzt oder eine Webseite bei uns hosted oder Cloud-VPS betreibt, dann ist dieser Vertrag notwendig. Ein häufiges Missverständnis ist übrigens, dass das neu ist: tatsächlich ist dieser Vertrag seit der Neufassung vom Bundesdatenschutzgesetz von 1990 – also mittlerweile 28 Jahre – notwendig, aber jetzt wird es plötzlich ernst genommen.

Wie schließe ich den Vertrag ab? Der Vertrag zur Auftragsdatenverarbeitung lässt sich ganz einfach in der Verwaltung unter dem Menüpunkt „ADV-Vertrag“ ausfüllen und abschließen. Dazu muss angegeben werden, welche Daten-Typen und zu welchem Zweck (Vertragsdaten, Personenstammdaten, Daten zur Lohnabrechnung, etc.) über welche Betroffenen (Kunden, Mitarbeiter, etc.) gespeichert werden. Für unsere Kunden mit kostenpflichtigen Webhosting-Paketen (Premium-Paket, Mini, Starter, Business, Excellence) ist es kostenlos möglich, bis zu 5 Verträge je Account anzulegen.

Bei dem kostenlosen Webspace müssen wir zur Refinanzierung von Aufwand und Verpflichtungen, die uns aus den Verträgen entsteht, eine Gebühr berechnen. Derzeit berechnen wir 10 € (inkl. USt) pro Jahr für den Abschluss eines Vertrags zur Auftragsdatenverarbeitung für Kunden mit kostenlosem Webspace. Eine einmalige Gebühr haben wir verworfen, da die Verpflichtungen aus dem Vertrag über Jahre laufen können, und zum anderen unsere Kunden keinen Anreiz hätten, ihre Verträge und Auftragsdatenverarbeitung regelmäßig zu prüfen. In einem Jahr (Juni 2019) werden wir dann prüfen, wie sich die Kosten für die ADV-Verträge für den kostenlosen Webspace entwickeln und entscheiden, ob wir die Gebühr nach unten oder oben anpassen müssen oder vielleicht sogar auf sie verzichten können. Kunden mit kostenlosem Webspace, die einen solchen Vertrag schließen möchten, wenden sich bitte per Mail an den Support.

Die Umsetzung der EU-DSGVO ist keine einmalige Sache, die nach dem 25.5.2018 abgeschlossen ist, sondern es sollen Prozesse, Systeme und Regelungen schaffen, die den Datenschutz dauerhaft garantieren und laufend optimiert und angepasst werden. Dementsprechend ist eine regelmäßige Prüfung der Verträge im Sinne aller.

Wenn noch Fragen offen sind: die Kommentarfunktion ist geöffnet und wie immer freut sich der Support über E-Mail 🙂 – Und nun ein schönes, verlängertes Wochenende!

Update: die Einschätzung zur Verarbeitung personenbezogener Daten bei Webhosting wurde korrigiert.

Diese Woche haben wir endlich das langersehnte SSH für alle Kunden ausgerollt. Über die Woche verteilt haben wir für einen immer größeren Prozentsatz der Kunden das Feature freigeschaltet, bis heute endlich die Freigabe für alle Kunden erfolgte. Im Gegensatz zu vielen anderen Hostern verwenden wir bei SSH keine komplizierten und nervigen Chroots, sondern sorgen mit AppArmor und Seccomp für die nötige Trennung zwischen Accounts, so dass Kunden nichts falsch machen *können*. Nebenbei fiel eine nützliche Idee für ein sehr interessantes Sicherheitskonzept für die Webseiten (=nie mehr ein gehacktes WordPress!) dabei heraus, an der wir forschen.

Nach dem Erreichen dieses Meilensteins kündigen wir direkt das nächste Feature an: wir arbeiten bereits seit einiger Zeit an einem WordPress-Toolkit, bestehend aus einem Menü für die Verwaltung von Plugins, Themes, Sprachpaketen und Updates über die lima-city Verwaltung, ohne dass das WordPress angefasst werden muss. Zudem haben wir ein wunderbar funktionierendes WordPress-Staging mit optionalem One-Click-Update gebaut.

WordPress-Staging ist bisher nicht so häufig anzutreffen, dass jeder gleich weiß, was damit gemeint ist: Staging-Systeme sind Kopien von Live-Systemen, die zum Testen und Prüfen gedacht sind. Das WordPress-Staging ermöglicht es auf einer Kopie der WordPress-Installation, gefahrlos Änderungen (Updates, Plugin-Installationen, größere Änderungen, Theme-Wechsel, Konfigurationsanpassungen etc.) am WordPress vorzunehmen ohne dass die Live-Seite sich während der „Wartungsarbeiten“ ändert, oder eine Wartungsseite angezeigt werden muss. Dafür gibt es eine Extra-Webseite (z.B. staging.meinblog.de für ein WordPress auf meinblog.de), damit man auch mit mehreren Leuten ausprobieren, testen und ändern kann. Wenn alles einwandfrei funktioniert wird die Live-Seite mit der Staging-Kopie überschrieben. Zudem kann die Staging-Kopie einfach wieder gelöscht werden, wenn etwas schief gegangen ist. Oder vielleicht möchte man einfach nur mal etwas testen, ohne dass es später live gehen soll – auch das ist kein Problem.

Integriert ist das optionale und absolut risikofreie „One Click Update“. Jeder kennt sicher die Situation, dass man etwas „kaputt-updated“, nach dem Update geht gar nichts mehr. Das passiert mit dem Staging-Tool nie wieder: beim Anlegen der Kopie kann wenn gewünscht direkt die gesamte Installation mit Plugins, Updates und Themes aktualisiert werden. Ein Klick in der Verwaltung genügt also, um eine Kopie der WordPress-Installation auf einer neuen Webseite zu erstellen und diese zu updaten. Dann kann in Ruhe auf der Kopie getestet werden, ob alles funktioniert, und wenn das der Fall ist, lässt sich das Update mit einem Klick in der Verwaltung live schalten. Wenn nicht: dann geht’s ab in die Mülltonne damit.

Wir werden das neue Tool (das schon bei einigen Kunden im Testbetrieb ist) nächste Woche noch optisch überarbeiten und dann live schalten, man darf also gespannt sein! Bis dahin ein schönes Wochenende, und nichts am WordPress kaputt machen 😉

Bei der Migration eines Kunden auf unsere Plattform haben wir vor kurzem ein kleines Nebenprojekt umgesetzt: Hosted Memcached.

Memcached ist der Klassiker unter den Cache-Servern. Da Anfragen in PHP isoliert sind (der PHP-Prozess vergisst alle Daten, wenn er den Request bearbeitet hat), können Daten, die man über mehrere Anfragen hinweg benötigt wie Sessions, Datenbank-Daten, Daten von APIs, etc. nicht mehrfach verwendet werden. Hier setzt Memcached an und bietet einen dauerhaft laufenden Server-Prozess, mit dem PHP kommunizieren kann und darin Daten in Text- oder Binärform ablegen und wieder abrufen kann. Üblicherweise werden in Memcache Sessions und Datenbank-Abfragen zwischengespeichert. Beim Ablegen von Daten gibt man gleichzeitig an, wie lange Memcached die Daten behalten soll (z.B. 5 Minuten), um immer „frische“ Daten zu erhalten. Bekannte Nutzer von Memcached mit riesigen Installationen sind Wikipedia oder Facebook.

Memcached funktioniert mit diversen PHP-Softwares und verbessert die Leistung: ownCloud, nextCloud, Magento, Shopware, Contao, Joomla, Woltlab Burning Board, Drupal.

Wir bieten unseren Kunden mit Paket „Business“ und aufwärts ab sofort zum Testen einen gehosteten, privaten Memcached-Server mit 128 MB Kapazität kostenlos an. Die Kapazität lässt sich selbstverständlich erhöhen, für viele Anwendungsfälle reicht ein kleiner Cache allerdings aus. Der Memcached-Server wird ausschließlich von einem Kunden genutzt und nicht geteilt.

Interessiert an einer Aktivierung von Memcache? Fragen? Frag uns!

Da kommt die Post und ich wundere mich über einen A4-Umschlag, der offensichtlich von einem Kunden kommt. Was mag darin wohl sein? Dokumente für einen Domain-Umzug? Ein unterschriebener Vertrag?

Nein! Es ist ein Ausdruck einer PayPal-Transaktionsbestätigung. Vom 18.8.2016.

Es bleibt ein großes Fragezeichen. Man muss nicht alles verstehen.

Wir waren letzte Woche Mittwoch und Donnerstag auf dem CloudFest und haben tolle Leute getroffen und einen regen Austausch gepflegt. Im Folgenden stelle ich ein tolles Projekt bzw. einen tollen Verein vor und skizziere, was sich bei lima-city in den nächsten Wochen und Monaten tun wird.

Der CMS Garden e.V. ist ein Verein, der sich um die „Förderung von Bildung, Wissenschaft und Forschung, insbesondere auf den Gebieten Content-Management und Open-Source-Software“ kümmert. Das bedeutet im Wesentlichen, dass sie auf Veranstaltungen und Messen über CMS‘ informieren und ein Netzwerk von CMS-Interessierten aufbauen. CMS Garden hatte einen Stand mit einem sehr freundlichen Team und wir haben uns toll ausgetauscht. Wir unterstützen diese engagierten Menschen nun finanziell mit einem kleinen monatlichen Dauerauftrag. Der CMS Garden ist auf diversen Veranstaltungen vertreten, gibt die Gartenfibel heraus und hat auch Software-Projekte, also schaut mal rein! Viele Grüße an das Team!

Als nächste größere Veränderung werden wir nach Abschluss unserer Testphase endlich SSH für den Webspace anbieten. SSH ist wird für alle bezahlten Webhosting-Pakete verfügbar sein. Die SSH-Zugänge sind für die Verwaltung des Webspace konzipiert und bringen selbstverständlich Unterstützung für Composer und git mit. Mit SSH wird die Verwaltung moderner CMS für Profis wesentlich einfacher und typische Administrationsaufgaben, vom Installieren von Software mit wget & tar bis hin zum Einspielen von Updates oder Bedienen von „Konsolen“-Binaries für Shops wie z.B. Magento lassen sich schneller und bequemer durchführen. Und wem das durch den Kopf schießt: nein, wir machen keinen chroot-Unsinn, die Zauberwörter heißen AppArmor und seccomp. Wir haben schon eine ganze Reihe an Kunden, welche die SSH-Zugänge testen, aber wenn auch Du daran interessiert bist, schicke uns bitte eine kurze Mail an den Support.

Zudem werden wir unser Partnerprogramm (derzeit nur in der Verwaltung über „Kunden werben“ zu finden) mit mehr Informationen auf der Webseite präsentieren und auf der Webseite auch über die neu kommenden Partner- & Reseller-Lösungen informieren. Im Partnerprogramm können unsere Kunden ihre Freunde, Bekannte oder Geschäftspartner werben und erhalten 10% Umsatzbeteiligung auf alle Umsätze des geworbenen Kunden. Unsere Partner- & Reseller-Lösungen gehen einen Schritt weiter und haben für verschiedene Hosting-Anwendungsfälle Lösungen. Das reicht von Bildungsträgern, die Webspace für Schulungen und Kurse benötigen, bis hin zu Agenturen, die ihre Kunden einfacher hosten wollen. Unsere Lösung für Bildungsträger ist schon im Einsatz und die Agenturlösung wird in den nächsten Wochen mit den ersten Kunden ausprobiert.

Beispiel: EV-Zertifikat für lima-city

Beim Thema SSL wird es etwas bunter: neben dem kostenlosen Let’s Encrypt werden wir weitere Optionen für SSL anbieten. Die zunehmende Verbreitung von SSL hat dafür gesorgt, dass das „sicher“ bzw. Schloss-Symbol in der Adresszeile nicht mehr den selben Stellenwert besitzt wie vor der großen Verbreitung von SSL. Wer sich also hervorheben möchte muss dies mit einem Extended Validated Zertifikat tun, das den Firmennamen in der Adresszeile anzeigt. Da der Prozess, ein solches Zertifikat zu beantragen, deutlich komplexer und aufwändiger ist als für normale SSL-Zertifkate (die Firma muss z.B. im Handelsregister registriert sein, die Existenz der Firma wird geprüft, es wird häufig zur Verifizierung ein Test-Anruf durchgeführt, ggf. müssen von einem Anwalt, Notar oder Steuerberater eine Bestätigung erstellt werden etc.) muss man hier zwar Geld und Zeit investieren, kann dafür aber auch mit mehr Vertrauen rechnen.

Als kleines Nebenprojekt haben wir zudem noch die Multi-Faktor-Authentifizierung mit YubiKeys auf der Liste. Kunden, die unsere Partner- und Reseller-Lösungen benutzen,  bekommen sogar den ersten YubiKey von uns gratis – denn wenn wir zusammenarbeiten, dann am Besten auf einer sicheren Grundlage.

So weit zu unserem groben Fahrplan für die kommenden Wochen und Monate. Für Fragen und Anregungen stehe ich gerne zur Verfügung – einfach eine Mail an den Support senden und wir reden darüber :-).

Webseiten-Betreiber, die unser Webhosting nutzen, müssen sich nicht um SSL kümmern. Unser System stellt alle Zertifikate, die für verschlüsselte Verbindungen nötig sind, automatisch und kostenlos über das großartige Let’s Encrypt aus, wenn die Webseite das erste Mal per SSL aufgerufen wird. Nur diese erste Verbindung zeigt einen Zertifikatsfehler an, doch sobald das Zertifikat vorhanden ist, wird es automatisch verlängert. Diese Technik hat den Aufwand, den unsere Kunden für SSL betreiben müssen, fast auf Null reduziert.

Eine Webseite per SSL erreichbar zu machen ist allerdings nur ein Teil-Lösung. Die Webseite darf nämlich – und das ist der springende Punkt – auch nicht mehr per HTTP (also unverschlüsselt) aufrufbar sein. Ist die Seite auch über HTTP erreichbar sind Downgrade-Attacken (ein Angreifer erzwingt eine unverschlüsselte Verbindung) möglich. Der Angreifer kann dann weiterhin Daten der Verbindung auslesen und verändern. Ein sicheres Setup erfordert also, dass die Webseite ausschließlich per SSL erreichbar ist.

Derzeit hosten wir 318.653 Webseiten auf unseren Webhosting-Infrastruktur. Von diesen haben nur 35.844 (11,2 %) Webseiten „SSL erzwingen“ aktiviert. Obwohl bereits ca. 34% der Requests per HTTPS geladen werden ist diese Zahl deutlich zu gering. Grundsätzlich gibt es nur einen Grund, weshalb „SSL erzwingen“ nicht aktiv sein sollte: wenn unsichere Ressourcen (z.B. Bilder, Javascript, CSS etc) geladen werden müssen, und der Server, auf dem diese Ressourcen liegen, kein HTTPS unterstützt. Das ist aber immer seltener der Fall. Zudem wird spätestens mit der EU-DSGVO eine unverschlüsselte Übertragung personenbezogener Daten (und dazu reicht schon ein Kontakt- oder Anmeldeformular) extrem problematisch. Google Chrome wird auch in naher Zukunft bei Webseiten, die nicht per SSL geladen werden, ein „nicht sicher“ in der Adresszeile zeigen. Es ist höchste Zeit, SSL zu nutzen!

Wir aktivieren daher schrittweise zwischen dem 19.3. und dem 23.3. für alle bei uns gehosteten Webseiten „SSL erzwingen“. In 99,9% aller Fälle ist kein weiteres Handeln erforderlich. Wir setzen die Option und die Webseite leitet beim Aufruf per HTTP auf HTTPS um, zusätzlich wird ein „Content-Security-Policy“-Header mit „upgrade-insecure-requests“ ausgeliefert. Der Browser schreibt aufgrund des gesetzten Headers alle HTTP-URLs auf HTTPS um.

Sollten nach der Aktivierung von „SSL erzwingen“ CSS, Javascript oder andere Ressourcen nicht mehr geladen werden findest Du mehr Informationen zur Fehlerbehebung in unserem Hilfe-Artikel zu „Mixed Content„. Den Status von „SSL erzwingen“ kannst Du unter „Websites & Domains“ einsehen: ist „SSL erzwingen“ aktiv, dann ist das Schloss oben rechts geschlossen. Ein Klick auf das Schloss schaltet „SSL erzwingen“ ein oder aus.

Es gibt keinen Grund zu warten: wir empfehlen, „SSL erzwingen“ schon jetzt zu aktivieren.

Die Änderungen, die wir in der Nacht von Montag auf Dienstag an unserer Webseite vorgenommen haben, sind wohl offensichtlich. Die gesamte Webseite inklusive unserer Angebote wurde überarbeitet und in einen neuen Look transformiert. Zusätzlich wird unsere Cloud ein halbes Jahr nach ihrer Einführung erstmals öffentlich beworben.

Die größte Änderung – neben dem Facelift –  ist sicher die Umstrukturierung der Webhosting-Pakete, die zu einigen Nachfragen geführt hat. Seit der Einführung des Premium-Pakets ist unser Kundenstamm stetig gewachsen. Wir haben viele neue Kunden und ihre Bedürfnisse kennengelernt und ein besonderes Problem mit dem Premium-Paket festgestellt. Die Einschätzung der Ressourcen, die eine Webseite benötigt, und die Realität liegen häufig weit auseinander. Dass Kunden schätzen, sie würden mehr Traffic erzeugen, als sie wirklich tun, ist weniger das Problem. Schwieriger sind die Power-User, die z.B. auf einem 12-Core-Server durchgehend 6 Cores mit PHP-Prozessen belegen und von denen auffallend viele nur den Mindestbetrag von 2 € zahlen. Das ist einerseits eine nachvollziehbare Ansicht – wir haben das Angebot so gestaltet – andererseits nutzt es die anderen Kunden aus, die wenig Leistung benötigen und den „fremden Leistungshunger“ zahlen müssen.

Dabei handelt es sich auch nicht um ein Problem, dass sich alleine technisch lösen lässt. Wir haben begonnen, die – für alle Kunden extrem hoch eingestellten – Limits des Premium-Pakets aufgrund dieser Power-User etwas zu drosseln, um die Qualität des Webhosting für andere Kunden zu verbessern. Das wurde wiederum von den Power-Usern nicht besonders gut angenommen. Wir mussten uns einiges dafür anhören.

Schlussendlich haben wir uns dann zu entschieden, die Angebot anders zu strukturieren, weil das Problem nicht der Ressourcenverbrauch der Kunden ist, sondern das Angebot. Das Premium-Paket hat zwar einen schönen idealistischen Anspruch, funktioniert in der Praxis aber nicht, weil die Power-User ihren Leistungsbedarf nicht abschätzen können oder vielleicht sogar bewusst unser Angebot wählen, da sie das Preis-Leistungsverhältnis sonst nirgendwo auf dem Webhosting-Markt bekommen. Unsere neuen Pakete sind hingegen viel besser auf die verschiedenen Kundenprofile abgestimmt. Wir haben sogar noch eine Schippe daraufgelegt und kräftig am Spitzen-Paket „Excellence“ gearbeitet. In diesem Paket haben wir mit PHP-FPM, Apache 2.4 auf Event-Basis und Hosting in unserer Cloud eine unschlagbare Performance erreicht, die von den Kunden, die dorthin gewechselt sind, kräftig gelobt wird.

Das wirft natürlich die Frage auf, was mit den bestehenden Premium-Paketen passiert und ob wir weiterhin Prepaid-Webhosting anbieten. Die Antworten sind einfach: an bestehenden Verträgen ändert sich nichts. Premium-Verträge laufen ganz normal weiter und können weiterhin geändert werden. An laufenden Verträgen ändert sich also nichts, außer Du als Kunde wirst aktiv und wechselst auf ein neues Paket. Zudem bieten wir weiterhin Prepaid-Hosting an. Bei den Webhosting-Paketen kann zwischen 12 Monaten und 1 Monat Laufzeit gewählt werden, beide Laufzeiten enthalten auch Inklusiv-Domains. Die Pakete für 1 Monat sind speziell für Prepaid-Hosting gedacht und können jederzeit gekündigt werden.

In den nächsten Tagen werden wir wieder den kostenlosen Testzeitraum für Webhosting-Pakete anbieten, damit man sich unverbindlich ein Bild von der neuen Produktpalette machen kann. Bevor dieser Blog-Post noch länger wird: ich beantworte gerne Fragen zu unserer Änderung hier in den Kommentaren oder per Support-Ticket (support@lima-city.de oder per Ticket-System).

Vielen Dank an Lennart für die Konzeption, die Geduld und Liebe zum Detail und alles, was zum neuen Corporate Design gehört, an Alex für das Coden der Templates, an Simon für das Abwickeln des Tagesgeschäfts während ich in die finale Relaunch-Phase abgetaucht bin, an alle Kunden die uns gut zugeredet und kritisiert haben, an alle Probe-Leser, Tester und Fragen-Steller, Testimonial-Schreiber und Open-Source-Coder. Ihr seid die Besten!