Desde principios de a\u00f1o he empezado a notar un patr\u00f3n curioso. Cada semana hablo con agencias, freelancers o peque\u00f1as empresas que gestionan varios sitios web con otros proveedores de hosting. Muchos llegan despu\u00e9s de haber tenido el mismo problema con su hosting actual: una web se infecta, y poco despu\u00e9s el resto de las webs del servidor tambi\u00e9n.<\/p>\n\n\n\n
Empieza con un sitio comprometido, luego aparecen scripts sospechosos en otros proyectos, y en algunos casos, todo el entorno termina contaminado. La reacci\u00f3n suele ser la misma: frustraci\u00f3n, costes de limpieza, tiempo que tienen que invertir en un proceso que no es parte del n\u00facleo de su negocio, y la sensaci\u00f3n de que algo tan b\u00e1sico como la seguridad deber\u00eda estar mejor resuelto.<\/p>\n\n\n\n
Pero lo que muchas veces parece mala suerte no lo es. En muchos casos, es simplemente un problema de arquitectura. Entonces, \u00bfqu\u00e9 est\u00e1 pasando con todos estos proveedores?<\/p>\n\n\n\n
Cuando gestionas varios sitios web en un mismo servidor, es f\u00e1cil asumir que cada uno funciona de forma independiente, y en parte con raz\u00f3n. <\/p>\n\n\n\n
Hace casi 11 a\u00f1os, cuando hice mi primer entrenamiento para el equipo de soporte de SiteGround, nos explicaban el aislamiento de cuenta como un est\u00e1ndar de la empresa<\/strong>, y el ejemplo que usaban era \u201ces como el cintur\u00f3n de seguridad, no hay empresa automovil\u00edstica que lo ofrezca como algo excepcional, puesto que ya todos lo tienen\u201d. Y por muchos a\u00f1os parec\u00eda ser as\u00ed, sin embargo, en algunos entornos de hosting esa separaci\u00f3n no es tan real como parece<\/strong>.<\/p>\n\n\n\n Si el servidor no est\u00e1 dise\u00f1ado con aislamiento adecuado entre cuentas, un atacante que logra acceso a una web puede intentar moverse lateralmente dentro del sistema. Eso significa que desde un solo sitio comprometido se puede intentar:<\/p>\n\n\n\n Este fen\u00f3meno se conoce como contaminaci\u00f3n cruzada<\/strong> y es una de las causas m\u00e1s comunes de infecciones masivas en entornos de hosting compartido<\/strong>.<\/p>\n\n\n\n Muchos usuarios culpan directamente al CMS, los temas, plugins, pero la realidad es que, por ejemplo, WordPress alimenta m\u00e1s del 40% de la web, y su seguridad depende mucho del entorno donde se ejecuta<\/strong>.<\/p>\n\n\n\n Si la arquitectura del servidor no est\u00e1 dise\u00f1ada para aislar correctamente cada cuenta, una vulnerabilidad en un solo sitio puede convertirse r\u00e1pidamente en un problema para todos los dem\u00e1s. Por eso tantas agencias viven el mismo ciclo:<\/p>\n\n\n\n Detectar malware > Pagar una limpieza > El sitio vuelve a infectarse semanas despu\u00e9s<\/em><\/p>\n\n\n\n No porque hayan hecho algo mal, sino porque el entorno sigue teniendo la misma debilidad estructural<\/strong>.<\/p>\n\n\n\n Muchos proveedores de hosting ofrecen ayudas cuando el problema ya ocurri\u00f3<\/strong> y limpian archivos, restauran copias de seguridad<\/a>, y aunque esto es un proceso necesario, no es suficiente para una gesti\u00f3n profesional de m\u00faltiples webs. <\/p>\n\n\n\n La ciberseguridad<\/a> real empieza antes de que ocurra la infecci\u00f3n<\/strong>. En SiteGround<\/strong> dise\u00f1amos nuestra infraestructura con un enfoque diferente: dado que una web es como una casa (puedes tener la mejor seguridad, pero si dejas una ventana abierta alguien puede entrar), intentamos reducir al m\u00e1ximo la posibilidad de que una infecci\u00f3n se propague<\/strong> en los dem\u00e1s cuartos. Esto se consigue combinando varias capas de seguridad<\/strong>.<\/p>\n\n\n\n Tras m\u00e1s de una d\u00e9cada en SiteGround, si algo he comprobado es que la seguridad es el cimiento para nosotros. Nuestro sistema incorpora m\u00faltiples capas de protecci\u00f3n<\/a>:<\/p>\n\n\n\n Esta es la primera l\u00ednea de defensa. Nuestros servidores utilizan un entorno Apache chrooted con suEXEC<\/strong>, lo que significa que cada cuenta opera dentro de su propio entorno aislado<\/strong>. En lenguaje sencillo, esto evita que un sitio pueda acceder a los archivos o procesos de otro.<\/p>\n\n\n\n Cada cuenta vive en su propia burbuja blindada. B\u00e1sicamente, para cada usuario es como estar solo en el servidor, los dem\u00e1s sitios web se encuentran en un userspace completamente independiente. Esto garantiza que, aunque el sitio de al lado cometa un error y se infecte, el malware no tenga f\u00edsicamente forma de saltar a tus archivos o procesos.<\/p>\n\n\n\n Mucho antes de que la IA fuera el tema de conversaci\u00f3n global, nosotros ya la us\u00e1bamos para protegerte. Nuestros sistemas IDS\/IPS act\u00faan como un radar que identifica bots maliciosos y ataques<\/a> conocidos en milisegundos<\/strong>. <\/p>\n\n\n\n Lo que nos hace excepcionales es que nuestro equipo de administradores mitiga las amenazas de forma tan proactiva que, en la gran mayor\u00eda de los casos, el ataque se detiene incluso antes que el usuario pueda notar que su web se ha visto afectada<\/p>\n\n\n\n Tampoco nos conformamos con lo que viene de serie. Hemos desarrollado un m\u00f3dulo de seguridad interno basado en NGINX<\/strong> que analiza cada solicitud que intenta entrar en tu web. Al ser una tecnolog\u00eda propia y personalizada por nuestros expertos, el servidor no solo “ve” el tr\u00e1fico, sino que entiende y bloquea autom\u00e1ticamente patrones sospechosos que otros sistemas gen\u00e9ricos pasar\u00edan por alto.<\/p>\n\n\n\n Desarrollamos nuestras propias Reglas de Seguridad WAF (Web Application Firewall)<\/strong> y las actualizamos constantemente para proteger contra nuevas vulnerabilidades.<\/p>\n\n\n\n Es decir, no solo monitorizamos los servidores, sino que actualizamos nuestra WAF en tiempo real para bloquear desde las amenazas de siempre hasta los ataques m\u00e1s modernos<\/strong>, como los bots de IA<\/a> que rastrean la red buscando autom\u00e1ticamente cualquier punto d\u00e9bil en tu web.<\/p>\n\n\n\n El software desactualizado es la puerta abierta favorita de los hackers. Por eso, gestionamos actualizaciones autom\u00e1ticas de WordPress y sus plugins<\/strong> de forma inteligente. Adem\u00e1s, nuestros servidores siempre ejecutan las versiones m\u00e1s recientes y estables de PHP<\/a>. Al mantener cada pieza del engranaje al d\u00eda, minimizamos dr\u00e1sticamente la superficie de ataque de tu web sin que t\u00fa tengas que mover un dedo.<\/p>\n\n\n\n La tecnolog\u00eda es vital, pero el factor humano es lo que nos hace l\u00edderes, y yo lo s\u00e9 bien, ya que pas\u00e9 10 a\u00f1os en atenci\u00f3n al cliente<\/a>.<\/p>\n\n\n\n Tenemos un equipo de expertos dedicado exclusivamente a monitorizar nuestra infraestructura las 24 horas del d\u00eda<\/strong>, los 365 d\u00edas del a\u00f1o. Si surge una nueva vulnerabilidad global a las 3 de la ma\u00f1ana, nuestro equipo ya est\u00e1 aplicando reglas de seguridad antes de que te despiertes. Para nosotros, la seguridad no es un proceso automatizado que se deja solo, es un compromiso constante.<\/p>\n\n\n [86]<\/p>\n\n\n\n No existe plataforma 100% invulnerable, pero s\u00ed existen arquitecturas dise\u00f1adas para que un incidente aislado no se convierta en un desastre para todos los sitios del servidor.<\/p>\n\n\n\n La diferencia entre limpiar infecciones constantemente y evitarlas muchas veces est\u00e1 en algo que no se ve: c\u00f3mo est\u00e1 construido el entorno de hosting por dentro. Si gestionas varios sitios web, la pregunta importante no es solo qu\u00e9 ocurre cuando un sitio se infecta. La pregunta clave es: \u00bfPuede esa infecci\u00f3n propagarse al resto de tus proyectos?<\/strong><\/p>\n\n\n\n Si la respuesta es s\u00ed, probablemente el problema no est\u00e9 en tus webs, sino en una configuraci\u00f3n inadecuada del hosting, que no ofrece un aislamiento de cuentas que deber\u00eda ser un est\u00e1ndar en la industria.<\/p>\n\n\n\n En SiteGround, desde 2014 hemos migrado nuestra infraestructura de servidores dedicados a arquitectura Cloud. En 2019, pasamos de usar cPanel a panel propio<\/a>. Luego, en 2020, pasamos todo a la infraestructura de Google Cloud<\/a>. En todos estos a\u00f1os y con todas estas evoluciones<\/strong>, dando servicio a m\u00e1s de 4 millones de dominios<\/strong>, habiendo atendido miles de casos personalmente<\/strong>, pese a que alguna web haya podido dejar una ventana abierta en alg\u00fan momento, no he visto ni un solo caso de contaminaci\u00f3n cruzada en nuestros clientes<\/strong>.<\/p>\n\n\n\n\n
El problema puede estar en el entorno elegido<\/h3>\n\n\n\n
Seguridad reactiva vs seguridad preventiva<\/h3>\n\n\n\n
<\/span>C\u00f3mo protegemos las cuentas en nuestros servidores<\/span><\/h2>\n\n\n\n
Aislamiento de cuentas<\/h3>\n\n\n\n
Detecci\u00f3n y bloqueo de ataques<\/h3>\n\n\n\n
Protecci\u00f3n a nivel de servidor<\/h3>\n\n\n\n
Firewall de aplicaciones web<\/h3>\n\n\n\n
Actualizaciones y mantenimiento continuo<\/h3>\n\n\n\n
Monitorizaci\u00f3n activa de vulnerabilidades<\/h3>\n\n\n\n
<\/span>La diferencia est\u00e1 en prevenir el problema<\/span><\/h2>\n\n\n\n
<\/p>\n\n\n\n