I ping possono essere pericolosi

Recentemente mi è stato chiesto di analizzare un file di traccia, della durata di soli 161 secondi e contenente poco più di 2,6 milioni di frame. Sono rimasto sorpreso nello scoprire che circa il 75% di quei frame erano richieste ping o risposte ping. Se non avessi riconosciuto l'indirizzo IP di origine, avrei concluso che l'obiettivo era sotto attacco denial of service. Invece ho scoperto che stavano usando l'argomento "run_forever" sul comando ping di STCP per monitorare la raggiungibilità dell'obiettivo.

A differenza del comando ping presente nella maggior parte dei sistemi UNIX o Linux, il comando ping di STCP non effettua pause tra la ricezione di una risposta ping e la richiesta ping successiva. Poiché il numero predefinito di ping è solo 4, questo non rappresenta un problema significativo. Tuttavia, quando il numero di richieste viene aumentato utilizzando l'argomento count o l'argomento run_forever, ciò può creare un carico significativo sul sistema, sull'adattatore Ethernet e sulla rete. Ciò rende il comportamento predefinito del comando ping di STCP totalmente inadatto al monitoraggio a lungo termine di un host di destinazione.

Tuttavia, solo perché il comportamento predefinito non è adatto, ciò non significa che non sia possibile utilizzare il comando ping per il monitoraggio a lungo termine. Il trucco consiste nell'eseguire ripetutamente il comando inviando una richiesta ping alla volta, invece di eseguire il comando una sola volta e inviare un flusso continuo di richieste ping. La seguente macro eseguirà questa operazione.

Come potete vedere, i primi due argomenti vengono passati direttamente al comando ping e corrispondono agli argomenti host e timeout di ping. Il timeout predefinito di ping è di 15 secondi, ma ritengo che sia troppo lungo e nella macro l'ho modificato a 1 secondo. Naturalmente è possibile regolarlo sia nella macro che fornendo un valore come argomento. Il terzo argomento è il numero di secondi di pausa tra i ping, il valore predefinito è 1 secondo. Poiché l'esecuzione della macro e il caricamento e l'esecuzione del comando ping richiedono tempo, il tempo effettivo tra i ping è leggermente più lungo. Packet_monitor ha mostrato tempi compresi tra 1,05 e 1,1 secondi. L'argomento finale è qualcosa che il ping UNIX o Linux non fornisce: un timestamp per ogni ping, in modo da poter capire quando il target smette di rispondere e quando ricomincia. Se non si desidera visualizzare i timestamp, è possibile disattivarli con l'argomento -no_timestamp.