MSXFAQ Offline Apr/Mai 2020

Eigentlich kann ich mich über die Besucherzahlen und auch die Erreichbarkeit der MSXFAQ nicht beschweren. Seit der ersten HTML-Seite läuft die MSXFAQ auf einem "Shared Hosting" bei IONOS (vormals 1&1) und da ich weder SQL noch PHP und auch kein CMS nutzen, sondern die Seiten offline erstelle und verwalte und als statische HTML-Seiten per FTP übertrage, sollte die Belastung seitens IONOS auch im Rahmen bleiben. Allerdings dürfte die MSXFAQ sicher zu einer der aktiveren Webseiten sein.

  • IONOS Linux Hosting
    https://www.ionos.de/hosting/linux-hosting
    Mein Paket war damals noch das "1&1 Unlimited Plus " und dürfte wohl dem "Pro"-Paket im Jahr 2020 entsprechen.
    Das ist ein "Shared Hosting", d.h. meine Webseite teilt sich mit anderen Kunden den Server, hat 200 GB Disk, "unlimited Traffic" und ist für "Firmen und Vereine" geeignet. Weitere Details insbesondere zu Beschränkungen gibt es nicht.

Da ich meine MSXFAQ selbstintensiv nutze, ist mir recht schnell aufgefallen, dass unter https://www.msxfaq.de am 27. April 2020 auf einmal sprichwörtlich "gähnende Leere" herrschte und am 11. Mail ab 16:05 erneut.

Ich möchte mich für die beiden Ausfälle entschuldigen aber ich kann beim besten Willen keine Fehler bei mir feststellen. Das Verhalten von IONOS hat mich aber dazu bewogen, die MSXFAQ nicht nur auf einer anderen Plattform sondern auch seit dem 12.5.2020 bei einem anderen Hoster zu betreiben.

Diese Seite ist dennoch interessant für jeden Kunden des Shared Hosting von IONOS und vermutlich auch anderen Providern, die gerne mit "ganz viel Leistung" für "ganz wenig Geld" die Kunden anlocken aber die Fallstricke verschweigen.

Auslöser

Jeder Aufruf einer beliebigen URL lieferte einen Redirect auf 127.0.0.1. Am 27. April und am 11. Mai hat meine MSXFAQ folgendes Bild gezeigt:

Analog hat natürlich auch meine PRTG-Überwachung auf dem privaten Server zuhause sich gemeldet, der den Ausfall minutengenau protokolliert.

Am 27.4 ab 15:15 hat die Webseite keine Daten mehr geliefert.

Analyse

Also habe ich die klassische Fehlersuchkette durchlaufen:

  • DNS ist OK
    Mein Client hat per DNS die richtige IP-Adresse aufgelöst.

    Meine eigene Namensauflösung funktioniert.
  • WireShark Browser verbindet sich
    Per Netzwerkmitschnitt habe ich auch gesehen, dass mein Browser sich verbindet und sogar einen TLS-Handshake hinbekommt

    Bedingt durch die Verschlüsselung kann ich natürlich nicht reinschauen
  • Fiddler meldet HTTP-Redirect
    Da ich Fiddler eh immer griffbereit habe, sehe ich, wie der erste Zugriff noch zur MSXFAQ geht aber nicht mit Inhalt sondern einem HTTP 302 beantwortet wird:
  • Debugging Tools des Browsers
    Alternativ können Sie mit dem Browser eine vergleichbare Analyse erhalten

Es liegt also schon mal nicht an meinen Client sondern es muss irgendetwas auf dem Server sein. Solche Umleitungsseiten sind natürlich beliebte Funktionen einer "htaccess"-Datei auf der Webseite. Also habe ich auch da noch nachgeschaut. Ein Zugriff per SFTP war noch möglich. Also ist der Server an sich noch aktiv.

Es wurde allerdings nicht nur die MSXFAQ.DE abgeschaltet sondern gleich jede Webseite in dem Paket. Learning: Trenne Webseiten auch in getrennte Pakete und nicht nur als virtuelle Verzeichnisse mit eigener Domain.

Natürlich aktualisiere und ergänze ich kontinuierlich Inhalte der MSXFAQ aber ich bin schon sicher, dass ich nichts an der "htaccess."-Datei gemacht habe. Ein schneller Blick per FTP hat meine Einschätzung bestätigt, das die letzte Änderung schon einige Wochen zurück gelegen hat:

Da ich die MSXFAQ lokal verwalte und im Internet nur eine "Kopie" liegt, konnte ich einen schnellen Vergleich meiner lokalen Kopie im Staging-Bereich mit der öffentlichen Version mittels Syncback durchführen. Der Vergleich hat weder fehlende noch überzählige Dateien aufgeführt. Die MSXFAQ wurde demnach nicht verändert und ich sollte mal meinen Provider fragen.

Anruf IONOS 27.4 15:26 - 23 Min

Ich habe zum Ausfall keine Mail in meinem Postfach des Hosters gefunden und auch im Status-Portal habe ich keinen Ausfall oder eine Warnung gesehen. Der Anruf lief dann erfreulich schnell.

  • 15:26 Anruf bei IONOS
    Das gibt erfreulich schnell. Eine Warteschlange gab es quasi nicht und mein Ansprechpartner hat das Problem schnell bestätigen und sogar einen Eintrag zu meinem Hosting finden können. Rückfrage bei der "Technik" gestartet.
  • 15:40 Eine HTACCESS wurde seitens IONOS aktiviert.
    Die Rückfrage hat dann etwas gedauert und anscheinend haben sich die Techniker die Webseite und die Zugriffe genauer angeschaut. So konnte mit mein Supporter direkt sagen, dass es wohl sehr viele Zugriffe (>300.000) in kurzer Zeit auf die Webseite gegeben hat und daher INONOS als Schutzfunktion erst einmal die Zugriffe mit einem Redirect versehen hat.
    Nachdem wir gemeinsam festgestellt haben, dass die Webseite nichts böses im Schilde führt und es keinen Grund für so eine Datenmenge gibt.
  • 15:45 Back in Service
    Die Sperre wurde mittlerweile wieder entfernt und die MSXFAQ ist wieder erreichbar. Das ganze Telefonat hat ca 23 Minuten gedauert und die Nichterreichbarkeit der MSXFAQ lag bei ca. 30 Minuten.

Auf der Seite ein Lob an IONOS für die sehr gute Erreichbarkeit, die qualifizierte Hilfe der Person an der Hotline und dem Techniker im Hintergrund und schnelle Entstörung.

Allerdings sollte die Kommunikation dahingehend verbessert werden, da IONOS ja einen aktiven Eingriff vorgenommen hat. Ein Telefonanruf vorab wäre super gewesen und die angeblich versandte Störungs-Mail ist nicht angekommen.

Black Hole

Im Sprachgebrauch von IONOS wurde meine Webseite nicht abgeschaltet sondern als "Black Hole" konfiguriert. Es wurde also nicht per DNS oder Firewall der Zugriff der Clients verbogen, sondern nur die Auslieferung der Daten durch den Webserver unterbunden. Die Clients haben sich weiterhin mit dem Webserver verbinden und sogar den TLS-Handshake aufbauen können.

Nur danach hat der Webserver dann nicht die Daten auf dem Storage gelesen und ausgeliefert sondern die 302 Umleitung.

Ich frage natürlich, was der Hintergedanke eine 302 Umleitung auf "Localhost" zu machen. Das Verfahren habe ich so noch nicht gesehen und ich wüsste nicht, wie automatische Prozesse, z.B. Suchmaschinen darauf reagieren.

Es gibt wie bei SMTP auch bei HTTP bekannte Fehlercodes, die Probleme des Servers mitteilen. Sie sind per Wikipedia ganz einfach zu finden. Ich finde hier vier ErrorCodes, die viel deutliche die Fehlersituation beschreiben.


Auszug aus https://de.wikipedia.org/wiki/HTTP-Statuscode#5xx_%E2%80%93_Server-Fehler

Bis heute hat niemand bei IONOS mit erklären können, auf welcher Idee die "302 Umleitung" basiert, die eine so abweichende Nutzung sinnvoll erscheinen lässt. Ich hätte eher die Sorge, dass Google und Co eine solche Seite als "schlecht" ansehen, weil man den Crawler ja damit in die Irre leitet. Das ist einem MX-Record auf 127.0.0.1 sehr ähnlich, mit dem einige Mailserver mit einer Loop lahmgelegt werden konnten.

Ich musste also besser verstehen, was IONOS dazu bringt, eine Webseite derart außer Betrieb zu nehmen

Post Ausfall Analyse

Laut IONOS wurde serverseitig per HTACCESS meine MSXFAQ abgeschaltet, weil es sehr viele Zugriffe gegeben hätte und ein Missbrauch vermutet wurde. Ich finde es ja gut, wenn ein Hoster seine Systeme überwacht und plötzliche Anstiege überwacht und sogar aktiv gegensteuert. Es wird sogar mit einem DoS-Schutz für das Webhosting Paket geworben. Aber darunter verstehe ich nicht die Webseite offline zu schalten. Ich bin daher von einer mehr oder weniger einfachen DoS-Attacke ausgegangen, die sich in den Logfiles anzeigen lässt. IONOS bereitet eine einfache Statistik sogar direkt in dem Webspeicher áuf. Hier ist aber im Nachhinein gut zu sehen, dass der 27.4 zwar schon viele Zugriffe hat aber nicht extrem aus der Reihe tanzt

Ich habe mit dennoch das Apache-Log des Tages gezogen und genauer angeschaut

Eine Dateigröße von 96 Megabyte für den ersten Tag der 18. Kalenderwoche und über 408.341 Zeilen in der Datei sind schon nicht zu unterschätzen. Ich habe das Log in Power Bi geöffnet und nach IP-Adressen und URLs ausgewertet. Die 408341 Requests haben sich auf 8671 IP-Adressen verteilt.

Vorneweg: Ich habe nicht viel gefunden und weiter unten beschreibe ich, warum ich diesen Schritt zukünftig nicht als erste Aktion gehen sollte. Aber ich möchte meine Ergebnisse dennoch kurz vorstellen.

Einige IP-Adressen sind aufgefallen und zeigen schön, die man mit PowerBI auch solche Logs ganz gut "durchsuchen" kann.

  • 91.133.70.0
    Diese Adresse ist der "Top Caller" des Tages mit 4207 Anforderungen. Aber ein Blick in die Daten zeigt nur, dass er einige Bilder eben 115 mal geladen hat und weiter unten (nicht sichtbar) eben ca. 115 HTM-Seiten betrachtet hat. Die Adresse ist aus RIPE (https://apps.db.ripe.net/db-web-ui/query?searchtext=91.133.70.0) einem Hotel St. Hubertushof in Salzburg zugewiesen. Hier sehe ich keine böse Absicht
  • 165.225.72.0
    Diese Adresse hat 2815 Requests abgesetzt. Die MSXFAQ hat mehr Dateien und wenn jemand die MSXFAQ komplett kopiert hätte, wäre es OK. Aber dieser eine User hat ganz schön oft gewisse Bilder geladen, die eigentlich im Cache liegen sollten. Die Adresse gehört aber zu ZScaler (https://whois.arin.net/rest/net/NET-165-225-72-0-1/pft?s=165.225.72.0) Mehrere Firmen können sich hinter so einer Adresse verbergen, so dass ich hier auch erst einmal nicht weiter suchen muss.
  • 52.149.180.0
    Bei der Suche nach URLs und 404 Fehler findet man natürlich auch den ein oder anderen Beifang. Diese IP-Adresse gehört vermutlich hu einer AzureVM bei Microsoft (https://whois.arin.net/rest/net/NET-52-145-0-0-1/pft?s=52.149.180.0) und hat wohl verschiedene Dateien einer WordPress/Windows Live Writer-Installation geprüft. Sie wurden aber alle mit einem 404 beantwortet, so dass hier auch nicht passiert ist.

    Das waren aber auch nur 14 und zudem erfolglose Anfragen. Meldung an Microsoft Abuse ist dennoch raus gegangen.

Dennoch habe ich hier dann mal abgebrochen, denn einen Glücktreffer habe ich nicht gemacht.

Google Analytics

Wenn ein normaler Anwender die MSXFAQ aufruft, dann bezieht er auch die ein oder andere Information über Google Analytics. Das gilt aber nicht immer für Angreifer, die keinen Browser mit JavaScript sondern eher CURL u..a nutzen und keine Links nachladen. Dennoch ist ein Blick in die Analytics Konsole schnell möglich. Auch hier ist in der Wochenansicht zumindest kein extremer Anstieg zu sehen.

Auch in der Ansicht des Tages ist der Einbruch zwischen 14:00-15:00 Uhr zu sehen aber nur eine geringfügige höhere Last gegen 13:00 Uhr.

Ich habe mir dann die Apache Logfiles der vorigen Woche angeschaut, die mir als GZIP-Datei vorliegen. Über die komplette Woche sind da 2.618.138 Zugriff (Dateien aber auch Bilder, CSS etc.) zu sehen. Das Apache-Log der Woche ist 693 Megabyte groß. Dagegen ist das Logfile vom 27. April mit 152 MB zwar groß aber immer noch im Rahmen. Es ist ja nur ein Tag der fünf aktiven Werktage mit den meisten Zugriffen auf die MSXFAQ. Insofern sehe ich gar nicht mal so viel mehr Requests, als nicht auch zu üblichen Tagen vorhanden sind.

PRTG Monitoring

Viel aussagekräftiger war aus meiner Sicht aber die Überwachung von PRTG, mit der ich die Homepage der MSXFAQ jede Minute abrufe und die Zeit dafür messe.

Hier ist nicht nur der Ausfall zu sehen, sondern auch die längere Abrufzeit ca. 1 Stunde davor. Da gab es wohl schon ein paar Performanceengpässe auf der Leitung oder dem Server. Aber eine langsame Abrufzeit muss nicht mit meiner MSXFAQ verbunden sein. Als "Shared Hosting" könnte ja auch eine andere Webseite auf dem gleichen Server unter Last gestanden haben und meine Seite mit betreffen. Denn solche Peaks gab es auch schon vorher immer mal wieder.

Eine langsame Antwortzeit ist aber keine Aussage zu den Anzahl der Requests.

Dieses Beispiel zeigt mit wieder, wie wichtig ein eigenes Monitoring von Diensten aus dem Internet ist. Ich habe für diese Funktion auf einem PC zuhause einfach die 100 Sensor Free-Version von PRTG installiert, die nebenbei noch meine IoT-Geräte überwacht.

Excel und LTFViewer

Ich habe daher noch mal einen "Large Text File Viewer" genommen, um am nächsten Tag das Logfile des 27.4 gesamt zu betrachten. Ich habe mir die Zeilennummer für jede angefangene Stunde geholt und die Anzahl der Zeilen pro Stunde ermittelt:

Diese Zahlen bestätigen aber meinen Verdacht, dass es gar keine höhere Last auf der MSXFAQ gegeben hat. Ich finde hier aber keinen großen "Zugriff" oder gar eine extreme Steigerung von Abrufen. Vielmehr zeigt das Bild den Einbruch der reinen Zugriffe bis 15:00 an.

Lernkurve

Jeden Vorfall sollte man nutzen, um daraus zu lernen und besser zu werden. Es gibt mehrere Punkte, die ich für mich aber auch bei IONOS noch verfolgen möchte:

  • Eigenes Monitoring kennen
    Die MSXFAQ läuft viele Jahre problemlos. ich muss zugegeben, dass ich gar nicht drauf gekommen bin, zuerst mal bei meiner eigenen PRTG-Installation nachzuschauen. Das werde ich in Zukunft früher machen und auch einen Alarm an den Sensor hängen, dass ich informiert werde. Leider können Sie bei einem Shared Hosting keine Performance Daten des Webserver per SSH, SNMP o.ä. abrufen. IONOS stelle solche Zahlen aber nicht bereit, so dass sie nur selbst von draußen eingeschränkt überwachen können.
  • Meldung von IONOS
    Wenn mein Hoster meine Webseite "außer Betrieb" nimmt, dann sollte ich das wissen. Angeblich hat man mir eine Mail gesendet aber ich habe sie weder im Spamorder noch im Postfach gefunden. Das Postfach liegt wohlgemerkt auch bei IONOS. Es ist also eine "interne Mail" und die sollte doch zuverlässig zugestellt werden.
  • Besser DoS Schutz
    In diesem Fall gehe ich davon aus, dass gar kein DoS stattgefunden hat. Aber wenn das doch mal passiert, dann finde ich eine Umleitung von Zugriffen auf http://127.0.0.1 schon etwas suspekt. Da hätte man als Provider auch eine Informationsseite schalten können. Ich bin sicher, das der ein oder andere Besucher schon irritiert gewesen ist.

Ich bin mal gespannt, ob ich im Nachgang noch ein paar Informationen dazu einsammeln kann. Firmen, die aber von Webseiten und deren Erreichbarkeit abhängen, sollten nicht nur passiv überwachen sondern vielleicht sogar Logdateien aktiv auswerten um z.B.: Angriffsmuster zu erkennen. Auf der MSXFAQ kann ich recht einfach eine "Liste der gültigen Dateien" erstellen, da bei mir alle statisch ist. Diese URLs können dann mit dem Webserver-Log abgeglichen werden, um die Angreifer besser zu verstehen. Vor allem sollte kein 20 OK für eine Datei kommen, die nicht von mir ist. Das ist aber eine Aufgabe für den nächsten Winter.

29. Apr bis 6. Mai 2020 -Ursachenforschung

Der Ausfall am 27.4 war nur sehr kurz aber dennoch muss ich natürlich wissen, warum die Webseite offline geschaltet wurde. Daher habe ich am 29. April noch mal den Kontakt gesucht um das Problem aufzuarbeiten. Ich vermute, dass die MSXFAQ gewisse Grenzwerte überschritten hat, die aber nicht öffentlich kommuniziert werden. Weiter oben habe ich die "Black Hole"-Funktion ja schon beschrieben und bewertet.

IONOS hat sich dann bis zum 6. Mail Zeit gelassen, um den Vorfall zu untersuchen. Ein ausführliches Telefonat mit einem Techniker am späten Abends hat weitere Erkenntnisse gebracht, die ich hier zusammenfasse.

  • Störungsmail
    Beim ersten Kontakt hat mein Ansprechpartner mir noch gesagt, dass ich eine Mail bekommen haben müsste. Sie ist aber bis zum Schluss nicht gekommen. Heute weiß ich, dass die Technik in dem Fall die Mail an den "Persönlichen 1&1 IONOS Berater" sendet, der diese dann bearbeiten und den Kunden informieren sollte. Damit ist natürlich eine Verzögerung eingebaut, die ich nicht abgewartet habe. Dennoch gibt es aktuell wohl keine aktive Benachrichtigung eines Kunden bei einer providerseitigen Abschaltung einer Webseite.

Ich würde als Provider diesen Prozess überdenken. Im Kundenportal sind Mailadressen und Mobilfunknummern hinterlegt. Eine Mail oder SMS sollte die Mindestmeldung in so einem schwerwiegenden Fall darstellen.

  • CPU-Last zu hoch (46%)
    In einem Gespräch wurde mir gesagt, dass die MSXFAQ für 46% aller Zugriffe auf den Host verantwortlich. So etwas macht natürlich bei einem "Shared Hosting" Probleme. Die Provider arbeiten ja damit, dass viele (bezahlte) Webseiten auf wenigen Hosts abgelegt werden. Allerdings zeigen meiner Auswertungen, dass dies eine überraschend oder plötzliche Laststeigerung ist, sondern schon Monate lang die Anrufzahlen und entsprechend die Last auf gleichem Niveau waren. Entweder hat IONOS nur die Grenzwerte verändert oder man interessiert sich nicht für die Kunden. Als Vertriebler hätte ich schon lange den Kunden angerufen und ein "Upgrade" angeboten.
    Beim Shared Hosting kann ich aber die CPU-Last meines Wissens gar nicht einsehen und da auch die Grenzwerte nicht publiziert sind, kann ich nicht die drohende Gefahr erkennen. Auf der anderen Seite finde ich es schon fraglich, wenn ein Server durch statische Seiten mit ca. 2MBit Bandbreite so belastet ist. Wie soll er dann eine Word-Press-Installation verkraften, die laut Produktwerbung (100%) geeignet ist?
  • Zu viele Prozesse (20)
    Eine weitere Mail sagt nur kurz, dass mein Vertrag maximal 20 Prozesse erlaubt und beim Überschreiten die Webseite geblockt wird. Wenn ich die Apache-Logs auswerte, dann komme ich schon auf solche Werte. Allerdings würde ich dann den 21 Request warten lassen, bis einer der 20 aktiven Worker fertig ist. Die MSXFAQ würde dann natürlich langsamer sein aber das könnte man ja messen.
    Stattdessen nimmt IONOS aber die TCP-Verbindung an, macht noch den SSL-Handshake und sendet dann den Redirect auf localhost. Ich habe umfangreich gesucht und habe aber in keiner Beschreibung dieses Limit von 20 Prozessen gefunden. Das Marketing scheint dies nicht als wichtig zu erachten.
    Viel schlimmer finde ich damit aber das Potential eines einfachen DoS. Ich müsste nur 20 Dateien gleichzeitig mit ganz wenig Bandbreite herunterladen, um eine Webseite "offline" zu schalten.
    So ganz glaube ich nicht, dass diese Grenze ein Trigger für Black-Hole" sein soll. Aber letztlich müsste IONOS hier etwas beschreiben.
  • Black Hole State abschalten geht nur manuell
    Es gibt keinen "Sebstheilungseffekt" oder einen "automatischen Neustart". Wenn eine Webseite durch einen Angriff einmal in den "Black Hole"-Status versetzt wird, dann muss der Kunde sich melden um wieder befreit zu werden. Das Spiel kann ein Angreifer immer wieder wiederholen. Solange IONOS keine Informationen zum Trigger an die betroffenen Kunden sendet, ist das kein zufriedenstellender Umstand.
  • Kein DoS-Schutz
    In dem Zuge frage ich mich schon, was IONOS dann unter dem "DDoS-Schutz" versteht. Sollte nicht genau so eine Maßnahme eine "Überlastung" einer Webseite verhindern und idealerweise auch den Betreiber informieren. Schade, dass der Eintrag keinen Weiterführenden Link hat.

    Auszug Quelle: https://www.ionos.de/hosting/linux-hosting (12. Mai 2020)

Ich muss also etwas an der Plattform der MSXFAQ machen und dazu muss ich auch wissen, woran es liegt und welche Grenzwerte bei anderen Verträgen und Plattformen bestehen.

Verschiedene Ansprechpartner, die ich nicht namentlich nennen will, haben mir aber mögliche Gründe genannt, warum es die MSXFAQ plötzlich erwischt hat. Die historischen Daten zeigen ja, dass die MSXFAQ monatelang ohne Störung gelaufen ist. Folgende Gründe könnten ursächlich sein:

  • Alter Server/Neue Server
    Auch die Hardware im Shared Hosting wird nach einigen Jahren mal getauscht. Vielleicht wurde einfach ein neuerer und schnellerer Server als neues Ziel für viele Verträge ausgesucht und so die Zusammenstellung der Verträge pro Server verändert. Wenn man mehr Kunden auf schnelleren aber weniger Servern verteilt, dann spart ein Hoster Strom, Abwärme und Rackspace. So könnte es dann passiert sein, dass die MSXFAQ erst aufgefallen ist. Wobei mein Langzeitmonitoring nicht darauf hinweist, dass etwas grundlegend verändert wurde. Das muss aber nichts heissen.
  • Besseres Monitoring/Neue Policy
    Wahrscheinlicher finde ich den Fall, dass das Monitoring der System angepasst und automatisiert wurde. Ich denke nicht, dass ein Admin regelmäßig die Last von Webseiten anschaut, um dann ein "Black Hole" zu konfigurieren. Das macht ein Automatismus, der zyklisch läuft und dann eben den Hahn sprichwörtlich zudreht und eine Info-Mail an den Berater sendet.

Wir werden den "Root Cause" vermutlich nicht erfahren, wenn es keine Whistleblower bei IONOS gibt. Ein ungutes Gefühl bleibt mir erhalten. Ich nehme hier schon mal vorweg, dass die MSXFAQ.DE umgezogen ist.

Datenblatt Webhosting Pro

Zur Sicherheit habe ich mir auch einmal die Leistungsbeschreibungen des Vertrags angeschaut, wie er auf der aktuellen Seite von IONOS zu sehen ist. Vielleicht habe ich ja eine andere Kennzahl übersehen, die zum "Black Hole" führt. Aus der Produktübersicht zu Shared Hosting (https://www.ionos.de/hosting/webhosting) geht leider nicht hervor, wie viele Requests ein Server maximal bedienen kann. Die Marketing-Seiten stellen ja gerne die positiven Aspekte heraus. Für den meinem Vertrag vergleichbaren PRO-Paket listet INONOS auf

  • Webspace: 250 GB
    Da bleibe ich locker drunter und auch die anderen Eckwerte für SQL-Datenbanken (nicht relevant) etc. sehe ich alle als nicht relevant an.
  • Traffic "Unlimited"
    Da ist kein Fußnotensternchen o.ä. und dann würde ich das als "Unbeschränkt" übersetzen. Natürlich gibt es immer Grenzen wie eben auch beim Mobilfunk irgendwann "gedrosselt" wird oder Firmen eine "Fair use"-Policy in die Fußnote schreiben. Es gibt aber auch echte Flat-Rates bei Telefonie oder DSL-Anschlüssen und der Anbieter könnte ja unbeliebte Kunden mit entsprechenden Fristen kündigen. So ist das ein "unlimited"
  • "Performance Level 2"
    Es ist echt schwer hier schnell qualifizierte Aussagen zu machen. Später dazu mehr.
  • RAM, bis zu 6GB (3 GB garantiert)
    Da würden alle statischen Dateien schon in den Cache reinpassen. PHP-Skripte nutze ich ja nicht und der PHP-Speicher wird sogar extra ausgezeichnet. So sollte ein Apache den Speicher locker als Cache nutzen können um Disk-IOs zu sparen
  • Anwendungen: Wordpress/Joomla: 100%
    Mit farbigen Donuts gibt IONOS die Eignung für Wordpress und andere Apps an. Die beiden CMS-Systeme Wordpress und Joomla werden mit 100% angegeben. Drupal mit 75%, Typo3 mit 50% und überall das Adjektiv "Performance". Kann man das missverstehen?.

Eine Aussage zu Requests/Sek finde ich auf der ganzen Seite aber nicht und in den AGBs geht IONOS gesondert auf die Speichermenge ein:


Quelle: IONOS AGBs https://www.ionos.de/terms-gtc/terms/

Performance, Entry Processes und NPROC

Wenn es aber nicht an der Bandbreite, der Datenmenge oder dem Speicherplatz liegt, dann kann es noch etwas mit der CPU-Last, Prozessen etc. zu tun haben. Es gibt aber noch andere Kriterien und eine hohe CPU-Last oder viele Request haben mich bei anderen Providern auf die Begriffe "Entry processes" und "NPROC" aufmerksam gemacht. Dazu findet man dann auch in den Tiefen der Online-Hilfe Hinweise auf damals gültige Verträge.


https://www.ionos.de/hilfe/hosting/problemloesungen-fuer-php/uebersicht-der-php-skript-limits-aelterer-webhosting-pakete-tarife-bis-22032017/

Leider ist mein Vertrag von 2000 und der Name passt in der Liste nicht zum Eintrag. Ich gehe daher mal von 16 NPROCs aus. Doch was sagt das aus? Ich interpretiere das wie folgt:

Jede Anfrage eines Clients startet eine Verbindung, die der Webserver bedient. Wenn die Daten übertragen wurden, wird die Verbindung wieder beendet und der Prozess kann einen anderen Benutzer bedienen. Ein Limit von "16" bedeutet also, das 16 gleichzeitige Verbindungen bedient werden können. Das sind nicht 16 Benutzer, denn auf der einen Seite kann ein Benutzer ja mehrere (in der Regel bis zu 4) Connections öffnen, um parallel die HTML-Datei, CSS und Images zu laden. Auf der anderen Seite ist der Anwender nach einer Sekunden auch fertig und liest erst mal. In der Zeit können andere Anwender wieder Informationen laden.

Der Wechsel auf einen größeren damaligen Tarif wird aber nicht mehr angeboten. Ich müsste also auf ein aktuelles Angebot wechseln, bei dem aber einige Funktionen entfallen, z.B. sind Postfächer dann nur 2 GB statt 50 GB groß.

Next Level Performance

Für diese neuen Verträge gibt es aber auch eine andere Einstufung für die Performance. IONOS interlegt zu jedem Vertrag einen "Performance Level".

Der meinem Vertrag ähnliche "Pro"-Vertrag hat als Grundausstattung schon "Performance Level 2" und für 1,99€/Monat pro Level kann bis zu Level 5 aufgewertet werden. Erst per Telefon mit einem Techniker habe ich dann aber die Prozesse erfahren. Die werden aber nicht pro Sekunde (NPROC) sondern pro Minute berechnet.

P1 = 300/Min
P2 = 600/Min
P3 = 900/Min
P4 = 1200/Min
P5 = 1500/Min

Die Berechnung pro Minute ist vorteilhaft, weil Mittelwerte nicht pro Sekunde anstehen. Aber die Zahlen haben so noch keine Aussagekraft. Es hängt von dem Aufbau der Seite und den Clients ab, wie viele Verbindungen pro Zeiteinheit neu aufgebaut werden können. Interessanterweise habe ich auf einer anderen Seite eine altes Marketingbild gesehen, bei dem zu den alten Termine ebenfalls die fünf Levels zugeordnet wurde.


Quelle https://www.cloudcomputing-insider.de/websites-mit-flexibler-performance-a-594519/

Hier werden zu den Level auch erstmals einmal "Visits" zugeordnet. IONOS geht also von 1:4 aus, wobei Visits dann wohl "abgerufene komplette Seiten"

Zwischenstand

Wenn Sie bis hier mitgelesen haben, dann kennen Sie nun alle Einschränkungen eines "Shared Hostings". Lassen sie sich nicht durch die Marketingfolien mit "unlimited Traffic", vielen Gigabyte RAM und frei erfundenen "Performance-Klassen" von IONOS und vermutlich vieler anderer vergleichbarer Angebote täuschen. Diese Angebote eignen sich für kleine Webseiten mit wenig Verkehr, die das Rentabilitätsmodell der Provider nicht zu stark strapazieren. Wenn ein Provider mehrere tausend Kunden für 5-10€/Monat auf einem Server im Shared Hosting betreibt, kann davon ganz gut leben. Insbesondere, wenn die Prozesse für Provisioning und Abrechnung aufgesetzt sind.

Für eine Webseite wie die MSXFAQ ist nun der Zeitpunkt gekommen, eine neue Heimstätte zu finden. Da ich mich nicht mit dem Betrieb von Hardware, Netzwerkverbindungen, Betriebssystemen, Webservern, Zertifikaten, Backup und Restore abgeben möchte und keinen "Root Access" braucht, wäre ein "Managed Server" interessant, den mehrere Provider anbieten.

ich habe ja schon am 6. Mai bei der Aufarbeitung des Ausfalls auch diesbezüglich gefragt, ob der Weg sinnvoll wäre. Leider wurde darauf nicht eingegangen und selbst bei expliziter Nachfrage nach derm Dimensionierung blieben zu viele Fragen offen.

11. Mai 2020 16:07 Schon wieder offline!

Ich wollte schon nachfragen, als der nächste Ausfall meine Aufmerksamkeit forderte. Am 11. Mai 2020 16:07 war die MSXFAQ wieder offline. Zum Glück habe ich das gegen 16:15 gemerkt, da ich eine neu hochgeladene HTML-Seite prüfen und dann in Twitter verlinken wollte. Auch hier konnte ich per SFTP weiterhin Dateien hochladen und auch die Apache-Logs runterladen. Die Browser bekamen aber wieder einen 302 Redirect.

auch habe also wieder direkt per Telefon anrufen und nach kurzer Wartezeit hatte ich auch eine freundliche Dame am Ohr, die mein Problem durchaus verstanden hat. Leider konnte sie aber niemand im technischen Betrieb erreichen und hat mein Ticket eskaliert. Auch die Mail zu dem Vorfall wurde erstellt. Allerdings geht die wohl nicht direkt an mich, sondern an meinen persönlichen Ansprechpartner, der diese dann bearbeiten muss.

Ich habe natürlich nicht locker gelassen, denn so kann es nicht weiter gehen und habe nach 20 Uhr noch mal angerufen und mein Leid erneut geschildert. Angeblich wurde dann ein Techniker beauftragt, zum Server hinzugehen, um die Details zu klären. hat IONOS keine Fernwartungsboards und bei Unix-Systemen es es doch eh egal, ob man aus der Ferne sich anmeldet oder vor der Konsole steht. Gegen 21:39 bekam ich dann einen hilfreichen Rückruf eines Technikers, mit dem ich 40 Minuten lang die Zusammenhänge analysiert habe. Viele Erkenntnisse dieses Telefonats habe ich auf dieser Seite unter der Analyse beschrieben. Er konnte aber die Blockade selbst nicht beheben, da er im Server-Bereich tätig ist und wohl beim Shared Hosting nichts machen kann.

E gab mir aber den Tipp, dass meine Webseite auf einem "Webhosting Infong" liegt und es bei IONOS auch Systeme der Klasse "Perfomance Infong" gäbe. Vielleicht könnte meine Webseite am Morgen durch einen Kollegen verschoben werden, bis die Webseite ein ganz neues Ziel gefunden hat. Damit bin ich ohne funktionierende MSXFAQ erst mal Schlafen gegangen. Davor habe ich natürlich noch eine Zusammenfassung des Abends an das Support-Ticket angehängt.

12. Mai 2020

Da auch um 8:30 immer noch nicht passiert ist habe ich mich wieder gemeldet. um es kurz zu machen. Die folgenden Telefonate waren überhaupt nicht konstruktiv.

  • 9:38 Rückfrage nach dem Status. Die Angelegenheit wird an das "Server-Team" weiter gegeben, die aber bis 12:00 in einem Meeting sind
    Ich habe in der Zwischenzeit verschiedene Hoster angesprochen, um mit einem Marktüberblick der Angebote zu beschaffen.
  • 14:15 Das sich bislang niemand bei mir gemeldet hat, habe ich wieder mal angerufen. Der Kollege hat den Case betrachtet und meinst, dass er ja schon weiter gegeben ist und sich noch keiner drum gekümmert hat. Ionos hätte 8 Mio Kunden und da müsste man sich etwas gedulden. Ich habe dann um die Grundlagen der Abschaltung geben und wurde auf die AGBs verwiesen. Er könne grundsätzlich keine Auskünfte zu rechtlichen Dinge geben und hat auch eine Vermittlung zur Rechtsabteilung oder seinem Vorgesetzten abgelehnt. Ich habe ihm dann angekündigt, dass ich das Gespräch ab jetzt aufnehmen wolle und er seine Aussagen wiederholen möge, worauf der nicht mit der Aufzeichnung einverstanden war und kommentarlos aufgelegt hat.
  • 14:20 So einfach kann sich ein Lieferant natürlich nicht aus der Affäre ziehen. Allerdings macht es IONOS sehr schwer einen anderen Kontakt als das Kundencenter zu erreichen. Also habe ich erneut angerufen aber diesmal direkt um die Eskalation, Zusendung der Rechtsgrundlagen für die Abschaltung und Zusendung der Telefonaufzeichnungen gebeten. Der Mitarbeiter hat wohl meine Verärgerung gemerkt und eine Rückfrage (15Min) eingeleitet.
    Leider könne er mich aus dem Homeoffice nicht weiterleiten und ich möge meine Beschwerde bitte per Mail support@ionos.de senden. Die Mail wurde mit einem "Autoresponder" beantwortet, dass es bis zu 24h dauern könnte.

Ich hatte mir und IONOS bis 18:00 eine Deadline gesetzt. Der Totalausfall dauerte mittlerweile schon viel zu lange.

Es ist mir unverständlich, wie ein Hoster hier sich einfach tot stellt. Es ist ja kein Hardware-Ausfall mit fehlenden Ersatzteilen sondern eine absichtlich herbeigeführte Blockade einer bezahlten Dienstleistung. Die MSXFAQ sollte ja wieder online gehen und anscheinend liegen die Prioritäten von IONOS in diesem Fall an anderer Stelle.

MSXFAQ zieht um

Schon während des 12. Mai habe ich per Telefon, Mail, Chat verschiedene Hoster angesprochen und ganz klar meine Kennzahlen genannt, so ich es konnte. Es war schon interessant, dass selbst die Vertriebswarteschleife bei einem Hoster nach 30 Minuten nicht bedient wurde und auch andere Hoster sich nicht mit Ruhm bekleckert haben. Auch über den Erfolg mit einem "Chat-Bot" zu einem Ergebnis zu kommen erscheint mir gewagt. Da haben einige Geschäftsführer wohl einen schlechten Tag gehabt. Einige der Hoster haben sich meine Anforderungen angehört aber konnten kein Produkt sicher anbieten. Wenn ich von einem Shared Hosting für 10€/Monat komme, dann werde ich misstrauisch, wenn ein Anbieter sage, dass man dazu eine Serverfarm braucht oder ein andere mit einen RootServer für 200€ nennt. Natürlich gab es auch gut gemeinte Hinweise per Twitter und Mail, die ich zum Teil verfolgt habe.

Letztlich musste ich aber eine Entscheidung treffen und ich habe einen alten bestehenden Vertrag bei einem Provider reaktiviert, hochgestuft und den Umzug der MSXFAQ nach 22 Jahren bei 1&1/IONOS zu HostEurope eingeleitet. Das gibt sehr schnell, da ich ja schon "bekannt" war und der Vertrieb und die Technik meine Fragen direkt beantworten konnten. Es wird am Anfang noch etwas rucken, da DNS-Einträge nun mal etwas brauchen und auch der Managed Webserver bekommt noch ein Update und SSL-Zertifikat.

Meinen Vertrag bei IONOS lasse ich für die "Familien-Domäne" weiter bestehen, denn die Anpassung der IMAP/POP-Einstellungen für alle Postfächer muss ich vielleicht später einmal angehen und das Shared Hosting für 10€ ist ja durchaus geeignet für kleine Familienseiten, bei denen eine einseitige Abschaltung nicht mal bemerkt wird.

Ich hotte, dass diese Beschreibung für ein oder anderen Webadministrator ein Weckruf ist, sich mit den nicht dokumentierten Beschränkungen auseinanderzusetzen, immer einen zweiten Hoster im Hintergrund zu haben, die Erreichbarkeit der Webseite durch ein unabhängiges Monitoring zu überwachen und den Hoster auf den Zahn zu fühlen. Ich bin sicher, dass IONOS nicht der einzige Hoster mit negativ-Bewertungen ist. Machen Sie sich ihr eigenes Bild.

Beifang ".bash_history"

Nachdem alle Dienste umgezogen waren, habe ich bei IONOS per SFTP noch mal die alten Daten der MSXFAQ aber auch der anderen Webseiten betrachtet. Dabei ist mir eine Datei aufgefallen, die ich selbst sicher nicht angelegt habe.

Diese Textdatei enthält wohl alle per "Bash" ausgelösten Aktionen und ist vom 6. Mai 2020. Das passt in etwa mit dem Gespräch am 6 Mai 2020.

export LS_OPTIONS='--color=auto'
eval "`dircolors`"
alias ll='ls $LS_OPTIONS -lha'
ll
for file in ~p57652/logs/access.log.??.?.gz; do echo $file : `zcat $file | wc -l` hits; done
cd logs
cd ..
cd logs
cat access.log.current | wc -l` hits; done
cat access.log.current | wc -l
cat ./access.log.current | awk '{freq[$1]++} END {for (x in freq) {print freq[x], x}}' | sort -rn | head -20
cat ./access.log.current | awk '{freq[$7]++} END {for (x in freq) {print freq[x], x}}' | sort -rn | head -20
cd ..
cd ..
less .htaccess
exit

Ein paar manuelle Befehle, um die aktuelle Zugriffsdateien auszuwerten und zuletzt die aktuellen Zugriffe zu verfolgen.

Abschluss

Der Umzug war natürlich nicht lange vorgeplant, so das selbst die erfolgreiche Bereitstellung noch nicht bedeutet hat, dass Sie als Anwender auch die Inhalte gesehen haben. Lokale DNS-Caches, Proxy-Server u.a. verzögern die Lösung solcher Probleme. Die PRTG Überwachung zeigt ein klares Bild:

Der Ausfall begannt am 11.5.202 gegen 16:00 und von meinem System war die MSXFAQ erst wieder am 13.5.2020 vormittags erreichbar. In der Zwischenzeit gab es nicht mal einen erfolgreichen Abruf, d.h. IONOS hat zu keiner Zeit die Sperre aufgehoben. Auf die unterschiedliche Response-Zeit gehe ich am Ende der Seite Umzug IONOS -> HostEurope weiter ein.

Weitere Links