


SCANRAND(1)					      SCANRAND(1)


NAME
       scanrand - Stateless TCP Network Analysis System

SYNOPSIS
       scanrand [options] target-range[:target-ports]

PACKAGE
       Paketto Keiretsu 1.0

DESCRIPTION
       Scanrand	 is  a	proof of concept, investigating stateless
       manipulation of the TCP Finite State Machine.   It  imple-
       ments extremely fast and efficient port, host, and network
       trace scanning, and does so with two  completely	 separate
       and  disconnected processes -- one that sends queries, the
       other that receives responses and reconstructs the  origi-
       nal  message from the returned content.	Security is main-
       tained, in the sense that false results are  difficult  to
       forge,  by  embeddeding	a  cryptographic signature in the
       outgoing requests which must be detected in  any	 received
       response.   HMAC-SHA1,  truncated  to 32 bits, is used for
       this "Inverse SYN Cookie".

OPTIONS
       Scanrand implements numerous options; reasonable	 defaults
       are  selected  when  no specific guidance is received from
       the user.  The only thing mandated is  a	 target	 destina-
       tion,  which  may  be  specified using either a FQDN(Fully
       Qualified Domain Name) or a numeric specification.   These
       numerics	 may employ any number of dashes, commas, or com-
       bination thereof at the same time.  For example,	 scanrand
       10.0.1-255.1-10,20:80,137-139 works fine.  More ports will
       be scanned by default when scanning  a  single  host  than
       when scanning a network.

       Scanrand	 is able to estimate remote hopcount by examining
       incom- ing TTLs.

   GENERIC OPTIONS
       -S     Only   send  requests,  do  not  listen  for  their
	      responses.

       -L     Only listen for responses, do not actually send the
	      matching requests.  There's nothing that forces the
	      sender and receiver to be the same host -- in fact,
	      split operation is explicitly supported.

       -e     Show  responses  from  hosts that are up but aren't
	      accepting connections to the requested port.

       -E     *ONLY* show responses from hosts that  are  up  but
	      aren't  accepting connections to the requested port
	      -- do not display ports that are up.




								1





SCANRAND(1)					      SCANRAND(1)


       -t [number of seconds]
	      Set maximum number of seconds that may pass  before
	      listening	 process  gives	 up on receiving any more
	      responses.  This timer is	 reset	with  every  good
	      response, whether the port is up or down.

       -b [bandwidth][b][k][m][g]
	      Limit the amount of bandwidth that scanrand may use
	      for its outgoing requests.   -b  100k  would  limit
	      said bandwidth to 100kbyte/s.  Note, since outgoing
	      SYN frames constitute only 64 bytes  on  the  wire,
	      very  little  bandwidth can go very, very far.  The
	      bandwidth value of 0 -- set by  default  --  corre-
	      sponds to no bandwidth limitation.

       -N     Use  Reverse-DNS	to determine a DNS host name that
	      matches the source of a detected packet.

       -NN    Use Reverse-DNS to determine a DNS host  name  that
	      matches the intended destination of a given packet.

       -v     Verbosity Level 1:  Mark the sending of packets.

       -vv    Verbosity Level 2:  Output all interpreted TCP  and
	      IP headers.


   ADDRESSING
       -d <interface>
	      Use this Layer 2 Device for all traffic.

       -i <IP Address>
	      Use this Layer 3 Source IP address for all traffic.

       -p <Port>
	      Use this Layer 4 TCP Source  Port	 for  all  direct
	      traffic.	 TCP  Traceroute  will use this port as a
	      basis for its activity, but will	vary  its  actual
	      selected port by up to 255.

       -s <Seed>
	      Use  this value as a cryptographic seed for authen-
	      ticating incoming packets.  This value is	 normally
	      generated	 automatically,	 but needs to be manually
	      specified	 and  synchronized  when  splitting   the
	      sender  and  receiver processes across invocations,
	      hosts, and possibly entire networks.  It is  highly
	      advised  not  to repeat the same seed for two sepa-
	      rate scans; spoofing responses becomes much  easier
	      given that circumstance.

       -f <file>
	      Read  list  of targets from a file.  Syntax follows
	      whatever is accepted on the command line.



								2





SCANRAND(1)					      SCANRAND(1)


   EXPERIMENTS
       -l <from-to>
	      Stateless TCP Tracerouting -- instead of just iter-
	      ating  across  ports  and	 hosts,	 we're	iterating
	      across network hops and reconstructing the  network
	      based  on	 the ICMP errors (with original copies of
	      our IP and first 8 bytes of TCP.	May  function  in
	      tandem with standard host/port lists.  Specify min-
	      imum and maximum hop-distance you want to	 map,  as
	      in scanrand -l1-20 www.foobar.com

       -c     Verify Inverse SYN Cookies in returned ICMP errors.
	      Not enabled by default.

       -D     Actively discover distance to target host.  This is
	      done  by	sending	 it an invalid ACK, which immedi-
	      ately forces a TCP RST.  It turns out that lots  of
	      systems  (including  Minewt,  oops)  attempting  to
	      return replies as fast as	 possible  will	 use  the
	      incoming	packet	as  a prototype for the response,
	      flipping only those fields that absolutely need  to
	      be.  This doesn't include TTL...so what happens is,
	      we send out our ACK probe with a TTL of around 180.
	      No  normal host will ever have a TTL in that range,
	      and no normal network will hop down from the  255's
	      into  there.   Now,  we can look at returned RST's,
	      see the TTL in the impossible range, and know  that
	      we  caused  it.	Divide	by two to get the average
	      distance (between getting there and  getting  back,
	      usually  identical but not always due to asymmetric
	      routing).	 "Distco mode" is flexible enough to han-
	      dle  when	 TTL's *are* handled correctly, and in at
	      least one case, will  determine  hopcounts  through
	      firewalls	 that otherwise try to scrub the TTL back
	      up to 64.	 On the flip side, at least one PIX likes
	      to  respond  to  an  ACK	with  a	 locally produced
	      RST|ACK, for some unimaginable reason.   Great  way
	      to  find	out  if you're behind a PIX, but it kills
	      Distco dead (sort of like the 80's).


   PORT SELECTION
       Instead of using a comma/dash  notated  port  range,  like
       "80,20-25",  several default port ranges have been precom-
       piled into scanrand.  They are:

       quick  Quick scanning hits the top one or  two  dozen  TCP
	      service  ports  that  are	 often enabled on a given
	      server.	  This	  translates	 directly     to:
	      80,443,445,53,20-23,25,135,139,8080,
	      110,111,143,1025,5000,465,993,31337,
	      79,8010,8000,6667,2049,3306  This	 is  the  default
	      scan mode when scanning a single host.  When multi-
	      ple   hosts  are	scanned,  scanrand  automatically



								3





SCANRAND(1)					      SCANRAND(1)


	      defaults to scan only port 80 (HTTP).

       squick Super-Quick scanning hits the top five or	 six  TCP
	      service  ports  that  are	 very  often enabled on a
	      given  server.   This   translates   directly   to:
	      80,443,139,21,22,23

       known  Known  Port  Scanning  uses IANA's list of TCP port
	      numbers, as well as any other port numbers observed
	      by Fyodor of the nmap project, to select 1150 ports
	      from the 65K possible to scan.  This is  equivalent
	      to the nmap "fast scan" option.

       all    Scans  all  ports	 --  0(which is a valid port!) to
	      65535.



BUGS
       It is very easy to scan faster than the network can accept
       packets.	 No code exists to dynamically reduce scan speed.
       Furthermore, we can only	 capture  absolute  latency  from
       beginning of scan, rather than latency of a given response
       to its received packets.	 There is a fix in  progress  for
       this.   Also, bandwidth calculation presently doesn't take
       into account the time necessary to actually send	 a  given
       packet.	This will be fixed.

AUTHOR
       This  work  has	been  done  by	Dan  Kaminsky  of DoxPara
       Research, who may be reached at dan@doxpara.com.


























								4


