Tài liệu Network Intrusion Detection pdf

•
Table of Contents

Network Intrusion Detection, Third Edition
By Stephen Northcutt, Judy Novak

Publisher : New Riders Publishing
Pub Date : August 28, 2002
ISBN : 0-73571-265-4
Pages : 512


The Chief Information Warfare Officer for the entire United States teaches you how to

protect your corporate network. This book is a training aid and reference for intrusion
detection analysts. While the authors refer to research and theory, they focus their
attention on providing practical information. The authors are literally the most
recognized names in this specialized field, with unparalleled experience in defending
our country's government and military computer networks. New to this edition is
coverage of packet dissection, IP datagram fields, forensics, and snort filters.




Table of Contents


Copyright

About the Authors

About the Technical Reviewers

Acknowledgments

Tell Us What You Think

Introduction

Part I: TCP/IP


Chapter 1. IP Concepts

The TCP/IP Internet Model


Packaging (Beyond Paper or Plastic)


Addresses


Service Ports


IP Protocols


Domain Name System


Routing: How You Get There from Here


Summary



Chapter 2. Introduction to TCPdump and TCP


TCPdump

Introduction to TCP


TCP Gone Awry


Summary



Chapter 3. Fragmentation


Theory of Fragmentation


Malicious Fragmentation


Summary



Chapter 4. ICMP


ICMP Theory

Mapping Techniques


Normal ICMP Activity


Malicious ICMP Activity


To Block or Not to Block


Summary



Chapter 5. Stimulus and Response


The Expected


Protocol Benders


Abnormal Stimuli


Summary

Chapter 6. DNS


Back to Basics: DNS Theory


Using DNS for Reconnaissance


Tainting DNS Responses


Summary



Part II: Traffic Analysis


Chapter 7. Packet Dissection Using TCPdump


Why Learn to Do Packet Dissection?


Sidestep DNS Queries

Introduction to Packet Dissection Using TCPdump


Where Does the IP Stop and the Embedded Protocol Begin?


Other Length Fields


Increasing the Snaplen


Dissecting the Whole Packet


Freeware Tools for Packet Dissection


Summary



Chapter 8. Examining IP Header Fields


Insertion and Evasion Attacks


IP Header Fields

The More Fragments (MF) Flag


Summary



Chapter 9. Examining Embedded Protocol Header Fields


TCP


UDP


ICMP


Summary



Chapter 10. Real-World Analysis


You've Been Hacked!

Netbus Scan


How Slow Can you Go?


RingZero Worm


Summary



Chapter 11. Mystery Traffic


The Event in a Nutshell


The Traffic


DDoS or Scan


Fingerprinting Participant Hosts


Summary

Part III: Filters/Rules for Network Monitoring


Chapter 12. Writing TCPdump Filters


The Mechanics of Writing TCPdump Filters


Bit Masking


TCPdump IP Filters


TCPdump UDP Filters


TCPdump TCP Filters


Summary



Chapter 13. Introduction to Snort and Snort Rules

An Overview of Running Snort


Snort Rules


Summary



Chapter 14. Snort Rules—Part II


Format of Snort Options


Rule Options


Putting It All Together


Summary



Part IV: Intrusion Infrastructure

Chapter 15. Mitnick Attack


Exploiting TCP


Detecting the Mitnick Attack


Network-Based Intrusion-Detection Systems


Host-Based Intrusion-Detection Systems


Preventing the Mitnick Attack


Summary



Chapter 16. Architectural Issues


Events of Interest


Limits to Observation

Low-Hanging Fruit Paradigm


Human Factors Limit Detects


Severity


Countermeasures


Calculating Severity


Sensor Placement


Outside Firewall


Push/Pull


Analyst Console


Host- or Network-Based Intrusion Detection

Summary



Chapter 17. Organizational Issues


Organizational Security Model


Defining Risk


Risk


Defining the Threat


Risk Management Is Dollar Driven


How Risky Is a Risk?


Summary

Chapter 18. Automated and Manual Response


Automated Response


Honeypot


Manual Response


Summary



Chapter 19. Business Case for Intrusion Detection


Part One: Management Issues


Part Two: Threats and Vulnerabilities


Part Three: Tradeoffs and Recommended Solution


Repeat the Executive Summary

Summary



Chapter 20. Future Directions


Increasing Threat


Defending Against the Threat


Defense in Depth


Emerging Techniques


Summary



Part V: Appendixes


Appendix A. Exploits and Scans to Apply Exploits

False Positives


IMAP Exploits


Scans to Apply Exploits


Single Exploit, Portmap


Summary



Appendix B. Denial of Service


Brute-Force Denial-of-Service Traces


Elegant Kills


nmap


Distributed Denial-of-Service Attacks

Summary



Appendix C. Detection of Intelligence Gathering


Network and Host Mapping


NetBIOS-Specific Traces


Stealth Attacks


Measuring Response Time


Worms as Information Gatherers


Summary



Copyright
Copyright © 2003 by New Riders Publishing
THIRD EDITION: September 2002

All rights reserved. No part of this book may be reproduced or transmitted
in any form or by any means, electronic or mechanical, including
photocopying, recording, or by any information storage and retrieval
system, without written permission from the publisher, except for the
inclusion of brief quotations in a review.
Library of Congress Catalog Card Number: 2001099565
06 05 04 03 02 7 6 5 4 3 2 1
Interpretation of the printing code: The rightmost double-digit number is
the year of the book's printing; the rightmost single-digit number is the
number of the book's printing. For example, the printing code 02-1 shows
that the first printing of the book occurred in 2002.
Printed in the United States of America
Trademarks
All terms mentioned in this book that are known to be trademarks or
service marks have been appropriately capitalized. New Riders Publishing
cannot attest to the accuracy of this information. Use of a term in this
book should not be regarded as affecting the validity of any trademark or
service mark.
Warning and Disclaimer
This book is designed to provide information about intrusion detection.
Every effort has been made to make this book as complete and as
accurate as possible, but no warranty of fitness is implied.
The information is provided on an as-is basis. The authors and New Riders
Publishing shall have neither liability nor responsibility to any person or
entity with respect to any loss or damages arising from the information
contained in this book or from the use of the discs or programs that may
accompany it.
Credits
Publisher
David Dwyer

Associate Publisher
Stephanie Wall
Production Manager
Gina Kanouse
Managing Editor
Kristy Knoop
Senior Acquisitions Editor
Linda Anne Bump
Senior Marketing Manager
Tammy Detrich
Publicity Manager
Susan Nixon
Project Editor
Suzanne Pettypiece
Copy Editor
Kelli Brooks
Indexer
Larry Sweazy
Manufacturing Coordinator
Jim Conway
Book Designer
Louisa Klucznik
Cover Designer
Brainstorm Design, Inc.
Cover Production
Aren Howell
Proofreader
Beth Trudell
Composition
Gloria Schurick

Dedication
Network Intrusion Detection, Third Edition is dedicated to Dr. Richard
Stevens
Stephen Northcutt: I can still see him in my mind quite clearly at lunch
in the speaker's room at SANS conferences—long blond hair, ponytail, the
slightly fried look of someone who gives his all for his students. I
remember the scores from his comment forms. Richard Stevens was the
best instructor of us all. I know he is gone and yet, every couple days, I
reach for his book TCP/IP Illustrated, Volume 1, usually to glance at the
packet headers inside the front cover. I am so thankful to own that book;
it helps me understand IP and TCP, the network protocols that drive our
world. In three weeks or so, I will teach TCP to some four hundred
students. I am so scared. I cannot fill his shoes, not even close, but the
knowledge must continue to be passed on. I can't stress "must" enough;
there is no magic product that can do intrusion detection for you. In the
end, every analyst needs a basic understanding of how IP works so they
will be able to detect the anomalies. That was the gift Dr. Stevens left
each of us. This book builds upon that foundation!
Judy Novak: Of all the influences in the field of security and traffic
analysis, none has been more profound than that of the late Dr. Richard
Stevens. He was a prolific and accomplished author. The book I'm most
familiar with is my dog-eared, garlic saucestained copy of TCP/IP
Illustrated, Volume 1. It is an absolute masterpiece because he is the
ultimate authority on TCP/IP and Unix, and he had the rare ability to make
the subjects coherent. I know several of the instructors at SANS consider
this work to be the "bible" of TCP/IP. I once had the opportunity to be a
student in a course he taught for SANS, and I think I sat with mouth
agape in reverence of someone with such knowledge. Last summer, he
agreed to edit a course I had written for SANS in elementary TCP/IP
concepts. This was the equivalent of having Shakespeare critically review a

grocery list. I carry his book with me everywhere, and I will not soon
forget him.
About the Authors
Stephen Northcutt is a graduate of Mary Washington College. Before
entering the field of computer security, he worked as a Navy helicopter
search and rescue crewman, white water raft guide, chef, martial arts
instructor, cartographer, and network designer. Stephen is author/co-
author of Incident Handling Step by Step, Intrusion Signatures and
Analysis, Inside Network Perimeter Security, and the previous two editions
of this book. He was the original author of the Shadow intrusion detection
system and leader of the Department of Defense's Shadow Intrusion
Detection team before accepting the position of Chief for Information
Warfare at the Ballistic Missile Defense Organization. Stephen currently
serves as Director of Training and Certification for the SANS Institute.
Judy Novak is currently a senior security analyst working for the
Baltimore-based consulting firm of Jacob and Sundstrom, Inc. She
primarily works at the Johns Hopkins University Applied Physics Laboratory
where she is involved in intrusion detection and traffic monitoring and
Information Operations research. Judy was one of the founding members
of the Army Research Labs Computer Incident Response Team where she
worked for three years. She has contributed to the development of a SANS
course in TCP/IP and written a SANS hands-on course, "Network Traffic
Analysis Using tcpdump," both of which are used in SANS certifications
tracks. Judy is a graduate of the University of Maryland—home of the 2002
NCAA basketball champions. She is an aging, yet still passionate, bicyclist,
and Lance Armstrong is her modern-day hero!
About the Technical Reviewers
These reviewers contributed their considerable hands-on expertise to the
entire development process for Network Intrusion Detection, Third Edition.
As the book was being written, these dedicated professionals reviewed all

the material for technical content, organization, and flow. Their feedback
was critical to ensuring that Network Intrusion Detection, Third Edition fits
our readers' need for the highest-quality technical information.
Karen Kent Frederick is a senior security engineer for the Rapid
Response team at NFR Security. She is completing her master's degree in
computer science, focusing in network security, from the University of
Idaho's Engineering Outreach program. Karen has over 10 years of
experience in technical support, system administration, and security. She
holds several certifications, including the SANS GSEC, GCIA, GCUX, and
GCIH. Karen is one of the authors of Intrusion Signatures and Analysis and
Inside Network Perimeter Security: The Definitive Guide to Firewalls,
VPNs, Routers, and Intrusion Detection Systems. Karen also frequently
writes articles on intrusion detection for SecurityFocus.com.
David Heinbuch joined the Johns Hopkins University Applied Physics
Laboratory in 1998. He has experience in intrusion detection, modeling
and simulation, vulnerability assessment, and software development. As a
member of the Information Operations group, he works on programs in
various areas, including secure computing systems, attack modeling and
analysis, and intrusion detection. Mr. Heinbuch has a bachelor of science in
computer engineering from Virginia Tech and an master's of science in
computer science from the Whiting School of Engineering, Johns Hopkins
University.
Acknowledgments
Stephen Northcutt: The network detects and analytical insights that fill
the pages of this book are contributions from many analysts all over the
world. You and I owe them a debt of thanks; they have given us a great
gift in making what was once mysterious, a known pattern.
I thank everyone who has served on, or contributed to, the Incidents.org
team. You have found many new patterns, helped minimize the damage
from a number of compromised systems, and even managed to teach a bit

of intrusion detection along the way. Good work!
Incident handlers would be of little purpose if people weren't reporting
attacks. The folks who contribute data to dshield.org are making a real
difference. You showed that it was possible to share attack information
and analysis and that bit by bit we would get smarter, better able to
understand exploits and probes.
Judy Novak, thank you for working with me on this project. Your efforts
and knowledge are the reason for the book's success. I truly appreciate
the work our technical editors, Karen Kent Frederick and David Heinbuch,
have done to catch the errors that can creep in while you are working late
into the night, or from an airplane. Suzanne Pettypiece, thank you for your
patience and organization in the busiest months of my entire life. A big
thanks to Linda Bump for working with us to keep the project on schedule!
I want to take this opportunity to express my appreciation to Alan and
Marsha Paller for friendship, support, encouragement, and guidance.
Kathy and Hunter, thank you again for the love and support in a writing
cycle. Kathy, I especially thank you for being willing to quit your job to
help me keep all the plates spinning. I love you.
"But if any of you lacks wisdom, let him ask of God, who gives to all men
generously and without reproach, and it will be given to him." James 1:5
Any wisdom or understanding I have is a gift from the Lord Jesus Christ,
God the All Mighty, and the credit should be given to Him, not to me.
I hope you enjoy the book and it serves you well!
Judy Novak: Many thanks to Stephen Northcutt for his tireless efforts in
educating the world about security and encouraging me to join him in his
efforts. His guidance has literally changed my life and the rewards and
opportunities from his influence have been plentiful. While the words to
express my thanks seem anemic, the gratitude is truly heartfelt.
I'd like to thank the wonderfully wise technical editors David Heinbuch and
Karen Kent Frederick for their patient and astute feedback. They are the

blessed souls who save me from total embarrassment! Also, I'd like to
extend special thanks to Paul Ritchey, who edited the Snort chapters for
technical accuracy. He whipped out the feedback with speed and insight.
Finally, last, but never least, I'd like to thank my family—Bob and
Jesse—for leaving me alone long enough when I needed to work on the
book, but gently nudging me to take a break when atrophy set in. There is
real danger in being left alone too long!
Tell Us What You Think
As the reader of this book, you are the most important critic and
commentator. We value your opinion and want to know what we're doing
right, what we could do better, what areas you'd like to see us publish in,
and any other words of wisdom you're willing to pass our way.
As the Associate Publisher at New Riders, I welcome your comments. You
can fax, email, or write me directly to let me know what you did or didn't
like about this book—as well as what we can do to make our books
stronger.
Please note that I cannot help you with technical problems related to the
topic of this book, and that due to the high volume of mail I receive, I
might not be able to reply to every message.
When you write, please be sure to include this book's title and author as
well as your name and phone or fax number. I will carefully review your
comments and share them with the author and editors who worked on the
book.
Fax: 317-581-4663
Email:

Mail: Stephanie Wall
Associate Publisher
New Riders Publishing
201 West 103rd Street

Indianapolis, IN 46290 USA

Introduction
Our goal in writing Network Intrusion Detection, Third Edition has been to
empower you as an analyst. We believe that if you read this book cover to
cover, and put the material into practice as you go, you will be ready to
enter the world of intrusion analysis. Many people have read our books, or
attended our live class offered by SANS, and the lights have gone on;
then, they are off to the races. We will cover the technical material, the
workings of TCP/IP, and also make every effort to help you understand
how an analyst thinks through dozens of examples.
Network Intrusion Detection, Third Edition is offered in five parts.
Part I
,
"TCP/IP," begins with
Chapter 1
, ranging from an introduction to the
fundamental concepts of the Internet protocol to a discussion of Remote
Procedure Calls (RPCs). We realize that it has become stylish to begin a
book saying a few words about TCP/IP, but the system Judy and I have
developed has not only taught more people IP but a lot more about IP as
well—more than any other system ever developed. We call it "real TCP"
because the material is based on how packets actually perform on the
network, not theory. Even if you are familiar with IP, give the first part of
the book a look. We are confident you will be pleasantly surprised. Perhaps
the most important chapter in
Part I
is
Chapter 5
, "Stimulus and Response."

Whenever you look at a network trace, the first thing you need to
determine is if it is a stimulus or a response. This helps you to properly
analyze the traffic. Please take the time to make sure you master this
material; it will prevent analysis errors as you move forward.
Tip
Whenever you look at a network trace, the first thing
you need to determine is if it is a stimulus or a
response.

The book continues in
Part II
, "Traffic Analysis" with a discussion of traffic
analysis. By this, we mean analyzing the network traffic by consideration
of the header fields of the IP and higher protocol fields. Although ASCII
and hex signatures are a critical part of intrusion detection, they are only
tools in the analyst's tool belt. Also in
Part II
, we begin to show you the
importance of each field, how they are rich treasures to understanding.
Every field has meaning, and fields provide information both about the
sender of the packet and its intended purpose. As this part of the book
comes to a close, we tell you stories from the perspective of an analyst
seeing network patterns for the first time. The goal is to help you prepare
for the day when you will face an unknown pattern.
Although there are times a network pattern is so obvious it almost
screams its message, more often you have to search for events of interest.
Sometimes, you can do this with a well-known signature, but equally
often, you must search for it. Whenever attackers write software for denial
of service, or exploits, the software tends to leave a signature that is the
result of crafting the packet. This is similar to the way that a bullet bears

the marks of the barrel of the gun that fired it, and experts can positively
identify the gun by the bullet. In
Part III
of the book, "Filters/Rules for
Network Monitoring" we build the skills to examine any field in the packet
and the knowledge to determine what is normal and what is anomalous. In
this section, we practice these skills both with TCPdump and also Snort.
In
Part IV
, we consider the larger framework of intrusion detection. We
discuss where you should place sensors, what a console needs to support
for data analysis, and automated and manual response issues to intrusion
detection. In addition, this section helps arm the analyst with information
about how the intrusion detection capability fits in with the business model
of the organization.
Finally, this book provides three appendixes that reference common
signatures of well-known reconnaissance, denial of service, and exploit
scans. We believe you will find this to be no fluff, packed with data from
the first to the last page.
Network Intrusion Detection, Third Edition has not been developed by
professional technical writers. Judy and I have been working as analysts
since 1996 and have faced a number of new patterns. We are thankful for
this opportunity to share our experiences and insights with you and hope
this book will be of service to you in your journey as an intrusion analyst.
Part I: TCP/IP

1 IP Concepts

2 Introduction to TCPdump and TCP

3 Fragmentation

4 ICMP

5 Stimulus and Response

6 DNS



Chapter 1. IP Concepts


As you read this chapter, it will become apparent that you belong in one of two categories: the
beginner category or that of the seasoned veteran. The Internet Protocol (IP) is a large and
potentially intimidating topic that requires a gentle introduction for uninitiated beginners so as
not to overwhelm them with foreign acronyms, details, and concepts. Therefore, the purpose
of this first chapter is to expose newcomers to terms, concepts, and the ever-present
acronyms of IP. The suite of protocols covered here is more commonly known as Transmission
Control Protocol/Internet Protocol (TCP/IP). These protocols are required to communicate
between hosts on the Internet—the worldwide infrastructure of networked hosts. Indeed,
communication protocols other than TCP/IP exist (for instance, AppleTalk for Apple
computers). These protocols are typically found on intranets, where associated hosts talk on a
private network. Most Internet communications require TCP/IP, which is the standard for
global communications between hosts and networks.
Those seasoned veteran readers who dabble in TCP/IP daily might be tempted to skip this
chapter. Even so, you should give it a quick skim. If you ever need to explain a concept about
IP (perhaps to the individual who signs off on your pay raise or bonus, for example), you
might find this chapter's approach useful. Those of you who are getting your feet wet in this
area will certainly benefit from this introduction.

This is an around-the-world introduction to TCP/IP presented in a single chapter. Many of the
topics discussed in this introductory chapter are covered in much greater detail and complexity
in upcoming chapters; those chapters contain the core content, but you need to be able to
peel away the theoretical skin to understand them. Specifically, this chapter covers the
following topics:
●
The TCP/IP Internet model. This section examines the foundations of
communications over the Internet, specifically communications made possible by using a
common model known as the TCP/IP Internet model.
●
Packaging of data on the Internet. This section reviews the encapsulation of data to
be sent through different legs of a journey to its destination.
●
Physical and logical addresses. This section highlights the different ways to identify a
computer or host on the Internet.
●
TCP/IP services and ports. This section explores how hosts communicate with each
other for different purposes and through different applications.
●
Domain Name System. This section focuses on the importance of host names and IP
number translations.
●
Routing. This section explains how data is directed from the sending computer to the
receiving computer.


The TCP/IP Internet Model
Computer users often want to communicate with another computer on the Internet for some
purpose or another (to view a web page on a remote web server, for instance). A response
from a web server can seem almost instantaneous, but a lot of processes and infrastructures

actually support this seemingly trivial act behind the scenes.
Layers
Figure 1.1
shows a logical roadmap of some of the processes involved in host-to-host
communications. You begin the process of downloading a web page in the box labeled "Web
browser." Before your request to see a web page can get to the web server, your computer
must package the request and send it through various processes and layers. Each layer
represents a logical leg in the journey from the sending computer to the receiving computer.
After the sending computer packages the data through the different layers, it is delivered to
the receiving computer over the Internet. The receiving computer unwraps the data layer by
layer. An individual layer gets the data intended for it and passes the remainder of the
message to upper layers.
Figure 1.1. The TCP/IP Internet model.
Although discussed in more detail later in this chapter, it is important now to briefly look at
each layer. The following four layers comprise the TCP/IP Internet model:
•

Application layer. The application layer is the topmost layer (the request for a
web page in the preceding example). Software on the sending and receiving
computers supports the implementation of the application (the web browser and web
server, for instance).
•

Transport layer. Below the application layer lays the transport layer. This layer
encompasses many aspects of how the two hosts will communicate. This transport
layer is often concerned with providing reliability over other inherently unreliable
layers.
Two transport layers protocols will be covered: TCP, which is referred to as a reliable
protocol because mechanisms ensure data delivery, and User Datagram Protocol
(UDP), which makes no promise of reliable delivery. In this example application, TCP is

required because of the unacceptability of data loss.
•

Network layer. Below the transport layer is the network layer, which is
responsible for moving the data from the source computer to the destination computer
(the web server in this case), often one hop or leg of the journey at a time. This hop is
between a computer and a router or a router and a router, but it ultimately takes the
data closer in routing space to its destination.
•

Link layer. The bottom layer is the link layer, which is the component that takes
care of communications from a host to the physical medium on which it resides. In this
case, that component is Ethernet. This layer is concerned with receiving and sending
data from the host over a specific interface to the network.
Data Flow
Look at
Figure 1.1
again. In theory, the data flow activity is this: The request for a web page
"descends" the sender's layers, often referred to as the TCP/IP stack. It gets directed to the
destination computer and "ascends" its TCP/IP stack. The vertical arrows between layers
represent the up and down flow on the same computer. The horizontal arrows between
computers signify that each layer talks to its "peer" layer on the communicating host. The two
computers do not directly interact with each other, per se. When the request descends the
sending computer's TCP/IP stack, it is packaged in such a manner that each layer has a
message for its counterpart layer, and so they appear to be talking directly.
This concept is quite important and crucial to understanding this chapter and the TCP/IP
model, in general. Therefore, it is important to reiterate the poignant points and elaborate on
terminology. The term TCP/IP stack is used to denote the layered structure of processing a
TCP/IP request or response. A process known as encapsulation does the implementation of the
layering. This means that data on the sender's host gets wrapped with identifying information

to assist the receiving host in parsing the received message layer by layer. Each layer on the
sending host adds its own header, and the receiving host reverses the process by examining
the message, stripping it of its header, and directing it to the appropriate layer. This process is
repeated for the higher layers until the data reaches the uppermost layer, which finally
processes the web page request. When the response is sent back, the entire process is
repeated; now the web server host packages the data to be sent, it is delivered and received,
and the web browser host strips the received message to pass to the application layer
supporting the web browser.


Packaging (Beyond Paper or Plastic)
At a very granular level, data exchanged between hosts must be bundled in some kind of
standard format. A host is a generic term that can reference a workstation on your desk, a
router, or a web server to name just a few examples. The important distinction is that these
computers are connected to a network capable of transporting data to and from the computer.
In the generic sense, the packaging of associated data is called a packet. The problem in
terminology arises because this data package is labeled differently at various layers of
communication between the source application and the destination application located on
different hosts. This section discusses some of the key concepts related to data packaging,
including bits, bytes, packets, data encapsulation, and interpretation of the layers.
Bits, Bytes, and Packets
The atom of computing is a bit, a single storage location that has a value of either 0 or 1 (also
known as binary). Although succinct and compact, you cannot actually store or convey a lot of
information with a single bit, so bits are grouped into clumps of eight. A unit of eight bits is a
byte (or octet, if you prefer). Eight times a very small amount of information is still pretty
small, but an octet can contain an American Standard Code for Information Interchange
(ASCII) character, such as the letter a or a comma (,). It can also hold a large integer
number, as high as 255 (2
8
-1).

Bits, Bytes, and Binary
Figure 1.2
shows a byte. Because this discussion is focusing on bits, binary is the
language used— the language of 0s and 1s. Each bit is represented as a power of 2,
the base of binary. Notice that a byte spans powers of 2 from 2
0
through 2
7
. If all
bits have a value of 0, the byte is obviously 0. Now, imagine that all bits are 1s. Add
up all the individual bit values, starting with the smallest value (2
0
= 1, any base
with an exponent of 0 is 1); you will have 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128. The
total value is 255, and that is the maximum value that a given byte can have. This
value is examined later when the discussion turns to IP addresses.

Figure 1.2.

You just saw an example of how binary-to-decimal conversion is done. If you are
given a byte of data, just re-create this byte with the appropriate powers of 2 and
their associated decimal values. Any bit that is set is assigned the accompanying
decimal value of that bit. Then, just total up all the decimal values; voila, the
conversion is done. This is not really rocket science after all.
Multiple bytes, or octets, are grouped together for shipping across a network by packaging
them into packets.
Figure 1.3
shows one of the great truths of networking: An overhead cost
accrues when slinging packets around the network.You have to go through a lot of trouble to
package your content for shipping across a network and then to unwrap it when it gets to the

other side (and even more trouble, of course, to finish the job with a tamper-proof seal). A
field known as the cyclical redundancy check (CRC), or checksum, is used to validate that the
frame (the name given to the packet on the wire) has not been damaged or corrupted in
transit.
Figure 1.3. Portrait of a packet.
Like an envelope addressed for mailing, IP packets need to include the addresses of both the
sending and receiving hosts (see
Figure 1.3
). If you live in a house with a street address, you can
think of that as your hardware address, the address assigned to your house. In networking, at
least with Ethernet networks, this is analogous to a network interface card's (NIC) Media
Access Controller (MAC) address. This hardware address is assigned to the NIC when the card
is constructed. The MAC address is 48 bits long, which means it can hold a very large number
(2
48
-1). The "
Addresses
" section later in this chapter discusses the differences between MAC
addresses and IP addresses.
To create a frame, which is the name the packet acquires when transmitted on physical media,
you construct the packet using various protocol layers and then include the physical
information. Finally, the frame is placed on the networking medium by the NIC. The frame has
a frame header of 14 bytes, with fields such as the source and destination MAC addresses,
frame data that can vary in length, and a trailer of 4 bytes that represents the CRC.
Encapsulation Revisited
Figure 1.4
represents the concept of the layered packaging configuration. Different layers of
protocols theoretically "talk" to like layers of protocols on the source and destination hosts.
The layers are stacked atop one another— hence, the origin of the term "TCP/IP stack." At
each layer of the stack, the packet consists of a header of its own and data, sometimes known

as the payload. All the encapsulation is done for the purpose of sending some kind of content,
but the encapsulation requires different header information at different levels in its journey
from source to destination.
Figure 1.4. One layer's header is another layer's data.
Suppose that you have a message or other content to send. It is first collected by the
application, which could be a program such as telnet or electronic mail; these TCP applications
are discussed in more detail in the section "
IP Protocols
." The TCP packet is known as a TCP
segment and includes the TCP header and TCP data. If this were UDP, the packet would be
known as a datagram, which is confusing because it is redundant with the name at the IP
layer.
At this point, the TCP segment is handed down from the TCP layer of the TCP/IP stack to the
IP layer. The IP layer prepends (that means appends at the front) header information to the
TCP segment and becomes known as an IP datagram. Really, the TCP header and data become
invisibly enmeshed as data for the IP datagram, which has its own header. The IP datagram is
delivered to the link layer of the TCP/IP stack, and it is known as a frame. The link layer
prepends the frame header to the IP datagram to carry it across the physical medium, such as
Ethernet.
The process is repeated in reverse when the frame arrives at the destination host and all
headers are stripped away and passed to the proper upper-layer protocols. Each layer of the
TCP/IP stack with its embedded message converses with the similar layer of the receiving
host.
Interpretation of the Layers
With all the layering going on, the bottom line is that you have a bunch of adjacent 0s and 1s.
How do you know how to interpret them? Suppose that you are looking at the IP header; how
do you know what kind of embedded protocol you will find following it? Surely that must be
known to properly interpret the protocol. The term protocol is meant to denote a set of agreed
upon rules or formats. Each protocol (such as IP, TCP, UDP, and ICMP) has its own layouts and
formats.

Figure 1.5
shows an example of the organization of the IP header. You can see that a certain
number of bits are allocated for each field in the header. A Protocol field identifies the
embedded protocol. Each row that you see in the IP header is 32 bits (0 through 31,
inclusive), which means four (8-bit) bytes. To complicate matters a little, counting starts with
0 when talking about bit and byte locations. The first row represents bytes 0 through 3; the
second row represents bytes 4 through 7; and the third row represents bytes 8 through 11.
Notice that the circled Protocol field is in the third row. The preceding time-to-live (TTL) field is
1 byte long, which makes it the 8th byte; and the Protocol field, which is also 1 byte long,
represents the 9th byte. This means that the 9th byte (actually, it's the 10th byte, but
remember counting starts at 0) is examined to find the embedded protocol. The point is that
most packets at their respective levels are positional; fields can be discovered by going to
known displacements in the packet.
Figure 1.5. Positional layouts.
Now that you have counted your way to the Protocol field, what is it and what does it do? The
value in this field tells you what protocol is found in the embedded data. Suppose that the
value you find in this byte is 17. You might find the protocol value expressed in hexadecimal. A
hexadecimal 11 is the same as a decimal 17. This means that a UDP packet is embedded after
the IP header. A value of 6 means that the embedded packet is TCP, and a value of 1 means
that it is Internet Control Message Protocol (ICMP).
Base 16, Hexadecimal
Okay, so you have learned that binary is base 2 and is made up of 0s and 1s. This is
the numbering system used by computers to represent data. So, why complicate the
matter with another entirely new numbering system, base 16 (or hexadecimal)? The
real dilemma is that it takes a lot of bits to represent any sizable number and,
therefore, binary becomes very unwieldy very soon. Hexadecimal assists in
referencing binary numbers in a more abbreviated notation. You can replace 4
binary bits with 1 hexadecimal character (2
4
= 16).

Consider, for example, the IP header protocol field; it is 8 bits. That can be
converted into 2 hex characters. A decimal 17 in the protocol field, as mentioned
earlier, means that the embedded protocol is UDP. How do you go from a decimal 17
to a hexadecimal 11?
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0

0 0 0 1 0 0 0 1
The binary powers of the 8 bits are shown. To arrive at 17, you need to have the bit
corresponding to 16 (or 2
4
) set to 1, and the bit corresponding to 1 (2
0
) set to
1—that is, 16 + 1 = 17. These have been grouped as two hex digits, two 4-bit
clumps. The 4 bits (or hex character) that are leftmost (also known as high-order or

most significant bits) have a value of 0001. Likewise, the 4 bits that are rightmost
(also known as low-order or least significant bits) have a value of 0001. Each hex
character represents values of 0 through 15. And each of these has a low-order bit
of 1 set (2
0
), and so we arrive at the value of 11 hexadecimal (also known as 0x11,
in which the 0x distinguishes this as hex, not decimal).



Addresses
Most likely, you have heard the term IP address. But, what does it really represent and what
does it really do? And, exactly how do hosts address each other? These are some of the topics
covered in this section.
Physical Addresses, Media Access Controller Addresses
You can scour the headers of IP packets looking for physical layer MAC addresses until you
turn blue, and you will not find them. MAC addresses do not mean anything to IP, which uses
logical addresses; they are not part of the protocol. For all intents and purposes, they may as
well not exist.
By the same token, physical MAC addresses are how the Ethernet card interfaces with the
network. The Ethernet card does not know a single thing about IP, IP headers, or logical IP
addresses. So, you are faced with the signature line of Cool Hand Luke: "What we have here is
a failure to communicate." Clearly, if things are going to work, an operation process is required
that facilitates the correspondence between logical IP and physical MAC addresses.
Do you know the IP address of your desktop computer? If you don't, you are not really one
down at all; it is absolutely normal not to know it. It is normal for several reasons, one being
that in these days most of you don't even own or even get to keep the same IP address. IP
address space is a precious commodity. When you connect to the network, many of you are
loaned an address for that session, or possibly longer by an Internet service provider (ISP) or
network service provider via applications, such as Dynamic Host Configuration Protocol

(DHCP).
Leasing an IP Number: Dynamic Host Configuration Protocol
DHCP is a protocol that permits dynamic assignment of IP numbers. This replaces
the labor-intensive process of IP address management, in which every host is
configured with a static IP number assigned to it. DHCP allows the centralization and
automation of the IP assignment process. Hosts are leased an IP number for a given
amount of time, and this makes the process of managing and administering large
networks more efficient. This is good for the network administrator, but makes the
security administrator's job more complicated (for example, when some IP number
and associated temporary owner have to be chased down for questionable activity).
Exactly how many possible IP numbers are there? The exact number is 2
32
(because the
address is comprised of 32 bits), which is a number higher than 4 billion. But, every single IP
number is not available; reserved ranges decrease the possible numbers. With the explosive
growth of the Internet worldwide, the sad realization has dawned that the IP addresses are
being rapidly depleted. What are some remedies for the address depletion?
First, a particular site can use DHCP and assign IP numbers temporarily for the duration of
their use. This means that not all hosts will be active at any given time and a smaller pool of
possible IP numbers is required. The other remedy is something known as reserved private
addresses. The governing body of the Internet, the Internet Address Numbers Authority
(IANA), has set aside blocks of IP addresses to be used for internal addresses only. For
instance, the 192.168 and 172.16 subnets are to be used for hosts talking within a particular
network. This traffic should not leave the site's gateway. This allows a site with an insufficient
number of IP addresses to use these Class B network addresses for internal purposes and to
save the assigned IP addresses for other purposes.
Okay, go ahead and smirk now; some of you did know your IP address. That is good.
However, do you know your host's MAC address by heart? The answer would most likely be
"no," because almost no one knows his MAC address. There are several reasons for this, but
the primary one is that a 48-bit address with no provisions for human memorization is hard to

lock into the brain.
The Address Resolution Protocol (ARP) enables you to resolve the translation of physical MAC
addresses to logical IP addresses. ARP is not an IP protocol per se; it is the process of sending
an Ethernet frame to all systems on the same network segment. This is known as a broadcast.
If a message is a broadcast message, it is sent to all the machines on part of or the entire