Take the 2-minute tour ×

Usually scanning tools implement a switch in order to delay requests and not flood the target. Sometimes there tools that do not implement this delay option.

Is there a way to delay packets from tools that do not implement this option without touching the source code? I know that touching the source code is an option...the option I follow frequently. But I would like to know if there is any tool that exists to do that. Probably this tools, if exists, should be a kind of proxy that would store, in a buffer of some kind, all the packets the tool send and resend them introducing the configured delay.

Any ideas?

share|improve this question
Squid's delay pools may suit your needs. –  Ladadadada Feb 13 '13 at 13:09
Wouldn't the buffer significantly undermine the tools accuracy? The scanning tool has to measure timeouts & delays. –  Mark C. Wallace Feb 13 '13 at 13:59
If you are doing things like blind SQL injection tampering with the packets can introduce false delays and either cause you to get false positives or to get no results at all. –  NULLZ Feb 14 '13 at 1:23
@Mark C. Wallace I think it depends on the task you are performing and the tool you are using. I still think that there are scenarios where this can be a useful tool but in a good part of scenarios the best option will be to modify the source code if available due mainly to timeouts. –  kinunt Feb 18 '13 at 9:22
add comment

5 Answers

up vote 1 down vote accepted

You cannot introduce delays in a generic way without (potentially) breaking functionality, because some / most of scanning is subject to timeouts. When a tool wants to know if port X is open on host Y, it sends a packet which targets that port; if it does not receive a response within a given time T, then it decides that the port is "closed". The timeout period starts as soon as the tool believes the packet to be sent; if you delay the outgoing packet from the outside, then the tool will believe that the port is closed while its packet has actually not been sent yet.

If you really want to delay packet sending from the outside, then you will need heavy tools. You could imagine running the tool within a modified QEMU virtual machine, with opcode-by-opcode emulation; the modification would be about "stalling" the VM regularly, i.e. letting it run for only ten thousand cycles, then block it for two seconds. What the operating system inside the VM thinks of as the "real-time clock" would also have to be stalled, so that the VM does not notice the passing of time during its frozen intervals. There is no conceptual impossibility in this plan, but it would probably imply some rather tricky and convoluted programming (VM and emulators are not the simplest kind of code).

Alternatively, play with LD_PRELOAD and/or ptrace (I am assuming a Unix-like machine) to intercept the system calls which do the actual sending of packets, and add delays at that point. IF the tool starts its timer immediately after the system call, then this will be sufficient; if it starts the timer immediately before the system call, then you will have to alter the process' notion of current time, i.e. intercept gettimeofday() as well (and, on modern Linux systems, this can be a bit harder because gettimeofday() does not necessarily involve a "true" system call).

If the tool manages several packets in parallel (it launches a full batch, then waits for all possible responses simultaneously), then these delay-based methods will not work (not satisfactorily, or at all).

share|improve this answer
add comment

There may be software out there that could introduce packet delays, however there are considerations against using that:

  1. introducing packet delays may interfere with OS or application fingerprinting. Fingerprinting measures responses, introducing delay may skew your results
  2. Delaying packets cause resource contention. If you tell your scanner to do a /24 network scanning TCP and UDP ports 1-65535 it is going to need to send over 33 billion packets. IF you use a 3rd party program to space out the sending of those packets there's a whole load of resources that are going to be taken up. This could make your scanner or the proxy application unstable
  3. Most scanners have timeouts built-in, chances are the proxy would delay packets to the point where the scanner assumes hosts are down

I would not go down the route of trying to delay packets with a third party, I'd use a scanner that has a built-in delay mechanism or modify source code.

share|improve this answer
add comment

You can suspend the process and resume it after a while. The OS buffers data that is being sent to a suspended server and the server will receive it after it is resumed.

For Linux:

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

For Windows there is PsSuspend:

pssuspend <process name>
ping -w 500 -n <seconds> #windows sleep hack
pssuspend -r <process name>
share|improve this answer
add comment

You can do this with tc traffic control on Linux, you can manipulate latency, jitter, packet loss/duplication/corruption and bandwidth. I have found it useful to determine how robust certain connection are, amongst other things.

Since this is done within the OS network stack it will be more effective than any userspace solution.

FreeBSD has pf which offers some similar functionality, though I have not used it to a great extent. I'm only aware of commercial products on Windows platforms. Non-consumer network equipment usually has the facility to throttle traffic at least.

As noted in the other answers, for straight out scanning and fingerprinting this is almost always not going to be useful, but for crawling or brute-forcing it should work.

share|improve this answer
add comment

In simplest way, you can create a simple bash script for executing the tool command after some interval. Eg. -

for var in list 
sleep 5
share|improve this answer
add comment

Your Answer


