Sniffers

 A Sniffer is any device, whether software or hardware, that grabs information traveling along a network. That network could be running any protocol: Ethernet, TCP/IP, IPX, or others (or any combination of these). The purpose of the Sniffer is to place the network interface--in this case, the Ethernet adapter--into promiscuous mode (which refers to Promiscuous mode refers to that mode where all workstations on a network listen to all traffic, not simply their own. In other words, non-promiscuous mode is where a workstation only listens to traffic route it its own address. In promiscuous mode, the workstation listens to all traffic, no matter what address this traffic was intended for.)  And by doing so, to capture all network traffic.

When discussing on Sniffers, we are not discussing on  key capture utilities, which grab keystrokes and nothing more. Essentially, a key capture utility is the software equivalent of gazing over someone's shoulder. This peering might or might not reveal important information. True, it might capture passwords typed into the console of the local terminal, but what about other terminals? In contrast, Sniffers capture network traffic. This network traffic (irrespective of what protocol is running) is composed of packets (these might be IP datagrams or Ethernet packets). These are exchanged between machines at a very low level of the operating-system network interface. However, these also carry vital data, sometimes very sensitive data. Sniffers are designed to capture and archive that data for later inspection. 

Unlike telephone circuits, computer networks are shared communication channels. It is simply too expensive to 
dedicate local loops to the switch (hub) for each pair of communicating computers. Sharing means that computers 
can receive information that was intended for other machines. To capture the information going over the network 
is called sniffing.  Most popular way of connecting computers is through Ethernet. Ethernet protocol works by 
sending packet information to all the hosts on the same circuit. The packet header contains the proper address 
of the destination machine. Only the machine with the matching address is supposed to accept the packet. 
A machine that is accepting all packets, no matter what the packet header says, is said to be in promiscuous mode.
 Because, in a normal networking environment, account and password information is passed along Ethernet in 
clear-text, it is not hard for an intruder once they obtain root to put a machine into promiscuous mode 
and by sniffing, compromise all the machines on the net.


 Where Is One Likely to Find a Sniffer?

We can find a Sniffer almost anywhere. However, there are some strategic points that a cracker might favor. One of those points is anywhere adjacent to a machine or network that receives many passwords. This is especially so if the targeted machine is the gateway of a network, or a path of data going to or coming from the outside world. If the network goes out to the Internet (and that's really what I'm getting at here), the cracker will want to capture authentication procedures between the network and other networks. This could exponentially expand the cracker's sphere of activity.

Where Do Sniffers Come From and Why Do They Exist?

Sniffers are designed as devices that can diagnose a network connection. traceroute examines the route between two points and is used to determine whether problems exist along that route.

Tools such as traceroute are Sniffers of sorts. However, a hard-core Sniffer is designed to examine the packet traffic at a very deep level. Again, this--like the scanner--has a perfectly legitimate purpose. Sniffers were designed by those aiding network engineers (and not for the purpose of compromising networks).

Some companies produce entire suites of Sniffer applications designed to diagnose network problems. The leading company in this industry is Network General Corporation (NGC), which offers a wide variety of Sniffer products, including

Ø      The Sniffer Network Analyzer (I should mention that the term The Sniffer is a registered trademark of NGC)

Ø      A wide area network (WAN) Sniffer

Ø      Network General Reporter

What Information Is Most Commonly Gotten from a Sniffer?

A Sniffer attack is not as easy as one might think. It requires some knowledge of networking before a cracker can effectively launch one. Simply setting up a Sniffer and leaving it will lead to problems because even a five-station network transmits thousands of packets an hour. Within a short time, the out file of a Sniffer could easily fill a hard disk drive to capacity (if logged every packet).

 

To circumvent this problem, crackers typically sniff only the first 200-300 bytes of each packet. Contained within this portion is the username and password, which is really all most crackers want. However, it is true that one could sniff all the packets on a given interface, if one has the storage media to handle that kind of volume, one would probably find some interesting things.

 

Where Does One Get a Sniffer?

There are many Sniffers available on many platforms. The majority of these are commercial. Commercial sniffing applications are a good idea if you have a real need to diagnose your network (or catch a cracker). They are probably a poor idea if you simply want to learn about networking.

 

angst - an active Sniffer

An active Sniffer, based on libpcap and libnet. Dumps into a file the payload of all the TCP packets received on the specified ports. Can be found at http://angst.sourceforge.net

 

AOL Recorder - AOL Spy Software

Shareware software, which records every AOL activity including IM's, emails (sent and recieved), keywords, keystrokes, websites, screen names, passwords etc. http://www.computer-monitoring.com/aolrecorder.htm

 

aps

LINUX packet Sniffer in C. Can be found at http://www.swrtec.de/swrtec/clinux

 

ASniffer

Windows Sniffer with GUI for both incoming and outgoing traffic. ASniffer shows you raw packets and does full analysis of main network protocols: IP, TCP, UDP, ARP.  Can be found at http://www.aSniffer.com

BKtspibdc

A network tool for sniffing switches. Can be found at http://www.low-level.net/code.php

 

BUTTSNiff 0.9.3

This is a great Sniffer made by cDc. offers tcp monitoring, ftp/telnet/http/pop3/pop2 password sniffing, packet filtering, and alot of other features. Can be found at http://newdata.box.sk/2000/buttsniff.zip

 

ethereal

A network protocol analyzer that lets you capture and interactively browse the contents of network frames. Can be found at http://www.ethereal.com

 

Ethereal 0.8.4

Sniffer for bsd. Can be found at http://www.ethereal.com

 

ICMPSniffer

ICMP datagram Sniffer. Can be found at http://newdata.box.sk/neworder/feb2000/icmpsnif.exe

 

krnsniff.c

A kernel based Sniffer module. Can be found at http://newdata.box.sk/neworder/pt/krnsniff.c

 

linSniffer-LK.c

LinSniffer 0.03. Can be found at http://newdata.box.sk/Fneworder/pt/linSniffer-LK.c

 

maxty

A small kernel-space tty Sniffer, it is LKM which will attach to read/write syscalls and save requests into separate log files. http://newdata.box.sk/2001/apr/maxty.tar.gz

 

mpsnif

Small network Sniffer for win9x. Can be found at http://digilander.iol.it/ItaAto/mpsnif.html

 

Natas, Network Administrators Tool for Analyzing and Sniffing

Natas is an advanced network packet capturing and analyzing program designed for Windows 2000. Natas only works with the new Windows 2000 Winsock v2.2 that supports raw sockets like *nix operating systems. You have to be admin on the machine to run Natas. Can be found at http://intex.ath.cx/natas.html

 

ngrep - network grep

ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep is a pcap-aware tool that will allow you to specify extended regular expressions to match against data payloads of packets. It currently recognizes TCP, UDP and ICMP across Ethernet, PPP, SLIP, FDDI and null interfaces, and understands bpf filter logic in the same fashion as more common packet sniffing tools, such as tcpdump and snoop. Can be found at http://ngrep.sourceforge.net

 

nicedump-0.9.1b.tgz

A network Sniffer which tries to display the entire packet contents.  http://newdata.box.sk/2001/jan/nicedump-0.9.1b.tgz

 

 

packet32.zip

Packetdriver source code (32bit) from Christopher Chlap, for those who want to code their own Windows 95/98/NT Sniffers. Can be found at http://newdata.box.sk/2001/jan/packet32.zip

 

parasite-0.5.tar.gz

THC-Parasite allows you to sniff traffic on a switched network by using either ARP Spoofing or MAC Flooding. Can be found at http://newdata.box.sk/2001/jan/parasite-0.5.tar.gz

 

pcapture.tar.gz

Simple pcap dumper (just to learn on how to use libpcap). Can be found at http://newdata.box.sk/2001/jan/pcapture.tar.gz

 

pdump

An advanced perl packet Sniffer -dumps, greps, monitors, creates, and modifies traffic on a network. It combines features from tcpdump, ngrep, tcptrace, dsniff (with its webspy and urlsnarf), pfilt, macof, and xpy. It understands tcpdump-like syntax and allows easy modifications via a plug-in system. Can be found at http://pdump.lucidx.com

 

PHoss - Phenoelit's own security Sniffer

PHoss is a Sniffer designed to find HTTP, FTP, LDAP, Telnet, IMAP4 and POP3 logins on the wire. Can be found at http://www.phenoelit.de/phoss

 

pptp-sniff.tar.gz

PPTP Sniffer for L0phtCrack. This will sniff PPTP authentication and output the challenge and password hashes just like our readsmb Sniffer that comes with the l0phtcrack distribution. This only works with Solaris right now. Can be found at http://newdata.box.sk/2001/jan/pptp-sniff.tar.gz

 

Roe's downloads

Self-programmed apps, including a network Sniffer for finding passwords. Can be found at http://www.roe.ch/download

 

ScoopLm

Captures LM/NTLM authentication information (LanManager and Windows
NT challenge/response) on the network. Can be found at http://www.securityfriday.com/scooplm_doc.html

 

sersniff

A simple program to tunnel/sniff between 2 serial ports. Can be found at http://www.earth.li/projectpurple/progs/sersniff.html

 

Sniff'em

A packet Sniffer for Windows OS. Can be found at http://www.sniff-em.com/subsniff.html

 

Sniffit 0.3.2

Enhanced Sniffer for linux. Can be found at http://newdata.box.sk/neworder/sniffit.0.3.2.tar.gz

 

sniffit for WinNT

Windows port of sniffit - network Sniffer. Can be found at http://www.symbolic.it/Prodotti/sniffit.html

 

snmpsniff-1.0.tar.gz

SNMP Sniff v1.0 allows you to decode any SNMPv[1,2]c packets that go through your network. It shows just about everything you need to know about the PDU, including errors, variable bindings, etc. can be found at http://newdata.box.sk/2001/jan/snmpsniff-1.0.tar.gz

 

Snoopie

A little DOS-program that uses a PC/TCP-compatible packet-driver to switch your network adapter intopromiscous-mode where every network-traffic can be monitored by your machine. It traces all open TCP-connections on your local network to catch logins from ftp-, telnet- and POP3-connections. The found passwords are shown on the screen and are written to your harddisk when you terminate snoopie. Can be found at http://privat.schlund.de/s/snoopie/

 

snuff

Multi-stream packet Sniffer for Linux kernels 2.0/2.2. Can be found at http://ns2.crw.se/tm

 

spynet312.exe

SpyNet v3.12 is a Sniffer for Win 95/98/NT/2000 which can recompose the original TCP sessions from the composing packets. Reconstructs telnet sessions, e-mail messages, POP3 logins, etc. Also has the ability to fake cookies it sniffs. Can be found at http://newdata.box.sk/2001/jan/spynet312.exe

 

ssldump

An SSLv3/TLS network protocol analyzer. It identifies TCP connections on the chosen network interface and attempts to interpret them as SSLv3/TLS traffic. Can be found at http://www.rtfm.com/ssldump

 

synsniff11.tar.gz

synsniff, as the name would imply, is a simple program, which watches for the first part of a TCP connection (the SYN packet) and logs it. Optionally, synsniff can detect FIN (end of session) packets with no corresponding SYN; this is useful for discovering stealth FIN scans. It is primarily a TCP connection logger but also includes some portscan detection heuristic. Can be found at http://newdata.box.sk/2001/jan/synsniff11.tar.gz

 

tcpdump/libpcap

Allows you to dump traffic in the network; great for examining packets, packet headers. Can be found at http://www.tcpdump.org

 

tcpflow-0.12.tar.gz

Tcpflow is a program that captures data transmitted as part of TCP connections (flows), and stores the data in a way that is convenient for protocol analysis or debugging. tcpflow understands TCP sequence numbers and will correctly reconstruct data streams regardless of retransmissions or out-of-order delivery. Each stream is stored in a separate file for later analysis. tcpflow is designed to be portable, using the LBL packet capture library and GNU autoconf. It works under most UNIX platforms and for most common network interface types (Ethernet, PPP, loopback, etc.). Can be found at http://newdata.box.sk/2001/jan/tcpflow-0.12.tar.gz

 

tcpnetra.c

Sniffs incoming tcp packets. Can be found at http://newdata.box.sk/neworder/pt/tcpnetra.c

 

tml.tgz

TCP-msglogger. http://newdata.box.sk/neworder/pt/tml.tgz

vpacket.zip

Packetdriver source code (16bit) from Christopher Chlap, for those who want to code their own Windows 95/98/NT snuffers. http://newdata.box.sk/2001/jan/vpacket.zip

 

weedlog

Linux packet logger. Can be found at http://www.firepool.com/weedlog

 

Win Sniffer for 95/NT/2000

Console Sniffer for MS Windows 95/NT/2000. Can be found at http://server36.hypermart.net/winsniff

 

xipdump-1.5.2.tgz

Xipdump is a protocol analyzer and tester. It's a kind of graphical tcpdump (8), which adds the possibility of changing packet values and resending them. The graphical representation of a packet is intended to offer a complete, customizable view at a glance. Changes: A port to Solaris. Can be found at http://newdata.box.sk/2001/jan/xipdump-1.5.2.tgz

 

sniffer program writter in 'C code ' download here

 Analysis of the captured frame

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

Here we looks at a captured frame that is actually an HTTP GET request issued from one 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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 t                                                                                        

The actual data (i.e. the HTTP GET request.)

The Ethernet Header

3C

2E

AC

00

01

01

00

01

D0

E1

66

80

08

00

 

 

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. Communication between hosts at the datalink level of communication use this AC 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

The IP Header

45

00

01

F7

E8

80

40

00

80

06

39

40

C2

7E

57

A5

D1

01

EC

1A

 

Above is a table it may take some explaining: 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 (IPng) header this 4 would become a 6. However the IPv6 header is somewhat different to the IPv4 header. But in here we go 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 TOS (Type of Service) 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. 

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 traveling 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 e.g. 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 fragment i.e. it is chopped up into more manageable chunks there has to be a way of 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. eg 10. Now let say the datagram never reaches it destination...when this byte's value becomes 0 the router will discard it and send back an ICMP message to the source host telling it that the destination host is unreachable.

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

 

Detecting Sniffers

  

To detect a sniffing device that only collects data and does not respond to any of the information, requires physically checking all your ethernet connections by walking around and checking the ethernet connections individually.


 


It is also impossible to remotely check by sending a packet or ping if a machine is sniffing.


A Sniffer running on a machine puts the interface into promiscuous mode, which accepts all the packets. On some Unix boxes, it is possible to detect a promiscuous interface. It is possible to run a Sniffer in non-promiscuous mode, but it will only capture sessions from the machine it is running on. It is also possible for the intruder to do similiar capture of sessions by trojaning many  programs such as sh, telnet, rlogin, in.telnetd, and so on to write a log file of what the user did. They can easily watch the tty and kmem devices as well.


 


These attacks will only compromise sessions coming from that one machine, while promiscuous sniffing compromises all sessions on the ethernet. For SunOs, NetBSD, and other possible BSD derived Unix systems, there is a  command


 "ifconfig -a"


 


that will tell you information about all the interfaces and if they are in promiscuous mode. DEC OSF/1 and IRIX and possible other OSes require the device to be specified. One way to find out what interface is on the system, you can execute:


# netstat –r


 


Then you can test for each interface by doing the following command:


#ifconfig le0


 


Intruders often replace commands such as ifconfig to avoid detection. Make sure you verify its checksum.


Ultrix can possibly detect someone running a Sniffer by using the commands:


pfstat and pfconfig.


pfconfig allows you to set who can run a Sniffer


pfstat shows you if the interface is in promiscuous mode.


 


These commands only work if sniffing is enabled by linking it into the kernel. by default, the Sniffer is not linked into the kernel. Most other Unix systems, such as Irix, Solaris, SCO, etc, do not have any flags indication whether they are in promiscuous mode or not, therefore an intruder could be sniffing your whole network and there is no way to detect it.


Often a Sniffer log becomes so large that the file space is all used up. On a high volume network, a Sniffer will create a large load on the machine. These sometimes trigger enough alarms that the administrator will discover a Sniffer.


I highly suggest using lsof (LiSt Open Files) available from  coast.cs.purdue.edu:/pub/Purdue/lsof for finding log files and finding programs that are accessing the packet device such as /dev/nit on SunOs.


There is no commands I know of to detect a promiscuous IBM PC compatible machine, but they atleast usually do not allow command execution unless from the console, therefore remote intruders can not turn a PC machine into a Sniffer without inside assistance.


 


Stopping sniffing attacks


 


Softwares in detecting Sniffers

 

dsniff

A collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due tolayer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings. Can be found at http://www.monkey.org/edugsong/dsniff

 

antisniff b1 - l0pht

It detects people monitoring(sniffing) the local network's traffic. Can be found at http://newdata.box.sk/2000/antisniff.zip

 

Attacker v3.0

A TCP/UDP port listener/attack warning program. Can be found at http://www.foundstone.com/resources/tools.html

 

Blast

A small, quick TCP service stress test tool to help spot potential weaknesses in your network server. Can be found at http://www.foundstone.com/resources/tools.html

 

Snort

Linux libpcap-based packet Sniffer/logger which can be used as a lightweight network intrusion detection system. It features rules based logging which can perform content searching/matching and may be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and much more. Can be found at http://www.snort.org 

 Tools


 Active hubs send to each system only packets intended for it rendering promiscuous sniffing useless. This is only effective for 10-Base T. The following vendors have available active hubs: 


   *  3Com    *  HP 


 Encryption


There are several packages out there that allow encryption between connections therefore an intruder could capture the data, but could not decypher it to make any use of it.


Some packages available are:


   *  deslogin is one package available at ftp.coast.cs.purdue.edu:/pub/tools/unix/deslogin .


   * swIPe is another package available at  ftp.csua.berkeley.edu:/pub/cypherpunks/swIPe/


   * Netlock encrypts all (tcp, udp, and raw ip based) communications transparently. It has automatic (authenticated Diffie-Helman) distributed key management mechanism for each host and runs on the SUN 4.1 and HP 9.x systems. The product comes with a Certification Authority Management  application which generates host certificates (X.509) used for authentication  between the hosts. and provides centralized control of each     Hosts communications rules.


     The product is built by Hughes Aircraft and they can be reached at  800-825-LOCK or email at netlock@mls.hac.com.


 


Kerberos


Kerberos is another package that encrypts account information going over the network. Some of its draw backs are that all the account information is held on one host and if that machine is compromised, the whole network is vulnerable. It is has been reported a major difficulty to set up. Kerberos comes with a stream-encrypting rlogind, and stream-encrypting telnetd is available. This prevents intruders from capturing what you did after you logged in. There is a Kerberos FAQ at ftp at rtfm.mit.edu in 


/pub/usenet/comp.protocols/kerberos/Kerberos_Users__Frequently_Asked_Questions_1.11


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. S/key is available on  ftp:thumper.bellcore.com:/pub/nmh/skey


 Other one time password technology is card systems where each user gets a card that generates numbers that allow access to their account. Without the card, it is improbable to guess the numbers.


 The following are companies that offer solutions that are provide better password authenication (ie, handheld password devices):


Secure Net Key (SNK) : phone: 415-964-0707 Fax: (415) 961-7487


Secure ID : USA Phone: 617-547-7820


ArKey and OneTime Pass : Phone : US+216-686-0090 Fax: US+216-686-0092


WatchWord and WatchWord II : Phone :1-800-521-6261 ext 217


CRYPTOCard : Phone : 608-278-7700 


SafeWord : Phone :510-827-5707 Fax: (510)827-2593


Secure Computing Corporation: Phone: (612) 628-2700





Non-promiscuous Interfaces


You can try to make sure that most IBM DOS compatible machines have interfaces


that will not allow sniffing. Here is a list of cards that do not support promiscuous mode: 


Test the interface for promiscuous mode by using the Gobbler. 


     IBM Token-Ring Network PC Adapter


     IBM Token-Ring Network PC Adapter II (short card)


     IBM Token-Ring Network PC Adapter II (long card)


     IBM Token-Ring Network 16/4 Adapter


     IBM Token-Ring Network PC Adapter/A


     IBM Token-Ring Network 16/4 Adapter/A


     IBM Token-Ring Network 16/4 Busmaster Server Adapter/A


The following cards are rumoured to be unable to go into promiscuous mode, but


that the veracity of those rumours is doubtful.


     Microdyne (Excelan) EXOS 205


     Microdyne (Excelan) EXOS 205T


     Microdyne (Excelan) EXOS 205T/16


     Hewlett-Packard 27250A EtherTwist PC LAN Adapter Card/8


     Hewlett-Packard 27245A EtherTwist PC LAN Adapter Card/8


     Hewlett-Packard 27247A EtherTwist PC LAN Adapter Card/16


     Hewlett-Packard 27248A EtherTwist EISA PC LAN Adapter Card/32


     HP 27247B EtherTwist Adapter Card/16 TP Plus


     HP 27252A EtherTwist Adapter Card/16 TP Plus


     HP J2405A EtherTwist PC LAN Adapter NC/16 TP


Adapters based upon the TROPIC chipset generally do not support promiscuous mode. The TROPIC 
chipset is used in IBM's Token Ring adapters such as the 16/4 adapter. Other vendors (notably 3Com) 
also supply TROPIC based adapters. TROPIC-based adapters do accept special EPROMs, however, 
that will allow them to go into promiscuous mode. However, when in promiscuous mode, these 
adapters will spit out a "Trace Tool Present" frame.


 


These considerations are all relevant to the Sniffer issue. In closing, Sniffers are very powerful tools for 
crackers, but only if a person lets them be. Moreover, if system administrator find one on the network, 
do not immediately remove it. Instead, install one of your own and find out who is pulling the strings. In order to find out who is sniffing.