Mr Tweaks - Back to homepage

Shop | How to | Reg Edit Tips | Got An Error? | Mac Tips | About Us | Products Page | Tips | Cable & ADSL | News & Events | Strange Tips | Contact Us | Links | Security


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
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 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. (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).
EtherPeek I think you can download a trial-ware version.
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.
Analyzer: a public domain protocol analyzer
A toolkit for doing various kinds of analyses.
Other Windows...
There are a larger number of Windows-based sniffing programs, many of which can be downloaded and installed like any other application.


EtherPeek 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

The original version from LBL is at

A port for Windows has been done at

It currently looks like this is the best GUI-based sniffing program for UNIX. It is actively maintained. It is available at:
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'.
sniffit Useful when trying to analyze application-layer data.
A libpcap based packet-sniffer/logger with extensive filtering.
Contains tcpdump and sniffit, among numerous other security utilities on a floppy bootable disk.
karpski 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 Esniff only runs on older SunOS platforms, so it really isn't relavent today.
exdump 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.
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.
Klos PacketView
A low-end DOS product.


Here are some other utilities that aren't classified above.
A sniffing program dedicated to SNMP.

3.2 Where can I get a utility to inject strangely formatted packets onto the wire?


libnet 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.

rootshell contains a number of "exploit" scripts (such as bonk, teardrop, etc.) that demonstrate injecting raw packets onto the wire.


ipsend 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

A Tcl/Tk based software toolset for protocol developement.


A PERL-based 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.

Vendor Diversity

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 into connections:

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.

Clipping the AUI

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.

     1               8          
    \ . . . . . . . . /         
     \ . . . . . . . /          
        9         15            
Pin  Sgnl  Description          
 1   GND                        
 2   CI-A  Control In Circuit A 
 3   DO-A  Data Out Circuit A   
 4   GND                        
 5   DI-A  Data In Circuit A    
 6   VC    Voltage Common       
 7   -                          
 8   GND                        
 9   CI-B  Control In Circuit B 
10   DO-B  Data Out Circuit B   
11   GND                        
12   DI-B  Data In Circuit B    
13   VP    +12 Volts DC         
14   GND                        
15   GND                        

Cutting pings 3 and 10 will stop transmission. The easiest way is to clip the pins on the connector rather than the wire itself.

Clipping the UTP (10-BASE-T, 100-BASE-TX)

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 the same.

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 no guarantees.

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.

Why would I want to do this?

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 accidentally re-enabled.

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).

There are two IEEE 802.11 standards, one for 2-mbps and one for 11-mbps. This discussion focuses on the 2-mbps standard.

Spread Spectrum

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 frequencies.
  • 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.

Signal range

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 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 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 "". Alice would send out an ARP request with the following information.
Operation: Request
Alice: 00-40-05-A4-79-32
Bob: ?? ?? ?? ?? ?? ??

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 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.

See 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 problem.

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 = 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 full-duplex lines.
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 sniffer companies.
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, and memory.

Click Here!