¿Su sitio está bajo ataque? Qué hacer en la primera hora

Primero: confirme que es un ataque

Un ataque y una avería se parecen desde afuera —el sitio no responde— y se distinguen desde adentro. Antes de tocar nada, mire el patrón del tráfico en el panel de su proveedor de red o en los registros del servidor. Un ataque suele dejar una firma reconocible: el volumen se dispara sin que haya una campaña, una promoción o una nota de prensa que lo explique; las peticiones se concentran en pocas URLs, casi siempre el formulario de acceso, el buscador interno o una API pública; llegan desde regiones donde usted no tiene clientes; y el servidor se degrada de forma creciente en lugar de caerse de golpe.

Una avería, en cambio, tiende a ser abrupta y pareja: falla todo a la vez, sin que el tráfico haya cambiado. Distinguir una cosa de la otra en los primeros minutos evita la peor pérdida de tiempo posible, que es reparar lo que no está roto.

Qué hacer en los primeros minutos

El orden importa más que la velocidad. Estos cuatro pasos se pueden dar en paralelo si hay más de una persona, pero ninguno debe saltarse.

Active el modo de protección de su proveedor de red. Si su sitio está detrás de una red de distribución de contenido o de un servicio de protección, casi todos ofrecen un modo reforzado que exige verificación al visitante antes de dejar pasar la petición. Es la medida que más tráfico automatizado detiene con menos riesgo para el visitante legítimo.

No reinicie el servidor. Es lo primero que pide el instinto y es lo que menos ayuda. Si el ataque satura la capacidad antes de llegar a su aplicación, reiniciar solo añade el tiempo de arranque a la interrupción; y en cualquier caso borra memoria, conexiones y a veces registros que después harían falta para entender qué ocurrió y demostrar qué se hizo.

Preserve la evidencia. Guarde los registros del servidor y de la red desde antes de que empezara el incidente. Es lo que permite reconstruir el ataque, ajustar las reglas para que no vuelva a pasar y, si el caso lo requiere, sostener una denuncia. Los registros suelen rotarse solos: si nadie los aparta, en unas horas ya no están.

Avise a quien atiende clientes. Ventas y soporte van a recibir las llamadas antes que usted. Una frase acordada —qué se sabe, qué se está haciendo, cuándo habrá noticias— evita que cada persona improvise la suya.

Las medidas por tipo de ataque

No todos los ataques se contienen igual, y aplicar la medida equivocada cuesta tiempo.

Denegación de servicio (DDoS). El objetivo es agotar su capacidad, no entrar. Se contiene aguas arriba, en la red que está delante de su infraestructura, no en su servidor: cualquier medida que tomen sus máquinas ya llega tarde, porque el tráfico ya las alcanzó. Si su sitio no está detrás de una red que absorba ese volumen, ponerlo detrás de una es la medida, y conviene hacerlo antes del próximo ataque, no durante.

Bots y prueba de credenciales. Aquí el volumen puede ser modesto y el daño mayor: alguien está probando usuarios y contraseñas filtradas contra su formulario de acceso. Las señales son intentos fallidos por encima de lo normal, muchos usuarios distintos desde pocas direcciones —o un usuario desde muchísimas—, y accesos exitosos desde geolocalizaciones que no encajan. La contención pasa por limitar la tasa de intentos, exigir verificación en el acceso y forzar el cambio de contraseña de las cuentas que ya hayan sido tomadas.

Ataques contra la aplicación. Inyección SQL, cross-site scripting, path traversal, intentos de ejecutar código. Son peticiones cuidadas, no masivas, y por eso pasan desapercibidas entre el tráfico normal. Se detienen con un cortafuegos de aplicaciones web con reglas ajustadas a lo que su aplicación hace de verdad; las reglas genéricas de fábrica o bloquean clientes legítimos o dejan pasar lo que importa.

Señales de que ya entraron. Si su aplicación empieza a generar tráfico saliente que antes no generaba —conexiones a direcciones desconocidas, transferencias grandes fuera de horario—, el problema ya no es el ataque: es el acceso que consiguió. Ahí la prioridad cambia por completo, de contener a aislar, y conviene involucrar a alguien con experiencia en respuesta a incidentes antes de seguir tocando el sistema.

Lo que conviene no hacer

Tres reacciones frecuentes que empeoran la situación:

Bloquear países enteros como primera medida. Reduce el ruido y da la sensación de estar haciendo algo, pero los ataques serios llegan distribuidos —incluido desde su propio país— y el bloqueo geográfico corta a clientes legítimos que viajan o usan una VPN. Sirve para ganar minutos mientras se prepara la medida real.

Subir la capacidad del servidor durante el ataque. Si el atacante puede generar más tráfico que su presupuesto, esta es una carrera que se pierde pagando. La capacidad se dimensiona para su negocio, no para quien lo ataca.

Cerrar el incidente cuando el tráfico baja. Que el ataque pare no significa que el problema esté resuelto. Si no se ajustó nada, lo único que cambió es que el atacante se cansó, y suele volver.

Cómo responde Lynxsource

Lynxsource implanta la protección sobre Cloudflare, vigila sus registros desde su Centro de Operaciones de Seguridad sobre Microsoft Sentinel las 24 horas y responde cuando ocurre un ataque, con equipo propio en Ecuador, Colombia, Bolivia, Estados Unidos y Canadá.

En la práctica, lo que cambia con un servicio gestionado es el reloj. Las alarmas entran al SOC y se clasifican y priorizan en menos de un minuto; un analista toma el caso que la inteligencia artificial marcó en cuatro minutos de media, contiene el ataque y después explica qué pasó, qué se hizo y qué conviene ajustar. La diferencia con un cortafuegos encendido y sin vigilar no está en la herramienta: está en que alguien esté mirando a las tres de la mañana.

Si quiere el detalle del servicio —qué cubre, sobre qué tecnología funciona y en qué se diferencia de activar un WAF por su cuenta—, está en la página de WAF y protección web gestionada. Y si lo que hay ahora mismo es un ataque en curso, el formulario de evaluación no es el camino: llame a los números que están en el pie de esta página.