FIREWALK(8)

NAME
firewalk - Gateway port scanner

SYNOPSIS
firewalk [-hIinoPpqrSsTtv] 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 hopcounts. 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 destination host does not have to be reached. It just needs to be somewhere downstream, on the other side of the gateway, from the scanning host. See below for more information 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 flooding 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 iteration. 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 specified, delimited by commas. Valid values range from 1 to 65535. Ommiting the terminating port number is shorthand for 65535. Default is 1 - 1024.

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

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

SEE ALSO

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

AUTHOR

Mike D. Schiffman <mds@es2.net> Enterprise Security Services Cambridge Technology Partners

BUGS

Please send bug reports to mds@es2.net