Resumen

  • El programa de APNIC 62 titula la sesión “1.27M Attacks in 204 Days”; el resumen habla de “attack events” y las diapositivas contabilizan 1.272.286 “Total Events”.
  • La observación procede de un único sensor, una IP pública y dos servicios abiertos de forma deliberada: SSH y Telnet. No mide todos los ataques de Asia-Pacífico.
  • Una tabla cuenta 198.973 eventos de inicio SSH exitoso, mientras el embudo cuenta 4.530 IP de origen únicas en esa misma fase.
  • Un recibo de medición debería asociar a cada cifra su conjunto de sensores, servicios, periodo, taxonomía de eventos, severidad, deduplicación y unidad.

La cifra cambia de nombre

En la agenda de APNIC, el despliegue de la Universidad de Dhaka acumuló 1,27 millones de ataques durante 204 días. El texto descriptivo lo formula como 1,27 millones de eventos de ataque. La portada del informe elimina otro grado de interpretación y dice 1,27 millones de eventos. El panel central precisa el total: 1.272.286.

No es una disputa semántica menor. Un evento suele ser un registro emitido por un sensor o una regla. “Evento de ataque” añade una clasificación. “Ataque”, para un lector, sugiere una acción o un incidente delimitado. Contar el primero y nombrarlo como el tercero modifica la escala aparente del hallazgo.

La propia presentación permite dibujar el perímetro. Se usó una máquina virtual Ubuntu con un núcleo, 2 GB de memoria, 20 GB para retener registros y una sola dirección IP pública. Los puertos 22 y 23 quedaron abiertos para SSH y Telnet; el tráfico entrante se dejó pasar a propósito.

Ese diseño es una virtud experimental. El señuelo muestra qué ocurrió cuando dos servicios conocidos estuvieron disponibles para escáneres y sesiones interactivas. No representa todo el tráfico de la universidad, de Bangladesh ni del espacio de APNIC.

198.973 y 4.530 describen cosas distintas

La mejor prueba aparece en una sola diapositiva. La tabla de firmas enumera 198.973 eventos “SSH login successful”. A su lado, el embudo rotulado “Unique IPs” sitúa 4.530 direcciones de origen en la fase de inicio exitoso. Es razonable leer el primer valor como repeticiones y el segundo como direcciones deduplicadas, aunque el material público no ofrece el esquema necesario para reproducir el enlace exacto.

La relación ronda los 44 eventos exitosos por IP de origen que alcanzó esa fase. El volumen de eventos sirve para medir presión y reiteración. La cardinalidad de direcciones sirve para medir alcance bajo una clave y una ventana definidas. Ningún valor identifica por sí mismo a personas, organizaciones o campañas.

Una IP puede pertenecer a un equipo comprometido, un proxy, un servicio compartido o una salida detrás de NAT. Puede cambiar de usuario. Una persona puede operar muchas direcciones y muchas personas pueden aparecer bajo una sola. Por eso “36.598 IP atacantes únicas” no demuestra la existencia de 36.598 atacantes humanos únicos.

La misma cautela vale para las otras métricas. Las 78.411 contraseñas únicas son cadenas introducidas en el señuelo, no cuentas. Los 7.107 nombres de usuario tampoco son identidades verificadas. Descargas, comandos, URL de mando y control y sistemas autónomos tienen unidades y relaciones diferentes con el sensor.

El éxito del señuelo no es una intrusión real

También importa qué objeto califica el adjetivo “exitoso”. Un honeypot está diseñado para admitir y observar conductas que un servidor de producción debería bloquear. Un inicio aceptado por el señuelo demuestra que una sesión atravesó sus reglas. No demuestra la toma de un servidor real de la Universidad de Dhaka.

Lo que ocurre después sí contiene señales operativas: ejecución de comandos, descarga de archivos y patrones de persistencia. La secuencia puede alimentar detección y respuesta. Su valor se conserva mejor si se distingue conexión, intento de autenticación, sesión aceptada en el señuelo, comando y carga, en lugar de convertirlo todo en una cifra de brechas.

Hay además una comprobación aritmética reveladora. Los 1.016.974 eventos SSH y los 255.312 de Telnet suman exactamente 1.272.286. En cambio, las ocho firmas mostradas suman 1.272.287, una más. El documento no explica si las categorías se solapan, si existe un error de transcripción o si se aplicó otro filtro. Lo único demostrable es que esa tabla no se reconcilia con las definiciones publicadas.

La pieza que falta es un recibo de medición

Cada cifra principal debería viajar con una ficha breve: sensores y servicios incluidos, fechas exactas, tipo de evento, regla de severidad, clave de deduplicación, unidad y límites de identidad. Un embudo necesita además definir cada transición. Una distribución de firmas debe indicar si las categorías son excluyentes y cómo se cotejan con el total.

Este recibo es una propuesta editorial de Theo March, no una obligación anunciada por APNIC ni por la Universidad de Dhaka. No exige exponer cargas sensibles. Permite separar presión de alcance, dirección de actor y acceso a un señuelo de compromiso productivo.

Qué acreditan las fuentes y qué queda fuera

El programa y las diapositivas de APNIC acreditan el título, el diseño del sensor y los valores exhibidos. Las páginas del proyecto explican que la honeynet usa sensores para recoger tráfico sospechoso, malware y patrones de ataque. No acreditan un número de personas, incidentes o campañas; tampoco atribución por país, prevalencia regional ni una brecha en producción. No resuelven la diferencia de una unidad en la tabla de firmas.

Fuentes