Los pings pueden ser peligrosos

Recientemente me pidieron que hiciera un análisis de un archivo de rastreo, tenía sólo 161 segundos de duración y contenía un poco más de 2,6 millones de fotogramas. Me sorprendió descubrir que aproximadamente el 75% de esos fotogramas eran peticiones o respuestas de ping. Si no hubiera reconocido la dirección IP de la fuente, habría llegado a la conclusión de que el objetivo estaba bajo un ataque de denegación de servicio. En cambio, me enteré de que estaban usando el argumento "run_forever" en el comando ping de STCP para monitorear la accesibilidad del objetivo.

A diferencia del comando ping en la mayoría de los sistemas UNIX o Linux, el comando ping de STCP no se detiene entre la recepción de una respuesta ping y la siguiente solicitud ping. Dado que el número de pings por defecto es sólo 4, esto no es un problema significativo. Pero cuando se incrementa el número de peticiones usando el argumento count o se usa el argumento run_forever, esto puede crear una carga significativa en el sistema, el adaptador Ethernet y la red. Esto hace que el comportamiento por defecto del comando ping de STCP sea totalmente inadecuado para la monitorización a largo plazo de un host objetivo.

Pero, sólo porque el comportamiento por defecto sea inadecuado no significa que no puedas usar el comando ping para la monitorización a largo plazo. El truco está en ejecutar repetidamente el comando enviando una petición de ping a la vez en lugar de ejecutar el comando una vez y enviar un flujo continuo de peticiones de ping. La siguiente macro hará eso.

Como pueden ver, los dos primeros argumentos se pasan directamente al comando ping y corresponden a los argumentos de host y timeout de ping. El tiempo de espera por defecto de ping es de 15 segundos, pero creo que es demasiado largo y en la macro lo he cambiado a 1 segundo. Por supuesto, puedes ajustarlo tanto en la macro como proporcionando un valor como argumento. El tercer argumento es el número de segundos para hacer una pausa entre pings, el valor por defecto es 1 segundo. Debido a que toma tiempo ejecutar la macro y cargar y ejecutar el comando ping el tiempo real entre pings es un poco más largo. Packet_monitor mostró los tiempos entre 1,05 y 1,1 segundos. El argumento final es algo que el ping de UNIX o Linux no le dará - una marca de tiempo para cada ping para que pueda saber cuando el objetivo deja de responder y cuando comienza de nuevo. Si no quieres las marcas de tiempo puedes desactivarlas con el argumento -no_timestamp.