A Hacker's Genesis
I remember it as if it happened yesterday, in one brief, exhilarating moment. It was the fall of 1981, the time of year when all picturesque, lively nature is changing to beautiful demise. I was a young boy, and Christmas was right around the corner. I had worked hard around the house the past summer, never complaining about my chores. I was especially well mannered, too, all in the hopes of finally getting the dirt bike I dreamed of. I remember I couldn't sleep Christmas Eve; I kept waking up, heart pounding, to check the clock—in suspense.
Unfortunately, to my dismay, on Christmas morning, when I ran to the front room, I found only a small box for me under the tree, too small to be a motorbike and too big to hold the key, owner's manual, and a note that directed me to a surprise in the garage. But even as I wondered how I had failed to deserve a bike, I was aware there was still an unopened surprise for me under the tree. The box was wrapped so precisely, hinting there may have been something of great value in it. (I have always noticed that people seem to take extra time and care to wrap the expensive presents.) I could see this package had taken some time to wrap; the edges were perfect, and even the tape snippets were precise. I tore this perfect wrapping apart vigorously while noticing the box was moderately heavy, all the time wondering what it could be. After removing a large piece of wrapping paper that covered the top of the box, I stared at it unable to focus for a moment on what it actually was. Then my eyes made contact; there it was—a new computer.
At first I wasn't quite sure what this could mean for me. Then it hit me: I could play cool games on this thing! (I remembered seeing advertisements, which gave so many children hope, that computers weren't just for learning and school, that we could play really wicked games, too. I was always a pretty good student; it didn't take much effort for me to be on the Dean's List. My point is, it didn't take me long to unbox, set up, and configure my new computer system—without consulting the manuals or inspecting those ''Read Me First" booklets. But I did go through them carefully when I thought something was missing: I was a bit disappointed to discover that the system didn't included any games or software, aside from the operating system and a programming language called BASIC. Nevertheless, a half-hour later I was loading BASIC, and programming my name to scroll across the screen in a variety of patterns. I guess that was when it all started.
Only a few weeks passed until I realized I had reached the full potential of my computer. The program I was working on had almost reached memory capacity; it included a data array of questions, choices, and scenarios with character-block graphics and audio beeps. In short, I had staged a world war on Earth between the Evil Leaders and the Tactful Underdogs.
Here's the scenario: The Underdogs had recently sustained an onslaught of attacks that changed 90 percent of their healthy, young, soldiers into desolate casualties. The odds were against the Underdogs from the beginning, as their archaic arsenal couldn't compare to the technological warfare used by the Evil Leaders. From the start, they didn't have much confidence; only hope had brought these young boys and girls together as soldiers to fight the aggressors.
Your best friends are dying; your arsenal is empty; and you haven't eaten in days. During all this turmoil, that inner voice—the one you packed deep away inside yourself from childhood—has spoken again, and it is dictating your thoughts. Your view faded back to the time you found that spaceship in the prairie at the end of your block. If it really were an unidentified flying object, as confirmed by sightings throughout the city and reported in the local newspapers... Then, maybe, there is some advanced weaponry onboard; maybe you can figure out how to operate that thing—as long as you can remember, there was a low electromagnetic-type hum emanating from the ship. You were the last soldier of that special group of friends who made the pact of silence years ago, after stumbling upon the ship, while searching for logs to serve as support beams for your prairie fort. At that moment, and what seemed a heavy pause, nausea overwhelmed you as you come to realize that the fate of the Underdogs might be in your hands alone (later you would understand that it would be left to your mind rather than your hands to operate the ship). Regardless, there might be one last hope... one last chance to bomb the "Black House" and win the war for the Underdogs...
I was surprised when they announced my name as one of the winners in the Science Fair that year. So much of my time had been spent working on my
game that I had completely, and deliberately, blown off my original science project—I still can't remember what that was. At the last minute, I phoned my teacher, scheduled time on a school television, and packed up my computer to show as my project for the fair. My goal was twofold: I was hoping to pass off my programming as my project and to secure my entry in the fair (my grade would have been mortally wounded if I had failed, as the Science Fair project was worth one-third of the overall grade). Certainly I never expected to hear my name called as a winner. As it turned out, my booth had generated more attention than all of the other top projects combined. Everyone loved my game and seemed amazed at the complexity of the programming and assumed I must have spent a great deal of time on it (little did they know).
As a reward for my success from my parents, I was allowed to trade in my computer and was given some cash to acquire a more professional computer system. It was exciting to move from cassette data storage to one with a floppy diskette (the icing on the cake was that the system actually supported color!). I spent hours every night working on the new system and getting acquainted with a different operating system, one with so many more commands and much more memory address space to work on my next project, which was called Dragon's Tomb. It proved to be the inspiration for the development of Sorcery.
Over countless evenings and on innumerable tablets of graph paper, then using pixels, lines, circles, custom fill-ins, multiple arrays, numerous variables, and 650 pages of code (more than 46,000 lines of coding) in four separate modules, on four floppy diskettes (later custom-pirate-modified as double-siders), the results were extremely gratifying:
For many years, there has been peace in your neighboring land of the long-forgotten city. The fertile plain of the River Zoth has yielded bountifully; commerce has prospered; and the rulers of the magic Orb of Power have been wise and just. But of late, disturbing reports of death, destruction, and intense torture have reached your village. According to the tales of whimpering merchants and jaded travelers, the forgotten city has been overrun by evil.
In the days long past, the Orb of Power was summoned by a powerful cleric. It is written that the Orb withholds the secrets of the Universe, along with immense power to rule such. But if the Orb should someday fall into the wrong hands.
Days ago, you joined a desert caravan of the strongest warriors and the wisest magic users. Firlor, among the oldest of the clerics, has told you the magic words to unveil the dreadful castle where the Orb is said to be guarded. The heat is making it hard to concentrate—if you could only remember the words when. a sandstorm! The shrieking wind whips over you, driving sand into your eyes and mouth and even under your clothing. Hours pass; your water is rapidly disappearing; and you are afraid to sleep for fear you will be buried beneath the drifts.
When the storm dies down, you are alone. The caravan is nowhere in sight. The desert is unrecognizable, as the dunes have been blown into new patterns. You are lost...
Tired and sore, you struggle over the burning sands toward the long-forgotten city. Will you reach the ruins in time to recover the magic Orb of Power? The sun beats down, making your wounds stiff, and worsening the constant thirst that plagues anyone who travels these waterless wastes. But there is hope—are those the ruins over there?
In the midst of broken columns and bits of rubble stands a huge statue. This has got to be the place! You've found it at last. Gratefully, you sink onto the sand. But there's no time to lose. You must hurry. So with a quavering voice, you say the magic words, or at least what you remember them to be. And then you wait.
A hush falls over the ruins, making the back of your neck prickle. At first nothing happens; then out of the east, a wind rises, gently at first but quickly growing stronger and wilder, until it tears at your clothes and nearly lifts you off your feet. The once-clear sky is choked with white and gray clouds that clash and boil. As the clouds blacken, day turns to night. Lightning flashes, followed by menacing growls of thunder. You are beginning to wonder if you should seek shelter, when all of a sudden there is a blinding crash, and a bolt of lightning reduces the statue to dust!
For a moment, silence; then, out of the statue's remains soars a menacing flame. Its roar deafens you, as higher and higher it climbs until it seems about to reach the clouds. Just when you think it can grow no larger, its shape begins to change. The edges billow out into horrifying crisp, ragged shapes; the roar lessens; and before your eyes materializes a gigantic dark castle.
You stand before the castle pondering the evil that awaits.
Sorcery lies in the realm of dragons and adventure. Your quest begins at the entrance of a huge castle consisting of many levels and over 500 dungeons. As you travel down the eerie hallways into the abyss of evil, you will encounter creatures, vendors, treasure, and traps. sinkholes, warps, and magic staffs.
Sorcery also includes wandering monsters; choose your own character, armor, and weapons, with a variety of spells to cast a different adventure each time you play.
I spent two years developing Sorcery back in the early eighties. My original intent was to make my idea reality then distribute it to family, friends, and other computer-enthusiasts. Although I did copy-protect my development, I never did sell the product. Now as I reflect, this rings a familiar sound: Could someone have stolen my efforts? Anyway, little did I know that the Sorcery prelude manuscript would alter the path of my future.
Again, spending too much time working on personal projects, and very little time concentrating on school assignments, I had run into another brick wall. It was the eleventh hour once more, and I had blown off working on an assignment that was due the next day: I was supposed to give another boring speech in class. This time, however, the topic could be of my own choosing. As you may have deduced, I memorized my Sorcery introduction, but altered the tone to make it sound as if I was promoting the product for sale. With fingers, and probably some toes, crossed, I winged the speech, hoping for a passing mark.
To my surprise, the class listened to the speech with interest and growing concentration. As a result, I was awarded the highest grade in my class. But the unparalleled reward was yet to come.
After classes that day, a fellow student approached me apprehensively. I had previously noticed his demeanor in class and had decided he was a quiet underachiever. With unkempt greasy hair and crumpled shirts, he always sat at the back of the classroom, and often was reprimanded for sleeping. The teachers seemed to regard him as a disappointment and paid him no attention as he passed through the hallways.
As he drew near me, I could see he was wide-eyed and impatient. I remember his questions that day very well. He was persistent and optimistic as he asked whether my program really existed or if I had made up the whole scenario for a better grade. It was obvious to me that he wanted a copy. I told him the truth and asked if he had a computer that was compatible with mine. At that, he laughed, then offered me a software trade for a copy of Sorcery. I would have given him a copy regardless, but thought it would be nice to add to my own growing collection of programs. The software he offered included a graphics file converter and a program to condense file sizes by reducing the headers. I remember thinking how awesome it would be to condense my own programs and convert graphics without first modifying their format and color scheme.
We made the trade after school the following day, and I hurried home to load the software from the disk. The graphics converter executed with error, and disappointed, I almost discarded the floppy without trying the file condenser. Upon loading that program later that night, and to my disbelief, it ran smoothly. What really caught my attention, however, was the pop-up message I received upon exiting the program: It told of an organization of computer devotees who traded software packages and were always looking for qualified members. At the end of the message was a post office box mailing address: "snd intrest 2:"
I jumped at this potential opportunity. I could hardly imagine an organized group whose members were as interested in technology as I was, and who exchanged software, ideas, and knowledge. I composed my letter and mailed it off that very same day.
Only a week passed before I received my first reply and group acceptance request from the leader of the group (a very fond welcome indeed, for those of you who can identify him from this). At that moment, the path my life had begun to take reached a new intersection, one that would open the door to a mind-boggling new genesis
The Hacker's Technology Handbook
The Hacker's Technology Handbook contains a collection of the key concepts vital to forming a hacker's knowledge foundation. Traditionally, learning to hack takes many years of trial and error, technology reference absorption, and study time. This chapter, along with the primers given in Chapters 1 through 3, is designed to be used as a quick reference to that same material, and with review, can reduce that learning curve down to the time it takes to go through this book.
Each section in this chapter corresponds with a step on the path to achieving the basics of a hacker's education and knowledge. The topics covered include networking concepts, networking technologies, protocols, and important commands. Hacker coding fundamentals are covered in the next chapter.
Networking Concepts
Open Systems Interconnection Model
The International Standards Organization (ISO) developed the Open Systems Interconnection (OSI) Model to describe the functions performed during data communications. It is important to recognize the seven layers that make up the OSI model (see Figure 6.1) as separate entities that work together to achieve successful communications. This approach helps divide networking complexity into manageable layers, which in turn allows specialization that permits multiple vendors to develop new products to target a specific area. This approach also helps standardize these concepts so that you can understand all of this theory from one book, as opposed to hundreds of publications.
Layer 7: Application. Providing the user interface, this layer brings networking to the application, performs application synchronization and system processes. Common services
that are defined at this layer include FTP, SMTP, and WWW.
Layer 6: Presentation. Appropriately named, this layer is responsible for presenting data to layer 7. Data encoding, decoding, compression, and encryption are accomplished at this layer, using coding schemes such as GIF, JPEG, ASCII, and MPEG.
Layer 5: Session. Session establishment, used at layer 6, is formed, managed, and terminated by this layer. Basically, this layer defines the data coordination between nodes at the Presentation layer. Novell service access points, discussed in Chapter 2 and NetBEUI are protocols that function at the Session layer.
Layer 4: Transport. TCP and UDP are network protocols that function at this layer. For that reason, this layer is responsible for reliable, connection-oriented communication between nodes, and for providing transparent data transfer from the higher levels, with error recovery.
Layer 3: Network. Routing protocols and logical network addressing operate at this level of the OSI model. Examples of logical addressing include IP and IPX addresses. An example of a routing protocol defined at this layer is the Routing Information Protocol (RIP; discussed later).
Layer 2: Data Link. This layer provides the reliable transmission of data into bits across the physical network through the Physical layer. This layer has the following two sublayers:
MAC: This sublayer is responsible for framing packets with a MAC address, for error detection, and for defining the physical topology, whether bus, star, or ring (defined in Chapter 3).
LLC: This sublayer's main objective is to maintain upper-layer protocol standardization by keeping it independent over differing local area networks (LANs).
Layer 1: Physical. Also appropriately named, the Physical layer is in charge of the electrical and mechanical transmission of bits over a physical communication medium. Examples of physical media include net-
Figure 6.1 The seven layers of the OSI model.
• work interface cards (NICs), shielded or unshielded wiring, and topologies such as Ethernet and Token Ring.
Cable Types and Speeds versus Distances
As part of the lowest-layer design specifications, there are a variety of cable types used in networking today. Currently, categories 3 and 5 (illustrated in Figure 6.2) are among the most common types used in local area networks. Regardless of cable type, however, it is important to note the types and speeds versus distances in design; these are shown in Table 6.1.
Table 6.1 Transmission Speeds and Interface Types versus Distance
Decimal, Binary, and Hex Conversions Decimal
Data entered into applications running on a computer commonly use decimal format. Decimals are numbers we use in everyday life that do not have to have a decimal point in them, for example, 1, 16, 18, 26, and 30—any random number.
Firsi Octet
Figure 6.3 IP address example. Binary
When decimal numbers are entered into the computer, the system converts these into binary format, 0s and 1s, which basically correlate to electrical charges—charged versus uncharged. IP addresses, for example, are subnetted and calculated with binary notation. An example of an IP address with 24 bits in the mask is shown in Figure 6.3.
The first octet (206) indicates a Class C (Internet-assigned) IP address range with the format network.network.network.host, with a standard mask binary indicating 255.255.255.0. This means that we have 8 bits in the last octet for hosts.
The 8 bits that make up the last, or fourth, octet are understood by infrastructure equipment such as routers and software in the following manner:
Bit: 1 2 3 4 5 6 7 8
Value: 128 64 32 16 8 4 2 1 = 255 (254 usable hosts)
In this example of a full Class C, we only have 254 usable IP addresses for hosts; 0 and 255 cannot be used as host addresses since the network number is 0 and the broadcast address is 255.
Note that when a bit is used, we indicate it with a 1:
3 Bits: 1 1 1
Value: 128 64 32 16 8 4 2 1
When a bit is not used, we indicate this with a 0:
3 Bits: 0 0 0 0 0
Value: 128 64 32 16 8 4 2 1
As a result:
3 Bits: 1 1 1 0 0 0 0 0
Value: 128 64 32 16 8 4 2 1
We add the decimal value of the used bits: 128 + 64 + 32 = 224. This means that the binary value 11100000 equates to the decimal value 224.
DECIMAL BINARY
224 11100000
Hex
The hexadecimal system is a form of binary shorthand. Internetworking equipment such as routers use this format while formulating headers to easily indicate Token Ring numbers, bridge numbers, networks, and so on, to reduce header sizes and transmission congestion. Typically, hex is derived from the binary format, which is derived from decimal. Hex was designed so that the 8 bits in the binary 11100000 (Decimal=224) will equate to only two hex characters, each representing 4 bits.
To clarify, take a look at the binary value for 224 again:
1110000
In hex, we break this 8-bit number into 4-bit pairs:
11100000
Each bit in the 4-bit pairs has a decimal value, starting from left to right: 8 then 4 then 2 then 1 for the last bit:
8 4 2 1 8 4 2 1
1 1 1 0 0 0 0 0
Now we add the bits that are ''on," or that have a 1 in each of the 4-bit pairs:
8 4 2 1 = 8 + 4 + 2 + 0 = 14 8 4 2 1 = 0 + 0 + 0 + 0 = 0
1 1 1 0 0 0 0 0
In this example, the decimal values that represent the hex characters in each of the 4-bit pairs are 14 and 0. To convert these to actual hex, use Table 6.2. Using this chart, the hex conversion for the decimals 14 and 0 (14 for the first 4-bit pair and 0 for the second 4-bit pair) = e0.
Let's look at one more example: We'll convert the decimal number 185 to binary:
Bits: 10 1110 0 1
Value: 128 64 32 16 8 4 2 1 = 185
Binary for 185: 10111001 (bits indicated
above)
Using the hex chart, the hex conversion for the decimals 11 and 9 (11 for the first 4-bit pair and 9 for the second 4-bit pair) = b9, as shown here:
Protocol Performance Functions
To control the performance of session services, distinctive protocol functions were developed and utilized to accommodate the following communication mechanics:
• Maximum Transmission Unit (MTU). The MTU is simply the maximum frame byte size that can be transmitted from a network interface card (NIC) across a communication medium. The most common standard MTU sizes include:
Token Ring = 4464
FDDI = 4352
ISDN = 576
SLIP = 1006
PPP = 1500
Handshaking. During a session setup, the handshaking process provides control information exchanges, such as link speed, from end to end.
Windowing. With this function, end-to-end nodes agree upon the number of packets to be sent per transmission, called the window size. For example, with a window size of three, the source station will transmit three segments, and then wait for an acknowledgment from the destination. Upon receiving the acknowledgment, the source station will send three more segments, and so on.
Buffering. Internetworking equipment such as routers use this technique as memory storage for incoming requests. Requests are allowed to come in as long as there is enough buffer space (memory address space) available. When this space runs out (buffers are full), the router will begin to drop packets.
Source Quenching. In partnership with buffering, under source quenching, messages sent to a source node as the receiver's buffers begin to reach capacity. Basically, the receiving router sends time-out messages to the sender alerting it to slow down until buffers are free again.
Error Checking. Error checking is typically performed during connection-oriented sessions, in which each packet is examined for missing bytes. The primary values involved in this process are checksums. With this procedure, a sending station calculates a checksum value and transmits the packet. When the packet is received, the destination station recalculates the value to see if there is a checksum match. If a match is made, the receiving station processes the packet; if, on the other hand, there was an error in transmission, and the checksum recalculation does not match, the sender is prompted for packet retransmission.
Networking Technologies
Media Access Control Addressing and Vendor Codes
As discussed in previous chapters, the media access control (MAC) address is defined in the MAC sublayer of the Data Link layer of the OSI model. The MAC address identifies the physical hardware network interface and is programmed in read-only memory (ROM). Each interface must have a unique address in order to participate on communication mediums, primarily on its local network. MAC addresses play an important role in the IPX protocol as well (see Chapter 2). The address itself is 6 bytes, or 48 bits, in length and is divided in the following manner:
The first 24 bits equals the manufacturer or vendor code.
The last 24 bits equals a unique serial number assigned by the vendor.
The manufacturer or vendor code is an important indicator to any hacker. This code facilitates target station discovery, as it indicates whether the interface may support passive mode for implementing a stealth sniffer, which programmable functions are supported (duplex mode, media type), and so on.
During the discovery phase of an analysis, refer to the codes listed in Appendix G on page 877 when analyzing MAC vendor groups in sniffer captures.
Ethernet
For quick frame resolution reference during sniffer capture analyses, refer to the four Ethernet frame formats and option specifications shown in Figure 6.4. Their fields are described here:
Preamble. Aids in the synchronization between sender and receiver(s). Destination Address. The address of the receiving station. Source Address. The address of the sending station.
Frame Type. Specifies the type of data in the frame, to determine which protocol software module should be used for processing. An Ethernet type quick reference is given in Table 6.4.
Figure 6.4 Ethernet frame formats. Table 6.4 Ethernet Type Reference
ETHERNET ETHERNET
DECIMAL HEX DECIMAL OCTAL DESCRIPTION
Harris Corporation
Taylor Instrument
Rosemount Corporation
IBM SNA Service on
Ether
Varian Associates Integrated Solutions
TRFS
Allen-Bradley
Datability
Retix
AppleTalk AARP
(Kinetics) Kinetics
Apollo Computer
Wellfleet
Communications Symbolics Private Hayes
Microcomputers
VG Laboratory Systems
Bridge
Communications Novell, Inc.
KTI
Reserved
Frame Length. Indicates the data length of the frame.
DSAP (Destination Service Access Point). Defines the destination protocol of the frame.
SSAP (Source Service Access Point). Defines the source protocol of the frame.
DSAP/SSAP AA. Indicates this is a SNAP frame.
CTRL. Control field.
Ethernet Type. Indicates the data length of the frame.
Frame Data. Indicates the data carried in the frame, based on the type latent in the Frame Type field.
Cyclic Redundancy Check (CRC). Helps detect transmission errors. The sending station computes a frame value before transmission. Upon frame retrieval, the receiving station must compute the same value based on a complete, successful transmission.
The chart in Figure 6.5 lists the Ethernet option specifications as they pertain to each topology, data transfer rate, maximum segment length, and media type. This chart can serve
Ethernet
10Base2
IQBaseS
IQBaseT
lOBaseFL
100BaseT
Topology
Bus
But
Bus
Star
Pl-tOPt
Bus
Data Transfer Rale
10 Mt?ps
10 Mbps
10 Mbps-
10 Mbps
IQMpps
1 -
Maximum Segment
Length
500 Meters
165 Meters
500 Meters
100 Meters
2.100 Meiers
100 Meiers
Media Type
Thick Coax
Thin Coax
Thick Coax
Unshielded Twisted Pair
Fiber Optic
Unshielded Twisted Pair
as a quick reference during cable breakout design.
Figure 6.5 Ethernet option specifications for cable design.
End Delimiter
Figure 6.6 The Token Frame format. Token Ring
For quick frame resolution reference during sniffer capture analyses, refer to the two Token Ring frame formats, Token Frame and Data/Command Frame, shown in Figures 6.6 and 6.7, respectively.
A Token Frame consists of Start Delimiter, Access Control Byte, and End Delimiter fields, described
here:
Start Delimiter. Announces the arrival of a token to each station.
Access Control. The prioritization value field:
000 Normal User Priority
001 Normal User Priority
010 Normal User Priority
011 Normal User priority
100 Bridge/Router
101 Reserved IBM
110 Reserved IBM
111 Station Management
End Delimiter. Indicates the end of the token or data/command frame.
The Data/Command Frame format is composed of nine fields, defined in the following list.
Start Delimiter. Announces the arrival of a token to each station.
Access Control. The prioritization value field:
000 Normal User Priority
001 Normal User Priority
Start
AtЈ*SS
Frame
Destination
Source
Frame
End
Frame Status
Delimiter
Cai Ip.-I
Control
Address
Address
Oala
Check
Delimiter
Sequence
Figure 6.7 The Data/Command Frame format.
010 Normal User Priority
011 Normal User priority
100 Bridge/Router
101 Reserved IBM
110 Reserved IBM
111 Station Management
Frame Control. Indicates whether data or control information is carried in the frame.
Destination Address. A 6-byte field of the destination node address.
Source Address. A 6-byte field of the source node address.
Data. Contains transmission data to be processed by receiving station.
Frame Check Sequence (FCS). Similar to a CRC (described in Chapter 3), the source station calculates a value based on the frame contents. The destination station must recalculate the value based on a successful frame transmission. The frame is discarded if the FCS of the source and destination do not match.
End Delimiter. Indicates the end of the Token or Data/Command frame.
Frame Status. A 1-byte field specifying a data frame termination, and address-recognized and frame-copied indicators.
Token Ring and Source Route Bridging
When analyzing Token Ring source route bridging (SRB) frames, it is important to be able to understand the frame contents to uncover significant route discovery information. To get right down to it, in this environment, each source station is responsible for preselecting the best route to a destination (hence the name source route bridging). Let's investigate a real-world scenario and then analyze the critical frame components (see Figure 6.8).
Assuming that Host A is required to preselect the best route to Host B, the steps are as follows:
Host A first sends out a local test frame on its local Ring 0x25 for Host B. Host A assumes that Host B is local, and thus transmits a test frame on the local ring.
Host A sends out an explorer frame to search for Host B. No response from Host B triggers Host A to send out an explorer frame (with the first bit in MAC address or multicast bit set to 1) in search for Host B. Each bridge will forward a copy of the explorer frame. As Host B receives
each explorer, it will respond by adding routes to the frame from the different paths the particular explorer traveled from Host A.
3. Host A has learned the different routes to get to Host B. Host A will receive responses from Host B with two distinct routes:
Ring 0x25 to Bridge 0xA to Ring 0x26 to Bridge 0xB to Ring 0x27 to Host B
Ring 0x25 to Bridge 0xC to Ring 0x28 to Bridge 0xD to Ring 0x27 to Host B
Communication will begin, as Host A knows how to get to Host B, typically choosing the first route that was returned after the explorer was released. In this case, the chosen router would be Route 1: Ring 0x25 to Bridge 0xA to Ring 0x26 to Bridge 0xB to Ring 0x27 to Host B.
Let's examine two significant fields of our new Token Ring frame, shown in Figure 6.9, and defined here:
Route Information Indicator (RII). When this bit is turned on (set to 1), it indicates that the frame is destined for another network, and therefore includes a route in the Route Information
Field (RIF).
Access
Frame
Destination
Route
SourCa
Roula
Control
Control
Address
In formal ion
Address
Information
CRC
Indicator
Field (OIF)
(RII)
Figure 6.9 New Token Ring Frame format.
• Route Information Field (RIF). The information within this field is critical, as it pertains to the route this frame will travel to reach its destination. Let's examine the RIF subfields and then compute them in our previous example in Figure 6.10.
The RIF will contain the following fields: Routing Control and three Route Descriptors.
• Routing Control. This field is broken down into the following five segments (see Figure 6.11):
Type. Indicates one of three types of routes in the frame: 000: Specific Route (as in our example).
110: Single Route Broadcast/Spanning Tree Explorer (for example, as used by NetBIOS); only bridges in local spanning tree will forward this.
100: All Routes Explorer (as used by the National Security Agency [NSA]); an all routes broadcast. Length. Indicates the total RIF size (2 to 18).
Direction. A result of the frame's direction, forward or backward; specifies which direction the RIF should be read (0=left to right, 1=right to left).
MTU. Specifies the MTU in accordance to each receiving node along the path:
516 and lower
1500 (Ethernet standard)
2052
4472 (Token Ring standard)
Pouting Control
Route Descriptor
Rome Descriptor
Roule Descriptor
Figure 6.11 Routing Control segments.
8144
11407 110-17800
111: For all broadcast frames only
• Route Descriptor. This field is broken down into two segments: Ring Number and Bridge Number.
Now we're ready to compute the RIF we should see in the previous scenario. To summarize: Communication will begin, as Host A knows how to get to Host B, with the following chosen route:
Given from Figure 6.12:
• A to (Ring 0x25 to Bridge 0xA) to (Ring 0x26 to Bridge 0xB) to (Ring 0x27) to B.
The three sets of parentheses indicate the information that correlates with the three Route Descriptor fields in our RIF.
• RIF: Host A to (Ring 0x25 to Bridge 0xA) to (Ring 0x26 to Bridge 0xB) to (Ring 0x27) to
Host B.
In this scenario, our RIF calculation will include the following hexadecimal values (see Figure 6.13).
From this analysis, we can conclude that as Host A travels to Host B using the route Host A to (Ring 0x25 to Bridge 0xA) to (Ring 0x26 to Bridge 0xB) to (Ring 0x27) to Host B, the RIF would consist of the following values in hex:
Token Ring and Source Route Translational Bridging
With source route translational bridging (SR/TLB), internetworks can translate between different media by bridging between them. Here, the SR in SR/TLB indicates source route bridging (Token
Ring) and the TLB indicates transparent bridging (Ethernet). When combining these technologies into one bridging protocol, they become source route translational bridging. For example, a frame containing a RIF would trigger the bridge to perform source routing, while no RIF could indicate otherwise.
The real showstopper in a scenario such as this is that Token Ring and Ethernet use different bit orders in 48-bit MAC addressing. Basically, Ethernet reads all bits in each byte from left to right, or canonical order, while Token Ring reads the bits in each byte from right to left, or noncanonical order.
To clarify this simple conversion, we'll break it down into the following four steps:
Given the target Station B Ethernet MAC address (0000.25b8cbc4), Station A is transmitting a frame to Station B (see Figure 14).What would the stealth sniffer capture as the destination MAC address on Ring 0x25?
Подпись: own ddoo ctuao aaoa oaio 0101 idij iodo iidu ion niiu oino
The bit order translation for this scenario is very simple. Let's take a look at Station B's MAC address as it appears on its own Ethernet segment, and convert it to binary (see Figure 6.15).
Next, we'll reverse the order of each of the six 8-bit bytes to the noncanonical order (see Figure 6.16).
Finally, we convert the newly ordered bytes back into hex format (see Figure 6.17).
Presto! Given the target Station B Ethernet MAC address (0000.25b8cbc4), where Station A is transmitting a frame to Station B, the stealth sniffer capture (on the Token Ring side) would have the destination MAC address (for Station B) of 0000.a41d.d323.
To recapitulate:
Station B's MAC on the Ethernet segment (in hex): 0000.25b8cbc4
Station B's MAC on the Ethernet segment (binary conversion from hex in step1):
Подпись: Figure 6.16 Step 3, reversing the bit order.
3. Station B's MAC on the Token Ring side (noncanonical order from binary in step 2):
00000000.00000000.10100100.00011101.11010011.00100011
4. Station B's MAC on the Token Ring side (hex conversion from new binary in step 3):
0000.a41d.d323
Fiber Distributed Data Interface
The Fiber Distributed Data Interface (FDDI) uses dual, counter rotating rings with stations that are attached to both rings. Two ports on a station, A and B, indicate where the primary ring comes in and the secondary ring goes out, and then where the secondary ring comes in, and the primary goes out, respectively. Stations gain access to the communication medium in a predetermined manner. In a process almost identical to the standard Token Ring operation, when a station is ready for transmission, it captures the Token and sends the information in FDDI frames (see Figure 6.18). The FDDI format fields are defined as follows:
Preamble. A sequence that prepares a station for upcoming frames.
Start Delimiter. Announces the arrival of a token to each station.
Frame Control. Indicates whether data or control information is carried in the frame.
Destination Address. A 6-byte field of the destination node address.
Source Address. A 6-byte field of the source node address.
Data. Contains transmission data to be processed by receiving station.
Frame Check Sequence (FCS). Similar to a CRC, the source station calculates a value based on the frame contents. The destination station must recalculate the value based on a successful frame transmission. The frame is discarded if the FCS of the source and destination do not match.
End Delimiter. Indicates the end of the frame.
Frame Status. Specifies whether an error occurred and whether the receiving station copied the frame.
FDDI communications work using symbols that are allocated in 5-bit sequences; they formulate one byte when taken with another symbol. This encoding sequence provides 16 data symbols, 8 control symbols, and 8 violation symbols, as shown in Table 6.5.
Table 6.5 FDDI Encoding Sequence Symbols
SYMBOLS BIT STREAM
Data Symbols
(binary 0000) 11110
(binary 0001) 01001
(binary 0010) 10100
(binary 0011) 10101
(binary 0100) 01010
(binary 0101) 01011
(binary 0110) 01110
(binary 0111) 01111
(binary 1000) 10010
(binary 1001) 10011
A (binary 1010) 10110
B (binary 1011) 10111
C (binary 1100) 11010
D (binary 1101) 11011
E (binary 1110) 11100
F (binary 1111) 11101
Control Symbols
Q 00000 H 00100
I
11111
J
11000
K
10001
T
01101
R
00111
S
11001
Violation Symbols
V or H
00001
V or H
00010
V
00011
V
00101
V
00110
V or H
01000
V
01100
V or H
10000
Routing Protocols
This section is designed to serve as a quick reference to specifications and data to help analyze captures during a sniffer analysis, as well as to help build a target InfoBase during the discovery phase of a security analysis.
Distance Vet lor
link Sldtft
Piitli [Meimmorion jMcliicl
1 lop : juiil
C?s1 patn
RoLiliivj Updates
Enlire table at irilerwals
Partial when necessary
Neiiilidoi Ftoulei MenlilicJlion
None
Included
Melric Al<|rn itlmi
Dellman-Ford
Dijkatra
Figure 6.19 Comparing Distance Vector Link State protocol specifications. Distance Vector versus Link State Routing Protocols
The primary differences between Distance Vector and Link State routing protocols are compared in Figure 6.19.
In a nutshell, Distance Vector routing protocols send their entire routing tables at scheduled intervals, typically in seconds. Path determination is based on hop counts or distance (a hop takes place each time a packet reaches the next router in succession). There is no mechanism for identifying neighbors and convergence is high.
With Link State routing protocols, only partial routing table updates are transmitted, and only when necessary, for example, when a link goes down or comes up. The metric is based on a much more complex algorithm (Dijkstra), whereby the best or shortest path is determined and then selected. An example of this type of path determination is a scenario that features a low-bandwidth dial-up connection (only one hop away), as opposed to higher-bandwidth leased lines that, by design, are two or three hops away from the destination. With Distance Vector routing protocols, the dial-up connection may seem superior, as it is only one hop away; however, because the Link State routing protocol chooses the higher-bandwidth leased lines, it avoids potential congestion, and transmits data much faster.
Figure 6.20 lists the five most common routing protocols and their specifications. Administrative Distance
The Administrative Distance is basically a priority mechanism for choosing between different routes to a destination. The shortest administrative distance has priority:
ROUTE ADMINISTRATIVE DISTANCE
Attached 0 Interface
Static Route 1
EIGRP Summary
EBGP
EIGRP Internal IGRP
OSPF
IS-IS
RIP
EGP
5
20
90
100 110 115 120
140
EIGRP External
IBGP 200 Loop Prevention Methods
One of the primary goals of routing protocols is to attain a quick convergence, whereby each partic ipating router maintains the same routing table states and where no loops can occur. The following list explains the most popular loop prevention mechanisms:
Split Horizon. Updates are not sent back out the interface in which they were received.
Poison Reverse. Updates are sent back out the interface received, but are advertised as unreachable.
Count to Infinity. Specifies a maximum hop count, whereby a packet can only traverse through so many interfaces.
Holddown Timers. When a link status has changed (i.e., goes down), this sets a waiting period before a router will advertise the potential faulty route.
Triggered Updates. When link topology changes (i.e., goes up), updates can be triggered to be advertised immediately.
Routing Information Protocol
The Routing Information Protocol (RIP) propagates route updates by major network numbers as a classful routing protocol. In version 2, RIP introduces routing advertisements to be aggregated outside the network class boundary. The RIP Packet format is shown in Figure 6.21; version 2 is shown in Figure 6.22. The format fields are defined as follows:
Command. Specifies whether the packet is a request or a response to a request.
Version Number. Identifies the current RIP version.
Address Family Identifier (AFI). Indicates the protocol address being used:
1
IP (IPv4)
2
IP6 (IPv6)
3
NSAP
4
HDLC (8-bit multidrop)
5
BBN 1822
6
802 (includes all 802 media)
7
E.163
8
E.164 (SMDS, Frame Relay,
ATM)
9
F.69 (Telex)
10
X.121 (X.25, Frame Relay)
11
IPX
Command
Version
Nol
API
Route
Entry
Subnet
Next
Metric
Number
Used
Tag
Address
Mask
Hop
Figure 6.22 RIP version 2 format.
Appletalk
Decnet IV
Banyan Vines
Route Tag. Specifies whether the route is internal or external.
Entry Address. IP address for the entry.
Subnet Mask. Subnet mask for the entry.
Next Hop. IP address of next hop router.
Metric. Lists the number of hops to destination.
Interior Gateway Routing Protocol
Cisco developed the Interior Gateway Protocol (IGRP) for routing within an autonomous system, acting as a distance-vector interior gateway protocol. Merging both distance-vector and link-state technologies into one protocol, Cisco later developed the Enhanced Interior Gateway Protocol (EIGRP). The IGRP Packet format is shown in Figure 6.23; the Enhanced version (EIGRP) is shown in Figure 6.24. The format fields are defined as follows:
Version Number. Specifies the current protocol version.
Operation Code (OC) Command. Specifies whether the packet is a request or an update.
Version
OC
Not
AS
AS Nets
Checksum
Number
Command
Used
Figure 6.25 RTMP format.
Autonomous System (AS). Lists the AS number.
AS Subnets. Indicates the subnetworks outside of the current autonomous system. AS Nets. Indicates the number and networks outside of the current autonomous system. Checksum. Gives the standard UDP algorithm.
Appletalk Routing Table Maintenance Protocol
187
Acting as a transport layer protocol, Appletalk's Routing Table Maintenance Protocol (RTMP) was developed as a distance-vector protocol for informing local routers of network reachability. The RTMP Packet format is shown in Figure 6.25; the format fields are defined as follows:
RN. Indicates router's network.
IDL. Specifies the node ID length.
NID. Gives the Node ID.
Start Range 1. Indicates the network 1 range start.
D. Indicates distance.
End Range 1. Specifies network 1 range end.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment