¿Cómo introducir la demora en las herramientas de escaneo que no implementan la demora sin tocar el código fuente?

3

Por lo general, las herramientas de exploración implementan un interruptor para retrasar las solicitudes y no inundar el objetivo. A veces hay herramientas que no implementan esta opción de retraso.

¿Hay alguna forma de retrasar paquetes de herramientas que no implementan esta opción sin tocar el código fuente? Sé que tocar el código fuente es una opción ... la opción que sigo con frecuencia. Pero me gustaría saber si existe alguna herramienta para hacerlo. Probablemente, estas herramientas, si existen, deberían ser un tipo de proxy que almacenaría, en un búfer de algún tipo, todos los paquetes que la herramienta envía y reenvía introduciendo el retraso configurado.

¿Alguna idea?

    
pregunta kinunt 13.02.2013 - 12:43
fuente

5 respuestas

1

No puede introducir retrasos de manera genérica sin (potencialmente) romper la funcionalidad, ya que algunos / la mayoría de las exploraciones están sujetas a tiempos de espera. Cuando una herramienta desea saber si el puerto X está abierto en el host Y , envía un paquete que se dirige a ese puerto; Si no recibe una respuesta dentro de un tiempo determinado T , decide que el puerto está "cerrado". El período de tiempo de espera comienza tan pronto como la herramienta cree que el paquete se enviará; Si retrasa el paquete saliente desde el exterior, la herramienta considerará que el puerto está cerrado mientras que su paquete aún no se ha enviado.

Si realmente quiere retrasar el envío de paquetes desde el exterior, necesitará herramientas pesadas. Podría imaginar la ejecución de la herramienta dentro de una máquina virtual QEMU modificada, con la emulación opcode-by-opcode; la modificación consistiría en "detener" la máquina virtual con regularidad, es decir, dejarla funcionar solo por diez mil ciclos, luego bloquearla durante dos segundos. Lo que el sistema operativo dentro de la VM considera como el "reloj de tiempo real" también tendría que detenerse, para que la VM no note el paso del tiempo durante sus intervalos de congelación. No hay imposibilidad conceptual en este plan, pero probablemente implicaría una programación bastante complicada y complicada (VM y emuladores no son el tipo de código más simple).

Alternativamente, juegue con LD_PRELOAD y / o ptrace (estoy asumiendo una máquina similar a Unix) para interceptar El sistema llama y realiza el envío real de paquetes, y agrega demoras en ese punto. Si la herramienta inicia su temporizador inmediatamente después de la llamada al sistema, esto será suficiente; si inicia el temporizador inmediatamente antes de la llamada del sistema, entonces tendrá que modificar la noción de la hora actual del proceso, es decir, también interceptar gettimeofday() (y, en los sistemas Linux modernos, esto puede ser un poco más difícil porque gettimeofday() no implica necesariamente una llamada de sistema "verdadera").

Si la herramienta administra varios paquetes en paralelo (lanza un lote completo, luego espera todas las respuestas posibles simultáneamente), entonces estos métodos basados en demoras no funcionarán (no serán satisfactorios o no funcionarán).

    
respondido por el Tom Leek 13.02.2013 - 18:50
fuente
2

Puede haber software por ahí que podría introducir retrasos en los paquetes, sin embargo, existen consideraciones en contra de su uso:

  1. introducir retrasos en los paquetes puede interferir con el sistema operativo o las huellas digitales de la aplicación. La toma de huellas dactilares mide las respuestas, la introducción de demoras puede sesgar sus resultados
  2. Los paquetes de retraso causan la contención de recursos. Si le dice a su escáner que realice una red / 24 escaneando los puertos TCP y UDP 1-65535, tendrá que enviar más de 33 mil millones de paquetes. Si utiliza un programa de terceros para espaciar el envío de esos paquetes, hay una gran cantidad de recursos que se tomarán. Esto podría hacer que su escáner o la aplicación proxy sean inestables
  3. La mayoría de los escáneres tienen tiempos de espera incorporados, es probable que el proxy retrase los paquetes hasta el punto en que el escáner asuma que los hosts están inactivos

No seguiría el camino de intentar retrasar los paquetes con un tercero, usaría un escáner que tiene un mecanismo de retardo incorporado o modificaría el código fuente.

    
respondido por el GdD 13.02.2013 - 15:12
fuente
2

Puedes suspender el proceso y reanudarlo después de un tiempo. El sistema operativo almacena los datos que se envían a un servidor suspendido y el servidor los recibirá una vez que se reanude.

Para Linux:

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

Para Windows hay PsSuspend :

pssuspend <process name>
ping -w 500 -n <seconds> 1.1.1.1 #windows sleep hack
pssuspend -r <process name>
    
respondido por el Cristian Dobre 13.02.2013 - 18:29
fuente
2

Puede hacer esto con tc control de tráfico en Linux, puede manipular la latencia, la fluctuación de fase, la pérdida / duplicación / corrupción de paquetes y el ancho de banda. Me ha resultado útil determinar cuán sólidas son ciertas conexiones, entre otras cosas.

Dado que esto se hace dentro de la pila de red del sistema operativo, será más efectivo que cualquier solución de espacio de usuario.

FreeBSD tiene pf que ofrece alguna funcionalidad similar, aunque no lo he usado en gran medida. Solo soy consciente de productos comerciales en plataformas Windows. El equipo de red que no es de consumo generalmente tiene la capacidad de estrangular el tráfico al menos.

Como se señaló en las otras respuestas, para el escaneo directo y la toma de huellas dactilares, esto casi siempre no será útil, pero para el rastreo o la fuerza bruta debería funcionar.

    
respondido por el mr.spuratic 13.02.2013 - 19:01
fuente
1

De la forma más sencilla, puede crear un script bash simple para ejecutar el comando de la herramienta después de algún intervalo. P.ej. -

#!/bin/bash
for var in list 
command
sleep 5
done
    
respondido por el Kumar Vikramjeet 13.02.2013 - 14:54
fuente