Mapping Your Theatre of War

At this point, you should have a large amount of information with possible avenues for attack. A key point to a successful vulnerability assessment is the recurring theme of human interaction. A good security analyst will have a network map that includes physical as well as logical attributes. Imagine the various war movies where military leaders are standing at the glass panel with overlaid maps, plotting targets, logistics about targets, enemy and friendly forces. The same type of mapping is required when conducting vulnerability assessments. Attributes, notes on systems, architectures, and any other useful aspects should be included in the mappings. Whiteboards can be a security analyst's best friend because they allow a visualization of what he or she is finding. You simply do not get this type of intelligence out of any vulnerability assessment tool available on the market today (including online VA scanners ). The human aspect of assessments is imperative for success!

Some important steps should be taken when mapping your theatre of war. During the information-gathering stage, you work to find as many networks, domains, and public exposures as possible. You are already finding information from sources that many professionals don't know exist. Now you need to go a step further. As you are mapping the network, you need to probe to find out what types of firewalls or packet filters are in place in front of services. There are tools available that can allow you to determine where packet filtering takes place, when load balancers are used, what IDS systems are in use, and more. These tools, used in combination with your already growing network map, allow you to see an even clearer picture of your organization's network from the outside.

Packet Filter and Firewall Discovery

The nature of Internet traffic allows us to see various responses from devices when we use the right tools. Simple tools such as traceroute show how traffic traverses the Internet, but when confronted with a (properly configured) packet filter, these tools simply "time out" and do not provide any additional (and useful) information. These tools may even provide false positives because it appears a host doesn't exist when, in fact, traffic to it is simply filtered. Other more sophisticated tools allow you to see beyond packet filters by attempting connections to ports and analyzing the responses sent even when a connection cannot be made.

Layer Four Traceroute

Layer Four Traceroute (LFT) is a tool developed and maintained by one of the authors (with the help of others). It is designed to display the route network traffic takes to a host. Similar to Van Jacobson's traceroute utility (methodology), paths are determined across networks and the Internet. LFT differs in its ability to use TCP (using TCP SYN and FIN probes and listening for "ttl exceeded," "TCP reset," and many other responses from firewalls and packet filters) instead of UDP (only waiting for "ttl exceeded") to find its path to hosts . This enables LFT to determine services behind many packet filter-based firewalls because TCP will often receive a response to its packet(s) sent, especially when targeting an "open" port/answering service. LFT can also use various TCP ports (both for source and destination), providing more specific means of determining services behind packet filters. LFT is included in many UNIX distributions and is freely available under open source licensing.

A good example for using LFT to help map firewalls and packet filters is to check already known services. Relating back to our Acme vulnerability assessment, we can use LFT to trace to our MTAs (following MX records) and also trace to our web server, which we previously identified as residing in a different location (remember, it is on a separate subnet from 2.2.0.0/20). The first thing to mention is the LFT options and what options are used as defaults.

 Usage: lft [<options>] [<gateway> <...>] <target:destport> Options are:   -d <dport>       destination port number   -s <sport>       source port number   -m <min>         minimum number of probes to send per host   -M <max>         maximum number of probes to send per host   -a <ahead>       number of hops forward to query before receiving replies   -c <scatter ms>  minimum number of milliseconds between subsequent queries   -t <timeout ms>  maximum RTT before assuming packet was dropped   -l <min ttl>     minimum TTL to use on outgoing packets   -q <sequence>    set the initial sequence number (ISN)   -D <deviceip>   network device name or IP address (e.g., "enl" or "1.2.3.4")   -H <ttl>         maximum number of hops to traverse (max TTL of packets)   -i                     disable "stop on ICMP" other than TTL expired   -n                     disable use of the DNS resolver to display hostnames   -F                     enable use of FIN packets only (defaults are SYN)   -N                     enable lookup and display of network names   -A                     enable lookup and display of Autonomous System numbers   -T                     enable display of LFT's execution timer   -S                     suppress the status bar (only show the completed trace)   -V                     print a lot of debugging garbage including packets   -E/-e                  enable LFT's stateful Engine to detect firewalls   -v                     show version information Default is: lft -d 80 -m 1 -M 2 -a 5 -c 20 -t 1000 -H 30 -s 53 

Switching destination ports may help you get more accurate results during route checks. Also, setting the source port allows some firewalls to be bypassed as we discussed previously. We will start with Acme's web server and see what we find. Note the first option used is -E, which sets LFT to attempt to detect firewalls and packet filters.

 root@scanner:$# lft -E -d 80 -m 1 -M 2 -a 5 -c 20 -t 1000 -H 30 -s 53 www.acmeexample.com TTL  LFT trace to www.acmeexample.com (5.125.5.44) :80/tcp  1  s0-0.borderl.acmeexample.net (2.2.0.1) 1.0/1.0ms  2  e0-0.cc.vostrom.com (69.16.147.1) 20.1/20.2ms  3  network-69-16-136-217.phx1.puregig.net (69.16.136.217) 20.1/20.2ms  4  ge-6-2.car1.phoenix1.level3.net (67.72.71.37) 20.1/20.2ms  5  ae-1-54.mp2.phoenix1.level3.net (4.68.98.97) 20.1/20.1ms  6  so-1-0-0.mp2.sandiegol.level3.net (4.68.128.149) 20.1/20.1ms  **  [firewall] the next gateway may statefully inspect packets  7  so-10-0.hsa1.sandiego1.level3.net (4.68.113.38) 20.1/20.1ms  8   [target] www.acmeexample.com (5.125.5.44) : 80 38.0/37.7ms 

If you look at the trace between TTL 6 and TTL 7, you will see there is a flag stating that the next gateway may inspect packets. This IP address should now be included in the topology maps we have been building as some type of firewall or packet filter.

Next we will check the MTAs through the MX records. Acme has two MX records listed:

• Maill.acmeexample.com

• Mail2.acmeexample.com

When using LFT to trace these hosts, maill.acmeexample.com (results not shown) found the same address as being a possible packet filter. The following are the results from the second MX record listed (mail2.acmeexample.com):

 root@scanner# lft -E -d 80 -m 1 -M 2 -a 5 -c 20 -t1000 -H 30 -s 53 mail2.acmeexample.com TTL LFT trace to mail2.acmeexample.com (2.2.0.14) : 80/tcp  1  ln-gateway.centergate.com (206.117.161.1) 0.6/0.5ms  2  ln-usc-gsr-vlan302.ln.net (130.152.181.81) 1.4/1.4ms  3  ge-9-3.a01.lsanca02.us.ra.verio.net (198.172.117.161) 1.6/1.6ms  4  ge-1-1.a00.lsanca17.us.ra.verio.net (129.250.29.132) 1.9/1.5ms  5  xe-1-0-0-4.r20.lsanca01.us.bb.verio.net (129.250.29.120) 1.9/1.6ms  6  p16-1-1-2.r21.mlpsca01.us.bb.verio.net (129.250.5.97) 12.9/23.2ms  7  p64-0-0-0.r21.plalca01.us.bb.verio.net (129.250.5.48) 13.6/14.1ms  8  p16-1-0-0.r00.plalca01.us.bb.verio.net (129.250.3.85) 13.6/13.9ms  9  network-69-16-136-217.phx1.puregig.net (69.16.136.217) 20.1/20.2ms  10 ae0-4000m.core-02.phx1.puregig.net (69.16.128.34) 20.2/20.2ms  11 ge0-0-0-51.jr1.phx1.llnw.net (69.28.162.9) 20.1/20.1ms  12 ge2-12.fr1.lax.llnw.net (69.28.172.41) 40.3/40.2ms  13 ge-0-0-4.p820.pat2.pao.yahoo.com (216.115.98.33) 40.3/40.2ms  14 ge-0-0-3.msr1.scd.yahoo.com (66.218.64.146) 40.3/40.2ms  ** [firewall] the next gateway may statefully inspect packets  15 unknown-acme.acmeexample.com (66.218.82.230) 40.2/40.3ms  16  [target] mail2.acmeexample.com (2.2.0.14):80 38.5/39.2/*/*ms 

Again, we see an IP address that appears to statefully inspect packets similar to firewalls or packet filters. This IP address (66.218.82.230) could be a firewall, but most likely this is a border router with access control lists (ACLs) enabled on the public or external interface. Since the IP address is not part of the network address block Acme provided (or that we found) but rather part of Acme's ISP (determined through name lookup), it is a good chance ACLs are in use by Acme at its border. Again, this should be mapped and added to our theatre of war. Also, to confirm it is some type of packet filter, we will next try an LFT command that attempts to connect to a port we generally believe will be closed ( randomly selected port 35).

 root@scanner# lft -E -d 35 -m 1 -M 2 -a 5 -c 20 -t1000 -H 30 -s 53 mail2.acmeexample.com TTL LFT trace to mail2.acmeexample.com (2.2.0.14) : 35/tcp 1  ln-gateway.centergate.com (206.117.161.1) 0.6/0.5ms 2  ln-usc-gsr-vlan302.ln.net (130.152.181.81) 1.4/1.4ms 3  ge-9-3.a01.lsanca02.us.ra.verio.net (198.172.117.161) 1.6/1.6ms 4  ge-1-1.a00.lsanca17.us.ra.verio.net (129.250.29.132) 1.9/1.5ms 5  xe-1-0-0-4.r20.lsanca01.us.bb.verio.net (129.250.29.120) 1.9/1.6ms 6  p16-1-1-2.r21.mlpsca01.us.bb.verio.net (129.250.5.97) 12.9/23.2ms 7  p64-0-0-0.r21.plalca01.us.bb.verio.net (129.250.5.48) 13.6/14.1ms 8  p16-1-0-0.r00.plalca01.us.bb.verio.net (129.250.3.85) 13.6/13.9ms 9  network-69-16-136-217.phx1.puregig.net (69.16.136.217) 20.1/20.2ms 10 ae0-4000m.core-02.phx1.puregig.net (69.16.128.34) 20.2/20.2ms 11 ge0-0-0-51.jr1.phx1.llnw.net (69.28.162.9) 20.1/20.1ms 12 ge2-12.fr1.lax.llnw.net (69.28.172.41) 40.3/40.2ms 13 ge-0-0-4.p820.pat2.pao.yahoo.com (216.115.98.33) 40.3/40.2ms 14 ge-0-0-3.msr1.scd.yahoo.com (66.218.64.146) 40.3/40.2ms ** [firewall] the next gateway may statefully inspect packets 15 unknown-acme.acmeexample.com (66.218.82.230) 40.2/40.3ms **  [35/tcp failed] Try alternate options or use -V to see packets 

As you can see, packets to port TCP/35 appear to be dropped at the 66.218.82.230 address, which supports our conclusion that it is some type of packet filter.

Each public resource that you find during your information gathering should be checked with some additional detail to assist in determining assessment boundaries. As we progress with the assessment, these types of checks will also help us conduct a more directed attack. There are other tools that can be used to help with this process.

Tip 

LFT has several other, special options that show even more useful information. Check out the -A and -N operators that enumerate the service provider networks and ASNs that are being traversed.

Firewalk

Firewalk is a utility operable on UNIX that is similar to LFT (mentioned in the previous section). It has the ability to conduct comparable actions by sending packets with TTLs higher than the target gateway. The gateway will pass the traffic on (if allowed) and ICMP "ttl exceeded" responses are received. The alternative is receiving no response signifying a filtered host. Firewalk does not appear to be actively developed as its most recent posting is from March 2004, but may still be an extremely useful tool to be included in your assessment toolkit.

hping2

This is another command line utility available on UNIX platforms and capable of soliciting useful information regarding packet filter configurations, port scanning, and more. The tool allows the user to assemble packets specifically crafted to gather information about the target host. The tool works well for validating findings from other tools and has many options to accurately discover information about target hosts. hping2 is complex to use but provides an analyst with methods to verify host information through a variety of options. There are over 70 options that can be used with hping2. The following shows the options available and the modes possible with hping2.

 root@scanner:$# hping2 -help usage: hping host [options]   -h  -help      show this help   -v  -version   show version   -c  -count     packet count   -i  -interval  wait (uX for X microseconds, for example -i u1000)       -fast      alias for -i u10000 (10 packets for second)   -n  -numeric   numeric output   -q  -quiet     quiet   -I  -interface interface name (otherwise default routing interface)   -V  -verbose   verbose mode   -D  -debug     debugging info   -z  -bind      bind ctrl+z to ttl           (default to dst port)   -Z  -unbind    unbind ctrl+z Mode   default mode     TCP   -0  -rawip      RAW IP mode   -1  -icmp       ICMP mode   -2  -udp        UDP mode   -8  -scan       SCAN mode.                    Example: hping -scan 1-30,70-90 -S www.target.host   -9 -listen      listen mode 

There are also options for each of the protocol modes (such as Raw IP, ICMP, TCP, etc.). These options are shown here:

 IP   -a  -spoof       spoof source address   -rand-dest       random destination address mode. see the man.   -rand-source     random source address mode. see the man.   -t  -ttl         ttl (default 64)   -N  -id          id (default random)   -W  -winid       use win* id byte ordering   -r  -rel         relativize id field          (to estimate host traffic)   -f  -frag        split packets in more frag.  (may pass weak acl)   -x  -morefrag    set more fragments flag   -y  -dontfrag    set don't fragment flag   -g  -fragoff     set the fragment offset   -m  -mtu         set virtual mtu, implies -frag if packet size > mtu   -o  -tos         type of service (default 0x00), try -tos help   -G  -rroute      includes RECORD_ROUTE option and display the route buffer   -lsrr            loose source routing and record route   -ssrr            strict source routing and record route   -H  -ipproto     set the IP protocol field, only in RAW IP mode ICMP   -C  -icmptype    icmp type (default echo request)   -K  -icmpcode    icmp code (default 0)       -force-icmp  send all icmp types (default send only supported types)       -icmp-gw     set gateway address for ICMP redirect (default 0.0.0.0)       -icmp-ts     Alias for -icmp -icmptype 13 (ICMP timestamp)       -icmp-addr   Alias for -icmp -icmptype 17 (ICMP address subnet mask)       -icmp-help   display help for others icmp options UDP/TCP   -s  -baseport    base source port             (default random)   -p  -destport    [+] [+] <port> destination port (default 0) ctrl+z inc/dec   -k  -keep        keep still source port   -w  -win         winsize (default 64)   -O  -tcpoff      set fake tcp data offset (instead of tcphdrlen / 4)   -Q  -seqnum      shows only tcp sequence number   -b  -badcksum    (try to) send packets with a bad IP checksum                     many systems will fix the IP checksum sending the packet                     so you'll get bad UDP/TCP checksum instead.   -M  -setseq      set TCP sequence number   -L  -setack      set TCP ack   -F  -fin         set FIN flag   -S  -syn         set SYN flag   -R  -rst         set RST flag   -P  -push        set PUSH flag   -A  -ack         set ACK flag   -U  -urg         set URG flag   -X  -xmas        set X unused flag (0x40)   -Y  -ymas        set Y unused flag (0x80)   -tcpexitcode     use last tcp->th_flags as exit code   -tcp-timestamp   enable the TCP timestamp option to guess the HZ/uptime Common   -d  -data        data size                     (default is 0)   -E  -file        data from file   -e  -sign        add 'signature'   -j  -dump        dump packets in hex   -J  -print       dump printable characters   -B  -safe        enable 'safe' protocol   -u  -end         tell you when -file reached EOF and prevent rewind   -T  -traceroute  traceroute mode              (implies -bind and -ttl 1)   -tr-stop         Exit when receive the first not ICMP in traceroute mode   -tr-keep-ttl     Keep the source TTL fixed, useful to monitor just one hop   -tr-no-rtt        Don't calculate/show RTT information in traceroute mode ARS packet description (new, unstable)   -apd-send        Send the packet described with APD (see docs/APD.txt) 

As previously stated, there are many options available within the hping2 utility. One of the more interesting options is the -T or traceroute option, providing the user with an ability to potentially craft packets to bypass packet filters. For example, conducting a standard hping2 -T (traceroute) request to an IP address containing a web server may not properly find the target with default options; however, using the -p 80 switch to send probes on port 80, the traceroute will most likely be successful returning traffic routes to the target host.

Whether conducting service validation behind packet filters or port scanning reviews (to be covered in the next chapter), hping2 has the flexibility to assist analysts in validating ports and services as well as routing information to hosts.

Nemesis

Another tool to assemble packets for security checks similar to hping2 mentioned above is Nemesis. It is possible to use Nemesis on both UNIX and Windows, so for Windows users who do not have access to hping2, Nemesis may be used in its place. The following is an example of options available from Nemesis (shown in UNIX).

 root@scanner:$# nemesis -help NEMESIS -=- The NEMESIS Project Version 1.4beta3 (Build 22) NEMESIS Usage:   nemesis [mode] [options] NEMESIS modes:   arp   dns   ethernet   icmp   igmp   ip   ospf (currently non-functional)   rip   tcp   udp NEMESIS options:   To display options, specify a mode with the option "help". 

To provide further information regarding what options are available within Nemesis, the following command output shows what options are available when using TCP for the packet type.

 root@scanner:$# nemesis tcp help TCP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22) TCP usage:   tcp [-v (verbose)] [options] TCP options:   -x <Source port>   -y <Destination port>   -f <TCP flags>      -fS (SYN), -fA (ACK), -fR (RST), -fP (PSH), -fF (FIN), -fU (URG)      -fE (ECE), -fC (CWR)   -w <Window size>   -s <SEQ number>   -a <ACK number>   -u <Urgent pointer offset>   -o <TCP options file>   -p <Payload file> IP options:   -S <Source IP address>   -D <Destination IP address>   -I <IP ID>   -T <IP TTL>   -t <IP TOS>   -F <IP fragmentation options>      -F[D], [M], [R], [offset]   -O <IP options file> Data Link Options:   -d <Ethernet device name>   -H <Source MAC address>   -M <Destination MAC address> 

In the event you need to send packets to a specific service or application to validate service responses, Nemesis can be an effective tool and run from both UNIX and Windows hosts.