null_session's TCP/IP for kids
Sept. 1, 2000
This file was written to take the kids who are still stuck in the "1 n33d
s0m3 w4r3z d00d!" mode and bring them up to about the same level as your
average system admin. That is to say that this is a quick hit, usable as an
introduction but NOT intended for someone with experience in these matters
(unless, of course, you want to critique me).
What is TCP/IP?
I'm sure you have often seen refrences to the tcp/ip protocol. Refrences like
that are usually made by marketing people and salesman. TCP/IP actually
stands for Transmission Control Protcol/Internet Protocol, but really it is a
suite of many protocols and services, all of which work together to provide a
fairly simple interface to a shared network of computers. Tcp/ip provides a
layer(actually several) of abstraction from the pain of hardware networking.
The services that tcp/ip provide allow you to type "slashdot.org" to find
distraction in satan's equivilent of talk radio, rather than 00:00:86:51:A1:13
a true hardware level (Ethernet, in this case) network address.
Just in case you had a thought like "well what's wrong with that?" consider
for a moment then that every network interface in the world has one of these.
Every interface on every computer, every interface on every router, every
printer, every IP phone, etcetera, and they are ALL DIFFERENT (theoretically,
at least). Not only from a user perspective is this impossible, it would
also make networking a technical nightmare. Luckily, since the dawn of
networking there have been networking protocols and programming interfaces
galore (tcp/ip is but one of these) that have more or less held the nightmares
at bay.
Features of TCP/IP
TCP/IP has many different charateristics, and many of them change depending
on which protocols you are actually using. Through the different protocols
it may set up a reliable virtual path, or it may just dump packets out at the
network. A couple of things that can be said for sure are that TCP/IP is
routable, meaning that it can be routed through many network interfaces and
across different network types, and that TCP/IP is packet switching, meaning
that the data is broken up into many chunks and each chunck is sent
individually across the network.
TCP/IP is often referred to as a protocol stack. This means that the
different protocols are visualized vertically, passing information up and
down the stack. It can also be visualized that on two interfaces, two
protocols that are at the same level in the stack communicate directly with
each other. This is better shown visually:
foo.somewhere.org bar.elseware.org
Telnet Telnetd
| |
TCP TCP
| |
IP IP
| |
NIC driver NIC driver
| |
Ethernet----------------------Ethernet
Here I've shown a telnet session between foo and bar. In reality this works
as follows: d1ck@foo is having a telnet session with bar's telnetd. d1ck types
on his 'leet windows 98 telnet session "del c:\*.*". This information goes
(character by character, but we don't need to get into that here) down foo's
protocol stack, across the network (Ethernet in this case, but it matters not)
and up bar's ip stack until it is sent to bar's ptty. The real sequence of
events is: telnet(foo)->tcp(foo)->ip(foo)->NIC driver(foo)->Ethernet.--->
NIC driver(bar)->ip(bar)->tcp(bar)->telnetd(bar). Of course it has no
effect because d1ck is a complete idiot, but I digress.
Even though we know how this is really working, it is perfectly acceptable
(and even necessary, if you care to maintian you sanity) to consider foo's
telnet as talking directly to bar's telnetd, or foo's tcp talking directly to
bar's tcp, etc... This is all possible because of the miracle of encapsulation.
So what in the hell is encapsulation? Encapsulation is the method by which
foo's tcp can talk directly to bar's tcp. Every layer uses a header to keep
addressing and other information that is needed by the protocol to deliver
the packet. Each layer, upon recieving the packet from the previous layer,
treats the entire thing like data and adds it's own header. There are two
benefits resulting from this: 1) the "direct communication" that we're
discussing, and 2) these protocols are not dependent on each other. It is
possible to put something besides TCP on top of IP, and it will still work.
The encapsulation scheme is once again best shown by graphics:
+-------+
Telnet | data |
+-------+
+--------+-------+
TCP | header | data |
+--------+-------+
+--------+----------------+
IP | header | data |
+--------+----------------+
+--------+-------------------------+
NIC driver | header | data |
+--------+-------------------------+
As the data moves down the stack towards the NIC driver and to the network,
headers are added. These headers accomplish different things depending the
specific protocols being used. When the data is recieved and subsequently
moves back up the stack the headers are stripped off and discarded, leaving
the exact same data that left the sender.
I'm sure by now you're probably asking yourself two things- "What's a NIC
driver?" and "What are these other protocols?" NIC is easy, it's an acronym
for Network Interface Card. The driver is simply the code that allows IP to
talk to it. It is this arrangement that allows us to use TCP/IP with myriad
network cards. For each card there is a NIC driver, but everything above it
on the stack works with any driver.
It is now time to answer that other question. There are many protocols
associated with TCP/IP, but you only really need to know of a few right now.
I'll chart out the most common protocols according to their position in the
protocol stack:
Telnet/FTP/HTTP DNS/TFTP
| |
TCP UDP
\ /
IP ICMP
\ /
Network access (NIC Driver)
I'm not going to go into the top level (application) protocols, they are far
beyond the scope of this doc. I will, however, give short descriptions of
the others:
TCP: Transmission Control Protocol (RFC0793)
TCP is a connection oriented, reliable protocol. That means that when you
use TCP it verifies EVERY packet it recieves with an acknowledgement. It is
very reliable and guarantees correct delivery of the data (each packet is
checked and discarded if it doesn't match what was sent). As you might guess,
this generates a rather large amount of overhead, slowing the protocol down
considerably. TCP is able to present data to any of several applications
through the use of ports and sockets.
UDP: User Datagram Protocol (RFC0768)
UDP uses ports and sockets like TCP, but UDP is connectionless and
unreliable. Don't misunderstand this, unreliable only means that the data
is NOT checked by the reciever for accuracy and corruption. As a result, UDP
is MUCH faster than TCP.
IP: Internet Protocol (RFC0791)
IP provides addressing and routing (hence the term "IP address"). It also
communicates directly to the drivers for the network interface. IP also
supports fragmentation, the ability to break packets that are too large to
send over the network into smaller chunks (called datagrams) that can then be
re-assembled by the recieving machine (this is important- more on fragging
later).
ICMP: Internet Control Message Protocol (RFC0792)
ICMP is used primarily by routers and other network hardware to communicate
on the state of the network. ICMP allows routers and NICs to tell each other
when they are broken, when they can't handle more data, etc... The only times
you should really encounter ICMP are when you are setting up a firewall,
troubleshooting a broken network, or running ping (a ping is a ICMP echo
request). If I find out you are using ICMP for any other reason (like DoS),
I'll have a group of very large men in suits pull your ears off.
I'm sure you noticed the notes RFC####. These refer to the "Request
For Comments" documents (available at http://www.rfc-editor.org). These
are the absolute authority on how these protocols work. These documents
are god as far as you are concerned. You will often hear people speak of
"RFC compliance" (and especially Microsoft's lack of it), they are speaking
of the need to follow these standards. I reccomend you read all of the RFCs
I mentioned above.
Notes on addressing and routing:
As mentioned above, addressing and routing is all handled by IP. This is
really beyond the scope of this doc as it can be rather complex (or at least
difficult to explain). I may put something together on addressing, routing
and subnetting, it depends if anyone expresses interest. The best resource
is of course the RFC, but I'll say a few words. Addressing is arranged in 4
octets (8 bits each). It is most often written as 133.213.10.230 - 4 decimal
numbers seperated by dots. This is also occasionally called the layer 2
address as IP is the second layer in the IP protocol stack. Routers use this
address, which is actually a network address and a host address slapped
together, to route packets to the appropriate destination (remeber, when you
go surfing for porn, your packets are probably crossing 8 or 10 different
routers along the way). You most often, of course, see addresses written as
ftp.suse.com or mail.knockwurst.net etc... These are handled by the
application (meaning it operates on the same level as telnet or netscape)
called DNS or Domain Name Service. DNS mearly maps text names to the numerical
IP addresses. -before I'm flamed I should mention that DNS is also referred to
as named or BIND.
Notes on fragmentation:
Fragmentation is also handled by IP. Remember, IP can talk to a plethora of
different network types. This is good, but it causes certain problems. For
instance, my nice large ethernet packets might not be able to travel on your
token ring or x.25 network. As a result, IP can fragment what it recieves
into smaller chunks. In this case the fragements are all sent, and once they
arrive they are re-assembled on the recieving machine. It is by using
fragments that people are able to sneek through firewalls. Most firewalls
(although they are getting smarter) do not re-assemble fragmented packets
for inspection. As a result, arbitrarily fragmented packets can be passed
through and re-assembled to do their dirty work on the inside.
Notes on sockets and ports:
TCP is able to determine what application is to recieve data by looking at what
port it comes in on. For instance, in our telnet example, even though d1ck
was listening to a shoutcast server and surfing halfdressedhoochiemamas.com,
his TCP stack knew the incoming data was for telnet because it was sent
to port 23. Even if he was running two telnet sessions, they would be sorted
out by the TCP stack using a combination of the source port (a random number)
and destiation port (port 23 for telnet) - collectively called the socket.
Author's notes:
This was written as a brief introduction. It is by no means an in-depth
analysis, it's not even a good tutorial. My sole intention was to prick your
interest, so you would go out and read the stuff I'm about to tell you to go
read. If you can't be bothered to take the time to learn this, go back to
playing Diablo or EQ and quit trying to become a hacker, as you will never get
there. If you are digging it, however, I suggest the following:
The RFCs mentioned above - these are absolutely necessary.
http://www.rfc-editor.org
Understanding IP Addressing: Everything You Ever Wanted to Know - Chuck Semeria
http://www.3com.com/nsc/501302.html
Security Problems in the TCP/IP Protocol Suite - S.M. Bellovin
http://www.insecure.org/stf/tcpip_smb.txt
Simple Active Attack Against TCP - Laurent Joncheray
http://www.insecure.org/stf/iphijack.txt