I ping possono essere pericolosi

Recentemente mi è stato chiesto di fare un'analisi di un file di traccia, la durata era di soli 161 secondi e conteneva poco più di 2,6 milioni di fotogrammi. Sono rimasto stupito nello scoprire che circa il 75% di quei fotogrammi in cui erano presenti richieste di ping o risposte ping. Se non avessi riconosciuto l'indirizzo IP di origine sarei saltato alla conclusione che l'obiettivo era sotto un attacco di denial of service. Invece ho appreso che stavano usando l'argomento "run_forever" sul comando ping di STCP per monitorare la raggiungibilità del target.

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

Ma, solo perché il comportamento predefinito è inadeguato, non significa che non si possa usare il comando ping per un monitoraggio a lungo termine. Il trucco è quello di eseguire ripetutamente il comando inviando una richiesta di ping alla volta invece di eseguire il comando una volta sola e di inviare un flusso continuo di richieste di ping. La seguente macro farà questo.

Come si può vedere i primi due argomenti sono passati direttamente al comando ping e corrispondono agli argomenti host e timeout del ping. Il timeout di default del ping è di 15 secondi, ma penso che sia troppo lungo e nella macro ho cambiato questo a 1 secondo. Naturalmente è possibile modificarlo sia nella macro che fornendo un valore come argomento. Il terzo argomento è il numero di secondi di pausa tra un ping e l'altro, il valore predefinito è 1 secondo. Poiché ci vuole tempo per eseguire la macro e caricare ed eseguire il comando ping, il tempo effettivo tra i ping è un po' più lungo. Packet_monitor ha mostrato i tempi tra 1,05 e 1,1 secondi. L'argomento finale è qualcosa che il ping UNIX o Linux non vi darà - un timestamp per ogni ping in modo da poter dire quando il bersaglio smette di rispondere e quando è ripartito. Se non si vogliono i timestamp si possono disattivare con l'argomento -no_timestamp.