hosting compartido
6 artículos con esta etiqueta
Acceso no autorizado a algunos servidores web de ConoHa WING (GMO Internet) (426 cuentas): datos en las áreas de servidor web de los clientes afectados y qué deben hacer hoy los propietarios de sitios
El 20 de septiembre de 2026, GMO Internet, Inc. anunció que, en algunos servidores de alojamiento (servidores web) de su servicio de alojamiento de pago ConoHa WING, un tercero obtuvo acceso no autorizado a las áreas de servidor web de algunos clientes e instaló un programa malicioso. Están afectadas 426 cuentas, y los datos concernidos son «datos almacenados en las áreas de servidor web de los clientes». El acceso y la instalación comenzaron el 3 de septiembre; la empresa lo detectó el 16 de septiembre y, el 18 de septiembre, identificó la causa y el alcance y eliminó los programas. Afirma haber identificado la causa, pero no la ha revelado. Según la empresa, los datos de miembros, contratos y pagos se gestionan en un entorno separado y no se filtraron. El aviso no indica si se extrajeron datos de las áreas de servidor web. Los clientes afectados fueron contactados individualmente en la dirección de correo electrónico registrada; los clientes que no fueron contactados no están afectados. No había un aviso de seguimiento a 15 de octubre. La opinión de este sitio: primero compruebe si recibió un correo individual y, en ese caso, siga sus instrucciones. Después, considere que las credenciales guardadas en su área de servidor web (la contraseña de la base de datos en wp-config.php, las claves de API en .env, etc.) pueden haber sido leídas y cámbielas, y busque archivos, administradores y tareas programadas añadidos desde el 3 de septiembre.
Cómo saber si han hackeado tu sitio web o tu servidor: comprobaciones paso a paso para hosting compartido, WordPress y un VPS, y qué hacer primero si encuentras algo
Revisar un sitio en busca de intrusiones significa mirar tanto las señales visibles desde fuera como los rastros que quedan dentro. Señales: el informe de problemas de seguridad de Search Console, una etiqueta 'This site may be hacked' en los resultados de búsqueda, un aviso de tu hosting, administradores desconocidos, redirecciones que solo ocurren en el móvil o al llegar desde el buscador. Rastros: usuarios administradores, archivos del núcleo modificados (wp core verify-checksums), historial de inicios de sesión, authorized_keys, cron, puertos a la escucha, archivos cambiados recientemente. La opinión de este sitio: no encontrar nada no demuestra que estés limpio. Si encuentras algo, conserva las pruebas antes de limpiar, cambia todas las credenciales desde un dispositivo limpio, restaura una copia anterior a la intrusión o reconstruye, cierra la vía de entrada y solo entonces solicita una revisión.
Cuando tu proveedor de hosting web sufre una brecha: qué deben hacer los clientes
Un compromiso en el lado del proveedor no se puede bloquear con la configuración del cliente, así que la defensa pasa de la prevención a limitar cuánto puedes perder. Los resultados de la investigación del 10 de septiembre establecieron lo más importante: el acceso no autorizado al sistema de gestión comercial se produjo entre abril de 2023 y marzo de 2026; las cuentas de hosting afectadas pasaron de 583 a 951, y algunas contraseñas iniciales no tenían hash. La visión de este sitio: trata todo lo que hay en un hosting compartido como legible, saca los secretos, las credenciales y las copias de seguridad fuera del proveedor, y cambia hoy cualquier contraseña inicial que sigas usando.
¿Dejaste un archivo de secretos en un directorio público? Audita tu webroot
Cualquier cosa en tu webroot puede descargarse por URL por cualquiera. Un JSON de token/credenciales olvidado, un .env o una copia de seguridad significa exposición instantánea — y si vino de una plantilla compartida, todos los sitios tienen el mismo archivo. Solución: coloca en el directorio público solo cosas compartibles públicamente, mantén los secretos fuera del webroot con permisos 600, y una vez que encuentres uno, audita cada sitio y servidor.
Un caso en que el .env de Laravel era legible públicamente: un error de ubicación en hosting compartido y cómo corregirlo
La causa: toda la app estaba bajo la raíz web; solo public/ debería ser visible. Corrige en tres pasos — un bloqueo temporal con .htaccess, rotar claves, reestructurar — y luego prevenlo con proceso.
Mantener el .env fuera de la web pública en hosting compartido
La solución principal: el cuerpo de la app fuera del docroot, solo public/ expuesto. Bloquea primero el acceso con .htaccess, hazlo permanente reestructurando, luego autocomprueba. La visión de este sitio: esto no es el descuido de una persona sino un diseño peligroso que se volvió estándar en todo el sector — arréglalo con proceso, no con vigilancia. bootstrap-redirect vence al symlink.