Una alerta avisó de que un servidor web tenía unas 500 conexiones a medias, abiertas y sin terminar, sostenidas desde la noche anterior. El resto de servidores vigilados estaban a cero. Era un ataque pequeño pero constante contra la plataforma de votaciones de un cliente. Se resolvió en quince minutos de trabajo, y la parte interesante no es el ataque: es por qué esos quince minutos no empezaron antes.
Contamos el caso entero, con los números reales, porque explica mejor que cualquier argumento qué se compra cuando se contrata vigilancia.
Qué vimos
El cliente es una empresa de voto electrónico para asambleas y elecciones. Cuando hay una votación abierta, su web no puede fallar: cada persona que no consigue entrar es un voto que no se emite.
La alerta decía que el servidor web acumulaba conexiones en un estado intermedio, de esas que se abren y nunca se completan. Unas 500 a la vez, sin bajar. En el resto de máquinas vigiladas, cero.
Es el patrón clásico de un ataque de agotamiento: en vez de tumbar el servidor con un aluvión enorme, alguien abre miles de conexiones a medias y las deja colgadas, ocupando sitio en la cola hasta que no queda hueco para la gente de verdad.
Por qué no se cayó
El servidor tenía activada una defensa del propio sistema operativo que le permite seguir atendiendo aunque esa cola se llene. Por eso aguantó toda la noche sin que nadie notara nada.
Esa es la primera lección, y conviene no exagerarla: no pasó nada porque la máquina estaba bien configurada de antemano. No porque tuviéramos suerte.
Pero tampoco era para quedarse mirando. Era un ataque pequeño y sostenido, de los que suelen ser una prueba antes de ir a más. Con la cola llena, los votantes habrían empezado a ver errores o esperas justo durante una votación. Y hay un efecto secundario que casi nadie tiene en cuenta: una alerta encendida todo el día acaba tapando a las demás.
Cómo supimos que no era tráfico real
Antes de tocar nada hay que estar seguro, y para eso están los datos. Tres comprobaciones, en este orden:
- Todo venía del mismo sitio. Un único bloque de direcciones, el 179.51.184.0/22, repartiendo sus conexiones a partes iguales entre los dos puertos de la web.
- Nadie completaba la conexión. En veinte segundos entraron 207 peticiones y ninguna llegó a establecerse.
- Ninguna repetía origen. Un navegador real que no consigue conectar lo vuelve a intentar desde el mismo sitio. Aquí cada intento venía de un puerto distinto, que es la firma de las peticiones falsificadas.
Y el remate: ninguna de esas conexiones había aparecido jamás en el registro del servidor web. Ni ese día ni los anteriores. Tráfico que llama a la puerta miles de veces y nunca entra no es tráfico de nadie que quiera algo de la web.
La parte que explica el retraso
Con el análisis hecho, bloquear ese bloque de direcciones es cuestión de un minuto. No lo hicimos inmediatamente, y fue a propósito.
En una plataforma de votaciones, bloquear por error un rango legítimo significa dejar sin votar a personas reales, en un proceso con fecha y hora de cierre. Así que antes de cortar hicimos dos cosas: comprobar que desde ese bloque no se había votado nunca, y preguntar al cliente si ese tráfico era suyo, por ejemplo una prueba de carga de su equipo.
Hasta que el cliente confirmó que no era suyo, no se bloqueó nada. Eso es lo que separa las 21:30 del aviso de las 13:00 del día siguiente, y no es tiempo perdido: es el tiempo de asegurarse de que la solución no causa más daño que el problema.
En un servicio donde cada usuario cuenta, bloquear a ciegas puede salir más caro que el ataque.
Quince minutos
Con la confirmación del cliente, el resto fue rápido. Se bloqueó el bloque en el cortafuegos perimetral y se eliminaron las conexiones que habían quedado colgadas.
| Conexiones a medias en el servidor | Estado |
|---|---|
| Antes de actuar | 441 |
| Después de bloquear | 1 |
La alerta volvió a su sitio y la votación siguió sin que ningún votante se enterara de nada.
Las tres cosas que hicieron falta
Este caso se resolvió bien porque estaban las tres, y si falta una el final es otro:
Vigilancia que avisa. Nadie estaba mirando ese servidor a las 21:30. Lo que había era un sistema comprobando constantemente el estado de las máquinas, que detectó algo anómalo y lo dejó registrado. Sin eso, el ataque habría seguido hasta que alguien llamara diciendo que la web va rara, probablemente en mitad de la votación.
La máquina bien puesta de antemano. La defensa que evitó la caída no se activó esa noche: llevaba puesta desde el primer día. El trabajo aburrido de configurar bien un servidor es el que te salva en el momento en que pasa algo.
Alguien que entienda el negocio del cliente. Un técnico sin contexto bloquea el rango a las 21:35 y se va a dormir tranquilo. Si ese rango hubiera sido el de una mutua votando desde su red corporativa, el problema del día siguiente habría sido bastante peor que 500 conexiones colgadas.
Qué puedes sacar de esto para tu empresa
No hace falta tener una plataforma de votaciones para que esto te sirva. Tres preguntas que puedes hacerle hoy a quien lleve tu informática:
- ¿Quién se entera si un servidor empieza a comportarse raro de madrugada? Si la respuesta es «nos avisan los usuarios por la mañana», no hay vigilancia, hay suerte.
- ¿Dónde queda registrado? Un aviso que nadie guarda no sirve para reconstruir nada después.
- ¿Quién decide si se bloquea algo que afecta a clientes? Y si esa persona sabe lo suficiente de tu negocio como para medir las consecuencias.
Si quieres ver el volumen de ruido que recibe una empresa normal cada día, lo publicamos con todos los números en esta entrada sobre lo que bloquea un cortafuegos. Este caso es lo que pasa cuando algo de ese ruido se convierte en un problema.
Cómo lo tenemos montado
Los servidores que gestionamos mandan su estado a un sistema de vigilancia que comprueba procesador, memoria, disco, servicios y conexiones las 24 horas. Cuando algo se sale de lo normal, salta la alerta y queda registrada. El detalle de cómo está montada la parte de red está en la página de seguridad de red.
Si no sabes qué se está vigilando ahora mismo en tu empresa, esa es una de las cosas que mira la auditoría gratuita: revisamos 243 puntos y te decimos qué hay, qué falta y qué pasaría una noche como esta. El informe es tuyo, contrates o no.
Preguntas frecuentes
¿Qué es un ataque de conexiones a medias?
El atacante abre miles de conexiones contra tu servidor y nunca las completa. Cada una ocupa un hueco en la cola de espera durante un rato, y si se llena, los visitantes legítimos dejan de poder entrar. No roba datos ni entra en el sistema: su único objetivo es que tu web deje de atender a la gente.
¿Por qué no se bloqueó el ataque nada más detectarlo?
Porque era una plataforma de votaciones con un proceso abierto, y bloquear por error un rango legítimo habría dejado sin votar a personas reales. Antes de cortar comprobamos que desde ese bloque no se había votado nunca y confirmamos con el cliente que ese tráfico no era suyo. Con la confirmación, resolverlo llevó quince minutos.
¿Cómo se sabe que no es tráfico de usuarios reales?
Por tres señales juntas: todo venía de un único bloque de direcciones, ninguna conexión llegaba a completarse, y ningún intento repetía el mismo origen, cuando un navegador real reintenta siempre desde el mismo sitio. Además, ninguna de esas peticiones había aparecido nunca en el registro del servidor web.
¿Mi empresa necesita vigilancia 24 horas?
Depende de qué pase si tus sistemas fallan de madrugada. Si tienes una tienda, un portal o un servicio que la gente usa fuera de tu horario, sí. Si todo el mundo trabaja de nueve a seis y nada se publica a internet, con vigilancia en horario laboral y buenas copias de seguridad suele bastar. Lo que no vale es no saber cuál de los dos casos eres.
