Mijn hostingprovider heeft mijn website opgeschort: de mogelijke oorzaken

De oorzaak vinden

Bij hosting met cPanel vervangt een opschorting de site door een pagina die meldt dat het account is opgeschort, vaak in het Engels (“This Account has been suspended”). Ze blokkeert ook het inloggen op het controlepaneel, de FTP-toegang en het verzenden van e-mail vanaf het account; het ontvangen hangt af van de configuratie van de server. De bestanden zelf blijven staan.

De oorzaak staat meestal in een bericht van de hostingprovider: zoek in de mailbox die aan het account is gekoppeld, spammap inbegrepen, naar de woorden “opgeschort”, “suspension”, “abuse”, “malware” of “factuur”, en kijk daarna in het klantenaccount en de tickets.

Geeft het bericht geen oorzaak, vraag er dan schriftelijk om, met de betreffende bepaling uit de gebruiksvoorwaarden: een opschorting wordt sneller opgeheven als iedereen over hetzelfde probleem praat.

Eerst een kopie van de site veiligstellen

De voorwaarden van de hostingprovider bepalen na welke termijn de gegevens van een opgeschort account mogen worden verwijderd. Zet vóór elke andere stap een kopie in veiligheid:

• De bestanden: via SFTP als de toegang nog open is, anders door de hostingprovider om een archief te vragen.
• De database: via de export van phpMyAdmin of wp db export, of in dezelfde aanvraag voor een archief.
• De e-mail, als de mailboxen op hetzelfde account worden gehost: een kopie van elke mailbox via IMAP vanuit een e-mailprogramma.
• De geplande verwijderdatum, schriftelijk opgevraagd.

Bewaar deze kopie zoals ze is, ook als de site is geïnfecteerd: ze dient voor het opschonen en om te vergelijken.

Oorzaak 1: een gehackte site

Op een gedeelde server brengt een site die malware verspreidt, valse inlogpagina’s host of spam verstuurt, de andere accounts en de reputatie van de IP-adressen van de server in gevaar. De hostingprovider schort het account daarom op, en heropent het zodra het probleem is opgelost.

1. Vraag om de lijst van gedetecteerde bestanden, en of de hostingprovider de toegang tot de bestanden kan heropenen zolang u opschoont.
2. Verwijder de gemarkeerde bestanden en zoek daarna wat ze heeft neergezet: PHP-bestanden in wp-content/uploads, onbekende mappen in de root, scripts die e-mail versturen, toegevoegde beheerdersaccounts.
3. Wijzig de wachtwoorden van de hosting, de FTP, de database en de beheerders, en vervang de beveiligingssleutels in wp-config.php.
4. Werk WordPress, het thema en de plugins bij, en verwijder wat niet meer wordt gebruikt.
5. Schrijf de hostingprovider wat er is gevonden, verwijderd en hersteld, met vermelding van het kenmerk van de opschorting.

Wie met dezelfde bestanden naar een andere hostingprovider verhuist, neemt de infectie mee, en daarmee het risico op een nieuwe opschorting. Het opschonen gebeurt voordat de site weer online gaat, waar dat ook is.

Oorzaak 2: resources boven de limieten

Gedeelde hosting begrenst wat elk account verbruikt. Op servers met CloudLinux gelden de limieten voor de processor, het fysieke geheugen, de in- en uitvoer van de schijf, het aantal processen en de entry processes, dat wil zeggen de gelijktijdige verbindingen met dynamische scripts zoals PHP. Het aantal bestanden wordt geteld in inodes: elk bestand en elke map verbruikt er één.

Wordt de limiet voor entry processes bereikt, dan krijgen bezoekers een foutmelding 508 “Resource Limit Is Reached”. Herhaalde overschrijdingen kunnen tot opschorting leiden. Het paneel van de hostingprovider toont het verbruik in de tijd: zoek de uren van de pieken en lees daarna de toegangslogs van die uren.

De meest voorkomende oorzaken

• Bots die in een lus proberen in te loggen op wp-login.php of xmlrpc.php.
• Zware plugins: statistieken, logboeken, afbeeldingsgeneratoren, back-ups.
• Back-ups die op het account zijn opgeslagen, in wp-content, die schijfruimte en inodes vullen.
• De geplande taken van WordPress, die bij elk bezoek worden gestart.

du -sh wp-content/* | sort -h
find . -type f | wc -l

<Files "xmlrpc.php">
Require all denied
</Files>

Dit blok weigert elk verzoek naar xmlrpc.php. Controleer eerst of geen enkele tool het gebruikt: Jetpack bijvoorbeeld werkt via XML-RPC. Toont de site daarna een fout 500, dan staat de hostingprovider deze instructie niet toe in .htaccess: verwijder het blok en vraag de hostingprovider om het equivalent.

define( 'DISABLE_WP_CRON', true );

De geplande taken moeten dan door de planner van de server worden aangeroepen: maak in het paneel van de hostingprovider een taak die https://www.uw-site.com/wp-cron.php met een vaste tussenpoos aanroept, bijvoorbeeld elke 15 minuten.

Oorzaak 3: een onbetaalde factuur

Betaal de factuur vanuit het klantenaccount en controleer of de opgeslagen kaart niet is verlopen. De heractivering volgt op de betaling, automatisch of op verzoek, afhankelijk van de hostingprovider; duurt het lang, open dan een ticket met het kenmerk van de betaling.

De domeinnaam wordt vaak los van de hosting verlengd. Een verlopen domein laat de site ook verdwijnen, maar de getoonde pagina is dan die van de registrar, en niet die van de hostingprovider: twee facturen, en twee controles.

Oorzaak 4: een klacht of een schending van de voorwaarden

• Auteursrecht: een afbeelding of tekst die zonder licentie is gebruikt. Verwijder de content, of stuur het bewijs van de licentie, met vermelding van het kenmerk van de klacht.
• Melding van misbruik: een valse inlogpagina of malware die op uw site is ontdekt. Dat is een hack, te behandelen als oorzaak 1.
• Klachten over spam: e-mails die vanaf het account zijn verstuurd naar ontvangers die ze niet verwachtten, nieuwsbrieven inbegrepen. Controleer wie vanaf het account verstuurt, en hoe de adressen zijn verzameld.

Antwoord schriftelijk, binnen de gestelde termijn, met een beschrijving van wat er is gedaan: dat is het stuk dat de hostingprovider aan het dossier toevoegt om de opschorting op te heffen.

Voordat de site weer online gaat

1. De oorzaak is gevonden en verholpen, en de hostingprovider heeft schriftelijk bevestigd wat hij verwacht.
2. De wachtwoorden zijn gewijzigd en de onderdelen van de site zijn bijgewerkt.
3. Er bestaat een automatische back-up, opgeslagen buiten het hostingaccount.
4. Iemand ontvangt de waarschuwingen van de hostingprovider: het e-mailadres van het account wordt gelezen.