SKANDAL-REPORT: Die Sperrung von cap4free.de – technisches Versagen oder überzogene Schutzmaßnahmen bei DomainFactory?

Ein Investigativbericht von Mevludin Useinoski

Einleitung

Es ist der digitale Super-GAU für jeden Webmaster: Ein technisch einwandfrei gepflegtes Community-Projekt wird über Nacht zum Sündenbock eines Hosters. Der Fall cap4free.de offenbart die tiefen Schattenseiten des modernen Webhostings. Es ist eine alarmierende Geschichte über aggressive Bots, intransparente Traffic-Zahlen und einen Kundenservice, der erst blockt und dann zur Kasse bittet. Was hier passiert ist, gleicht einer digitalen Geiselnahme eines sozialen Projekts, das auf Barrierefreiheit und gesellschaftliche Teilhabe ausgerichtet ist.

Wenn automatisierte Algorithmen die Kontrolle über den Serverbetrieb übernehmen, geraten Individualprojekte und gemeinnützige Plattformen schnell in die Räder der industriellen Massenabfertigung. Dieser Bericht dokumentiert nicht nur einen akuten Einzelfall, sondern analysiert die fundamentalen strukturellen Probleme der Shared-Hosting-Branche, in der die Verantwortung für die Abwehr globaler Cyber-Gefahren zunehmend auf den Endnutzer abgewälzt wird. Ziel dieses Berichts ist die lückenlose Offenlegung der Ereignisse sowie eine tiefgehende technische und strukturelle Analyse der angewandten Hosting-Praktiken im Stil professioneller Berichte. Es geht um die fundamentale Frage, ob ein Webhoster seine Kunden als Schutzschild missbrauchen darf, um eigene infrastrukturelle Defizite zu kaschieren, und wo die Grenzen der Zumutbarkeit bei der Sperrung kritischer digitaler Infrastrukturen liegen.

Recherche und Community-Lage

Allgemeine Nutzererfahrungen

Die unangekündigte Sperrung von Webseiten und die darauffolgende Konfrontation mit automatisierten Textbausteinen ist in der Hosting-Branche kein unbekanntes Phänomen. Ein systematischer Blick auf die gängigen Bewertungsportale, Verbraucherschutzforen und unabhängigen IT-Erfahrungsberichte zeigt ein klares Bild über die Entwicklung im Massen-Hosting-Sektor. Während die Stabilität der reinen Hardware-Infrastruktur in den letzten Jahren durch moderne Rechenzentren gestiegen ist, bemängeln Kunden branchenweit immer häufiger die quality des technischen Supports. Nach Übernahmen von Traditionsmarken durch internationale Hosting-Konzerne beklagen langjährige Nutzer oft eine zunehmende Standardisierung der Hilfeleistungen bei DomainFactory. Technische Anfragen werden vermehrt durch Callcenter-Strukturen oder vorgefertigte Makros abgearbeitet, was eine individuelle Problemlösung bei komplexen Serverlasten erheblich erschwert.

Kunden berichten in ihren Rezensionen wiederholt davon, dass bei Auslastungsspitzen reflexartig gesperrt wird, statt gemeinsam mit dem Webmaster nach der Ursache zu suchen. Besonders auffällig ist hierbei die Transformation des Supports von einer technischen Hiltestellung hin zu einer Vertriebsstruktur. Anstatt detaillierte Fehleranalysen bereitzustellen, erhalten betroffene Administratoren oft standardisierte Schreiben von DomainFactory, die den Wechsel in teurere Tarife oder den Kauf von zusätzlichen Sicherheitszertifikaten und Schutzschilden nahelegen. Diese Praxis führt zu einem tiefen Vertrauensverlust bei den Anwendern, die sich in einer akuten Krisensituation im Stich gelassen fühlen und den Eindruck gewinnen, dass ihre Notlage gezielt zur Umsatzsteigerung ausgenutzt werden soll. Es zeigt sich eine besorgniserregende Tendenz: Der Kunde wird mit den technischen Konsequenzen globaler Angreiferwellen allein gelassen.

Community-Diskussionen

In einschlägigen Technologie-Foren, Webmaster-Communities und Plattformen für Systemadministratoren wird das Vorgehen bei plötzlichen Serverüberlastungen intensiv debattiert. Viele Administratoren berichten von identischen Erlebnissen bei DomainFactory: Sobald ein automatisierte Überwachungssystem des Hosters eine Lastspitze registriert, greift die automatische Schutzsperre. In der Community wird kritisiert, dass diese Sperren oft rein digitaler Natur sind und ohne menschliche Vorprüfung durch qualifizierte Systemadministratoren umgesetzt werden. Kleinere Foren und Blogs stehen diesen Schutzmechanismen oft hilflos gegenüber. Die Kritikpunkte in den einschlägigen Sysadmin-Boards ähneln sich dabei stark: mangelnde Transparenz bei der Bereitstellung von Log-Dateien, unzureichende telefonische Erreichbarkeit von echten Technikern und der permanente Verweis auf teurere Server-Tarife oder externe Sicherheits-Dienstleistungen als einzige Option zur Wiederfreischaltung.

In den Fachdiskussionen wird immer wieder betont, dass die Kommunikation das Hauptproblem darstellt. Anstatt dem Kunden konkrete IP-Adressen oder Auszüge aus den Server-Logfiles bereitzustellen, damit dieser gezielte Gegenmaßnahmen ergreifen kann, verbleiben die Hoster wie DomainFactory in einer Position der Unnahbarkeit. Dem Webmaster werden jegliche Werkzeuge zur Selbsthilfe genommen, da der Zugriff auf die administrativen Werkzeuge im Moment der Sperre oft ebenfalls eingeschränkt oder komplett blockiert ist. Dadurch entsteht ein technologisches Machtgefälle, bei dem der Kunde gezwungen ist, die Behauptungen des Hosters ungeprüft zu akzeptieren. Dies betrifft insbesondere Betreiber, die auf Barrierefreiheit angewiesen sind und durch wissenschaftliche, blockierte Menüs zusätzlich ausgegrenzt werden.

Technische Einordnung

Im Shared Hosting teilen sich Hunderte, manchmal Tausende Kunden dieselbe physische Server-Infrastruktur, einschließlich der CPU-Kerne, des Arbeitsspeichers und der Netzwerkanbindung. Um das Gesamtsystem vor dem Ausfall zu schützen, setzen Anbieter wie DomainFactory auf sogenannte Ressourcen-Erkennungssysteme. Wenn ein plötzlicher Bot-Traffic oder eine koordinierte Crawling-Welle auf ein einzelnes Projekt einbricht, steigen die Prozesse des Webservers rasant an. Typische Schutzsysteme riegeln die betroffene Domain ab, um ein Mitreißen der Nachbardomains auf dem gleichen Server-Node zu verhindern. Das Problem liegt jedoch in der Natur des Bot-Traffics: Aggressive Scraper und automatisierte Skripte tasten gezielt Schwachstellen ab. Ohne serverseitige Filter wie Web Application Firewalls auf Infrastrukturebene trifft diese Last direkt das Content-Management-System des Kunden, das unter der Last der Anfragen kollabiert, bevor der Webmaster überhaupt reagieren kann.

Experten fordern daher seit langem, dass Hoster grundlegende Schutzmechanismen wie Rate Limiting standardmäßig auf Serverebene implementieren müssen, anstatt die ungefilterte Last an die Kunden-Skripte durchzureichen. Wenn ein Server so konfiguriert ist, dass er Hunderttausende von Anfragen ungehindert auf ein einzelnes Skript wie die integrierte Steuerung eines Forums durchschlagen lässt, liegt ein strukturelles Defizit in der vorgelagerten Sicherheitsarchitektur des Hosters vor. Ein moderner Schutz vor bösartigen Bots sollte auf der Netzwerk- und Transportebene stattfinden, noch bevor die Anwendungsschicht des Kunden überhaupt beansprucht wird. Das Abwälzen dieser architektonischen Verantwortung auf den Endnutzer ist ein zentraler Kritikpunkt an den aktuellen Shared-Hosting-Konzepten von DomainFactory.

Zwischenfazit

Die Recherche zeigt, dass es sich bei solchen Vorfällen in der Regel nicht um eine globale Störung des gesamten Hosters handelt, sondern um gezielte, automatisierte Einzelmaßnahmen zum Schutz der Shared-Hosting-Umgebung. Dennoch hinterlässt die wiederkehrende Nutzerkritik an der Kommunikationspolitik der Anbieter tiefe Zweifel an der Kundenorientierung. Eine sachliche Einordnung erfordert den Blick auf beide Seiten: Der Hoster muss die Gesamtstabilität seiner Plattform garantieren, während der Kunde ein Anrecht auf transparente Daten, präzise Logfiles und eine faire Chance zur Mängelbeseitigung hat. Eine Vorverurteilung ist hierbei fehl am Platz, doch die Methodik, wie diese Konflikte auf dem Rücken kleinerer Plattformen ausgetragen werden, bedarf einer kritischen und lückenlosen Betrachtung, um die strukturellen Missstände im System von DomainFactory aufzudecken.

Kompletter Fall cap4free.de (Originalbericht)

Der Überfall: Sperrung ohne Vorwarnung (Freitag, 08.05.2026)

Der Schock traf das Netzwerk am Freitagnachmittag um 16:01 Uhr. Ohne vorherige Warnung wurde der Stecker gezogen. Zu einem Zeitpunkt, an dem die administrative Erreichbarkeit des Supports vor dem Wochenende ohnehin stark eingeschränkt ist, schalteten die automatisierten Systeme von DomainFactory die Erreichbarkeit des Forums komplett ab. Diese zeitliche Platzierung kurz vor dem Wochenende verschärft die Situation für jeden Betreiber drastisch, da eine schnelle Klärung dadurch systematisch erschwert wird.

Die erste System-Mail traf sekundengenau um 16:01 Uhr ein:

Betreff: Überlastung durch Ihre Domain / Sperrmitteilung // AN: 528786

Ihre bei uns registrierte Domain forum.cap4free.de war in den letzten Tagen mehrfach für eine Serverüberlastung verantwortlich. ACHTUNG Aus diesem Grund wurde die Domain gesperrt.

Diese Nachricht hinterließ den Betreiber fassungslos. Das Forum wurde technisch akribisch gepflegt, Updates wurden stets zeitnah eingespielt und es gab im Vorfeld keinerlei Anzeichen für eine Fehlfunktion oder eine schleichende Überlastung des Tarifs bei df.eu. Die Formulierung in den letzten Tagen suggeriert zudem eine fortlaufende Belastung, über die der Kunde jedoch zu keinem Zeitpunkt vorab informiert wurde, um präventive Gegenmaßnahmen zu ergreifen. Es ist vollkommen inakzeptabel, ein System aufgrund einer angeblich mehrtägigen Last ohne Zwischenwarnung abzuschalten.

Der Kampf um Gehör: Login und die Telefon-Falle

Unmittelbar nach der Sperrung begann Mevludin Useinoski mit dem Kampf um seine Seite. Da er telefonisch Hilfe suchen wollte, musste er sich mühsam in seinen Kunden-Login anmelden. Dieser Prozess gestaltete sich jedoch als eine massive Geduldsprobe, da die administrativen Oberflächen im Zustand einer akuten Domainsperre oft verzögert reagieren oder Fehlermeldungen ausgeben. Für einen Webmaster mit einer Sehbehinderung stellt dies eine zusätzliche, künstliche Barriere dar.

Der Prozess der Verzweiflung stellte sich wie folgt dar:

Login trotz Barrieren: Mevludin kämpfte sich durch das verschachtelte Menü, um die notwendige Telefon-PIN, den sogenannten Support-Token, zu generieren. Ohne diese tagesaktuelle Identifikationsnummer verweigert das System jede Auskunft am Telefon, sodass der Kunde gezwungen ist, wertvolle Zeit in den administrativen Untermenüs zu verlieren.

Die Abfuhr am Telefon: Mit der mühsam generierten PIN in der Hand rief er den Support an, in der Hoffnung, mit einem qualifizierten Techniker das Problem direkt auf Serverebene zu besprechen. Das Ergebnis war eine eiskalte Ablehnung. Trotz der korrekt vorliegenden PIN wurde ihm jegliche technische Hilfe am Telefon verweigert. Man verwies ihn barsch zurück auf das E-Mail-System. Ein direktes Gespräch mit einem Techniker oder Systemadministrator sei an der Hotline von df.eu unerwünscht und organisatorisch nicht vorgesehen.

Die manuelle Spurensuche: Da der Support am Telefon schwieg und keine Daten lieferte, suchte der Betreiber im Kundenmenü selbst nach den Ursachen. Er durchforstete die rudimentär zugänglichen Statistiken nach den IP-Leichen, die den Traffic verursachten. Er identifizierte die Angreifer-IPs eigenhändig, um dem Support handfeste Fakten statt spekulativer Ausreden präsentieren zu können.

Die Diagnose: Das Rätsel der 200.000 Geister-Zugriffe

Kurz nach den ersten kontaktversuchen traf um 16:20 Uhr eine E-Mail von Florian aus dem Technical Support ein, die das angebliche Ausmaß der Überlastung beziffern sollte:

Guten Tag, wir können heute bereits über 200.000 Zugriffe auf Ihre Subdomain verzeichnen. Es handelt sich um Zugriffe von Bots oder Crawlern auf URLs wie app.php/cron. Eine Sperre ist unumgänglich.

Die vom Betreiber mühsam extrahierten Daten der Täter-IPs zeigten jedoch ein hochgradig verteiltes, globales Zugriffsmuster, das eindeutig auf ein automatisiertes Bot-Netzwerk hindeutete. Es handelt sich um gezielte, bösartige Aufrufe von außen:

340 Zugriffe stammten von der IP-Adresse 74.7.241.45 aus den Niederlanden.

145 Zugriffen wurden über die IPv6-Adresse 2600:3c03::2000… aus den Vereinigten Staaten registriert.

89 Zugriffe kamen von der IP-Adresse 150.5.134.235 aus Hongkong.

Darüber hinaus zeigten sich über 50 weitere IP-Adressen weltweit, unter anderem aus Australien, Singapur, Deutschland und Indonesien, die in kurzen Abständen die exakt gleiche URL attackierten.

Die schriftliche Antwort von Mevludin Useinoski erfolgte um 16:35 Uhr und legte die Problematik unmissverständlich dar:

Hallo Florian, vielen Dank für die Informationen. Die Situation ist für mich überraschend. Mir ist es aufgrund meiner Sehbehinderung besonders schwierig, solche Entwicklungen selbstständig zu überwachen. Warum wird die Webseite einfach gesperrt? In meinen Statistiken ist kein ungewöhnlich hoher Traffic erkennbar. Wenn hier jemand versucht, das Forum zu stören, wäre es wichtig, dass SIE Maßnahmen zum Schutz treffen.

Die Entlarvung: „Du bist unschuldig, aber bleibst gesperrt“

Die darauffolgende Antwort des Hosters offenbarte die ganze Absurdität der internen Richtlinien. Um 18:41 Uhr schrieb Andre M. vom Technical Support eine Nachricht, die den Betreiber jeglicher Schuld freisprach, aber dennoch an der harten Sanktion festhielt:

Die Ursache liegt nicht in fehlenden Updates oder einem Fehlverhalten Ihrerseits. Wir bedauern die Frustration, aber in einer SharedHosting-Umgebung können wir keinen individuellen Schutz bereitstellen. Eine Freischaltung ist nur möglich, wenn externe Schutzmaßnahmen eingerichtet werden. Wir verweisen auf Paragraph 9.1 unserer AGB.

Diese Aussage gleicht einer Kapitulation vor der eigenen Technik. Der Hoster gibt offen zu, dass der Kunde ein absolut fehlerfreies System betreibt, straft ihn jedoch für die Unfähigkeit der eigenen Server-Infrastruktur ab, unvollständige oder bösartige Bot-Anfragen abzufangen. Der Verweis auf die Allgemeinen Geschäftsbedingungen dient hierbei als juristisches Schutzschild, um die eigene Verantwortung komplett auf den Kunden abzuwälzen.

Gegen diesen Bescheid legte Mevludin Useinoski um 20:09 Uhr energischen Widerspruch ein:

Guten Abend, Ihre Rückmeldungen wirken auf mich äußerst mechanisch. Es ist frustrierend, dass meine Homepage gesperrt wird, wenn IHR System angegriffen wird. Vor wenigen Wochen wurde ein Update von Ihrer Seite eingespielt, seither treten diese Fehler gehäuft auf. Die Verantwortung liegt klar bei Ihnen als Anbieter!

Der „Trick“: Das Angebot, das wir ablehnen

Nachdem zweifelsfrei feststand, dass das Forum von technischer Seite her absolut sicher war und kein Fehlverhalten des Betreibers vorlag, änderte DomainFactory die Kommunikationsstrategie. Das Gespräch verlagerte sich weg von einer technischen Problemlösung hin zu einem gezielten Verkaufsgespräch für kostenpflichtige Zusatzdienste.

Am Montag, dem 11.05.2026, um 08:28 Uhr meldete sich Thomas Radlmeier in seiner Funktion als Senior Supervisor zu Wort:

Leider hält der Traffic an. Eine Freischaltung ist technisch nicht umsetzbar. Um Ihre Seite wieder freischalten zu können, ist der Einsatz von Sucuri Website Security Deluxe notwendig. Als Entgegenkommen bieten wir Ihnen den ersten Monat kostenfrei an.

Diese Strategie entlarvt das Vorgehen des Hosters vollständig. Die Freischaltung eines unverschuldet blockierten Kontos wird direkt an den Abschluss eines kostenpflichtigen Zusatzabonnements gekoppelt. Ein Dienst, der monatlich spürbare Extrakosten verursacht, soll nun die Arbeit übernehmen, die eigentlich in den Kernkompetenzen eines seriösen Webhosters liegen sollte. Es drängt sich der Verdacht auf, dass hier eine Notsituation von df.eu instrumentalisiert wird, um Upselling zu betreiben.

Mevludins Antwort erfolgte um 09:06 Uhr und setzte eine klare Grenze gegen diese Geschäftspraktik:

Guten Tag, ich bin mit Ihrer vorgeschlagenen Lösung absolut nicht einverstanden. Es ist für mich nicht nachvollziehbar, warum ich zusätzliche Kosten tragen soll, nur weil Ihr Server attackiert wird. Ihr Angebot für den kostenpflichtigen Schutzdienst lehne ich daher ab.

Die bittere Bilanz: Datenlecks und Traffic-Lügen

Was dieser Fall für alle Kunden von DomainFactory bedeutet, ist zutiefst alarmierend und wirft ein Schlaglicht auf gravierende interne Missstände:

Der Traffic-Schwindel: Der Betreiber hat sich durch das Kundenmenü gekämpft und die internen Daten akribisch analysiert. Dabei stieß er auf eine massive logische Ungereimtheit. Wie kann eine vollständig gesperrte Domain, deren PHP-Prozesse serverseitig komplett gestoppt und blockiert sind, weiterhin eine unzulässige Last erzeugen? DomainFactory bleibt die Antwort auf diese Frage und die Bereitstellung der geforderten, detaillierten Server-Logfiles bis heute schuldig. Werden hier blockierte Anfragen fälschlicherweise dem Kundenkonto angerechnet?

Der Sicherheits-Skandal und der dringende Verdacht eines Datenlecks: Zeitnah zur Sperrung erhielt Mevludin gezielte Phishing-Mails auf die E-Mail-Adresse info@cap4free.de. Das Erschreckende daran ist, dass diese Adresse zu keinem Zeitpunkt öffentlich im Internet genutzt, auf der Webseite hinterlegt oder in Formularen eingetragen wurde. Sie diente ausschließlich der internen, administrativen Kommunikation mit dem Hoster. Dass genau diese Adresse plötzlich in den Fokus von Betrügern gerät, lässt darauf schließen, dass Kundendaten im Netz gelandet sein müssen oder die internen Systeme von DomainFactory ein massives Sicherheitsleck aufweisen. Dies erfordert eine datenschutzrechtliche Überprüfung.

Die Telefon-Blockade: Trotz einer korrekt im barrierebehafteten Kundenmenü generierten PIN wird dem Kunden am Telefon jede qualifizierte Hilfe verweigert. Ein Hoster, der seine Kunden in der Not eiskalt allein lässt und jeglichen menschlichen Dialog blockiert, disqualifiziert sich für den professionellen Betrieb von Community-Plattformen.

Wie geht es weiter? Ein Appell an die Community

Wir lassen uns von DomainFactory nicht vorschreiben, wie wir unsere Plattform betreiben. Wir lassen uns nicht durch unbewiesene Behauptungen und verkaufstaktische Tricks das Geld aus der Tasche ziehen! Unser soziales Projekt basiert auf freiem Austausch und gegenseitiger Unterstützung, nicht auf der Gewinnmaximierung anonymer Hosting-Konzerne. Ein barrierefreies Netz lässt sich nicht unter den Bedingungen digitaler Willkür aufbauen.

Unser Notfallplan steht fest:

Der Umzug auf unseren eigenen V-Server. Wir werden das Forum komplett von df.eu abziehen, um wieder ein freies, stabiles und vernünftiges Forum zur Verfügung zu stellen. Auf einer eigenen Server-Infrastruktur haben wir die volle Kontrolle über die Sicherheitsarchitektur, können bösartige IPs direkt an der Firewall blockieren und sind nicht länger der Willkür und den unfairen Bedingungen eines Großhosters ausgeliefert. Wir transformieren diesen Rückschlag in einen technologischen Befreiungsschlag.

Mevludin Useinoski
Leitung cap4free-Netzwerk

Teilt diesen Beitrag! Das Netz muss erfahren, wie hier mit engagierten Webmastern umgegangen wird!

Schluss / Fazit

Aus technischer Sicht wirft der Fall cap4free.de grundlegende Fragen über die Zukunft und die Fairness im Shared-Hosting-Bereich auf. Die Abwicklung von automatisierten Bot-Wellen über die Cronjob-Schnittstelle eines weit verbreiteten Forensystems gehört zum Standard-Repertoire jeder modernen Serverüberwachung. Dass ein etablierter Hoster die serverseitige Filterung solcher bekannten Zugriffsmuster verweigert und stattdessen den Kunden in die Pflicht nimmt, ein kostenpflichtiges Zusatzprodukt eines Drittanbieters zu buchen, zeigt die tiefen strukturellen Defizite in dieser Branche. Es hinterlässt in der Fachwelt einen bleibenden Eindruck, wenn die fundamentale Abwehr von Cyber-Risiken zu einem kostenpflichtigen Upgrade-Modell umfunktioniert wird, anstatt als integraler Bestandteil des Hosting-Vertrags verstanden zu werden.

Es bleiben wesentliche Fragen offen, die eine lückenlose Aufklärung verlangen. Warum blieben die Detail-Logfiles trotz mehrfacher, berechtigter Aufforderung unter Verschluss? Wie erklären sich die unbefugten Phishing-Zugriffe auf eine nicht öffentliche, rein interne E-Mail-Adresse zeitnah zum Vorfall, die den dringenden Verdacht eines Datenlecks erhärten? Eine endgültige technische Verifizierung der serverseitigen Gesamtlast kann ohne die Bereitstellung der vollständigen Serverprotokolle durch DomainFactory nicht abschließend erfolgen. Der Konflikt verdeutlicht jedoch exemplarisch die tiefe Kluft zwischen den wirtschaftlichen Interessen großer Hosting-Konzerne und den praktischen Bedürfnissen engagierter Webmaster, die Barrierefreiheit und soziale Teilhabe im Internet realisieren wollen. Der Schritt zur Server-Migration ist die einzig logische und konsequente Antwort auf eine verweigerte Partnerschaft auf Augenhöhe.