6.2. Device Discovery
The first step in managing a network
is discovering which devices are on the network. There are some
fairly obvious reasons why this is important. You will need to track
address usage to manage services such as DNS. You may need this
information to verify licensing information. From a security
perspective, you will want to know if there are any devices on your
network that shouldn't be there. And one particularly
compelling reason for a complete picture of your network is IP
address management.
6.2.1. IP Address Management
Management of IP addresses is often
cited as the most common problem faced in the management of an IP
network. There are two goals in IP management -- keeping track of
the addresses in use so you know what is available and keeping track
of the devices associated with each assigned IP address.
Several developments over the
last few years have helped to lessen the problems of IP management.
First, DHCP servers, systems that automatically allocate and track IP
addresses, help when dynamic allocation is appropriate. But there are
a number of reasons why a system may require a static IP address. Any
resource or server -- time server, name server, and so
on -- should be given a static address. Network devices like
switches and routers require static addresses. Some sites require
reverse DNS lookup before allowing access. The easiest way to provide
this is with a static IP address and with an appropriate DNS
entry.
[26] Even when such issues don't
apply, the cost and complexity of DHCP services may prevent their
use. And even if you use DHCP, there is nothing to prevent a user
from incorrectly assigning a static IP address in the middle of the
block of addresses you have reserved for DNS assignment.
Another development that has helped
is automatic testing of newly assigned addresses. While earlier
implementations of TCP/IP stacks sometimes neglected to test whether
an IP address was being used, most systems, when booted, now first
check to see if an IP address is in use before using it. The test,
known as
gratuitous ARP, sends out an ARP
request for the IP address about to be used. If anyone replies, the
address must already be in use. Of course, this test works only when
the other machine is turned on. You may set up a machine with
everything appearing to work correctly, only to get a call later in
the day. Once such a problem has been detected, you will need to
track it down.
While these and similar developments
have gone a long way toward lessening the problems of IP management
and duplicate IP addresses, IP management remains a headache on many
networks. Ideally, you will keep careful records as IP addresses are
assigned, but mistakes are unavoidable. Thus, an automated approach
is often desirable.
The
simplest way to collect MAC/IP address pairs is to ping the address
and then examine your ARP table. The ping is necessary since most ARP
tables are flushed frequently. At one time, it was possible to ping a
broadcast address and get a number of replies at once. Most hosts are
now configured to ignore ICMP requests sent to broadcast addresses.
(See the discussion of Smurf Attacks in
Chapter 3, "Connectivity Testing".)
You will need to repeat ping scans very frequently if you want to get
a picture over time. It is a simple matter to create a script that
automates the process of pinging a range of IP addresses,
particularly if you use a tool like
fping.
You'll need the output from the
arp
command if you want the MAC addresses. And you certainly will want to
do some cleanup with
sort or
sed.
Fortunately, there is a class of tools
that simplifies this process -- IP scanner or
ping scanner. These are usually very simple
tools that send ICMP ECHO_REQUEST packets in a systematic manner to
each IP address in a range of IP addresses and then record any
replies. (These tools are not limited to using just ECHO_REQUEST
packets.)
6.2.2. nmap
The
program
nmap is a multifunction tool that
supports IP scanning. It also provides port scanning and stack
fingerprinting. (Stack fingerprinting is described later in this
chapter.)
nmap is an extremely feature-rich
program with lots of versatility. For many of its uses, root
privileges are required, although some functions work without root
privileges.
nmap certainly could have been described in
Chapter 2, "Host Configurations", when port scanners were introduced. But
if all you want is a port scan for a single machine, using
nmap is overkill.
[27] Nonetheless, if you only want as few
programs as possible and you need some of the other functionality
that
nmap provides, then you can probably get by
with just
nmap.
To use
nmap as a port scanner, the only
information you need is the IP address or hostname of the target:
bsd1# nmap sol1
Starting nmap V. 2.12 by Fyodor ([email protected], www.insecure.org/nmap/)
Interesting ports on sol1.lander.edu (172.16.2.233):
Port State Protocol Service
21 open tcp ftp
23 open tcp telnet
25 open tcp smtp
37 open tcp time
111 open tcp sunrpc
515 open tcp printer
540 open tcp uucp
6000 open tcp X11
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
The results should be self-explanatory.
You can specify several IP addresses or you can span a segment by
specifying an address with a mask if you want to scan multiple
devices or addresses. The next example will scan all the addresses on
the same subnet as the
lnx1 using a class C
network mask:
bsd1# nmap lnx1/24
While
nmap skips addresses that don't
respond, this can still produce a lot of output.
Fortunately,
nmap will recognize a variety of
address range options. Consider:
bsd1# nmap 172.16.2.230-235,240
This will scan seven IP
addresses -- those from
172.16.2.230 through
172.16.2.235 inclusive and
172.16.2.240. You can use
172.16.2.* to scan everything on the subnet. Be
warned, however, that the shell you use may require you to use an
escape sequence for the
* to work correctly. For
example, with C-shell, you could use
172.16.2.\*. You should also note that the
network masks do not have to align with a class boundary. For
example,
/29 would scan eight hosts by working
through the possibilities generated by changing the three low-order
bits of the address.
If you want to just do an IP scan to
discover which addresses are currently in use, you can use the
-sP option. This will do a
ping-like probe for each address on the subnet:
bsd1# nmap -sP lnx1/24
Starting nmap V. 2.12 by Fyodor ([email protected], www.insecure.org/nmap/)
Host (172.16.2.0) seems to be a subnet broadcast address (returned 3 extra
pings). Skipping host.
Host cisco.lander.edu (172.16.2.1) appears to be up.
Host (172.16.2.12) appears to be up.
Host (172.16.2.230) appears to be up.
Host bsd2.lander.edu. (172.16.2.232) appears to be up.
Host sol1.lander.edu (172.16.2.233) appears to be up.
Host lnx1.lander.edu (172.16.2.234) appears to be up.
Host (172.16.2.255) seems to be a subnet broadcast address (returned 3 extra
pings). Skipping host.
Nmap run completed -- 256 IP addresses (6 hosts up) scanned in 1 second
You should
be warned that this particular scan uses both an ordinary ICMP packet
and a TCP ACK packet to port 80 (HTTP). This second packet will get
past routers that block ICMP packets. If an RST packet is received,
the host is up and the address is in use. Unfortunately, some
intrusion detection software that will ignore the ICMP packet will
flag the TCP ACK as an attack. If you want to use only ICMP packets,
use the
-PI option. For example, the previous
scan could have been done using only ICMP packets with the command:
bsd1# nmap -sP -PI lnx1/24
In this case, since the devices are on the same subnet and there is
no intervening firewall, the same machines are found.
Unfortunately,
nmap stretches the limits of what might be
considered appropriate at times. In particular,
nmap provides a number of options for stealth
scanning. There are two general reasons for using stealth scanning.
One is to probe a machine without being detected. This can be
extremely difficult if the machine is actively watching for such
activity.
The other reason is to slip packets
past firewalls. Because firewall configuration can be quite complex
and because it can be very difficult to predict traffic patterns,
many firewalls are configured in ways that allow or block broad,
generic classes of traffic. This minimizes the number of rules that
need to be applied and improves the throughput of the firewall. But
blocking broad classes of traffic also means that it may be possible
to sneak packets past such firewalls by having them look like
legitimate traffic. For example, external TCP connections may be
blocked by discarding the external SYN packets used to set up a
connection. If a SYN/ACK packet is sent from the outside, most
firewalls will assume the packet is a response for a connection that
was initiated by an internal machine. Consequently, the firewall will
pass the packet. With these firewalls, it is possible to construct
such a packet and slip it through the firewall to see how an internal
host responds.
nmap has several types of scans that are
designed to do stealth probes. These include
-sF,
-sX, and
-sN. (You can also use the
-f option to break stealth probes into lots of
tiny fragments.) But while these stealth packets may slip past
firewalls, they should all be detected by any good intrusion
detection software running on the target. You may want to try these
on your network just to see how well your intrusion detection system
works or to investigate how your firewall responds. But if you are
using these to do clandestine scans, you should be prepared to be
caught and to face the consequences.
Another questionable feature of
nmap is the ability to do decoy scans. This
option allows you to specify additional forged IP source addresses.
In addition to the probe packets that are sent with the correct
source address, other similar packets are sent with forged source
addresses. The idea is to make it more difficult to pinpoint the real
source of the attack since only a few of the packets will have the
correct source address. Not only does this create unnecessary network
traffic, but it can create problems for hosts whose addresses are
spoofed. If the probed site automatically blocks traffic from probing
sites, it will cut off the spoofed sites as well as the site where
the probe originated. Clearly, this is not what you really want to
do. This calls into question any policy that simply blocks sites
without further investigation. Such systems are also extremely
vulnerable to denial-of-service attacks. Personally, I can see no
legitimate use for this feature and would be happy to see it dropped
from
nmap.
But while
there are some questionable options, they are easily outnumbered by
useful options. If you want your output in greater detail, you might
try the
-v or the
-d
option. If information is streaming past you on the screen too fast
for you to read, you can log the output to a file in human-readable
or machine-parseable form. Use, respectively, the
-o or
-m options along with
a filename. The
-h option will give a brief
summary of
nmap's many options. You may
want to print this to use while you learn
nmap.
If
you are using
nmap to do port scans, you can use
the
-p option to specify a range of ports.
Alternatively, the
-F, or fast scan option, can
be used to limit scans to ports in your services file. You'll
certainly want to consider using one or the other of these. Scanning
every possible port on a network can take a lot of time and generate
a lot of traffic. A number of other options are described in
nmap's documentation.
Despite the few negative things I have mentioned,
nmap really is an excellent tool. You will
definitely want to add it to your collection.
6.2.3. arpwatch
Active scans, such as those we have just
seen with
nmap, have both advantages and
disadvantages. They allow scans of remote networks and give a good
snapshot of the current state of the network. The major disadvantage
is that these scans will identify only machines that are operational
when you do the scan. If a device is on for only short periods at
unpredictable times, it can be virtually impossible to catch by
scanning. Tools that run constantly, like
arpwatch, provide a better picture of activity
over time.
For
recording IP addresses and their corresponding MAC addresses,
arpwatch is my personal favorite. It is a very
simple tool that does this very well. Basically,
arpwatch places an interface in promiscuous mode
and watches for ARP packets. It then records IP/MAC address pairs.
The primary limitation to
arpwatch comes from
being restricted to local traffic. It is not a tool that can be used
across networks. If you need to watch several networks, you will need
to start
arpwatch on each of those networks.
The information can be recorded in one
of four ways. Data may be written directly to the system console, to
the system's
syslog file, or to a
user-specified text file, or it can be sent as an email to root.
(
syslog is described in
Chapter 11, "Miscellaneous Tools".) Output to the console or the
syslog file is basically the same. An entry will
look something like:
Mar 30 15:16:29 bsd1 arpwatch: new station 172.16.2.234 0:60:97:92:4a:6
Of course, with
the
syslog file, these messages will be
interspersed with many other messages, but you can easily use
grep to extract them. For example, to write all
the messages from
arpwatch that were recorded in
/var/log/messages into the file
/temp/arp.data, you can use the command:
bsd1# grep arpwatch /var/log/messages > /tmp/arp.list
If your
syslog file goes by a different name or
you want output in a different output file, you will need to adjust
names accordingly. This approach will include other messages from
arpwatch as well, but you can easily delete
those that are not of interest.
Email looks like:
From: arpwatch (Arpwatch)
To: root
Subject: new station (lnx1.lander.edu)
hostname: lnx1.lander.edu
ip address: 172.16.2.234
ethernet address: 0:60:97:92:4a:6
ethernet vendor: 3Com
timestamp: Thursday, March 30, 2000 15:16:29 -0500
Email output has the advantage of doing
name resolution for the IP address, and it gives the vendor for the
MAC address. The vendor name is resolved using information in the
file
ethercodes.dat. This file, as supplied with
arpwatch, is not particularly complete or
up-to-date, but you can always go to the IEEE site as described in
Chapter 2, "Host Configurations" if you need this data for a particular
interface. If you do this, don't forget to update the
ethercodes.dat file on your system.
arpwatch can also record raw data to a file.
This is typically the file
arp.dat, but you can
specify a different file with the
-f option. The
default location for
arp.dat seems to vary with
systems. The manpage for
arpwatch specifies
/usr/operator/arpwatch as the default home
directory, but this may not be true for some ports. If you use an
alternative file, be sure to give its full pathname. Whether you use
arp.dat or another file, the file must exist
before you start
arpwatch. The format is pretty
sparse:
0:60:97:92:4a:6 172.16.2.234 954447389 lnx1
Expect a lot of entries the first few days after you start
arpwatch as it learns your network. This can be
a little annoying at first, but once most machines are recorded, you
shouldn't see much traffic -- only new or changed addresses.
These should be very predictable. Of particular concern are
frequently changing addresses. The most likely explanation for a
single address change is that a computer has been replaced by
another. Although less likely, a new adapter would also explain the
change.
Frequent or unexplained changes deserve
greater scrutiny. It could simply mean someone is using two
computers. Perhaps a user is unplugging his desktop machine in order
to plug in his portable. But it can also mean that someone is trying
to hide something they are doing. On many systems, both the MAC and
IP addresses can be easily changed. A cracker will often change these
addresses to cover her tracks. Or a cracker could be using ARP
poisoning to redirect traffic.
Here is an example of an email report for an address change:
From: arpwatch (Arpwatch)
To: root
Subject: changed ethernet address
hostname: <unknown>
ip address: 205.153.63.55
ethernet address: 0:e0:29:21:88:83
ethernet vendor: <unknown>
old ethernet address: 0:e0:29:21:89:d9
old ethernet vendor: <unknown>
timestamp: Monday, April 3, 2000 4:57:16 -0400
previous timestamp: Monday, April 3, 2000 4:52:33 -0400
delta: 4 minutes
Notice that the subject line will alert you to the nature of the
change. This change was followed shortly by another change as shown
here:
From: arpwatch (Arpwatch)
To: root
Subject: flip flop
hostname: <unknown>
ip address: 205.153.63.55
ethernet address: 0:e0:29:21:89:d9
ethernet vendor: <unknown>
old ethernet address: 0:e0:29:21:88:83
old ethernet vendor: <unknown>
timestamp: Monday, April 3, 2000 9:40:47 -0400
previous timestamp: Monday, April 3, 2000 9:24:07 -0400
delta: 16 minutes
This is basically the same sort of information, but
arpwatch labels the first as a changed address
and subsequent changes as flip-flops.
If you are running DHCP and find
arpwatch's output particularly annoying,
you may want to avoid
arpwatch. But if you are
having problems with DHCP,
arpwatch might, in
limited circumstances, be useful.
 |  |  |
| 6. Device Discovery and Mapping |  | 6.3. Device Identification |
