Chapter 4. LAN Reconnaissance

This chapter covers LAN reconnaissance; specifically, it covers capturing packets and scoping out the LAN environment using ettercap-ng, p0f, and dsniff. When investigating a LAN, your goals can sometimes be at odds with each other. Are you trying to be quick? Is stealth a factor? Sometimes going for speed can compromise your intentions (whatever they may be). The nature of the LAN itself poses some questions as well. What physical access to the LAN do you have? Is the LAN switched? What kind of monitoring is present? What are the repercussions of being discovered?

Topics that are discussed in this chapter include:

Before we begin, let's talk briefly about the tools we'll be using.

ettercap is written by Alberto Ornaghi and Marco Valleri. ettercap strives to be the most capable packet sniffer for use in a switched environment. The differences between the older ettercap program and the newer ettercap-ng are numerous, but in a nutshell, some of the biggest changes are unified sniffing and layer 3 routing. The ettercap-ng project homepage can be found at http://ettercap.sourceforge.net. Along with downloads for source and binaries, the site includes documentation and the community forum.

The dsniff suite was written by Dug Song. dsniff is a collection of tools for network auditing and penetration testing and consists of arpspoof, dnsspoof, dsniff, filesnarf, macof, mailsnarf, msgsnarf, sshmitm, urlsnarf, webmitm, and webspy. dsniff is available at http://www.monkey.org/~dugsong/dsniff/.

Finally, p0f was written by Michal Zalewski. p0f version 2 is a versatile, passive OS fingerprinting tool. p0f is available at http://lcamtuf.coredump.cx/p0f.shtml along with documentation and additional information on network reconnaissance.

The first part of reconnaissance is finding hosts on the LAN. Assuming you are on a machine that is connected to the LAN and it has a working network interface, the most direct method is to ping every IP address and see who responds. Unfortunately, not every ping is created equal. The version that ships with Windows is pretty limited and does not support pinging a broadcast address. The ping that comes with most BSD systems sometimes supports pinging an entire subnet and sometimes it does not. The ping that comes with the Linux netkit typically supports the -b option, which allows pinging a broadcast address.

Since pinging a broadcast address is such an uncertain event, it's not worth even investigating the possibility. Instead, if doing reconnaissance on, for example, a class C-sized network from a Unix system, it's more productive to do a bash one-liner at the command line:

[lou@duodenum] x=1; while [ $x -lt "255" ]; do ping -c 1 10.150.9.$x | grep "bytes fr
om" |  awk '{print $4 " up"}'; let x++; done
10.150.9.15: up
10.150.9.16: up
10.150.9.22: up
10.150.9.23: up
10.150.9.24: up
10.150.9.45: up
10.150.9.46: up
10.150.9.81: up
10.150.9.82: up
10.150.9.86: up

If this takes a long time on your network, you can speed things up by using a shorter timeout. Most Unix versions of ping support the -t (timeout) option. If the LAN is fast, a 300-millisecond timeout should be very safe.

If you suspect the network is prone to losing packets, use two pings to deal with the possibility of packet loss and then filter the results with sort and uniq. Here is an example of running the same ping-sweep with a 300-millisecond timeout on a fast and lossy network:

[lou@duodenum] x=<low_ip>; while [ $x -lt" <high_ip>" ]; do ping -t 0.3 -c 2
<network>$x | grep "bytes from" |  awk '{print $4 " up"}' | sort | uniq; let
x++; done

This is hardly the optimal way to map out a LAN, but unlike more esoteric tools, you can count on bash, ping, grep, awk, sort, and uniq to be on just about every modern Unix-flavored machine you work with. As complicated as the command looks in print, it is easy to remember the concepts.

On a Microsoft Windows machine, things are a bit different. Again, even though it is not the optimal way of doing a ping-sweep, it is pretty easy to perform in a CMD window to see what hosts are available:

C:\Documents and Settings\lou> for /L %H in (1,1,254) DO ping -w 30 -n1 10.150.9.%H |
 find "Reply" >> hostlist.txt
C:\Documents and Settings\lou> more hostlist.txt
Reply from 10.150.9.81: bytes=32 time<1ms TTL=128
Reply from 10.150.9.82: bytes=32 time<1ms TTL=64
Reply from 10.150.9.86: bytes=32 time<1ms TTL=64

For a smaller LAN, or if you are working with a smaller subnet of a large LAN, this works pretty well to give you an idea of what hosts are up and responding to ICMP.

One big problem with using these one liners is that you will get noticed. Sending a lot of ICMP messages to every host in sequential order is very noisy and exactly the kind of behavior a decent IDS system detects. Also, this method assumes that your machine is already connected to the LAN with correct TCP/IP settings. It also assumes that all the machines you are trying to map are responding to ICMP Echo packets. (Plenty of boxes are running host-based firewalls these days, and it is entirely conceivable that someone has disabled ICMP replies in their security policy.)

There are other ways to find out who and what is on a LAN. Most of the methods illustrated in the following sections revolve around investigating the Layer 2 (a.k.a. the Link Layer) aspects of a LAN.