Come introdurre il ritardo negli strumenti di scansione che non implementano il ritardo senza toccare il codice sorgente?

3

Solitamente gli strumenti di scansione implementano uno switch per ritardare le richieste e non per inondare il target. A volte ci sono strumenti che non implementano questa opzione di ritardo.

C'è un modo per ritardare i pacchetti dagli strumenti che non implementano questa opzione senza toccare il codice sorgente? So che toccare il codice sorgente è un'opzione ... l'opzione che seguo frequentemente. Ma mi piacerebbe sapere se esiste uno strumento per farlo. Probabilmente questo strumento, se esiste, dovrebbe essere una sorta di proxy che memorizzerebbe, in un buffer di qualche tipo, tutti i pacchetti che lo strumento invia e li rinvia introducendo il ritardo configurato.

Qualche idea?

    
posta kinunt 13.02.2013 - 12:43
fonte

5 risposte

1

Non è possibile introdurre ritardi in modo generico senza (potenzialmente) funzionalità di interruzione, poiché alcuni / gran parte della scansione è soggetta a timeout. Quando uno strumento vuole sapere se la porta X è aperta sull'host Y , invia un pacchetto che indirizza quella porta; se non riceve una risposta entro un certo tempo T , decide che la porta è "chiusa". Il periodo di timeout inizia non appena lo strumento ritiene che il pacchetto debba essere inviato; se si ritarda il pacchetto in uscita dall'esterno, lo strumento riterrà che la porta sia chiusa mentre il suo pacchetto non è stato ancora inviato.

Se vuoi davvero ritardare l'invio dei pacchetti dall'esterno, avrai bisogno di strumenti pesanti. Potresti immaginare di eseguire lo strumento all'interno di una QEMU macchina virtuale modificata, con emulazione opcode-by-opcode; la modifica riguarderebbe "lo stallo" della VM regolarmente, cioè lasciandola girare per soli diecimila cicli, quindi bloccarla per due secondi. Ciò che il sistema operativo all'interno della VM considera come "orologio in tempo reale" dovrebbe anche essere bloccato, in modo che la VM non si accorga del passare del tempo durante i suoi intervalli congelati. Non vi è alcuna impossibilità concettuale in questo piano, ma probabilmente implica una programmazione piuttosto complicata e complicata (VM ed emulatori non sono il tipo di codice più semplice).

In alternativa, gioca con LD_PRELOAD e / o ptrace (presumo che una macchina simile a Unix) intercetti le chiamate di sistema che effettuano l'invio effettivo di pacchetti e aggiungono ritardi a quel punto. SE lo strumento inizia il suo timer immediatamente dopo la chiamata di sistema, allora questo sarà sufficiente; se avvia immediatamente il timer prima della chiamata di sistema, allora dovrai modificare la nozione del tempo corrente, cioè intercettare gettimeofday() (e, nei moderni sistemi Linux, questo può essere un po 'più difficile perché gettimeofday() non implica necessariamente una "vera" chiamata di sistema).

Se lo strumento gestisce più pacchetti in parallelo (avvia un batch completo, quindi attende tutte le possibili risposte contemporaneamente), allora questi metodi basati sul ritardo non funzioneranno (non in modo soddisfacente, o del tutto).

    
risposta data 13.02.2013 - 18:50
fonte
2

Potrebbero esserci software là fuori che potrebbero introdurre ritardi nel pacchetto, tuttavia ci sono alcune considerazioni contro l'uso di questo:

  1. l'introduzione di ritardi nel pacchetto potrebbe interferire con il sistema operativo o con il fingerprint delle applicazioni. Le impronte digitali misurano le risposte, l'introduzione del ritardo può distorcere i risultati
  2. Ritardare i pacchetti causa conflitto di risorse. Se si dice allo scanner di effettuare una scansione di rete in / 24 delle porte TCP e UDP 1-65535, sarà necessario inviare oltre 33 miliardi di pacchetti. Se si utilizza un programma di terze parti per distribuire l'invio di quei pacchetti, c'è un intero carico di risorse che verranno utilizzate. Ciò potrebbe rendere instabile lo scanner o l'applicazione proxy
  3. La maggior parte degli scanner ha un timeout integrato, è probabile che il proxy possa ritardare i pacchetti fino al punto in cui lo scanner presume che gli host siano inattivi

Non vorrei seguire la strada del tentativo di ritardare i pacchetti con una terza parte, userei uno scanner che ha un meccanismo di ritardo incorporato o modifica il codice sorgente.

    
risposta data 13.02.2013 - 15:12
fonte
2

Puoi sospendere il processo e riprenderlo dopo un po '. Il sistema operativo memorizza i dati che vengono inviati a un server sospeso e il server lo riceverà dopo che è stato ripreso.

Per Linux:

pkill -stop <process-name>
sleep <seconds>
pkill -cont <process-name>

Per Windows c'è PsSuspend :

pssuspend <process name>
ping -w 500 -n <seconds> 1.1.1.1 #windows sleep hack
pssuspend -r <process name>
    
risposta data 13.02.2013 - 18:29
fonte
2

Puoi farlo con il controllo del traffico tc su Linux, puoi manipolare la latenza, il jitter, la perdita / duplicazione / danneggiamento dei pacchetti e la larghezza di banda. Ho trovato utile determinare la robustezza di determinate connessioni, tra le altre cose.

Poiché questo viene fatto all'interno dello stack di rete del sistema operativo, sarà più efficace di qualsiasi soluzione per lo spazio utente.

FreeBSD ha pf che offre alcune funzionalità simili, sebbene non l'abbia usato in larga misura. Sono a conoscenza solo dei prodotti commerciali su piattaforme Windows. Le apparecchiature di rete non di consumo di solito hanno la possibilità di limitare il traffico almeno.

Come notato nelle altre risposte, per la scansione diretta e le impronte digitali questo non sarà quasi sempre utile, ma per la scansione o la forzatura bruta dovrebbe funzionare.

    
risposta data 13.02.2013 - 19:01
fonte
1

Nel modo più semplice, è possibile creare un semplice script bash per eseguire il comando dello strumento dopo un certo intervallo. Per esempio. -

#!/bin/bash
for var in list 
command
sleep 5
done
    
risposta data 13.02.2013 - 14:54
fonte