Modern Hackers

8/7/2019 Modern Hackers

1/428

The MH DeskReference

Version 1.2

Written/Assembled by

The Rhino9 Team

Table of Contents

=Part One=

=Essential background Knowledge=

[0.0.0] Preface

[0.0.1] The Rhino9 Team

[0.0.2] Disclaimer

[0.0.3] Thanks and Greets

[1.0.0] Preface To NetBIOS

[1.0.1] What is NetBIOS?

[1.0.2] NetBIOS Names

[1.0.3] NetBIOS Sessions

[1.0.4] NetBIOS Datagrams

[1.0.5] NetBEUI Explained


2/428

[1.0.6] NetBIOS Scopes

[1.2.0] Preface to SMB's

[1.2.1] What are SMB's?

[1.2.2] The Redirector

[2.0.0] What is TCP/IP?

[2.0.1] FTP Explained

[2.0.2] Remote Login

[2.0.3] Computer Mail

[2.0.4] Network File Systems

[2.0.5] Remote Printing

[2.0.6] Remote Execution

[2.0.7] Name Servers

[2.0.8] Terminal Servers

[2.0.9] Network-Oriented Window Systems

[2.1.0] General description of the TCP/IP protocols

[2.1.1] The TCP Level

[2.1.2] The IP level

[2.1.3] The Ethernet level

[2.1.4] Well-Known Sockets And The Applications Layer

[2.1.5] Other IP Protocols

[2.1.6] Domain Name System


3/428

[2.1.7] Routing

[2.1.8] Subnets and Broadcasting

[2.1.9] Datagram Fragmentation and Reassembly

[2.2.0] Ethernet encapsulation: ARP

[3.0.0] Preface to the WindowsNT Registry

[3.0.1] What is the Registry?

[3.0.2] In Depth Key Discussion

[3.0.3] Understanding Hives

[3.0.4] Default Registry Settings

[4.0.0] Introduction to PPTP

[4.0.1] PPTP and Virtual Private Networking

[4.0.2] Standard PPTP Deployment

[4.0.3] PPTP Clients

[4.0.4] PPTP Architecture

[4.0.5] Understanding PPTP Security

[4.0.6] PPTP and the Registry

[4.0.7] Special Security Update

[5.0.0] TCP/IP Commands as Tools

[5.0.1] The Arp Command

[5.0.2] The Traceroute Command


4/428

[5.0.3] The Netstat Command

[5.0.4] The Finger Command

[5.0.5] The Ping Command

[5.0.6] The Nbtstat Command

[5.0.7] The IpConfig Command

[5.0.8] The Telnet Command

[6.0.0] NT Security

[6.0.1] The Logon Process

[6.0.2] Security Architecture Components

[6.0.3] Introduction to Securing an NT Box

[6.0.4] Physical Security Considerations

[6.0.5] Backups

[6.0.6] Networks and Security

[6.0.7] Restricting the Boot Process

[6.0.8] Security Steps for an NT Operating System

[6.0.9] Install Latest Service Pack and applicable hot-fixes

[6.1.0] Display a Legal Notice Before Log On

[6.1.1] Rename Administrative Accounts

[6.1.2] Disable Guest Account

[6.1.3] Logging Off or Locking the Workstation

[6.1.4] Allowing Only Logged-On Users to Shut Down the Computer

[6.1.5] Hiding the Last User Name


5/428

[6.1.6] Restricting Anonymous network access to Registry

[6.1.7] Restricting Anonymous network access to lookup account names and networkshares

[6.1.8] Enforcing strong user passwords

[6.1.9] Disabling LanManager Password Hash Support

[6.2.0] Wiping the System Page File during clean system shutdown

[6.2.1] Protecting the Registry

[6.2.2] Secure EventLog Viewing

[6.2.3] Secure Print Driver Installation

[6.2.4] The Schedule Service (AT Command)

[6.2.5] Secure File Sharing

[6.2.6] Auditing

[6.2.7] Threat Action

[6.2.8] Enabling System Auditing

[6.2.9] Auditing Base Objects

[6.3.0] Auditing of Privileges

[6.3.1] Protecting Files and Directories

[6.3.2] Services and NetBios Access From Internet

[6.3.3] Alerter and Messenger Services

[6.3.4] Unbind Unnecessary Services from Your Internet Adapter Cards

[6.3.5] Enhanced Protection for Security Accounts Manager Database

[6.3.6] Disable Caching of Logon Credentials during interactive logon.

[6.3.7] How to secure the %systemroot%\repair\sam._ file

[6.3.8] TCP/IP Security in NT


6/428

[6.3.9] Well known TCP/UDP Port numbers

[7.0.0] Preface to Microsoft Proxy Server

[7.0.1] What is Microsoft Proxy Server?

[7.0.2] Proxy Servers Security Features

[7.0.3] Beneficial Features of Proxy

[7.0.4] Hardware and Software Requirements

[7.0.5] What is the LAT?

[7.0.6] What is the LAT used for?

[7.0.7] What changes are made when Proxy Server is installed?

[7.0.8] Proxy Server Architecture

[7.0.9] Proxy Server Services: An Introduction

[7.1.0] Understanding components

[7.1.1] ISAPI Filter

[7.1.2] ISAPI Application

[7.1.3] Proxy Servers Caching Mechanism

[7.1.4] Windows Sockets

[7.1.5] Access Control Using Proxy Server

[7.1.6] Controlling Access by Internet Service

[7.1.7] Controlling Access by IP, Subnet, or Domain

[7.1.8] Controlling Access by Port

[7.1.9] Controlling Access by Packet Type

[7.2.0] Logging and Event Alerts


7/428

[7.2.1] Encryption Issues

[7.2.2] Other Benefits of Proxy Server

[7.2.3] RAS

[7.2.4] IPX/SPX

[7.2.5] Firewall Strategies

[7.2.6] Logical Construction

[7.2.7] Exploring Firewall Types

[7.2.3] NT Security Twigs and Ends

=Part Two=

=The Techniques of Survival=

[8.0.0] NetBIOS Attack Methods

[8.0.1] Comparing NAT.EXE to Microsoft's own executables

[8.0.2] First, a look at NBTSTAT

[8.0.3] Intro to the NET commands

[8.0.4] Net Accounts

[8.0.5] Net Computer

[8.0.6] Net Config Server or Net Config Workstation

[8.0.7] Net Continue

[8.0.8] Net File

[8.0.9] Net Group


8/428

[8.1.0] Net Help

[8.1.1] Net Helpmsg message#

[8.1.2] Net Localgroup

[8.1.3] Net Name

[8.1.4] Net Pause

[8.1.5] Net Print

[8.1.6] Net Send

[8.1.7] Net Session

[8.1.8] Net Share

[8.1.9] Net Statistics Server or Workstation

[8.2.0] Net Stop

[8.2.1] Net Time

[8.2.2] Net Use

[8.2.3] Net User

[8.2.4] Net View

[8.2.5] Special note on DOS and older Windows Machines

[8.2.6] Actual NET VIEW and NET USE Screen Captures during a hack

[9.0.0] Frontpage Extension Attacks

[9.0.1] For the tech geeks, we give you an actual PWDUMP

[9.0.2] The haccess.ctl file

[9.0.3] Side note on using John the Ripper


9/428

[10.0.0] WinGate

[10.0.1] What Is WinGate?

[10.0.2] Defaults After a WinGate Install

[10.0.3] Port 23 Telnet Proxy

[10.0.4] Port 1080 SOCKS Proxy

[10.0.5] Port 6667 IRC Proxy

[10.0.6] How Do I Find and Use a WinGate?

[10.0.7] I have found a WinGate telnet proxy now what?

[10.0.8] Securing the Proxys

[10.0.9] mIRC 5.x WinGate Detection Script

[10.1.0] Conclusion

[11.0.0] What a security person should know about WinNT

[11.0.1] NT Network structures (Standalone/WorkGroups/Domains)

[11.0.2] How does the authentication of a user actually work

[11.0.3] A word on NT Challenge and Response

[11.0.4] Default NT user groups

[11.0.5] Default directory permissions

[11.0.6] Common NT accounts and passwords

[11.0.7] How do I get the admin account name?

[11.0.8] Accessing the password file in NT

[11.0.9] Cracking the NT passwords

[11.1.0] What is 'last login time'?


10/428

[11.1.1] Ive got Guest access, can I try for Admin?

[11.1.2] I heard that the %systemroot%\system32 was writeable?

[11.1.3] What about spoofin DNS against NT?

[11.1.4] What about default shared folders?

[11.1.5] How do I get around a packet filter-based firewall?

[11.1.6] What is NTFS?

[11.1.7] Are there are vulnerabilities to NTFS and access controls?

[11.1.8] How is file and directory security enforced?

[11.1.9] Once in, how can I do all that GUI stuff?

[11.2.0] How do I bypass the screen saver?

[11.2.1] How can tell if its an NT box?

[11.2.2] What exactly does the NetBios Auditing Tool do?

[12.0.0] Cisco Routers and their configuration

[12.0.1] User Interface Commands

[12.0.2] disable

[12.0.3] editing

[12.0.4] enable

[12.0.5] end

[12.0.6] exit

[12.0.7] full-help

[12.0.8] help


11/428

[12.0.9] history

[12.1.0] ip http access-class

[12.1.1] ip http port

[12.1.2] ip http server

[12.1.3] menu (EXEC)

[12.1.4] menu (global)

[12.1.5] menu command

[12.1.6] menu text

[12.1.7] menu title

[12.1.8] show history

[12.1.9] terminal editing

[12.2.0] terminal full-help (EXEC)

[12.2.1] terminal history

[12.2.2] Network Access Security Commands

[12.2.3] aaa authentication arap

[12.2.4] aaa authentication enable default

[12.2.5] aaa authentication local-override

[12.2.6] aaa authentication login

[12.2.7] aaa authentication nasi

[12.2.8] aaa authentication password-prompt

[12.2.9] aaa authentication ppp

[12.3.0] aaa authentication username-prompt

[12.3.1] aaa authorization


12/428

[12.3.2] aaa authorization config-commands

[12.3.3] aaa new-model

[12.3.4] arap authentication

[12.3.5] clear kerberos creds

[12.3.6] enable last-resort

[12.3.7] enable use-tacacs

[12.3.8] ip radius source-interface

[12.3.9] ip tacacs source-interface

[12.4.0] kerberos clients mandatory

[12.4.1] kerberos credentials forward

[12.4.2] kerberos instance map

[12.4.3] kerberos local-realm

[12.4.4] kerberos preauth

[12.4.5] kerberos realm

[12.4.6] kerberos server

[12.4.7] kerberos srvtab entry

[12.4.8] kerberos srvtab remote

[12.4.9] key config-key

[12.5.0] login tacacs

[12.5.1] nasi authentication

[12.5.2] ppp authentication

[12.5.3] ppp chap hostname

[12.5.4] ppp chap password


13/428

[12.5.5] ppp pap sent-username

[12.5.6] ppp use-tacacs

[12.5.7] radius-server dead-time

[12.5.8] radius-server host

[12.5.9] radius-server key

[12.6.0] radius-server retransmit

[12.6.1] show kerberos creds

[12.6.2] show privilege

[12.6.3] tacacs-server key

[12.6.4] tacacs-server login-timeout

[12.6.5] tacacs-server authenticate

[12.6.6] tacacs-server directed-request

[12.6.7] tacacs-server key

[12.6.8] tacacs-server last-resort

[12.6.9] tacacs-server notify

[12.7.0] tacacs-server optional-passwords

[12.7.1] tacacs-server retransmit

[12.7.2] tacacs-server timeout

[12.7.3] Traffic Filter Commands

[12.7.4] access-enable

[12.7.5] access-template

[12.7.6] clear access-template

[12.7.7] show ip accounting


14/428

[12.7.8] Terminal Access Security Commands

[12.7.9] enable password

[12.8.0] enable secret

[12.8.1] ip identd

[12.8.2] login authentication

[12.8.3] privilege level (global)

[12.8.4] privilege level (line)

[12.8.5] service password-encryption

[12.8.6] show privilege

[12.8.7] username

[12.8.8] A Word on Ascend Routers

[13.0.0] Known NT/95/IE Holes

[13.0.1] WINS port 84

[13.0.2] WindowsNT and SNMP

[13.0.3] Frontpage98 and Unix

[13.0.4] TCP/IP Flooding with Smurf

[13.0.5] SLMail Security Problem

[13.0.6] IE 4.0 and DHTML

[13.0.7] 2 NT Registry Risks

[13.0.8] Wingate Proxy Server

[13.0.9] O'Reilly Website uploader Hole

[13.1.0] Exchange 5.0 Password Caching


15/428

[13.1.1] Crashing NT using NTFS

[13.1.2] The GetAdmin Exploit

[13.1.3] Squid Proxy Server Hole

[13.1.4] Internet Information Server DoS attack

[13.1.5] Ping Of Death II

[13.1.6] NT Server's DNS DoS Attack

[13.1.7] Index Server Exposes Sensitive Material

[13.1.8] The Out Of Band (OOB) Attack

[13.1.9] SMB Downgrade Attack

[13.2.0] RedButton

[13.2.1] FrontPage WebBot Holes

[13.2.2] IE and NTLM Authentication

[13.2.3] Run Local Commands with IE

[13.2.4] IE can launch remote apps

[13.2.5] Password Grabbing Trojans

[13.2.6] Reverting an ISAPI Script

[13.2.7] Rollback.exe

[13.2.8] Replacing System .dll's

[13.2.9] Renaming Executables

[13.3.0] Viewing ASP Scripts

[13.3.1] .BAT and .CMD Attacks

[13.3.2] IIS /..\.. Problem

[13.3.3] Truncated Files


16/428

[13.3.4] SNA Holes

[13.3.5] SYN Flooding

[13.3.6] Land Attack

[13.3.7] Teardrop

[13.3.8] Pentium Bug

[14.0.0] VAX/VMS Makes a comeback (expired user exploit)

[14.0.1] Step 1

[14.0.2] Step 2

[14.0.3] Step 3

[14.0.4] Note

[15.0.0] Linux security 101

[15.0.1] Step 1

[15.0.2] Step 2

[15.0.3] Step 3

[15.0.4] Step 4

[15.0.5] Step 5

[15.0.6] Step 6

[16.0.0] Unix Techniques. New and Old.

[16.0.1] ShowMount Technique

[16.0.2] DEFINITIONS


17/428

[16.0.3] COMPARISION TO THE MICROSOFT WINDOWD FILESHARING

[16.0.4] SMBXPL.C

[16.0.5] Basic Unix Commands

[16.0.6] Special Chracters in Unix

[16.0.7] File Permissions Etc..

[16.0.8] STATD EXPLOIT TECHNIQUE

[16.0.9] System Probing

[16.1.0] Port scanning

[16.1.1] rusers and finger command

[16.1.2] Mental Hacking, once you know a username

[17.0.0] Making a DDI from a Motorola Brick phone

[18.0.0] Pager Programmer

[19.0.0] The End

==============Part One==============

===================Needed Background Knowledge===================

This ones for you Kevin...

[0.0.0] Preface

This book was written/compiled by The Rhino9 Team as a document for the modern


18/428

hacker. We chose to call it the Modern Hackers Desk Reference because it mostly dealswith Networking Technologies and Windows NT issues. Which, as everyone knows, is amust knowledge these days. Well, rhino9, as the premiere NT Security source, we havecontinually given to the security community freely. We continue this tradition now withthis extremely useful book. This book covers WindowsNT security issues, Unix, Linux,

Irix, Vax, Router configuration, Frontpage, Wingate and much much more.

[0.0.1] The Rhino9 Team

At the time of release, the rhino9 team is:

NeonSurge ([email protected]) [Security/Technical Research/Senior Member]

Chameleon ([email protected]) [Security/Software Developer/Senior Member]

Vacuum ([email protected]) [Security/Software Research/Senior Member]

Rute ([email protected]) [Security/Software Developer/Code Guru]

Syndicate ([email protected]) [Security/HTML Operations/Senior Member]

The090000 ([email protected]) [Security]

DemonBytez ([email protected]) [Security]

NetJammer ([email protected]) [Security]

[0.0.2] Disclaimer

This text document is released FREE of charge to EVERYONE. The rhino9 team madeNO profits from this text. This text is NOT meant for re-sale, or for trade for any othertype of material or monetary possesions. This text is given freely to the Internetcommunity. The authors of this text do not take responsibility for damages incurredduring the practice of any of the information contained within this text document.


19/428

[0.0.3] Thanks and Greets

Extra special greetings and serious mad ass props to NeonSurge's fiance SisterMoon, andChameleon's woman, Jayde. Special thanks to the people at ntsecurity.net. Special thanksto Simple Nomad for releasing the NT HACK FAQ which was used in the making of thisdocument. Thanks to Cisco Systems for making such superior equipment. Thanks to theguy from Lucent Technologies, whose text file was used during one of the NT Securitysections (if you see this, contact me so I can give you proper credit). Special props go outto Virtual of Cybrids for his information on CellPhones and Pagers. Special props toPhreak-0 for his Unix contributions. Mad props to Hellmaster for the Vax info. Thanksto Rloxley and the rest of X-Treme for helping with the distribution and advertising ofthis document. Thanks to Merlin45 for being the marketing pimp that he is. Greetings toCybrids, Intercore, X-Treme, L0pht, CodeZero (grins), 2600 Magazine (thanks for your

vigilance on the Mitnick case).

[1.0.0] Preface to NetBIOS

Before you begin reading this section, understand that this section was written for thenovice to the concept of NetBIOS, but - it also contains information the veteran mightfind educational. I am prefacing this so that I do not get e-mail like "Why did you startyour NetBIOS section off so basic?" - Simple, its written for people that may be comingfrom an enviroment that does not use NetBIOS, so they would need me to start withbasics, thanks.

[1.0.1] Whats is NetBIOS?

NetBIOS (Network Basic Input/Output System) was originally developed by IBM andSytek as an Application Programming Interface (API) for client software to access LANresources. Since its creation, NetBIOS has become the basis for many other networkingapplications. In its strictest sense, NetBIOS is an interface specification for acessingnetworking services.


20/428

NetBIOS, a layer of software developed to link a network operating system with specifichardware, was originally designed as THE network controller for IBM's Network LAN.NetBIOS has now been extended to allow programs written using the NetBIOS interfaceto operate on the IBM token ring architecture. NetBIOS has since been adopted as an

industry standard and now, it is common to refer to NetBIOS-compatible LANs.

It offers network applications a set of "hooks" to carry out inter-applicationcommunication and data transfer. In a basic sense, NetBIOS allows applications to talk tothe network. Its intention is to isolate application programs from any type of hardwaredependancies. It also spares software developers the task of developing network errorrecovery and low level message addressing or routing. The use of the NetBIOS interfacedoes alot of this work for them.

NetBIOS standardizes the interface between applications and a LANs operatingcapabilities. With this, it can be specified to which levels of the OSI model theapplication can write to, making the application transportable to other networks. In aNetBIOS LAN enviroment, computers are known on the system by a name. Eachcomputer on the network has a permanent name that is programmed in various differentways. These names will be discussed in more detail below.

PC's on a NetBIOS LAN communicate either by establishing a session or by usingNetBIOS datagram or broadcast methods. Sessions allow for a larger message to be sentand handle error detection and correction. The communication is on a one-to-one basis.Datagram and broadcast methods allow one computer to communicate with several othercomputers at the same time, but are limited in message size. There is no error detection orcorrection using these datagram or broadcast methods. However, datagramcommunication allows for communication without having to establish a session.

All communication in these enviroments are presented to NetBIOS in a format calledNetwork Control Blocks (NCB). The allocation of these blocks in memory is dependanton the user program. These NCB's are divided into fields, these are reserved for input andoutput respectively.

NetBIOS is a very common protocol used in todays enviroments. NetBIOS is supportedon Ethernet, TokenRing, and IBM PC Networks. In its original induction, it was defined


21/428

as only an interface between the application and the network adapter. Since then,transport like functions have been added to NetBIOS, making it more functional overtime.

In NetBIOS, connection (TCP) oriented and connectionless (UDP) communication areboth supported. It supports both broadcasts and multicasting and supports three distinctservices: Naming, Session, and Datagram.

[1.0.2] NetBIOS Names

NetBIOS names are used to identify resources on a network. Applications use thesenames to start and end sessions. You can configure a single machine with multipleapplications, each of which has a unique NetBIOS name. Each PC that supports anapplication also has a NetBIOS station name that is user defined or that NetBIOS derivesby internal means.

NetBIOS can consist of up to 16 alphanumeric characters. The combination of charactersmust be unique within the entire source routing network. Before a PC that uses NetBIOScan fully function on a network, that PC must register their NetBIOS name.

When a client becomes active, the client advertises their name. A client is considered tobe registered when it can successfully advertise itself without any other client claiming ithas the same name. The steps of the registration process is as follows:

1. Upon boot up, the client broadcasts itself and its NetBIOS information anywhere from6 to 10 to ensure every other client on the network receives the information.

2. If another client on the network already has the name, that NetBIOS client issues itsown broadcast to indicate that the name is in use. The client who is trying to register thealready in use name, stop all attempts to register that name.


22/428

3. If no other client on the network objects to the name registration, the client will finishthe registration process.

There are two types of names in a NetBIOS enviroment: Unique and Group. A uniquename must be unique across the network. A group name does not have to be unique andall processes that have a given group name belong to the group. Each NetBIOS nodemaintains a table of all names currently owned by that node.

The NetBIOS naming convention allows for 16 characters in a NetBIOS name.Microsoft, however, limits these names to 15 characters and uses the 16th character as aNetBIOS suffix. A NetBIOS suffix is used by Microsoft Networking software to

indentify the functionality installed or the registered device or service.

[QuickNote: SMB and NBT (NetBIOS over TCP/IP work very closely together and bothuse ports 137, 138, 139. Port 137 is NetBIOS name UDP. Port 138 is NetBIOS datagramUDP. Port 139 is NetBIOS session TCP. For further information on NetBIOS, read thepaper at the rhino9 website listed above]

The following is a table of NetBIOS suffixes currently used by Microsoft WindowsNT.These suffixes are displayed in hexadecimal format.

Name Number Type Usage

==========================================================================

00 U Workstation Service

01 U Messenger Service

01 G Master Browser


06 U RAS Server Service


23/428

1F U NetDDE Service

20 U File Server Service

21 U RAS Client Service

22 U Exchange Interchange

23 U Exchange Store

24 U Exchange Directory

30 U Modem Sharing Server Service

31 U Modem Sharing Client Service

43 U SMS Client Remote Control

44 U SMS Admin Remote Control Tool

45 U SMS Client Remote Chat

46 U SMS Client Remote Transfer

4C U DEC Pathworks TCPIP Service

52 U DEC Pathworks TCPIP Service

87 U Exchange MTA

6A U Exchange IMC

BE U Network Monitor Agent

BF U Network Monitor Apps


00 G Domain Name

1B U Domain Master Browser

1C G Domain Controllers

1D U Master Browser


24/428

1E G Browser Service Elections

1C G Internet Information Server

00 U Internet Information Server

[2B] U Lotus Notes Server

IRISMULTICAST [2F] G Lotus Notes

IRISNAMESERVER [33] G Lotus Notes

Forte_$ND800ZA [20] U DCA Irmalan Gateway Service

Unique (U): The name may have only one IP address assigned to it. On a network device,multiple occurences of a single name may appear to be registered, but the suffix will beunique, making the entire name unique.

Group (G): A normal group; the single name may exist with many IP addresses.

Multihomed (M): The name is unique, but due to multiple network interfaces on the samecomputer, this configuration is necessary to permit the registration. Maximum number ofaddresses is 25.

Internet Group (I): This is a special configuration of the group name used to manageWinNT domain names.

Domain Name (D): New in NT 4.0

For a quick and dirty look at a servers registered NetBIOS names and services, issue thefollowing NBTSTAT command:


25/428

nbtstat -A [ipaddress]

nbtstat -a [host]

[1.0.3] NetBIOS Sessions

The NetBIOS session service provides a connection-oriented, reliable, full-duplexmessage service to a user process. NetBIOS requires one process to be the client and theother to be the server. NetBIOS session establishment requires a preordained cooperationbetween the two stations. One application must have issued a Listen command whenanother application issues a Call command. The Listen command references a name in its

NetBIOS name table (or WINS server), and also the remote name an application must useto qualify as a session partner. If the receiver (listener) is not already listening, the Callwill be unsuccessful. If the call is successful, each application receives notification ofsession establishment with the session-id. The Send and Receive commands the transferdata. At the end of a session, either application can issue a Hang-Up command. There isno real flow control for the session service because it is assumed a LAN is fast enough tocarry the required traffic.

[1.0.4] NetBIOS Datagrams

Datagrams can be sent to a specific name, sent to all members of a group, or broadcast tothe entire LAN. As with other datagram services, the NetBIOS datagrams areconnectionless and unreliable. The Send_Datagram command requires the caller tospecify the name of the destination. If the destination is a group name, then everymember of the group receives the datagram. The caller of the Receive_Datagramcommand must specify the local name for which it wants to receive datagrams. TheReceive_Datagram command also returns the name of the sender, in addition to the actualdatagram data. If NetBIOS receives a datagram, but there are no Receive_Datagramcommands pending, then the datagram is discarded.

The Send_Broadcast_Datagram command sends the message to every NetBIOS systemon the local network. When a broadcast datagram is received by a NetBIOS node, everyprocess that has issued a Receive_Broadcast_Datagram command receives the datagram.If none of these commands are outstanding when the broadcast datagram is received, the


26/428

datagram is discarded.

NetBIOS enables an application to establish a session with another device and lets the

network redirector and transaction protocols pass a request to and from another machine.NetBIOS does not actually manipulate the data. The NetBIOS specification defines aninterface to the network protocol used to reach those services, not the protocol itself.Historically, has been paired with a network protocol called NetBEUI (network extendeduser interface). The association of the interface and the protocol has sometimes causedconfusion, but the two are different.

Network protocols always provide at least one method for locating and connecting to aparticular service on a network. This is usually accomplished by converting a node or

service name to a network address (name resolution). NetBIOS service names must beresolved to an IP address before connections can be established with TCP/IP. MostNetBIOS implementations for TCP/IP accomplish name address resolution by usingeither broadcast or LMHOSTS files. In a Microsoft enviroment, you would probably alsouse a NetBIOS Namer Server known as WINS.

[1.0.5] NetBEUI Explained

NetBEUI is an enhanced version of the NetBIOS protocol used by network operatingsystems. It formalizes the transport frame that was never standardized in NetBIOS andadds additional functions. The transport layer driver frequently used by Microsofts LANManager. NetBEUI implements the OSI LLC2 protocol. NetBEUI is the original PCnetworking protocol and interface designed by IBM for the LanManger Server. Thisprotocol was later adopted by Microsoft for their networking products. It specifies theway that higher level software sends and receives messages over the NetBIOS frameprotocol. This protocol runs over the standard 802.2 data-link protocol layer.

[1.0.6] NetBIOS Scopes

A NetBIOS Scope ID provides an extended naming service for the NetBIOS over TCP/IP(Known as NBT) module. The primary purpose of a NetBIOS scope ID is to isolateNetBIOS traffic on a single network to only those nodes with the same NetBIOS scope


27/428

ID. The NetBIOS scope ID is a character string that is appended to the NetBIOS name.The NetBIOS scope ID on two hosts must match, or the two hosts will not be able tocommunicate. The NetBIOS Scope ID also allows computers to use the same computernamee as they have different scope IDs. The Scope ID becomes a part of the NetBIOSname, making the name unique.

[1.2.0] Preface to SMB's

The reason I decided to write this section was because recently the rhino9 team has beengiving speeches and lectures. The two questions we most frequently come across is"What is NetBIOS?" and "What are SMBs?". Well I hope I have already answered theNetBIOS question with the section above. This particular section is being written to

better help people understand SMB's.

[1.2.1] What are SMB's?

Server Message Blocks are a type of "messaging protocol" that LAN Manager (and NT)clients and servers use to communicate with each other. SMB's are a higher level protocolthat can be transported over NetBEUI, NetBIOS over IPX, and NetBIOS over TCP/IP (orNBT).

SMBs are used by Windows 3.X, Win95, WintNT and OS/2. When it comes to securityand the compromise of security on an NT network, the one thing to remember aboutSMBs is that it allows for remote access to shared directories, the registry, and othersystem services, making it a deadly protocol in the eyes of security conscience people.

The SMB protocol was originally developed by IBM, and then jointly developed byMicrosoft and IBM. Network requests that are sent using SMB's are encoded as NetworkControl Blocks (NCB) data structures. The NCB data structures are encoded in SMBformat for transmission across the network. SMB is used in many Microsoft and IBMnetworking software:


28/428

* MS-Net

* IBM PC Network

* IBM LAN Server

* MS LAN Manager

* LAN Manager for Unix

* DEC Pathworks

* MS Windows for Workgroups

* Ungermann-Bass Net/1

* NT Networks through support for LAN Manager

SMB Messages can be categorized into four types:

Session Control: Used to establish or discontinue Redirector connections with a remotenetwork resource such as a directory or printer. (The redirector is explained below)

File: Used to access and manipulate file system resources on the remote computer.

Printer: Used by the Redirector to send print data to a remote printer or queue, and toobtain the status of remote print devices.

Message: Used by applications and system components to send unicast or broadcastmessages.

[1.2.2] The Redirector


29/428

The Redirector is the component that enables a client computer to gain access toresources on another computer as if the remote resources were local to the clientcomputer. The Redirector communicates with other computers using the protocol stack.

The Redirectors primary function is to format remote requests so that they can beunderstood by a remote station (such as a file server) and send them on their way throughthe network.

The Redirector uses the Server Message Block (SMB) structure as the standard vehiclefor sending these requests. The SMB is also the vehicle by which stations returnresponses to Redirector requests.

Each SMB contains a header consisting of the command code (which specifies the taskthat the redirector wants the remote station to perform) and several environment andparameter fields (which specify how the command should be carried out).

In addition to the header, the last field in the SMB may contain up to 64K of data to besent to the remote station.

[2.0.0] What is TCP/IP?

TCP/IP is a set of protocols developed to allow cooperating computers to share resourcesacross a network. It was developed by a community of researchers centered around theARPAnet (Advanced Research Projects Agency). Certainly the ARPAnet is the best-known TCP/IP network. However as of June, 87, at least 130 different vendors hadproducts that support TCP/IP, and thousands of networks of all kinds use it.

First some basic definitions. The most accurate name for the set of protocols we aredescribing is the "Internet protocol suite". TCP and IP are two of the protocols in thissuite. (They will be described below.) Because TCP and IP are the best known of theprotocols, it has become common to use the term TCP/IP to refer to the whole family.


30/428

The Internet is a collection of networks, including the Arpanet, NSFnet, regionalnetworks such as NYsernet, local networks at a number of University and research

institutions, and a number of military networks and a growing number of privatecorporation owned networks. The term "Internet" applies to this entire set of networks.The subset of them that is managed by the Department of Defense is referred to as the"DDN" (Defense Data Network). This includes some research-oriented networks, such asthe Arpanet, as well as more strictly military ones. All of these networks are connected toeach other. Users can send messages from any of them to any other, except where thereare security or other policy restrictions on access.

Officially speaking, the Internet protocol documents are simply standards adopted by the

Internet community for its own use. More recently, the Department of Defense issued aMILSPEC definition of

TCP/IP. This was intended to be a more formal definition, appropriate for use inpurchasing specifications. However most of the TCP/IP community continues to use theInternet standards. The MILSPEC version is intended to be consistent with it.

Whatever it is called, TCP/IP is a family of protocols. A few provide "low-level"functions needed for many applications. These include IP, TCP, and UDP. (These will bedescribed in a bit more detail later.)

Others are protocols for doing specific tasks, e.g. transferring files between computers,sending mail, or finding out who is logged in on another computer. Initially TCP/IP wasused mostly between

minicomputers or mainframes. These machines had their own disks, and generally wereself-contained. Thus the most important "traditional" TCP/IP services are:

[2.0.1] File Transfer

The file transfer protocol (FTP) allows a user on any computer

to get files from another computer, or to send files to another

computer. Security is handled by requiring the user to specify a user


31/428

name and password for the other computer, or logging into a system that

allows for Anonymous logins. Provisions are made for

handling file transfer between machines with different character set,

end of line conventions, etc. This is not quite the same thing as more

recent "network file system" or "NetBIOS" protocols, which will be

described below. Rather, FTP is a utility that you run any time you

want to access a file on another system. You use it to copy the file

to your own system. You then work with the local copy. (See RFC 959

for specifications for FTP.)

[2.0.2] Remote Login

The network terminal protocol (TELNET) allows a user to log in

on any other computer on the network. You start a remote session by

specifying a computer to connect to. From that time until you finish

the session, anything you type is sent to the other computer. Note

that you are really still talking to your own computer. But the telnet

program effectively makes your computer invisible while it is

running. Every character you type is sent directly to the other

system. Generally, the connection to the remote computer behaves much

like a dialup connection. That is, the remote system will ask you to

log in and give a password, in whatever manner it would normally ask a

user who had just dialed it up. When you log off of the other

computer, the telnet program exits, and you will find yourself talking


32/428

to your own computer. Microcomputer implementations of telnet

generally include a terminal emulator for some common type of

terminal. (See RFC's 854 and 855 for specifications for telnet. By the

way, the telnet protocol should not be confused with Telenet, a vendor

of commercial network services.)

[2.0.3] Computer Mail

This allows you to send messages to users on other

computers. Originally, people tended to use only one or two specific

computers. They would maintain "mail files" on those machines. The

computer mail system is simply a way for you to add a message to

another user's mail file. There are some problems with this in an

environment where microcomputers are used. The most serious is that a

micro is not well suited to receive computer mail. When you send mail,

the mail software expects to be able to open a connection to the

addressee's computer, in order to send the mail. If this is a

microcomputer, it may be turned off, or it may be running an

application other than the mail system. For this reason, mail is

normally handled by a larger system, where it is practical to have a

mail server running all the time. Microcomputer mail software then

becomes a user interface that retrieves mail from the mail

server. (See RFC 821 and 822 for specifications for computer mail. See

RFC 937 for a protocol designed for microcomputers to use in reading


33/428

mail from a mail server.)

These services should be present in any implementation of TCP/IP, except that micro-

oriented implementations may not support computer mail. These traditional applicationsstill play a very important role in TCP/IP-based networks. However more recently, theway in which networks are used has been changing. The older model of a number oflarge, self-sufficient computers is beginning to change. Now many installations haveseveral kinds of computers, including microcomputers, workstations, minicomputers, andmainframes. These computers are likely to be configured to perform specialized

tasks. Although people are still likely to work with one specific computer, that computerwill call on other systems on the net for specialized services. This has led to the"server/client" model of network services. A server is a system that provides a specificservice for the rest of the network. A client is another system that uses that service. (Note

that the server and client need not be on different computers. They could be differentprograms running on the same computer.)

Here are the kinds of servers typically present in a modern computer setup. Note thatthese computer services can all be provided within the framework of TCP/IP.

[2.0.4] Network File Systems

This allows a system to access files on another computer in a

somewhat more closely integrated fashion than FTP. A network file

system provides the illusion that disks or other devices from one

system are directly connected to other systems. There is no need to

use a special network utility to access a file on another system. Your

computer simply thinks it has some extra disk drives. These extra

"virtual" drives refer to the other system's disks. This capability is

useful for several different purposes. It lets you put large disks on

a few computers, but still give others access to the disk space. Aside


34/428

from the obvious economic benefits, this allows people working on

several computers to share common files. It makes system maintenance

and backup easier, because you don't have to worry about updating and

backing up copies on lots of different machines. A number of vendors

now offer high-performance diskless computers. These computers have no

disk drives at all. They are entirely dependent upon disks attached to

common "file servers". (See RFC's 1001 and 1002 for a description of

PC-oriented NetBIOS over TCP. In the workstation and minicomputer

area, Sun's Network File System is more likely to be used. Protocol

specifications for it are available from Sun Microsystems.)

[2.0.5] Remote Printing

This allows you to access printers on other computers as if

they were directly attached to yours. (The most commonly used protocol

is the remote lineprinter protocol from Berkeley Unix. Unfortunately,

there is no protocol document for this. However the C code is easily

obtained from Berkeley, so implementations are common.)

[2.0.6] Remote Execution

This allows you to request that a particular program be run on

a different computer. This is useful when you can do most of your work

on a small computer, but a few tasks require the resources of a larger

system. There are a number of different kinds of remote execution.


35/428

Some operate on a command by command basis. That is, you request that

a specific command or set of commands should run on some specific

computer. (More sophisticated versions will choose a system that

happens to be free.) However there are also "remote procedure call"

systems that allow a program to call a subroutine that will run on

another computer. (There are many protocols of this sort. Berkeley

Unix contains two servers to execute commands remotely: rsh and

rexec. The man pages describe the protocols that they use. The

user-contributed software with Berkeley 4.3 contains a "distributed

shell" that will distribute tasks among a set of systems, depending

upon load. Remote procedure call mechanisms have been a topic for

research for a number of years, so many organizations have

implementations of such facilities. The most widespread

commercially-supported remote procedure call protocols seem to be

Xerox's Courier and Sun's RPC. Protocol documents are available from

Xerox and Sun. There is a public implementation of Courier over TCP as

part of the user-contributed software with Berkeley 4.3. An

implementation of RPC was posted to Usenet by Sun, and also appears as

part of the user-contributed software with Berkeley 4.3.)

[2.0.7] Name Servers

In large installations, there are a number of different

collections of names that have to be managed. This includes users and


36/428

their passwords, names and network addresses for computers, and

accounts. It becomes very tedious to keep this data up to date on all

of the computers. Thus the databases are kept on a small number of

systems. Other systems access the data over the network. (RFC 822 and

823 describe the name server protocol used to keep track of host names

and Internet addresses on the Internet. This is now a required part of

any TCP/IP implementation. IEN 116 describes an older name server

protocol that is used by a few terminal servers and other products to

look up host names. Sun's Yellow Pages system is designed as a general

mechanism to handle user names, file sharing groups, and other

databases commonly used by Unix systems. It is widely available

commercially. Its protocol definition is available from Sun.)

[2.0.8] Terminal Servers

Many installations no longer connect terminals directly to

computers. Instead they connect them to terminal servers. A terminal

server is simply a small computer that only knows how to run telnet

(or some other protocol to do remote login). If your terminal is

connected to one of these, you simply type the name of a computer, and

you are connected to it. Generally it is possible to have active

connections to more than one computer at the same time. The terminal

server will have provisions to switch between connections rapidly, and

to notify you when output is waiting for another connection. (Terminal


37/428

servers use the telnet protocol, already mentioned. However any real

terminal server will also have to support name service and a number of

other protocols.)

[2.0.9] Network-Oriented Window Systems

Until recently, high- performance graphics programs had to

execute on a computer that had a bit-mapped graphics screen directly

attached to it. Network window systems allow a program to use a

display on a different computer. Full-scale network window systems

provide an interface that lets you distribute jobs to the systems that

are best suited to handle them, but still give you a single

graphically-based user interface. (The most widely-implemented window

system is X. A protocol description is available from MIT's Project

Athena. A reference implementation is publicly available from MIT. A

number of vendors are also supporting NeWS, a window system defined by

Sun. Both of these systems are designed to use TCP/IP.)

Note that some of the protocols described above were designed by Berkeley, Sun, orother organizations. Thus they are not officially part of the Internet protocol suite.However they are implemented

using TCP/IP, just as normal TCP/IP application protocols are. Since the protocoldefinitions are not considered proprietary, and since commercially-supportimplementations are widely available, it is

reasonable to think of these protocols as being effectively part of the Internet suite.


38/428

Also note that the list above is simply a sample of the sort of services available throughTCP/IP. However it does contain the majority of the "major" applications. The othercommonly-used protocols tend to be

specialized facilities for getting information of various kinds, such as who is logged in,

the time of day, etc. However if you need a facility that is not listed here, we encourageyou to look through the current edition of Internet Protocols (currently RFC 1011), whichlists all of the available protocols, and also to look at some of the major TCP/IPimplementations to see what various vendors have added.

[2.1.0] General description of the TCP/IP protocols

TCP/IP is a layered set of protocols. In order to understand what this means, it is useful tolook at an example. A typical situation is sending mail. First, there is a protocol for mail.This defines a set of commands which one machine sends to another, e.g. commands tospecify who the sender of the message is, who it is being sent to, and then the text of themessage. However this protocol assumes that there is a way to communicate reliablybetween the two computers. Mail, like other application protocols, simply defines a set ofcommands and messages to be sent. It is designed to be used together with TCP and IP.

TCP is responsible for making sure that the commands get through to the other end. Itkeeps track of what is sent, and retransmits anything that did not get through. If anymessage is too large for one

datagram, e.g. the text of the mail, TCP will split it up into several datagrams, and makesure that they all arrive correctly. Since these functions are needed for many applications,they are put together into

a separate protocol, rather than being part of the specifications for sending mail. You canthink of TCP as forming a library of routines that applications can use when they needreliable network

communications with another computer.

Similarly, TCP calls on the services of IP. Although the services that TCP supplies areneeded by many applications, there are still some kinds of applications that don't needthem. However there are some


39/428

services that every application needs. So these services are put together into IP. As withTCP, you can think of IP as a library of routines that TCP calls on, but which is alsoavailable to applications that don't use TCP. This strategy of building several levels ofprotocol is called "layering". We think of the applications programs such as mail, TCP,and IP, as being separate "layers", each of which calls on the services of the layer below

it. Generally, TCP/IP applications use 4 layers: an application protocol such as mail, aprotocol such as TCP that provides services need by many applications IP, whichprovides the basic service of getting datagrams to their destination the protocols neededto manage a specific physical medium, such as Ethernet or a point to point line.

TCP/IP is based on the "catenet model". (This is described in more detail in IEN 48.)This model assumes that there are a large number of independent networks connectedtogether by gateways. The user should be able to access computers or other resources onany of these networks. Datagrams will often pass through a dozen different networks

before getting to their final destination.

The routing needed to accomplish this should be completely invisible to the user. As faras the user is concerned, all he needs to know in order to access another system is an"Internet address". This is an

address that looks like 128.6.4.194. It is actually a 32-bit number. However it is normallywritten as 4 decimal numbers, each representing 8 bits of the address. (The term "octet" isused by Internet documentation for such 8-bit chunks. The term "byte" is not used,because TCP/IP is supported by some computers that have byte sizes other than 8 bits.)Generally the structure of the address gives

you some information about how to get to the system. For example, 128.6 is a networknumber assigned by a central authority to Rutgers University. Rutgers uses the next octetto indicate which of the

campus Ethernets is involved. 128.6.4 happens to be an Ethernet used by the ComputerScience Department. The last octet allows for up to 254 systems on each Ethernet. (It is254 because 0 and 255 are not allowed, for reasons that will be discussed later.) Note that128.6.4.194 and 128.6.5.194 would be different systems. The structure of an Internetaddress is described in a bit more detail later.

Of course we normally refer to systems by name, rather than by Internet address. Whenwe specify a name, the network software looks it up in a database, and comes up with thecorresponding Internet


40/428

address.

Most of the network software deals strictly in terms of the address. (RFC 882 describes

the name server technology used to handle this lookup.) TCP/IP is built on"connectionless" technology. Information is transferred as a sequence of "datagrams". Adatagram is a collection of data that is sent as a single

message. Each of these datagrams is sent through the network individually. There areprovisions to open connections (i.e. to start a conversation that will continue for sometime). However at some level, information from those connections is broken up intodatagrams, and those datagrams are treated by the network as completely separate.

For example, suppose you want to transfer a 15000 octet file. Most networks can't handlea 15000 octet datagram. So the protocols will break this up into something like 30 500-octet datagrams. Each of these datagrams will be sent to the other end. At that point, theywill be put back together into the 15000-octet

file. However while those datagrams are in transit, the network doesn't know that there isany connection between them. It is perfectly possible that datagram 14 will actuallyarrive before datagram 13. It is also possible that somewhere in the network, an error willoccur, and some datagram won't get through at all. In that case, that datagram has to besent again.

Note by the way that the terms "datagram" and "packet" often seem to be nearlyinterchangable. Technically, datagram is the right word to use when describing TCP/IP.A datagram is a unit of data, which is what the protocols deal with. A packet is a physicalthing, appearing on an Ethernet or some wire. In most cases a packet simply contains adatagram, so there is very little difference. However they can differ. When TCP/IP isused on top of X.25, the X.25 interface breaks the datagrams up into 128-byte packets.This is invisible to IP, because the packets are put back together into a single datagram at

the other end before being processed by TCP/IP. So in this case, one IP datagram wouldbe carried by several packets. However with most media, there are efficiency advantagesto sending one datagram per

packet, and so the distinction tends to vanish.

[2.1.1] The TCP Level


41/428

Two separate protocols are involved in handling TCP/IP datagrams. TCP (the"transmission control protocol") is responsible for breaking up the message into

datagrams, reassembling them at the other end, resending anything that gets lost, andputting things back in the right order. IP (the "internet protocol") is responsible forrouting individual datagrams. It may seem like TCP is doing all the work. And

in small networks that is true. However in the Internet, simply getting a datagram to itsdestination can be a complex job. A connection may require the datagram to go throughseveral networks at Rutgers, a serial line to the John von Neuman Supercomputer Center,a couple of Ethernets there, a series of 56Kbaud phone lines to another NSFnet site, andmore Ethernets on another campus. Keeping track of

the routes to all of the destinations and handling incompatibilities among different

transport media turns out to be a complex job.

Note that the interface between TCP and IP is fairly simple. TCP simply hands IP adatagram with a destination. IP doesn't know how this datagram relates to any datagrambefore it or after it. It may

have occurred to you that something is missing here. We have talked about Internetaddresses, but not about how you keep track of multiple connections to a given system.Clearly it isn't enough to get a

datagram to the right destination. TCP has to know which connection this datagram ispart of.

This task is referred to as "demultiplexing." In fact, there are several levels ofdemultiplexing going on in TCP/IP. The information needed to do this demultiplexing iscontained in a series of "headers". A header is simply a few extra octets tacked onto thebeginning of a datagram by some protocol in order to keep track of it. It's a lot likeputting a letter into an envelope and putting an address on the outside of the envelope.Except with modern networks it happens several times. It's like you put the letter into alittle

envelope, your secretary puts that into a somewhat bigger envelope, the campus mailcenter puts that envelope into a still bigger one, etc.


42/428

Here is an overview of the headers that get stuck on a message that passes through atypical TCP/IP network:

We start with a single data stream, say a file you are trying to send to some othercomputer:

TCP breaks it up into manageable chunks. (In order to do this, TCP has to know howlarge a datagram your network can handle. Actually, the TCP's at each end say how big adatagram they can handle, and then they pick the smallest size.)

TCP puts a header at the front of each datagram. This header actually contains at least 20octets, but the most important ones are a source and destination "port number" and a"sequence number". The port

numbers are used to keep track of different conversations. Suppose 3 different people aretransferring files. Your TCP might allocate port numbers 1000, 1001, and 1002 to thesetransfers. When you are sending a datagram, this becomes the "source" port number,since you are the source of the datagram. Of course the TCP at the other end has assigneda port number of its own for the conversation. Your TCP has to know the port numberused by the other end as well. (It finds out when the connection starts, as we will explainbelow.) It puts this in the "destination" port field. Of course if the other end sends a

datagram back to you, the source and destination port numbers will be reversed, sincethen it will be the source and you will be the destination.

Each datagram has a sequence number. This is used so that the other end can make surethat it gets the datagrams in the right order, and that it hasn't missed any. (See the TCPspecification for

details.) TCP doesn't number the datagrams, but the octets. So if there are 500 octets ofdata in each datagram, the first datagram might be numbered 0, the second 500, the next1000, the next 1500,

etc.

Finally, I will mention the Checksum. This is a number that is computed by adding up all


43/428

the octets in the datagram (more or less - see the TCP spec). The result is put in theheader. TCP at the other end computes the checksum again. If they disagree, thensomething bad happened to the datagram in transmission, and it is thrown away.

The window is used to control how much data can be in transit at any one time. It is notpractical to wait for each datagram to be acknowledged before sending the next one. Thatwould slow things down

too much. On the other hand, you can't just keep sending, or a fast computer mightoverrun the capacity of a slow one to absorb data. Thus each end indicates how muchnew data it is currently prepared to

absorb by putting the number of octets in its "Window" field. As the computer receivesdata, the amount of space left in its window decreases. When it goes to zero, the sender

has to stop. As the receiver processes the data, it increases its window, indicating that it isready to accept more data. Often the same datagram can be used to acknowledge receiptof a set of data and to give permission for

additional new data (by an updated window).

The "Urgent" field allows one end to tell the other to skip ahead in its processing to aparticular octet. This is often useful for handling asynchronous events, for example whenyou type a control character or other command that interrupts output. The other fields arebeyond the scope of this document.

[2.1.2] The IP level

TCP sends each of these datagrams to IP. Of course it has to tell IP the Internet address ofthe computer at the other end. Note that this is all IP is concerned about. It doesn't careabout what is in the

datagram, or even in the TCP header. IP's job is simply to find a route for the datagramand get it to the other end. In order to allow gateways or other intermediate systems toforward the datagram, it

adds its own header.


44/428

The main things in this header are the source and destination Internet address (32-bitaddresses, like 128.6.4.194), the protocol number, and another checksum. The sourceInternet address is simply the address of your machine. (This is necessary so the otherend knows where the datagram came from.) The destination Internet address is the

address of the other machine. (This is necessary so any gateways in the middle knowwhere you want the datagram to go.) The protocol number tells IP at the other end to sendthe datagram to TCP. Although most IP traffic uses TCP, there are other protocols thatcan use IP, so you have to tell IP which protocol to send the datagram to.

Finally, the checksum allows IP at the other end to verify that the header wasn't damagedin transit. Note that TCP and IP have separate checksums. IP needs to be able to verifythat the header didn't get

damaged in transit, or it could send a message to the wrong place. For reasons not worthdiscussing here, it is both more efficient and safer to have TCP compute a separatechecksum for the TCP header and data.

Again, the header contains some additional fields that have not been discussed. Most ofthem are beyond the scope of this document. The flags and fragment offset are used tokeep track of the pieces when a

datagram has to be split up. This can happen when datagrams are forwarded through anetwork for which they are too big. (This will be discussed a bit more below.) The timeto live is a number that is

decremented whenever the datagram passes through a system. When it goes to zero, thedatagram is discarded. This is done in case a loop develops in the system somehow. Ofcourse this should be impossible, but well-designed networks are built to cope with"impossible" conditions.

At this point, it's possible that no more headers are needed. If your computer happens tohave a direct phone line connecting it to the destination computer, or to a gateway, it maysimply send the

datagrams out on the line (though likely a synchronous protocol such as HDLC would beused, and it would add at least a few octets at the beginning and end).


45/428

[2.1.3] The Ethernet level

Most of our networks these days use Ethernet. So now we have to describe Ethernet's

headers. Unfortunately, Ethernet has its own addresses. The people who designedEthernet wanted to make sure that no two machines would end up with the same Ethernetaddress. Furthermore, they didn't want the user to have to worry about assigningaddresses. So each Ethernet controller comes with an address

builtin from the factory. In order to make sure that they would never have to reuseaddresses, the Ethernet designers allocated 48 bits for the Ethernet address. People whomake Ethernet equipment have to

register with a central authority, to make sure that the numbers they assign don't overlapany other manufacturer.

Ethernet is a "broadcast medium". That is, it is in effect like an old party line telephone.When you send a packet out on the Ethernet, every machine on the network sees thepacket. So something is needed

to make sure that the right machine gets it. As you might guess, this involves the Ethernetheader. Every Ethernet packet has a 14-octet header that includes the source anddestination Ethernet address, and

a type code. Each machine is supposed to pay attention only to packets with its ownEthernet address in the destination field. (It's perfectly possible to cheat, which is onereason that Ethernet communications are not terribly secure.)

Note that there is no connection between the Ethernet address and the Internet address.Each machine has to have a table of what Ethernet address corresponds to what Internetaddress. (We will describe how

this table is constructed a bit later.) In addition to the addresses, the header contains atype code. The type code is to allow for several different protocol families to be used onthe same network. So you can

use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of them will put a differentvalue in the type field. Finally, there is a checksum. The Ethernet controller computes achecksum of the entire

packet. When the other end receives the packet, it recomputes the checksum, and throws


46/428

the packet away if the answer disagrees with the original. The checksum is put on the endof the packet, not in the

header.

When these packets are received by the other end, of course all the headers are removed.The Ethernet interface removes the Ethernet header and the checksum. It looks at the typecode. Since the type

code is the one assigned to IP, the Ethernet device driver passes the datagram up to IP. IPremoves the IP header. It looks at the IP protocol field. Since the protocol type is TCP, itpasses the datagram

up to TCP. TCP now looks at the sequence number. It uses the sequence numbers and

other information to combine all the datagrams into the original file. The ends our initialsummary of TCP/IP. There are

still some crucial concepts we haven't gotten to, so we'll now go back and add details inseveral areas. (For detailed descriptions of the items discussed here see, RFC 793 forTCP, RFC 791 for IP, and RFC's

894 and 826 for sending IP over Ethernet.)

[2.1.4] Well-Known Sockets And The Applications Layer

So far, we have described how a stream of data is broken up into datagrams, sent toanother computer, and put back together. However something more is needed in order toaccomplish anything useful. There

has to be a way for you to open a connection to a specified computer, log into it, tell itwhat file you want, and control the transmission of the file. (If you have a differentapplication in mind, e.g. computer mail, some analogous protocol is needed.) This is doneby "application protocols".

The application protocols run "on top" of TCP/IP. That is, when they want to send amessage, they give the message to TCP. TCP makes sure it gets delivered to the otherend. Because TCP and IP take care of all the networking details, the applicationsprotocols can treat a network connection as if it were a simple byte stream, like a terminal


47/428

or phone line. Before going into more details about applications

programs, we have to describe how you find an application.

Suppose you want to send a file to a computer whose Internet address is 128.6.4.7. Tostart the process, you need more than just the Internet address. You have to connect to theFTP server at the other

end. In general, network programs are specialized for a specific set of tasks. Mostsystems have separate programs to handle file transfers, remote terminal logins, mail, etc.When you connect to

128.6.4.7, you have to specify that you want to talk to the FTP server. This is done byhaving "well-known sockets" for each server. Recall that TCP uses port numbers to keep

track of individual conversations. User programs normally use more or less random portnumbers. However specific port numbers are assigned to the programs that sit waiting forrequests.

For example, if you want to send a file, you will start a program called "ftp". It will opena connection using some random number, say 1234, for the port number on its end.However it will specify port

number 21 for the other end. This is the official port number for the FTP server. Note thatthere are two different programs involved. You run ftp on your side. This is a programdesigned to accept commands

from your terminal and pass them on to the other end. The program that you talk to on theother machine is the FTP server. It is designed to accept commands from the networkconnection, rather than an

interactive terminal. There is no need for your program to use a well-known socketnumber for itself. Nobody is trying to find it. However the servers have to have well-known numbers, so that people can open connections to them and start sending themcommands. The official port numbers for each program are given in "AssignedNumbers".

Note that a connection is actually described by a set of 4 numbers: the Internet address ateach end, and the TCP port number at each end. Every datagram has all four of thosenumbers in it. (The Internet


48/428

addresses are in the IP header, and the TCP port numbers are in the TCP header.) In orderto keep things straight, no two connections can have the same set of numbers. However itis enough for any one number

to be different. For example, it is perfectly possible for two different users on a machine

to be sending files to the same other machine. This could result in connections with thefollowing parameters:

Internet addresses TCP ports

connection 1 128.6.4.194, 128.6.4.7 1234, 21

connection 2 128.6.4.194, 128.6.4.7 1235, 21

Since the same machines are involved, the Internet addresses are the same. Since they areboth doing file transfers, one end of the connection involves the well-known port numberfor FTP. The only thing

that differs is the port number for the program that the users are running. That's enough ofa difference. Generally, at least one end of the connection asks the network software toassign it a port number

that is guaranteed to be unique. Normally, it's the user's end, since the server has to use awell-known number.

Now that we know how to open connections, let's get back to the applications programs.As mentioned earlier, once TCP has opened a connection, we have something that mightas well be a simple wire. All

the hard parts are handled by TCP and IP. However we still need some agreement as towhat we send over this connection. In effect this is simply an agreement on what set ofcommands the application will

understand, and the format in which they are to be sent. Generally, what is sent is acombination of commands and data. They use context to differentiate.

For example, the mail protocol works like this: Your mail program opens a connection tothe mail server at the other end. Your program gives it your machine's name, the sender


49/428

of the message, and the

recipients you want it sent to. It then sends a command saying that it is starting themessage. At that point, the other end stops treating what it sees as commands, and startsaccepting the message. Your end then starts sending the text of the message. At the end

of the message, a special mark is sent (a dot in the first column). After that, both endsunderstand that your program is again sending commands. This is the simplest way to dothings, and the one that most applications use.

File transfer is somewhat more complex. The file transfer protocol involves two differentconnections. It starts out just like mail. The user's program sends commands like "log mein as this user", "here is

my password", "send me the file with this name". However once the command to send

data is sent, a second connection is opened for the data itself. It would certainly bepossible to send the data on the

same connection, as mail does. However file transfers often take a long time. Thedesigners of the file transfer protocol wanted to allow the user to continue issuingcommands while the transfer is going

on. For example, the user might make an inquiry, or he might abort the transfer. Thus thedesigners felt it was best to use a separate connection for the data and leave the originalcommand connection for

commands. (It is also possible to open command connections to two different computers,and tell them to send a file from one to the other. In that case, the data couldn't go overthe command

connection.)

Remote terminal connections use another mechanism still. For remote logins, there is justone connection. It normally sends data. When it is necessary to send a command (e.g. toset the terminal type or to change some mode), a special character is used to indicate thatthe next character is a command. If the user happens to type that special character as data,two of them are sent.

We are not going to describe the application protocols in detail in this document. It'sbetter to read the RFC's yourself. However there are a couple of common conventionsused by applications that will be


50/428

described here. First, the common network representation: TCP/IP is intended to beusable on any computer. Unfortunately, not all computers agree on how data isrepresented. There are differences in

character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, linefeed, or a representation using counts), and in whether terminals expect characters to besent individually or a line

at a time. In order to allow computers of different kinds to communicate, eachapplications protocol defines a standard representation.

Note that TCP and IP do not care about the representation. TCP simply sends octets.However the programs at both ends have to agree on how the octets are to be interpreted.

The RFC for each application specifies the standard representation for that application.Normally it is "net ASCII". This uses ASCII characters, with end of line denoted by acarriage return followed by a line feed. For remote

login, there is also a definition of a "standard terminal", which turns out to be a half-duplex terminal with echoing happening on the local machine. Most applications alsomake provisions for the two

computers to agree on other representations that they may find more convenient. Forexample, PDP-10's have 36-bit words. There is a way that two PDP-10's can agree tosend a 36-bit binary file. Similarly,

two systems that prefer full-duplex terminal conversations can agree on that. Howevereach application has a standard representation, which every machine must support.

Keep in mind that it has become common practice for some corporations to change aservices port number on the server side. If your client software is not configured with thesame port number, connection will not be successful. We will discuss later in this texthow you can perform port scanning on an entire IP address to see which ports are active.

[2.1.5] Other IP Protocols

Protocols other than TCP: UDP and ICMP


51/428

So far, we have described only connections that use TCP. Recall that TCP is responsiblefor breaking up messages into datagrams, and reassembling them properly. However inmany applications, we have

messages that will always fit in a single datagram. An example is name lookup. When a

user attempts to make a connection to another system, he will generally specify thesystem by name, rather than Internet

address. His system has to translate that name to an address before it can do anything.Generally, only a few systems have the database used to translate names to addresses. Sothe user's system will want to send a query to one of the systems that has the database.This query is going to be very short. It will certainly fit in one datagram. So will theanswer. Thus it seems silly to use TCP. Of course TCP does

more than just break things up into datagrams. It also makes sure that the data arrives,resending datagrams where necessary. But for a question that fits in a single datagram,

we don't need all the

complexity of TCP to do this. If we don't get an answer after a few seconds, we can justask again. For applications like this, there are alternatives to TCP.

The most common alternative is UDP ("user datagram protocol"). UDP is designed forapplications where you don't need to put sequences of datagrams together. It fits into thesystem much like TCP. There is a

UDP header. The network software puts the UDP header on the front of your data, just asit would put a TCP header on the front of your data. Then UDP sends the data to IP,which adds the IP header, putting

UDP's protocol number in the protocol field instead of TCP's protocol number. HoweverUDP doesn't do as much as TCP does. It doesn't split data into multiple datagrams. Itdoesn't keep track of what it has

sent so it can resend if necessary. About all that UDP provides is port numbers, so thatseveral programs can use UDP at once. UDP port numbers are used just like TCP portnumbers. There are well-known port

numbers for servers that use UDP. Note that the UDP header is shorter than a TCPheader. It still has source and destination port numbers, and a checksum, but that's aboutit. No sequence number, since it is not needed. UDP is used by the protocols that handlename lookups (see IEN 116, RFC 882, and RFC 883), and a number of similar protocols.


52/428

Another alternative protocol is ICMP ("Internet Control Message Protocol"). ICMP isused for error messages, and other messages intended for the TCP/IP software itself,rather than any particular

user program. For example, if you attempt to connect to a host, your system may get back

an ICMP message saying "host unreachable". ICMP can also be used to find out someinformation about the network. See RFC 792 for details of ICMP. ICMP is similar toUDP, in that it handles messages that fit in one datagram. However it is even simpler thanUDP. It doesn't even have port numbers in its header. Since all ICMP messages areinterpreted by the network software itself, no port numbers are needed to say where aICMP message is supposed to go.

[2.1.6] Domain Name System

Keeping track of names and information: the domain system

As we indicated earlier, the network software generally needs a 32-bit Internet address inorder to open a connection or send a datagram. However users prefer to deal withcomputer names rather than

numbers. Thus there is a database that allows the software to look up a name and find thecorresponding number. When the Internet was small, this was easy. Each system wouldhave a file that listed all of the

other systems, giving both their name and number. There are now too many computersfor this approach to be practical. Thus these files have been replaced by a set of nameservers that keep track of host

names and the corresponding Internet addresses. (In fact these servers are somewhatmore general than that. This is just one kind of information stored in the domain system.)

Note that a set of interlocking servers are used, rather than a single central one. There arenow so many different institutions connected to the Internet that it would be impracticalfor them to notify a central

authority whenever they installed or moved a computer. Thus naming authority isdelegated to individual institutions. The name servers form a tree, corresponding toinstitutional structure. The names

themselves follow a similar structure.


53/428

A typical example is the name BORAX.LCS.MIT.EDU. This is a computer at theLaboratory for Computer Science (LCS) at MIT. In order to find its Internet address, you

might potentially have to consult 4

different servers. First, you would ask a central server (called the root) where the EDUserver is. EDU is a server that keeps track of educational institutions. The root serverwould give you the names and

Internet addresses of several servers for EDU. (There are several servers at each level, toallow for the possibly that one might be down.) You would then ask EDU where theserver for MIT is. Again, it

would give you names and Internet addresses of several servers for MIT. Generally, not

all of those servers would be at MIT, to allow for the possibility of a general powerfailure at MIT. Then you would ask

MIT where the server for LCS is, and finally you would ask one of the LCS servers aboutBORAX. The final result would be the Internet address for BORAX.LCS.MIT.EDU.Each of these levels is referred to as

a "domain". The entire name, BORAX.LCS.MIT.EDU, is called a "domain name". (Soare the names of the higher-level domains, such as LCS.MIT.EDU, MIT.EDU, andEDU.)

Fortunately, you don't really have to go through all of this most of the time. First of all,the root name servers also happen to be the name servers for the top-level domains suchas EDU. Thus a single

query to a root server will get you to MIT. Second, software generally remembersanswers that it got before. So once we look up a name at LCS.MIT.EDU, our softwareremembers where to find servers for

LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation ofBORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live"associated with it. Typically this is a few days. After that,

the information expires and has to be looked up again. This allows institutions to changethings.


54/428

The domain system is not limited to finding out Internet addresses. Each domain name isa node in a database. The node can have records that define a number of differentproperties. Examples are

Internet address, computer type, and a list of services provided by a computer. A program

can ask for a specific piece of information, or all information about a given name. It ispossible for a node in the

database to be marked as an "alias" (or nickname) for another node. It is also possible touse the domain system to store information about users, mailing lists, or other objects.

There is an Internet standard defining the operation of these databases, as well as theprotocols used to make queries of them. Every network utility has to be able to makesuch queries, since this is now the official way to evaluate host names. Generally utilities

will talk to a server on their own system. This server will take care of contacting the otherservers for them. This keeps down the amount of code that has to be in each applicationprogram.

The domain system is particularly important for handling computer mail. There are entrytypes to define what computer handles mail for a given name, to specify where anindividual is to receive mail, and to

define mailing lists. (See RFC's 882, 883, and 973 for specifications of the domainsystem. RFC 974 defines the use of the domain system in sending mail.)

[2.1.7] Routing

The description above indicated that the IP implementation is responsible for gettingdatagrams to the destination indicated by the destination address, but little was said abouthow this would be

done. The task of finding how to get a datagram to its destination is referred to as"routing". In fact many of the details depend upon the particular implementation.However some general things can be said.

First, it is necessary to understand the model on which IP is based. IP assumes that a


55/428

system is attached to some local network. We assume that the system can send datagramsto any other system on its own network. (In the case of Ethernet, it simply finds theEthernet address of the destination system, and puts the datagram out on the Ethernet.)The problem comes when a system is asked to send a datagram to a system on a differentnetwork. This problem is handled by gateways. A gateway is a system that connects a

network with one or more other networks. Gateways are often normal computers thathappen to have more than one network interface. For example, we have a Unix machinethat has two different Ethernet interfaces. Thus it is connected to networks 128.6.4 and128.6.3. This machine can act as a gateway between those two networks. The software onthat machine must be set up so that it will forward datagrams from one network to theother. That is, if a machine on network 128.6.4 sends a datagram to the gateway, and thedatagram is addressed to a machine on network

128.6.3, the gateway will forward the datagram to the destination. Major communicationscenters often have gateways that connect a number of different networks. (In many cases,special-purpose gateway systems provide better performance or reliability than general-

purpose systems acting as gateways. A number of vendors sell such systems.)

Routing in IP is based entirely upon the network number of the destination address. Eachcomputer has a table of network numbers. For each network number, a gateway is listed.This is the gateway to be

used to get to that network. Note that the gateway doesn't have to connect directly to thenetwork. It just has to be the best place to go to get there. For example at Rutgers, ourinterface to NSFnet is at

the John von Neuman Supercomputer Center (JvNC). Our connection to JvNC is via ahigh-speed serial line connected to a gateway whose address is 128.6.3.12. Systems onnet 128.6.3 will list 128.6.3.12 as

the gateway for many off-campus networks. However systems on net 128.6.4 will list128.6.4.1 as the gateway to those same off-campus networks. 128.6.4.1 is the gatewaybetween networks 128.6.4 and

128.6.3, so it is the first step in getting to JvNC.

When a computer wants to send a datagram, it first checks to see if the destinationaddress is on the system's own local network. If so, the datagram can be sent directly.Otherwise, the system expects to

find an entry for the network that the destination address is on. The datagram is sent tothe gateway listed in that entry. This table can get quite big. For example, the Internet


56/428

now includes several hundred

individual networks. Thus various strategies have been developed to reduce the size ofthe routing table. One strategy is to depend upon "default routes". Often, there is only onegateway out of a network. This gateway might connect a local Ethernet to a campus-wide

backbone network. In that case, we don't need to have a separate entry for every networkin the world. We simply define that gateway as a "default". When no specific route isfound for a datagram, the datagram is sent to the default gateway. A default gateway caneven be used when there are several gateways on a network. There are provisions forgateways to send a message saying "I'm not the best gateway -- use this one instead."(The message is sent via ICMP. See RFC 792.) Most network software is designed to usethese messages to add entries to their routing tables. Suppose network 128.6.4 has twogateways, 128.6.4.59 and 128.6.4.1. 128.6.4.59 leads to several other internal Rutgersnetworks. 128.6.4.1 leads indirectly to the NSFnet. Suppose we set 128.6.4.59 as adefault gateway, and have no other routing table entries. Now what happens when weneed to send a datagram to MIT? MIT is network 18. Since we have no entry for network

18, the datagram will be sent to the default, 128.6.4.59. As it happens, this gateway is thewrong one. So it will forward the

datagram to 128.6.4.1. But it will also send back an error saying in effect: "to get tonetwork 18, use 128.6.4.1". Our software will then add an entry to the routing table. Anyfuture datagrams to MIT will then go directly to 128.6.4.1. (The error message is sentusing the ICMP protocol. The message type is called "ICMP redirect.")

Most IP experts recommend that individual computers should not try to keep track of theentire network. Instead, they should start with default gateways, and let the gateways tellthem the routes, as just

described. However this doesn't say how the gateways should find out about the ro

Documents

Modern Hackers