Kort gezegd: Zijn bij uw bureau meerdere klantsites getroffen, dan is dat zelden toeval, maar meestal een gedeelde server, een gedeelde toegang of dezelfde PHP-versie. Bent u getroffen, neem dan direct contact op. Wij geven u overzicht, houden het incident op afstand in bedwang, schonen de systemen op en leveren u rapporten voor uw klanten.
Verwijder nu niets en zet niets opnieuw op. Ook als de druk van klanten groot is: zonder veiliggestelde logboeken en bestanden is noch de oorzaak vast te stellen noch aan te tonen wat niet was getroffen. Meld uw noodgeval en wij nemen het over vanaf het eerste bericht.
Bent u getroffen? Aanwijzingen als klantsites zijn gehackt
Als bureau ziet u patronen die individuele beheerders nooit opmerken. Op een gezamenlijk incident wijzen:
- Meerdere klantsites tonen tegelijk dezelfde symptomen: doorverwijzingen, spaminhoud, waarschuwingen in de browser.
- Hetzelfde onbekende beheerdersaccount of hetzelfde verdachte bestand duikt bij verschillende klanten op.
- De hoster meldt misbruik of opvallende belasting voor een account waarop veel projecten staan.
- Klanten bellen omdat hun site door Google wordt gewaarschuwd, en bij een tegencontrole vindt u meer sites in dezelfde toestand.
- Een ontwikkelaar of oud-medewerker had toegang tot veel projecten, en een toegang is uitgelekt.
- Onderhoud via een centrale tool, zoals deployment, back-ups of een updatedienst, heeft een site gewijzigd die u niet hebt aangeraakt.
- U beheert veel sites op PHP-versies waarvan u de patchstatus niet voor elke afzonderlijke site kunt aantonen.
Sinds PHP2Shell komt daar bij dat het lek in de PHP-interpreter zelf zit. Een CMS-update, bijvoorbeeld bij WordPress, dicht het niet; beslissend is de PHP-runtime die daadwerkelijk levert.
Wat u nu direct doet
- Maak een lijst van de getroffen sites: domein, server, hostingaccount, PHP-versie, CMS, verantwoordelijken. Ook verdachte gevallen horen erbij.
- Zoek gemeenschappelijke kenmerken: dezelfde server? Dezelfde toegangen? Dezelfde plugin? Dezelfde deploymentweg?
- Schermen gevaarlijke sites af: zet sites die actief schadelijke code leveren in onderhoudsmodus. Niet verwijderen.
- Laat logboeken en toestand veiligstellen: vraag de hoster protocollen te bewaren; zet eigen deploymentprotocollen veilig.
- Controleer centrale toegangen: wie heeft toegang tot hostingpaneel, SSH, Git, wachtwoordmanager en deployment? Wijzigingen pas na overleg.
- Informeer klanten terughoudend: eerst alleen wat aangetoond is. Noem geen oorzaak voordat die vaststaat.
- Neem contact met ons op: bel ons of stuur een bericht via WhatsApp.
Hoe helpt PHP SOS concreet?
- Situatie opnemen: Wij verschaffen ons samen met u overzicht van alle sites en servers en ordenen ze naar urgentie: actief geleverde schadelijke code, vermoeden van gegevenslek, vermoedelijk alleen niet gepatcht.
- Veiligstellen en dichten: Wij zetten elk getroffen systeem veilig voordat er iets wordt gewijzigd en dichten de gemeenschappelijke ingang: toegangen, PHP-status, herstart van alle processen.
- Controleren en opschonen: Wij zoeken systematisch over alle sites naar dezelfde sporen, verwijderen webshells en achterdeuren en herstellen netjes. Details onder Malware en webshells laten verwijderen.
- Beveiligen en rapporteren: Wij scheiden sites van elkaar waar dat zinvol is en leveren per klant een kort rapport dat u kunt doorgeven, plus een totaalrapport voor u.
Wij werken op afstand, zonder reistijd, in heel Duitsland en Europa. Op verzoek op de achtergrond voor uw bureau, zoals beschreven op de pagina Bureaus en white label.
Waarom bij bureaus vaak veel sites tegelijk omvallen
Wie veel projecten op één server draait, bespaart kosten, maar ruilt isolatie voor gemak. Draait alles onder dezelfde gebruiker en dezelfde PHP-processenpool, dan kan code van een gehackte site de bestanden van de buren lezen en wijzigen. Dat is geen exotisch geval, maar standaard in veel configuraties. Hoe pools netjes te scheiden zijn, beschrijft PHP-FPM-pools isoleren.
Daar komen gedeelde toegangen bij: één SSH-sleutel voor alle projecten, een hostingaccount met alle domeinen, dezelfde wachtwoorden voor staging en productie. Hier geldt het principe van de minste rechten. Meer daarover in Rechten van de webservergebruiker.
Ook de leveringsketen telt: plugins, thema's en bibliotheken komen van derden, de hoster is verantwoordelijk voor het platform, het bureau voor de bedrijfsvoering. Waar deze grenzen lopen en waar hiaten ontstaan, behandelt Leveringsketen bureau en hoster.
Inventaris, PHP-versies en communicatie met klanten
Het vaakst voorkomende probleem in zulke situaties is ontbrekend overzicht: welke site draait op welke server met welke PHP-versie, en wie is verantwoordelijk? Zonder die lijst is niet te zeggen wie door de patch wordt geraakt en wie niet. Hoe u zo'n register opbouwt, laat Inventaris van websites en servers zien. Draaien er meerdere PHP-versies naast elkaar, dan helpt bovendien Meerdere PHP-versies op één server.
Tegenover de klanten telt duidelijkheid. U hoeft niet alles te weten, maar mag niets mooier voorstellen: wat is aangetoond, wat wordt nog onderzocht, wat doet u hierna? Formuleringshulp vindt u onder Klanten informeren na een incident. Zijn persoonsgegevens getroffen, dan kunnen meldplichten volgens art. 33 AVG een rol spelen. Dit is algemene informatie; de beoordeling hoort bij de functionaris voor gegevensbescherming en de advocaat. Groeit het incident uit tot voorbij afzonderlijke sites, dan gaan we over op gestructureerde Incident Response.
Wat u ons het best kunt sturen
- een lijst van de getroffen en vermoedelijk getroffen domeinen
- gegevens over server en hosting per project, voor zover bekend
- PHP-versies en gebruikte CMS of webshops
- de toegangen die u ons kunt verlenen en de rollen in het team
- aanwijzingen wat er het laatst is gewijzigd of uitgerold
- naam van het aanspreekpunt voor beslissingen en voor klantcommunicatie
Waarom PHP SOS
Wij werken Made in Germany en zijn met ons partnernetwerk van cyberprofessionals al meer dan 25 jaar gespecialiseerd in IT-beveiliging. U hebt één aanspreekpunt voor alle getroffen projecten, wij werken op afstand en documenteren per systeem wat is gevonden en gedaan. Wij beloven geen wonderen. Wat niet is aan te tonen, noemen wij onbekend, zodat u tegenover uw klanten niet meer zegt dan u weet.
Bent u getroffen? Bel ons. Wij helpen.
Zijn meerdere van uw klantsites opvallend, dan is de tijdsdruk dubbel: technisch en in de verhouding tot uw klanten. Neem nu contact op: bel ons of stuur een bericht via WhatsApp. Wij nemen het over vanaf het eerste bericht en blijven erbij tot het incident is afgerond en gedocumenteerd. Meld nu uw noodgeval
Veelgestelde vragen
Waarom zijn vaak meteen meerdere klantsites getroffen?
Vaak delen de sites een server, een hostingaccount, hetzelfde PHP-proces of dezelfde toegangsgegevens. Komt een aanvaller op één plek binnen, dan kan hij zich zijwaarts verplaatsen. Kwetsbare PHP treft bovendien alle sites die het gebruiken.
Moet ik de klanten direct informeren?
Dat hangt af van de situatie en het contract. Stel eerst vast welke sites echt zijn getroffen, zodat u niet op basis van vermoedens informeert. Bij persoonsgegevens zijn meldplichten mogelijk; de beoordeling hoort bij de functionaris voor gegevensbescherming of de advocaat.
Wie is aansprakelijk als de site van een klant is gehackt?
Dat hangt af van uw contracten, de omvang van het beheer en het verloop. Wij geven daarover geen rechtsadvies. Een duidelijk rapport over oorzaak en maatregelen helpt bij die beoordeling.
Kunt u onder onze naam werken zonder dat de eindklant ons ziet?
Op verzoek werken wij op de achtergrond voor uw bureau en leveren we rapporten die u aan uw klanten kunt doorgeven. De details bespreken we vooraf.
Is het genoeg om de klantsites afzonderlijk op te schonen?
Meestal niet. Ligt de oorzaak bij de gedeelde server, een gedeelde toegang of een niet-gepatchte PHP-versie, dan duiken de problemen na de afzonderlijke opschoning weer op. De oorzaak moet mee worden verholpen.