Copyright 1998-2000 by Robert Graham (sniffing-faq@robertgraham.com. All rights reserved. This document may be only be reproduced (whole or in part) for non-commercial purposes. All reproductions must contain this copyright notice and must not be altered, except by permission of the author.Official source of this document:
Trevor Schroeder from http://www.zweknu.org
Lachlan M. D. Cranswick <l.cranswick at dl dot ac dot uk>
However, computer conversations consist of apparently random binary data. Therefore, network wiretap programs also come with a feature known as "protocol analysis", which allow them to "decode" the computer traffic and make sense of it.
Sniffing also has one advantage over telephone wiretaps: many networks use "shared media". This means that you don't need to break into a wiring closet to install your wiretap, you can do it from almost any network connection to eavesdrop on your neighbors. This is called a "promiscuous mode" sniffer. However, this "shared" technology is moving quickly toward "switched" technology where this will no longer be possible, which means you will have to actually tap into the wire.
Sniffing programs have been around for a long time in two forms. Commercial packet sniffers are used to help maintain networks. Underground packet sniffers are used to break into computers.
Typical uses of such wiretap programs include:
Think of it this: you have two machines in your own office talking to each other, and both are on the Internet. They take a direct route of communication, and the traffic never goes across the outside public portion of the Internet. Any communication anywhere in the net follows a similar "least-cost-path" principle.
This implies that all machines are able to "see" all the traffic on the same wire.
Thus, Ethernet hardware is built with a "filter" that ignores all traffic that doesn't belong to it. It does this by ignoring all frames whose MAC address doesn't match.
A wiretap program turns off this filter, puttin the Ethernet hardware into "promiscuous mode". Thus, Mark can see all the traffic between Alice and Bob, as long as they are on the same Ethernet wire.
This is accomplished by putting a unique 12-digit hex number in every piece of Ethernet hardware. Section 1.5.4 explains how to discover the Ethernet MAC address of your own machine.
To really understand why this is so important, you might want to review the information in section 5.4 below. Ethernet was designed to carry other traffic than just TCP/IP, and TCP/IP was designed to run over other wires (such as dial-up lines, which use no Ethernet). For example, many home users install "NetBEUI" for File and Print Sharing because it is unrelated to TCP/IP, and therefore hackers from across the Internet can't get at their hard-drives.
Raw transmission and reception on Ethernet is governed by the Ethernet equipment. You just can't send data raw over the wire, you must first do something to it that Ethernet understands. In much the same way, you can't stick a letter in a mailbox, you must first wrap it in an envelope with an address and stamp.
Following a is a brief explanation how this works:
_________
/.........\
/..Internet.\
+-----+ +------+.........+---+
|Alice|-----|ROUTER|.........|Bob|
+-----+ ^ +------+.........+---+
| \.........../
| \---------/
+-------+
|wiretap|
+-------+
Alice has IP address: 10.0.0.23In order to talk to Bob, Alice needs to create an IP packet of the form 10.0.0.23-->192.168.100.54
As the packet traverses the Internet, it will be passed from router-to-router. Therefore, Alice must first hand off the packet to the first router. Each router along the way will examine the destination IP address (192.168.100.54) and decide the correct path it should take.
In the able diagram, we draw the Internet as a "cloud". All Alice knows about is the local connection to the first router, and Bob's eventual IP address. Alice knows nothing about the structure of the Internet and the route that packet will take.
Alice must talk to the router in order to send the packet. She uses the Ethernet to do so. An Ethernet frame looks like the following:
+--+--+--+--+--+--+ | destination MAC | +--+--+--+--+--+--+ | source MAC | +--+--+--+--+--+--+ |08 00| +--+--+-----------+ | | . IP . . packet . . . | | +--+--+--+--+-----+ | CRC | +--+--+--+--+What this means is that the TCP/IP stack in Alice's machine might create a packet that is 100 bytes long (let's say 20 bytes for the IP info, 20 bytes for the TCP info, and 60 bytes of data). The TCP/IP stack then sends it to the Ethernet module, which puts 14 bytes on the front for the destination MAC address, source MAC address, and the ethertype 0x0800 to indicate that the other end's TCP/IP stack should process the frame. It also attaches 4-bytes on the end with a checksum/CRC (a validator to see if the frame gets corrupted as it goes across the wire).
The adapter then sends the bits out onto the wire.
All hardware adapters on the wire see the frame, including the ROUTER's adapter, the packet sniffer, and any other machines. Proper adapters, however, have a hardware chip that compares the frame's "destination MAC" with its own MAC address. If they don't match, then it discards the frame. This is done at the hardware level, so the machine the adapter is attached to is completely unaware of this process.
When the ROUTER ethernet adapeter sees this frame, it reads it off the wire and removes the leading 14-bytes and the trailing 4-bytes. It looks at the 0x0800 ethertype and decides to send it to the TCP/IP stack for processing (which will presumably forward it to the next router in the chain toward the destination).
In the above scenario, only the ROUTER machine is supposed to see the Ethernet frame, and all other machines are supposed to ignore it. The wiretap, however, breaks the rules and copies the frame off the network, too.
See Charles Spurgeon's Ethernet website at: http://wwwhost.ots.utexas.edu/ethernet/ethernet-home.html
The logic behind this is that the Ethernet has multiple sublayers, PHY, MAC, LLC. The Ethernet address is considered part of the MAC sublayer.
However, the OUI is really only 22-bits long, two of the bits in that field are used for other purposes. One bit indicates if the address is a "broadcast/multicast" address, the other bit indicates if the adapter has been reassigned a "locally administered address" (where a network administrator reassigns the MAC address to fit some local policy).
For example, you will commonly see the MAC address 03 00 00 00 00 01
on the wire. The first byte contains the binary representation of 00000011
where both these special bits are set (and the rest are zero). This is a special
multicast packet that is sent to all machines that run the "NetBEUI" protocol
(which is commonly installed on Windows machines to share files locally without
using TCP/IP as the transport).
The IEEE maintains the list of vendor/OUI codes at http://standards.ieee.org/regauth/oui/.
Windows NT IP Configuration
Host Name . . . . . . . . . : sample.robertgraham.com
DNS Servers . . . . . . . . : 192.0.2.254
Node Type . . . . . . . . . : Hybrid
NetBIOS Scope ID. . . . . . :
IP Routing Enabled. . . . . : No
WINS Proxy Enabled. . . . . : No
NetBIOS Resolution Uses DNS : No
Ethernet adapter SC12001:
Description . . . . . . . . : DEC DC21140 PCI Fast Ethernet Adapter
Physical Address. . . . . . : 00-40-05-A5-4F-9D
DHCP Enabled. . . . . . . . : No
IP Address. . . . . . . . . : 192.0.2.160
Subnet Mask . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . : 192.0.2.1
Primary WINS Server . . . . : 192.0.2.253
eth0 Link encap:Ethernet HWaddr 08:00:17:0A:36:3E
inet addr:192.0.2.161 Bcast:192.0.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1137249 errors:0 dropped:0 overruns:0
TX packets:994976 errors:0 dropped:0 overruns:0
Interrupt:5 Base address:0x300
In other words, you are asking about this scenario:
The answer is of course "no", it isn't even remotely possible. You have to have access to the wire that the communication is going across in order to eavesdrop. Same as with telephones, same as everywhere.
Remote access to the wire
However, if you are a really, really good cracker/hacker, there are ways of getting access to those lines. Typical examples are:
Close to the wire
In some situations, like cable-modems, DSL, Ethernet VLANs, etc., you can redirect traffic between two people to go through your own machine. This is because while you are not directly in the path of communication, you can sometimes move that path to flow past your own computer. It's much like the concept that you can divert a stream slightly, though not very far. See the "Redirect section under Cable-Modems.
"Secure Sockets Layer", SSL is built into all popular web browsers and web servers. It allows encrypted web surfing, and is almost always used in e-commerce when users enter their credit card information.
This site for Apache SSL describes this: http://www.modssl.org/
E-mail can be sniffed in many alternative ways. It passes through corporate firewalls, which may monitor the traffic. It often gets logged and saved for extended periods of time. It may get accidentally misdirected, and end up in somebody else's mailbox. The best way to keep such e-mail secret is to encrypt it. The two common ways of doing this are with PGP (Pretty Good Privacy) and S/MIME (Secure MIME). PGP can be purchased as an add-on to many products. S/MIME is built into e-mail programs by Netscape and Microsoft.
"Secure Shell", ssh has become the de facto standard for logging into UNIX machines from the Internet. You should immediately replace telnet with this service. Numerous other protocols can be tunneled through ssh connections (i.e. file copy). The product was originally developed by a Finish company http://www.ssh.fi/ but many open-source/freeware implementations also exist.
VPNs provide encrypted traffic across the Internet. However, if a hacker compromises the end-nodes of a VPN connection, they can still sniff the traffic. A typical scenario is an end-user who surfs the Internet normally and gets compromised with a Remote Access Trojan (RAT) that contains a sniffing plug-in. When the user establishes the VPN connection, the sniffing program is able to see not only the encrypted traffic that can be seen on the Internet, but also the unencrypted traffic before it gets sent through the stack to the VPN.
In the Windows/SAMBA environment, make sure that you have the older LanManager authentication turned off. This requires SAMBA v2 or later, WinNT SP3 or later, and so on.
Both Windows 2000 and UNIX provide support for Kerberos authentication. This is one of the strongest generic mechanisms available. ftp://aeneas.mit.edu/pub/kerberos/doc/KERBEROS.FAQ
There are numerous smart card implementations around providing one-time passwords. These are often used when connecting remotely, either dial-in or VPN across the Internet.
Enhancements to Telnet and FTP for UNIX and Windows. http://srp.stanford.edu/srp/
Replacing your hub with a switch will provide a simple, yet effective defense against casual sniffing.
While this solution is extremely effective in practice (and should be strongly considered), it shouldn't be relied upon as a complete defense against sniffing. A switch still creates a "broadcast domain", providing an attacker the ability to spoof ARP packets.
The easiest such exploit is the "router redirection". ARP queries contain the correct IP-to-MAC mapping for the sender. In order to reduce ARP traffic, most machines will cache this information that they read from the query broadcasts. Therefore, a malicious attacker can redirect nearby machines to forward traffic through it by sending out regular ARP packets containing the router's IP address mapped to its own MAC address. All the machines on the local wire will believe the hacker is the router, and therefore pass their traffic through him/her.
A similar attack would be to DoS a target victim and force it off the network, then begin using its IP address. If a hacker does this carefully, s/he can inherit connections already established without dropping them. Windows machines are even so polite that when they come onto the network and see someone else using their address, they will kindly shut down their own TCP/IP stacks and allow this to continue. SMB (the Windows file sharing protocol) is also kind enough to allow predictable identifiers, allowing cr/hackers to predict enough information to keep the connection going.
Most intrusion detection systems and even network management tools like the Expert Sniffer(tm) will detect these shenanigans. For example, putting the BlackICE IDS on all the Windows end-nodes or hooked to a normal port (to receive broadcasts) will alert the security admin that such things are taking place (but, will generate false positives when DHCP reassigns addresses. Sigh.)
Most Ethernet adapters allow the MAC address to be manually configured. Thus a hacker can spoof MAC addresses by reassigning the address on the adapter, or by bypassing the built-in stack and hand-crafting frames. The hacker must maintain a a constant stream of outgoing frames in order to convince the auto-learning switch that they are the legitimate owner of the MAC address.
Many (most??) switches allow MAC addresses to be configured statically in order to prevent this sort of thing. While it may be a difficult management burden to do this for all end-nodes, it may prove useful for the router, restricting the hacker to wiretapping individual end-nodes instead of everyone all at once.
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.
The real answer is "yes", there are some older adapters that do not support promiscuos mode. In particular, the original IBM Token Ring adapters (TROPIC chipset) were not able to run in promiscuous mode. There are also a few Ethernet where promiscuous mode is broken, either in the hardware or in the driver. Actually, there are far more adapters who simply lack the functionality in the driver in order to turn on promiscuous mode, meaning all programs that attempt to put them into promiscuous mode will fail even though the hardware supports the mode in theory. If you really must have one, then call technical support for a sniffing product vendor (such as NAI) and ask them which cards they DON'T support. For Windows, you might check with Microsoft support to see which cards do not support NetMon (I remember there are a few, but I can't find the documentation for it).
Note that in the Intel/Microsoft "PC99" guidelines, promiscuous mode is a "required" feature.
If this is a concern, it will be cheaper in the long run simply to upgrade to switching hubs, which basically does the same thing. An Ethernet switch moves the "address match" upstream, so that the switch does it rather than the adapter.
Finally, it should be noted that most new networks are switched in some fashion. Even though hackers cannot sniff an entire Ethernet segment, they still install sniffers on machines in order to see the incoming/outgoing traffic. A non-promiscuous adapter won't help defend against this.
A stand-alone packet sniffer doesn't transmit any packets, but when installed non-standalone on a normal computer, the sniffing program will often generate traffic. For example, it might send out DNS reverse lookups in order to find names associated with IP addresses.
Non-standalone packet sniffers are indeed what you want to detect. When crackers/hackers invade machines, they often install sniffing programs. You want to be able to detect this happening.
General Overview of Detection Methods
Most "packet sniffers" run on normal machines with a normal TCP/IP stack. This means that if you send a request to these machines, they will respond. The trick is to send a request to IP address of the machine, but not to its Ethernet adapter.
To illustrate:
There are ways defending against this. Now that this technique
is widely publicized, newer hackers will enabled a virtual
MAC address filter in their code. Many machines (notably Windows)
have MAC filtering in drivers. (There is a hack for Windows:
most drivers just check the first byte, so a
MAC address of
This technique will usually work on switched/bridged Ethernets. When switches see an unknown MAC address for the first time, they will "flood" the frame to all segments.
The ping method can be enhanced in a number of ways:
The ARP method is similar to the ping method, but an ARP packet is used instead. An explanation (in Spanish) is given at http://www.apostols.org/projectz/neped/ which includes a program to do this detection.
The simplest ARP method transmits an ARP to a non-broadcast address. If a machine responds to such an ARP of its IP address, then it must be in promiscuous mode.
A variation of this technique takes advantage of the fact that machines "cache" ARPs. Each ARP contains the complete information of both the sender as well as the desired target information. In other words, when I send out a single ARP to the broadcast address, I include my own IP-to-Ethernet address mapping. Everyone else on the wire remembers this information for the next few minutes. Therefore, you could do something like sending out a non-broadcast ARP, then a broadcast ping. Anybody who responds to your ping without ARPing you could only have gotten the MAC address from a sniffed ARP frame. (To make double-sure, use a different source MAC address in the ping).
Many sniffing programs do automatic reverse-DNS lookups on the IP addresses they see. Therefore, a promiscuous mode can be detected by watching for the DNS traffic that it generates.
This method can detect dual-homed machines and can work remotely. You need to monitor incoming inverse-DNS lookups on the DNS server in your organization. Simply do a ping sweep throughout the company against machines that are known not to exist. Anybody doing reverse DNS lookups on those addresses are attempting to lookup the IP addresses seen in ARP packets, which only sniffing programs do.
This same technique works locally. Configure the detector in promiscuous mode itself, then send out IP datagrams to bad addresses and watch for the DNS lookups.
One interesting issue with this technique is that hacker-based sniffing programs tend to resolve IP addresses as soon as they are found, whereas commercial programs tend to delay resolution until the point where the packet sniffer user views the protocol decodes.
Another technique involves configuring the source-route information inside the IP header. This can be used to detect packet sniffers on other, nearby segments.
Details:
In loose source-routing, an option is added to the IP header. Routers will ignore the destination IP address and instead forward to the next IP address in the source-route option. This means when you send the packet, you can say "please send packet to Bob, but route it through Anne first".
In this scenario, both "Anne" and "Bob" are on the segment. Anne does not route, and therefore will drop the packet when received. Therefore, "Bob" will only respond if he has sniffed the packet from the wire.
On the off chance that Anne does indeed route (in which case Bob will respond), then the TTL field can be used to verify that Bob responded from routing through Anne, or answering directly.
Whereas the ping and ARP methods only work on the local network, the decoy method works everywhere.
Since so many protocols allow "plain text" passwords, and hackers run sifters looking for those passwords, the decoy method simply satisfies that need. It consists simply of setting up a client and a serve on either side of the network, which the client runs a script to logon to the server using Telnet, POP, IMAP, or some other plain-text protocol. The server is configured with special accounts that have no real rights, or the server is completely virtual (in which case, the accounts don't really exist).
Once a hacker sifts the usernames/passwords from the wire, he/she will then attempt to log on using this information. Standard intrusion detection systems or audit trails can be configured to log this occurance, alerting the fact that a sniffing hacker has found the traffic and attempted to use the information.
http://www.zurich.ibm.com/~dac/Prog_RAID98/Full_Papers/sniffer_detector.html/index.htm
When hackers break into your systems, they will often leave behind wiretap programs running in the background in order to sniff passwords and user accounts off the wire. These are often imbedded (as a trojan) in other programs, so the only way to find if something like this is running is to query the interfaces to see if they are running in promiscuous mode.
The most technique is to run the program "ifconfig -a". On my computer (Solaris 2.6) the output looks like:
# ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,MULTICAST> mtu 1500 inet 192.0.2.99 netmask ffffff00 broadcast 192.0.2.255 ether 8:0:20:9c:a2:98Of course, the first thing a hacker will do is replace the 'ifconfig' program to hide this. There are other utilities you can download from the net that will query the hardware directly in order to discover this information, or you could run the 'ifconfig' program directly from a CD-ROM distribution.
This is a more evil method. On one hand, it can significantly degrade network performance. On the other hand, it can 'blind' packet sniffers by sending too much traffic.
This method functions by sending huge quantities of network traffic on the wire. This has no effect on non-promiscuous machines, but has a huge effect on sniffing machines, especially those parsing application layer protocols for passwords. Simply ping the machine before the load and during the load and testing the difference in response time can indicate if the machine is under load.
One problem with this technique is that packets can be delayed simply because of the load on the wire, which may case timeouts and therefore false positives. On the other hand, many sniffing programs are "user mode" whereas pings are responded to in "kernel mode", and are therefore independent of CPU load on a machine, thereby causing false negatives.
A TDR is basically RADAR for the wire. It sends a pulse down the wire, then graphs the reflections that come back. An expert can look at the graph of the response and figure out if any devices are attached to the wire that shouldn't be. They also roughly tell where, in terms of distance along the wire, the tap is located.
This can detect hardware packet sniffers that might be attached to the wire, but which are completely silent otherwise.
TDRs used to be used a lot in the old days of coax Ethernet in order to detect vampire taps, but these days with star topologies, they are used very rarely.
There also exist OTDR equipment, but this is really only for the truely paranoid.
You can manually check hub-lights to see if there are any connections you don't expect. It helps to have labeled cables to figure out where (physically) a packet sniffer might be located.
Smart hubs with SNMP management can provide automated monitroning of Ethernet (and other) hubs. Some management consoles will even let you log connections/disconnections to all your ports. If you've configured the system with the information where all the cables terminate, you can sometimes track down where a packet sniffer might be hiding.
Tools to detect packet sniffers
The most comprehensive sniffer-detection tool.
A tool from Carnegie-Mellon that checks to see if promiscuous mode is enabled on a UNIX machine.
A tool from The Apostols that detects packet sniffers running on the local segment.
Other Sniffing Detection Resources
http://www.securiteam.com/unixfocus/Detecting_sniffers_on_your_network.html
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.
ftp://ethereal.zing.org/pub/ethereal/win32/
Installation is a little difficult; you'll have to hunt around on the website in order to figure out how to do it.
If you have a UNIX computer, then you should be using both tcpdump and Ethereal.
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/
Thanks to < cripto at datasurge dot net > for the link
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.
www.rootshell.com 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.
A Tcl/Tk based software toolset for protocol developement.
A PERL-based library for manipulating raw IP using libpcap.
A scripting language that comes as part of CyberCop scanner.
Channels
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.
Broadcasts
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:
See the cable-modem section above.
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.
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.
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.
__
+-~~ ~~-+
|........|
-++++++++-
12345678
------------------------------------------------
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.
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.
Examples:
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.
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.
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).
Encryption
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.
Access
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.
Roving
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.
Airports
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.
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.
See the HUNT Project at http://www.cri.cz/kra/index.html for more info.
| Operation: | Request | |
| Alice: | 192.0.2.173 | 00-40-05-A4-79-32 |
| Bob: | 192.0.2.1 | ?? ?? ?? ?? ?? ?? |
Alice ----> ARP broadcast request ----> Bob Alice <---- ARP unicast response <---- Bob Alice ----> ICMP ping request ----> Bob Alice <---- ICMP ping response <---- Bob Alice <---- ICMP ping request <---- CharlesNow 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.
A hacker (Mark) can subvert this by sending a redirect to Alice claiming that she should send him Bob's packets.
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 http://www.l0pht.com/advisories/rdp.txt for more information.
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.
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).
Note that all of these systems have secure alternatives. When entering things like credit card information, most web sites use SSL encryption rather than normal HTTP. Similarly, S/MIME and PGP can encrypt e-mail at a level higher than e-mail protocols like POP/IMAP/SMTP.
Protocol analysis is the process of capturing network traffic (with sniffing programs) and looking at it closely in order to figure out what is going on.
As data is sent across a wire, it is "packetized", meaning broken down into multiple packets that are each sent individually across the network, then reassembled back on the other side. For example, you probably downloaded this document from the network. Since this document is around 45,000 bytes and the typical packet size is 1,500 bytes, it took about 30 packets to deliver this document to you.
Below is a sample packet. This packet was taken from a packet sniffer that watch my workstation download this FAQ from my website. This packet was originally 1514 bytes long, but only the first 512 bytes are shown here:
000 00 00 BA 5E BA 11 00 A0 C9 B0 5E BD 08 00 45 00 ...^......^...E. 010 05 DC 1D E4 40 00 7F 06 C2 6D 0A 00 00 02 0A 00 ....@....m...... 020 01 C9 00 50 07 75 05 D0 00 C0 04 AE 7D F5 50 10 ...P.u......}.P. 030 70 79 8F 27 00 00 48 54 54 50 2F 31 2E 31 20 32 py.'..HTTP/1.1.2 040 30 30 20 4F 4B 0D 0A 56 69 61 3A 20 31 2E 30 20 00.OK..Via:.1.0. 050 53 54 52 49 44 45 52 0D 0A 50 72 6F 78 79 2D 43 STRIDER..Proxy-C 060 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D onnection:.Keep- 070 41 6C 69 76 65 0D 0A 43 6F 6E 74 65 6E 74 2D 4C Alive..Content-L 080 65 6E 67 74 68 3A 20 32 39 36 37 34 0D 0A 43 6F ength:.29674..Co 090 6E 74 65 6E 74 2D 54 79 70 65 3A 20 74 65 78 74 ntent-Type:.text 0A0 2F 68 74 6D 6C 0D 0A 53 65 72 76 65 72 3A 20 4D /html..Server:.M 0B0 69 63 72 6F 73 6F 66 74 2D 49 49 53 2F 34 2E 30 icrosoft-IIS/4.0 0C0 0D 0A 44 61 74 65 3A 20 53 75 6E 2C 20 32 35 20 ..Date:.Sun,.25. 0D0 4A 75 6C 20 31 39 39 39 20 32 31 3A 34 35 3A 35 Jul.1999.21:45:5 0E0 31 20 47 4D 54 0D 0A 41 63 63 65 70 74 2D 52 61 1.GMT..Accept-Ra 0F0 6E 67 65 73 3A 20 62 79 74 65 73 0D 0A 4C 61 73 nges:.bytes..Las 100 74 2D 4D 6F 64 69 66 69 65 64 3A 20 4D 6F 6E 2C t-Modified:.Mon, 110 20 31 39 20 4A 75 6C 20 31 39 39 39 20 30 37 3A .19.Jul.1999.07: 120 33 39 3A 32 36 20 47 4D 54 0D 0A 45 54 61 67 3A 39:26.GMT..ETag: 130 20 22 30 38 62 37 38 64 33 62 39 64 31 62 65 31 ."08b78d3b9d1be1 140 3A 61 34 61 22 0D 0A 0D 0A 3C 74 69 74 6C 65 3E :a4a"....<title> 150 53 6E 69 66 66 69 6E 67 20 28 6E 65 74 77 6F 72 Sniffing.(networ 160 6B 20 77 69 72 65 74 61 70 2C 20 73 6E 69 66 66 k.wiretap,.sniff 170 65 72 29 20 46 41 51 3C 2F 74 69 74 6C 65 3E 0D er).FAQ</title>. 180 0A 0D 0A 3C 68 31 3E 53 6E 69 66 66 69 6E 67 20 ...<h1>Sniffing. 190 28 6E 65 74 77 6F 72 6B 20 77 69 72 65 74 61 70 (network.wiretap 1A0 2C 20 73 6E 69 66 66 65 72 29 20 46 41 51 3C 2F ,.sniffer).FAQ</ 1B0 68 31 3E 0D 0A 0D 0A 54 68 69 73 20 64 6F 63 75 h1>....This.docu 1C0 6D 65 6E 74 20 61 6E 73 77 65 72 73 20 71 75 65 ment.answers.que 1D0 73 74 69 6F 6E 73 20 61 62 6F 75 74 20 74 61 70 stions.about.tap 1E0 70 69 6E 67 20 69 6E 74 6F 20 0D 0A 63 6F 6D 70 ping.into...comp 1F0 75 74 65 72 20 6E 65 74 77 6F 72 6B 73 20 61 6E uter.networks.an ....
This is the standard "hexdump" representation of a network packet, before being decoded. A hexdump has three columns: the offset of each line, the hexadecimal data, and the ASCII equivalent. This packet contains a 14-byte Ethernet header, a 20-byte IP header, a 20-byte TCP header, an HTTP header ending in two line-feeds (0D 0A 0D 0A) and then the data.
The reason both hex and ASCII are shown is that sometimes ones is easier to read than the other. For example, at the top of the packet, the ASCII looks like garbage, but the hex is readable, from which you can tell, for example, that my MAC address is 00-00-BA-5E-BA-11 (i.e. "BASEBAll").
A "protocol analyzer" will then take this hexdump and interpret the individual fields:
ETHER: Destination address : 0000BA5EBA11 ETHER: Source address : 00A0C9B05EBD ETHER: Frame Length : 1514 (0x05EA) ETHER: Ethernet Type : 0x0800 (IP) IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Precedence = Routine IP: ...0.... = Normal Delay IP: ....0... = Normal Throughput IP: .....0.. = Normal Reliability IP: Total Length = 1500 (0x5DC) IP: Identification = 7652 (0x1DE4) IP: Flags Summary = 2 (0x2) IP: .......0 = Last fragment in datagram IP: ......1. = Cannot fragment datagram IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 127 (0x7F) IP: Protocol = TCP - Transmission Control IP: Checksum = 0xC26D IP: Source Address = 10.0.0.2 IP: Destination Address = 10.0.1.201 TCP: Source Port = Hypertext Transfer Protocol TCP: Destination Port = 0x0775 TCP: Sequence Number = 97517760 (0x5D000C0) TCP: Acknowledgement Number = 78544373 (0x4AE7DF5) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x10 : .A.... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 28793 (0x7079) TCP: Checksum = 0x8F27 TCP: Urgent Pointer = 0 (0x0) HTTP: Response (to client using port 1909) HTTP: Protocol Version = HTTP/1.1 HTTP: Status Code = OK HTTP: Reason = OK ....
In the above hexdump and decode, I've underlined the "Time to Live" field of 0x7F. This is how a protocol decode works: it pulls each of the fields out of the packet and attempts to explain what the numbers mean. Some fields are as small as a single bit, other span many bytes.
Protocol analysis really is a difficult art, and requires a lot of knowledge about protocols in order to do it well. However, the rewards are that a lot of information can be easily gleaned from protocols. This info can be useful to network managers trying to debug problems, or hackers who are trying to break into computers.
All data within a computer is represented as numbers. Hexadecimal (or simply "hex") is a better numbering system for viewing this data than the "decimal" numbers everyone is already familiar with. Hexadecimal is one of those computer science concepts that is difficult to understand, until the "aha" moment when you finally understand it. After that point, it becomes second nature. Everybody has a different path to that "aha" moment, so don't feel bad if you don't understand the following discussion. However, you must eventually understand hexadecimal, so you really should look it up on the web.
The word "decimal" has the root "dec", meaning "10". This means that there are
10 digits in this numbering system:
0 1 2 3 4 5 6 7 8 9
The word "hexadecimal" has the roots "hex" meaning 6 and "dec" meaning 10; add them
together and you get 16. This means there are sixteen digits in this numbering system:
0 1 2 3 4 5 6 7 8 9 A B C D E F
The is useful because all data is stored in a computer as "bits" (binary-digits, meaning two digits: 0 1), but all bits are grouped into 8-bit units known as "bytes" or "octects", which in theory have 256 digits. Bits are two small to view data, because all we would see is a stream like 00101010101000010101010110101101101011110110, which is unreadable. Similarly, using 256 digits would be impossible: who can memorize that many different digits? Hexadecimal breaks a "byte" down into a 4-bit "nibble", which has 16-combinations (256 = 16*16). This allows us to represent each bytes as two hexadecimal digits.
Hexadecimal allows technical people to visualize the underlying binary data. A technical person has the following table memorized:
0000 = 0 0001 = 1 0010 = 2 0011 = 3 0100 = 4 0101 = 5 0110 = 6 0111 = 7 1000 = 8 1001 = 9 1010 = A 1011 = B 1100 = C 1101 = D 1110 = E 1111 = FIn other words, when you encounter the hexadecimal digit "B", you should immediately visualize the bit pattern "1011" in your head. It is much like memorizing multiplication tables as a kid, memorizing this table will serve much the same purpose.
Hexadecimal is often preceded by a special character(s). For example, when you see the number "12", is this "twelve" (decimal) or "eighteen" (hexadecimal)? If it is hex, it is often written as either "0x12", "x12", or "$12". The former is the preferred version, since that is how many programming languages represent it. Naturally, this isn't needed for hex dumps because the fact we are showing hex is pretty much assumed.
Computers represent everything as numbers. This means the text your are reading right now is represented as numbers within the computer. ASCII is one just representation. In ASCII, the letter 'A' is represented by the number 65, or in hex, 0x41. The letter 'B" is represented by the number 66/0x42. And the process continues for all characters, numbers, punctuation, and so forth.
If you look at the normal (U.S. English) keyboard you will count 32 punctuation characters, 10 decimal digits, 26 letters, and 26 more letters when you take into account UPPER/lower case. This comes to 94 different characters. In binary, you need 7-bits to represent that number of combinations. This maps nicely onto the standard 8-bit bytes used in computers, with room left over.
In hex dumps, note that the ASCII columns contains lots of periods. A byte has 256 combinations, but we can only view 94 of them. Any character that is not one of these 94 visible characters is shown as a period.
Any discussion of protocol analysis usually starts with the OSI model.
Previous to the OSI Model, networking was generally "monolithic". In other words, the application that displayed the data on your screen was also responsible for the hardware that moved the bits across the wire. You couldn't change either the software or the hardware with upgrading the entire system. Imagine having to buy a new computer simply to upgrade the software!
The concept behind the OSI model is to separate the functionality into different conceptual modules. As a quick introduction to this, consider the following 3-layer model that most consumers are familiar with:
| Application | Web browser, e-mail, RealAudio |
| Transfer | TCP/IP |
| Link | Dial-up modem, Cable modem, DSL, Ethernet |
Conceptually, this can be viewed in the following diagram:
+-------------+
| Computer |
| |
| +-------+ |
| | Web | | ____
| |Browser| | __/ \__
| +----++-+ | / Internet\
| || | | cloud \
| +----||-+ | +--------+ | +------+
| | TCP \\| +-----+ Link | Router | \ | Web |
| | IP \+=+ NIC +===//==+ +=====//======+====+ Site |
| | | +-----+ | | / | |
| +-------+ | +--------+ | +------+
| | | /
+-------------+ \__ __/
\____/
In this conceptual representation, the user's "Web Browser" application is trying
to view a web-page located on a "Web Site" located out on the web somewhere.
The "Web Browser" passes it down to the "TCP/IP" stack, which sends it out
the "NIC" across the local "Link" to the nearest "Router" gateway.
At this point, the client doesn't really know
what is going to happen to the data. Presumably, it is passed from router-to-router
through the Internet "cloud" until it reaches the destination "Server" hosting
the "Web-Site".
The important point to learn from all this is the concept of abstraction. Each component of this diagram does not know anything about the other components. For example, consider the postman that delivers your mail (physical mail, not e-mail). The postman has no knowledge of the contents of your letters. S/he simply moves the mail between the local post-office and your mail box. In much the same way, the IP layer within the machine has no knowledge of the contents of the packets. Its only responsibility is to accept packets from the TCP layer, and send them out NIC toward the local Router. The IP layer is even fuzzy on the exact details of how the NIC transports the packets to the local router, and is completely clueless as to what happens to the packets after that point.
In other words, each layer has a single job to do, and doesn't know anything about what is going on in the other layers.
This is difficult for humans to understand, because we can see what the entire process is trying to accomplish. It is difficult for us to constrain our view to just a single component.
Note that in the above diagram, there is lots of stuff toward the left of the diagram, but not much detail toward the right. This is because the user really has no idea how packets are really routed on the Internet, nor does the user really know much about the web site. In fact, the web site may consist of multiple computers for load-balancing purposes, or conversely may consist of a single computer hosting many web sites.
In order to understand the OSI Model, you must first understand the political backdrop behind its creation. In the late 1970s, computer networking was dominated by large, proprietary systems. Once you bought product from a single vendor, you could never buy products from other vendors that would work with it. You were "locked-in", and the vendor was free to charge whatever they wanted. Therefore, the OSI working group (OSI = Open Systems Interconnect) as part of the ISO (International Organization for Standardization) was created in order to standardize network protocols. In theory, if everyone conformed to standards, then consumers could buy products from different vendors at lower prices and save lots of money.
However, the OSI/ISO standardization process is fundamentally dysfunctional. For example, what does the acronym I-S-O stand for? In English, this stands for "International Organization for Standardization" or IOS. In French, it stands for "Organisation Internationale de Normalization", or OIN. (This can be seen on their homepage at http://www.iso.ch). English and French are the two official languages of ISO, and acronyms are chosen so that they match neither the English or French terms they refer to. Generally, standards that start within the ISO follow the same logic: in an effort to appease everybody, they end up satisfying nobody.
The OSI Model was a blueprint for an entire protocol suite that would implement the individual layers. They actually succeeded in generating this standard, but it never achieved popular use and has largely been supplanted by TCP/IP. While large organizations (government, industrial), mostly in Europe, have attempted to use it, it has largely become a boat anchor.
The following is a description of the 7-Layers within the model, and how they map onto the TCP/IP suite that we are familiar with.
| Layer | Unit | As far as... | Explanation |
|---|---|---|---|
| Application 7 | File transaction command | user | This layer doesn't mean the application itself, but the protocols that do the work for the application. Examples: HTTP for web browsers, SMTP/POP/IMAP for e-mail, |
| Presentation 6 |
This layer is an example of the political processes mentioned
above. The theory was that the application layer didn't need
to format the data for transmission across the wire; that
would be the job of an underlying layer. Furthermore,
the idea was that a client and server would negotiate
which format they wanted to use.
This actually made sense back in the late 1970s, because most networking involved dumb, character-mode terminals controlled by mainframes. An application wanted to deal with abstract concepts like database forms that a user filled out. Different terminals have different control codes to display this type of information. However, it makes virtually no sense nowadays. As a result, OSI protocols always negotiate a Presentation encoding, even though only one option is available. In TCP/IP, the only protocol that really does his negotiation is Telnet. Character-mode applications such as 'vi' go through a package called "curses". When you Telnet to a host, you exchange your terminal type with with the host. When an application such as 'vi' wishes to clear the screen, the 'curses' packages tells it how to do so for your particular terminal. However, the concept of how data is formatted on the wire is extremely important to applications. So even though it doesn't exist as a real layer outside of OSI protocols, it is still an important component of all applications. | ||
| Session 5 |
Like the Presentation layer, the Session layer is an artifact
of the ISO political processes, but more so. In fact,
as it turns out, the Session layer is completely useless.
If you pick up a book on OSI and read up on the Session layer,
you will end up reading lots of technical content about it
but you still won't be able to answer the question: What is the
session layer for? If you ask somebody what the Session layer
does, they will tell you something like "It establishes a session
between two entities". If you ask what a "session" is, the
answer would be "It's what the Session layer establishes". If they
give you a more detailed answer, they are probably confused and
will really be describing a Transport layer "connection", which isn't
the same thing.
There is a Session layer protocol defined by OSI, but the OSI hasn't defined any uses for it (that I know of). In other words, all the OSI applications establish both Transport layer "connections" and Session layer "sessions" when they start talking to each other, then tear down the connections/sessions together when they stop talking. Luckily, the OSI protocol has been defined in a fairly efficient manner such that both can be established in the same packet, and the Session layer only adds a couple bytes on average to every packet sent. Now I could actually tell you what the Session layer really is for, but I'm not going to. (Hint: it has to do with terminals talking to mainframes.) You should simply remember the concept that it really doesn't do anything. The 7-Layer model really just contains 6-layers (actually, 5-layers, because the Presentation layer should be thrown out as well). | ||
| Transport 4 | connection | other program |
The Transport layer is TCP (and UDP).
Like the discussions above, the official OSI Transport layer has lots of worthless features attached to it. However, I'm going to pretend it just describes how TCP implements this layer. Furthermore, in order to understand this layer, you need to understand the layer below (IP), so I explain both in the next section. |
| Network 3 | packet | other machine |
The Network layer is IP.
Everything on the Internet pretty much focuses on
the IP protocol. Even though there are 7 layers in the OSI model,
the "first" layer is layer #3, the Network layer.
Like the discussions above, the OSI has specified lots of useless features for the Network layer. Each layer was given to its own group to design, so each group designed into their layers pretty much all the features of the rest of the stack. Therefore, it is difficult to point to any particular networking feature and say "it belongs to layer #X". Luckily, TCP/IP is much more clean that way. Therefore, I will follow the standard practice of describing only the features that the TCP/IP protocol implements rather all possible features. The IP protocol is designed around the concept of an "unreliable datagram". Its one purpose is to get a packet of data from one machine to the destination machine all the way across the Internet. In order to do this, each machine is given an IP address: e.g. 192.0.2.14. The originating machine puts that address into a packet, then sends it to the nearest router. The router then looks at the IP address, and decides which direction it goes, and forwards it to the next router in that direction. The packet travels from hop-to-hop through the Internet until it reaches its destination. The whole process takes, on average, about a tenth of a second. You can visualize this as being just like normal mail. You write a letter, wrap it in an envelope, then address it. You stick the envelope in the mailbox and somehow it disappears, gets routed from hop-to-hop through the postal network, and eventually ends up at its destination. The important concept to remember is "unreliable": letters get lost in the mail. Roughly 1 out of every 100 IP datagrams gets lost on the Internet, sometimes more, sometimes less. This is where TCP (from the Transport layer above) steps in: it keeps track of all the datagrams going back and forth, and if one is lost, it automatically retransmits it. In order for TCP to provide this reliability, it must create a "connection". In other words, before two programs can talk to each other across the Internet, they must first establish a TCP connection through a process known as a "handshake". Whenever one machine sends data to the other, the receiver must send back an acknowledgement so that the sender knew it arrived. Likewise, IP itself requires no connection; it is "connectionless". In fact, many protocols who don't want the complexity of TCP choose bypass it by using UDP on top of IP: UDP is essentially the same as TCP, but doesn't acknowledge packets and doesn't require a connection. A good example of this usage is an application like IP Phone: it doesn't matter if a bit of data is lost here and there (cell phones do it all the time). Most of the time you won't notice a single lost packet, and if multiple packets are lost in succession, you can simply ask the other person to repeat what they said. In fact, TCP is very bad for this application: whenever a packet is lost, transmission halts until both sides are caught up again. In an IP Phone conversation, this means you might hear a pause, then the other person's delayed comments that need to be replayed very fast in order to catch up. For this reason, "real time" applications like audio, video, and games prefer UDP over TCP. Finally, the IP address will get your data as far as the destination machine, but many programs on that machine may be waiting for data to arrive. How does that machine know to which application that belongs? The Transport layer (TCP and UDP) contain their own unique addresses for each program on that machine. Each program is bound to a different "port" number. For example, imagine a machine with two web services running on it. You get to the different web services by specifying different ports in the URL. the URL http://www.example.com:80/index.html will get to the web service running at port 80, and http://www.example.com:81/index.html will get to the web service running at port 81. Thus, these URLs will return different web pages, depending on which service responded. |
| Data Link 2 | frame | next hop |
The most important concept to remember about the Data Link layer is "next hop". It's only purpose is to connect two machines together: you machine and the nearest router, or two routers. This is the "Link" component in the diagram above. In other words, on an Ethernet wire, your machine wraps the IP packet with Ethernet information, sends it to the first router. That router than strips off the Ethernet header and forgets about it. The router then decides which direction to foward the packet, the wraps it with the Data Link framing information to go across that wire to the next router. A machine might have both an Ethernet "MAC" address and an IP address. The Ethernet is the Data Link layer, and the MAC address is only visible locally, and is used by the local router in order to figure out how to send incoming traffic to you (vs. anybody else sharing the same Ethernet wire). Conversely, the IP address is global. If somebody in Siberia sends you traffic, they will use your IP address. |
| Physical 1 | bit | wire |
The Physical layer simply gets the bits out onto the wire. Different wires require different ways of encoding the bits. A telephone modem, for example, converts the bits into sounds patterns that go across the telephone wire. Ethernet, on the other hand, converts the bits into a series of high/low voltage levels. |
People often have trouble understanding all these concepts. I like to summarize as follows:
A more laid-back approach can be found at: http://www.europa.com/~dogman/osi/
To truely understand this answer, you must read sections section 5.1 and section 5.4 above. However, this is a common question, so I'll introduce the concept briefly here.
All down that is transfered on the Internet is packaged in individual units known as "packets". It takes between 30 and 50 packets for this document to be transfered to your computer, for example. Each packet is labeled with an "IP address" that specifies its destination.
The trick is that everything that is sent by the computer needs to be broken down into these packets. For example, if you listen to Internet "radio" to a streaming broadcast, it appears to you as one continuous stream, but in reality the transmitter is breaking the data down into individual packets, then your machine is reassembling them back into a stream.
The entire effort of sniffing consists of looking at either the individual packets, the reassembled data, or the sifted information (like passwords) out of the reassembled data.
TCP is a "reliable" service, meaning that everthing has to be acknowledged in order to verify that it was received correctly. Similar protocols to TCP use 2, 3, or 4 packet handshakes in order to setup the connection. An amazing amount of work went into choosing the optimal 3 packet exchange.
In TCP-speak, we view this exchange as :
TCP has this interesting concept that every packet acknowledges receipt of data in the other direction. So if I send you one packet and you send me five in response, then each of your five responses acknowledge that you have received my one packet. This means that all TCP packets have the ACK bit set, except for the first one (because there's nothing to acknowledge). Note: most firewalls that block incoming TCP connections really just block packets without the ACK bit set; this means TCP traffic with that bit can still make it through the firewall to "ping" yo
All connection oriented protocols have "sequence numbers" which help order the data in the correct sequence, and acknowledge how far along in the sequence you've received the data. Most connection-oriented protocols beging their sequence numbers at zero, but TCP has this weird concept of starting them at a random number. Therefore, the TWHS looks something like:
| Flags | seq | ack |
|---|---|---|
| SYN | 102723769 | 0 |
| SYN-ACK | 1527857206 | 102723770 |
| ACK | 102723770 | 1527857207 |
Another thing to remember is that a TCP connection occurs from the port on one machine to the port on another. For example, a web server typically runs at port 80, and client ports are allocated starting at port 1024. Therefore, we might expand our example to show this:
| Flags | src | dst | seq | ack |
|---|---|---|---|---|
| SYN | 1037 | 80 | 102723769 | 0 |
| SYN-ACK | 80 | 1037 | 1527857206 | 102723770 |
| ACK | 1037 | 80 | 102723770 | 1527857207 |
This explanation is just an overview provided as an alternative way of looking at the subject. I strongly recommend you grab a book on TCP/IP, or lookup "three way handshake" on the web.
RMON (Remote MONitoring) is an SNMP-based standard that allows management of network traffic.
If you'll recall, SNMP is the standard way of remotely managing devices. In a typical network, you have routers, hubs, switches, backup power supplies, servers, mail gateways, and so forth. In a modern network, all these devices can be remotely managed with a centralized console. The console sends SNMP commands to monitor their status, to reconfigure them, and receive alerts from them.
Of course, each of these devices accepts different commands and support different parameters that can be monitored. For a router, you might be concerned with the rate that packets are being forwarded. For a hub, you might want to monitor for any cabling faults on the ports. For backup power supply, you will want to monitor the voltage of the power being supplied. The collection of monitorable/changeable parameters are stored in a virtual database called a MIB (Management Information Base).
RMON is just another SNMP MIB. The item that this MIB manages is the traffic on the wire. In other words, we aren't talking about managing a real thing, but a virtual device.
The 9 groups defined by the original RMON specification are:
The "History" group is simply the "Statistics" group, but with the ability to keep track of the variables over time. One typical thing you might do is tell the RMON box to copy the Statistics group every hour and store the samples away.
The Host group monitors the traffic that each MAC address sends/receives on the wire (bytes sent/received, frames sent/received). The HostTopN group serves as a sort of History mechanism to the Host MIB. Keeping a history of all the data would take too much memory, so instead it would allow you to do historical summaries of only the most active hosts. For example, every day you might store only the 10 most active hosts.
The Matrix MIB keeps a table of all the source/destination pairs. You can think of this in a number of ways. For any host, you can identify who that host is talking to. Likewise, you can identify who is talking to that host. This MIB is extremely resource intensive.
Note that in this discussion, the word "host" means essentially "MAC address". In a normal routed TCP/IP environment, this means that you will generally see that everyone is talking to the router. Later versions of RMON extended the host concept to the IP address layer; described below.
The Filter group allows you to specify filters. The most common use for this is when you want to sniff a single host's traffic, or if you are sniffing for a certain protocol. The Capture group is where the sniffed traffic is placed. The management console tells the capture group to create a buffer, then turns on sniffing, then downloads the frames to the console for decoding.
Alarming within RMON was extraordinarily sophisticated. For example, you could set a Filter to scan for a certain pattern within network traffic and trigger an Alarm.
However, the source of this confusion is that RMON wasn't your average MIB. It broke the mold of how people viewed SNMP. Before RMON, SNMP was designed to be a simple/lightweight protocol. The idea was that you would add this tiny little SNMP agent to all your networking equipment, and that this agent would have minimal impact on the equipment. RMON introduced new ways of thinking where the agent could be much more resource intensive. This came from the fact that RMON wasn't added to existing equipment, but instead existing equipment was designed to run RMON.
Over time, people found many of the RMON concepts useful. They extended into later MIBs and versions of SNMP. At the same time, people imbedded RMON into existing equipment like hobs, switches, and routers. In fact, the original coax Ethernet that RMON was designed for doesn't exist today; yet RMON is still a thriving/evolving standard.
On the flip side, there is a big security concern that RMON is so pervasive on equipment throughout the Internet that you can often find open RMON probes that will allow remote sniffing. Again, it won't provide very good sniffing capabilities, but it will be good enough.
Second of all, RMON is extremely resource intensive. In RMONv2, the network-layer matrix table can quickly fill up after a few moments attached to the network.
