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 browserbased 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.1Types 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 applicationlevel 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 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, and 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 addresses 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 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 030 70 79 8F 27 00 00 48 54 54 50 2F 31 2E 31 20 32 040 30 30 20 4F 4B 0D 0A 56 69 61 3A 20 31 2E 30 20 050 53 54 52 49 44 45 52 0D 0A 50 72 6F 78 79 2D 43 060 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 070 41 6C 69 76 65 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 080 65 6E 67 74 68 3A 20 32 39 36 37 34 0D 0A 43 6F 090 6E 74 65 6E 74 2D 54 79 70 65 3A 20 74 65 78 74 0A0 2F 68 74 6D 6C 0D 0A 53 65 72 76 65 72 3A 20 4D 0B0 69 63 72 6F 73 6F 66 74 2D 49 49 53 2F 34 2E 30 ...P.u......}.P. py.'..HTTP/1.1.2 00.OK..Via:.1.0. STRIDER..Proxy-C onnection:.KeepAlive..Content-L ength:.29674..Co ntent-Type:.text /html..Server:.M icrosoft-IIS/4.0

0C0 0D 0A 44 61 74 65 3A 20 53 75 6E 2C 20 32 35 20 0D0 4A 75 6C 20 31 39 39 39 20 32 31 3A 34 35 3A 35 0E0 31 20 47 4D 54 0D 0A 41 63 63 65 70 74 2D 52 61 0F0 6E 67 65 73 3A 20 62 79 74 65 73 0D 0A 4C 61 73 100 74 2D 4D 6F 64 69 66 69 65 64 3A 20 4D 6F 6E 2C 110 20 31 39 20 4A 75 6C 20 31 39 39 39 20 30 37 3A 120 33 39 3A 32 36 20 47 4D 54 0D 0A 45 54 61 67 3A 130 20 22 30 38 62 37 38 64 33 62 39 64 31 62 65 31

..Date:.Sun,.25. Jul.1999.21:45:5 1.GMT..Accept-Ra nges:.bytes..Las t-Modified:.Mon, .19.Jul.1999.07: 39:26.GMT..ETag: ."08b78d3b9d1be1

140 3A 61 34 61 22 0D 0A 0D 0A 3C 74 69 74 6C 65 3E :a4a"....<title> Sniffing. (Network) wiretap, .sniffer) .FAQ</title>. <h1>Sniffing. (network.wiretap , .sniffer).FAQ</ 150 53 6E 69 66 66 69 6E 67 20 28 6E 65 74 77 6F 72 160 6B 20 77 69 72 65 74 61 70 2C 20 73 6E 69 66 66 170 65 72 29 20 46 41 51 3C 2F 74 69 74 6C 65 3E 0D 180 0A 0D 0A 3C 68 31 3E 53 6E 69 66 66 69 6E 67 20 190 28 6E 65 74 77 6F 72 6B 20 77 69 72 65 74 61 70 1A0 2C 20 73 6E 69 66 66 65 72 29 20 46 41 51 3C 2F

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 1D0 73 74 69 6F 6E 73 20 61 62 6F 75 74 20 74 61 70 1E0 70 69 6E 67 20 69 6E 74 6F 20 0D 0A 63 6F 6D 70 1F0 75 74 65 72 20 6E 65 74 77 6F 72 6B 73 20 61 6E ... Fig. 2.4 "hexdump" of a network packet ment.answers.que stions.about.tap ping.into...comp uter.networks.an

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

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

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: Internet

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:

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

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 is 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? 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. 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: Bob:

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

ARP broadcast request

ARP unicast response

ICMP ping request

ICMP ping response

ICMP ping request Fig. 4.2 Requests exchanged between 2 nodes in a network 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 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 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.

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

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.

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

0-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-toEthernet 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 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 modes 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 Ether 8:0:20:9c:a2:98

Of course, the first thing a hacker will do is replace the 'ifconfig' program to hide this.

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 (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 would need to know the "spreading" function used. eavesdropper

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

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 40bit 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 usesshared-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

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 basestations 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 email, 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 types this in after the log in: > Su -

Password: ********
# ifconfig eth0 promisc This will now set the network interface eth0 in promiscous mode.

/************************simple_Tcp_sniff.c********************/

1. 2. 3. 4. 5.

#include <stdio.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include "headers.h"

6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

int main () { int sock, bytes_recieved, fromlen; char buffer[65535]; struct sockaddr_in from; struct ip *ip; struct tcp *tcp;

sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP); while (1) { fromlen = sizeof from; bytes_recieved = recvfrom (sock, buffer, sizeof buffer, 0, (struct sockaddr *)&from, &fromlen);

19. 20. 21. 22. 23. 24. 25. 26. 27. 28.}

printf ("\nBytes received ::: %5d\n", bytes_recieved); printf ("Source address ::: %s\n", inet_ntoa(from.sin_addr)); ip = (struct ip *) buffer; printf("IP header length ::: %d\n",ip->ip_length); printf ("Protocol ::: %d\n", ip->ip_protocol); tcp = (struct tcp *)(buffer + (4*ip->ip_length)); printf ("Source port ::: %d\n", ntohs(tcp->tcp_source_port); printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port)); }

/***********************EOF**********************************/ What this means: 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> = <arpa/inet.h> = structs like the sockaddr_in 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 unsigned char unsigned short ip_version:4; ip_tos; ip_total_length; /* set to "4", for Ipv4 */ /* type of service*/ /* Total length of ip datagram in bytes */ unsigned short unsigned short unsigned char ip_id; ip_flags; ip_ttl; /*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 unsigned int unsigned int }; struct tcp { unsigned short tcp_source_port; /*tcp source port*/ ip_cksum; ip_source; ip_dest; /*calculated for the ip header ONLY*/ /*source ip */ /*dest ip*/ /*identification field*/

unsigned short unsigned int

tcp_dest_port; tcp_seqno;

/*tcp dest port*/ /*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*/ /*length of tcp header in 32-bit words*/

tcp_hlen:4,

tcp_fin:1, tcp_syn:1,

/*Finish flag "fin"*/ /*Synchronize sequence numbers to start a connection

tcp_rst:1, tcp_psh:1,

/*Reset flag */ /*Push, sends data to the application*/

tcp_ack:1, tcp_urg:1, tcp_res2:2; unsigned short tcp_winsize;

/*acknowledge*/ /*urgent pointer*/

/*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 bytes_recieved fromlen buffer

=socket file descriptor = bytes read from the open socket "sock" = the size of the from structure char: = where the ip packet that is read off the wire will be held buffer will hold a datagram 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; /* Port number struct in_addr unsigned char };

sin_addr; /* 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 2-byte 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; char }; 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 sa_data[14]; /*address family*/ /*address data*/

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. Sockaddr_in looks like: struct sockaddr_in { short int sin_family; /* Address family /* Port number /* Internet address */ */ */

unsigned short int sin_port; struct in_addr unsigned char }; sin_addr;

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 : 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. 2. 3. SOCK_DRAM SOCK_STREAM SOCK_RAW : used for udp datagrams : used for tcp packets : 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: 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 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

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

unsigned int unsigned int unsigned char unsigned short unsigned short unsigned short unsigned char unsigned char unsigned short unsigned int unsigned int };

ip_length:4; /*little-endian*/ ip_version:4; ip_tos; ip_total_length; ip_id; ip_flags; ip_ttl; ip_protocol; ip_cksum; ip_source; ip_dest;

/* Structure of a TCP header */ struct tcp { unsigned short unsigned short unsigned int unsigned int tcp_source_port; tcp_dest_port; tcp_seqno; tcp_ackno;

unsigned int 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 unsigned short unsigned short };

tcp_res1:4,

/*little-endian*/

tcp_winsize; tcp_cksum; tcp_urgent;

/*********************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 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 email secret is to encrypt it. 11.2 VPNs (Virtual Private Networks) VPNs provide encrypted traffic across the Internet. However, if a hacker compromises the endnodes 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 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 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

[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