idlescan

	Idlescan is an implementation of the scan method uncovered by Antirez
on bugtraq, in Dec 1998. You should all read his post to better understand
the concepts behind this scanner. His article can be found here:
	http://www.securityfocus.org/templates/archive.pike?list=1&date=1998-12-15&msg=19981218074757.A990@seclab.com

	For those that have not read Antirez's post the basic concept is the
following:
	Due to the fact that on most operating systems the id field of an IP
packet increments by one unit each time a packet is sent, you are able to guess
the number of packets sent by a specific host during a certain time interval.
Exceptions are systems like OpenBSD that don't have this predictable behavior.
	If you have a machine that doesn't have network traffic, when you
you provoque a reply (icmp echo, tcp packet, etc), then the ip.id difference
will be 1. This is due to the reply sent to your machine.
	When you send a SYN packet to another machine, that machine will either
reply with a SYN/ACK if the port is open, or with a RST if the port is closed.
The logic response to a packet with the SYN and ACK flags set will be a RST,
because the operating systems did not start that connection. On the other end
there will be no reply to a packet with the RST flag set (this would cause a
loop). So... when you receive a SYN/ACK (port open) the ip.id  of the next
packet sent will be increased by one, due to your reply, but it won't be
increased in case the port is closed (RST packet).
	So... you can use this technique to scan a "target" machine, by using
another idle machine (I am calling these idle machines, sensors, for simplicity)
	You check the ip.id of your sensor, spoof a packet with the SYN flag
set from the sensor to the tager, and check the ip.id of the sensor again.
If it increases by more than one unit, then the port is open, if it increases
by one unit (caused by the reply to your host), then the port is closed.
	You can expand this method to use several sensors, thus making a
totally spoofed and distributed scan.

	The advantages of this are obvious: You can make a totally spoofed
scan, and it can be made highly distributed, making the source of the scan
almost impossible to detect. The disadvantages are that there is a need for
idle machines (but this are easy to find... many printers, routers or switches
will do just fine) and the scan is pretty slow. You cannot scan in parallel
using only one sensor, but you can speed this up by using several sensors.

	idlescan is an implementation of this scan method. For now
it supports multiple sensors and one target. The code is meant to 
demonstrate the dangers of this type of attack,  and there are lots of room
for improvement in the code.

	If you don't understand how the scan works and you can't make it work
then pleaaase don't send any mail asking why its not working and how to make
it work. This code is only meant to demonstrate the consequences of 
predictable ip.id increments. Don't forget as well that I bear no
responsibility for the use of this program, you are on your own. Of course
bug reports, comments and critics are always welcome.

	Thanks go to (in no particular order)
	antirez, for the concept of the scan. Its all his idea.
	Fatzu, for the superbofh.org site
	HPT for the hackers-pt site

	thanks also go to (in no particular order):
	kossak, daz, lifeline, superbofh team, and many others.

	Requires:
	- Linux
	- glibc2
	- libnet - http://packetfactory.net/libnet/

	download sites:
	http://superbofh.org/idlescan/
	http://www.hackers-pt.org/ptstuff/

	usage:
	idlescan sensor1,sensor2,sensor3,... target [ -p port-range ]

	ie:
	$ idlescan nowhere.domain,idle.domain,idle2.domain target.domain -p 50-150,200,210,400-500


"1st rule of idlescan is, you do not talk about idlescan!!!"
"2nd rule of idlescan is, you do not talk about idlescan!!!"

--
LiquidK <liquidk@superbofh.org>

