Kort sagt: Är flera kundwebbplatser berörda hos er byrå är det sällan en slump, utan oftast en gemensam server, en delad åtkomst eller samma PHP-version. Berörs ni, hör av er direkt. Vi ger er en överblick, begränsar incidenten på distans, rensar systemen och levererar rapporter till era kunder.
Radera ingenting och installera inte om något nu. Även om kundernas tryck är stort: Utan säkrade loggar och filer går det varken att klarlägga orsaken eller att belägga vad som inte berördes. Anmäl nödläge, så tar vi över från första meddelandet.
Berörs ni? Tecken när kundwebbplatser har hackats
Som byrå ser ni mönster som enskilda driftansvariga aldrig märker. På en gemensam incident tyder:
- Flera kundwebbplatser visar samtidigt samma symtom: omdirigeringar, skräppostinnehåll, varningar i webbläsaren.
- Samma okända adminkonto eller samma misstänkta fil dyker upp hos olika kunder.
- Webbhotellet rapporterar missbruk eller avvikande belastning för ett konto där många projekt ligger.
- Kunder ringer eftersom deras webbplats varnas av Google, och vid en motkontroll hittar ni fler webbplatser i samma skick.
- En utvecklare eller före detta medarbetare hade åtkomst till många projekt, och en åtkomst har läckt ut.
- Underhållsarbete via ett centralt verktyg, till exempel driftsättning, säkerhetskopior eller en uppdateringstjänst, har ändrat en webbplats som ni inte har rört.
- Ni driver många webbplatser på PHP-versioner vars patchnivå ni inte kan belägga för varje enskild.
Sedan PHP2Shell tillkommer att sårbarheten finns i själva PHP-tolken. En CMS-uppdatering, till exempel hos WordPress, stänger den inte; avgörande är den PHP-körmiljö som faktiskt levererar.
Det här gör ni direkt
- Lista de berörda webbplatserna: Domän, server, hostingkonto, PHP-version, CMS, ansvariga. Även misstänkta fall hör dit.
- Sök gemensamma nämnare: Samma server? Samma åtkomster? Samma plugin? Samma driftsättningsväg?
- Skärma av utsatta webbplatser: Sätt webbplatser som aktivt levererar skadlig kod i underhållsläge. Radera inte.
- Låt säkra loggar och läge: Be webbhotellet bevara protokoll; säkra egna driftsättningsprotokoll.
- Kontrollera centrala åtkomster: Vem har åtkomst till hostingpanel, SSH, Git, lösenordshanterare och driftsättning? Ändringar först efter överenskommelse.
- Informera kunderna återhållsamt: Först bara det som är belagt. Ange ingen orsak innan den har fastställts.
- Kontakta oss: Ring eller skriv via WhatsApp.
Hur hjälper PHP SOS konkret?
- Kartlägga läget: Vi skaffar oss tillsammans med er en överblick över alla webbplatser och servrar och ordnar dem efter brådska: aktivt levererad skadlig kod, misstanke om dataläckage, förmodligen bara ej patchad.
- Säkra och stänga: Vi säkrar varje berört system innan något ändras och stänger den gemensamma ingångsporten: åtkomster, PHP-nivå, omstart av alla processer.
- Granska och rensa: Vi söker systematiskt över alla webbplatser efter samma spår, tar bort webshells och bakdörrar och återställer rent. Detaljer under Ta bort skadlig kod och webshells.
- Härda och rapportera: Vi separerar webbplatser från varandra där det är meningsfullt och levererar en kort rapport per kund som ni kan lämna vidare, samt en samlad rapport till er.
Vi arbetar på distans, utan resor, i hela Europa. På begäran i bakgrunden för er byrå, som beskrivs på sidan Byråer och white label.
Varför många webbplatser ofta faller samtidigt hos byråer
Den som driver många projekt på en server sparar kostnader men byter isolering mot bekvämlighet. Körs allt under samma användare och samma PHP-processpool kan koden från en hackad webbplats läsa och ändra grannarnas filer. Det är inget exotiskt fall utan standard i många konfigurationer. Hur pooler kan separeras på rätt sätt beskrivs i Isolera PHP-FPM-pooler.
Dessutom finns delade åtkomster: en SSH-nyckel för alla projekt, ett hostingkonto med alla domäner, samma lösenord för staging och produktion. Här gäller principen om minsta möjliga rättigheter. Mer om det i Webbserveranvändarens rättigheter.
Även leveranskedjan räknas: Plugin, teman och bibliotek kommer från tredje part, webbhotellet ansvarar för plattformen, byrån för driften. Var gränserna går och var luckor uppstår behandlas i Leveranskedjan byrå och webbhotell.
Inventering, PHP-versioner och kommunikation med kunder
Det vanligaste problemet i sådana lägen är bristande överblick: Vilken webbplats körs på vilken server med vilken PHP-version, och vem ansvarar? Utan den listan går det inte att säga vem som berörs av patchen och vem som inte gör det. Hur ni bygger upp ett sådant register visar Inventering av webbplatser och servrar. Körs flera PHP-versioner parallellt hjälper dessutom Flera PHP-versioner på en server.
Mot kunderna räknas tydlighet. Ni behöver inte veta allt, men inte försköna något: Vad är belagt, vad granskas fortfarande, vad gör ni härnäst? Formuleringshjälp finns under Informera kunder efter en incident. Om personuppgifter berörs kan anmälningsskyldighet enligt art. 33 GDPR spela roll. Det är allmän information; bedömningen hör hemma hos dataskyddsombud och jurist. Växer incidenten utöver enskilda webbplatser går vi över till strukturerad incidenthantering.
Det här bör ni skicka till oss
- en lista över de berörda och de förmodat berörda domänerna
- uppgifter om server och hosting per projekt, i den mån de är kända
- PHP-versioner och använda CMS eller butiker
- de åtkomster ni kan ge oss och rollerna i teamet
- uppgifter om vad som senast ändrades eller rullades ut
- namn på kontaktpersonen för beslut samt för kundkommunikation
Varför PHP SOS
Vi arbetar Made in Germany och är sedan över 25 år, tillsammans med vårt partnernätverk av cyberproffs, specialiserade på IT-säkerhet. Ni har en kontaktperson för alla berörda projekt, vi arbetar på distans och dokumenterar per system vad som hittats och gjorts. Vi lovar inga underverk. Det som inte går att belägga kallar vi okänt, så att ni inte säger mer till era kunder än ni vet.
Berörs ni? Ring oss. Vi hjälper er.
Är flera av era kundwebbplatser avvikande är tidstrycket dubbelt: tekniskt och i förhållande till era kunder. Hör av er nu: Ring eller skriv via WhatsApp. Vi tar över från första meddelandet och är med tills incidenten är avslutad och dokumenterad. Anmäl nödläge nu
Vanliga frågor
Varför är ofta flera kundwebbplatser berörda på en gång?
Ofta delar webbplatserna en server, ett hostingkonto, samma PHP-process eller samma inloggningsuppgifter. Kommer en angripare in på ett ställe kan han röra sig i sidled. En sårbar PHP berör dessutom alla webbplatser som använder den.
Ska jag informera kunderna direkt?
Det beror på läget och avtalet. Klarlägg först vilka webbplatser som verkligen berörs, så att ni inte informerar utifrån antaganden. Vid personuppgifter är anmälningsskyldighet möjlig; bedömningen hör hemma hos dataskyddsombud eller jurist.
Vem bär ansvaret om en kunds webbplats har hackats?
Det beror på era avtal, skötselns omfattning och händelseförloppet. Vi ger ingen juridisk rådgivning om det. En ren rapport om orsak och åtgärder hjälper vid den bedömningen.
Kan ni arbeta i vårt namn utan att slutkunden ser oss?
På begäran arbetar vi i bakgrunden för er byrå och levererar rapporter som ni kan lämna vidare till era kunder. Detaljerna går vi igenom i förväg.
Räcker det att rensa kundwebbplatserna en och en?
Oftast inte. Ligger orsaken i den gemensamma servern, i en delad åtkomst eller i en ej patchad PHP-version dyker problemen upp igen efter den enskilda rensningen. Orsaken måste åtgärdas samtidigt.