1.

Packet Sniffers
A packet sniffer, the network analyzer, is a wire-tap device that plugs into
computer networks and eavesdrops on the network traffic. To capture the information
going over the network is called sniffing. It is a "sniffing" program that lets someone
listen in on computer conversations. 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. These tools known as network sniffers are named after a
product called the Sniffer Network Analyzer. Introduced in 1988 by Network General
Corp. (now Network Associates Inc.), the Sniffer was one of the first devices that let
managers sit at their desks and take the pulse of the larger network. The original
sniffers read the message headers of data packets on the network, giving
administrators details about the addresses of senders and receivers, file sizes and other
low-level information about those packets, in addition to verifying transmission.
Using graphs and text-based descriptions, sniffers helped network managers evaluate
and diagnose performance problems with servers, the network wire, hubs and
applications.
They help keep networks humming, but they can also be used by hackers to uncover
user names and passwords from data packets traveling across public or private WANs.
Encrypting the headers of data packets (using the Secure Sockets Layer standard in
browser-based environments, for example) thwarts sniffer-assisted password thefts.
Sniffing also has one advantage over telephone wiretaps: many networks use "shared
media". Sharing means that computers can receive information that was intended for
other machines. 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. 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.
A sniffer being used on a network to snoop passwords and anything else is considered
to be a passive attack. A passive attack is one that doesn't directly intrude onto a
foreign network or computer. On the other hand, an active attack directly interfaces
with a remote machine. Remote buffer overflows, network floods and other similar
attacks fall under the category of an active attack . By nature, passive attacks are not

meant to be discovered by the person(s) being attacked. At no point should they have
indication of your activity. This makes sniffers just as serious as any active attack.

1.1 Types of Sniffers

Today, sniffers exist in two broad varieties:
The first is a stand-alone product incorporated into a portable computer that
consultants can carry to customer sites and plug into the network to gather
diagnostic data.
The second is part of a larger package of network-monitoring hardware and
software for helping organizations keep tabs on their LANs, WANs and Web
services.
Thus Commercial packet sniffers are used to help maintain networks.
Underground packet sniffers are used to break into computers.

1.2 Functions of sniffers

They provide administrators a centralized view of networks to monitor high-level

activity, such as which applications are running, which users are logged on to the
network and who is the source of unusually large files or high volumes of traffic.

Rather than merely identifying low-level characteristics such as packet source and
destination, current sniffers can decode data from all seven layers of the Open
System Interconnection network stack and can often recommend fixes for
problems. If application-level analysis fails to provide a solution, sniffers can drill
into low-level activities.

Conversion of data to human readable formats so that people can read the traffic.

Used

along

with

Network

intrusion

detection

in

order

to

discover

hackers/crackers.

Modern sniffers typically incorporate remote monitoring standards (Rmon and

Rmon 2), that define a standard way for systems to automatically collect key
performance data points such as resource utilization. Rmon-savvy sniffers can
take constant readings on the health of network components and compare those
readings against historical trends. If necessary, they can trigger alarms when
traffic loads or performance delays surpass limits set by network administrators.

1.3 The components of a packet sniffer

1.3.1 The hardware
Most products work from standard network adapters, though some require
special hardware. If you use special hardware, you can analyze hardware faults like
CRC errors, voltage problems, cable programs, jitters, negotiation errors, and so
forth.
1.3.2 Capture driver
This is the most important part. It is a special driver for the network card
known as a packet driver. The packet driver is what allows the network card to
operate in promiscuous mode. On Windows machines, if you notice that it has a
packet driver installed in the properties of one or more of the network devices (the
same place that you would view TCP/IP properties) installed on the machine, there is
a very good chance that a packet sniffer is installed. It captures the network traffic
from the wire, filters it for the particular traffic you want, then stores the data in a
buffer.
1.3.3 Buffer
Once the frames are captured from the network, they are stored in a buffer.
There are a couple captures modes: capture until the buffer fills up, or use the buffer
as a "round robin" where the newest data replaces the oldest data. Some products (like
the BlackICE Sentry IDS from Network ICE) can maintain a full round-robin capture
buffer on disk at full 100-mbps speeds. This allows have hundreds of gigabytes of
buffer rather than the meager 1-gigabyte you're likely to have in a memory-based
buffer.
1.3.4 Real-time analysis
Pioneered by the Network General Sniffer, this feature does some minor bit of
analysis of the frames as they come off the wire. This is able to find network
performance issues and faults while capturing. Real-Time display of captured packets,
incoming Network packets will be immediately decoded and added to the Packet list,
this eats up a whole lot of resources.
1.3.5 Decode
This displays the contents of network traffic with descriptive text so that an
analysts can figure out what is going on. In the Packet Decoding view packets are
decoded and displayed in a format that is comprehensible.

1.3.6 Packet editing/transmission

Some products contain features that allow you to edit your own network packets
and transmit them onto the network.

2. How a Packet Sniffer works

A sniffer must be located within the same network block (or net of trust) as the
network it is intended to sniff. With relatively few exceptions, that sniffer could be
placed anywhere within that block
Under many networking protocols, data that you transmit gets split into small
segments, or packets, and the Internet Protocol address of the destination computer is
written into the header of each packet. These packets then get passed around by
routers and eventually make their way to the network segment that contains the
destination computer. As each packet travels around that destination segment, the
network card on each computer on the segment examines the address in the header. If
the destination address on the packet is the same as the IP address of the computer, the
network card grabs the packet and passes it on to its host computer.
But Packet Sniffers set up on a computer work slightly differently. Instead of
just picking up the packets that are addressed to them, they set their network cards to
what's known as promiscuous mode and grab a copy of every packet that goes past.
This lets the packet sniffers see all data traffic on the network segment to which
they're attached - if they're fast enough to be able to process all that mass of data, that
is. This means that it is looking at everything that comes through. The amount of
traffic largely depends on the location of the computer in the network. A client system
out on an isolated branch of the network sees only a small segment of the network
traffic, while the main domain server sees almost all of it.
A packet sniffer can usually be set up in one of the two modes:
Unfiltered - captures all of the packets
Filtered - captures only those packets containing specific data elements
Packets that contain targeted data are copied onto the hard disk as they pass
through. These copies can then be analyzed carefully for specific information or
patterns.
When you connect to the Internet, you are joining a network maintained by your
Internet service provider (ISP). The ISP's network communicates with networks
maintained by other ISPs to form the foundation of the Internet. A packet sniffer

located at one of the servers of your ISP would potentially be able to monitor all of
your online activities, such as:

Which Web sites you visit

What you look at on the site

Whom you send e-mail to

What's in the e-mail you send

What you download from a site

What streaming events you use, such as audio, video and Internet telephony.

From this information, employers can determine how much time a worker is spending
online and if that worker is viewing inappropriate material.

2.1 Why Packet Sniffing Works ?

The reason that packet sniffing works is due to the way Ethernet networks
send their packets. Ethernet was built around a "shared" principle: all machines on a
local network share the same wire. Any time that a PC sends out a packet, it is sent
out as a broadcast. 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 sniffer program turns off this filter, putting the Ethernet hardware into
"promiscuous mode". In order to sniff on the wire, a driver must be written that both
puts the adapter into promiscuous mode, as well as buffers the incoming frames.
As mentioned, packet sniffing works by making a copy of each packet as it
flows across the network. In the past, it has been difficult to tell if anyone on your
network is engaging in packet sniffing. After all, no one is hacking into a server or
anything, so the audit logs wouldn't indicate any sort of unusual activity. A person
who's packet sniffing is merely reading information as it comes to them.

2.2 Capturing of Packets by Sniffers

A sniffer captures the data coming in and going out of the Network Interface
card or modem and displays that information in a table.

2.2.1 The analysis of a captured frame

The following is a captured frame that is actually an HTTP GET request
issued from my PC to another host. This frame was captured using the Windows NT
Server (4.0) Network Monitor.

3C 2E AC 00 01 01 00 01 D0 E1 66 80 08 00 45 00
01 F7 E8 80 40 00 80 06 39 40 C2 7E 57 A5 D1 01
EC 1A
Fig. 2.1 A Captured Frame
Each box represents a byte of the frame. The number in each box is actually a
hexadecimal number. This frame can be broken down into different parts :
The Ethernet header - Bytes 1 to 14
The IP header - Bytes 15 to 35
The TCP header - Bytes 36 to 56
The actual data i.e. the HTTP GET request.

2.2.2 The Ethernet Header

3C 2E AC 00 01 01 00 01 D0 E1 66 80 08 00
Fig. 2.2 The Ethernet Header
The Ethernet header is 14 bytes long. Ethernet operates at the Network Access
layer and is a type of datalink protocol. Other datalink protocols include Token Ring,
ATM, Frame Relay. Each of these have a standard set of rules to which they must
comply defining such things a media access control, the maximum transmission unit
size and what we are looking at here : the header length and makeup. Every network
interface card has a unique address known as a MAC (Media Access Control) address.
This is a physical address and not a logical one such as IP addresses.
The first 6 bytes actually represent the source MAC address and the next 6
bytes denote the destination MAC address. Communications between hosts at the
datalink level of communication use this MAC address. When a message is
propagated throughout a network segment each receiving NIC will look at the
destination hardware address in the frame and either A) ignore it or B) pick it up. It
will only do B in these circumstances :
If the destination address is the address of the receiving computer or if the
broadcast MAC address (FFFFFF) is set as the destination address.
This leads to the question what happens if you don't know the MAC address of the
machine you trying to communicate with? A protocol call the Address Resolution
Protocol (ARP) does this for you. ARP will send out a message using the broadcast
MAC address, requesting that the machine using IP address xxx.xxx.xxx.xxx respond

with its MAC address. Every machine on the network segment will receive this
message and check its IP address. If it finds it does have that IP address it will respond
accordingly. If not then it will go on about its business. The next two bytes represent
which protocol the Ethernet header is framing. Here we can see the value is 08 00.
Hex 08 00 represents IPv4. Below are some other common protocols
08 06 - ARP
08 08 - Frame Relay ARP
86 DD - IP Next Generation (IPv6)
08 05 - X.25 level 3

2.2.3 The IP Header

45 00 01 F7 E8 80 40 00 80 06
39 40 C2 7E 57 A5 D1 01 EC 1A
Fig. 2.3 The IP Header
Each box represents an 8-bit byte (commonly known as an octet). The figure in each
box is a hexadecimal number. A normal IP header breaks down like this :
Byte number 1
The first byte (45) is divided into two 4 bit halves. The leading 4 bits (the
number 4) denotes what version of IP the datagram is using. As we can see it using
IPv4. In an IPv6 header this 4 would become a 6. However the IPv6 header is
somewhat different to the IPv4 header. But as this tutorial is about v4 we won't go
into that now. The remaining 4 bits of the first byte show how long the IP header is.
Each bit is worth 4 bytes so we know that the IP header is 20 bytes long (5 bits x the 4
bytes each bit represents = 20). In binary format the first byte is represented as this :
0100 0101
Byte number 2
The second byte provides information to the gateways (or routers) as it travels
along the network path from the source to the destination host. This byte is commonly
known as the Type of Service TOS) byte and is also divided like the first byte but not
so equally.
The first 3 bits denote how important this IP datagram is i.e. its Precedence. Usually
all the bits are set to 0 (000). This is the standard and marks the IP datagram as being
"Routine". The more important the data is these three bits will be set accordingly.
(001) for Priority (010) for Immediate (011) for Flash and so on... A router will drop
everything else to pass through a flash datagram. Note - how close this information is

to the beginning of the header....this way a router learns almost immediately the
priority of a datagram and can base its following actions on that. The next 4 bits
represent the delay, throughput, reliability and cost.
Delay
If this bit is set to 1 it is requesting of the router that it be sent via a path that
offers least amount of delay time (propagation delay).
Throughput
If this bit is set to 1 it is asking that the router send the datagram through a
path that has the most bandwidth i.e. the amount of data that can be stuffed through a
pipe in a given moment.
Reliability
While data is travelling over the lines if there is too much noise (whether this
be cross talk or electromagnetic interference (EMI)) it can become corrupt or lost. If
this bit is set to 1 it is requesting to be sent through a path with the least chance of
data loss.
Cost
Some network paths can be more expensive to use than others eg the using
microwave technology is more expensive than using a frame relay route. This bit
allows you to request a path whether that be the more expensive one or not. The last
bit of the second byte is reserved, as per the RFC, for future use.
Bytes 3 and 4
The next two bytes (01 F7) represent the total IP datagram length. In this case
it's 503 bytes (01 F7 hex > dec = 503). Because the total length field is limited to two
bytes this means the maximum possible size for an IP datagram is 65535 bytes (FF FF
hex). Remember though that the datalink protocol being used may have a maximum
transmission unit (MTU) that is smaller than 65535 bytes. In this case the datalink
protocol being used is Ethernet and this has an MTU of 1500 bytes.
Bytes 5 and 6
When an IP datagram is fragmented i.e. it is chopped up into more managable
chunks there has to be a way for the receiving host to reassemble the fragmented IP
datagram. The next two bytes (E8 80) denote the datagram ID number. Each fragment
of the IP datagram will have the same ID number. The next two bytes are linked to
this.
Bytes 7 and 8
8

These bytes represent the fragment area.... When IP has a datagram to send it
contacts the protocol operating at the datalink level to ascertain how much data it can
handle at anyone time i.e. the MTU. IP will then divide its data into chunks that the
datalink protocol can handle. If fragmentation is necessary IP uses these two bytes to
keep a track of each fragment.
Byte number 9
This byte (80) represents the Time To Live (TTL). The TTL is a timing
method used by routers to kill off any datagrams that are not delivered for whatever
reason. The TTL byte here is set to hex 80 (128 dec.). So this datagram has 128
"seconds" to live. If it doesn't reach the destination by then it'll be discarded. When
the datagram comes to the first router in its journey the router will reduce this number.
Every router along the way will reduce this number. When it reaches the host at the
receiving end this number would have a lower value.
Byte number 10
This byte denotes what higher level protocol the IP datagram is carrying. In
this case it's (06) .i.e. the Transmission Control Protocol (TCP). Others are:
(01) ICMP (Internet Control Message Protocol)
(08) EGP
(11) UDP (User Datagram Protocol)
(59) OSPF (Open Shortest Path First)
(58) IGRP.
Bytes 11 and 12
Starting on the next line down, these two bytes (39 40) make up the header
checksum. This is as much as IP will do for data integrity...it is a connectionless
protocol after all. IP assumes that most of the error checking will be done by the
higher level protocols such as TCP.
Bytes 14 to 20
The first four make up the source IP address and the last 4 bytes make up the
destination IP address :
C2 7E 57 A5 > 194.126.87.165
D1 01 EC 1A > 209.1.236.26

2.3 Protocol analysis

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.

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

...

Fig. 2.4 "hexdump" of a network packet

10

In the hexdump shown above and decode, the "Time to Live" field of 0x7F is
underlined. 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.
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: 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)

11

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

Fig. 2.5 Representation of a network packet by sniffer

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.

3. Terms often used in sniffing:

3.1 Ethernet MAC address
Since many machines may share a single Ethernet wire, each must have an
individual identifier. This doesn't happen with dial-up modems, because it is assumed
that any data you send to the modem is destined for the other side of the phone line.
But when you send data out onto an Ethernet wire, you have to be clear which
machine you intend to send the data to. Sure, in many cases today there are only two
machines talking to each other, but you have to remember that Ethernet was designed
for thousands of machines to share the same wire. This is accomplished by putting a
unique 12-digit hex number in every piece of Ethernet hardware. 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.
Following a is a brief explanation how this works:

12

Internet
Router

Alice

Bob

Sniffer
Fig. 3.1 An Ethernet Setup
Alice has IP address: 10.0.0.23
Bob has IP address: 192.168.100.54
In 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 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
Fig.3.2 An Ethernet Frame
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

13

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 routers 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 adapter 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 sniffer, however, breaks the rules and copies the frame off the network, too.

3.2 The format of the MAC address

The Ethernet MAC address is a 48 bit number. This number is broken down
into two halves, the first 24-bits identify the vendor of the Ethernet board, the second
24-bits is a serial number assigned by the vendor. This guarantees that no two
Ethernet cards have the same MAC address (unless the vendor fouls up). Duplicate
address would cause problems, so uniquess is very important. This 24-bit number is
called the OUI ("Organizationally Unique Identifier").
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).

3.3 Determining ones own Ethernet address

Win9x:
Run the program "winipcfg.exe". It will tell you. WinNT
Run the program "ipconfig /all" from the command-line. It will show the MAC
address for your adapters. Sample results are:
14

Windows NT IP Configuration
Host Name . . . . . . . . . : www.yahoo.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

3.4 RMON
RMON (Remote MONitoring) is an SNMP-based standard that allows
management of network traffic.
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.
3.4.1 Does RMON function as a remote sniffer?

15

In a pinch, RMON can be used to remotely sniff traffic. The problem is that it
isn't very good at it. For example, with today's sniffing products, you can easily do a
packet capture of all traffic and save it real time to gigabyte disk drives. If you try to
do that with RMON, you'll find difficulties in trying to transfer all that data back to
your management console. One way to reduce this data is to set packet capture filters.
However, filtering is extremely weak in RMON. If you want to do sniffing, don't rely
upon RMON to do it for you.
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.
3.4.2 Limitations of RMON:
First of all, RMON suffers from the basic problems of SNMP. SNMP has
always been a "checkbox" item that customers always want in their products, but
which vendors don't spend a lot of time on. Thus, basic activities work within SNMP,
but it never quite reaches the hype. Likewise, while there are a ton of products out
there that support RMON, they don't always work correctly. Indeed, since RMON is
so resource intensive, you will often find that heavy use of RMON crashes the remote
device. Second of all, RMON is extremely resource intensive.

3.4.5Ways of sniffing a connection between two people

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

Another possibility is to break into a person's machine and install a sniffing

program. On UNIX, sniffing programs are part of most "rootkits". On Windows,
sniffing is part of some RATs (Remote Admin Trojans, e.g. BackOrifice). To
stop people from sniffing the data.

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

16

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

4.2 ARP Redirect

ARP packets contain both the local binding as well as the desired binding. For
example, let's say that Alice wants to find Bob's Ethernet MAC address. Bob has an IP
address of "192.0.2.1". Alice would send out an ARP request with the following
information.

Operation: Request
Alice: 192.0.2.173
Bob: 192.0.2.1

00-40-05-A4-79-32
?? ?? ?? ?? ?? ??

Fig. 4.1 ARP Request

The entire exchange might look 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

Alice
Alice
Alice

Alice

ARP broadcast request

Bob

ARP unicast response

Bob

ICMP ping request

ICMP ping response
ICMP ping request

Bob
Bob
Charles

Fig. 4.2 Requests exchanged between 2 nodes in a network

17

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.

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

4.4 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 (causing 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

18

what you want to do. You may want to subvert an authenticated connection, in which
case you DoS (Denial of Service) 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.

5. Protocols vulnerable to sniffing

5.1 Telnet and rlogin
Sniffing can capture the keystrokes as the user types them, including the user
name and password. A long time ago I wrote a commercial product that would capture
all the text and dump it to a terminal emulator, which reconstructed exactly what the
end-user was seeing. This basically produced a realtime viewer of the remote users
screen.
5.2 HTTP
The default version of HTTP has numerous holes. Many web sites use "Basic"
authentication, which sends passwords across the wire in plain-text. Many web sites
use another technique which prompts the user for a username and password, which
are also sent across the network in plain-text. Data sent in clear-text.
5.3 SNMP
Alomost all SNMP traffic is SNMPv1, which has no good security. SNMP
passwords (called community-strings) are sent across the wire in the clear.
5.4 NNTP, POP, FTP, IMAP

19

Passwords sent in the clear. Data sent in clear

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.

6. Layers found on the Ethernet Sniffer

This approximates the OSI layer for each expert layer found on the ethernet
sniffer, although there is no true one-to-one relationship between the two.

6.1 The Subnet Layer

OSI Layer: Network -Layer 3
As traffic moves across the network, network layer traffic may appear. If any
layer 3 information is captured, the Sniffer will detail the movement of traffic
between network addresses. The number of frames, hops, and total symptoms and
diagnosis will be displayed for each object in the Subnet layer.
With this breakdown of information, it's easy to see the communication pattern
between subnets. This single display will show two subnets that are exchanging small
amounts of data, or LARGE amounts of information.
If the network's subnet masks aren't defined properly , this information (and
other Expert information) will be incorrect! Keep your subnet masks updated in the
Sniffer, and the Expert will maintain an accurate view of the network.

6.2 The Route Layer

OSI Layer: Network - Layer 3
The Sniffer watches for IP RIP packets as they traverse the network, and
builds an IP RIP routing table in this layer. Destination, next hop, byte counts, aging
timers, and metric information is updated in real-time for every route seen during a
RIP update. In many modern networks, RIP isn't used and this layer will remain at a
zero counter for the duration of a capture. If the Sniffer doesn't see any RIP
information after two minutes of capture, it automatically shuts this layer off to
allocate resources to other layers. Even if this layer is supposed to be blank, rogue
routers can sometimes send RIP information. The Sniffer will show any IP RIP
activity, tipping the network manager off to unusual and potentially harmful routing
activity on the network.

20

6.3 The Global Layer

OSI Layer: None
The Global Layer is an overall perspective of network health from the most
basic network layers. Although this layer doesn't cleanly fit into an OSI layer, most of
the information displayed is OSI Layer 2 information.
The Global Layer shows the total amount of traffic traversing the network. If
the Sniffer is on a trunked link, this 'globe' will be broken into many pieces, with each
object representing a separate VLAN. Problems identified at this layer are issues that
can affect more than one device on the network. A large number of CRC errors, high
levels of broadcasts, or an overloaded LAN have the potential to cause damage to
large groups of network users.

6.4 The DLC Layer

OSI Layer: Physical and Data Link - Layers 1 and 2
The Data Link Control (DLC) Expert Layer is a list of every OSI Layer 2
address communicating on the network, through the network, from the network, or to
the network. In Ethernet, this DLC address corresponds to the MAC address of each
Ethernet card. Each MAC address is shown with a statistical breakdown of the total
traffic to and from the address. All information shown is for all traffic relating to a
single MAC address. This layer helps identify problems that occur at an individual
device level. High layers of collisions or physical errors from a single MAC address
may be seen at this layer.

6.5 The Station Layer

OSI Layer: Network - Layer 3
This layer details similar information as the DLC layer, and each device is
broken into separate layer 3 protocol objects. For example, a workstation that is
communicating via IP and IPX is listed twice in the Station layer; once for the IP
traffic, and again for the IPX traffic. Although a station may be sending a large
amount of information, the specific layer 3 protocol that the station is using can't be
seen until the object is viewed at the Station layer. Duplicate network address and
router problems are also displayed at the Station layer.

6.6 The Connection Layer

OSI Layer - Transport - Layer 4

21

A single workstation communicating via TCP/IP may communicate to

multiple devices using the transport layer protocol of TCP or UDP. The Connection
layer details each device communication at the network transport layer, and details
important information about the quality of the connection.
For example, communication via TCP can detail the number of zero windows
during the communication, the size ranges of the TCP sliding windows, and even the
network level acknowledgement times from each device! This layer allows the
network manager to begin breaking the network into two pieces; the network portion
and the application portion.
If average acknowledgement times at this layer are low, then the network is
communicating efficiently (regardless of the application's response times!). If the
average acknowledgment times increase, then a network problem may be preventing
the efficient transfer of network information.

6.7 The Session Layer

OSI Layer - Session - Layer 5
At the Session layer and above, the Expert is showing information specific to
applications running over the network. However, not all applications have a session
layer. For example, Telnet does not use a session layer protocol to setup, maintain,
and break-down an application session. Many database protocols use the session layer
for login and logout maintenance. Problems at the session layer may be related to a
slow login process or a lack of response from an application server. The Sniffer will
also flag an application that is repeating requests or has too many requests denied in a
particular timeframe.

6.8 The Application Layer

OSI Layers - Presentation and Application - Layers 6 and 7
All application transactions are displayed at this layer of the Sniffer, and each
workstation has separate objects for each individual application running on the
network. For example, each person communicating to a web server will be listed in
this layer by requests, number of frames, and duration timeframes.
If a Web application is showing slow response times, the object will be
flagged at the application layer and individual statistics for that particular application
will be displayed. Each application displays different types of statistics, since
applications vary in their operation and communication.

22

6.9 The Service Layer

OSI Layers - Presentation and Application - Layers 6 and 7
The service layer is a new layer, and it's a variation of the application layer. In
the application layer, each communication to a web server is listed as a separate object
in the Expert display. In the service layer, the web server is listed as a single object,
and all statistics for the entire service are rolled-up into this single object.
This al lows the network manager to view specific information by server. This
becomes especially important when network and server administrators are interested
in the scalability of an individual server and the overall response times to a single
server.

7. Detection of packet sniffers

In theory, it is impossible to detect sniffing programs because they are passive:
they only collect packets, they don't transmit anything. However, in practice it is
sometimes possible to detect sniffing programs. 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

7.1 ping method

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:
1. The machine suspected of running the packet sniffer has an IP address
10.0.0.1, and an Ethernet address of 00-40-05-A4-79-32.
2. You are on the same Ethernet segment as the suspect (remember, the
Ethernet is used only to communicate locally on a segment, not remotely
across the Internet).
3. You change the MAC address slightly, such as 00-40-05-A4-79-33.
4. You transmit an "ICMP Echo Request" (ping) with the IP address and this
new MAC address.

23

5. Remember that NOBODY should see this packet, because as the frame
goes down the wire, each Ethernet adapter matches the MAC address with
their own MAC address. If none matches, then they ignore the frame.
6. If you see the response, then the suspect wasn't running this "MAC address
filter" on the card, and is hence sniffing on the wire.
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 FF-00-0000-00-00 looks like FF-FF-FF-FF-FF-FF (the broadcast address which all adapters
accept). However, some adapters implement multicast in such as way that this address
will match as a multicast, which is any address whose first byte is an odd number.
Thus, this can result in false positives).
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.

7.2 ARP method

The ARP method is similar to the ping method, but an ARP packet is used
instead. 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)

7.3 DNS method

24

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.

7.4 host method

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".
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
Of course, the first
thing
a hacker will do is replace the 'ifconfig' program to hide this.
ether
8:0:20:9c:a2:98

1. Encryption

Fig.7.1 Output of a command ifconfig a

8. Sniffing 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
25

(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 securely 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 antisniffing 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.
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.

26

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

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.

9. Basic Packet-Sniffer Construction from the Ground Up

The following illustrates a construction of a packet sniffer from the bottum up,
looking in depth at the sniffer core and then gradualy functionality could later be
added to the application.
This sniffer will illustrate the use of the SOCK_RAW device and show how to gather
packets from the network and print out some simple header information to std_out.
Although the basic premise is that packet sniffers operate in a promiscuous mode
which listens to all packets weather or not the packet is destined for the machines
MAC address, this example will collect packets in a non-promiscuous mode . This
will let us concentrate on the SOCK_RAW device for the first example. To operate
this same code in a promiscous mode the network card may be put in a promiscous
mode manually.
To do this type this in after the log in :

> su Password : ********

# ifconfig eth0 promisc

28

This will now set the network interface eth0 in promiscous mode.
/************************simple_Tcp_sniff.c********************/
1.

#include <stdio.h>

2.

#include <sys/socket.h>

3.

#include <netinet/in.h>

4.

#include <arpa/inet.h>

5.

#include "headers.h"

6.

int main()

7.

8.

int sock, bytes_recieved, fromlen;

9.

char buffer[65535];

10.

struct sockaddr_in from;

11.

struct ip *ip;

12.

struct tcp *tcp;

13.
14.

sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);

15.

while(1)

16.

17.

fromlen = sizeof from;

18.

bytes_recieved = recvfrom(sock, buffer, sizeof buffer, 0,

(struct sockaddr *)&from, &fromlen);

19.

printf("\nBytes received ::: %5d\n",bytes_recieved);

20.

printf("Source address ::: %s\n",inet_ntoa(from.sin_addr));

21.

ip = (struct ip *)buffer;

22.

printf("IP header length ::: %d\n",ip->ip_length);

23.

printf("Protocol ::: %d\n",ip->ip_protocol);

24.

tcp = (struct tcp *)(buffer + (4*ip->ip_length));

25.

printf("Source port ::: %d\n",ntohs(tcp->tcp_source_port);

26.

printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port));

27.

28. }
/***********************EOF**********************************/
What this means :

29

Line 1-4 :
These are the header files required to use some needed c functions we will use later
<stdio.h>

= functions like printf and std_out

<sys/socket.h> = this will give access to the SOCK_RAW and the

IPPROTO_TCP defines
<netinet/in.h> =

structs like the sockaddr_in

<arpa/inet.h>

lets us use the functions to do network to host byte

order conversions
Line 5 :
This is the header file headers.h that is also included with this program to give
standard structures to access the ip and tcp fields. The structures identify each field in
the ip and tcp header for instance :
struct ip {
unsigned int

ip_length:4;

/* length of ip-header in 32-bit

words*/

unsigned int

ip_version:4;

/* set to "4", for Ipv4 */

unsigned char

ip_tos;

/* type of service*/

unsigned short

ip_total_length;

/* Total length of ip datagram in

bytes */

unsigned short

ip_id;

unsigned short

ip_flags;

unsigned char

ip_ttl;

/*identification field*/
/*time-to-live, sets upper limit
for max number of routers to
go through before the packet is
discarded*/

unsigned char

ip_protocol;

/*identifies the correct transport

protocol */

unsigned short

ip_cksum;

/*calculated for the ip header ONLY*/

unsigned int

ip_source;

/*source ip */

unsigned int

ip_dest;

/*dest ip*/

};
struct tcp {
unsigned short

tcp_source_port;

/*tcp source port*/

unsigned short

tcp_dest_port;

/*tcp dest port*/

30

unsigned int

tcp_seqno;

/*tcp sequence number,

identifies the byte in the
stream of data*/

unsigned int

tcp_ackno;

/*contains the next seq num that

the sender expects to recieve*/

unsigned int

tcp_res1:4,

/*little-endian*/

tcp_hlen:4,

/*length of tcp header in 32-bit

words*/

tcp_fin:1,

/*Finish flag "fin"*/

tcp_syn:1,

/*Synchronize sequence
numbers to start a connection

tcp_rst:1,

/*Reset flag */

tcp_psh:1,

/*Push, sends data to the

application*/

tcp_ack:1,

/*acknowledge*/

tcp_urg:1,

/*urgent pointer*/

tcp_res2:2;
unsigned short

tcp_winsize;

/*maxinum number of bytes able

to recieve*/

unsigned short

tcp_cksum;

/*checksum to cover the tcp

header and data portion of the
packet*/

unsigned short

tcp_urgent;

/*vaild only if the urgent flag is

set, used to transmit
emergency data */

};
Line 8-13 :
This is the variable declaration section
integers :
sock

=socket file descriptor

bytes_recieved

= bytes read from the open socket "sock"

fromlen

= the size of the from structure char :

buffer

= where the ip packet that is read off the

wire will be held buffer will hold a datagram

31

of 65535 bytes which is the maximum length

of an ip datagram.
Struct sockaddr_in :
struct sockaddr_in {
short int

sin_family;

/* Address family */

unsigned short int sin_port;

struct in_addr
unsigned char

sin_addr;

/* Port number

*/

/* Internet address */

sin_zero[8]; /* Same size as struct sockaddr */

};
Before we go any further two topics should be covered,byte-ordering and
sockaddr

structures. Byte-ordering,is the way that the operating system stores bytes

in memory. There are two ways that this is done first with the low-order byte at the
starting address this is known as "little-endian" or host-byte order. Next bytes can be
stored with the high order byte at the starting address, this is called "big-endian" or
network byte order.
The Internet protocol uses >>>>>> network byte order.
This is important because if you are working on an intel based linux box you
will be programming on a little-endian machine and to send data via ip you must
convert the bytes to network-byte order. For examle lets say we are going to store a 2byte number in memory say the value is (in hex) 0x0203.
The next topic that one must understand is the sockaddr vs. the sockaddr_in
structures.
The struct sockaddr is used to hold information about the socket such as the
family type and other address information it looks like :
struct sockaddr {
unsigned short sa_family;

/*address family*/

char

/*address data*/

sa_data[14];

};
The first element in the structure "sa_family" will be used to reference what
the family type is for the socket, in our sniffer it will be AF_INET. Next the "sa_data"
element holds the destination port and address for the socket. To make it easier to deal
with the sockaddr struct the use of the sockaddr_in structure is commonly used.
Sockaddr_in makes it easier to reference all of the elements that are contained by
sockaddr.
32

Sockaddr_in looks like:

struct sockaddr_in {
short int

sin_family;

unsigned short int sin_port;

struct in_addr
unsigned char

sin_addr;

/* Address family
/* Port number
/* Internet address

*/
*/
*/

sin_zero[8]; /* Same size as struct sockaddr */

};
We will use this struct and declare a variable "from" which will give us the
information on the packet that we will collect from the raw socket. For instance the
var "from.sin_addr" will give access to the packets source address (in
network byte order). The thing to mention here is that all items in the sockaddr_in
structure must be in network-byte order. When we receive the data in the
sockaddr_in struct we must then convert it back to Host-byte order. To do this we can
use some predefined functions to convert back and forth between host and network
byteorder.
Here are the functions we will use:
ntohs

: this function converts network byte order to host byte order

for a 16-bit short

ntohl

: same as above but for a 32-bit long

inet_ntoa : this function converts a 32-bit network binary value to a

dotted decimal ip address
inet_aton : converts a character string address to the 32-bit network
binary value
inet_addr : takes a char string dotted decimal addr and returns a 32-bit
network binary value
To further illustrate ,say I want to know the port number that this packet originated
from:
int packet_port; packet_port =ntohs(from.sin_port);
If I want the source IP address of the packet we will use a special function to get it
to the 123.123.123.123 format:
char *ip_addr; ip_addr

=inet_ntoa(from.sin_addr)

Line 11-12:
struct ip *ip :
33

struct tcp *tcp :

This is a structure that we defined in our header file "headers.h". This structure
is declared so that we can access individual fields of the ip/tcp header. The structure is
like a transparent slide with predefined fields drawn on it. When a packet is taken off
the wire it is a stream of bits, to make sense of it the "transparency" (or cast) is laid on
top of or over the bits so the individual fields can be referenced.
Line 14 :
sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
This is the most important line in the entire program. Socket() takes three arguments
in this form:
sockfd = socket(int family, int type, int protocol);
The first argument is the family. This could be either AF_UNIX which is used
so a process can communicate with another process on the same host or AF_INET
which is used for internet communication between remote hosts. In this case it will be
AF_INET . Next is the type, the type is usually between 1 of 4 choices
The main four are :
1.

SOCK_DRAM

: used for udp datagrams

2.

SOCK_STREAM

: used for tcp packets

3.

SOCK_RAW

: used to bypass the transport layer

and directly access the IP layer

4.

SOCK_PACKET

: this is linux specific, it is similuar to

SOCK_RAW except it accesses the DATA LINK Layer

For our needs we will use the SOCK_RAW type. You must have root acces to
open a raw socket. The last parameter is the protocol,the protocol value specifies
what type of traffic the socket should receive , for normal sockets this value is usally
set to "0" because the socket can figure out if for instance the "type" of
SOCK_DGRAM is specified then the protocol should be UDP.In our case we just
want to look at tcp traffic so we will specify IPPROTO_TCP.
Line 15 :
while (1)
The while (1) puts the program into an infinite loop this is necessary so that
after the first packet is processed we will loop around and grab the next.
Line 18:
34

bytes_recieved = recvfrom(sock, buffer, sizeof buffer, 0, (struct sockaddr

*)&from, &fromlen);
Now here is where we are actually reading data from the open socket
"sock".The from struct is also filled in but notice that we are casting "from" from a
"sockaddr_in" struct to a "sockaddr" struct. We do this because the recvfrom()
requires a sockaddr type but to access the separate fields we will continue to use the
sockaddr_in structure. The length of the "from" struct must also be present and passed
by address. The recvfrom( ) call will return the number of bytes on success and a -1
on error and fill the global var errno. This is what we call "blocking-I/O" the
recvfrom() will wait here forever until a datagram on the open socket is ready to be
processed. This is opposed to Non-blocking I/O which is like running a process in the
background and move on to other tasks.
Line 20:
printf("Source address ::: %s\n",inet_ntoa(from.sin_addr));
This printf uses the special function inet_ntoa() to take the value of
"from.sin_addr" which is stored in Network-byte order and outputs a value in a
readable ip form such as 192.168.1.XXX.
Line 21:
ip = (struct ip *)buffer;
This is where we will overlay a predefined structure that will help us to
individually identify the fields in the packet that we pick up from the open socket.
Line 22:
printf("IP header length ::: %d\n",ip->ip_length);
The thing to notice on this line is the "ip->ip_length" this will access a pointer in
memory to the ip header length the important thing to remember is that the length
will be represented in 4-byte words this will be more important later when trying to
access items past the ip header such as the tcp header or the data portion of the acket.
Line 23:
printf("Protocol ::: %d\n",ip->ip_protocol);
This gives access to the type of protocol such as 6 for tcp or 17 for udp.
Line 24:
tcp = (struct tcp *)(buffer + (4*ip->ip_length));
The ip header length is stored in 4 byte words, this is where that bit of
information becomes important. Here we are trying to get access to the tcp header
35

fields, to do this we must overlay a structure that has the fields predefined just as we
did with ip. There is one key difference here the ip header fields were easy to access
due to the fact that the beginning of the buffer was also the beginning of the ip header
as so :
|----------------------- buffer ----------------------------|
_________________________________________

ip header
^

* ip
^

* header
So to get access to the ip header we just set a pointer casted as an ip structure to the
beginning of the buffer like "ip = (struct ip *)buffer;". To get access to the tcp header
is a little more difficult due to the fact that we must set a pointer and cast it as a tcp
structure at the beginning of the tcp header which follows the ip header in the buffer
as so :
|----------------------- buffer ----------------------------|

ip header

tcp header

^
* tcp
This is why we use 4*ip->ip_length to find the start of the tcp header.
Line 25-26:
printf("Source port ::: %d\n",ntohs(tcp->tcp_source_port);
printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port));
We can now access the source and dest ports which are located in the tcp header via
the structure as defined above. This concludes a simple tcp sniffer. This was a very
basic application that should help define how to access packets passing on the
network and how to use sockets to access the packets.
To use the above program, cut out the above code and strip off all of the line
numbers. Save the edited file as sniff.c. Next cut out the header file headers.h and
save it to a file headers.h in the same directory. Now just compile: gcc -o sniff sniff.c
You should now have the executable "sniff", to run it type
#./sniff

36

/*************************headers.h**************************/
/*structure of an ip header

*/

struct ip {
unsigned int

ip_length:4;

unsigned int

ip_version:4;

/*little-endian*/

unsigned char

ip_tos;

unsigned short

ip_total_length;

unsigned short

ip_id;

unsigned short

ip_flags;

unsigned char

ip_ttl;

unsigned char

ip_protocol;

unsigned short

ip_cksum;

unsigned int

ip_source;

unsigned int

ip_dest;

};
/* Structure of a TCP header */
struct tcp {
unsigned short

tcp_source_port;

unsigned short

tcp_dest_port;

unsigned int

tcp_seqno;

unsigned int

tcp_ackno;

unsigned int

tcp_res1:4,

/*little-endian*/

tcp_hlen:4,
tcp_fin:1,
tcp_syn:1,
tcp_rst:1,
tcp_psh:1,
tcp_ack:1,
tcp_urg:1,
tcp_res2:2;
unsigned short

tcp_winsize;

unsigned short

tcp_cksum;

unsigned short

tcp_urgent;
37

};
/*********************EOF***********************************/

10. Packet Sniffers Packages

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

WinDump
A version of tcpdump for Windows.

Echelon
Echelon for Dummies is a distributed sniffer which tries to show how the
"echelon" network could be designed. It uses sniffer servers that can be installed and
run on remote hosts, and will dig through local network traffic, using custom
pattern/keyword matching to find packets with interesting content, which are then
forwarded to a central loghost on which the logging daemon is run that gathers and
logs the data. For stealth purposes, Sniffers and the logger communicate via random
protocols and encryption, and are compatible to many Unix systems and NT.

Gobbler
The Gobbler is perhaps the best freeware DOS Ethernet sniffer. It can decode
the Ethernet, IP, TCP and UDP layers, as well as a few low-level protocols like ARP
and ICMP. The interface is notable because it's surprisingly easy to quickly browse a
dump looking for interesting packets. The source code is available, so in theory one
could extend it to your own needs, though I don't know if this is easy to do.

11. Protection against packet sniffers

While one can configure the local network to make sniffing hard, one is powerless
stopping people from out on the Internet from sniffing ones traffic. The best defense
38

in this case is to encrypt the data, so that while they can sniff it, they cannot read it.
Some techniques are:

11.1 SSL
"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.
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.

11.2 VPNs (Virtual Private Networks)

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.

11.3 Replacing hub with a switch

Since a promiscuous sniffer can only sniff the data traffic being shared on its
local network segment, promiscuous sniffing can be completely thwarted through the
use of network "switches" instead of "hubs." A 10Base-T or 100Base-T network hub
operates by retransmitting any received data to all connected machines. But a network
switch "knows" which specific machine and LAN segment any received data is
destined for and it therefore retransmits any received data only on the LAN segment
containing the intended receiver. Therefore, if switches are used instead of hubs, each
machine will occupy its own LAN segment and that segment will only carry data
traffic intended for that machine. Such LAN segmentation renders promiscuous mode
packet sniffers completely powerless.

11.4 Using Adapters that do not support sniffing

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
39

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. But 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.
Non-promiscuous Interface Cards are:

IBM Token-Ring Network PC Adapter

IBM Token-Ring Network 16/4 Adapter

HP 27252A EtherTwist Adapter Card/16 TP Plus

HP J2405A EtherTwist PC LAN Adapter NC/16 TP

11.5 One-time password technology

S/key and other one time password technology makes sniffing account information
almost useless. S/key concept is having your remote host already know a password
that is not going to go over insecure channels and when you connect, you get a
challenge. You take the challenge information and password and plug it into an
algorithm, which generates the response that should get the same answer if the
password is the same on the both sides. Therefore the password never goes over the
network, nor is the same challenge used twice. Unlike SecureID or SNK, with S/key
you do not share a secret with the host.

11.6 Tools to detect packet sniffers

AntiSniff
The most comprehensive sniffer-detection tool.
CPM (Check Promiscuous Mode)
A tool from Carnegie-Mellon that checks to see if promiscuous mode is
enabled on a UNIX machine.
neped
40

A tool from The Apostols that detects packet sniffers running on the local
PromiscDetect
PromiscDetect for Windows NT 4.0 / 2000 / XP checks if your network adapter(s) is
in promiscuous mode or not (that is, in most cases, if a sniffer is running on the
computer or not). Of course the attacker might be intercepting the communication
between the tool and the adapter, making the result unreliable, but there are probably
many more cases out there where the tool will really detect a sniffer.

12. Conclusion
Thus Sniffers capture packet traffic across a network, usually an Ethernet. These can
be placed surreptitiously on your drives. A sniffer can catch all packet traffic on a
particular network block (or segment). Prevention of compromise is a two-fold
process: encryption and compartmentalization. Encrypted communications can be
used to prevent the capture of passwords if a sniffer attack is underway. It can be
assert that one can benefit greatly by running a sniffer on a network, even if only for a
day. This will familiarize him with what problems are faced to implement various
attacks. Also, if one is proficient with a sniffer, one can see for himself what type of
information can actually be gleaned from your particular network configuration

Bibliography

41

[1] The Internet Protocol Journal (IPJ), Volume 2, Number 2, June 1999, Firewalls
and Internet Security, the Second Hundred (Internet) Years by Frederick Avolio,
Avolio Consulting, Inc.
[2] UltimateSniffin' the Ether v2_0. http://networking.earthweb.com
[3] Tapping across a network. http://www.wiretapped.net/
[4] Sniffer Packages. http://packetstormecurity.org and http://www.wiretapped.net
[5] Sniffers the Network Analyzers http://www.networkingunlimited.com
[6] Beej's Guide to Network Programming. http://www.ecst.csuchico.edu/~beej/
[7] TCP/IP Illustrated Vol 1,2,3 - W.Richard Stevens

42