                                 //heresy\\
                                    
 А АБВлллллллллллм   лл олллллл лллллм  олллллл мллллллллллм     мллллВБА А
               пллн олн лл     олп пллн лл     оллп      пллл   лллп
                лл  лл олн     ллм млп олн     оллм       оллн оллн
               олллллн лллллл олллллм  лллллл   плллллм    пллмллп
               лл  лл олн     лл  пллнолн          плллн    олллн
              оВн олн лл     олн  млл лл           мллл    млллп
              ВБ  лл олллллл лл  ллп оллллл АБВлллллпп АБВлллп


                         "Burn them at the stake!"
         
             [Started June 12, 1997 - copyright Kweiheri Tron]                 
                                 
       			       = [403] =
                 

			    
                            ====[TCP/IP]====
                          
                              An Overview.

                                  By:
                             
                             Kweiheri Tron
                                
                                  of
                              
                               [HERESY]
                                
                       "i want to r00l the w0rld"
                                - kt


Disclaimer:     The author of this text file, Kweiheri Tron, is not liable
                for anybody's idiocy in any way.  The reader, upon opening
                this textfile, assumes responsibility for the information
                contained within.  Don't be stupid. 

                Permission is granted to reproduce and distribute this file
                unchanged or unmodified.


1. Introduction

	Its disappointing to see the amount of ignorance that exists
both in local scene, and on the internet, concerning what hacking
is.  Locally (and somewhat on the net), there exists a small group of
'psuedo hackers' who think that running toneloc, and trying to guess
passwords on dialup systems they find is hacking.  Not only is this
dangerous, but it is futile.  

	These people also don't want to keep an open mind regarding tcp/ip
and networking.  They seem to have goals set concerning what direction
they want to take.

	Besides being unmotivated and not willing to learn something
beyond what is shown in movies and television, they are extremely image
conscious.  All that matters is seeming, talking, and 'being' like
a hacker.  You know who you are.

	People cannot be controlled.  That is not what I am trying to do,
even though I encourage learning and help others, I do not waste effort
on people who are ignorant.  What is most annoying, is that, when
told in a modest tone, that they should look into learning real 
knowledge, they backlash.  
		
	  It is to them, that I do not dedicate this file.
			

	     And no, I do not rewrite what is in Phrack.

			- Kweiheri Tron.


2.  What is TCP/IP?

	TCP/IP is a term used to describe the set of protocols that
are used on the internet (and other places as well).  TCP/IP is an
OSI-Layered protocol, which means, its heirarchy is based on the
7 layer OSI reference frame, or model.  OSI, was a standard developed
for multiple layer protocols. It stands for Open Systems Interconnection. 
Some of the protocol sets that are based on the OSI model include ISDN,
and X.25.  

	The OSI model consists of 7 basic layers, and understanding these
layers is the key to understanding the basics of Tcp/ip.  

    		     A K-Rad Ascii OSI Diagram.

		        |Application Layer |
 			|Presentation Layer|
			|Session Layer     |
			|Transport Layer   |
			|Network Layer     |
			|Data Link Layer   |
			|Physical Layer    |

	The first three layers are considered "Upper Level Protocols".
The last four are considered "Lower level protocols".

	These layers are designed to communicate with each other.  The benefit
to knowing the OSI model, is so that you can understand the heirarchy
of the protocols.  Data, in the form of packets, are sent down through the
layers of the protocol stack.  
	
	TCP/IP doesn't exactly follow the OSI model.  Instead, the TCP/IP
model looks somewhat like this:

			|Application Layer |
			|Transport Layer   |
			|Internet Layer    |
			|Network / Physical|

	Right now, this is probably meaningless to you.  To understand
these diagrams, you have to understand what the layers are.  For the sake
of brevity, I am going to leave out the osi-layers not included in the
tcp/ip diagram.

Application Layer 
	
	This is usually the front end, or user program.  It would be your
web browser, or email program, or telnet client.  It not only presents
the user with the data, but packages it up and sends it down to the lower
level protocols.


Transport Layer


	This is a very important layer.  It takes the data received from
the application layer, and prepares it to be sent out into the network.
There are two main (yes, main) types of transport layer protocols.  These
would be TCP and UDP.  TCP, is a more complex, reliable protocol, while
UDP is more primitive and less reliable.  

TCP stands for transmission control protocol, and thats a good name for
it.  By creating a "virtual circuit" with the remote system, it performs 
reliable delivery of data.  More will be explained later.

UDP stands for user datagram protocol, and it is much simpler than
TCP.  It does not ensure the safe delivery of data to a remote host.


Internet Layer

	This is another important layer, as it handles delivery, routing,
and addressing of packets of data.  


3. Network / Physical Layer

	This layer includes error checking software and hardware,
as well as the physical cables and hardware involved in the movement of
data.


4. Communication Between Layers / Headers

	Again, this is somewhat complex, and I will not go into it that
deeply.  As the packet moves down the layers, headers are added to the 
front and / or appended to the end of the packet.  The main headers I will
explain are TCP, UDP, and IP.


The UDP Header 

	This is what makes UDP 'simpler' than TCP.  The UDP header
doesn't contain very much information.  It looks somewhat like this.

	|SRC PORT|DST PRT |
	|LENGTH  |CHECKSUM|

	Thats about it.  SRC PORT is a field where the system sending out 
the datagram can place the port that its being set from.  DST PORT, is
the destination port.  LENGTH is the length of the datagram (including
data). CHECKSUM is an optional field used to ensure that data within the
packet has not ben corrupted.

	After the header is the data segment.. where the actual data
being sent out onto the network is stored.


The TCP Header.

	I will not detail everything about the TCP header, because there
is no need to in a file about the basics of TCP/IP.  The TCP Header 
is larger than the UDP header, and looks like this:

		|SRC PORT     |DST PORT    |	
		|SEQUENCE NUMBER           |
		|ACK NUMBER                |
		|DO|R*|U|RST|S|F|A|P|WINDOW|
		|CHECKSUM     |URGENT PTR  |
		|OPTIONS / PADDING         |


	The source port and destination port refer to the same thing as
those found in UDP headers.  The sequence number is a 32 bit number
that identifies the packets place in the sequenced tcp transfer of data.
The ACK number, or acknowledgement number is used when the ACK flag is set
to 1, and it acknowledges a recieved packet, the number being the sequence
number of the packet recieved, plus 1.  

	The weird looking mess of characters under the acknowledgement
number field is my representation of the Data Offset (DO), Reserved
field (R*), Reset Flag (RST), Syn Flag (S), Fin Flag (F), Ack Flag (A),
Push Flag (P), and Window field.

	The Options / Padding is for uses not important to what
this text is about.. so I will leave it to my curious readers
to find out what those fields are for if they want to.


The TCP Flags

	These are variables that are either on, or off..  set to 1,
or 0.  They are important to TCP connections, as they decide how and
what is done during the connections. 

	SYN Flag:  This is set to 1 when a remote system wants to initiate
		   a tcp connection.  SYN comes from "Synchronize".

	ACK Flag:  When set to 1, activates the Acknowledgement field
		   in the TCP header.

	FIN Flag:  When set to 1, tells a remote system to begin
		   the process of ending the TCP connection.

	RST Flag:  When set to 1, tells the remote system that the
		   TCP connection needs to be reset.

	URG Flag:  Activates the Urgent Pointer field.  It is up
		   to the application layer program to use this.
		   TCP itself doesn't go any faster if this flag 
		   is set as 1.

	PSH Flag:  Informs the remote system that a lot of packets
	 	   are coming it's way.  Called the Push Function.

	
	I'd explain the rest of the TCP header, but its not really useful
to you if you're reading this, and this text is already long and boring
enough.


5. The Internet Layer

	This is where the IP protocol resides.  All packets are sent from
TCP and UDP to IP for routing and delivery.  Ip adds a header of its own
to packets, before delivery.  This header is simpler than TCP, but is
imperative to delivery of the packet.

	|VER|LENGTH|SERV TYPE|PACKET LENGTH|
	|IDENT|DF|MF|FRAG OFFSET           |
	|TTL|TRNSPORT|HEADER CHECKSUM      |
	|SENDING ADDRESS		   |
	|DESTINATION ADDRESS		   |
	|OPTIONS		|PADDING   |

	At this point, there is no need to define what every field means.
I will define the ones that I see are important to those new to TCP/IP.

	VER - Small field containing the version of protocol software.
	LENGTH - Length of the IP Header.
	PACKET LENGTH - The length of the entire packet.
	IDENT - A unique identifier needed to reassemble fragmented
		messages.
	DF - A Flag, if set, then the message cannot be fragmented.
	MF - Tells the remote host that more fragments of the message
	     are coming behind it.  Fragments are reassembled by
	     the Internet Layer of the recieving host.
	FRAG OFFSET - Holds the position of this packet in the
		      series of fragmented packets.
	TTL - Time To Live.  Without it, packets would float around
	      forever.  Once the TTL is up, the next gateway or router
	      to recieve the packet will discard it immediately.

	TRNSPORT - Holds the number of the Transport Layer protocol that
		   handled it on the source system.  

	SENDING ADDRESS - Well, somewhat obvious, isnt it? 
	DESTINATION ADDRESS - See above.

		
6. TCP and UDP Data Transmissions

	UDP is what is known as a connectionless protocol.  It doesnt
establish any sort of connection with the destination host.  It sort of
just..  slaps a header on, and ships it out, hoping that the destination
recieves the packets.  Utilities that use UDP, use it for speed, or
because a particular service is used a lot.

	|~~~~~~|  -->      -->              |~~~~~|    
	|mr udp|    -->  --> datagram flow  |dest |
	|______| -->        -->             |_____|

			
		Typical UDP based Data transfer.

		Nothing is done to ensure correct
		transfer.


	TCP, however, is a much different and more elegant transport layer
protocol.  TCP initiates the data transfer with a whole procedure known as
the 3-way handshake.
	
	The 3-Way-Handshake is used to start a virtual 'connection'
between two hosts.  If you look back at the TCP header, you will see SYN
and ACK flags.  This is where they come in.

	The host that wants to connect to another, via TCP, sends out a
tcp packet with the syn flag set to 1, and an initial sequence number.
When the host recieves this packet, it responds with a Syn ACK, and a
sequence number of its own.  The system then waits for the connecting host
to send a final ACK when it recieves the syn ack, with a sequence number
of the syn ack, plus 1.  This is somewhat complex sounding in text, so
I'll draw another ascii diagram:

  step 1	|~~~~~~| -----------> SYN SEQ 20    |~~~~~~|
  step 2 	|mr tcp| SYN SEQ 400 ACK 21  <----- |remote| 
  step 3	|______| --------------> ACK 401    |______|

	There, the connection has been established, and everything is
ready for the data transfer.  
	The tcp data transfer is a sequenced two way system.  To be
general, the data is sent, and when it is recieved, an ACK is sent to from
the recieving host to the sending host to ACKowledge (hence ACK) the 
proper delivery of the packet.  

	         |~~~~~~|   -----> 2031  |~~~~~~|
	         |mr tcp|	         |remote|
        	 |______| <--- ACK 2032  |______|	

	There is a lot more to a TCP connection as well, like TCB's
(Transmission Control Blocks), sliding windows, buffers, and all the rest.
But for a basic text, there is no need to get into it that deep.

The End of a TCP Connection

	A packet is sent from one of the hosts, with the FIN flag set to 1  
The host that recieves this packet then sends an ACK, and that is it
for the connection.

7.  How all this information will be useful.

	Understanding tcp/ip will take much more than reading this text.
This is nothing more than a push in the right direction.  Most probably,
you won't even grasp a lot of whats here, though I did my best to try and
explain it as simply as possible.  Understanding TCP/IP will elevate you
above the rest of the "hackers" who think they are cool because they crack
passwd files.  You will understand how sniffers work, and how all of the
tcp/ip based attacks are done.  You will know how your 'internet utils'
work, and won't be a clueless sap.

	If you can code in C, I highly recommend learning to code network
applications.  This sort of stuff is what hacking is really all about,
understanding.  

8.  Where to learn more.

	There are a lot of resources on the net.  Personally, I learned
about tcpip independently on the net and with some books.  Besides what
other hackers may have written about tcp/ip, there exist what are called
RFC's (Request For Comments).   These are very useful technical docs that
are freely available via anonymous ftp.  There are always tcp/ip books at
the public library, if you don't want to pay the hefty price for them.  

	And remember, it's ok to ask questions, but don't pester people or
expect them to take you as their student.  Hacking is something you have
to learn independently.  Nobody is going to teach you to hack, so don't
ask.

	There is no other better place you can learn tcp/ip and hacking,
than on your own system.  Run Linux, and play on your own system.  That is
the best way to go.

			- Kweiheri Tron of [403]

				June 12, 1997.

			
			Email: kweiheri@sekurity.org


		Coming soon:  

			   Volume II in TCP/IP
		Attacks directly related to the protocols.

