Seguridad del sitio web: Cómo se hackean los sitios y cómo detenerlo

Por qué incluso los sitios pequeños son atacados

Comencemos con la creencia que escuchamos en casi cada primera reunión: "¿Quién se molestaría con nosotros? Tenemos cinco páginas y recibimos tres consultas a la semana." Suena razonable. También es exactamente por eso que sitios como ese son los que más a menudo son comprometidos.

Nadie te eligió. La abrumadora mayoría de los ataques contra pequeñas y medianas empresas no son personales en absoluto. El software hace el trabajo: toma listas de dominios y direcciones IP, las revisa una por una y prueba cada una por docenas de vulnerabilidades conocidas. El bot no tiene idea de si eres una clínica dental o un estudio de cerámica. Lee una cadena de versión en la respuesta del servidor, verifica su lista y sigue adelante si no hay coincidencia. Si hay una coincidencia, se pone a trabajar.

Es el equivalente a caminar por una calle probando las manijas de las puertas de los coches. Nadie eligió tu coche. El tuyo simplemente estaba desbloqueado.

Cuánto vale realmente un sitio web de folleto

Un atacante casi nunca quiere hacerte daño a ti específicamente. Un sitio comprometido tiene un valor de mercado, y proviene de varias cosas a la vez:

• Equidad de enlaces. Enlaces ocultos o secciones enteras ocultas sobre casinos, préstamos o farmacias se inyectan silenciosamente en tus páginas. No los ves. Los motores de búsqueda sí.
• Tráfico.Tus visitantes son redirigidos a otros lugares, pero no todos. A menudo solo los usuarios móviles, solo aquellos que llegan desde la búsqueda, y solo una vez al día por persona. Esa es precisamente la razón por la que puedes visitar tu propio sitio desde tu propio portátil durante meses y no notar nada.
• Recursos del servidor.Tu alojamiento se convierte en un nodo para enviar spam, minar o atacar otros sitios.
• Datos.Una base de datos de consultas, números de teléfono, direcciones y correos electrónicos es un producto con compradores. Incluso si todo lo que tienes es "solo un formulario de contacto".
• Extorsión.Los archivos se encriptan o se eliminan, y se te invita a pagar por su regreso.

Lo que lleva a la conclusión que cambia cómo se siente todo este tema: la seguridad del sitio web no se trata de defenderse contra un genio con capucha. Es higiene que te saca del grupo de objetivos fáciles. Un bot no gastará tiempo en un sitio bien cuidado mientras mil descuidados estén al lado.

Cómo los propietarios suelen enterarse

Los síntomas casi nunca provienen de ti. Tu anfitrión envía correos sobre actividad sospechosa. Google Search Console señala una advertencia. Un cliente llama para decir que su navegador les está gritando. El correo electrónico de la empresa de repente cae en la carpeta de spam de todos. El tráfico de búsqueda cae sin explicación. Si alguna de esas cosas ha sucedido, te enteraste tarde, pero tarde no es lo mismo que demasiado tarde.

Cómo los sitios realmente son comprometidos

Olvida las películas. En realidad, casi cada compromiso de pequeñas empresas se remonta a una lista corta y notablemente aburrida. Hemos limpiado docenas de sitios infectados, y el punto de entrada casi siempre fue uno de estos.

CMS desactualizado y plugins sobre todo

Este es el claro ganador. WordPress, Joomla, OpenCart: las plataformas en sí no son inherentemente vulnerables. El problema es el ecosistema: un plugin de galería actualizado por última vez en 2021, un tema comprado en un mercado cuyo autor se fue hace años, un módulo de formulario que un contratista instaló y olvidó.

Entiende la mecánica aquí, porque son contraintuitivas. Cuando se encuentra una vulnerabilidad en un plugin, se publica. Así es como funciona la industria, y es correcto. Pero a partir de ese momento comienza una carrera: el desarrollador envía una solución, y los bots de escaneo reciben la huella de la versión vulnerable en cuestión de horas. Un sitio que se actualiza una vez al año no está en esa carrera en absoluto.

Contraseñas débiles, y mucho peor, reutilizadas

Una contraseña como Admin2024! se siente fuerte: letra mayúscula, dígitos, un signo de exclamación. Está en todos los diccionarios de cracking. Pero ese no es el verdadero daño. El verdadero daño es la misma contraseña en tu panel de hosting, tu administrador de sitio, tu correo electrónico y algún servicio que fue vulnerado hace dos años. La filtración de otra persona se convierte en tu inicio de sesión, y técnicamente no ocurre ningún "hackeo" en absoluto. El atacante simplemente escribe un nombre de usuario y una contraseña.

Credenciales robadas de una laptop del personal

El clásico que nadie sospecha. Las credenciales FTP guardadas en un gestor de archivos en la laptop de un diseñador son leídas por malware común. El sitio es "hackeado" a través de un inicio de sesión legítimo. La señal reveladora: limpias todo a fondo y la infección regresa en dos días.

Formularios no protegidos y puntos finales abiertos

Cada lugar donde tu sitio acepta entradas del exterior — un formulario de contacto, búsqueda en el sitio, una carga de archivos, un punto final de API — es una puerta. Cuando se acepta la entrada sin verificar su tipo, tamaño y contenido, la puerta funciona en ambas direcciones. La carga de archivos merece un miedo especial: permitir que alguien coloque algo en tu servidor que el servidor ejecute más tarde es esencialmente entregar las llaves.

Archivos dejados en la raíz web

El asesino silencioso, y lo encontramos constantemente. Viviendo en la carpeta pública: backup.zip de la agencia anterior, dump.sql con la base de datos completa, un .git carpeta que contiene todo el historial del proyecto con contraseñas en commits antiguos, un test.php, un info.php, una copia de configuración llamada config.php.bak. Cada uno de esos es descargable por cualquiera que adivine la URL. Y los bots no adivinan: llevan listas de los nombres habituales y los verifican en segundos.

Una palabra específicamente sobre .bak y .viejo extensiones: el servidor no las ejecuta como código, las sirve como texto plano. Lo que significa que entrega tu contraseña de base de datos directamente al navegador.

Proyectos Olvidados y Abandonados

Una antigua página de destino de campaña en un subdominio. Una copia de staging construida hace dos años y nunca eliminada. Un foro que nadie usa. Nunca se actualizan porque nadie recuerda que existen. Y generalmente permanecen en la misma cuenta de hosting, por lo que comprometer una página de destino olvidada entrega los archivos de tu sitio principal. Abrimos cada auditoría con "¿qué más vive en esta cuenta?", y la respuesta sorprende regularmente al propietario más que a nadie.

HTTPS y SSL: Ya no es un tema de debate

Si no tienes HTTPS, deja de leer y soluciona eso primero. En 2026, un sitio sin cifrado no es económico. Es un fallo.

Lo que Realmente Hace un Certificado SSL

Sin HTTPS, los datos viajan entre el navegador de tu visitante y tu servidor en texto plano. Cualquiera posicionado a lo largo de ese camino puede leerlo y cambiarlo: el propietario del Wi-Fi del café, un ISP, equipos en una red intermedia. Leerlo significa leer contraseñas y contenidos de formularios. Cambiarlo significa que pueden reescribir tu página o inyectar sus propios anuncios en ella, y tu visitante estará seguro de que provino de ti.

Un certificado SSL resuelve dos problemas a la vez. Cifra el canal y prueba que el dominio pertenece a quien lo está sirviendo. Lo segundo es tan importante como lo primero: sin identidad, el cifrado no tiene sentido, porque podrías estar cifrando un canal hacia un estafador.

Los Detalles que Importan Más que el Certificado en Sí

Los certificados son gratuitos y automáticos ahora: Let's Encrypt resolvió esa cuestión para todos. Así que los errores ya no son sobre "tener uno o no". Están en la configuración:

• Redirecciones. Cada solicitud HTTP debe redirigir permanentemente a HTTPS. De lo contrario, la versión antigua simplemente sigue funcionando junto a la nueva.
• Contenido mixto. La página se carga a través de HTTPS pero carga una imagen, fuente o script a través de HTTP. El navegador se queja y el candado desaparece. Los fragmentos de análisis antiguos y los widgets de terceros son los culpables habituales.
• Renovación automática. Los certificados tienen una vida corta y son renovados por un robot. Cuando el robot falla, lo escucharás de los clientes en el peor día posible. Monitorea la fecha de caducidad.
• URLs canónicas. Después de pasar a HTTPS, asegúrate de que cada página tenga una dirección en lugar de cuatro variaciones con y sin www.

Lo que HTTPS no hace

Aquí vive una peligrosa idea errónea. El candado no significa que el sitio sea seguro. Significa exactamente una cosa: el canal hacia el servidor está cifrado. Un sitio comprometido lleno de código malicioso funciona felizmente a través de HTTPS con el candado intacto. Los sitios de phishing también tienen certificados: se emiten de forma gratuita y automática a todos. HTTPS es una base, no un techo.

Para los sitios que manejan dinero, la barra es mucho más alta. El cifrado del canal es el boleto de entrada; después vienen la verificación de la firma del webhook, las operaciones idempotentes y la estricta separación de accesos. Pasamos por esa maquinaria en detalle usando la pasarela de pago Payora, donde la seguridad de la transacción supera a cualquier otra característica en la construcción.

Encabezados de Seguridad: La Defensa Silenciosa Que Nadie Activa

Los encabezados de seguridad son instrucciones que tu servidor envía al navegador junto con la página. El punto es que los navegadores son confiables por defecto: ejecutarán cualquier script que encuentren en tu página y mostrarán tu página dentro de la ventana de otra persona si se les pide. Los encabezados son cómo le dices al navegador: "no hagas eso conmigo."

Su gran virtud es que son gratuitos, se configuran una vez y se aplican del lado del visitante sin cargar tu servidor. Su gran problema es que están ausentes por defecto en casi todas partes.

Política de Seguridad de Contenidos (CSP)

El más poderoso y el más temperamental. Es una lista de permitidos: de dónde esta página puede cargar scripts, estilos, imágenes y fuentes. Si un atacante logra inyectar un script extranjero en tu página, el navegador simplemente se niega a ejecutarlo, porque la fuente no está en la lista. En efecto, CSP convierte un compromiso exitoso en uno fallido.

Una advertencia honesta: apresurar CSP romperá tu sitio. El camino correcto es primero el modo solo de informe, recopilar las violaciones y luego ajustar. En un sitio con una docena de widgets de terceros, eso son varios días de trabajo, no diez minutos.

Strict-Transport-Security (HSTS)

Le dice al navegador: este dominio es solo HTTPS, recuérdalo durante un año. Cierra la brecha entre alguien que escribe una dirección sin un prefijo y el redireccionamiento que se activa. Esa brecha es precisamente donde ocurre la interceptación. Solo habilítalo una vez que estés seguro de que HTTPS funciona en todas partes y de forma permanente; revertir la decisión es lento.

X-Frame-Options

Evita que tu sitio sea incrustado en un marco en la página de otra persona. Defiende contra un truco simple y desagradable: una capa invisible colocada sobre tu verdadero botón, de modo que el clic del usuario vaya a un lugar donde nunca pretendió. Para cualquier sitio con una cuenta de cliente o un proceso de pago, este es obligatorio.

X-Content-Type-Options

Una línea, sin configuración. Prohíbe al navegador adivinar el tipo de un archivo en contra de lo que el servidor declaró. Sin esto, una imagen subida puede, bajo las condiciones adecuadas, ser interpretada como un script y ejecutada.

Referrer-Policy

Controla qué información sobre tu sitio el navegador transmite cuando un visitante hace clic en otro lugar. Sin esto, la URL completa de la página —incluyendo parámetros como un token de restablecimiento de contraseña o un identificador interno— viaja a la analítica de otra persona. Eso no es un hack. Es una fuga: silenciosa y continua.

Permissions-Policy

Desactiva lo que tu sitio claramente no necesita: cámara, micrófono, geolocalización, sensores. La regla es simple: cualquier cosa no utilizada debe estar apagada.

Cualquier escáner público en línea calificará tus encabezados en un minuto, y el resultado suele ser desalentador. Para nosotros, los encabezados son parte de la construcción base en cada proyecto — parte del desarrollo en sí mismo, no un extra pagado añadido después.

Actualizaciones y Código de Terceros: Disciplina Sobre Heroísmo

El consejo es aburrido: mantén las cosas actualizadas. El problema es que es el único consejo que todos han escuchado y casi nadie sigue. Veamos por qué — y cómo hacerlo efectivo.

Por qué se posponen las actualizaciones

No es pereza. Es miedo. Una actualización rompió una vez el diseño, o el carrito dejó de funcionar, y desde entonces se ha evitado el botón de "actualizar". El miedo es racional: las actualizaciones realmente pueden romper cosas, especialmente cuando un sitio está ensamblado a partir de plugins que fueron modificados directamente en su fuente.

Pero haz las cuentas. El riesgo de un diseño roto te cuesta una hora. El riesgo de un compromiso te cuesta una restauración, una limpieza, conversaciones incómodas con los clientes y meses recuperando posiciones en los motores de búsqueda. El segundo riesgo es un orden de magnitud más costoso.

Cómo actualizar sin pánico

1. Haz una copia de seguridad antes, no después.Copia de seguridad completa: archivos y base de datos. Nunca omitas este paso, sin excepciones.
2. Mantén una copia de staging.Un entorno separado, cerrado a motores de búsqueda y externos, donde se prueban las actualizaciones antes de que se publiquen. En cualquier proyecto serio, esto no es opcional.
3. Separa lo crítico de lo rutinario.Las actualizaciones de seguridad se aplican de inmediato. Las menores en un horario. Los saltos de versión importantes son su propio proyecto con un plan.
4. Revisa las cosas importantes después.Envía un formulario, realiza un pago, inicia sesión en una cuenta, míralo en un teléfono. Tres minutos de revisión manual ahorran semanas.

Auditoría del código de otras personas

Una vez al trimestre, abre tu lista de plugins y haz dos preguntas. Primero: ¿se utiliza esto en absoluto? Un plugin instalado "solo por si acaso" es un agujero sin función. Y ten en cuenta que un plugin desactivado aún se encuentra en el sistema de archivos y puede seguir siendo vulnerable, por lo que las cosas no utilizadas deben ser eliminadas, no apagadas.

Segundo: ¿está vivo el autor? Si la última actualización fue hace tres años y la descripción dice que es compatible con una versión que está obsoleta desde hace tiempo, ese es un código abandonado. No se volverá más seguro por sí solo. Encuentra un reemplazo con calma, por adelantado, en lugar de la noche después de un compromiso.

Y la regla que vale la pena enmarcar en la pared: cuanto menos código de terceros en tu sitio, menor será tu superficie de ataque. Cada plugin es un extraño al que has concedido silenciosamente acceso a tu servidor.

Higiene de Acceso y Alojamiento: Ganancias Más Grandes Que el Código

La causa más común de un compromiso en el mundo real no es un exploit ingenioso. Es el acceso disperso. Aquí es también donde el orden se restaura más rápido y casi sin costo.

Menor Privilegio

Cada persona y cada proceso debe tener exactamente los derechos que su trabajo requiere y no un ápice más. Un gestor de contenido no necesita derechos de administrador; necesita publicar artículos. Un contratista que edita una página no necesita la base de datos. Un script que lee un catálogo no necesita acceso de escritura.

Abre tu lista de usuarios administradores ahora mismo. En auditorías, encontramos rutinariamente cuentas activas pertenecientes a personas que se han ido, a una agencia con la que te separaste hace un año, y a un usuario misterioso llamado admin2 que nadie puede justificar. Ese último no es un descuido: es un síntoma.

Una Cuenta Por Persona

Una compartida admin iniciar sesión con la contraseña que está en un hilo de chat significa que nadie es responsable. Cuando algo sucede, el registro dice "admin inició sesión", lo que no te dice nada preciso. Las cuentas individuales te ofrecen dos cosas: un historial legible de quién hizo qué, y la capacidad de revocar el acceso de una persona sin cambiar las contraseñas de toda la empresa.

Autenticación de Dos Factores

Si implementas exactamente un elemento de todo este artículo, que sea este. 2FA hace que una contraseña robada no valga nada. Cada intento de fuerza bruta y cada violación de terceros deja de funcionar en tu contra, porque la contraseña sola ya no es suficiente. Actívalo en todas partes donde exista: panel de hosting, registrador de dominios, administrador del sitio, correo electrónico, Cloudflare, GitHub.

Una palabra especial sobre el registrador de dominios. Es el punto de falla más subestimado en toda la pila. Perder el control de tu dominio es peor que perder tu sitio: un sitio se restaura desde una copia de seguridad en una hora, mientras que un dominio puede tardar meses en recuperarse a través de tickets de soporte — si es que se recupera.

Claves SSH en lugar de Contraseñas, y No FTP

Una contraseña puede ser adivinada o robada de una laptop. Una clave no puede ser adivinada en un marco de tiempo útil. La configuración toma quince minutos una vez, después de lo cual el inicio de sesión con contraseña en el servidor se desactiva por completo.

Por separado: deja de usar FTP simple. Envía tu nombre de usuario y contraseña en texto claro, como si fuera 1998. Usa SFTP o SSH solamente. Si tu proveedor ofrece FTP como el método principal, eso te dice algo sobre el proveedor.

Un Gestor de Contraseñas en lugar de Memoria

Ningún humano puede recordar cuarenta contraseñas complejas distintas, que es exactamente por qué las reutilizan. Un gestor de contraseñas elimina el problema por completo: genera una contraseña única por servicio, las almacena encriptadas y te permite entregar credenciales a un colega sin pegarlas en un mensajero. Cuesta una miseria y previene una catástrofe.

Formularios, Spam y Limitación de Tasa

El formulario de contacto es la parte más accesible de tu sitio web. Está abierto a todos, funciona sin iniciar sesión y está ahí esperando datos. No es de extrañar que reciba el mayor abuso.

Por qué CAPTCHA no es la respuesta

CAPTCHA atrapa scripts primitivos y molesta a los humanos reales. El tráfico de spam moderno lo supera ya sea técnicamente o a través de servicios de resolución donde personas reales responden captchas por fracciones de centavo. Mientras tanto, afecta de manera medible la conversión: algunos clientes genuinos simplemente se rinden ante las letras distorsionadas y se van.

El enfoque que funciona es en capas e invisible para el visitante:

• Honeypot. Un campo oculto que un humano nunca ve ni llena, y un bot llena automáticamente. Lleno significa descartado. Simple, gratuito, efectivo contra la mayor parte de ello.
• Comprobaciones de tiempo. Un formulario enviado medio segundo después de que se cargó la página no fue llenado por una persona.
• Limitación de tasa.No más de unas pocas presentaciones desde una dirección en un período determinado. Este es el mecanismo clave, y el mismo protege tu página de inicio de sesión de intentos de adivinación de contraseñas.
• Puntuación invisible.Los sistemas modernos evalúan el comportamiento y solo desafían las solicitudes que parecen sospechosas. Un cliente real no ve nada en absoluto.

La validación del lado del servidor es innegociable

La validación elegante de campos en el navegador es una conveniencia para los usuarios, no una defensa. Los datos que llegan a tu servidor pueden ser enviados sin tocar nunca tu página. Así que todo se verifica nuevamente del lado del servidor: tipo, longitud, formato, valores permitidos. La regla es simple y universal: la entrada del mundo exterior nunca es confiable, incluso si tu propio script la validó hace un momento.

Las cargas de archivos son su propio problema

Si un visitante puede cargar un archivo, compórtate como si estuviera subiendo algo hostil. Verifica el tipo de contenido real, no la extensión en el nombre. Cambia el nombre del archivo tú mismo. Limita el tamaño. Y lo más importante, almacena las cargas en un lugar donde el servidor físicamente no ejecute código, idealmente en un almacenamiento completamente separado.

La limitación de tasa va más allá de los formularios

El mismo mecanismo pertenece a tus puntos finales de API, búsqueda en el sitio, restablecimiento de contraseña y cualquier operación costosa. Sin él, un bot persistente puede derribar tu servidor a través de pura repetición. Es más importante donde hay dinero involucrado: en proyectos de pago siempre limitamos la velocidad a la que se pueden crear transacciones — nuestro artículo sobre la aceptación de pagos en criptomonedas explica por qué eso protege tu contabilidad tanto como tu servidor.

Copias de Seguridad: La Única Póliza de Seguro Que Siempre Paga

En términos simples: las copias de seguridad importan más que cualquier otra cosa en este artículo. Cada otra medida reduce la probabilidad de un desastre. Las copias de seguridad deciden cómo termina el desastre: una noche desagradable o un negocio cerrado.

La regla 3-2-1

Un clásico inventado mucho antes que nosotros y aún imbatido:

• 3 copias de tus datos: la activa y dos copias de seguridad.
• 2 medios o plataformas diferentes — no pongas todo en una sola canasta.
• 1 copia fuera del sitio, físicamente y administrativamente separada del servidor.

Ese último punto es donde la mayoría de las configuraciones colapsan. Una copia de seguridad en el mismo servidor, o en la misma cuenta de hosting, no es una copia de seguridad. Un atacante que entra la elimina primero — es un paso estándar, no un adorno. El ransomware la encripta junto con todo lo demás. Y si el host muere, también muere.

Una copia de seguridad no probada no es una copia de seguridad

Aquí está la parte que duele. Seguimos viendo la misma escena: las copias de seguridad se ejecutaron fielmente durante dos años, y el día que importa, los archivos resultan estar corruptos. O contienen archivos pero no la base de datos. O la base de datos está ahí, pero la exportación dañó la codificación y el texto son signos de interrogación. O el archivo tiene 40 kilobytes porque el script falló en la primera carpeta y el correo de error fue a una bandeja de entrada que nadie lee.

La conclusión: las restauraciones deben ser ensayadas. Una vez por trimestre, despliega una copia en un entorno de pruebas y mírala. ¿Carga el sitio? ¿Está la base de datos? ¿Están las imágenes presentes? ¿Aparecen los pedidos? Es la única manera de conocer la verdad sobre tus copias de seguridad por adelantado en lugar de durante una catástrofe.

La retención supera la frecuencia

Una copia de seguridad diaria con tres días de retención es inútil contra una infección silenciosa. El código malicioso a menudo permanece inactivo durante meses. Para cuando lo encuentres, las tres copias ya están infectadas. Mantén la profundidad: diaria durante dos semanas, semanal durante un par de meses, mensual durante un año. El espacio en disco es incomparablemente más barato que un sitio del que no hay nada que restaurar.

Qué respaldar

Los archivos y la base de datos son obvios. Lo que se olvida es todo lo demás: configuración del servidor, reglas del servidor web, trabajos programados, configuraciones de DNS, correo electrónico. Un buen indicador es la pregunta: "si la empresa de hosting desapareciera mañana, ¿cuánto tiempo llevaría una reconstrucción completa en otro lugar?" Si no tienes una respuesta, tu copia de seguridad es incompleta.

Monitoreo y Registros: Velo Antes Que Su Cliente

Los compromisos rara vez son ruidosos. Con mucha más frecuencia son silenciosos, y ese es todo el punto: cuanto más tiempo no te des cuenta, más tiempo el activo genera dinero para quien lo tomó. Así que la tarea de monitoreo no es "atrapar a un hacker". Es acortar la brecha entre el evento y tu conocimiento sobre él.

El conjunto mínimo

• Monitoreo de tiempo de actividad.Una verificación de disponibilidad cada minuto con una alerta. Los servicios básicos son gratuitos y tardan diez minutos en configurarse.
• Monitoreo de integridad de archivos.El sistema registra el estado de tus archivos y te avisa cuando algo cambia. Nadie tocó el código, sin embargo, dos archivos cambiaron a las 3 a.m. — eso es una conversación.
• SSL y expiración de dominio.Alertas por adelantado, no después. Un dominio de renovación olvidado duele más que la mayoría de los hacks.
• Google Search Console.Gratis y obligatorio. Los motores de búsqueda a menudo detectan una infección antes que el propietario, y lo dirán claramente en la sección de seguridad.
• Escaneo externo de malware.Revisiones regulares desde el exterior capturan lo que solo un visitante ve: redirecciones, scripts inyectados, contenido intercambiado.

Registros: Aburridos, y Donde Vive la Verdad

Los registros del servidor web registran cada solicitud a su sitio. En un día tranquilo, nadie los quiere. En el día de un incidente, son su única fuente de hechos: cuándo, desde dónde, qué exactamente se solicitó y qué respondió el servidor.

Hay dos cosas que vale la pena hacer por adelantado, porque no se pueden hacer de forma retroactiva. Primero, confirme que los registros realmente se están escribiendo y guardando durante al menos un mes. En muchas configuraciones, se truncaron después de 24 horas, y no queda nada por investigar. Segundo, habilite el registro de inicio de sesión de administrador: exitoso y fallido. Un aumento en los fallos es un intento de adivinar la contraseña en tiempo real, y puede responder antes de que tenga éxito.

Qué Buscar

No necesitas ser un analista para notar lo obvio. Solicitudes de archivos que no tienes y nunca has tenido. Solicitudes de administrador a las 3 a.m. de un país donde no empleas a nadie. Una dirección haciendo cientos de solicitudes en un minuto. Un aumento de respuestas de error donde antes no había ninguna. Ninguno de estos es prueba por sí solo, pero cada uno es una razón para mirar más de cerca.

Incluimos monitoreo básico en cada proyecto que apoyamos después del lanzamiento — ejemplos de ese trabajo están en nuestro portafolio. La lección no es glamorosa: un sitio que nadie observa eventualmente producirá una sorpresa, y la sorpresa siempre cuesta más que la observación.

WAF y CDN: Lo Que Cloudflare Hace y No Hace

Cloudflare y servicios similares son una capa genuinamente útil, que es exactamente por qué hay tanta mitología a su alrededor. Seamos honestos sobre dónde está el valor y dónde comienza la ilusión.

Lo que son

Una CDN coloca una red de nodos en todo el mundo entre tu visitante y tu servidor. Los archivos estáticos se sirven desde el nodo más cercano — el sitio es más rápido y tu servidor se alivia. Un WAF (firewall de aplicación web) es un filtro que inspecciona las solicitudes entrantes y descarta las que tienen forma de ataque antes de que lleguen a tu código.

El verdadero valor

• Absorbiendo DDoS.El tráfico basura se rompe contra la red del proveedor en lugar de tu servidor. Un pequeño negocio no sobrevivirá a ese ataque solo.
• Ocultando tu verdadera IP del servidor.Los ataques directos se vuelven más difíciles cuando el objetivo no es visible.
• Filtrado de bots.Una gran parte del ruido de escaneo se elimina automáticamente, y tus registros se vuelven legibles de la noche a la mañana.
• Parcheo virtual.Una regla de WAF puede mantener una vulnerabilidad reciente cerrada mientras preparas una actualización adecuada. Eso es tiempo prestado, no una solución.
• Velocidad.Un efecto secundario agradable que tanto los visitantes como los motores de búsqueda notan.

Lo que no harán

Ahora la parte incómoda. Un WAF no te salvará cuando:

• Tu contraseña fue robada. Un inicio de sesión con credenciales válidas es una solicitud legítima. El filtro la permite pasar, y está bien.
• Tu IP real ya es conocida y tu servidor acepta conexiones directamente, eludiendo el filtro. Esta es una mala configuración extremadamente común: tu servidor debe aceptar tráfico solo de la red del proveedor.
• La falla está en tu propia lógica de negocio. Si tu código permite que un usuario obtenga el pedido de otro usuario cambiando un número, eso es una solicitud perfectamente bien formada en lo que respecta al WAF.
• El código malicioso está ya dentro. El filtro vigila la puerta principal, no lo que sucede dentro de la casa.
• La encriptación está configurada en "flexible". Entonces, la conexión de Cloudflare a tu servidor viaja en texto claro mientras tu visitante ve un candado y asume que todo está bien. Esa es una imitación peligrosa de la seguridad: usa el modo estricto con validación de certificado.

En resumen: un WAF y un CDN son una excelente cerca perimetral. Una cerca es inútil cuando la llave está debajo de la alfombra y una ventana en la planta baja está abierta. Complementa la higiene. No la reemplaza.

Qué Hacer Si Ya Está Comprometido

Mantén la calma. El pánico cuesta más que el hackeo mismo: en un pánico, las personas eliminan las cosas que una investigación necesita. El procedimiento está bien establecido. Síguelo.

1. Aislar

Ponga el sitio detrás de una página de mantenimiento que devuelva un estado 503. Eso protege a los visitantes de infecciones y le dice a los motores de búsqueda que la interrupción es temporal en lugar de terminal. No elimine nada aún.

2. Preservar la Evidencia

Contrario a la intuición pero crítico. Tome una copia completa del sitio infectado más el último mes de registros antes de cualquier limpieza. Si restaura desde una copia de seguridad sin identificar el punto de entrada, volverá a estar comprometido de la misma manera, generalmente dentro de una semana. Esa copia es su única oportunidad de entender cómo entraron.

3. Rotar Cada Credencial

Todas, sin excepciones, sin "esa definitivamente no podría haber sido filtrada". Hosting, SSH, base de datos, cada usuario administrador, FTP, registrador de dominio, correo electrónico, servicios conectados. Active la autenticación de dos factores en todos los lugares donde faltaba mientras está allí. Una advertencia que la gente pasa por alto: haga esto desde una computadora limpia. Si la laptop está infectada, sus nuevas contraseñas se filtrarán exactamente como las antiguas.

4. Encontrar el Punto de Entrada

Comience con los archivos modificados en la fecha de infección: la pista más rápida que hay. Busque en los registros qué solicitud llegó poco antes de que apareciera el primer archivo extraño. Revise todo en la cuenta de hosting, incluidos los subdominios olvidados. Revise las computadoras de todos con acceso. Hasta que se encuentre el punto de entrada, el incidente no está cerrado.

5. Reconstruir

La mejor ruta es una reinstalación limpia: CMS fresco, plugins frescos de fuentes oficiales, y solo tu contenido y base de datos tomados de la copia de seguridad — con la base de datos revisada primero, porque el código también se inyecta allí, generalmente en plantillas y configuraciones. Limpiar manualmente archivos infectados es una lotería: si te pierdes un solo archivo, todo vuelve.

6. Cierra el agujero y recupera tu reputación

Arregla la causa que identificaste, o simplemente has reiniciado el reloj. Luego: solicita una revisión en Google Search Console, verifica los registros de correo de tu dominio (un sitio comprometido probablemente estaba enviando spam, y tu dominio puede que ya esté en listas de bloqueo), y confirma que no queden administradores desconocidos en la base de datos.

Una nota honesta: si tu sitio acepta pagos o almacena datos personales de clientes, improvisar es la decisión equivocada. Quieres a alguien que haya hecho esto antes — ponte en contacto. Manejamos incidentes como estos, y lo más importante, explicamos después exactamente qué salió mal y cómo asegurarnos de que no vuelva a ocurrir.

Una Lista de Verificación de Seguridad Práctica

Comprimamos todo lo anterior en una lista con la que puedes empezar hoy. Está ordenada por efecto relativo al esfuerzo — comienza desde arriba.

Hoy, en una tarde

1. Enciende 2FA para hosting, tu registrador de dominio, correo electrónico y el administrador del sitio.
2. Verifica HTTPS funciona en todas partes y todas las redirecciones HTTP a él.
3. Abre tu lista de usuarios administradores y elimina a todos los que no deberían estar allí: ex personal, antiguos contratistas, cuentas que nadie reconoce.
4. Revisa la raíz web en busca de archivos sueltos: archivos, volcado de bases de datos, un .git carpeta, copias de configuración, scripts de prueba.
5. Confirmar que existen copias de seguridad y no están almacenadas en el mismo servidor.
6. Conectar el sitio a Google Search Console y leer la sección de seguridad.

Esta semana

1. Configura un gestor de contraseñas y reemplaza cada contraseña reutilizada por una única.
2. Actualiza el CMS y todos los plugins, después de hacer una copia de seguridad completa.
3. Elimina plugins y temas no utilizados — elimina, no desactives.
4. Configura encabezados de seguridad: comience con X-Content-Type-Options, X-Frame-Options y Referrer-Policy, que son seguros para habilitar de inmediato.
5. Deshabilitar FTP y pasar a claves SSH.
6. Agregar monitoreo de tiempo de actividad y alertas para la expiración de SSL y dominio.
7. Limitar la tasa de intentos de inicio de sesión en el panel de administración.

Este mes

1. Prueba una restauración en un entorno de pruebas — desplégalo realmente y míralo.
2. Coloca un CDN y WAF delante, y cierra el acceso directo al servidor para que nada eluda el filtro.
3. Implementa CSP, comenzando en modo solo informe.
4. Audita todo en la cuenta de hosting: subdominios, copias de staging, páginas de aterrizaje olvidadas. Elimina lo que no se necesita.
5. Configura monitoreo de integridad de archivos.
6. Revisa permisos de archivos y carpetas, eliminando el acceso de escritura donde no sea necesario.

En Repetición, Para Que Nunca Necesites Este Artículo Nuevamente

• Semanal: actualizaciones de seguridad, una mirada al registro de inicio de sesión.
• Mensual: verifica copias de seguridad, revisa usuarios, revisa los registros.
• Trimestral: prueba la restauración, audita plugins, rota contraseñas de claves.
• Anual: auditoría completa, reconsidera quién tiene acceso y por qué.

Un último pensamiento para llevar contigo. La seguridad no es un estado que alcanzas y olvidas; es un hábito, como cerrar la puerta de la oficina. Nadie puede garantizar una protección absoluta, y cualquiera que lo prometa te está engañando. Pero la diferencia entre un sitio donde se realiza esta lista y un sitio donde no se hace nada es la diferencia entre "alguien lo intentó y no logró nada" y "estamos en la semana tres de la recuperación de nuestros datos".

Preguntas frecuentes