Een cateringbedrijf uit Breda kwam bij ons met een site die twee keer in drie maanden besmet was geraakt. De eerste keer hadden ze de malware laten verwijderen, wachtwoorden gewijzigd en alles geüpdatet. Zes weken later stonden de vreemde bestanden er weer. Niemand had iets geïnstalleerd, er was geen verouderde plugin, de wachtwoorden waren nieuw en uniek. Het probleem zat niet in hun website. Het zat op de server ernaast.

Dat is precies waarom de vraag “is gedeelde hosting veilig” niet met ja of nee te beantwoorden is. Het hangt volledig af van hoe uw hostingpartij de scheiding tussen accounts heeft ingericht, en dat is nu net het onderdeel dat niet op de verkooppagina staat. In dit artikel leggen wij uit hoe besmetting tussen sites overslaat, hoe u herkent of u ermee te maken heeft, en wat u eraan kunt doen zonder meteen naar een dure server te verhuizen.

Wat gedeelde hosting technisch inhoudt

Bij gedeelde hosting draaien tientallen tot honderden websites op één fysieke server. Ze delen de processor, het geheugen, de PHP-installatie en de webserver. Elke klant krijgt een eigen map en een eigen database, en in theorie kan niemand bij de buren. Het is een prima model: u betaalt een paar euro per maand in plaats van tientallen, en voor de meeste bedrijfssites is de capaciteit ruim voldoende.

De vraag is hoe strikt die scheiding is uitgevoerd. Bij een goed ingerichte omgeving draait elke website onder een eigen systeemgebruiker, met bestandsrechten die alleen die gebruiker toegang geven, en zijn functies waarmee PHP buiten de eigen map kan kijken uitgeschakeld. Bij een slecht ingerichte omgeving draaien alle sites onder dezelfde gebruiker, vaak die van de webserver. Dan is er in de praktijk nauwelijks een muur.

Hoe besmetting van de buren overslaat

Stel dat op dezelfde server een verwaarloosde website staat: een oude webshop van iemand die er niet meer naar omkijkt, met een plugin die al twee jaar een bekend lek bevat. Een geautomatiseerde scan vindt dat lek en plaatst een klein beheerbestand op die site. Vanaf dat moment heeft de aanvaller een voet op de server. Wat er dan kan gebeuren:

  • Doorlopen naar andere mappen. Draaien alle sites onder dezelfde gebruiker, dan kan het script uw bestanden lezen en schrijven alsof het uw eigen site is.
  • Configuratiebestanden uitlezen. In wp-config.php staan uw databasenaam, gebruikersnaam en wachtwoord. Is dat bestand leesbaar voor de buurman, dan is uw database dat ook.
  • Massaal injecteren. Een script loopt alle themabestanden op de server af en plakt er dezelfde regel code in. Dat is de klassieke situatie waarin twintig sites tegelijk dezelfde omleiding krijgen.
  • De server op de zwarte lijst. Wordt er vanaf de server spam verstuurd, dan komt het IP-adres op blokkeerlijsten. Uw eigen e-mail komt niet meer aan, terwijl uw site brandschoon is.
  • Prestatieproblemen. Een besmette buursite die honderdduizenden verzoeken verwerkt, eet het geheugen op. Uw site wordt traag of geeft foutmeldingen zonder aanwijsbare eigen oorzaak.

De laatste twee treffen u ook bij een perfect gescheiden omgeving. Reputatie en capaciteit deelt u nu eenmaal.

Hoe u herkent dat het probleem niet bij u ligt

Dit zijn signalen die wij gebruiken om te onderscheiden of een besmetting van binnenuit of van buitenaf komt:

  1. De besmetting komt terug na een grondige schoonmaak. Verwijderd, wachtwoorden vervangen, alles bijgewerkt, en na een paar weken staat het er weer. Dan is er een ingang die buiten uw site ligt.
  2. De gewijzigde bestanden hebben een tijdstempel dat nergens op slaat. Bestanden die zijn aangepast op een moment dat niemand heeft ingelogd, terwijl de toegangslogs van uw site niets bijzonders tonen.
  3. De code lijkt op wat er elders rondgaat. Zoekt u een stuk van de toegevoegde code op en vindt u meldingen van tientallen andere sites bij dezelfde hostingpartij, dan is dat veelzeggend.
  4. Uw e-mail komt niet aan terwijl uw domein in orde is. Controleer of het IP-adres van uw server op een blokkeerlijst staat. Dat kunt u opzoeken bij openbare blacklistcontroles.
  5. De hostingpartij is vaag. Vraagt u of sites onder een eigen gebruiker draaien en krijgt u geen duidelijk antwoord, dan weet u genoeg.

Ziet u geen enkel signaal van buitenaf, kijk dan eerst binnenshuis. In de meeste gevallen zit de ingang toch in de eigen site. Hoe u die vindt, beschrijven wij in het artikel over backdoors in WordPress.

Wat u kunt doen zonder te verhuizen

Verhuizen is niet altijd nodig en niet altijd het eerste antwoord. Deze maatregelen verkleinen het risico aanzienlijk:

  • Vraag uw hostingpartij naar de isolatie. Draait elke site onder een eigen gebruiker? Is open_basedir actief? Wordt er per account gescand? Een goede partij beantwoordt dat binnen een dag.
  • Zet de bestandsrechten strak. Mappen op 755, bestanden op 644, en wp-config.php op 640 of 600. Nooit 777, ook niet tijdelijk. Meer daarover staat in ons artikel over bestandsrechten.
  • Verwijder wat u niet gebruikt. Een oude testsite of een verlaten subdomein in hetzelfde account is precies de verwaarloosde buurman, alleen dan van uzelf.
  • Zet een firewall vóór de site. Een firewall die op DNS-niveau werkt, filtert verkeer voordat het uw server bereikt en helpt ook tegen aanvallen die op de hele server gericht zijn.
  • Houd een controle op bestandswijzigingen bij. Krijgt u een melding zodra een kernbestand verandert, dan merkt u een injectie binnen uren in plaats van weken.
  • Bewaar back-ups buiten de server. Staan uw back-ups op dezelfde server, dan zijn ze bij een serverbrede besmetting net zo goed geraakt.

Wanneer verhuizen wél verstandig is

Er zijn situaties waarin doorgaan op hetzelfde pakket weinig zin heeft. Als u twee keer besmet bent geraakt zonder aanwijsbare oorzaak in uw eigen site. Als uw hostingpartij niet kan uitleggen hoe accounts gescheiden zijn. Als u een webshop draait met betaalgegevens en klantaccounts, want dan is het risicoprofiel simpelweg anders. En als de site regelmatig traag is op willekeurige momenten die niets met uw eigen bezoekersaantallen te maken hebben.

Een middenweg is beheerde WordPress-hosting: technisch vaak nog steeds gedeeld, maar met strikte isolatie per account, serverzijdige beveiliging en dagelijkse back-ups buiten de server. Voor de meeste mkb-sites is dat een betere stap dan een eigen server, die u immers zelf moet onderhouden.

Overweegt u het, wacht er dan niet mee tot na een besmetting: een verhuizing tijdens een hack is een stuk vervelender dan een geplande verhuizing. Wij begeleiden zulke overstappen tegen een vast bedrag, en zetten de site daarna zo neer dat de beveiliging van meet af aan op orde is.

Tot slot

Gedeelde hosting is niet onveilig omdat het gedeeld is. Het wordt onveilig als niemand de muren tussen de buren controleert. Stel uw hostingpartij deze week één vraag per e-mail: draaien de websites op deze server onder gescheiden systeemgebruikers, en wat gebeurt er als een andere klant besmet raakt? Het antwoord vertelt u meer dan welke productpagina dan ook.