FIREWALK(8)					      FIREWALK(8)


NAME
       firewalk - Gateway port scanner

SYNOPSIS
       firewalk [-hIinoPpqrSsTtvx] [ gateway destination ]

DESCRIPTION
       Firewalk	 is  a	network	 auditing  tool	 that attempts to
       determine what transport protocols a  given  gateway  will
       pass.   Firewalk	 works	by sending out TCP or UDP packets
       with a TTL one greater then the targeted gateway.  If  the
       gateway allows the traffic, it will forward the packets to
       the  next  hop  where  they  will  expire  and  elicit  an
       ICMP_TIME_EXCEEDED  message.  If the gateway host does not
       allow the traffic, it will likely drop the packets on  the
       floor and we will see no response.

       To  get	the  correct  IP  TTL that will result in expired
       packets one beyond the gateway we need  to  ramp	 up  hop-
       counts.	 We  do	 this  in the same manner that traceroute
       works.  Once we have the gateway hopcount (at  that  point
       the scan is said to be `bound`) we can begin our scan.

       It  is significant to note the fact that the ultimate des-
       tination host does not have to be reached.  It just  needs
       to be somewhere downstream, on the other side of the gate-
       way, from the scanning host.  See below for more	 informa-
       tion on this.



COMMAND-LINE OPTIONS
       -h	      Dump program usage and exit.

       -I port_number Specify  the  initial  destination port for
		      the TTL ramping.	Valid values range from 1
		      to 65535.	 Default is 34434.

       -i interface_name
		      Specify  interface to use.  Only neccessary
		      on multi-homed machines.

       -n	      Do not resolve IP addresses into hostnames.
		      This saves a DNS lookup.

       -o filename    Write  program output to the supplied file.
		      Default is standard output.

       -P pause	      Set a network writing pause  which  may  be
		      neccessary  to keep the program from flood-
		      ing the network.	Valid values range from 1
		      to 2000.	Default is 0.

       -p {TCP, UDP}  Type of scan to perform.	Default is UDP.


       -q	      Turn  on quiet mode, only open port numbers
		      are printed, delimited by newlines for easy
		      comsumption into shell scripts.

       -r count	      Number  of  packets to send per loop itera-
		      tion.  Valid values range	 from  1  to  10.
		      Default is 1.

       -S port_range  Specify  the ports for the scan.	Ports may
		      be  specified  in	 ranges,   delimited   by
		      dashes,  and  multiple ranges may be speci-
		      fied, delimited by  commas.   Valid  values
		      range from 1 to 65535.  Ommiting the termi-
		      nating port number is shorthand for  65535.
		      Default is 11-139,6000-6010.

       -s port_number Specify  the  source  port  for  the  scan.
		      Valid  values  range  from  1   to   65535.
		      Default is 10001.

       -T timeout     Network packet reading timeout.  Valid val-
		      ues range from 1 to  1000.   Default  is	2
		      seconds.

       -t	      Set  the	initial	 IP  time  to live value.
		      Valid  values  range  from  1  to	 MAX_HOP.
		      Default is 1.

       -v	      Dump program version and exit.

       -x expire vector
		      Set  the expire vector.  This is the number
		      of hops the probes  will	expire	from  the
		      gateway host.  Default is 1.



       COMMAND-LINE EXAMPLES

       firewalk	  -n  -oscan1  -t5  -s5555  -pudp  -P50	 -ieth1
       r2  -T1 -S7-25,137-139,6000 192.168.2.10 192.168.3.10

       firewalk 192.168.2.10 192.168.3.10


CAVEATS
       Problem:

       If  we pick a target gateway host that is sufficiently far
       from the scanning host we run the risk that an  intermedi-
       ate  gateway will have some ACL filters in place that will
       block portions of our scan (termed  as  `dark  dropping`).
       The  scanner  has  no way of detecting this and will think
       the target gateway is dropping the packets.


       Solution:

       Ramp the scan like we ramp hopcounts.  Scan  each  gateway
       en  route  to the target gateway.  This is a slow but rea-
       sonably effective solution.  If the scan is done	 in  this
       way  we	will  catch these `dark dropping hosts` as target
       gateways and scan them directly.

       Problem:

       The destination host needs to be at least one hop from the
       gateway.	  In  this  version,  firewalk doesn't handle the
       myriad of possible responses from  the  destination  host.
       This  will  require a bit more intelligence on the part of
       the listening module to be able	to  differeniate  between
       ICMP_TIME_EXCEEDED  messages  and  correct transport layer
       protocol responses (i.e.: UDP elicits a	UDP  datagram  of
       some  sort  OR  an  ICMP	 port  unreachable, TCP elicits a
       SYN|ACK OR an RST message).

					       []   []
					  ______|____|____... . .
					 /
	[]----------/Internet/----------<>-----[]----[]----.. . .
	hop 0	     . . .		hop n	     hop n + 2
	^				^	     ^
	|				|	     |
	|				|	     |
	firewalking			filtering    destination
	host				router	     host

       Solution:

       Make the listener  aware	 of  hopcount  distances  between
       gateway	and  destination  so  it  can  know  what type of
       response to expect.  By doing this we can also do a  light
       port scan of the destination host (assuming the traffic is
       passed through the gateway).

       Please  read  the  whitepaper  from  http://www.packetfac-
       tory.net/firewalk for more information on firewalk.


SEE ALSO
       traceroute(8), pcap(3), libnet(3)

AUTHOR
       Mike D. Schiffman <mike@infonexus.com>

BUGS
       Please send bug reports to mike@infonexus.com






firewalk		    4.25.1999				3


