3. How to
Wiretaps are extremely useful programs for security managers. They are the only
mechanism that can log absolutely everything on the wire in such a way that hackers can't
erase the logs.
3.1 Where can I get a sniffing program for my computer?
- Ethereal is a UNIX-based program that also runs on Windows (which means installation is
more difficult than you would expect and it looks strange). However, it is probably the
best freeware solution available for sniffing on Windows.
It comes in both a read-only
(protocol analyzer) version as well as a capture (sniffing) version. The read-only version
is great for decoding existing packet captures (such as the traces that BlackICE
generates). It avoids the hassle of installing the packet capture driver.
Installation is a little difficult; you'll have to hunt around on the website in order
to figure out how to do it.
- Network Associates Sniffer (for Windows)
- You can probably go to NAI's website and download an eval copy of their Sniffer(r)
Network Analyzer. I'm not quite sure of the details. They still sell their older,
DOS-based version, which is still in many ways a superior product. Go to http://www.nai.com/mktg/survey.asp?type=d&code=2483
- WinNT Server
- Microsoft's WinNT Server comes with a built-in program called "Network
Monitor". Go to the Networking control panel, select the "Services" tab,
hit "Add..." and select "Network Monitor Tools and Agent". Once
installed, you can run it from the program menu under "Administrative Tools".
- BlackICE Pro
- http://www.networkice.com/ BlackICE is an
intrusion detection system that can also log evidence files to disk in a format that can
be read by other protocol analyzers. This may be more useful than a generic sniffing
program when used in a security environment. However, it is non-promiscuous, and only
snifs the packets going into/out-of the machine.
- This is a program that can decode-only. This is great for such programs like
"BlackICE" which can only log packets, but which do not contain their own
built-in decoders. It is shareware for 90 days. http://members.tripod.com/~radhikau/ciall/ciall.htm.
(However, since this is hosted on "Tripod", it is much less reputable than a
real company, and as far as I know, it could contain a trojan designed to compromise the
system: user beware).
- http://www.aggroup.com/ I think you can download a
- Intellimax LanExplorer
- Triticom LANdecoder32
You can sign up for a free demo versino.
- Doesn't decode frames, but reassembles sessions. This is the product that I want to
write, but I haven't gotten around to it yet. http://members.xoom.com/Laurentiu2
- Analyzer: a public domain protocol analyzer
- A toolkit for doing various kinds of analyses. http://netgroup-serv.polito.it/analyzer/
- Other Windows...
- There are a larger number of Windows-based sniffing programs, many of which can be
downloaded and installed like any other application.
- http://www.aggroup.com/ EtherPeek has been around
for years in a Macintosh version and has also ported their software to Windows.
- UNIX solutions are generally based upon libpcap
and/or BPF (Berkeley Packet Filters).
If you have a UNIX computer, then you should be
using both tcpdump and Ethereal.
- The oldest and most common wiretap program. In its simplest mode, it will dump a
single-line decode of the packets to the commandline, one line per packet. It is the
standard for UNIX packet capture.
The version that seems to have the best on-going
maintainance is at http://www.tcpdump.org/.
The original version from LBL is at ftp://ftp.ee.lbl.gov/
A port for Windows has been done at http://netgroup-serv.polito.it/analyzer/
- It currently looks like this is the best GUI-based sniffing program for UNIX. It
is actively maintained. It is available at: http://ethereal.zing.org/
- An old standby for Sun Solaris machines. It is much less capable than tcpdump, but it is
better at Sun-specific protocols like NFS/RPC. Snoop's tracefile has been specified in RFC 1761. It can be
converted to tcpdump/libpcap format via many utilities, including 'tcptrace'.
Useful when trying to analyze application-layer data.
- A libpcap based packet-sniffer/logger with extensive filtering. http://www.clark.net/~roesch/security.html
- Contains tcpdump and sniffit, among numerous other security utilities on a floppy
bootable disk. http://www.trinux.org/
A GUI Linux packet sniffer including a GTK interface.
- SuperSniffer v1.3
To quote the site: enhanced libpcap based packet sniffer with many modifications like
DES encryption of log file, traffic can be logged by regular expression pattern matching,
POP and FTP connections are logged on one line, telnet negotiation garbage is discarded,
duplicate connections are discarded, tcp packet reassembly, parellel tcp connection
logging. Daemon mode where logs are dumped to specified port with authentication.
Duplicate POP/FTP connections are not logged. Compiles under most operating systems, uses
GNU autoconf. September 6, 1999.
Thanks to < cripto at datasurge dot net
> for the link
- A small packet sniffer that helps sift passwords and usernames, published in Phrack
issue 45-5. See http://www.phrack.com/search.phtml?view&article=p45-5.
Esniff only runs on older SunOS platforms, so it really isn't relavent today.
Lightweight packet sniffer for Linux?
- Because DOS isn't a true OS, it is in some ways more flexible as platform for running
tricking things like wiretaps.
- Sniffer(r) Network Analyzer
- An oldy but a goody. The Sniffer defines all products in this genre. It consists of a
3-megabyte executable, which, since DOS has a max memory size of 640-kilobytes, is a
pretty impressive achievement. This is a commercial product that has since been obsoleted
by the Windows Sniffer, but I think it is still available. In many ways, it is better than
the GUI version. http://www.nai.com/
- The Gobbler and Beholder
- The Gobbler is a simple DOS-based packet sniffer with advanced packet-filtering
capabilities. It is very old, but still in use. It is from the Delft University in the
Netherlands. Beholder is an RMON probe based upon the same technology. http://nmrc.org/files/msdos/gobbler.zip
- Klos PacketView
- A low-end DOS product. http://www.klos.com/
- Here are some other utilities that aren't classified above.
- A sniffing program dedicated to SNMP. http://www.idt.ipp.pt/~rff-ribe/snmpsniff/
3.2 Where can I get a utility to inject strangely formatted packets onto the wire?
is a public library written for C that can be used to format not only raw packets, but
also a number of higher level protocols.
contains a number of "exploit" scripts (such as bonk, teardrop, etc.) that
demonstrate injecting raw packets onto the wire.
is a utility that comes with the ipfilter package. It contains a scripting language for
creating IP packets.
- Sun Packet Shell (psh) Protocol Testing Tool
based software toolset for protocol developement.
library for manipulating raw IP using libpcap.
- CyberCop Scanner's CASL
A scripting language that comes
as part of CyberCop scanner.
3.2.1 Where can such a utility for Windows?
- The CASL scripting is available for Windows, and you can use the NAI Sniffer product to
generate hand-crafted packets. However, I'm not aware of any really good solutions to this
for Windows, especially Win9x.
3.4 How can I sniff cable-modem segments?
The first problem is that cable-modems split upstream and downstream
into two asymmetric channels. The cable-modem can "receive-only" on one
high-speed channel (between 30-mpbs and 50-mbps), and "transmit-only" on the
low-speed channel (typically around 1-mbps). Thus, your own cable-modem box cannot receive
the transmit channel data.
Most cable-modem boxes have only a 10-mbps Ethernet output, which is far less than the
30-mbps they are reading from the cable. Furthermore, most cable-modem plants are
designing their systems to fill that channel as much as possible. Most cable-modem users
are seeing slower download speeds due to this congestion. It would be like drinking from a
firehose -- you would miss lots of the data.
There are many different cable-modem equipment vendors. What may work on one segment
may not work on a different one.
The Cable Box Itself
Most cable-modem boxes are either bridges or routers themselves, and have separate MAC
addresses and IP addresses. This means that putting your own Ethernet adapter into
"promiscuous mode" has zero effect on the cable-modem itself.
It should be remembered that the cable-segment is a very "virtual" object: it
looks like Ethernet to your computer, but it is very different on the other end.
When the box is a bridge, it can sometimes be reconfigured to pass all traffic.
These days, cable-modems frequently also support encryption, though not very good
encryption. I'm not sure whether this raises the difficulty at all.
While traditional sniffing is out of the question, there are some other ways to sniff
the wire. First of all, you can sniff broadcasts, multi-casts, and semi-directed packets.
For example, whenever anybody starts up PCAnywhere, they send out a PCAnywhere packet to
all their neighbors. This will advertise to you the presence of somebody who may be
running PCAnywhere, and who may be hacked.
The average cable-modem segment is filled with other broadcasts, such as NetBIOS
packets (advertising user names), SNMP broadcasts (advertising network equipment such as
routers and printers), bootp/DHCP broadcasts (advertising devices that you can probably
configure and take over), etc.
There are many ways of redirecting traffic through your own computer in order to sniff
- Many games can be played with ARP. First of all, you can send out an ARP packet that
claims that you are the local router. This is likely to flood your own connection because
EVERYONE will think you are the router. Conversally, you can send out an ARP where you
claim to be a particular person. This is convenient with Windows because it will shut down
its own connection -- you can often masquarade as somebody else this way.f
- ICMP Redirects
- Many opperating systems support ICMP Redirects, where you can tell a machine to forward
packets through you rather than the local router.
- ICMP Router Advertisements
- A different variation of ICMP that does much the same as redirects: convinces a machine
that you are the correct router.
In all of these cases, you have to configure your machine to further pass along the
traffic to the real destination.
3.5 How can I sniff DSL segments?
See the cable-modem section above.
3.6 How can I create a receive-only Ethernet adapter?
By clipping the "transmit" wires.
The easiest system to clip is 10-mbps using the old AUI transceiver. Note that in
today's networking, such equipment is hard to find and expensive to buy "new",
but littered all over the place as used equipment. You should consider stockpiling such
equipment now, especially PCI Ethernet cards with transceivers.
Other forms of Ethernet are not easily altered. Thin-coax Ethernet uses the same wire
for both transmitting/receiving. 10-BASE-T Ethernet requires a link heartbeat on the
transmit line so that the hub knows it is connected. In short, only the AUI port contains
pins that can be clipped without affecting the operation of the device.
\ . . . . . . . . /
\ . . . . . . . /
Pin Sgnl Description
2 CI-A Control In Circuit A
3 DO-A Data Out Circuit A
5 DI-A Data In Circuit A
6 VC Voltage Common
9 CI-B Control In Circuit B
10 DO-B Data Out Circuit B
12 DI-B Data In Circuit B
13 VP +12 Volts DC
Cutting pings 3 and 10 will stop transmission. The easiest way is to clip the pins on
the connector rather than the wire itself.
Creating UTP receive-only adapters is harder. Ethernet hubs check the "link
integrity" with the adapter, which is done by sending a regular voltage pulse down
the wire. On 100BaseTX, the problem is even more difficult because both sides send a
steady stream of empty traffic down the wire. Therefore, you can't simply cut the transmit
wires, because the hub will think the adapter is no longer there, and disconnect it.
However, you can "denature" the wire, introducing CRC errors that disrupt
outgoing frames, but which still allows the stream of symbols from the card and/or link
integrity pulses. This is actually a problem you may have encountered before: the link
lights on the hub and adapter show a connection, but you cannot communicate on the
network. Ethernet is actually very robust, so creating such a cable is difficult.
The high-speed integrity is maintained by using two wires for each signal, and twisting
the wires around each other. You can think of it as one wire shielding the other, or that
any electrical disturbance affects both equally, and since the difference in
voltage is measured, it all evens out (Geek note: differential SCSI or Ultra-DMA/66 cables
are based on the same principle).
As a consequence, simply "untwisting" the transmit pair will degrade the
signal to the point that outgoing traffic will be corrupted with CRC erros, yet the hub
will still get enough of a signal to know the adapter is still there.
Pin MDI signal MDI-X signal
1 TD+ xmit to UTP RD+ rcv from UTP
2 TD- xmit RD- rcv from UTP
3 RD+ rcv from UTP TD+ xmit to UTP
4 Not used Not used
5 Not used Not used
6 RD- rcv from UTP TD- xmit to UTP
7 Not used Not used
8 Not used Not used
In order to denature it, you must use a 4-pair cable where normally two of the pairs
are unused. Each twisted-pair is color coded, with COLOR-stripes on white for one wire,
and white-stripes on COLOR for the other wire. In the above diagram, the transmit pair is
normally orange/white, whereas the receive pair is normally green/white (for the AT&T
or EIA/TIA 568B standard). However, the EIA/TIA 568A standard reverses these colors
(aargg). Therefore, all you are worried about is that pins 3 and 6 must share the
same color, but in order to denature the transmit pair, pins 1 and 2 must NOT share a
color. Pick any of the others, it doesn't matter. Both ends of the cable must be wired
You should make this a long cable, as long as the standard will allow. The
problem is that it doesn't always degrade the signal enough, so the longer the better
(I've used 40-feet, but still about 5% of the transmitted frames still get through).
Furthermore, you should use 100-mbps (100-BASE-TX) for this, as the signal degrades
easier. I've never tried with 10-mbps.
However, this approach still leaves the possibility that somebody might "fix"
this by replacing the bad cable with a good one. An alternate technique involves altering
the NIC itself, inside the box where nobody can accidentally fix it. In this case, instead
of clipping the wire you should add something to it. Most adapters leave the traces
exposed (though some are beginning to shield the RJ45 connector, but you can easily peel
back the shielding). Solder a paperclip or wire onto the transmit pin #1 on the backside
of the connector. Adjust the length as needed until the transmission is screwed up. I've
never tried this, so if you get it to work, please drop me e-mail.
Using either of these techniques may cause the FCC to come after you because of radio
wave transmission. The computer case should shield the altered adapter, but I make
Another proposal is to create a circuit to generate the symbols. This may be easy for
hardware engineers, but I'm a software engineer and have never done it.
For security reasons. Networking is full of accidents waiting to happen, which
crackers/hackers exploit in order to break into systems. Clipping the transmit wires on an
Ethernet adapters generates a "one-way-drop" that can receive data, but cannot
be compromised by a hacker through some accident.
- Receiving syslog messages and storing them to a non-compromisable system. The 'syslog'
protocol is used by numerous UNIX services to log security events, and is based upon UDP
so one-way datagrams can be used forward to a device that cannot respond. ARP and route
tables need to be manually configured to ensure this operation.
- Similarly receiving SNMP traps, which also use UDP. Many systems generate SNMP traps in
response to security related events.
- Promiscuous packet capture. Many systems will dump ethernet traffic to disk files on the
fly. By setting up a receive-only system on a potentially insecure network, you don't risk
adding another security hole to the system.
Some people have suggested this as a way to conceal a wiretap from sniffer-detection
programs. This is overkill: in order to conceal yourself, you simply unbind the TCP/IP
stack or install firewall filters on the machine. This approach is not adequate for the
one-way-drops mentioned above because of the ease at which such functionality can be
3.7 What about eavesdropping on wireless like IEEE 802.11 a.k.a. AirPort?
In late 1999, Apple released their iBooks and at the same time their AirPort wireless
networking. This is actually an implementation of the IEEE 802.11 wireless standard, which
in theory means that both Apple computers and Windows-based PCs (as well as a host of
other equipment) should be able to use the same wireless infrastructure. For example, a
person with a Nokia wireless PCMCIA adapter in their notebook should be able to connect
via TCP/IP to an AirPort base station (and be configured automatically via DHCP).
are two IEEE 802.11 standards, one for 2-mbps and one for 11-mbps. This discussion focuses
on the 2-mbps standard.
The first question dealing with sniffing is the signaling. This wireless standard uses
"spread spectrum" technology.
- Rather than transmitting data at a single frequency, data is transmitted over a range of
- This makes it more immune to electronic noise.
- It allows many users to share the same spectrum like cellular. In fact, CDMA, a cellular
technology, uses spread spectrum, where each "code" (code division multiplexing)
determines the sequence used to "spread" the signal.
- In theory, spread-spectrum makes it impossible to eavesdrop. The eavesdropper would need
to know the "spreading" function used.
Spread-spectrum technology came out of the cold war as a way of sending signals that
were near impossible to eavesdrop on. The theory is that an eavesdroppper only hears
whitenoise, and that even proving there is a signal could be difficult.
However, this assumed that you could securily communicate the "spreading
function" to both the transmitter and receiver. This isn't reasonable in
consumer-grade products that we'll be buying. The keys will be distributed manually.
Moreover, there aren't that many keys. The upshot is that spread-spectrum has little
impact as an anti-sniffing countermeasure. To be fair, it isn't intended to be -- it's
used in wireless communication for its anti-noise, bandwidth-sharing capabilities.
Security will be accomplished via standard digital encryption techniques (see below).
The spectrum used by the standard is 2.400 GHz to 2.4835 GHz, though in theory
different frequencies are defined for Japan and Europe.
Roughly 100-meters (300-feet) indoors and 300-meters (1000-feet) outdoors. Estimates
indicate that a base station will be able to communicate one floor in each direction. In
extreme office conditions, vendors are quoting about 20-meters. However, with parabolic
antennas, eavesdroppers can receive signals from much further away.
In theory, any IEEE 802.11 compliant device can eavesdrop on all the packets that are
within range. (Though, of course, the may need to decrypt it as well).
A method called "Wired Equivalent Privacy (WEP)" is used. This is based upon
the RC4 encryption protocol with 40-bit keys. This is essentially the same protocol used
by web-browsers for secure connections. RC4 supports up to 128-bit encryption, but the
802.11 standard is at 40-bit encryption for export purposes. Some vendors are providing
more bits in the security key, for example Lucent is selling their "WaveLAN
Gold" cards supporting 128-bit encryption (though it appears that 128-bit is
available outside the US, not inside, as it was developed outside the US and Lucent is
protesting US export restrictions by not selling the stronger version inside the US).
WEP only protects the data portion. This means that a sniffing machine can decode the
physical layer transmissions, but must decrypt the data portion.
WEP uses a "shared-key" architecture. This is actually a very bad design,
because it requires users to enter in their keys in order to use the network. These keys
can will likely be based upon passwords, which usually result in effective keys even less
than 40-bits. In contrast, web-browsers using SSL are able to encrypt data with no
predetermined shared key.
WEP is optional, by default it is turned off. We will have to see in the future how
often it really is used. For example, WEP is not practical for "ad-hoc" networks
(peer-to-peer networks); it is more useful with the use of Access Points (APs). From the
look of it, vendors are selling the encryption feature as an "add-on" as well.
This bodes well for malicious packet sniffers.
To summarize encryption: it will make sniffing difficult, but not impossible. Most
people won't use encryption, but even then it will be easy to decrypt the 40-bit encrypted
messages. Specialized hardware could be built to recover the key in near real time, but
also distributed computing power (like http://www.distributed.net/)
can also be used to recover keys. In particular, because the data portion is very well
known (IP headers), it is susceptible to a "known plaintext" attack.
A security concern related to sniffing is simple access. Someone can walk into a
building with a notebook computer, which can connect to the network behind the firewall.
Internal networks tend to be insecure, so this is a real danger. The WEP protocol has a
number of features to prevent this, such as the ability to hard-code MAC addresses into
the base-stations specifying who may connect to the network.
Users can rove around a network, and be handed off from area-to-area much like
cell-phones. A unit maintains the same MAC address and IP address, but changes who it's
talking to. This means that the backbone to handle this has to be switched Ethernet or ATM
with VLANs. In theory, you could walk around a company and have your notebook beep at you
as soon as it finds an area where computers are talking unencrypted.
Several companies are equiping places like airports with access stations that allow you
to surf online. The WEP protocol as no support for this type of authentication (shared
secrets suck). These companies plan on charging connect time, but you could equally have
fun by sitting down with your notebook and sniffing everyone else connected to the web.
Have fun reading their e-mail, eavesdropping on their chatrooms, and the like.
3.8 How can I sniff a switched network?
In theory, you cannot sniff a switched network. All that the sniffing would do would be
to see your own traffic anyway. In practice, there are numerous ways.
- 3.8.1 Switch Jamming
- Some switches can be kicked out of "bridging" mode into "repeating"
mode where all frames are broadcast on all ports all the time. This is done by overflowing
the address tables with lots of false MAC addresses. This can be done with a simple
traffic generation phase, or by sending a continual stream of random garbage through the
switch. In security terms, this is known as "fail open" behavior rather than
"fail close", meaning that when the device fails, security provisions are
removed. Of course, switches aren't really designed with security in mind.
See the HUNT
Project at http://www.cri.cz/kra/index.html
for more info.
- 3.8.2 ARP Redirect
- ARP packets contain both the local binding as well as the desired binding. For example,
let's say that Alice wants to find Bob's Ethernet MAC address. Bob has an IP address of
"192.0.2.1". Alice would send out an ARP request with the following information.
||?? ?? ?? ?? ?? ??
The entire exchange might looke like the diagram below. Alice has an IP packet of some
sort (let's say an ICMP ping) to send to Bob. In order to find Bob's MAC address, Alice
ARPs it. Bob responds to Alice, telling her his MAC address. Now Alice sends her IP packet
to that Ethernet MAC address.
Alice ----> ARP broadcast request ----> Bob
Alice <---- ARP unicast response <---- Bob
Alice ----> ICMP ping request ----> Bob
Alice <---- ICMP ping response <---- Bob
Alice <---- ICMP ping request <---- Charles
Now Bob has an IP packet to send to Alice. In theory, Bob would need to ARP Alice in
order to find her MAC address. But he doesn't. This is because he has remembered her MAC
address information that was sent in the original ARP request.
In fact, everyone on the local Ethernet saw that request since it was broadcasted. So
if Charles at this point wants to ping Alice, he doesn't need to ARP her either, even
though he wasn't involved with the original exchange.
Broadcasts are sent to everyone on an Ethernet switch. Therefore, you can subvert the
switch by sending out ARPs claiming to be somebody else as the source address. You can
broadcast out an ARP claiming to be the router, in which case everyone will try to route
through you. Or you can send an ARP request just to the victim's MAC address, claiming to
be the router, at which point just the victim will forward packets to you. Conversely, you
can send an ARP to the router's MAC address claiming to be the victim.
In all these cases, you must be prepared to forward packets in the real direction,
otherwise you cut off communication.
See http://www.zweknu.org/src/MiM/ for
some sample programs.
- 3.8.3 ICMP Redirect
- An ICMP redirect tells a machine to send its packets in a different direction. A typical
example is when there are two logical subnets on the same physical segment. Alice is on
one subnet talking to Bob on another subnet. Neither knows they are on the same physical
segment, but the local router knows. When Alice sends the router a packet destined for
Bob, the router sends an ICMP Redirect to Alice informing here of the fact that she can
send the packet to Bob directly.
A hacker (Mark) can subvert this by sending a redirect
to Alice claiming that she should send him Bob's packets.
- 3.8.4 ICMP Router Advertisements
- ICMP Router Advertisements inform people who the router is. A hacker can send these
packets out claiming to be a router; people will believe them and start forwarding their
traffic through that person.
Luckily, many machines don't support this feature because
it is relatively new. Now that the security implications are well known, many new systems
still won't support it.
for more information.
- 3.8.5 Fake the MAC address of the victim
- The idea is to cause the switch to start fowarding you the frames destined to the
victim. You can do this simply by sending out frames with the source address of the
victim. The "auto-learning" feature of the switch will now believe you are the
victim, and send frames your way.
The obvious problem is that victim itself will still
send out frames with its MAC address (cuasing the switch to revert). Another problem is
that if the victim doesn't receive the frame, then its communications breaks, and there
won't be anything more to sniff.
There are a few solutions to this problem, depending upon what you want to do. You may
want to subvert an authenticated connection, in which case you DoS the victim (taking it
offline), redirect the switch, and continue on with the connection as if nothing happened.
For example, let's say that Alice has a Telnet connection to the BOB server. You DoS
Alice's machine, taking her off line. You then send out packets with Alice's MAC address,
causing the switch to send you all packets destined for her. In order to pick up her
connection, you cause the server to send you a TCP packet (i.e. use the talk service to
prompt her for a connection). At this point, you simply start reversing the sequence and
acknowledgement numbers to continue the Telnet connection.
Another solution to this problem is to "sample" traffic. Send out packets
with the victim's MAC on occasional intervals. You'll likely get the next few packets
destined for the victim, but the victim will timeout and recover the connection. The
victimized user will notice occasional network delays.
A similar solution is that when you receive an incoming packet, turn around and broadcast
it back out. This way the victim still receives the packet. A steady stream of outgong
traffic and broadcasts of the incoming traffic will allow you to recover a good percentage
of the original traffic.
- 3.8.6 Reconfigure span/monitor port on switch
- Most switches allow ports to be configured as "monitor" or "span"
ports that will copy some or all of the traffic going across the switch. In fact, these
ports are designed for packet sniffers when the network administrator needs to solve a
In many cases, a hacker can telnet to the switch or reconfigure it with SNMP.
Most switches are installed with default or backdoor passwords.
SNMP is particularly fun because the hacker can 'grind' through all the passwords until
he/she finds the correct one (though most come default with "public" or
"private"). In some cases, the network admin configures the switch to only allow
SNMP from the IP address of the network management console. However, this same network
management console will likely be sending other SNMP packets about: sniffing broadcasts or
just incoming SNMP directed at the host will likely reveal who the SNMP management console
is, at which point IP spoofing can be used to manage the switch. Similarly DNS Zone
Transfers might reveal suggestive names such as "hpov.example.com" (hpov = HP
OpenView, a popular SNMP console).
- 3.8.7 Cable-taps
- You can tap into full-duplex Ethernet cable. A couple vendors make products that do this
for you. Some features of these products are:
- Your packet sniffer needs two Ethernet adapters to receive the send/receive channels.
Most products support sniffing from only a single adapter at a time, which means you can
only sniff from one channel at a time.
- All the products I know are fault tolerant, which means that if the power fails on the
box, they will not interupt the flow of traffic.
Of course, you caa always tap into cables between switches or between an important host
and a switch. Vendors of cable-taps are:
- The "Century Tap"
family is used for this purpose. The basic tap works as described above. They also have a
fiber-optic tap. Finally, they have a 12-port tap that allows roving analysis on twelve
- They not only have the basic tap, but also one that support fiber-optics as well. Since
they don't make their own protocol analyzer, they resell their products for other packet
- Rather than a passive tap described above, they have a full "pod" that does
packet capture and filtering on the unit itself. It contains several Ethernet chips, CPUs,