This lesson looks at a core concept in the design of networks in general, and the internet inparticular: protocols. The way the internet works is often discussed in terms of "the stack", which organizes the basic protocols of the internet into layers. Additionally, there are some more standard tools (similar to nslookup and traceroute) that we'll learn about.
BR51: "Tower, BR51 request takeoff VFR to the west." Tower: "BR51, Tower, you are cleared for takeoff to the west." BR51: "Tower, BR51, copy, cleared for takeoff."This second transcript shows a different pattern in terms of turn-taking.
BR51: "Dulles Tower, this is Bay Raider 51, 35 miles to the west, final stop Dulles." Tower: "standby" Tower: "BR51, this is Dulles, cleared to Dulles" BR51: "Tower, BR51, copy, cleared to Dulles.
When you pick up that VHF bridge-to-bridge radio on one of the YP's, the ACP 125 protocol tells you how you should talk!
Here's an example dialog between callsigns S7 and CC:
CC: "Sierra Seven this is Charlie Charlie, radio check, over." S7: "This is Sierra Seven, roger, over." CC: "Sierra Seven, Charlie Charlie, immediate execute, turn starboard niner, I say again, turn starboard niner, standby ... execute, over."
Protocols usually revolve around providing a service. They govern the back-and-forth communication between the entity providing the service and the entity using the service. That boils down to specifying what messages can be sent and what those messages mean, e.g. what action results from sending that message. The protcol behind the web, HTTP, governs the interaction between web servers and web clients (browsers). We've seen a bit of this: Browsers can send messages like
GET /prices.html HTTP/1.1to a server (of course you need its IP address to send it this message!). The HTTP protocol specifies exactly what this can look like and what the responses the request should elicit from the server. For example, the server might send back the message
HTTP/1.1 404 Not Foundwhich indicates that it did not have a file
For many services/protocols, there are standard utilities that allow you to use that service/protocol. We saw this already with name resolution:
service: Name Resolution, protocol: DNS, tool: nslookup
------------------------------------- You Grandma ← Corresponder Layer ------------------------------------- mail man mail man ← Carrier Layer ------------------------------------- post office post office ← Depot Layer ------------------------------------- | | ← Shipping Layer `-- trucks,trains,planes --' -------------------------------------In this model, there are two important features: 1) Each layer has a concrete, well-defined role — the service it provides, and 2) each layer only needs to know how to interact with the layers directly above and directly below them as the letter travels down one side of the stack, over to the other side at the bottom layer, then up the stack on other side — these interactions are governed each by their own protocol. For example, to send a letter the Corresponders Layer you need to follow the addressing & stamping rules and you need to know that you leave the letter sticking out of your mail slot / box. What happens after that doesn't matter to you. To recieve, of course, you just have to know to check your mail slot / box. Once again, how the other layers operate is not something you need to know about. If you're operating at the carrier layer, you just need to know: where to pick up your bag of letters at the post office, how to read the addresses so you can deliver letters to mail slots / boxes, where at the post office to bring the outgoing letters you picked up from peoples' mail slots / boxes along your route. What's going on between the Corresponders, whether the letters will be sent via train or ship by the Shipping layer ... all this is irrelevent to you. And so it goes with the other layers as well. Any individual within this system can be identified as acting at one of these layers, whether it's Grandma, or George the Postman, or Jenny the Cargo Jet Pilot.
In the mail example, we started with a system we already knew all about and understood well and organized it into a layered protocol stack. Now, we'll start with the layered protocol stack organization for the internet, and we'll learn about and try to understand the internet based on it. The layers in the TCP/IP stack are:
----------------- Application Layer ----------------- Transport Layer ----------------- Internet Layer ----------------- Link Layer ----------------- Physical Layer -----------------Let's dispense with the easiest of these to understand: The Physical layer is wires and radio waves. Relatively little of what goes on in this course deals with this layer directly, so we won't say too much about it. In Cyber II, you'll learn a lot more about it. The application layer is about programs running on different hosts that want to communicate — like you and Grandma in our snail mail analogy. Our most familiar example of an application layer protocol is HTTP, the protocol that governs communication between web servers and browsers. Ideally, web servers and browsers need to know two things: the language they speak to one another (the HTTP protocol) and the protocol that governs interactions with the next layer down: the transport layer. So what is the transport layer all about?
To understand the transport layer, we should really understand what kind of service application-layer programs.need. Let's focus on the application-layer programs we're most familiar with: web-servers and web-clients. Basically, a client needs to send a bunch of bytes to the server (its request), and then wait and around and ultimately receive a bunch of bytes from the server (the server's response). The server needs the reverse. This is the service browsers and webservers need the transport layer to provide. In the case of HTTP, the browser specifies the host it wants to connect to, the bytes it wants sent and waits around for an answer. In order to make a connection, send all those bytes, and receive the response bytes back, the transport layer has to on one side break the request/response message up into small pieces and wrap each piece up with an addressed to form a packet, and on the other side reconstitute the received packets into a full message. Getting each individual packet from one host to the other is not the busnines of the transport layer. That's done by the next layer down: the Internet layer.
The internet layer is responsible for routing packets across the internet from the source host to the destination host. The protocol that governs it, the Internet Protocol (IP), defines what constitutes a valid address and what format the bytes that make up a packet have to follow. What's interesting is that IP makes no guarauntees about delivering packets. Packets may get to their destination ... or not. A sequence of packets sent from one host to another may arrive in the proper order ... or not. The service is fundamentally unreliable. You're only guaraunteed best effort delivery. (Same with mids. We prof's are not guaraunteed that Midshipman X will learn the material, only that we'll get Midshipman X's best effort. We are gaurauneed of that, right? ... right?) If some kind of gaurantee of delivery and proper ordering is required, that gaurantee becomes an extra duty of the transport layer. The internet layer does routing, so it looks at the destination address on a packet and chooses what host to send the packet to next. Actually getting the packet from the current host to the next one is the job of the Link Layer. You'll learn more about the link layer when you build wired and wireless networks later on.
To summarize the upper layers, which are most important to us: Any programs that communicate over the internet to provide services to users (web, video-conferencing, file sharing, etc) are in the Application Layer. The Transport Layer is responsible for getting bytes from a process (executing instance of a program) on host A to process (executing instance of a program) on host B. The Internet Layer is responsible for getting packets from host A to host B.
http://www.usna.edu:80tells the browser to use port 80 (which it would've done anyway), while
http://www.usna.edu:53tells the browser to use port 53. This request will fail, of course, because USNA's webserver isn't listening on port 53, it's listening on 80. DNS nameservers listen on port 53.
http://www.usna.edu, the browser asks for the name to be resolved by DNS and discovers it's 18.104.22.168, and then sends its GET request to:
IP address: 22.214.171.124 , port: 80 , protocol: IPv4-TCPbecause "everyone knows" web servers use TCP on port 80. What port number the browser uses is irrelevent and is basically randomly assigned. But it's crucial that the web server listens for requests on port 80. In general, it's absolutely crucial that a server providing a service uses a well-known port number so that client process on other machines know where to send their requests.
This mapping between protocols/services and ports is very important for cyber security. You will start to develop your own list of services-to-ports you remember as the semester progresses. Check out this list of service-to-ports mappings. You may note things like, for example, that World of Warcraft uses port 3724. In fact, there is an organization called IANA (Internet Assigned Numbers Authority) that controls the allocation of port numbers to services (as well as controlling the top-level domain names).
nc) is a very flexible and powerful tool. At its simplest, you give it an IP address (or symbolic name that it will resolve for you via DNS) and a port number, and whatever you type into after pressing enter gets sent to the given address and port using IPv4 TCP. In this mode it acts as a TCP client. The next simplest mode you give the
-lswitch (listen) and nc then acts like a server, listening for a connection request, accepting the first one it receives, then echoing whatever gets sent to it to the screen, and taking whatever gets typed on the screen and sending it to the client whose connection request it accepted. This requires a demo to really get, which you had in class. The diagram below illustrates what commands users at two hosts would have to give to make a tcp connection with netcat.
Note: the server command on Host 10.53.88.12 must be given first! Otherwise, when the client calls there's nobody home!
Netcat with the
-u switch (UDP) uses UDP instead
of TCP. Since this is connectionless, the server version
accepts datagrams from any and all who send them, rather than
making a connection with one client. As another consequence,
the UPD server doesn't exit just because one of the clients
With netcat we as users can act like application layer programs. Like most application layer programs, we require that the transport layer provide us with services, which means at a bare minimum that we decide whether we want UDP or TCP. There's lots of interesting demos and activities we can do that demonstrate how TCP and UDP work and how they differ from one another.
netstatthat shows you what port/protocol combinations are currently in use on your machine. (It's a shell utility on both Windows and Unix.) On my machine right now, netstat lists a whole bunch of things including one interesting line given below.
Active Internet connections Proto Local Address Foreign Address State ... TCP 10.53.33.254:60503 126.96.36.199:https ESTABLISHED ...
nslookup mail.google.com, which resolved to the same address of 188.8.131.52.
What this tells us is that there is an established tcp
connection between a socket on my machine (10.53.33.254) bound
to port 59325 and a socket on a server at 184.108.40.206.
nslookup 220.127.116.11 tells me that's the address
for iad23s07-in-f21.1e100.net, which I know to be a Google mail server
because that's the only secure web page I had open at the time) bound
to the port associated with the https protocol, which my list of port
numbers tells me is port 443.
I can view all server processes running on my machine by name and
process ID by running
netstat.exe with the following
options in an Administrator shell:
netstat -alnpHowever, to really get all the process numbers and program names, you should run this as
root, i.e. run it like this:
sudo netstat -alnp
netstat.exe -abno Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900 RpcSs [svchost.exe] TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1448 CryptSvc [svchost.exe] TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING 544 [wininit.exe] TCP 0.0.0.0:49376 0.0.0.0:0 LISTENING 608 [services.exe] UDP 0.0.0.0:68 0.0.0.0:0 LISTENING 988 Dhcp [svchost.exe] ⋮
The only thing missing here are the process' owners. To get that in
Windows, we need another program called
tasklist.exe. In an
Administrator shell, run the following command:
tasklist.exe /v Image Name PID Session Name Session# Mem Usage Status User Name CPU Time Window Title ====================== ===== ============ ======== ============ ======== ============================ ========= ============ System Idle Process 0 Services 0 24 K Unknown NT AUTHORITY\SYSTEM 557:44:44 N/A System 4 Services 0 1,312 K Unknown N/A 4:41:28 N/A smss.exe 332 Services 0 492 K Unknown NT AUTHORITY\SYSTEM 0:00:00 N/A csrss.exe 476 Services 0 2,996 K Unknown NT AUTHORITY\SYSTEM 0:00:37 N/A wininit.exe 544 Services 0 1,368 K Unknown NT AUTHORITY\SYSTEM 0:00:00 N/A services.exe 608 Services 0 10,956 K Unknown NT AUTHORITY\SYSTEM 0:08:48 N/A lsass.exe 624 Services 0 14,820 K Unknown NT AUTHORITY\SYSTEM 0:04:03 N/A ⋮ svchost.exe 900 Services 0 10,132 K Unknown NT AUTHORITY\NETWORK SERVICE 0:00:20 N/A svchost.exe 988 Services 0 29,776 K Unknown NT AUTHORITY\LOCAL SERVICE 0:03:05 N/A ⋮ svchost.exe 1448 Services 0 32,400 K Unknown NT AUTHORITY\NETWORK SERVICE 0:20:43 N/A ⋮
Now, with these two administrative tools, I can figure out which processes are providing network services (listening on a network socket) on my computer and who owns those processes. This is a big deal for me to understand my computers risk for intrusion. Think of it this way - if I wanted to protect my home from intruders, I would want to know where all of the possible entrances are so that I could seal them up. Obviously, I cannot seal them all since I need at least one entrance to get in and out and a window or two for fresh air, but fewer is more secure. The same notion applies to processes providing network services on computers - fewer is better. Unecessary services should be stopped and removed from computers to make them more secure from network attacks.
Leaving only essential entryways in my home is not the complete solution. Where those entryways are is also important. I am most vulnerable when I sleep; therefore, none of my entrances should lead directly into my bedroom. They should lead to other, less important, rooms so that my bedroom door can provide an extra layer of security. Processes that are running as the superuser are like entrances directly to my bedroom. If they are compromised, I become defenseless against harm from the intruder.