5.2. Access to Traffic
You can capture traffic only on a link
that you have access to. If you can't get traffic to an
interface, you can't capture it with that interface. While this
might seem obvious, it may be surprisingly difficult to get access to
some links on your network. On some networks, this won't be a
problem. For example, 10Base2 and 10Base5 networks have shared media,
at least between bridges and switches. Computers connected to a hub
are effectively on a shared medium, and the traffic is exposed. But
on other systems, watch out!
Clearly, if you are trying
to capture traffic from a host on one network, it will never see the
local traffic on a different network. But the problem doesn't
stop there. Some networking devices, such as bridges and switches,
are designed to contain traffic so that it is seen only by parts of
the local network. On a switched network, only a limited amount of
traffic will normally be seen at any interface.
[23] Traffic will be limited to traffic to or from the host or
to multicast and broadcast traffic. If this includes the traffic you
are interested in, so much the better. But if you are looking at
general network traffic, you will use other approaches.
Not being able to capture data on an
interface has both positive and negative ramifications. The primary
benefit is that it is possible to control access to traffic with an
appropriate network design. By segmenting your network, you can limit
access to data, improving security and enhancing privacy.
Lack of
access to data can become a serious problem, however, when you must
capture that traffic. There are several basic approaches to overcome
this problem. First, you can try to physically go to the traffic by
using a portable computer to collect the data. This has the obvious
disadvantage of requiring that you travel to the site. This may not
be desirable or possible. For example, if you are addressing a
security problem, it may not be feasible to monitor at the source of
the suspected attack without revealing what you are doing. If you
need to collect data at multiple points simultaneously, being at
different places at the same time is clearly not possible by
yourself.
Another approach is to have multiple
probe computers located throughout your network. For example, if you
have computers on your network that you can reach using
telnet,
ssh, X Window
software, or
vnc, you can install the
appropriate software on each. Some software has been designed with
remote probing in mind. For example, Microsoft's
netmon supports the use of a Windows platform as
a probe for collecting traffic. Data from the agents on these
machines can be collected by a central management station. Some RMON
probes will also do this. (
vnc and
ssh are described in
Chapter 11, "Miscellaneous Tools".
netmon is briefly
described later in this chapter, and RMON is described in
Chapter 8, "Performance Measurement Tools".)
When dealing with switches, there are two
common approaches you can take. (Several other techniques that I
can't recommend are described later in this chapter.) One
approach is to augment the switch with a spare hub. Attach the hub to
the switch and move from the switch to the hub only the connections
that need to be examined. You could try replacing the switch with a
hub, but this can be disruptive and, since a hub inherently has a
lower capacity, you may have more traffic than the hub can handle.
Augmenting the switch with a hub is a better solution.
Buying a small portable hub to use in
establishing a probe point into your network is certainly worth the
expense. Because you will be connecting a hub to a switch, you will
be using both crossover and patch cables. Be sure you work out the
details of the cabling well before you have to try this approach on a
problematic network. Alternately, there are several commercially
available devices designed specifically for patching into networks.
These devices include monitoring switches, fiber splitters, and
devices designed to patch into 100-Mbps links or links with special
protocols. If your hardware dictates such a need, these devices are
worth looking into.
TIP:
Here is a riddle for
you -- when is a hub not a hub? In recent years, the distinction
between hubs and switches has become blurred. For example, a 10/100
autoswitching hub may be implemented, internally, as a 10-Mbps hub
and a 100-Mbps hub connected by a dual-port switch. With such a
device, you may not be able to see all the traffic. In the next few
years, true hubs may disappear from the market. You may want to keep
this in mind when looking for a hub for traffic monitoring.
A second possibility with some switches
is to duplicate the traffic from one port onto another port. If your
switch supports this, it can be reconfigured dynamically to copy
traffic to a monitoring port. Other ports continue functioning
normally so the monitoring appears transparent to the rest of the
switch's operation. This technique is known by a variety of
names. With Bay Network products, this is known as
conversation steering. Cisco refers to this as
monitoring or using a
spanning port. Other names include
port aliasing and
port
mirroring.
Unfortunately, many switches either don't support this behavior
or place limitations on what can be done. For instance, some switches
will allow traffic to be redirected only to a high-speed port.
Implementation details determining exactly what can be examined vary
greatly. Another problem is that some types of errors will be
filtered by the switch, concealing possible problems. For example, if
there are any framing errors, these will typically be discarded
rather than forwarded. Normally, discarding these packets is exactly
what you want the switch to do, just not in this context.
You'll have to consult the documentation with your switch to
see what is possible.
 |  |  |
| 5. Packet Capture |  | 5.3. Capturing Data |
