En resumen: si en su agencia hay varios sitios de clientes afectados, rara vez es casualidad; suele ser un servidor compartido, un acceso compartido o la misma versión de PHP. Si le afecta, póngase en contacto de inmediato. Le damos una visión general, contenemos el incidente en remoto, limpiamos los sistemas y le entregamos informes para sus clientes.
No borre nada ahora y no reinstale nada. Aunque la presión de los clientes sea grande: sin registros ni archivos asegurados no se puede aclarar la causa ni demostrar qué no estuvo afectado. Comunique la emergencia y nos hacemos cargo desde el primer mensaje.
¿Le afecta? Indicios cuando se han hackeado sitios de clientes
Como agencia, usted ve patrones que los operadores individuales nunca notan. Apuntan a un incidente común:
- Varios sitios de clientes muestran al mismo tiempo los mismos síntomas: redirecciones, contenido de spam, advertencias en el navegador.
- La misma cuenta de administrador desconocida o el mismo archivo sospechoso aparece en distintos clientes.
- El proveedor de hosting informa de abuso o de una carga llamativa en una cuenta que aloja muchos proyectos.
- Los clientes llaman porque su sitio recibe una advertencia de Google, y al comprobarlo usted encuentra otros sitios en el mismo estado.
- Un desarrollador o un antiguo empleado tenía acceso a muchos proyectos y se ha filtrado un acceso.
- Trabajos de mantenimiento a través de una herramienta central, como el despliegue, las copias de seguridad o un servicio de actualizaciones, han modificado un sitio que usted no tocó.
- Gestiona muchos sitios en versiones de PHP cuyo estado de parcheo no puede acreditar para cada uno de ellos.
Desde PHP2Shell se suma que la vulnerabilidad está en el propio intérprete de PHP. Una actualización del CMS, por ejemplo de WordPress, no la cierra; lo decisivo es el entorno de ejecución de PHP que realmente sirve el sitio.
Qué hacer ahora mismo
- Hacer una lista de los sitios afectados: dominio, servidor, cuenta de hosting, versión de PHP, CMS, responsables. También los casos de sospecha.
- Buscar puntos en común: ¿mismo servidor? ¿mismos accesos? ¿mismo plugin? ¿misma vía de despliegue?
- Aislar los sitios en riesgo: ponga en modo de mantenimiento los sitios que entreguen código malicioso de forma activa. No borrar.
- Hacer que se aseguren los registros y el estado: pida al proveedor de hosting que conserve los registros; asegure sus propios registros de despliegue.
- Revisar los accesos centrales: ¿quién tiene acceso al panel de hosting, a SSH, a Git, al gestor de contraseñas y al despliegue? Los cambios, solo tras consultarnos.
- Informar a los clientes con cautela: al principio solo lo que está demostrado. No mencione ninguna causa antes de que esté establecida.
- Contactarnos: llame o escriba por WhatsApp.
¿Cómo ayuda PHP SOS en concreto?
- Evaluar la situación: obtenemos con usted una visión general de todos los sitios y servidores y los clasificamos por urgencia: código malicioso entregado activamente, sospecha de salida de datos, probablemente solo sin parchear.
- Asegurar y cerrar: aseguramos cada sistema afectado antes de modificar nada y cerramos la puerta de entrada común: accesos, estado de PHP, reinicio de todos los procesos.
- Revisar y limpiar: buscamos de forma sistemática en todos los sitios los mismos rastros, eliminamos webshells y puertas traseras y restauramos con limpieza. Detalles en Eliminación de malware y webshells.
- Reforzar e informar: separamos los sitios entre sí donde tiene sentido y entregamos por cliente un breve informe que usted puede transmitir, además de un informe global para usted.
Trabajamos en remoto, sin desplazamientos, en toda Europa. Si lo desea, en segundo plano para su agencia, como se describe en la página Agencias y marca blanca.
Por qué en las agencias suelen caer muchos sitios a la vez
Quien aloja muchos proyectos en un servidor ahorra costes, pero cambia aislamiento por comodidad. Si todo se ejecuta bajo el mismo usuario y el mismo pool de procesos de PHP, el código de un sitio hackeado puede leer y modificar los archivos de los vecinos. No es un caso exótico, sino el estándar en muchas configuraciones. Cómo separar bien los pools lo describe Aislar los pools de PHP-FPM.
A ello se suman los accesos compartidos: una clave SSH para todos los proyectos, una cuenta de hosting con todos los dominios, las mismas contraseñas para staging y producción. Aquí rige el principio de mínimo privilegio. Más información en Permisos del usuario del servidor web.
También cuenta la cadena de suministro: plugins, temas y bibliotecas proceden de terceros, el proveedor de hosting responde de la plataforma y la agencia de la operación. Dónde están esos límites y dónde surgen lagunas lo trata Cadena de suministro: agencia y proveedor de hosting.
Inventario, versiones de PHP y comunicación con los clientes
El problema más frecuente en estas situaciones es la falta de visión de conjunto: ¿qué sitio se ejecuta en qué servidor con qué versión de PHP y quién es responsable? Sin esa lista no se puede decir quién está afectado por el parche y quién no. Cómo montar un directorio así lo muestra Inventario de sitios web y servidores. Si se ejecutan varias versiones de PHP en paralelo, ayuda además Varias versiones de PHP en un servidor.
De cara a los clientes cuenta la claridad. No tiene que saberlo todo, pero no debe embellecer nada: ¿qué está demostrado, qué se está revisando todavía, qué hará a continuación? Encontrará ayudas de redacción en Informar a los clientes tras un incidente. Si hay datos personales afectados, pueden entrar en juego obligaciones de notificación según el art. 33 del RGPD. Es una información general; la valoración corresponde a los delegados de protección de datos y al abogado. Si el incidente va más allá de sitios individuales, pasamos a una respuesta a incidentes estructurada.
Qué debería enviarnos
- una lista de los dominios afectados y de los probablemente afectados
- datos sobre servidor y hosting de cada proyecto, en la medida en que se conozcan
- versiones de PHP y CMS o tiendas utilizados
- los accesos que pueda concedernos y los roles en el equipo
- indicaciones sobre lo último que se cambió o se desplegó
- nombre del interlocutor para las decisiones y para la comunicación con los clientes
Por qué PHP SOS
Trabajamos Made in Germany y llevamos más de 25 años especializados en seguridad informática junto con nuestra red de socios, profesionales de la ciberseguridad. Usted tiene un único interlocutor para todos los proyectos afectados, trabajamos en remoto y documentamos por sistema lo que se encontró y se hizo. No prometemos milagros. Lo que no puede demostrarse lo llamamos desconocido, para que ante sus clientes no diga más de lo que sabe.
¿Le afecta? Llame. Le ayudamos.
Si varios sitios de sus clientes muestran anomalías, la presión de tiempo es doble: técnica y en la relación con sus clientes. Póngase en contacto ahora: llame o escriba por WhatsApp. Nos hacemos cargo desde el primer mensaje y seguimos hasta que el incidente esté cerrado y documentado. Comunicar la emergencia ahora
Preguntas frecuentes
¿Por qué suelen estar afectados varios sitios de clientes a la vez?
Con frecuencia los sitios comparten un servidor, una cuenta de hosting, el mismo proceso de PHP o las mismas credenciales. Si un atacante entra en un punto, puede moverse lateralmente. Además, un PHP vulnerable afecta a todos los sitios que lo utilizan.
¿Debo informar de inmediato a los clientes?
Depende de la situación y del contrato. Aclare primero qué sitios están realmente afectados, para no informar con suposiciones. Si hay datos personales, son posibles obligaciones de notificación; la valoración corresponde a los delegados de protección de datos o al abogado.
¿Quién responde si el sitio de un cliente ha sido hackeado?
Depende de sus contratos, del alcance del mantenimiento y del desarrollo de los hechos. No prestamos asesoramiento jurídico al respecto. Un informe limpio sobre la causa y las medidas ayuda a aclararlo.
¿Pueden trabajar bajo nuestro nombre sin que el cliente final nos vea?
Si lo desea, trabajamos en segundo plano para su agencia y entregamos informes que usted puede transmitir a sus clientes. Hablamos de los detalles de antemano.
¿Basta con limpiar los sitios de los clientes uno por uno?
Por lo general no. Si la causa está en el servidor compartido, en un acceso compartido o en una versión de PHP sin parchear, los problemas reaparecen tras la limpieza individual. La causa debe resolverse también.