How to introduce delay in scanning tools that do not implement delay without touching source code?

Question

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?

Answer 1

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> 1.1.1.1 #windows sleep hack
pssuspend -r <process name>

Answer 2

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.

On a dedicated scanner I sometimes do something quick and dirty like:

DEV=eth1
tc qdisc add dev $DEV root handle 1:0 tbf rate 200kbit buffer 1600 limit 3000
# run scanning here ...
tc qdisc del dev $DEV root   # clean up

This limits all traffic on that device to 200kpbs. You can of course be more selective, see this TLDP Advanced Routing tip.

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.

Answer 3

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.

Answer 4

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).

Answer 5

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

#!/bin/bash
for var in list 
command
sleep 5
done