Intro to Network Communications

So far, our lectures have primarily focused on our own, isolated computing environments. Now, we will study the networks and communications transporting data across the world, specifically studying a standard called Transmission Control Protocol (TCP)/Internet Protocol (IP). Recall from the Intro to the World-Wide-Web and HTML class that the Advanced Research Projects Agency Network (ARPANET) was the precursor to the Internet. The development of the TCP/IP model has since been the de facto standard for the Internet as we know it today, with Requests for Comments (RFCs) published under 791 for IP and 793 for TCP.

  TCP/IP STACK LAYERS        COMPUTER ARCHITECTURE
+-----------------------+     +------------------+
| Layer 5 - APPLICATION | >>> | USER/APPLICATION |
+-----------------------+     +------------------+
| Layer 4 - TRANSPORT   | >>> |  APPLICATION/OS  |
+-----------------------+     +------------------+
| Layer 3 - NETWORK     | >>> |   OS/HARDWARE    |
+-----------------------+     +------------------+
| Layer 2 - DATA LINK   | >>> |     HARDWARE     |
+-----------------------+     +------------------+
| Layer 1 - PHYSICAL    | >>> |     HARDWARE     |
+-----------------------+     +------------------+

Each layer of the TCP/IP Stack has a specific responsibility that allows the transition of data from one layer to another. Additionally, each layer only needs to know how to interact with the layers directly above and below it. This is broadly analogous to postal mail. When you send a letter to grandma, there are certain standards you must conform to - such as proper addressing and postage - but once you mail the letter, you are agnostic to how the post office delivers it to grandma (such as whether the post office used a train, plane, or automobile to move the letter). Meanwhile, the postal worker is not concerned with the content of your letter, but making sure it’s properly delivered from the mailbox to the post office - or from the post office to grandma’s mailbox, on the other end.

Encapsulation and Decapsulation (aka Deencapsulation). As data moves down the stack (from the application layer to the physical layer) it is encapsulated by adding information to a message, such as purposefully-constructed header and footer information, to ensure proper handling and routing by the next layer. As the data arrives at its destination, and moves back up the stack, these headers and footers are used to route or process the application data, then are removed and discarded in a process known as decapsulation (sometimes written as deencapsulation).

Overview of Networking Terminology and Utilities

The following components comprise computer networks:

A Protocol for Tactical Voice Communications

The document ACP 125 gives a protocol for communications between Allied Forces on tactical voice nets, to "provide a standardized way of passing speech and data traffic." The protocol specifies such things as a phonetic alphabet ("ALFA, BRAVO, ..., ZULU"), prowords (e.g., "say again", "roger" ), how to unambiguously record a message (e.g., zero written as: Ø, letter Z written as: Ƶ), and brevity codes (e.g. the brief phrase "Birds away" means "Friendly surface-to-air missiles have been fired at the designated target").
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 call signs S7 and CC:

CC: "Sierra Seven this is Charlie Charlie,
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."
S7: "This is Sierra Seven, roger, out."

Host

A host is any hardware device that has the capability of permitting access to a network via a user interface, specialized software, network address, protocol stack, or any other means. Some examples include, but are not limited to, computers, personal electronic devices, thin clients, and multi-functional devices.

Network

A network is a system implemented with a collection of interconnected components. Such components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices.

Protocol

A protocol is a set of rules used by two or more communicating entities that describe the message order and data structures for information exchanged between the entities. Internet protocols are typically codified in RFCs and developed by the Internet Engineering Task Force (IETF), while organizations such as the International Organization for Standardization (ISO) and Institute of Electrical and Electronics Engineers (IEEE) help codify a variety of other protocols, such as Wi-Fi and Bluetooth. Example protocols:

• ARP - Address Resolution Protocol
• DHCP - Dynamic Host Configuration Protocol
• HTTPS - HyperText Transfer Protocol Secure
• ICMP - Internet Control Messaging Protocol
• IP - Internet Protocol
• NTP - Network Timing Protocol
• SMTP - Simple Mail Transfer Protocol
• TCP - Transmission Control Protocol
• TFTP - Trivial File Transfer Protocol
• UDP - User Datagram Protocol
• VoIP - Voice-over-IP

Services

A process used or provided by programs to leverage network connectivity, which may be referred to as a daemon. Services utilize and follow protocols in order to establish network connectivity for an application, such as an Apache web service (daemon) running on the Linux server that allows the client-side browser to send an HTTP GET request to access a hosted webpage. Example services:

• Mail
• Name Resolution
• Web

Utilities

Common utility programs that will be used to evaluate network communications within the course will leverage organic tools available on the system, typically within a shell environment. Some of these utilities will include viewing processes and network connections, assessing network connectivity, looking up network services, and using network configuration tools. Example utilities:

• arp - displays IP-MAC resolution
• ipconfig - displays network information
• netstat - displays network connections
• nslookup - queries the name server
• ping - sends ICMP request to see if an IP host is responding
• tasklist - outputs running processes
• tracert - sends ICMP request to each hop until final destination

Introduction to the Application Layer

There are many terms that seem to be used interchangeably, with application being one of them. It is important to distinguish between the subtle differences no matter how minor and this class will clarify some of the terms and tools to understand Layer 5 - Application Layer. Based on the National Institute for Standards and Technology (NIST) glossary, the term "application" is generally used when referring to a component of software that can be executed. The difference between an application and process is that an application, being a component of software that can be executed, has yet to be run and resides in non-volatile storage, whereas a process is executing, being run by the Central Processing Unit (CPU) and resides in Random Access Memory (RAM) volatile storage.

At the Application layer of the TCP/IP Stack, "applications" refers to processes (including daemons) that provide services that communicate data across a computer network.
Daemons are processes running specifically on the server-side to provide a service, such as web, name resolution, or mail. Daemons usually run in the background and handle requests for service that it provides.

Gmail Scenario. Throughout this part of the course, we will be building on this "Gmail Scenario" as a demonstration of how the TCP/IP Stack works. We start with your laptop and connect to Gmail at mail.google.com. Notice that accessing mail.google.com is not a mail service but a web service because we use our web browser to access it. As a precursor to the next lesson, know that the default Transport Layer port for HyperText Transfer Protocol Secure (HTTPS) is TCP port 443. Before your laptop can connect to the Gmail server, it must query a DNS server resolve the name mail.google.com to its IP address. For name resolution, the default port is UDP port 53. We'll focus more on these port numbers later. For now, we focus on the application layer, which includes HTTPS and DNS.

1. Your laptop's application layer generates a DNS query (#1) and passes it down to your laptop's transport layer.
   **See the next lesson for what happens below the application layer.**
   The DNS server's application layer receives the deencapsulated DNS query (#1).
2. The DNS server's application layer processes the DNS query (#1), generates a DNS response (#2), and passes the DNS response (#2) down to the DNS server's transport layer.
   **See the next lesson for what happens below the application layer.**
   Your laptop's application layer receives the deencapsulated DNS response (#2).
3. Now that your laptop has the IP address for mail.google.com, your laptop's application layer generates an HTTPS request (#3) for the Gmail web server and passes it down to your laptop's transport layer.
   **See the next lesson for what happens below the application layer.**
   The Gmail web server's application layer receives the deencapsulated HTTPS request (#5).

Activity: Analyzing Web and Mail Exchange Services

Web and mail are two different services and this activity will analyze network information to determine how each of the services are implemented.

1. Open a browser and navigate to mail.google.com.
   • Click on the address bar and the scheme will be HTTPS, which is a web service.
   • Open PowerShell and resolve the domain mail.google.com by entering: nslookup mail.google.com
     
   • In PowerShell, run the netstat command to observe network connections to any of the IPs that match mail.google.com: netstat -an | findstr "443". If you have a lot of browser tabs open, you'll see a lot of connections using port 443.
   • TCP/443 is a web service that has now been associated with your connection with mail.google.com. Can you find a connection in the list with one of the IP addresses listed in the nslookup output?
2. In the browser, select an email to analyze by expanding the ellipses and clicking on Show Original.
     
3. A new tab will open displaying the original message header and details. Take a moment to read through the content and pull out information that can be used to assess technical details, such as domain names and IP addresses.
4. Various parts of the message will identify a domain name of mx.google.com. This is the mail exchange service that is identified for organizations, using domain names similar to that of web domains. The usna.edu domain is used in both web (https://www.usna.edu) and mail services (m9999@usna.edu).
     - If you are not able to read through and find the mx value, use Ctl+F to find it within the message.
5. Open PowerShell and run a DNS query for mx.google.com: Resolve-DnsName -name google.com -type mx
6. The NameExchange value should have returned smtp.google.com, which is the Simple Mail Transfer Protocol (SMTP) or mail service that operates using TCP/25.
7. Conduct a DNS lookup using the PowerShell cmdlet Resolve-DnsName -name smtp.google.com or nslookup smtp.google.com

   NOTE: The name resolution of what was returned in the shell and the scenario will differ because IP addresses will change over time. That is the purpose of DNS, to provide the most up-to-date information based on the existing infrastructure.

Application Layer Overview

Processes. Software and code that resides on non-volatile storage is not in use and has not been executed to run on a system. It is not until a user starts the application for resources to be allocated by the OS, such as CPU and RAM. A process ID (PID) is assigned and can be observed by running the command tasklist in Windows.

For example, Google Chrome is a web browser application that is installed on your computer. Once run by double-clicking on the application, it becomes a process that can now be seen by running the command tasklist | findstr "chrome" with a measure of the amount of memory currently being utilized. The column names will not appear when filtering an output but running tasklist on its own will reveal that information. The PID can also be used to refine netstat outputs to see what network connections are being used by that process.

PS C:\Users\m9999> tasklist | findstr "chrome"
chrome.exe                   10472 Console                    1    107,896 K

C:\Users\m9999>tasklist

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
System Idle Process              0 Services                   0          8 K
System                           4 Services                   0     14,872 K
Registry                       148 Services                   0     66,796 K
smss.exe                       616 Services                   0      1,056 K
csrss.exe                     1448 Services                   0      5,556 K
wininit.exe                   1820 Services                   0      6,496 K
csrss.exe                     1828 Console                    1      6,436 K
services.exe                  1900 Services                   0     16,828 K
lsass.exe                     1920 Services                   0     27,504 K
svchost.exe                   2044 Services                   0     48,312 K
WUDFHost.exe                  1484 Services                   0     10,084 K
fontdrvhost.exe               1496 Services                   0      3,336 K
svchost.exe                   1624 Services                   0     26,236 K
chrome.exe                   10472 Console                    1    107,896 K
tasklist.exe                   656 Console                    1      9,208 K

PS C:\Users\m9999> netstat -ano | findstr "10472"
  TCP    10.60.145.241:55813    142.251.45.98:443      ESTABLISHED     10472
  TCP    10.60.145.241:55878    104.16.19.94:443       ESTABLISHED     10472
  TCP    10.60.145.241:55969    142.250.73.196:443     ESTABLISHED     10472
  TCP    10.60.145.241:55973    172.217.1.202:443      ESTABLISHED     10472
  TCP    10.60.145.241:56343    142.251.33.206:443     ESTABLISHED     10472
  TCP    10.60.145.241:57179    172.217.13.238:443     ESTABLISHED     10472
  TCP    10.60.145.241:57308    142.251.45.98:443      ESTABLISHED     10472
  TCP    10.60.145.241:58207    142.251.45.98:443      ESTABLISHED     10472
  TCP    10.60.145.241:58729    172.217.1.195:443      ESTABLISHED     10472
  TCP    10.60.145.241:59080    157.240.229.35:443     ESTABLISHED     10472
  TCP    10.60.145.241:59750    172.217.9.197:443      ESTABLISHED     10472
  TCP    10.60.145.241:60573    142.250.65.78:443      ESTABLISHED     10472
  TCP    10.60.145.241:61205    142.250.188.33:443     ESTABLISHED     10472
  TCP    10.60.145.241:61349    142.250.188.206:443    ESTABLISHED     10472
  TCP    10.60.145.241:61778    142.250.188.202:443    ESTABLISHED     10472
  TCP    10.60.145.241:63006    199.127.207.183:443    ESTABLISHED     10472
  TCP    10.60.145.241:63785    172.253.63.188:443     ESTABLISHED     10472
  TCP    10.60.145.241:63864    208.118.62.69:443      ESTABLISHED     10472
  TCP    10.60.145.241:64634    162.247.243.146:443    ESTABLISHED     10472
  TCP    10.60.145.241:64855    172.217.12.229:443     ESTABLISHED     10472
  TCP    10.60.145.241:64957    172.217.15.74:443      ESTABLISHED     10472
  TCP    10.60.145.241:65196    142.251.45.98:443      ESTABLISHED     10472
  UDP    0.0.0.0:5353           *:*                                    10472
  UDP    0.0.0.0:5353           *:*                                    10472

Let's investigate further by conducting a DNS query into Google's Gmail web services (if you haven't already done so as part of the activity). Use the nslookup utility to query the USNA name server and see what is returned for mail.google.com. Then associate the IP address to a network connection by piping the output of netstat -ano to the findstr command and searching for the IP associated with mail.google.com.

PS C:\Users\m9999> nslookup mail.google.com
Server:  ns1.usna.edu
Address:  10.1.74.10

Non-authoritative answer:
Name:    googlemail.l.google.com
Addresses:  2607:f8b0:4004:807::2005
          172.217.12.229
Aliases:  mail.google.com

PS C:\Users\m9999> netstat -ano | findstr "172.217.12.229"
  TCP    10.60.145.241:64855    172.217.12.229:443     ESTABLISHED     10472

Based on the output, the Chrome application with the process chrome.exe has now been associated with PID 10472 and has an established network connection to mail.google.com with a DNS resolution of 172.217.12.229 over TCP/443.

We can summarize our findings based on the table below:

Now that we've explored the client side of the connections, let's look at a daemon running on a server. Permissions limit users' ability to look into the Apache2 web service, so the ssh, or SSH daemon, will suffice.

1. Connect to the SSH server: ssh m9999@
2. View the ssh server process: systemctl status ssh
3. View the ssh server process based on your specific connection by running the process status command ps and greping the output to filter the sshd process and greping that output based on your specific username: ps -ef | grep ssh | grep m9999
   (Your output may differ slightly, but should look very similar.)

m9999@ward-rweb-09:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; disabled; preset: enabled)
     Active: active (running) since Sun 2023-08-27 06:17:31 EDT; 1 month 4 days ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 5591 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 5598 (sshd)
      Tasks: 3 (limit: 629145)
     Memory: 182.8M
        CPU: 16min 56.072s
     CGroup: /system.slice/ssh.service
             ├─   5598 "sshd: /usr/sbin/sshd -D [listener] 1 of 10-100 startups"
             ├─2025123 "sshd: m276720 [priv]"
             └─2025124 "sshd: m276720 [net]" ""
m9999@ward-rweb-09:~$ ps -ef | grep ssh | grep m9999
root     1730983    5598  0 14:13 ?        00:00:00 sshd: m9999 [priv]
m9999  1731040 1730983  0 14:13 ?        00:00:00 sshd: m9999@notty

Ports, Protocols, and Services (PPS). Enterprise-level management for Information Technology (IT) organizations can be extremely challenging and implementing a PPS Management (PPSM) solution is a critical part of a configuration management program. The hundreds of thousands of services and network connections utilized by thousands of students, staff and faculty, can seem overwhelming but starting with identifying critical PPS is a way to define recovery, restoration, and reconstitution when a disaster impacts any part of the tenets of cybersecurity or the CIA-triad.

Application Layer Protocols

Each of the below protocols have a default Transport Layer port that the server will listen for incoming client requests on. The default Transport Layer port is a part of the Application Layer protocol specification. However, there is nothing preventing the use of any Application Layer protocol on any Transport Layer port. That is, any of the below protocols can be used on any Transport Layer port. But, in order for a client to use the service being provided they need to know the port the server is listening on. By offering services on the default port, then clients (users) are able to easily find and use the service. Offering services on other than default ports only makes it more difficult, but not impossible, for users on the Internet to find the service.

DNS Servers. . . . . : 10.1.74.10

PS C:\Users\m9999> nslookup courses.cyber.usna.edu
Server:  ns1.usna.edu
Address:  10.1.74.10

Name:    ward-rweb-08.academy.usna.edu
Address:  10.1.83.71
Aliases:  courses.cyber.usna.edu

PS C:\Users\m9999> nslookup 10.1.74.10
Server:  ns1.usna.edu
Address:  10.1.74.10

Name:    ns1.usna.edu
Address:  10.1.74.10

https://www.archive.org/

https://207.241.224.2

GET /prices.html HTTP/1.1

HTTP/1.1 404 Not Found